A supplier's product you run has an actively exploited flaw. What to do in the first 4, 24 and 72 hours, and how the vendor's CRA clock lines up with your DORA, NIS2 and GDPR clocks.
The advisory lands before the vendor's email
A security analyst sees a public advisory: a remote-access appliance your company runs at two sites has a vulnerability that is being exploited in the wild, and it has just been added to CISA's Known Exploited Vulnerabilities catalog. There is no message from the vendor yet. The vendor management team doesn't know which contract covers the product, and nobody is sure whether this is already a reportable incident.
This is the third-party incident that most plans describe in one line. Below is the longer version: what to establish in the first 4, 24 and 72 hours, which deadlines apply to whom, and what you will wish you had written down.
Whose clock is it?
Two different sets of obligations start at roughly the same time, and they are easy to confuse.
The vendor's: if it is the manufacturer of a product with digital elements sold in the EU, the Cyber Resilience Act has required it since 11 September 2026 to report actively exploited vulnerabilities to its coordinating CSIRT and ENISA, and to inform impacted users. Our post on the Cyber Resilience Act covers those duties in detail.
Yours: an exploited vulnerability is not automatically an incident for you. It becomes one if it affects your systems, data or services. From that point your own reporting regime applies, and its clock starts from when you become aware or classify the incident, not from when the vendor tells you anything.
Which deadlines can apply?
- The vendor, under the CRA (Art. 14(2)): early warning within 24 hours of becoming aware of an actively exploited vulnerability, a vulnerability notification within 72 hours, and a final report no later than 14 days after a corrective or mitigating measure is available. Art. 14(8) adds a duty to inform impacted users about the vulnerability and the measures they can take.
- A financial entity, under DORA (Art. 19, with Commission Delegated Regulation (EU) 2025/301): for a major ICT-related incident, an initial notification within 4 hours of classifying it as major and no later than 24 hours after becoming aware of it, an intermediate report within 72 hours of the initial notification, and a final report within one month of the latest intermediate report.
- An essential or important entity, under NIS2 (Art. 23(4)): for a significant incident, an early warning within 24 hours of becoming aware, an incident notification within 72 hours, and a final report no later than one month after the notification. For financial entities in DORA's scope, DORA's reporting applies instead (NIS2 Art. 4).
- Any controller, under GDPR (Art. 33): a personal data breach goes to the supervisory authority within 72 hours of becoming aware of it, unless it is unlikely to result in a risk to people. If the vendor is your processor, Art. 33(2) requires it to notify you without undue delay.
Hours 0 to 4: are we exposed?
Before anything else, find out whether you run the affected product and version, and where. This is an inventory question, and it is answered fastest when your vendor register links each vendor to the products, versions and business services that depend on it.
- Which business units, sites and versions run the product? Is the vulnerable component internet-facing?
- Which business services depend on it, and are any of them critical or important functions?
- What data passes through it: personal data, payment data, credentials?
- Is there any sign of exploitation already: alerts, unusual logins, new accounts, outbound traffic?
- Who is the incident owner, and who decides whether this is reportable?
Hours 0 to 4: reach the vendor
Use the security contact named in the contract or the vendor's published disclosure policy, not the account manager's mobile number. Ask in writing, so the answers become part of your record:
- Is our version affected, and is a fix or mitigation available now?
- Is there evidence of exploitation against customers, and are there indicators of compromise we can search for?
- Has your own service or infrastructure that processes our data been affected?
- When will you send your next update, and through which channel?
Hours 4 to 24: what does the contract say?
Pull the contract while the technical team works. For a financial entity, DORA Article 30(2)(f) requires every ICT contract to oblige the provider to assist when an ICT incident related to its service occurs, at no additional cost or at a cost set in advance. For services supporting critical or important functions, Article 30(3)(b) adds notice periods and reporting obligations of the provider towards you. Our DORA Article 30 checklist lists the full set of clauses.
Outside DORA, look for the same three things: a notification obligation with a time limit, an assistance or cooperation obligation, and a right to information or audit after the event. If the contract only promises "commercially reasonable efforts", write that down now. It will matter in the post-incident review and at renewal.
In the same window, classify. Under DORA, the 4-hour clock for the initial notification starts at classification, and the 24-hour backstop starts at awareness, so a slow classification does not buy time.
Hours 24 to 72: mitigate and decide
By now you should have the vendor's advisory or know that it is late. Each option is a decision someone owns:
- Patch or apply the vendor's mitigation, and confirm it took effect.
- Apply compensating controls: restrict network access, disable the vulnerable feature, add monitoring.
- Suspend the service or switch to a fallback where the risk is unacceptable, using the exit plan if you have one.
- Accept the residual risk for a defined period, with a named approver and a review date.
Why record every decision?
Your intermediate report under DORA and the incident notification under NIS2 both fall in this window. They ask what happened, what the impact is and what you did. Without a log, those answers get rebuilt from chat threads and email.
Keep a simple record per decision: what was known at the time, what was decided, by whom, when, and on what evidence. The vendor's statements belong in it too, with their timestamps. If the vendor's notification arrived after your own deadline, that is a finding about the contract, not only about the incident.
After 72 hours: close the loop
- Submit final reports on the applicable timelines and keep the vendor's final advisory with them.
- Re-run the vendor review: did the vendor meet its contractual notification and assistance obligations?
- Update the contract at the next opportunity: notification time, security contact, support period, assistance terms.
- Update the vendor register with the product, version and dependency gaps the incident exposed.
What to prepare if you are the vendor
Your customers will be running this playbook against you. The fastest way to shorten their 72 hours is to answer their first questions before they ask:
- A security contact and a published coordinated vulnerability disclosure policy.
- A customer advisory template that states affected versions, exploitation status, mitigations and the time of the next update.
- A list of which contract commits you to which notification time, per customer segment.
- If you are a manufacturer under the CRA, a tested process for the 24-hour early warning and the user notification in Art. 14(8).
See how vendor documents become findings
The ProcureCortex demo at procurecortex.com/explore (self-serve: email sign-in link, no sales call) shows vendor reviews where each finding links to the document and clause it came from, with a recorded reviewer decision, which is the record this playbook relies on. All vendors and findings in the demo are sample data, and the demo labels findings against SOC 2, ISO 27001, GDPR and contract clauses; mapping them to DORA, NIS2 or the CRA is your own team's analysis.
Sources
- Regulation (EU) 2022/2554 (DORA), Articles 18, 19 and 30: https://eur-lex.europa.eu/eli/reg/2022/2554/oj
- Commission Delegated Regulation (EU) 2025/301, content and time limits for major ICT-related incident reports: https://eur-lex.europa.eu/eli/reg_del/2025/301/oj
- Directive (EU) 2022/2555 (NIS2), Articles 4 and 23: https://eur-lex.europa.eu/eli/dir/2022/2555/oj
- Regulation (EU) 2024/2847 (Cyber Resilience Act), Article 14: https://eur-lex.europa.eu/eli/reg/2024/2847/oj
- Regulation (EU) 2016/679 (GDPR), Articles 28 and 33: https://eur-lex.europa.eu/eli/reg/2016/679/oj
- CISA, Known Exploited Vulnerabilities Catalog: https://www.cisa.gov/known-exploited-vulnerabilities-catalog
Get the vendor review guide
One email a month with a worked example like this one. Nothing else.