Do these 3 things before closing this tab:
1Clear out junk files and repair common Windows errors2Scan for outdated or missing drivers - takes under a minute3Repair Windows errors before they cause bigger problemsiTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
As of 11 September 2026, manufacturers must report certain CRA vulnerabilities and product-security incidents—even though most of the Cyber Resilience Act does not apply until 11 December 2027. A single cyber event can also trigger separate NIS2, DORA or GDPR duties, each with its own scope test, clock and recipient. Assess each regime separately; one notification does not automatically satisfy the others.
This runbook reflects the European Commission, European Banking Authority and other official material available as of 7 October 2026. The deadlines below are not interchangeable: first identify the organisation’s legal role, then assess the event against each regime and record that regime’s trigger time, deadline and filing route.
Which incident-reporting rules might apply?
A security event does not have to meet every regime’s threshold. Nor does a company’s role under one rule establish its role under another. Start with the activity and entity involved, not the name given to the incident internally.
Windows Errors? Fix Them Before They Spread
Repair common Windows errors and clear accumulated junk for a smoother, more stable PC - no reinstall needed.Free scan · no reinstallOutdated Drivers Are Slowing You Down
One free scan finds every outdated or missing driver and matches the right update for your exact hardware.Free scan · exact hardware match| Regime | Who and what may trigger reporting? | Deadline sequence | Recipient and other notifications |
|---|---|---|---|
| Cyber Resilience Act (CRA) | A manufacturer becomes aware of an actively exploited vulnerability or a severe incident that impacts the security of its product with digital elements. | Early warning within 24 hours of awareness; full notification within 72 hours. For an actively exploited vulnerability, final report no later than 14 days after a corrective or mitigating measure is available. For a severe incident, final report within one month of the 72-hour notification. | Submit through the CRA Single Reporting Platform, addressed to the CSIRT in the Member State where the manufacturer has its main establishment. Information is normally made available to ENISA and shared with relevant CSIRTs. |
| NIS2 | An essential or important entity has a significant incident affecting its services. The test includes severe operational disruption or financial loss to the entity, or considerable material or non-material damage to another person or entity. | Early warning within 24 hours of awareness; incident notification within 72 hours; final report generally within one month of the incident notification. An intermediate report may be requested. | Report to the national CSIRT or competent authority specified by the Member State’s implementation. National or sector-specific arrangements can affect the route. |
| Digital Operational Resilience Act (DORA) | An in-scope financial entity has a major ICT-related incident under the applicable classification rules. | Under the adopted standards summarized by the EBA, the initial notification is due within four hours after classification and no later than 24 hours after detection. An intermediate report is due at 72 hours; the final-report timing is one month. | Report to the relevant competent authority using the applicable templates and filing instructions. Local arrangements may also involve NIS2 authorities or CSIRTs. |
| General Data Protection Regulation (GDPR) | A controller has a personal-data breach likely to pose a risk to individuals’ rights and freedoms. A processor has a separate duty to notify its controller of every personal-data breach. | The controller notifies the supervisory authority without undue delay and no later than 72 hours after becoming aware, if the risk condition is met. A high-risk breach can require communication to affected people. | Notify the relevant supervisory authority. The controller assesses whether individual communication is required and whether a statutory exception applies. |
When do I have to report a CRA incident?
The CRA reporting obligations in Article 14 apply from 11 September 2026, before the Act’s main provisions generally apply from 11 December 2027. The European Commission says the reporting duty covers products with digital elements made available on the Union market, including products already placed on the market before the general application date. Do not assume that an earlier product launch excludes it.
Identify the manufacturer and the reportable event
The duty described by the Commission is for manufacturers that become aware of either an actively exploited vulnerability or a severe incident impacting the security of their product with digital elements. It is not a general instruction to report every security event involving any connected product. Establish whether the organisation is the manufacturer and whether the vulnerability or incident meets the CRA description.
Keep the two final-report clocks separate
- Actively exploited vulnerability: Send an early warning within 24 hours of awareness and a full notification within 72 hours. The final report is due no later than 14 days after a corrective or mitigating measure is available.
- Severe incident affecting product security: Send an early warning within 24 hours of awareness and a full notification within 72 hours. The final report is due within one month of the 72-hour notification.
The two final-report deadlines have different triggers. Track which event type is being reported and calculate the applicable final date from its own trigger rather than assigning every CRA report a generic one-month deadline.
Use the CRA reporting destination
Manufacturers submit through the CRA Single Reporting Platform, addressing the notice to the CSIRT in the Member State where the manufacturer has its main establishment. The Commission describes the platform as operational from 11 September 2026. Information is normally made available simultaneously to ENISA, and the initial CSIRT shares it without delay with CSIRTs in other Member States where the product was made available. The Commission notes that onward sharing may be delayed in exceptional circumstances on justified cybersecurity grounds. Use the platform’s current user guidance and filing instructions; a general national breach portal is not automatically a substitute.
The separate CRA reporting duties for open-source software stewards under Article 24(3) are stated to apply from 11 December 2027. Do not conflate that future date with the manufacturer reporting start date.
What is a significant NIS2 incident?
NIS2 reporting is for essential and important entities in relation to significant incidents affecting their services. Under the Directive’s test, an incident is significant if it has caused or is capable of causing severe operational disruption or financial loss for the entity, or if it has affected or is capable of affecting others by causing considerable material or non-material damage.
Apply the NIS2 stages
- Early warning: Without undue delay and in any event within 24 hours of awareness.
- Incident notification: Without undue delay and in any event within 72 hours of awareness.
- Intermediate report: Provide one when requested by the competent authority or CSIRT.
- Final report: Generally no later than one month after the incident notification. If the incident is still ongoing, provide a progress report at that stage and a final report within one month after handling the significant incident.
The Commission’s NIS2 FAQ summarizes the usual sequence as 24 hours, 72 hours and one month. The Directive’s transposition deadline was 17 October 2024, but that date does not identify the portal or authority for a particular organisation. Because NIS2 is implemented by Member States, confirm the current national law, competent authority, reporting channel and any sector-specific rules for the entity’s jurisdiction.
What is the difference between a NIS2 significant incident and a DORA major incident?
NIS2 and DORA use different legal scopes and incident tests. NIS2 asks whether an essential or important entity has a significant incident affecting service provision. DORA reporting concerns an in-scope financial entity and a major ICT-related incident classified under the applicable financial-sector rules. Do not treat “significant” and “major” as synonyms or carry a NIS2 assessment over as a DORA classification.
Apply DORA’s detection and classification clocks independently
Article 19 of DORA requires financial entities to report major ICT-related incidents to the relevant competent authority through staged reports: an initial notification, intermediate reporting as the incident’s status or handling changes or when requested, and a final report when root-cause analysis is complete and actual impact figures are available.
The EBA’s summary of the adopted joint technical standards gives the initial deadline as within four hours after classification and no later than 24 hours after detection. These are two separate limits, not a choice between them. It also summarizes an intermediate report at 72 hours and a one-month final-report timing. Use the applicable adopted standards and current competent-authority instructions to determine the filing details.
Member States may additionally require certain entities to provide relevant reports to NIS2 CSIRTs or authorities. Confirm local arrangements; a DORA filing to the competent authority should not be assumed to resolve every related national reporting duty.
Who do I report a personal-data breach to?
First distinguish a personal-data breach from a security incident in general. A personal-data breach involves a security incident leading to accidental or unlawful destruction, loss or alteration of personal data, or unauthorised disclosure of or access to it.
Recommended Free Tools
Controller: assess risk to individuals
A controller must notify the relevant supervisory authority without undue delay and no later than 72 hours after becoming aware when the breach is likely to pose a risk to individuals’ rights and freedoms. The 72-hour rule is not a requirement to notify the regulator about every security incident. Record the controller’s awareness time and its risk assessment, including the rationale if authority notification is not required.
If the breach is likely to pose a high risk to individuals, the controller must also communicate it to affected people unless an applicable exception removes that requirement. The Commission describes exceptions where effective technical and organisational protection measures made the affected data unintelligible, or later measures mean the high risk is no longer likely to materialise.
Processor: notify the controller
A processor must notify the controller of every personal-data breach. Record when the processor notified the controller separately from the controller’s own awareness and authority-notification clock.
Do I have 24 or 72 hours to notify?
It depends on the regime and the event that starts its clock. For CRA and NIS2, the early warning is due within 24 hours of awareness, followed by a fuller notification within 72 hours. Under GDPR, 72 hours is the outside limit for a controller’s supervisory-authority notification after awareness when the breach is likely to risk individuals’ rights and freedoms; there is no corresponding 24-hour GDPR early-warning stage in the described rule. Under DORA, the initial filing has both a classification-based four-hour limit and a detection-based 24-hour backstop.
What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
Do not start all clocks from a single incident-ticket timestamp by default. Preserve awareness, detection and classification times as distinct facts, with the person or system that recorded each time and the supporting evidence.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.Can I submit one report for all four rules?
Not on the basis of the rules described here. CRA has its own Single Reporting Platform; NIS2 uses the route set by national implementation; DORA reports go to the relevant competent authority; GDPR notifications go to the relevant supervisory authority. A report sent under one regime does not automatically satisfy another regime’s duty.
The European Commission’s Digital Omnibus proposal describes a single-entry point for reporting under NIS2, GDPR, DORA, eIDAS and CER. It is a proposal, not evidence that the single-entry route is already operative. A European Parliament Research Service briefing also describes a proposed change to the GDPR authority-notification deadline from 72 to 96 hours. Keep the current 72-hour rule and existing filing routes in the operative runbook unless and until legislation is adopted and the relevant provisions apply. Monitor the legislative position because proposals can change.
How to turn one incident into separate reporting decisions
Use one incident record as a shared evidence base, but maintain a distinct scope decision, clock and filing status for every potentially applicable regime. That lets responders coordinate facts without assuming that one threshold, deadline or submission covers the rest.
Quick wins for a faster PC:
Scan for outdated or missing drivers - takes under a minuteDriver Scan →Clear out junk files and repair common Windows errorsFree Scan →- Establish roles and scope. Identify the affected legal entities, their activities, the product and manufacturer if relevant, whether an entity is essential or important under NIS2, whether it is an in-scope financial entity under DORA, and whether it acts as controller or processor for affected personal data.
- Build a time line. Record when the incident was detected, when each relevant party became aware, when a DORA classification was made, when measures became available, and when notifications were submitted. Keep evidence supporting each timestamp.
- Test each threshold separately. Assess the CRA event description, NIS2 significance, DORA major-incident classification and GDPR personal-data-breach risk independently. Record why a regime is in scope or why its reporting threshold is not met.
- Calculate each deadline from its own trigger. Include early, intermediate and final stages, where applicable. For CRA, distinguish vulnerability and severe-incident final reports; for DORA, calculate from both classification and detection; for GDPR, use controller awareness and the risk condition.
- Confirm recipients and channels. Check the current CRA platform instructions, the applicable NIS2 national route, the DORA competent authority’s filing instructions and the relevant GDPR supervisory authority. Identify any local or sectoral parallel route.
- Assign an owner and preserve the record. Track each notification’s owner, due time, submission time, acknowledgement and outstanding follow-up. Retain the facts, threshold assessment and decisions supporting each filing, including decisions not to notify.
The reporting workflow should make it possible to answer, for each regime: which entity had the duty, what event met or failed the threshold, when the clock started, what was due next, where it was sent and whether any affected people also had to be informed.
What to verify before relying on the runbook
- NIS2: National transposition, entity classification, sector rules, the competent authority or CSIRT, and the actual filing channel.
- DORA: Entity scope, incident classification, applicable adopted technical standards, competent-authority templates and any national reporting arrangements.
- GDPR: Controller awareness, the documented risk assessment, supervisory-authority route, and whether communication to individuals is required.
- CRA: Manufacturer status, product availability on the Union market, event type, the correct final-report trigger and current platform guidance.
- Proposed changes: Whether the Digital Omnibus has progressed to adopted legislation and whether relevant provisions have begun to apply. Do not replace current filing procedures based on proposal language alone.
The official material underpinning these timelines includes the European Commission’s CRA reporting and NIS2 pages, the text of Directive (EU) 2022/2555, the European Commission’s GDPR obligations page, DORA Article 19, the EBA’s summary of adopted joint technical standards, and the European Parliament Research Service briefing on the Digital Omnibus proposal. The Commission’s live GDPR obligations page still described the 72-hour rule in the material available on 7 October 2026.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
