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.
Do I have to report a cybersecurity breach?
Updated
Maybe. Reporting is mandatory only when a named regime applies to your facts — personal-data notification, sector or incident reporting, or product-vulnerability reporting. This page maps those classes. It is not legal advice and does not start a clock.
Regime map, last verified 7 September 2026 against Regulation (EU) 2016/679 Articles 33–34, Directive (EU) 2022/2555 (NIS2) Article 23, Regulation (EU) 2022/2554 (DORA) Articles 18–19, Regulation (EU) 2024/2847 (CRA) Article 14, Cal. Civ. Code §1798.82, EDPB Guidelines 9/2022, and ENISA's Single Reporting Platform materials. It is not legal advice, not a filing, and not a substitute for counsel.
This is a regime map, not a determination
Audience: a founder, CISO, or incident commander who has just confirmed something went wrong and is asking whether a report is legally required. This page does not answer that for you. Counsel applies YOUR facts to YOUR laws. Mapping a class of regime is not a determination that any duty applies, and reading this page does not start a reporting clock.
Three classes of regime show up again and again. They are not the same duty, they do not share a recipient, and filing one never discharges the others. The instruments named below are examples of each class, not a complete world list. Last verified 7 September 2026. Not legal advice.
- Personal-data notification: a personal data breach may have to be notified to a supervisory authority and, in a narrower set of cases, to the people affected. GDPR Articles 33–34 are the EU example; Cal. Civ. Code §1798.82 is a US-state example.
- Sector or incident reporting: an entity in a named sector may have to report a significant or major incident to a CSIRT, competent authority, or financial supervisor even when no personal data is in play. NIS2 Article 23 and DORA Article 19 are the EU examples.
- Product-vulnerability reporting: a manufacturer of a product with digital elements on the Union market may have to report an actively exploited vulnerability or a severe incident affecting that product. CRA Article 14 is the EU example. It applies from 11 September 2026.
- This page does not start a clock. Awareness, determination, and discovery are legal and factual tests. Counsel decides when, if ever, a clock has started on YOUR facts.
Which kind of regime might apply
Work this table with counsel. It is a class map. The reporting-decision-tree page on this site is the branching tree (data type, jurisdiction, sector, threshold). The reporting-deadlines page on this site is the statute table of those clocks. Each 'if yes' leaf names an example instrument of that class. A dedicated jurisdiction guide for each leaf is not on this site yet. Last verified 7 September 2026. Not legal advice.
| Question | If the facts point yes | If the facts point no |
|---|---|---|
| Was personal data involved — a confidentiality, integrity, or availability compromise of personal data — for people in a jurisdiction with a notification statute? | You may be in a personal-data notification class. GDPR Articles 33–34 are the EU controller/processor example (supervisory authority; in a high-risk subset, the data subject). Cal. Civ. Code §1798.82 is a representative US-state example (California residents; notice after discovery or notification of the breach). A dedicated GDPR jurisdiction guide is not on this site yet. A dedicated US-state-laws guide is not on this site yet. A dedicated UK GDPR, HIPAA, Canada PIPEDA, Australia NDB, India DPDP / CERT-In, and UAE/Dubai guide is not on this site yet. | Personal-data notification is not the only class. An incident with no personal data can still sit in a sector or product-vulnerability class. Do not treat 'no personal data' as 'no reporting duty'. Counsel maps YOUR facts. |
| Are you an essential or important entity under a cybersecurity incident-reporting law, or a financial entity under a digital-operational-resilience law? | You may be in a sector or incident-reporting class. NIS2 Article 23 is the EU example for essential and important entities: notify the CSIRT or competent authority of a significant incident. DORA Article 19 is the EU financial-entity example: report major ICT-related incidents to the relevant competent authority. DORA is lex specialis as against NIS2 for in-scope financial entities (NIS2 recital 28). A dedicated NIS2 jurisdiction guide is not on this site yet. A dedicated DORA jurisdiction guide is not on this site yet. A dedicated SEC cyber-disclosure guide is not on this site yet. | Sector class is entity-and-service specific. Do not import a NIS2 or DORA duty because the incident is serious. Scope, 'significant', and 'major' are legal and factual tests. This page does not apply them. |
| Do you manufacture (or, in CRA terms, act as an in-scope open-source software steward of) a product with digital elements made available on the Union market, and is this an actively exploited vulnerability in that product, or a severe incident having an impact on its security? | You may be in a product-vulnerability class. CRA Article 14 is the EU example: notify the CSIRT designated as coordinator and ENISA, via the Single Reporting Platform, of actively exploited vulnerabilities and of severe incidents having an impact on the security of the product. Article 14 applies from 11 September 2026. A dedicated CRA jurisdiction guide is not on this site yet. | Do not import a CRA duty because you had an incident. CRA is product-security reporting, not a personal-data statute and not NIS2. Scope, 'product with digital elements', 'becoming aware', 'actively exploited', and 'severe' are legal and factual tests. This page does not apply them. |
Thresholds — statute language, not invented numbers
Thresholds are not interchangeable. 'Risk to rights and freedoms' is a GDPR phrase. 'Significant incident' is a NIS2 phrase. 'Major ICT-related incident' is a DORA phrase. CRA splits actively exploited vulnerabilities from severe incidents. This table labels each row as legal requirement (only if it applies), regulator guidance, or industry practice. No numeric threshold on this page is invented. The reporting-deadlines page on this site is the statute table of those clocks.
| Instrument | Threshold language as cited | Kind |
|---|---|---|
| GDPR Articles 33–34 — legal requirement only if GDPR applies | Article 33(1): the controller notifies the supervisory authority of a personal data breach unless the breach is 'unlikely to result in a risk to the rights and freedoms of natural persons'. Article 34(1): communication to the data subject when the breach is 'likely to result in a high risk' to those rights and freedoms. Those are qualitative tests in the regulation. This page does not score your risk. | Legal requirement (only if it applies). EDPB Guidelines 9/2022 are regulator guidance on how Article 33 is understood; they are not the regulation. |
| NIS2 Article 23 — legal requirement only if NIS2 as transposed applies | Article 23(1) requires notification of a 'significant incident'. Article 23(3): an incident is significant if it has caused or is capable of causing severe operational disruption of the services or financial loss for the entity, or has affected or is capable of affecting other natural or legal persons by causing considerable material or non-material damage. No numeric loss figure is in that article. | Legal requirement (only if it applies). ENISA's NIS2 technical implementation guidance is agency guidance on implementing acts for some digital-infrastructure entities; it does not decide that you are in scope. |
| DORA Articles 18–19 — legal requirement only if DORA applies | Article 19(1): financial entities report 'major ICT-related incidents' to the relevant competent authority. Classification of major incidents is a separate exercise under Article 18; the time limits for the initial, intermediate, and final reports are laid down under Article 20, not invented here. Voluntary notification of significant cyber threats is Article 19(2). | Legal requirement (only if it applies). Do not paste NIS2's 24-hour / 72-hour ladder onto DORA. The hours live in the Article 20 technical standards, which this page does not restate as yours. |
| CRA Article 14 — legal requirement only if CRA applies | Two tracks. Actively exploited vulnerability (Article 14(1)–(2)): 24-hour early warning, 72-hour notification, final report no later than 14 days after a corrective or mitigating measure is available. Severe incident having an impact on the security of the product (Article 14(3)–(5)): 24-hour early warning, 72-hour notification, final report within one month of the incident notification. Article 14(5) defines 'severe' qualitatively (negative effect on availability, authenticity, integrity or confidentiality of sensitive or important data or functions; or introduction or execution of malicious code). Applies from 11 September 2026. | Legal requirement (only if it applies). ENISA's Single Reporting Platform materials describe the filing path; they do not decide that CRA applies. |
| Cal. Civ. Code §1798.82 — legal requirement only if it applies | A business that owns or licenses computerized data including personal information discloses a breach of the security of the system, following discovery or notification of the breach, to a California resident whose unencrypted personal information was, or is reasonably believed to have been, acquired by an unauthorized person (or encrypted information plus the key, with a reasonable belief the key could render it readable). As amended effective 1 January 2026 (Stats. 2025, Ch. 319, SB 446), that disclosure shall be made within 30 calendar days of discovery or notification, subject to a law-enforcement or integrity-restoration delay in the statute. Other US states differ. This is one example, not a 50-state map. | Legal requirement (only if it applies). A dedicated US-state-laws guide is not on this site yet. |
Clock-start: awareness versus determination
Reading this page does not start a clock. The statutes start clocks from a named event. Counsel applies that event to YOUR facts. A dedicated how-regulators-determine-knowledge guide is not on this site yet.
| Instrument | The article's start language | What this page does not do |
|---|---|---|
| GDPR Article 33(1) | Without undue delay and, where feasible, not later than 72 hours after having become aware. EDPB Guidelines 9/2022 (regulator guidance, version 2.0, 4 April 2023) treat awareness as a reasonable degree of certainty that a security incident has compromised personal data — not the close of the investigation. | Does not decide that you have become aware. Does not start the 72 hours. Article 33(4) allows information in phases; Article 33(5) requires documentation of personal data breaches even when you do not notify. Those sentences are legal requirements only if GDPR applies. |
| NIS2 Article 23(4) | Early warning without undue delay and in any event within 24 hours of becoming aware of the significant incident; incident notification within 72 hours of becoming aware; final report not later than one month after the incident notification (or, if the incident is still ongoing, a progress report then a final report within one month of handling). | Does not decide that the incident is significant or that you have become aware. Does not start either band. |
| DORA Article 19(4) | Initial notification, intermediate report, and final report within the time limits laid down under Article 20. The financial entity produces those after collecting and analysing all relevant information (Article 19(1)). | Does not restate the Article 20 hours as yours. Does not classify the incident as major. Does not start a DORA clock. |
| CRA Article 14(2) and (4) | Each stage runs from the manufacturer becoming aware of the actively exploited vulnerability or of the severe incident. Article 14 applies from 11 September 2026. | Does not decide that CRA applies, that the product is in scope, or that you have become aware. The signed-in CRA ladder, if you use it, tracks a clock the organization already recorded — it does not start one. |
| Cal. Civ. Code §1798.82(a) | Following discovery or notification of the breach; as of 1 January 2026, within 30 calendar days of discovery or notification, subject to the statute's delay language. | Does not decide that a California-resident personal-information acquisition occurred. Does not start the 30 days. Other states use different start language. Counsel maps them. |
What to ask counsel and the commander now
This is a question list, not a filing. The first-72-hours page on this site is the operational 72-hour plan. The who-to-call page on this site is the contact order. A dedicated who-to-notify guide is not on this site yet. A dedicated document-your-decision guide is not on this site yet. A dedicated prepare-regulatory-report guide is not on this site yet. A dedicated supporting-evidence guide is not on this site yet.
- Which class of regime might apply: personal-data notification, sector or incident reporting, product-vulnerability reporting — or none of these, or more than one.
- Which jurisdictions of affected people, of establishment, and of product-on-market are in play. A dedicated which-jurisdictions-apply guide is not on this site yet.
- Controller versus processor; essential versus important entity; financial entity; manufacturer versus importer versus distributor versus open-source software steward. Those labels are legal.
- What you know, what you only suspect, and when each fact entered the UTC log. Awareness arguments are built from contemporaneous notes, not from a later tidy rewrite.
- Whether any clock counsel already identified may have started — and whether this page, or the product, is being treated as the start. It is not.
- Who is authorised to file, and who is not. A named human files. The product does not.
- Whether a no-notification decision still has to be documented (GDPR Article 33(5) is the example, only if GDPR applies).
Glossary
These are teaching labels for this page. They are not legal conclusions about YOUR facts.
| Term | How this page uses it |
|---|---|
| Regime map | A classing of reporting duties (personal-data vs sector/incident vs product-vulnerability). Not a determination that any duty applies. |
| Personal data breach | GDPR's phrase for a breach of security leading to accidental or unlawful destruction, loss, alteration, unauthorised disclosure of, or access to, personal data. Article 4(12). Whether one occurred is counsel's call. |
| Risk to rights and freedoms | GDPR Article 33's exception language ('unlikely to result in a risk') and the related Article 34 'high risk' test for individual notice. Qualitative. Not a score this page computes. |
| Significant incident | NIS2 Article 23(3)'s two-limb test (severe operational disruption or financial loss for the entity; or considerable material or non-material damage to others). Not a CVSS number. |
| Major ICT-related incident | DORA's reporting object under Article 19, classified under Article 18. Not the same phrase as NIS2's 'significant incident'. |
| Actively exploited vulnerability | CRA Article 14(1) track: a vulnerability in a product with digital elements that is being exploited. Separate from the severe-incident track in Article 14(3). |
| Becoming aware / discovery | The event several statutes name as clock-start. EDPB discusses GDPR awareness as a reasonable degree of certainty. California §1798.82 uses discovery or notification of the breach. This page does not find that event on your facts. |
Where this shows up in ShipReady Metrics
The signed-in app does not decide whether you must report, does not start a notification clock, does not file with a regulator, and does not interpret YOUR facts. None of the surfaces below is 'you must report.'
If you already have a session: signed-in app → Compliance → CRA reporting tracks the Article 14 24-hour / 72-hour / 14-day ladder from recorded awareness for findings the organization has classified as CRA-in-scope. It tracks a clock the organization already started. It is not a determination that CRA applies. A named human still submits.
The obligation map lists frameworks the organization has marked in-scope. That mark is not a legal opinion that a reporting duty applies, and it is not a list of reporting duties as legal conclusions. The cyber risk register lives under Security. None of those surfaces files a GDPR Article 33 notice, a NIS2 Article 23 notification, a DORA Article 19 report, a CRA Article 14 notification, or a California §1798.82 disclosure.
Primary sources (last verified 7 September 2026)
Every regulatory claim on this page is taken from one of these. If a later revision of a source changes the rule, the date above is how you can see we have not re-checked yet.
Regulation (EU) 2016/679 Articles 33 and 34 are legal requirements only when GDPR applies. EDPB Guidelines 9/2022 are regulator guidance. Directive (EU) 2022/2555 Article 23 is a legal requirement only as transposed and only if you are an in-scope essential or important entity. Regulation (EU) 2022/2554 Articles 18–20 are legal requirements only if DORA applies. Regulation (EU) 2024/2847 Article 14 is a legal requirement only if CRA applies; ENISA's Single Reporting Platform materials describe the filing path. Cal. Civ. Code §1798.82 is a California statute, last checked in the official Legislative Counsel text, including the 1 January 2026 amendment. These are examples of classes, not a complete world list. Not legal advice.
The reporting-decision-tree page on this site is the branching tree. The reporting-deadlines page on this site is the statute table. A dedicated who-to-notify, regulator-versus-customer-versus-individual, which-jurisdictions-apply, prepare-regulatory-report, supporting-evidence, document-your-decision, failure-to-report-consequences, how-regulators-determine-knowledge, GDPR, NIS2, DORA, CRA, UK GDPR, US-state-laws, SEC cyber-disclosure, HIPAA, Canada PIPEDA, Australia NDB, India DPDP / CERT-In, and UAE/Dubai guide is not on this site yet. Naming them is not a link.
Frequently asked questions
Do I have to report a cybersecurity breach?
This page cannot tell you. Reporting is mandatory only when a named regime applies to your facts. Personal-data notification (GDPR Articles 33–34, Cal. Civ. Code §1798.82 as examples), sector or incident reporting (NIS2 Article 23, DORA Article 19 as examples), and product-vulnerability reporting (CRA Article 14 as an example) are different classes. Counsel applies YOUR facts. Last verified 7 September 2026. Not legal advice.
Is this legal advice?
No. It is a regime map distilled from GDPR Articles 33–34, NIS2 Article 23, DORA Articles 18–19, CRA Article 14, Cal. Civ. Code §1798.82, EDPB Guidelines 9/2022, and ENISA's Single Reporting Platform materials. Whether any duty applies, and whether a clock has started, are legal questions for counsel on your facts. This page does not start a reporting clock.
Does this page start a reporting clock?
No. GDPR Article 33 runs from becoming aware; NIS2 Article 23(4) runs from becoming aware of a significant incident; CRA Article 14 runs from the manufacturer becoming aware; California §1798.82 runs from discovery or notification of the breach. Reading a public page is none of those events. The signed-in CRA ladder tracks recorded awareness; it does not start a clock either.
Is every incident a notifiable personal data breach?
No. A security incident, a personal data breach, a NIS2 significant incident, a DORA major ICT-related incident, and a CRA actively exploited vulnerability or severe incident are different legal objects. One set of facts can trigger more than one, or none. Filing one never discharges the others. Counsel maps the set. Not legal advice.
Does ShipReady Metrics decide whether we must report?
No. The signed-in app does not decide whether you must report, does not start a notification clock, does not file with a regulator, and does not interpret YOUR facts. Compliance → CRA reporting tracks a ladder from recorded awareness for findings the org classified as CRA-in-scope. The obligation map is frameworks marked in-scope, not a legal opinion. The cyber risk register lives under Security.
Published by ShipReady Metrics, an evidence-based technology and compliance intelligence platform. This guide is educational and vendor-neutral.