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.
Which reporting obligations might this incident trigger?
Updated
Walk this tree top to bottom. Each yes adds a regime that may apply; a yes on an earlier row does not skip later rows. This tool is not legal advice and does not start a clock.
Branching 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, 17 CFR 229.106 and Form 8-K Item 1.05, HIPAA 45 CFR §§164.400–414, PIPEDA s. 10.1, Australia Privacy Act 1988 Part IIIC, India CERT-In Directions 2022, and ADGM Data Protection Regulations 2021 Article 32. It is not legal advice, not a filing, and not a substitute for counsel.
This tool is not legal advice
Audience: an incident commander, CISO, founder, or counsel mapping which reporting duties one incident might trigger. This tool is not legal advice. It does not start a clock. Counsel decides whether any duty applies and whether a clock has started on YOUR facts.
Walk top to bottom. A yes on an earlier row does not skip later rows. One incident can sit in more than one class at once — personal-data notification, sector or incident reporting, listed-issuer disclosure, and product-vulnerability reporting are different duties with different recipients. Filing one never discharges the others. Last verified 7 September 2026. Not legal advice.
- This page lists regimes that may apply. Mapping a class is not a determination that any duty applies, and it is not an instruction to submit a filing.
- Clock-start is the event the cited article names — awareness, discovery, determination, or noticing. Reading this page is none of those events.
- Unpublished jurisdiction guides (GDPR, NIS2, DORA, CRA, UK GDPR, US-state, SEC, HIPAA, PIPEDA, Australia NDB, India DPDP / CERT-In, UAE/Dubai) are named in prose only. A dedicated guide for each is not on this site yet. Naming them is not a link.
- The do-I-have-to-report page on this site is the class map (personal-data vs sector vs product-vulnerability). This page is the branching tree that feeds that map.
Decision tree — data type
Start here. Personal data is not the only trigger. An incident with no personal data can still sit in a sector, listed-issuer, or product-vulnerability class. 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? | Add a personal-data notification class to the output set and continue. GDPR Articles 33–34 are the EU controller/processor example. Cal. Civ. Code §1798.82 is a US-state example. HIPAA 45 CFR §§164.400–414 is the US health-sector example when unsecured protected health information is in play. PIPEDA s. 10.1 is the Canadian federal example. Australia Privacy Act 1988 Part IIIC is the NDB example. Continue to the jurisdiction table — do not stop. 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 HIPAA, Canada PIPEDA, Australia NDB, UK GDPR, India DPDP / CERT-In, and UAE/Dubai guide is not on this site yet. | Do not treat 'no personal data' as 'no reporting duty'. Continue to sector, listed-issuer, and product-vulnerability rows. NIS2, DORA, SEC Item 1.05, and CRA Article 14 can attach without a personal-data breach. |
Decision tree — jurisdiction of individuals and entity location
Work every row that might match. People in more than one place, and an entity established in more than one place, can stack regimes. The which-jurisdictions-apply page on this site is the applicability map. Last verified 7 September 2026. Not legal advice.
| Question | If the facts point yes | If the facts point no |
|---|---|---|
| Are affected individuals in the EEA, or is the controller or processor established in the Union, in circumstances where GDPR's territorial scope might attach? | GDPR Articles 33–34 may apply (supervisory authority; in a high-risk subset, the data subject). Clock-start in Article 33(1) is becoming aware. A dedicated GDPR jurisdiction guide is not on this site yet. | Continue. GDPR is one personal-data statute, not the set. |
| Are affected individuals in the United Kingdom, or is the controller or processor established in the UK, in circumstances where UK GDPR might attach? | UK GDPR personal-data-breach notification to the ICO may apply. Treat it as a separate leaf from EU GDPR. A dedicated UK GDPR jurisdiction guide is not on this site yet. | Continue. UK GDPR is not discharged by an EU GDPR filing, or the reverse. |
| Are affected individuals California residents whose unencrypted personal information (or encrypted information plus the key) was, or is reasonably believed to have been, acquired by an unauthorized person? | Cal. Civ. Code §1798.82 may apply. Clock-start is discovery or notification of the breach; as of 1 January 2026, disclosure within 30 calendar days of that event, subject to the statute's delay language. Other US states differ. A dedicated US-state-laws guide is not on this site yet. | Continue. California is one state example, not a 50-state map. |
| Is the organization a HIPAA covered entity or business associate, and was unsecured protected health information acquired, accessed, used, or disclosed in a manner not permitted under the Privacy Rule? | HIPAA 45 CFR §§164.400–414 may apply. Clock-start is discovery (known, or by reasonable diligence would have been known). Individual notice without unreasonable delay and in no case later than 60 calendar days after discovery (§164.404). A dedicated HIPAA jurisdiction guide is not on this site yet. | HIPAA is a health-sector personal-data statute. Continue to other health, state, and sector rows if they might match. |
| Is the organization subject to PIPEDA, and is it reasonable to believe a breach of security safeguards creates a real risk of significant harm to an individual? | PIPEDA s. 10.1 may apply. Report to the Commissioner, and notify the individual, as soon as feasible after the organization determines that the breach has occurred. A dedicated Canada PIPEDA guide is not on this site yet. | Continue. Provincial private-sector statutes can attach where PIPEDA does not. This tree does not map them. |
| Is the organization an APP entity holding personal information, with unauthorised access, unauthorised disclosure, or loss that a reasonable person would conclude is likely to result in serious harm? | Australia Privacy Act 1988 Part IIIC (NDB) may apply. Sections 26WK–26WL: prepare a statement and notify the Information Commissioner and affected individuals as soon as practicable after becoming aware that there are reasonable grounds to believe an eligible data breach has occurred. A dedicated Australia NDB guide is not on this site yet. | Continue. 'Likely to result in serious harm' is the statute's test. This page does not score it. |
| Is the organization a body that CERT-In Directions 2022 name (service provider, intermediary, data centre, body corporate, or government organisation), and is the event a cyber incident in Annexure I of those Directions? | CERT-In Directions 28 April 2022 (IT Act s. 70B) may apply: report to CERT-In within 6 hours of noticing the incident or being brought to notice of it. DPDP Act 2023 s. 8(6) is a separate personal-data-fiduciary intimation duty (Board and affected Data Principal, form and manner as prescribed) — this page does not invent a numeric DPDP clock. A dedicated India DPDP / CERT-In guide is not on this site yet. | Continue. CERT-In is incident reporting, not a substitute for a personal-data statute. |
| Is the controller established in ADGM, or in the DIFC, or otherwise in the UAE in circumstances where a UAE personal-data statute might attach? | ADGM Data Protection Regulations 2021 Article 32 may apply (notify the Office of Data Protection without undue delay and, where feasible, not later than 72 hours after becoming aware). DIFC Data Protection Law No. 5 of 2020 Articles 41–42 may apply (notify the Commissioner as soon as practicable where the breach compromises confidentiality, security or privacy). Federal Decree-Law No. 45 of 2021 (PDPL) is a separate mainland regime; this page does not invent a numeric federal clock. A dedicated UAE/Dubai guide is not on this site yet. | Continue. DIFC, ADGM, and mainland PDPL are not interchangeable. |
Decision tree — sector and entity classification
Sector class is entity-and-service specific. Do not import a duty because the incident is serious. Walk every row. Last verified 7 September 2026. Not legal advice.
| Question | If the facts point yes | If the facts point no |
|---|---|---|
| Are you an essential or important entity under NIS2 as transposed, and is this a significant incident? | NIS2 Article 23 may apply: notify the CSIRT or competent authority. Article 23(4) clock-start is becoming aware of the significant incident (24-hour early warning; 72-hour notification; final report not later than one month after the incident notification). A dedicated NIS2 jurisdiction guide is not on this site yet. | Do not import NIS2 because the incident is serious. Scope, transposition, and 'significant' are legal and factual tests. This page does not apply them. |
| Are you a financial entity (or an in-scope ICT third-party) under DORA, and is this a major ICT-related incident? | DORA Article 19 may apply: report major ICT-related incidents to the relevant competent authority. Initial, intermediate, and final reports run within the time limits laid down under Article 20 — this page does not restate those hours as yours. Classification is Article 18. DORA is lex specialis as against NIS2 for in-scope financial entities (NIS2 recital 28). A dedicated DORA jurisdiction guide is not on this site yet. | Do not paste NIS2's 24-hour / 72-hour ladder onto DORA. Do not classify the incident as major on this page. |
| Are you a HIPAA covered entity or business associate (health sector), with a breach of unsecured PHI? | HIPAA 45 CFR §§164.400–414 may apply — see the jurisdiction table. Media notice if more than 500 residents of a State or jurisdiction (§164.406). Secretary notice contemporaneous with individual notice if 500 or more individuals (§164.408(b)); annual log if fewer than 500 (§164.408(c)). A dedicated HIPAA jurisdiction guide is not on this site yet. | Health-adjacent processing is not, by itself, HIPAA. Covered-entity and business-associate status are legal tests. |
| Are you an SEC registrant, and is this a cybersecurity incident that has been determined to be material? | Form 8-K Item 1.05 may apply (17 CFR 249.308; definitions in 17 CFR 229.106). File within four business days after the registrant determines that it has experienced a material cybersecurity incident. Instruction 1 to Item 1.05: the materiality determination must be made without unreasonable delay after discovery of the incident. Clock-start is determination, not discovery. A dedicated SEC cyber-disclosure guide is not on this site yet. | Do not treat every incident as material. Do not start a four-business-day clock from discovery. This page does not determine materiality. |
| 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? | CRA Article 14 may apply from 11 September 2026. Notify the CSIRT designated as coordinator and ENISA via the Single Reporting Platform. Two tracks — actively exploited vulnerability and severe incident — with different final-report marks. A dedicated CRA jurisdiction guide is not on this site yet. The worked example below is a class of clock, not a determination that CRA applies. | Do not import a CRA duty because you had an incident. CRA is product-security reporting, not a personal-data statute and not NIS2. |
Decision tree — severity and threshold class
Thresholds are not interchangeable. Walk the row for each regime already on the output set. No numeric threshold on this page is invented. The reporting-deadlines page on this site is the statute table of those clocks. Last verified 7 September 2026. Not legal advice.
| Question | If the facts point yes | If the facts point no |
|---|---|---|
| GDPR — is the personal data breach 'unlikely to result in a risk to the rights and freedoms of natural persons' (Article 33(1))? | Article 33(1)'s exception language may take the authority notification off the table — counsel applies that test. Article 33(5) still requires documentation of personal data breaches even when you do not notify. Article 34(1) is a narrower 'high risk' test for communication to the data subject. A dedicated GDPR jurisdiction guide is not on this site yet. | If the exception does not apply, GDPR Article 33 may stay on the output set. This page does not score your risk. EDPB Guidelines 9/2022 are regulator guidance, not the regulation. |
| NIS2 — has the incident caused or is it capable of causing severe operational disruption of the services or financial loss for the entity, or considerable material or non-material damage to others (Article 23(3))? | The incident may be 'significant' under Article 23(3). No numeric loss figure is in that article. A dedicated NIS2 jurisdiction guide is not on this site yet. | Do not treat a CVSS number as 'significant'. Continue other rows. |
| DORA — has the incident been classified as a major ICT-related incident under Article 18? | Article 19 reporting may apply. This page does not classify it. A dedicated DORA jurisdiction guide is not on this site yet. | Voluntary notification of significant cyber threats is Article 19(2) — a different object from a major incident. |
| CRA — is it an actively exploited vulnerability in the product, or a severe incident having an impact on the security of the product (Article 14(1) and (3))? | The matching CRA track may apply from 11 September 2026. 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). A dedicated CRA jurisdiction guide is not on this site yet. | KEV-match in a scanner is not, by itself, CRA awareness. The signed-in CRA ladder tracks findings the organization already classified as CRA-in-scope. |
| SEC — has the registrant determined, without unreasonable delay after discovery, that the cybersecurity incident is material? | Item 1.05 may apply. Four business days run from that determination. A dedicated SEC cyber-disclosure guide is not on this site yet. | Discovery without a materiality determination does not start the four business days. Instruction 1 to Item 1.05 still requires the determination without unreasonable delay. |
| HIPAA — is there a low probability that the PHI has been compromised, demonstrated on the four-factor risk assessment in 45 CFR §164.402? | The presumption of breach in §164.402 may be rebutted — counsel applies that test. Burden of proof is §164.414(b). A dedicated HIPAA jurisdiction guide is not on this site yet. | Unless an exclusion in §164.402 applies or the low-probability showing is made, the acquisition, access, use, or disclosure is presumed a breach. |
Output — regimes that may apply
This is a working list of regimes that may apply, with the clock-start the cited article names. It is not an instruction to submit a filing. Statutory times are not averaged and not rounded. Counsel applies each row to YOUR facts. The reporting-deadlines page on this site is the statute table of those clocks. Last verified 7 September 2026. Not legal advice.
| Regime that may apply | Clock-start the article names | Statutory time as cited |
|---|---|---|
| GDPR Articles 33–34 — legal requirement only if GDPR applies. A dedicated GDPR jurisdiction guide is not on this site yet. | Awareness. Article 33(1): 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. | Without undue delay and, where feasible, not later than 72 hours after having become aware (authority). Article 34 communication to the data subject when the breach is likely to result in a high risk — without undue delay. Article 33(4) allows information in phases. |
| NIS2 Article 23 — legal requirement only if NIS2 as transposed applies. A dedicated NIS2 jurisdiction guide is not on this site yet. | Awareness of the significant incident. Article 23(4). | Early warning without undue delay and in any event within 24 hours of becoming aware; incident notification within 72 hours of becoming aware; final report not later than one month after the incident notification (or, if still ongoing, a progress report then a final report within one month of handling). |
| DORA Articles 18–19 — legal requirement only if DORA applies. A dedicated DORA jurisdiction guide is not on this site yet. | Classification as a major ICT-related incident under Article 18, after collecting and analysing all relevant information (Article 19(1)). Not the same event as NIS2 'becoming aware'. | Initial, intermediate, and final reports within the time limits laid down under Article 20. This page does not restate those hours as yours. |
| CRA Article 14 — legal requirement only if CRA applies; applies from 11 September 2026. A dedicated CRA jurisdiction guide is not on this site yet. | Awareness. Each stage runs from the manufacturer becoming aware of the actively exploited vulnerability or of the severe incident (Article 14(2) and (4)). | Actively exploited vulnerability: 24-hour early warning, 72-hour notification, final report no later than 14 days after a corrective or mitigating measure is available. Severe incident: 24-hour early warning, 72-hour notification, final report within one month of the incident notification. Those two final-report marks are not the same and are not averaged. |
| Form 8-K Item 1.05 (17 CFR 229.106 definitions) — legal requirement only if you are a registrant and the incident is determined material. A dedicated SEC cyber-disclosure guide is not on this site yet. | Determination. Four business days after the registrant determines that it has experienced a material cybersecurity incident. The determination itself must be made without unreasonable delay after discovery (Instruction 1 to Item 1.05). | Four business days from determination — not from discovery, and not from awareness as GDPR uses that word. |
| HIPAA 45 CFR §164.404 — legal requirement only if HIPAA applies. A dedicated HIPAA jurisdiction guide is not on this site yet. | Discovery. A breach is treated as discovered on the first day it is known, or by exercising reasonable diligence would have been known (§164.404(a)(2)). | Without unreasonable delay and in no case later than 60 calendar days after discovery of a breach, except as provided in §164.412 (law-enforcement delay). |
| Cal. Civ. Code §1798.82 — legal requirement only if it applies. A dedicated US-state-laws guide is not on this site yet. | 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. Other states use different start language and different times. This is one example. |
| PIPEDA s. 10.1 — legal requirement only if PIPEDA applies. A dedicated Canada PIPEDA guide is not on this site yet. | Determination. As soon as feasible after the organization determines that the breach has occurred (s. 10.1(2) and (6)). | As soon as feasible — no hour-count in the Act. The Breach of Security Safeguards Regulations (SOR/2018-64) prescribe content, not a substitute clock. |
| Australia Privacy Act 1988 Part IIIC — legal requirement only if the NDB scheme applies. A dedicated Australia NDB guide is not on this site yet. | Awareness that there are reasonable grounds to believe an eligible data breach has occurred (ss. 26WK–26WL). | As soon as practicable. This page does not convert that phrase into a number of hours. |
| CERT-In Directions 28 April 2022 — legal requirement only if those Directions apply. A dedicated India DPDP / CERT-In guide is not on this site yet. | Noticing. Within 6 hours of noticing the incident or being brought to notice of it. | 6 hours from noticing or being brought to notice — not from classification, and not a DPDP clock. DPDP Act 2023 s. 8(6) is a separate intimation duty in the form and manner as prescribed; this page does not invent that clock. |
| ADGM Data Protection Regulations 2021 Article 32 — legal requirement only if ADGM DPR apply. DIFC Articles 41–42 are a separate leaf. A dedicated UAE/Dubai guide is not on this site yet. | Awareness (ADGM). As soon as practicable in the circumstances (DIFC Article 41). | ADGM: without undue delay and, where feasible, not later than 72 hours after becoming aware. DIFC: as soon as practicable — this page does not convert that phrase into 72 hours. |
Worked example — CRA Article 14 as a product-vulnerability clock
This is a class of clock the product can track. It is not a determination that CRA applies to YOUR product, YOUR finding, or YOUR incident. Counsel decides scope, 'product with digital elements', 'becoming aware', 'actively exploited', and 'severe'. Last verified 7 September 2026. Not legal advice.
CRA Article 14 applies from 11 September 2026. Two tracks, not one ladder averaged:
- 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. Clock-start: the manufacturer becoming aware.
- 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. Clock-start: the manufacturer becoming aware. 'Severe' is qualitative in Article 14(5).
- Recipient: the CSIRT designated as coordinator and ENISA, via the Single Reporting Platform. ENISA's platform materials describe the filing path; they do not decide that CRA applies.
- Where this shows up in the product: 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. This decision tree does not write into that ladder.
Checklist for the commander
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. The do-I-have-to-report page on this site is the class map. The who-to-notify page on this site is the recipient-class map. A dedicated document-your-decision, prepare-regulatory-report, and supporting-evidence guide is not on this site yet.
- Walk every table. A yes on data type does not skip jurisdiction, sector, or threshold. Multiple regimes can apply to one incident.
- List the regimes that may apply. Counsel decides on YOUR facts whether any of them requires a filing.
- For each regime on that list, write the clock-start the article names (awareness, discovery, determination, noticing) and the UTC time you currently believe that event occurred. This page does not find that event.
- Do not average statutory times. GDPR 72 hours, NIS2 24/72/one-month, CRA 24/72/14-day vs 24/72/one-month, SEC four business days, HIPAA 60 calendar days, CERT-In 6 hours are different clocks.
- Who is authorised to file, and who is not. A named human files. The product does not. This tree does not file.
- 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 that may apply | A named instrument that this tree has not ruled out on the facts you walked. Not an instruction to submit a filing. |
| Awareness | Clock-start language in GDPR Article 33, NIS2 Article 23(4), CRA Article 14, and ADGM Article 32. Not the same event as SEC determination or HIPAA discovery. |
| Determination | Clock-start language in Form 8-K Item 1.05 (materiality) and PIPEDA s. 10.1 (that the breach has occurred). Instruction 1 to Item 1.05 still requires the materiality determination without unreasonable delay after discovery. |
| Discovery | Clock-start language in HIPAA §164.404(a)(2) and Cal. Civ. Code §1798.82. HIPAA includes constructive knowledge (reasonable diligence). |
| Noticing | Clock-start language in CERT-In Directions 2022: 6 hours of noticing the incident or being brought to notice of it. |
| Significant incident | NIS2 Article 23(3)'s two-limb test. Not a CVSS number, and not DORA's 'major ICT-related incident'. |
| Material cybersecurity incident | Form 8-K Item 1.05's reporting object, using the cybersecurity-incident definition in 17 CFR 229.106(a). Materiality is a securities-law test this page does not apply. |
| Actively exploited vulnerability | CRA Article 14(1) track. Separate from the severe-incident track in Article 14(3). The product's CRA ladder is a tracker for findings the org classified as CRA-in-scope, not a determination that this track applies. |
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. This decision tree does not write into the CRA ladder. None of the surfaces below is an instruction to submit a filing.
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, a Form 8-K Item 1.05, or a HIPAA §164.404 notice.
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. 17 CFR 229.106 and Form 8-K Item 1.05 are securities-law disclosure. HIPAA 45 CFR §§164.400–414 is the US breach-notification rule for unsecured PHI. PIPEDA s. 10.1 and SOR/2018-64 are the Canadian federal example. Australia Privacy Act 1988 Part IIIC is the NDB scheme. CERT-In Directions 28 April 2022 are incident-reporting directions under IT Act s. 70B. ADGM Data Protection Regulations 2021 Article 32 is the ADGM example. These are examples, not a complete world list. Not legal advice.
The reporting-deadlines page on this site is the statute table. The who-to-notify page on this site is the recipient-class map. The regulator-customer-individual page on this site is the three-stream comparison. The which-jurisdictions-apply page on this site is the applicability map. A dedicated 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. The do-I-have-to-report page on this site is the class map.
Frequently asked questions
Which reporting obligations might this incident trigger?
This tree cannot tell you which duties apply. Walk data type, jurisdiction, sector, and threshold with counsel. The output is a set of regimes that may apply — GDPR Articles 33–34, NIS2 Article 23, DORA Article 19, CRA Article 14, Form 8-K Item 1.05, HIPAA 45 CFR §§164.400–414, and the other leaves named above. Last verified 7 September 2026. Not legal advice.
Is this legal advice?
No. This tool is not legal advice. It is a branching regime-map distilled from the statutes cited on this page. 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 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; Form 8-K Item 1.05 runs from determination of materiality; HIPAA §164.404 runs from discovery. Reading a public page is none of those events. The signed-in CRA ladder tracks recorded awareness; it does not start a clock either.
Can one incident trigger more than one regime?
Yes. A yes on an earlier row does not skip later rows. Personal-data notification, sector or incident reporting, listed-issuer disclosure, and product-vulnerability reporting are different duties with different recipients. 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. This decision tree does not write into the CRA ladder. 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.