IANAQSA, and a lot of this has more to do with contractual merchant-processor-card brand obligations than the DSS per se, so there's more "I think" than "I know" than usual here:
Suppose we have an e-commerce website where payment is done via
redirection to a payment provider, with no processing / storage of
cardholder data at our site (I'll update if needed with exact PCI
merchant category, but I understand that it's the lowest one, all
cardholder data is handled by the payment provider).
It sounds like you're a merchant subject to SAQ A. This limits the extent of the PCI DSS that you're required to adhere to. Particularly relevant to your questions, you're not subject to the patching requirements found in DSS 6 or log analysis of DSS 10.
One of the problems of SAQ A (IMHO!) is that all the protections it relies upon are trivially subverted by an attacker who is able to poison your site, but SAQ A doesn't subject you to the particular requirements (like 6 and 10) that would help secure your site against that vector. Be carefully aware that when you're not being held accountable to the protections, you will still be left holding the responsibility later.
(For example, simply requiring File Integrity Monitoring (FIM) as per DSS 11.5 on SAQ A merchant pages that direct customers to the iframe or javascript of the processor would be a huge increase in security. There are hundreds of Magento users who have learned this in the last month or two.)
- Is there a requirement for conducting investigation to identify whether these vulnerabilities have been exploited?
No, but if you have any reason to believe they have been exploited, then you have obligations as a merchant to investigate the potential card breach (e.g., think in card/transaction terms, not computer forensics terms). As you state that you "have no internal capabilities for forensics investigation, log review or any other detection activity" then if you determine there was a breach any ensuing technical investigation would involve hiring an outside firm (you have contractually agreed to do so already, if you're acceping card payments).
When I say "any reason to believe they have been exploited," I mean "any indication of increased fraud related to cards your customers have entrusted to your processor on your behalf." Again, think in card terms.
- Is there a mandatory disclosure to anyone?
You are not required to disclose the fact that you've determined you have vulnerabilities. You are required to disclose any believed breach of customer data, even if you don't hold that customer data - for example, if your support line starts getting a drastically increased volume of complaints from customers who say "I bought something at your site, and the next day fraudulent charges began to appear on my card!"
Bear in mind that your processor and the card brands also do statistical analysis, and are just as likely to notify you that you've had a problem as you are to notify them. Which leads to:
- An obligation in terms of delay for remediation?
If you're breached, and in the ensuing investigation it becomes clear that your failure to detect and remediate your security issues in a timely manner was a contributing factor, then whatever fines or sanctions you face may be worsened. So it's absolutely in your best interest to deal diligently with these issues, and to maintain a clear timeframe.
Think of it as a legal issue of due diligence; again, as a SAQ A merchant you aren't subject to portions of the DSS that might draw lines around this, but you're sure left holding the bag if there's a breach.