Incident reporting deadlines compared: which clock starts first and how short it runs
A team that must notify more than one authority can face clocks ranging from one hour to four business days, and the shortest clock often starts first. Under CIP-008-6, an entity must make its initial notification within one hour after determining a Reportable Cyber Security Incident. DORA's incident rules under Delegated Regulation (EU) 2025/301 require an initial notification within 4 hours of classifying an incident as major and no later than 24 hours after becoming aware of it. NIS2 starts with an early warning within 24 hours. Because these clocks run from determination, classification or awareness, the first decision your team makes is whether an event counts as an incident at all, and that decision starts the timer.
The longer clocks are 72 hours under GDPR, measured from when the controller becomes aware of a personal data breach unless the breach is unlikely to risk individuals, and 72 hours under DFARS 252.204-7012 for cyber incidents affecting covered defense information, measured from discovery. HIPAA allows 60 calendar days to notify affected individuals of a breach of unsecured PHI, counted from the first day the breach is known or would have been known with reasonable diligence to any workforce member or agent. SEC Form 8-K Item 1.05 allows four business days, but the clock starts only after the registrant determines the incident is material, so the materiality judgment is the trigger.
The answer depends on sector, entity classification and the moment awareness or materiality is determined. NIS2 applies the same reporting obligations to essential and important entities, but national laws and sector rules decide which entities are in scope. Confirm which authorities you must notify, what each one treats as a significant incident and who decides classification. Then build one playbook that starts from the earliest trigger, maps each notification to its own clock and records timestamps for awareness, classification and each submission so you can show when each clock started.
Which reporting clock applies to which regime
EU cybersecurity law sets the most layered clocks. NIS2 applies to in-scope essential and important entities and reports significant incidents to the CSIRT or competent authority in stages: an early warning within 24 hours, an incident notification within 72 hours and a final report within one month of the notification (Article 23(4)). DORA applies to listed financial entities and uses its own timing set by Delegated Regulation (EU) 2025/301. The Cyber Resilience Act adds a separate clock for manufacturers.
- NIS2 stages: early warning at 24 hours, incident notification at 72 hours and a final report within one month of the notification. The recipient is the entity's CSIRT or competent authority.
- DORA initial notification: under Article 5 of Delegated Regulation (EU) 2025/301, the initial notification is due within 4 hours of classifying the incident as major and no later than 24 hours after becoming aware of it. The intermediate report follows within 72 hours of the initial notification, and the final report no later than one month after the latest intermediate report.
- Cyber Resilience Act: under Article 14 of Regulation (EU) 2024/2847, manufacturers report an actively exploited vulnerability with an early warning within 24 hours of becoming aware, a vulnerability notification within 72 hours and a final report within 14 days after a fix is available. Recipients are the CSIRT coordinator and ENISA through the Single Reporting Platform.
- Overlap: a financial entity under NIS2 may also face DORA, since Article 1(2) of DORA makes it a sector-specific act for NIS2 purposes. Confirm with your national authority which clock governs a given event.
Before you build a playbook, confirm with your supervisor how your national transposition law maps these stages to your sector.
The GDPR runs its own clock, separate from cybersecurity law. Under Article 33(1), a controller must notify the competent supervisory authority without undue delay and, where feasible, within 72 hours of becoming aware of a personal data breach. The duty does not apply when the breach is unlikely to result in a risk to individuals. A late notification must explain the delay.
- Trigger: awareness of a personal data breach that is likely to result in a risk to individuals. The clock starts on awareness, not on the completion of a forensic review.
- Recipient: the competent national supervisory authority, which is independent under Article 51.
- Late notice: if the 72 hours pass, the notice must give reasons for the delay under Article 33(1).
- Fines: Article 83 sets maximum fines of EUR 10 million or 2% of worldwide annual turnover for infringements such as Articles 25 to 39, whichever is higher.
- Same incident, two clocks: a single event may start a GDPR 72-hour clock and a NIS2 or DORA clock at the same time, so the notifications must be consistent with each other.
Confirm with counsel and your supervisory authority whether a given event is a personal data breach and whether the risk threshold is met.
US health and defense clocks differ sharply in length and recipient. HIPAA breach notification runs to individuals and is measured in calendar days. DFARS cyber incident reporting for defense contractors runs to DoD within 72 hours. Both trigger on discovery, and each has its own evidence rules.
- HIPAA individuals: covered entities must notify affected individuals without unreasonable delay and no later than 60 calendar days after discovering a breach of unsecured PHI (45 CFR 164.404). Notice goes by first-class mail, or by email if the individual agreed.
- HIPAA discovery: a breach counts as discovered on the first day it is known, or would have been known with reasonable diligence, to any workforce member or agent other than the person committing it.
- DFARS 72 hours: under DFARS 252.204-7012(c), contractors report cyber incidents affecting covered defense information to DoD within 72 hours of discovery, at dibnet.dod.mil, using a DoD-approved medium assurance certificate.
- DFARS evidence: paragraph (e) requires preserving images of affected systems for at least 90 days after the report.
- Practical point: the 60-day HIPAA window and the 72-hour DFARS window are both measured from discovery, so a single breach affecting a defense contractor's health data can run both clocks at once.
Confirm your DoD medium assurance certificate and dibnet access before you need them, and confirm with counsel how state breach laws add to the HIPAA duties.
US energy and securities rules set the shortest and the most material-driven clocks. NERC CIP-008-6 requires an initial notification within one hour of determining a reportable incident, and the SEC's Form 8-K Item 1.05 requires disclosure within four business days after a registrant determines an incident is material. Both recipients differ, and only the SEC clock depends on a materiality judgment.
- NERC CIP Part 4.2: the initial notification is due within one hour after determining a Reportable Cyber Security Incident. An attempt to compromise an applicable system has until the end of the next calendar day.
- SEC Form 8-K Item 1.05: disclosure is generally due within four business days after the registrant determines the incident is material. The SEC adopted these rules on July 26, 2023.
- SEC content: the disclosure covers the nature, scope, timing and material impact of the incident.
- Materiality clock: the SEC clock starts at a determination, so the documented date of that determination matters as much as the date of discovery.
- Recipient: NERC CIP reports go to the entity's designated reporting authority under the standard, while the SEC clock is a public disclosure filed with the Commission.
Confirm your NERC reporting contacts and your disclosure committee's decision steps with counsel before an incident occurs.
Side-by-side reporting clocks, triggers and recipients
This table sets each incident reporting clock against its trigger, its recipient and what the clock leaves out. Read across a row to see one regime, and down the trigger column to spot where two clocks may start on the same event. The main takeaway is that the clocks start at different moments and reach different recipients, so one incident can open several deadlines at once.
| Regime | Clock and trigger | Who is notified | What the clock does not cover |
|---|---|---|---|
| NIS2 (essential and important entities) | Early warning within 24 hours, incident notification within 72 hours, final report within one month of the notification (Article 23(4)). Triggered by a significant incident. | The entity's CSIRT or, where applicable, its competent authority. | Does not set the test for what counts as significant. Confirm the criteria in Implementing Regulation (EU) 2024/2690 and national law. |
| DORA (financial entities, Delegated Regulation (EU) 2025/301) | Initial notification within 4 hours of classifying an incident as major and no later than 24 hours after becoming aware of it. Intermediate report within 72 hours of the initial notification. Final report no later than one month after the latest intermediate report. | The competent authority for the financial entity under the Regulation's reporting chapter. | Covers major ICT-related incidents only. Confirm with the supervisor how classification thresholds apply to your entity. |
| GDPR (controllers, Article 33) | Notify without undue delay and, where feasible, within 72 hours of becoming aware of a personal data breach. Late notices must give reasons. | The competent national supervisory authority. | Not required where the breach is unlikely to result in a risk to individuals. Affected individuals are a separate notice under Article 34. |
| HIPAA (covered entities, 45 CFR 164.404) | Notify affected individuals without unreasonable delay and no later than 60 calendar days after discovery of a breach of unsecured PHI. Discovery is the first day the breach is known or would have been known with reasonable diligence. | Affected individuals, by first-class mail or by email if the individual agreed. This clock is for individuals, not a regulator clock of the same kind. | Does not start a regulator clock on its own. Confirm HHS reporting steps and state law obligations with counsel. |
| Cyber Resilience Act (manufacturers, Article 14) | Early warning within 24 hours of becoming aware of an actively exploited vulnerability, vulnerability notification within 72 hours, final report within 14 days after a corrective or mitigating measure is available. | The CSIRT designated as coordinator and ENISA through the Single Reporting Platform, submitted simultaneously. | Covers actively exploited vulnerabilities in the manufacturer's product, not general security incidents in your own environment. |
| NERC CIP-008-6 (Part 4.2) | Initial notification within one hour after determining a Reportable Cyber Security Incident, or by the end of the next calendar day after determining an attempt to compromise an applicable system. | Recipients are set by the entity's own incident response plan and the applicable NERC reporting requirements. Confirm them with your regional reliability coordinator. | Applies only to in-scope bulk electric system assets. Does not apply to unrelated enterprise systems outside that scope. |
| DFARS 252.204-7012(c) (DoD contractors) | Report within 72 hours of discovery of a cyber incident affecting covered defense information. | DoD, through the DIBNet portal at dibnet.dod.mil, using a DoD-approved medium assurance certificate. | Does not cover incidents that do not affect covered defense information. Paragraph (e) separately requires preserving images for at least 90 days after the report. |
| SEC Form 8-K Item 1.05 (registrants) | Disclosure generally within four business days after the registrant determines the incident is material. Covers nature, scope, timing and material impact. | Public disclosure to investors through SEC filing, not a confidential regulator notice. | The clock starts on a materiality determination, not on discovery. Confirm the determination process with securities counsel. |
What changes which clock applies to your team
Reporting duties attach to who you are, what you make, what data you hold and what you have disclosed, not only to the type of incident. Each factor below can start a clock that did not run before, so check them in order before you build a single playbook.
Essential or important classification
Under NIS2, an in-scope entity is classified as essential or important (Article 3). Both face the same reporting obligations under Article 23, so the classification changes supervision rather than the clock: essential entities face ex ante supervision and important entities face ex post supervision. Confirm your classification with your national competent authority, because the same organization can fall into different categories depending on sector and size rules in national law. Once classified, the early warning clock of 24 hours and the 72-hour notification apply to significant incidents.
Financial entity status under DORA
DORA applies to 20 types of financial entity listed in Article 2(1), from credit institutions and payment institutions to insurers, along with ICT third-party service providers in point (u). If your organization is on that list, incident classification and reporting under Chapter III apply to your major ICT-related incidents, and the regulator's timing rules govern the initial and follow-up reports. If you are an ICT provider to a financial entity, your obligations come through the contract and the client's reporting needs, so confirm which side of that line you sit on before you write a clock into your playbook.
Manufacturer of products with digital elements
Under the Cyber Resilience Act, Article 14 of Regulation (EU) 2024/2847 requires manufacturers to report actively exploited vulnerabilities in their products to the designated CSIRT and to ENISA. This clock starts when a manufacturer becomes aware of the exploited vulnerability, not when a customer reports an outage, so vulnerability handling and incident response need one intake path. Confirm which of your products fall within scope and who in engineering owns the awareness determination, since that moment starts the clock.
Covered PHI or controlled unclassified information
The data you hold changes which obligations apply. HIPAA's breach notice to individuals runs from the date a breach is discovered, which includes the day any workforce member or agent knew or would have known with reasonable diligence. For defense contractors, DFARS 252.204-7012 covers cyber incidents affecting covered defense information and requires reporting to DoD within 72 hours of discovery. A single intrusion can start several clocks at once, so tag data types in your asset inventory and record the discovery time for each system.
Registrant with a materiality determination
For US public companies, Form 8-K Item 1.05 requires disclosure of a cybersecurity incident generally within four business days after the registrant determines it is material. The clock starts at the materiality determination, so the process that makes that decision and records its date is part of your playbook. Ask counsel and the audit committee to agree in advance how material determinations are documented, because the timing evidence will be reviewed after the fact.
NERC registered entity
Entities registered under NERC CIP-008-6 face a one-hour initial notification after they determine a Reportable Cyber Security Incident. Attempts to compromise an applicable system carry a later deadline of the end of the next calendar day. Because the one-hour clock starts at determination, the on-call decision path must be fast and documented, and it should run in parallel with any NIS2 or DORA early warning if your organization is also in those regimes.
How to build one playbook that meets several clocks
A single incident often starts several clocks at different moments, so the playbook should record one common timeline before anyone drafts a notice. Record three timestamps for every incident: the time of first awareness by any workforce member, the time the incident was classified (for example, as major under the EU incident reporting rules in Delegated Regulation (EU) 2025/301), and the time a materiality determination was made for SEC purposes. The GDPR's 72 hours run from awareness of a breach, NIS2's 24-hour early warning runs from its own trigger, and the DFARS 72 hours run from discovery. Those starting points rarely match, so a timeline that stores only the report time will not show which clock governed each notice. Confirm with counsel how each authority defines its trigger before the first incident, not during it.
Build the content once and reuse it. The NIS2 early warning is short, and most of its fields (what happened, whether unlawful or malicious action is suspected, whether cross-border impact is possible) overlap with the initial information a controller gives a supervisory authority under GDPR Article 33. Keep a master incident record with those facts, then maintain a separate regulator-specific template for each recipient, because each one asks for different fields, uses different channels and sets different follow-up dates. Mark which template is the authoritative version for each filing so that the first notice and the later intermediate report do not contradict each other.
The DFARS path needs two items that most playbooks forget. Reporting to DoD at dibnet.dod.mil requires a DoD-approved medium assurance certificate, so confirm now that the right people hold valid certificates and that someone other than the single holder can file. Paragraph (e) of DFARS 252.204-7012 also requires preserving images of affected systems for at least 90 days after the report, so the playbook should trigger a forensic image and a retention hold at the moment of reporting, not weeks later. Ask your counsel and forensic provider to confirm how those images will be stored and who can access them.
How to confirm your clocks in your own environment
This sequence turns the published reporting clocks into a playbook your team has tested against its own detection, classification and sign-off flow. It ends with a documented, owner-approved map of which clock starts when, for each regulator and contract.
Inventory every regulator and contract that applies
Legal, compliance and the business owner list each authority and contract that could require notice: national CSIRTs or competent authorities under NIS2, financial supervisors under DORA, data protection authorities under the GDPR, HHS for HIPAA, the SEC if you file, DoD if you hold covered defense information, and any customer or payment contract with its own notice terms. Confirm whether each one applies to your legal entity, sector and geography rather than assuming it from the framework name. Done when the list has one owner per row and every entry is marked applies, does not apply or needs counsel review.
Record the trigger wording for each clock
For each row, copy the exact trigger language into your register: for example, the GDPR clock runs from becoming aware of a breach, the DORA and NIS2 clocks depend on classifying an incident as major or significant, the HIPAA 60-day limit runs from discovery as defined in 45 CFR 164.404, and the SEC clock runs from a materiality determination. Note the start event, the classification step that precedes it and any exception, such as the GDPR carve-out for breaches unlikely to result in risk. Done when each trigger has a written definition that your detection and incident staff can apply without interpretation.
Map triggers to your detection and escalation flow
Security operations and incident response trace a real alert from first signal to the people who can classify it, recording who is informed, when and through which channel. Identify where awareness could occur earlier than your ticket shows, such as a vendor notice, a customer email or an overnight monitoring page, because several triggers count knowledge that a workforce member or agent had or would reasonably have had. Done when you have a timeline for each escalation path and a list of gaps where awareness is undefined.
Run a tabletop against a sample incident
Run a tabletop with incident response, legal, privacy, the business owner and a representative of the executive who signs notices. Use an invented scenario, labeled as illustrative, that touches several regimes at once, such as a ransomware event that also exposes personal data and protected health information. Measure how long classification, the awareness decision and draft notices take in the room, then compare that with the clocks from the register. Done when the exercise produces a written list of decisions, owners and open questions, and each clock has a recorded result.
Time classification and awareness in your own flow
Using real tickets from the last few incidents, the incident lead measures how long each step took in your environment, from detection through triage, classification and escalation to approval. Do not use durations from this page or from other organizations, because your tooling, staffing and approval chain set the numbers. Where a clock depends on classification, such as the DORA major incident test or the NIS2 significant incident test, record who decides and what evidence they need. Done when you can show measured intervals for each step and a list of steps that exceed the time you would need to meet the earliest clock.
Confirm channels, forms and credentials
Operations and legal confirm each notification route with the receiving body before an incident occurs: the national CSIRT or competent authority portal, the DORA reporting channel for your supervisor, the data protection authority's breach form, the HHS breach portal, DoD's reporting site, and the SEC filing process. Check whether any route needs a specific certificate, account or registration and who holds it, because a missing credential can delay a filing. Done when every channel has a named owner, a tested login or contact path and a backup route, and the credentials are stored where the on-call team can reach them.
Check transposition and local rules with counsel
Counsel reviews how each national law implements the NIS2 Directive in every Member State where you operate, because the Directive binds entities through transposition and Member States may keep or adopt stricter rules. Confirm the reporting authority, forms and any additional triggers, and check for pending amendments, such as the Commission's January 2026 proposal, which is still a proposal. Repeat the check for GDPR procedural rules and for any sector regulator outside the EU. Done when counsel signs off a memo listing each jurisdiction, its authority, its rules and the review date, and the playbook is updated to match.
Approve one playbook and schedule retesting
The CISO, legal and the accountable executive merge the register, timings, channels and counsel memo into one incident reporting playbook with a single owner and version history. Set a review trigger for changes in law, new regulated services and each tabletop, and ask DeployOpen or another implementation partner to confirm that the playbook matches your deployed tooling if you want an outside check on the implementation. Done when the playbook is approved, distributed to on-call staff and tested at the agreed interval, and the evidence of each test is stored with the document.
Incident reporting deadline questions buyers ask
Which reporting clock starts first when one incident triggers several notifications?
The clock that starts first is usually the one tied to awareness or classification, not to the final report, so map each regime's trigger before you decide what counts as discovery. Under NIS2, the 24-hour early warning runs from becoming aware of a significant incident, while the DORA major-incident initial notification under Delegated Regulation (EU) 2025/301 is due within 4 hours of classifying the incident as major and no later than 24 hours after awareness. GDPR's 72 hours runs from becoming aware of a personal data breach. HIPAA's 60-day limit runs from discovery, which is the first day the breach is known or would have been known with reasonable diligence to any workforce member or agent. Because these triggers differ, the earliest one often governs your timeline, so record the time of first awareness in your incident log from the start. Confirm each trigger with counsel, since member-state rules may add detail.
Can one incident report serve several authorities at once?
Partly. A single fact base can feed several reports, but each authority has its own form, recipient, content and deadline, so expect to write several documents from one timeline. Under NIS2, reports go to the CSIRT or competent authority in stages: early warning, incident notification and a final report. Under DORA, the initial, intermediate and final reports follow the regulatory technical standards and go to the authority that supervises the financial entity. GDPR notices go to the supervisory authority, and HIPAA notices go to affected individuals and HHS under its own rules. Build one incident record with a fixed set of facts (time of awareness, systems, data categories, impact, containment status) and generate each regulator's view from it. Ask counsel whether a report to one authority satisfies another, because the answer depends on the specific wording and member-state transposition.
What does a multi-regime incident playbook cost, and who pays for each part?
The cost has three parts: legal and regulatory mapping, technical runbooks and exercises, and ongoing maintenance. Counsel is paid to confirm triggers, member-state rules and sector-specific obligations, such as NIS2 transposition in each country where you operate. Your engineers and security staff are paid to write detection, triage and containment steps, and their time is usually the largest internal cost. An implementation partner, such as DeployOpen, is paid under a written, fixed scope to plan, draft and document the playbook, and to test it. Maintenance recurs whenever contacts, systems, sectors or rules change. Ask for a quote that lists each deliverable, which regimes are covered, how many exercises are included and who signs off on legal content. DeployOpen does not publish a price list, so the quote follows from the written scope.
How long does building and testing a reporting playbook take?
The duration depends mainly on how many regimes are in scope, how many systems and business units feed incidents, and how many exercises you want before go-live. A playbook covering one authority and a few systems is a much smaller job than one covering NIS2, DORA, GDPR and HIPAA across several subsidiaries. Legal review often sets the pace, because counsel must confirm triggers and member-state details before technical steps can be finalized. Testing usually runs as tabletop exercises first, then a simulated incident that exercises the clocks in real tooling. No researched timeline applies here, so ask any partner for a phased schedule tied to written deliverables, and confirm which parts depend on your legal team's availability.
What must our team supply before a playbook project can start?
Your team must supply accurate inputs, because the playbook is only as good as the asset inventory and contact data behind it. The main items are:
- An asset inventory that identifies systems, data categories, hosting locations and owners, including which systems support essential or important services under NIS2 or ICT services under DORA.
- A current contact list for each authority, the CSIRT, your incident response retainer, legal counsel, communications and executive approvers.
- Certificates and access for submission channels, such as the DoD reporting portal certificate for DFARS 252.204-7012 or the EU reporting platforms, where they apply.
- Your existing incident response plan, logging coverage and any prior notifications.
- Named legal review, with counsel who will approve trigger definitions and notice wording.
Spell out ownership for each item in the scope, so gaps are visible before work starts.
Can our own team build and run this playbook without an outside partner?
Yes, if you have security engineers, incident response staff and counsel with time and experience in each regime. The work is not unusual, but it is cross-functional: the playbook needs legal sign-off, technical runbooks, tested contacts and repeated exercises, and each regime changes over time. The main risk for an internal team is capacity and continuity, since the people who write the playbook are often the same people needed during an incident. A partner can take a defined part, such as drafting runbooks, running exercises or documenting evidence, under a fixed scope. Decide which parts you keep, and ask counsel to confirm the legal content whichever route you choose. For sector-specific obligations, confirm the details directly with the relevant authority or with your own counsel.
Which official texts to read before you set deadlines
The legal text controls every deadline on this page, and this page is only a summary. Before you write a playbook clock into a runbook, read the operative article in the source itself. For NIS2 that is Article 23 of Directive (EU) 2022/2555 on EUR-Lex, which sets the 24-hour early warning, 72-hour notification and one-month final report. Check how your Member State transposed those rules, because national law can add requirements. For DORA, read Article 19 of Regulation (EU) 2022/2554, and then Delegated Regulation (EU) 2025/301, whose Article 5 sets the four-hour and 24-hour initial clocks that apply once an incident is classified as major.
The other sources answer different questions. Article 33 of the GDPR, read through the EUR-Lex text of Regulation (EU) 2016/679, defines the 72-hour supervisory authority clock and the exemption for breaches unlikely to create risk to individuals. For HIPAA, the individual notice clock of 60 calendar days runs from discovery under 45 CFR 164.404, and the discovery rule depends on what workforce members and agents knew or should have known, so read the regulation in the eCFR text for 45 CFR Part 164 Subpart D. For NERC CIP-008-6, the one-hour clock is written into the standard itself. Confirm with your regional entity how it applies to your reportable cyber security incidents.
For SEC registrants, the four-business-day clock begins only after a materiality determination, so the determination process is the control to document. Read the SEC press release 2023-139 together with the rule text it summarizes. Once you have pulled each source, record the version and date you relied on in your playbook, and ask counsel to confirm which triggers apply to your entity. Regulators update texts and guidance, and a deadline that was correct when the playbook was written may not be correct at the next incident.
How DeployOpen helps teams build one reporting playbook
DeployOpen works with teams that must notify several authorities on different clocks, turning those obligations into one written playbook that fits the organization's own infrastructure. The work is scoped in writing first, then built, documented and handed over inside the client's environment, with ongoing support available as a retainer.
How we scope
- Map every regime in play, such as NIS2, DORA, GDPR and HIPAA, to the entities and sectors your organization actually falls under.
- List each notification recipient, clock and trigger, including which ones start at awareness and which start at classification.
- Agree scope, deliverables and timelines in writing before any work starts, since most engagements are fixed-scope.
How we build
- Draft one incident classification flow with decision points that show when each authority clock starts and stops.
- Create notification templates for early warning, initial, intermediate and final reports, aligned to each authority's required content.
- Test the playbook through tabletop-style walkthroughs so staff can see which deadline applies at each step.
How we hand over
- Deliver the playbook, templates and contact matrix in documents your own teams can edit and keep under version control.
- Walk responsible staff through the decision points, including legal, communications and management sign-off steps.
- Document open questions for your legal counsel or regulator contacts to confirm, since DeployOpen does not give legal advice on reporting duties.
How we support
- Offer ongoing support as a retainer to update the playbook when national transposition rules, delegated acts or proposed amendments change a clock.
- Review the playbook after regulatory changes or significant incidents so triggers and templates stay accurate.
- Keep the playbook connected to your monitoring and ticketing setup so detection and notification timestamps can be evidenced later.
