Operational guidance, not legal advice. This page distills named public sources (regulator guidance and industry practice). It is not a legal determination, not a notification decision, and not a substitute for your counsel, insurer, or a retained DFIR firm. Verify applicability and current deadlines for your facts and jurisdiction.
First 72 hours after a breach
Updated
In the first 72 hours after a breach: keep the timeline and evidence hold, finish containment, decide with counsel whether a 72-hour notification clock applies (GDPR Article 33, CRA Article 14), and document the facts. This page does not start a clock and is not legal advice.
Operational guidance, last verified 7 September 2026 against Regulation (EU) 2016/679 Article 33, Regulation (EU) 2024/2847 Article 14, EDPB Guidelines 9/2022, ENISA's Single Reporting Platform materials, NIST SP 800-61r2, CISA incident-response guidance, the SANS Incident Handler's Handbook, and the FTC Data Breach Response guide. It is not a notification determination and not a substitute for counsel, your insurer, or a retained DFIR firm.
What the first 72 hours are for
Audience: the incident commander and the leadership, counsel, and insurer already looped in. The first 24 hours kept the UTC timeline, placed an evidence hold, finished short-term containment, and mapped which clocks might have started. The first 72 hours are when some of those clocks — if they apply — come due: GDPR Article 33 to a supervisory authority, and the CRA Article 14 notification stage after the 24-hour early warning. Eradication that destroys evidence, a public campaign, and a final regulator report still belong later unless counsel says otherwise.
NIST SP 800-61r2 is still in containment here. The SANS PICERL model does not jump to recovery because a deadline is approaching. If day one is unfinished — no timeline, no hold, no clock map — do that first. This page assumes those moves have started. A dedicated breach-counsel guide and a dedicated incident-timeline guide are not on this site yet.
- Keep the UTC timeline. Every new fact, action, and decision is a new line, not an edit.
- Keep the evidence hold. Do not rotate, reimage, or tidy because a notification form wants a clean story.
- Finish containment. Long-term containment and eradication wait for a forensic image and a plan.
- Walk the 72-hour decision tree with counsel. Mapping is not filing. This page does not apply any law to you.
- Document the facts you have, including unknowns. GDPR Article 33(5) requires documentation of personal data breaches even when you do not notify. That is a legal requirement only if GDPR applies.
- Interim customer or partner comms only if counsel says a duty has started, or if your plan already named a need-to-know audience. Default is still need-to-know. CISA: do not tip the actor.
Does a 72-hour clock apply to us?
This is a decision tree of questions for counsel, not a determination. Two 72-hour bands that may apply are GDPR Article 33 (personal data, supervisory authority) and CRA Article 14 (product security, CSIRT and ENISA). They are different laws, different recipients, and different triggers. Filing one never discharges the other. Last verified 7 September 2026. Not legal advice.
| Question | If the facts point yes | If the facts point no |
|---|---|---|
| Are you a GDPR controller, and has a personal data breach occurred that is not 'unlikely to result in a risk to the rights and freedoms of natural persons'? | Article 33(1) is a legal requirement when it applies: notify the competent supervisory authority without undue delay and, where feasible, not later than 72 hours after becoming aware. If the notification is late, Article 33(1) requires reasons for the delay. Article 33(4) allows information in phases. | Article 33 is a controller duty. A processor notifies the controller without undue delay (Article 33(2)) — that is not a 72-hour DPA filing. If no personal data is in play, this is not your GDPR clock. 'Unlikely to result in a risk' is a legal and factual test. Counsel decides. Document the decision either way (Article 33(5)). |
| Are you a manufacturer (or in-scope open-source steward) of a product with digital elements on the Union market, and is this an actively exploited vulnerability in that product, or a severe incident having an impact on its security? | CRA Article 14's notification stage is a legal requirement when it applies: without undue delay and in any event within 72 hours of becoming aware, to the CSIRT designated as coordinator and to ENISA via the Single Reporting Platform — after the 24-hour early warning. Article 14 reporting applies from 11 September 2026. | Do not import a 72-hour CRA duty because the incident is serious. CRA is product-security reporting, not a personal-data statute. Scope, 'product with digital elements', 'becoming aware', 'actively exploited', and 'severe' are legal and factual tests. This page does not apply them. |
| Do other sector or jurisdiction rules apply (health, finance, critical infrastructure, US state statutes)? | Some regimes have their own early-warning or notification ladders. Many personal-data and US state breach-notification statutes are measured in days or 'without unreasonable delay', not 72 hours. The FTC guide notes every US state plus DC, Puerto Rico, and the Virgin Islands has a security-breach notification law; HIPAA and the FTC Health Breach Notification Rule may also apply. | Counsel maps YOUR facts to YOUR laws. Do not skip a shorter or different duty because this page led with 72 hours. Do not invent a 72-hour duty from a statute that does not have one. |
72-hour obligations that may apply — side by side
Legal requirement versus guidance versus practice stay distinct. GDPR Article 33 and CRA Article 14 are legal requirements only when they apply. EDPB Guidelines 9/2022 and ENISA's Single Reporting Platform materials are regulator guidance about how those duties are understood or filed; they do not decide that you are in scope. NIST SP 800-61r2, SANS, and CISA are operational practice. The FTC guide is US regulator guidance for businesses; the legal notification duties are in the statutes it points at.
Administrative fines for GDPR Articles 33 and 34 sit in Article 83(4), which lists Articles 25 to 39. Confirm the current ceilings in Article 83 with counsel. CRA penalties are laid down by Member States under the regulation. This page does not apply a fine. Last verified 7 September 2026. Not legal advice.
| Instrument | Clock and recipient | Verify before you treat it as yours |
|---|---|---|
| Regulation (EU) 2016/679 (GDPR) Article 33 — legal requirement only if it applies | Controller notifies the supervisory authority competent under Article 55, without undue delay and, where feasible, not later than 72 hours after becoming aware, unless the personal data breach is unlikely to result in a risk to the rights and freedoms of natural persons. Content: Article 33(3). Phased: Article 33(4). Document every personal data breach: Article 33(5). | Controller versus processor, 'personal data breach', 'becoming aware', and the 'unlikely to result in a risk' exception are legal and factual tests. EDPB Guidelines 9/2022 (regulator guidance, 4 April 2023, version 2.0) treat awareness as a reasonable degree of certainty that a security incident has compromised personal data — not the close of the investigation. Confirm against the regulation, the EDPB text, and counsel. This page does not start the clock. |
| Regulation (EU) 2024/2847 (Cyber Resilience Act) Article 14 notification stage — legal requirement only if it applies | After the 24-hour early warning: a notification without undue delay and in any event within 72 hours of becoming aware, simultaneously to the CSIRT designated as coordinator and to ENISA, via the Single Reporting Platform. Separate from GDPR. Applies from 11 September 2026. A later final report is a different stage (vulnerability track: 14 days after a corrective or mitigating measure is available). | Only if CRA applies to you and the product. Scope, 'becoming aware', 'actively exploited', and 'severe' are legal and factual tests. ENISA's SRP materials describe the filing path; they do not decide that you are in scope. Filing CRA never discharges GDPR, and the reverse. Confirm against the regulation and counsel. |
| Other sector or US state rules | Some have clocks measured in hours. Many do not. The FTC Data Breach Response guide (regulator guidance, not a statute) tells businesses to notify law enforcement and affected parties when the facts require it, and notes the US state-and-territory notification map. | Counsel maps YOUR facts. A 72-hour GDPR or CRA duty is not a template for a US state statute, and a US state deadline is not a GDPR filing. |
Document the facts — including what you do not know
A 72-hour file that looks complete because the unknowns were deleted is a worse artifact than an honest partial. GDPR Article 33(4) allows information in phases when it cannot all be provided at once. Article 33(5) requires the controller to document any personal data breach — facts, effects, remedial action — so the supervisory authority can verify compliance; that documentation duty is not the same as the 72-hour notification, and it applies to breaches you do not notify because of the risk exception. Those sentences are legal requirements only if GDPR applies. NIST SP 800-61r2's evidence-handling guidance is acquire, preserve, secure, and document. SANS treats contemporaneous notes as part of identification.
- UTC timeline: detections, actions, decisions, who authorised them, when counsel and the insurer were briefed, current contain-versus-observe state.
- What data and which systems are in play, and which are only suspected. 'Not yet scoped: backup accounts' is a fact.
- Whether personal data may be involved, and why you do or do not yet know. That sentence is for counsel, not a public post.
- Whether a product with digital elements you manufacture may be in play. Same limit: counsel, not a status page.
- Article 33(3) contents if GDPR may apply: nature of the breach, categories and approximate numbers where possible, contact point, likely consequences, measures taken or proposed. Missing items are listed as missing, then filled in phases (Article 33(4)).
- Corrections are new lines. Do not silently rewrite an earlier entry so the 72-hour form looks tidy.
Interim customer and partner comms
Need-to-know remains the default at 72 hours. CISA warns that actors monitor response activity and will move if they know they have been found. A public status page, an all-hands email, or an in-band 'we see you' message is how you tell them. Customer notice as a campaign still belongs later unless counsel says a clock has started — GDPR Article 34 (communication to the data subject when the breach is likely to result in a high risk) is a different duty from Article 33, and it is not a 72-hour clock. US individual-notice timing is in the state and sector statutes. Confirm with counsel. A first-week page on this site covers recovery and individual-notice caveats.
- If counsel says a 72-hour regulator filing is due, that filing is not a customer email and not a press release.
- If a partner or processor contract requires notice inside 72 hours, that is a contract question for counsel — not this page.
- Do not reset every password from a possibly compromised identity plane as your 'customer update'. CISA: do not tip the actor.
- One spokesperson. Split customer stories are how two regulators get two facts.
Where this shows up in ShipReady Metrics
The signed-in app does not run this 72-hour plan, decide that GDPR or CRA applies, or file a notice. If you already have a session: signed-in app → Compliance → CRA reporting tracks the 24-hour / 72-hour / 14-day ladder from your recorded awareness for findings the org has classified as CRA-in-scope. It does not start a clock for you, it does not assess GDPR Article 33, and it is not a determination that CRA applies. A named human still submits. The cyber risk register lives under Security; the obligation map (frameworks you have marked in-scope) is under Compliance. None of those surfaces preserve evidence or notify a supervisory authority, a CSIRT, or ENISA.
Primary sources (last verified 7 September 2026)
Every operational and regulatory claim on this page is taken from one of these. If a later revision of a source changes the advice, the date above is how you can see we have not re-checked yet.
Regulation (EU) 2016/679 Articles 33 and 83 are legal requirements only when GDPR applies. EDPB Guidelines 9/2022 are regulator guidance on how Article 33 is understood; they are not the regulation. Regulation (EU) 2024/2847 Article 14 is a legal requirement only when CRA applies; ENISA's Single Reporting Platform materials describe the filing path. NIST SP 800-61 Revision 2 remains the current final Computer Security Incident Handling Guide (August 2012) — guidance, not a statute. CISA's playbooks are operational procedures written for US federal civilian executive branch information systems. The SANS handbook is a practitioner checklist. The FTC guide is business guidance from a US regulator; the legal notification duties are in the statutes it points at, not in the guide itself.
Frequently asked questions
What should we do in the first 72 hours after a breach?
Keep the UTC timeline and the evidence hold, finish containment, walk the 72-hour decision tree with counsel (GDPR Article 33 and CRA Article 14 are the two bands this page names), and document facts including unknowns. Do not treat the map as a filing. Do not reimage to look prepared. NIST SP 800-61r2, CISA, SANS, and the FTC guide are the operational sources; the regulations are the legal ones. Not legal advice.
Does the GDPR 72-hour rule apply to us?
This page cannot tell you. GDPR Article 33 applies to controllers, for a personal data breach, unless the breach is unlikely to result in a risk to the rights and freedoms of natural persons. The 72 hours run from becoming aware, not from when the incident began and not from when the investigation closes. EDPB Guidelines 9/2022 (regulator guidance) discuss awareness as a reasonable degree of certainty that personal data was compromised. Processors notify the controller (Article 33(2)), not the DPA under that paragraph. Counsel decides on your facts. Last verified 7 September 2026. Not legal advice.
Is the CRA 72-hour notification the same as GDPR Article 33?
No. CRA Article 14 is product-security reporting to a CSIRT and ENISA for actively exploited vulnerabilities and severe incidents affecting a product with digital elements, from 11 September 2026. GDPR Article 33 is personal-data reporting to a supervisory authority. Different trigger, different recipient, different statute. Filing one never discharges the other. Whether either applies is counsel's call. Not legal advice.
What if we cannot gather every fact inside 72 hours?
GDPR Article 33(4) allows the information to be provided in phases without undue further delay when it cannot all be given at once. Article 33(1) requires reasons if the supervisory-authority notification itself is late. Those are legal requirements only if GDPR applies. Operationally, record unknowns as unknowns on the UTC timeline; do not invent completeness. Confirm with counsel. Not legal advice.
Is this legal advice?
No. It is a 72-hour plan distilled from GDPR Article 33, CRA Article 14, EDPB Guidelines 9/2022, ENISA SRP materials, NIST SP 800-61r2, CISA, the SANS Incident Handler's Handbook, and the FTC Data Breach Response guide. Whether a clock has started, whether GDPR or CRA applies, and what you must file are legal questions for counsel on your facts. This page does not start a reporting clock.
Published by ShipReady Metrics, an evidence-based technology and compliance intelligence platform. This guide is educational and vendor-neutral.