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.
What must a regulatory incident report contain?
Updated
A regulator report is a field checklist, not one universal form. GDPR Art. 33(3), CRA Art. 14, NIS2 Art. 23, and the DORA RTS name different content. Partial information is permitted where the article says so. Not legal advice. The product does not file.
Field checklist, last verified 7 September 2026 against Regulation (EU) 2016/679 Article 33(3)–(4), Regulation (EU) 2024/2847 Article 14, Directive (EU) 2022/2555 Article 23, Commission Delegated Regulation (EU) 2025/301 (DORA RTS on incident-reporting content), EDPB Guidelines 9/2022, and ENISA Single Reporting Platform materials. It is not legal advice, not a filing, does not start a clock, and is not a substitute for counsel.
This is a field checklist, not a filing
Audience: an incident commander, CISO, or counsel assembling the first notification a named human will send. This page is not legal advice. It does not start a clock. Reading it does not start a clock. Filling a row is not a determination that any regime applies, that a clock has started, or that you must file.
There is no one universal regulator form. GDPR Article 33(3) is a personal-data notice to a supervisory authority. CRA Article 14 is product-security reporting to a CSIRT and ENISA. NIS2 Article 23 is significant-incident reporting to a CSIRT or competent authority. DORA Article 19 is major ICT-related-incident reporting to a competent authority; the content fields live in Delegated Regulation (EU) 2025/301, a regulatory technical standard, not in DORA itself. Filing one never discharges the others. Last verified 7 September 2026. Not legal advice.
- A named human submits. This page does not. The product does not. Mapping a field is not a filing.
- Quote the article's fields. Do not blend GDPR Article 33(3), CRA Article 14, NIS2 Article 23, and the DORA RTS into one fake form.
- Partial information is permitted only where the cited article says so. This page does not invent a general 'file whatever you have' rule.
- The reporting-deadlines page on this site is the statute table of clocks. The who-to-notify page on this site is the recipient-class map. The supporting-evidence page on this site is the evidentiary record. The document-your-decision page on this site is the decision record. A dedicated CRA Article 14 feature page is not on this site yet. Naming it is not a link.
Content fields — four instruments, not one form
Work this table with counsel. Each column is a legal requirement only if that instrument applies to YOUR facts. Statute, directive, and RTS stay labelled. ENISA Single Reporting Platform materials and EDPB Guidelines 9/2022 are regulator guidance, not the article. Last verified 7 September 2026. Not legal advice.
| Content item | GDPR Art. 33(3) — statute (only if GDPR applies) | CRA Art. 14 — statute (only if CRA applies; from 11 September 2026) | NIS2 Art. 23 — directive as transposed (only if it applies) | DORA RTS (EU) 2025/301 — RTS, not DORA itself (only if DORA applies) |
|---|---|---|---|---|
| Nature of what happened | Article 33(3)(a): describe the nature of the personal data breach. Legal requirement only if GDPR applies. | Article 14(2)(b) vulnerability notification: general information, as available, about the product with digital elements concerned, and the general nature of the exploit and of the vulnerability. Article 14(4)(b) incident notification: general information, where available, about the nature of the incident, and an initial assessment. Those two tracks are not the same form. | Article 23(4)(b) incident notification: an initial assessment of the significant incident, including its severity and impact. Article 23(4)(d)(i) final report: a detailed description of the incident, including its severity and impact. | RTS Article 2(c) initial notification: a description of the ICT-related incident. RTS Article 3(e) intermediate: the type of ICT-related incident. DORA Article 19 is the reporting duty; this row is the RTS, not the regulation. |
| Categories and approximate numbers affected | Article 33(3)(a): including where possible, the categories and approximate number of data subjects concerned and the categories and approximate number of personal data records concerned. 'Where possible' is in the article. This page does not invent a number. | Not an Article 14 field in those words. Article 14 is product-security reporting, not a personal-data headcount. Do not paste Article 33(3)(a) onto a CRA draft. | Not an Article 23 field in those words. Recipients of the entity's services are a different duty (Article 23(1)–(2)), not a categories-and-numbers cell on the CSIRT notification. | RTS Article 3 intermediate report asks, among other things, for impact on the financial interest of clients, affected functional areas and business processes, and affected infrastructure components. Those are DORA RTS fields, not GDPR categories of data subjects. |
| Likely consequences / impact | Article 33(3)(c): describe the likely consequences of the personal data breach. | Article 14(2)(c)(i) final report (actively exploited vulnerability): a description of the vulnerability, including its severity and impact. Article 14(4)(c)(i) final report (severe incident): a detailed description of the incident, including its severity and impact. The 72-hour notifications ask for general information and, on the incident track, an initial assessment — not the final-report description. | Article 23(4)(b): initial assessment including severity and impact. Article 23(4)(d)(i): detailed description including severity and impact. Article 23(4)(d)(iv): where applicable, the cross-border impact of the incident. | RTS Article 2 initial: Member States impacted; classification criteria from Delegated Regulation (EU) 2024/1772. RTS Article 3 intermediate: impact on the financial interest of clients. RTS Article 4(e) final: direct and indirect costs and losses, and financial recoveries. |
| Measures taken or proposed | Article 33(3)(d): describe the measures taken or proposed to be taken by the controller to address the personal data breach, including, where appropriate, measures to mitigate its possible adverse effects. | Article 14(2)(b): any corrective or mitigating measures taken, and corrective or mitigating measures that users can take. Article 14(2)(c)(iii) final: details about the security update or other corrective measures that have been made available. Article 14(4)(b) and 14(4)(c)(iii) are the incident-track pair (measures taken / users can take; applied and ongoing mitigation measures). | Article 23(4)(d)(iii) final report: applied and ongoing mitigation measures. The 72-hour notification does not, in Article 23(4)(b), name a measures cell; do not invent one from GDPR Article 33(3)(d). | RTS Article 2(h) initial: whether the financial entity has activated a business continuity plan. RTS Article 3(k) intermediate: temporary actions or measures taken or planned to recover. RTS Article 4(c) final: information on the resolution of the ICT-related incident. |
| Contact point | Article 33(3)(b): communicate the name and contact details of the data protection officer or other contact point where more information can be obtained. | Not an Article 14 content cell in those words. ENISA Single Reporting Platform materials (regulator guidance, not the article) describe Assigned Representative identity fields on the platform. Guidance is not the statute. | Not an Article 23 content cell in those words. The recipient of the notification is the CSIRT or, where applicable, the competent authority — that is who you notify, not a field you fill about a DPO. | RTS Article 1(e), required in initial, intermediate, and final: the contact details of the persons responsible for communicating with the competent authority on the major ICT-related incident. That is the RTS, not GDPR Article 33(3)(b). |
| Regime-specific extras (do not paste across columns) | Article 33(5) documentation of any personal data breach (facts, effects, remedial action) is a separate duty from the Article 33(1) notification. It is not a fifth 33(3) field. | Article 14(2)(a) and 14(4)(a) early warning: Member States where the manufacturer is aware the product has been made available. Article 14(2)(b) and 14(4)(b): where applicable, how sensitive the manufacturer considers the notified information. Article 14(4)(a): at least whether the severe incident is suspected of being caused by unlawful or malicious acts. Article 14(2)(c)(ii): where available, information concerning any malicious actor that has exploited or is exploiting the vulnerability. Article 14(4)(c)(ii): the type of threat or root cause that is likely to have triggered the incident. | Article 23(4)(a) early warning: where applicable, whether the significant incident is suspected of being caused by unlawful or malicious acts or could have a cross-border impact. Article 23(4)(b): where available, the indicators of compromise. Article 23(4)(d)(ii): the type of threat or root cause that is likely to have triggered the incident. | RTS Article 1 general information (type of submission; name, LEI, type of financial entity; submitting entity; aggregated entities; parent undertaking; reporting currency). RTS Article 2 initial: incident reference code assigned by the financial entity; date and time of detection and classification; how discovered; origin where available. RTS Article 3 intermediate: occurrence time; recovery time where applicable; threats and techniques; indicators of compromise where applicable. RTS Article 4 final: root causes; dates and times resolved; recurring incidents where applicable. |
GDPR Article 33(3) field checklist — statute, not a blended template
These five cells are Article 33(3) as written. They are a legal requirement only if GDPR applies and only for the controller's notification to the supervisory authority under Article 33(1). They are not CRA Article 14, not NIS2 Article 23, and not the DORA RTS. 'Where possible' and 'where appropriate' are in the article. Last verified 7 September 2026. Not legal advice.
| Article 33(3) limb | What the statute says | What this page does not do |
|---|---|---|
| (a) Nature, categories, approximate numbers | Describe the nature of the personal data breach including where possible, the categories and approximate number of data subjects concerned and the categories and approximate number of personal data records concerned. | Does not invent a headcount. Does not treat 'where possible' as optional window-dressing or as a licence to omit the nature of the breach. Does not start the 72 hours. |
| (b) Contact point | Communicate the name and contact details of the data protection officer or other contact point where more information can be obtained. | Does not name YOUR DPO. Does not treat a support inbox as the contact point. Counsel maps the role. |
| (c) Likely consequences | Describe the likely consequences of the personal data breach. | Does not assess residual risk for you. Does not convert this limb into GDPR Article 34's 'high risk' test. Article 34 is a different duty. |
| (d) Measures taken or proposed | Describe the measures taken or proposed to be taken by the controller to address the personal data breach, including, where appropriate, measures to mitigate its possible adverse effects. | Does not treat a containment ticket as the whole limb. Does not require you to finish eradication before the first notification — Article 33(4) is the phased rule. |
Phased reporting — only where the article says so
Partial information is permitted where the cited text says so. This page does not invent a general phased-filing right. GDPR Article 33(4), CRA Article 14's staged ladder, NIS2 Article 23(4), and DORA Article 19 plus the RTS are different machines. Last verified 7 September 2026. Not legal advice.
| Instrument and kind | What the cited text permits or requires | What this page does not do |
|---|---|---|
| GDPR Article 33(4) — statute (only if GDPR applies) | Where, and in so far as, it is not possible to provide the information at the same time, the information may be provided in phases without undue further delay. Article 33(1) still requires reasons if the notification itself is not made within 72 hours. EDPB Guidelines 9/2022 are regulator guidance on how Article 33 is understood; they are not the regulation. | Does not treat 'in phases' as a licence to miss the 72-hour outer mark. Does not convert Article 33(4) into CRA's 24-hour / 72-hour / 14-day ladder. |
| CRA Article 14 — statute (only if CRA applies; from 11 September 2026) | Actively exploited vulnerability: 24-hour early warning (Article 14(2)(a)); 72-hour vulnerability notification (Article 14(2)(b), 'unless the relevant information has already been provided', 'general information, as available'); final report no later than 14 days after a corrective or mitigating measure is available (Article 14(2)(c), same 'unless already provided'). Severe incident: 24-hour early warning (Article 14(4)(a)); 72-hour incident notification (Article 14(4)(b), 'where available'); final report within one month after that incident notification (Article 14(4)(c)). Article 14(6): the CSIRT designated as coordinator may request an intermediate report. The 14-day mark and the one-month mark are not averaged. | Does not paste GDPR Article 33(4) onto CRA. Does not treat 'as available' as a skip of the 24-hour early warning. A dedicated CRA Article 14 feature page is not on this site yet. Naming it is not a link. |
| NIS2 Article 23(4) — directive as transposed (only if it applies) | Early warning within 24 hours (Article 23(4)(a)); incident notification within 72 hours updating the early warning and including an initial assessment and, where available, indicators of compromise (Article 23(4)(b)); an intermediate report on the request of the CSIRT or competent authority (Article 23(4)(c)); a final report not later than one month after the incident notification (Article 23(4)(d)), or a progress report then a final report within one month of handling the incident if it is still ongoing. Recital 102 (not a separate duty) says the early warning should include the information necessary to make the CSIRT or authority aware and to allow the entity to seek assistance. | Does not treat a recital as a filing trigger. Does not paste NIS2's 24-hour / 72-hour ladder onto GDPR or DORA. A dedicated NIS2 jurisdiction guide is not on this site yet. |
| DORA Article 19 plus RTS (EU) 2025/301 — regulation + RTS (only if DORA applies) | Article 19(4) is the three-stage duty: initial notification, intermediate report, final report. RTS Article 5(1) times those stages. Recital 2 of the RTS (not a separate duty) says the content of the initial notification should be limited to the most significant information. RTS Article 2 is that initial set; Article 3 the intermediate set; Article 4 the final set. RTS Article 3(a) and several other limbs use 'where applicable' or 'where available'. RTS Article 5(3): if unable to submit in time, inform the competent authority no later than the mark and explain the reasons for the delay. | Does not treat the RTS recital as permission to omit RTS Article 2 fields. Does not paste GDPR Article 33(3) onto a DORA initial notification. A dedicated DORA jurisdiction guide is not on this site yet. |
Named-reviewer sign-off before submit
A named human still sends the filing. That is practice on every column of the table above, and it is what the product's CRA drafts actually require. It is not a GDPR Article 33(3) field, and this page does not invent it as one. Last verified 7 September 2026. Not legal advice.
- Practice: the person who assembled the facts is not, by default, the person who submits. Counsel reviews the determination that a duty applies, the content against the cited article, and the unknowns listed as unknowns. A named reviewer signs that the draft is the one to send. This page does not name that person.
- What the product actually requires for CRA drafts: signed-in app → Compliance → CRA reporting produces stage drafts (24-hour early warning, 72-hour notification, 14-day final report) from recorded awareness for findings the organization has classified as CRA-in-scope. Every draft body opens with the marker line 'DRAFT — a named reviewer must verify and submit; nothing here has been sent to any authority.' Status is the literal 'draft'. The shape carries no submission field. Unknown manufacturer, product, or Member-State list renders 'TO BE COMPLETED BY REVIEWER', never a guess. Recording an actual submission is a separate audited human action on the register. The SRP has no API in that design — a named reviewer still types the filing.
- What the product does not do: it does not submit. It does not produce a GDPR Article 33 filing pack, a NIS2 Article 23 pack, or a DORA RTS pack. It does not offer a downloadable regulator template. The obligation map is frameworks the organization marked in-scope, not a legal opinion that a reporting duty applies.
- The supporting-evidence page on this site is the evidentiary record. The document-your-decision page on this site is the decision record.
Fictional well-formed initial notification (labelled fictional)
The facts and the notice below are labelled fictional. They are a teaching walk of an honest first GDPR Article 33(1) notification that uses Article 33(4) for the unknowns. They are not YOUR facts, not a determination, not a filing, and not a template the product downloads — that file does not exist. Counsel writes the real notice. Last verified 7 September 2026. Not legal advice.
Fictional facts. 'Harborline Tools GmbH' is a controller established in Germany. On 7 September 2026 at 14:12 UTC it became aware that an unauthorised actor had used a stolen admin token to read a production table of customer-support mailbox addresses and ticket subject lines. Categories of data subjects and a count are not yet scoped. Containment (token revocation, session kill) has started. Eradication is not done. Counsel has not finished the Article 33(1) risk test; this example assumes, fictionally, that counsel has decided a supervisory-authority notification is due. This page does not decide that.
Fictional initial notification (Article 33(3) limbs, with Article 33(4) unknowns listed as unknowns — not a CRA, NIS2, or DORA filing):
- Nature (Article 33(3)(a)): unauthorised access to a customer-support mailbox table via a stolen admin token, discovered 7 September 2026 at 14:12 UTC. Not yet known whether the actor copied, only viewed, or moved laterally. Listed as unknown under Article 33(4).
- Categories and approximate numbers (Article 33(3)(a), where possible): categories of data subjects not yet scoped; approximate number of data subjects not yet scoped; categories of personal data records currently believed to include mailbox addresses and ticket subject lines; approximate number of records not yet scoped. Those four gaps are listed as gaps, not filled with a guess.
- Contact point (Article 33(3)(b)): the controller's data protection officer, name and email as recorded in the public register — fictional placeholder only, not a real address.
- Likely consequences (Article 33(3)(c)): possible unauthorised knowledge of support-mailbox addresses and ticket subject lines. Whether that is likely to result in identity fraud, phishing, or no material consequence is not yet assessed. Listed as unknown under Article 33(4).
- Measures taken or proposed (Article 33(3)(d)): admin token revoked; sessions killed; evidence hold placed; outside counsel and DFIR engaged. Further containment and individual-notice decisions are proposed, not done. This sentence is not an Article 34 communication.
- What this fictional notice is not: not a CRA Article 14 early warning, not a NIS2 Article 23(4)(a) early warning, not a DORA RTS Article 2 initial notification, not a customer email, and not a downloadable file from ShipReady Metrics.
Checklist
This is a question list, not a filing. The reporting-deadlines page on this site is the statute table of clocks. The who-to-notify page on this site is the recipient-class map. The first-72-hours page on this site is the operational 72-hour plan. The supporting-evidence page on this site is the evidentiary record. The document-your-decision page on this site is the decision record.
- Which instrument may apply? Quote it. Do not blend GDPR Article 33(3), CRA Article 14, NIS2 Article 23, and the DORA RTS into one form.
- For each instrument that may apply, copy the content cells the cited article or RTS names. Label statute versus RTS versus regulator guidance versus this page.
- List what you know and what you do not know. Use the phased rule only where the article says so (Article 33(4); CRA 'as available' / 'unless already provided'; NIS2 'where applicable' / 'where available'; DORA RTS 'where available' / 'where applicable').
- Who is the named reviewer, and who is authorised to submit? A named human submits. The product does not. This page does not.
- The fictional example above is teaching copy. It is not a template the product downloads. That file does not exist.
- This page does not start a clock. Mapping a field is not a filing.
Glossary
These are teaching labels for this page. They are not legal conclusions about YOUR facts.
| Term | How this page uses it |
|---|---|
| Field checklist | The content cells a cited article or RTS names for a notification. Not a universal form, and not a downloadable template. |
| Phased reporting | Providing information in stages because the cited article says the information may be provided in phases, is 'as available', or is split across an initial / intermediate / final ladder. Not a general skip of the first mark. |
| Initial notification | The first stage a cited ladder names: GDPR Article 33(1) notification (with Article 33(4) phasing); CRA Article 14 early warning then notification; NIS2 Article 23(4)(a)–(b); DORA Article 19(4)(a) as specified in RTS Article 2. Those four 'initial' objects are not the same filing. |
| Named reviewer | The human who verifies a draft and submits it. Practice on this page. For CRA drafts in the product: the draft is unsubmittable by type and says a named reviewer must verify and submit. |
| Statute versus RTS versus guidance | The article or directive is the legal requirement (only if it applies). A regulatory technical standard specifies content the regulation points at. EDPB and ENISA materials are regulator guidance. This page is none of those. |
| Article 33(3) | The GDPR content list for the controller's supervisory-authority notification: nature (including where possible categories and approximate numbers), contact point, likely consequences, measures taken or proposed. |
| Article 33(4) | The GDPR phased-information rule. Not CRA's 24-hour / 72-hour / 14-day ladder, and not DORA's initial / intermediate / final reports. |
Where this shows up in ShipReady Metrics
The signed-in app does not prepare a GDPR Article 33 filing pack, does not file with a regulator, does not start a notification clock, and does not interpret YOUR facts. None of the surfaces below is a downloadable regulator template. That file does not exist.
If you already have a session: signed-in app → Compliance → CRA reporting produces draft ladder text (24-hour early warning, 72-hour notification, 14-day final report) from recorded awareness for findings the organization has classified as CRA-in-scope. Each draft is marked DRAFT and states that a named reviewer must verify and submit; nothing in that surface has been sent to any authority. Status is the literal 'draft'. The shape carries no submission field. It is not a GDPR Article 33 pack, not a NIS2 Article 23 pack, and not a DORA RTS pack. 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 field checklist. 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, or a CRA Article 14 notification.
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 Article 33(3)–(4) is a legal requirement only when GDPR applies. EDPB Guidelines 9/2022 are regulator guidance. Regulation (EU) 2024/2847 Article 14 is a legal requirement only when CRA applies and applies from 11 September 2026; ENISA's Single Reporting Platform materials, including the SRP Glossary, describe the filing path and platform fields — they are not the article. 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 Article 19 is the DORA reporting duty; Commission Delegated Regulation (EU) 2025/301 is the RTS specifying content and time limits; templates live in Commission Implementing Regulation (EU) 2025/302. 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 do-I-have-to-report page on this site is the class map. The reporting-decision-tree page on this site is the branching tree. 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. The supporting-evidence page on this site is the evidentiary record. The document-your-decision page on this site is the decision record. The failure-to-report-consequences page on this site is the maxima table. The how-regulators-determine-knowledge page on this site is the clock-start analysis. The GDPR breach-notification guide on this site is the jurisdiction treatment of Articles 33–34. A dedicated 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. A dedicated CRA Article 14 feature page is not on this site yet.
Frequently asked questions
What must a regulatory incident report contain?
Whatever the cited article names — not a blended template. GDPR Article 33(3) is nature (including where possible categories and approximate numbers), contact point, likely consequences, and measures taken or proposed. CRA Article 14, NIS2 Article 23, and DORA RTS (EU) 2025/301 name different cells. Last verified 7 September 2026. Not legal advice.
Is this legal advice?
No. It is a field checklist distilled from GDPR Article 33(3)–(4), CRA Article 14, NIS2 Article 23, and DORA RTS (EU) 2025/301, with EDPB Guidelines 9/2022 and ENISA Single Reporting Platform materials as regulator guidance. Whether any duty applies, what you must file, and whether a clock has started are legal questions for counsel on your facts. This page does not start a reporting clock.
Does ShipReady file this?
No. The signed-in app does not file with a regulator and does not produce a GDPR Article 33 pack. Compliance → CRA reporting drafts the Article 14 24-hour / 72-hour / 14-day ladder from recorded awareness for findings the org classified as CRA-in-scope. Each draft says a named reviewer must verify and submit; nothing has been sent. The obligation map is in-scope marks, not a filing.
Can we send a partial initial notification?
Only where the cited article says so. GDPR Article 33(4) allows information in phases without undue further delay when it cannot all be provided at once; Article 33(1) still requires reasons if the notification itself is late. CRA Article 14 uses 'as available' / 'unless already provided' across a 24-hour / 72-hour / 14-day (or one-month) ladder. NIS2 Article 23(4) and DORA RTS (EU) 2025/301 split content across stages and use 'where available' / 'where applicable'. This page does not invent a general skip. Not legal advice.
Does this page start a reporting clock?
No. GDPR Article 33 runs from becoming aware; CRA Article 14 runs from the manufacturer becoming aware; NIS2 Article 23(4) runs from becoming aware of a significant incident; DORA's initial-notification marks run from classification as major and from awareness as the RTS specifies. Reading a public field checklist is none of those events. The signed-in CRA ladder tracks recorded awareness; it does not start a clock either.
Published by ShipReady Metrics, an evidence-based technology and compliance intelligence platform. This guide is educational and vendor-neutral.