# Security Incident Report: [Incident ID, short title]

> Record and post-incident report for one cybersecurity incident: summary, classification, detection and
> awareness, timeline, scope and impact, evidence and chain of custody, analysis and root cause, response
> actions, regulatory and contractual notifications with their clocks, communications, lessons learned mapped
> to the six NIST CSF 2.0 functions, corrective actions and closure. It follows NIST SP 800-61 Rev. 3,
> *Incident Response Recommendations and Considerations for Cybersecurity Risk Management: A CSF 2.0 Community
> Profile* (April 2025), and lists EU, UK and US reporting clocks as dated examples: GDPR Article 33, NIS2
> Article 23, Cyber Resilience Act Article 14 (reporting since 11 September 2026), DORA and SEC Form 8-K
> Item 1.05. Replace every `[bracketed]` value and every row marked *Example*. This is a documentation format,
> not legal advice; check the current official texts and a qualified professional before deciding on a
> notification.

<!--
Guidance: How to use this template
- Open the record when an event is declared an incident and keep it current during the response; the same document becomes the post-incident report. Sections 1 to 9 are filled during the response, sections 10 to 13 after it.
- Fill section 3 (detection and awareness) at once. The awareness timestamp starts most legal clocks, and section 9 calculates every deadline from it.
- Write facts with times and sources; mark assumptions as such. Use UTC and state the time zone in every table.
- Keep sensitive evidence (indicators, credentials, personal data) in the case management system and refer to it by ID; this report may be read widely.
- Cross-reference: Incident Response Plan (`compliance/incident-response-plan`), Incident Severity Matrix (`ops/incident-severity-matrix`), Incident Commander Handbook (`ops/incident-commander-handbook`), Personal Data Breach Assessment (`compliance/personal-data-breach-assessment`), DORA Major Incident Report (`compliance/dora-major-incident-report`), CRA Vulnerability Handling (`security/cra-vulnerability-handling`), SOC Playbook (`security/soc-playbook`), Postmortem (`dev/postmortem`) for blameless review format.
- Pitfall: a report written weeks later from memory, with times that do not match the logs and no record of when the organisation became aware.
-->

## Document control

<!-- Guidance: Identify the incident and who may read the report. Restrict distribution while the investigation or any legal process is open. -->

| Field | Value |
|---|---|
| Document ID | [SIR-2026-NNN] |
| Incident ID | [INC-NNNN, case management reference] |
| Version | [0.1] |
| Status | [Open / Contained / Recovered / Closed] |
| Owner (incident lead) | [@incident-lead] |
| Approvers/reviewers | [@ciso], [@legal-counsel], [@dpo], [@system-owner] |
| Severity | [SEV-1 / SEV-2 / SEV-3 / SEV-4 per the severity matrix] |
| Legal privilege | [Prepared at the direction of counsel: Yes / No] |
| Classification | [Confidential, restricted distribution] |
| Last updated | YYYY-MM-DD |

### Approvals

| Role | Name | Decision | Date |
|---|---|---|---|
| Incident lead | [@name] | [Report accurate] | YYYY-MM-DD |
| Chief information security officer | [@name] | [Approve closure / Keep open] | YYYY-MM-DD |
| Legal counsel | [@name] | [Notifications complete] | YYYY-MM-DD |
| Data protection officer | [@name] | [Advice recorded] | YYYY-MM-DD |

### Revision history

| Version | Date | Author | Change summary |
|---|---|---|---|
| 0.1 | YYYY-MM-DD | [@name] | Record opened at declaration |
| 0.5 | YYYY-MM-DD | [@name] | *Example:* Scope confirmed, notifications recorded |
| 1.0 | YYYY-MM-DD | [@name] | *Example:* Post-incident report approved; corrective actions assigned |

## Contents

<!-- Guidance: Keep this list aligned with the headings. -->

1. [Summary](#1-summary)
2. [Classification](#2-classification)
3. [Detection and awareness](#3-detection-and-awareness)
4. [Timeline](#4-timeline)
5. [Scope and impact](#5-scope-and-impact)
6. [Evidence and chain of custody](#6-evidence-and-chain-of-custody)
7. [Analysis and root cause](#7-analysis-and-root-cause)
8. [Response actions](#8-response-actions)
9. [Notifications and reporting clocks](#9-notifications-and-reporting-clocks)
10. [Communications](#10-communications)
11. [Lessons learned by CSF 2.0 function](#11-lessons-learned-by-csf-20-function)
12. [Corrective actions](#12-corrective-actions)
13. [Metrics and closure](#13-metrics-and-closure)
14. [Glossary and references](#14-glossary-and-references)

## 1. Summary

<!-- Guidance: Write five to eight sentences a board member can read: what happened, when, impact, current status, notifications, and the most important fix. Update it at each version. Pitfall: technical detail here that belongs in section 7. -->

*Example:* On 2026-09-14 at 02:10 UTC an attacker exploited a known vulnerability in the remote access appliance of an online marketplace operator (a fictional organisation). Using a service account with excessive rights, the attacker reached a file server and copied an archive of 18,400 customer records (names, email and postal addresses, order history; no payment card data or passwords). Endpoint detection raised an alert at 07:40 UTC; the incident was declared SEV-1 at 08:50 and the appliance isolated at 11:30. Exfiltration of personal data was confirmed at 10:15 UTC, which started the GDPR and NIS2 clocks. The supervisory authority and the national CSIRT were notified within the deadlines, and affected customers were informed on 2026-09-18. Services were fully recovered on 2026-09-20. The main corrective actions are a patching service level for internet-facing appliances and removal of standing service account rights.

| Field | Value |
|---|---|
| Incident type | [*Example:* Unauthorised access and data exfiltration] |
| Current status | [*Example:* Closed, corrective actions open] |
| Systems affected | [*Example:* Remote access appliance, file server FS-02] |
| Data affected | [*Example:* 18,400 customer records, personal data] |
| Notifications made | [*Example:* Supervisory authority, national CSIRT, affected customers, cyber insurer] |

## 2. Classification

<!-- Guidance: Classify with the organisation's own severity matrix and record the reasoning, because it drives escalation and some legal thresholds. Questions: Is this an incident or only an event? Is personal data involved? Is it "significant" under NIS2 or "major" under DORA? Pitfall: downgrading severity to avoid notification without recording why. -->

| Item | Value | Reasoning |
|---|---|---|
| Event or incident | [Incident] | [*Example:* Confirmed compromise of confidentiality] |
| Category | [*Example:* Intrusion with data exfiltration] | [Taxonomy used, for example the internal list or the ENISA reference taxonomy] |
| Severity | [*Example:* SEV-1] | [Matrix criteria met] |
| Personal data breach (GDPR Article 4(12)) | [Yes / No] | [See `compliance/personal-data-breach-assessment`] |
| Significant incident (NIS2 Article 23(3)) | [Yes / No / Not in scope] | [Severe operational disruption or financial loss, or considerable damage to others] |
| Major ICT-related incident (DORA) | [Yes / No / Not in scope] | [See `compliance/dora-major-incident-report`] |
| Severe incident affecting product security (CRA Article 14) | [Yes / No / Not a manufacturer] | [Reasoning] |
| Material cybersecurity incident (SEC Form 8-K Item 1.05) | [Yes / No / Not a registrant] | [Materiality determination date and decision maker] |

## 3. Detection and awareness

<!-- Guidance: Record how the incident was detected and the moment the organisation became aware in the legal sense. Different laws use different triggers; record each moment separately. Pitfall: using the detection alert time when the legal trigger is confirmation, or the reverse, without saying which. -->

| Moment | Date and time (UTC) | Source | Recorded by |
|---|---|---|---|
| First malicious activity (established later) *(Example)* | 2026-09-14 02:10 | Appliance logs | [@forensic-analyst] |
| Detection (first alert) *(Example)* | 2026-09-14 07:40 | EDR alert on FS-02: unusual archive creation | [@soc-analyst] |
| Incident declared *(Example)* | 2026-09-14 08:50 | Incident lead decision | [@incident-lead] |
| Awareness of significant incident and of personal data breach *(Example)* | 2026-09-14 10:15 | Outbound transfer of the archive confirmed in proxy logs | [@incident-lead] |
| Materiality determination, if applicable | [YYYY-MM-DD HH:MM] | [Decision body] | [@name] |

Detection source categories: [internal monitoring / user report / third-party notification / threat intelligence / law enforcement / attacker contact].

## 4. Timeline

<!-- Guidance: One row per fact, with time, source and actor. Separate attacker actions (from forensics) from response actions. Keep the times identical to sections 3, 8 and 9. Pitfall: mixing local times and UTC. -->

| Time (UTC) | Actor | Event | Source |
|---|---|---|---|
| 2026-09-14 02:10 *(Example)* | Attacker | Exploits unpatched vulnerability in the remote access appliance | Appliance logs |
| 2026-09-14 02:40 *(Example)* | Attacker | Signs in to the internal network with service account svc-backup | Directory logs |
| 2026-09-14 06:55 *(Example)* | Attacker | Creates archive of customer export folder on FS-02 | EDR telemetry |
| 2026-09-14 07:20 *(Example)* | Attacker | Transfers archive to external host | Proxy logs |
| 2026-09-14 07:40 *(Example)* | SOC | Alert on archive creation | EDR |
| 2026-09-14 08:50 *(Example)* | Incident lead | Declares SEV-1, opens bridge | Case log |
| 2026-09-14 10:15 *(Example)* | Incident lead | Confirms exfiltration of personal data | Proxy logs |
| 2026-09-14 11:30 *(Example)* | Network team | Isolates appliance, disables svc-backup | Change record |
| 2026-09-15 09:30 *(Example)* | Legal | Submits NIS2 early warning | CSIRT portal receipt |
| 2026-09-16 16:30 *(Example)* | DPO and legal | Notifies supervisory authority; submits NIS2 incident notification | Portal receipts |
| 2026-09-18 18:00 *(Example)* | Infrastructure | Eradication complete: appliance replaced and patched, credentials reset | Change records |
| 2026-09-18 *(Example)* | Customer care | Emails affected customers | Mail platform log |
| 2026-09-20 14:00 *(Example)* | Service owner | Recovery complete, monitoring heightened | Case log |

```mermaid
sequenceDiagram
  participant A as Attacker
  participant V as Remote access appliance
  participant F as File server FS-02
  participant S as SOC
  participant L as Incident lead
  A->>V: Exploit unpatched vulnerability (02:10)
  A->>F: Sign in with svc-backup and archive data
  F-->>A: Archive sent to external host (07:20)
  F->>S: EDR alert (07:40)
  S->>L: Escalation, SEV-1 declared (08:50)
  L->>V: Isolate appliance (11:30)
```

## 5. Scope and impact

<!-- Guidance: Describe what was affected and how badly, with counts and confidence. Questions: Which systems, accounts and data sets? How many people or customers? Was there service disruption or financial loss? Is any impact still unknown? Pitfall: stating "no data accessed" before logs prove it. -->

| Dimension | Finding | Confidence | Basis |
|---|---|---|---|
| Systems *(Example)* | Remote access appliance; FS-02 | High | Forensic images |
| Accounts *(Example)* | svc-backup (service account) | High | Directory logs |
| Data *(Example)* | 18,400 customer records: names, email and postal addresses, order history | High | Archive reconstructed from file server |
| Data not affected *(Example)* | Payment data (held by payment provider), passwords | High | No access in logs |
| Service availability *(Example)* | Remote access unavailable 3 days for staff | High | Service records |
| Financial *(Example)* | [Response costs, legal, notification, lost revenue] | Medium | Finance estimate |
| Third parties *(Example)* | None identified | Medium | Partner review |
| Cross-border effect *(Example)* | Customers in [n] EU Member States | High | Customer database |

## 6. Evidence and chain of custody

<!-- Guidance: Record what was collected, by whom, where it is stored and its hash, so it can support legal action, insurance claims and regulators. Collect volatile evidence before rebuilding systems. Pitfall: wiping a system to restore service before imaging it. -->

| Evidence ID | Item | Collected by | Date and time (UTC) | Hash (SHA-256) | Storage location | Custody transfers |
|---|---|---|---|---|---|---|
| EV-001 *(Example)* | Memory image of appliance | [@forensic-analyst] | 2026-09-14 11:10 | [hash] | Evidence store, case [ID] | None |
| EV-002 *(Example)* | Disk image of FS-02 | [@forensic-analyst] | 2026-09-14 13:00 | [hash] | Evidence store | Shared with external forensic firm 2026-09-15 |
| EV-003 *(Example)* | Proxy and directory log export 2026-09-13 to 2026-09-15 | [@soc-analyst] | 2026-09-14 12:00 | [hash] | Evidence store | None |
| [EV-NNN] | [Item] | [@name] | [Time] | [Hash] | [Location] | [Transfers] |

Retention: keep evidence for [period], aligned with legal advice and any litigation hold. For the full custody record of each item, use the Forensic Evidence Record (`security/forensic-evidence-record`).

## 7. Analysis and root cause

<!-- Guidance: Explain how the attack worked and why controls did not stop it. Map techniques to MITRE ATT&CK for shared language. Ask "why" until you reach causes you can fix in process, technology and governance. Pitfall: stopping at "human error" or "zero-day". -->

### 7.1 Attack path

| Stage | ATT&CK technique | Observation |
|---|---|---|
| Initial access | T1190 Exploit Public-Facing Application *(Example)* | Vulnerability published [n] days before, patch not applied |
| Privilege use | T1078 Valid Accounts *(Example)* | Service account with standing rights to the file share |
| Collection | T1560 Archive Collected Data *(Example)* | Archive created on FS-02 |
| Exfiltration | T1048 Exfiltration Over Alternative Protocol *(Example)* | Transfer to external host not blocked by egress rules |

### 7.2 Root cause and contributing factors

| ID | Factor | Type | Evidence |
|---|---|---|---|
| RC-001 *(Example)* | No patching service level for internet-facing appliances; patch waited for a monthly window | Root cause (process) | Change calendar |
| RC-002 *(Example)* | Service account had standing read rights to all shares | Contributing (access design) | Directory export |
| RC-003 *(Example)* | Egress filtering allowed direct outbound transfers from servers | Contributing (network) | Firewall rules |
| RC-004 *(Example)* | Appliance logs not in the SIEM, so the exploit went unseen for 5 hours 30 minutes | Contributing (detection) | Logging inventory |

## 8. Response actions

<!-- Guidance: Record containment, eradication and recovery actions with times and owners, and any decision to accept risk. SP 800-61 Rev. 3 places these under the CSF 2.0 Respond and Recover functions. Pitfall: declaring recovery before the access path and credentials are fixed. -->

| ID | Phase | Action | Owner | Started (UTC) | Completed (UTC) |
|---|---|---|---|---|---|
| ACT-001 *(Example)* | Containment | Isolate appliance; disable svc-backup | [@network-lead] | 2026-09-14 11:00 | 2026-09-14 11:30 |
| ACT-002 *(Example)* | Containment | Block attacker infrastructure at egress | [@secops] | 2026-09-14 11:15 | 2026-09-14 11:40 |
| ACT-003 *(Example)* | Eradication | Replace and patch appliance; reset privileged and service credentials | [@infrastructure] | 2026-09-15 08:00 | 2026-09-18 18:00 |
| ACT-004 *(Example)* | Eradication | Hunt for persistence across servers (`security/threat-hunting-plan`) | [@threat-hunter] | 2026-09-15 09:00 | 2026-09-18 12:00 |
| ACT-005 *(Example)* | Recovery | Restore remote access with phishing-resistant MFA; heightened monitoring for 30 days | [@service-owner] | 2026-09-19 09:00 | 2026-09-20 14:00 |

## 9. Notifications and reporting clocks

<!-- Guidance: List every regime that may apply, its trigger, recipient and clock, then compute deadlines from section 3. Confirm applicability with counsel. Dates and clocks below were checked on 2026-10-30; laws change, so check the current official text. Pitfall: assuming one notification satisfies every regime. -->

### 9.1 Regimes to consider

| Regime (dated example) | Trigger and recipient (summary) | Clock (summary) | Applies? |
|---|---|---|---|
| EU GDPR, Regulation (EU) 2016/679, Articles 33 and 34; UK GDPR | Personal data breach: supervisory authority (ICO in the UK); individuals if high risk | Authority without undue delay and where feasible within 72 hours of awareness; individuals without undue delay | [Yes / No] |
| EU NIS2, Directive (EU) 2022/2555, Article 23 | Significant incident at an essential or important entity: CSIRT or competent authority, as transposed nationally | Early warning within 24 hours of awareness; incident notification within 72 hours; final report within one month of the notification | [Yes / No] |
| EU DORA, Regulation (EU) 2022/2554, Article 19, and Delegated Regulation (EU) 2025/301 | Major ICT-related incident at a financial entity: competent authority | Initial within 4 hours of classification and at most 24 hours of awareness; intermediate within 72 hours of the initial; final within one month of the latest intermediate | [Yes / No] |
| EU Cyber Resilience Act, Regulation (EU) 2024/2847, Article 14 (reporting since 11 September 2026) | Manufacturer: actively exploited vulnerability or severe incident affecting product security, through the ENISA Single Reporting Platform | Early warning 24 hours; notification 72 hours; final report 14 days after a fix is available (vulnerability) or one month after the notification (severe incident) | [Yes / No] |
| US SEC, Form 8-K Item 1.05 | Material cybersecurity incident at a registrant: public filing | Generally within four business days after determining materiality | [Yes / No] |
| US CIRCIA | Covered critical infrastructure entities: CISA | Proposed 72 hours (incidents) and 24 hours (ransom payments); not in force until CISA's final rule takes effect (not published as of 2026-10-30) | [Monitor] |
| US state breach laws, sector rules (for example HIPAA) | Defined personal or health information | Varies; check each law | [States or sectors] |
| Contracts, cyber insurance, card schemes | As written | As written | [List] |

### 9.2 Deadlines for this incident

| Regime | Clock starts (UTC) | Deadline (UTC) | Submitted (UTC) | Reference | Met? |
|---|---|---|---|---|---|
| NIS2 early warning *(Example)* | 2026-09-14 10:15 | 2026-09-15 10:15 | 2026-09-15 09:30 | [Portal receipt] | Yes, 45 minutes to spare |
| NIS2 incident notification *(Example)* | 2026-09-14 10:15 | 2026-09-17 10:15 | 2026-09-16 16:30 | [Receipt] | Yes |
| GDPR Article 33 notification *(Example)* | 2026-09-14 10:15 | 2026-09-17 10:15 | 2026-09-16 16:30 | [Reference] | Yes |
| GDPR Article 34 communication *(Example)* | High risk assessed 2026-09-16 | Without undue delay | 2026-09-18 | [Mail log] | Yes |
| NIS2 final report *(Example)* | 2026-09-16 16:30 (notification) | 2026-10-16 16:30 | [YYYY-MM-DD HH:MM] | [Receipt] | [Yes / No] |
| Cyber insurer *(Example)* | Policy terms | [As per policy] | 2026-09-14 15:00 | [Claim number] | Yes |

## 10. Communications

<!-- Guidance: Record who was told what and when, inside and outside. Use pre-approved templates where possible (`dev/incident-communication`). Pitfall: public statements that contradict regulator notifications. -->

| Audience | Channel | Message owner | Time (UTC) | Key content |
|---|---|---|---|---|
| Executive team *(Example)* | Bridge and written brief | [@ciso] | 2026-09-14 09:30 | Status, risk, decisions needed |
| Staff *(Example)* | Intranet | [@comms-lead] | 2026-09-14 14:00 | Remote access outage, phishing warning |
| Affected customers *(Example)* | Email | [@dpo] | 2026-09-18 | What happened, data involved, steps to take, contact point |
| Media *(Example)* | Holding statement on request | [@comms-lead] | Prepared 2026-09-15 | Approved by legal |
| Law enforcement *(Example)* | Report to national cybercrime unit | [@legal-counsel] | 2026-09-15 | Case reference |

## 11. Lessons learned by CSF 2.0 function

<!-- Guidance: SP 800-61 Rev. 3 ties incident response to all six CSF 2.0 functions. Ask what went well and what to improve for each one. Hold the review within [10] working days of recovery, blameless and with evidence. Pitfall: lessons only for Respond, when the root cause sits in Govern, Identify or Protect. -->

| Function | What went well | What to improve | Action IDs |
|---|---|---|---|
| Govern (GV) | *Example:* Incident lead had clear authority to isolate systems | No owner for appliance risk at board level | CA-005 |
| Identify (ID) | *Example:* Asset inventory listed the appliance | Vulnerability was not prioritised as known exploited | CA-001 |
| Protect (PR) | *Example:* Payment data out of scope by design | Standing service account rights; no egress allow-list | CA-002, CA-003 |
| Detect (DE) | *Example:* EDR detected collection 45 minutes after archive creation | Appliance logs missing from the SIEM | CA-004 |
| Respond (RS) | *Example:* All notifications on time | Early warning sent with only 45 minutes to spare; pre-fill portal data | CA-006 |
| Recover (RC) | *Example:* Recovery with stronger MFA | Recovery communication to staff late | CA-006 |

## 12. Corrective actions

<!-- Guidance: Each action fixes a root cause or contributing factor, has an owner, a date and a way to verify it. Track them in the risk register until closed. Pitfall: actions such as "be more careful" that cannot be verified. -->

| ID | Action | Addresses | Owner | Due | Verification | Status |
|---|---|---|---|---|---|---|
| CA-001 *(Example)* | Patch internet-facing appliances for known exploited vulnerabilities within [72] hours | RC-001 | [@infrastructure-lead] | YYYY-MM-DD | Monthly compliance report | [Open] |
| CA-002 *(Example)* | Replace standing service account rights with just-in-time access | RC-002 | [@iam-lead] | YYYY-MM-DD | Access review | [Open] |
| CA-003 *(Example)* | Default-deny egress for servers | RC-003 | [@network-lead] | YYYY-MM-DD | Firewall rule review | [Open] |
| CA-004 *(Example)* | Onboard appliance logs to the SIEM with detection rules (`security/detection-rule-spec`) | RC-004 | [@soc-lead] | YYYY-MM-DD | Test alert | [Open] |
| CA-005 *(Example)* | Add edge device risk to the risk register with a named owner | Govern gap | [@risk-officer] | YYYY-MM-DD | Register entry | [Open] |
| CA-006 *(Example)* | Pre-filled regulator templates and a tabletop exercise on the clocks (`security/tabletop-exercise`) | Respond and Recover gaps | [@incident-lead] | YYYY-MM-DD | Exercise report | [Open] |

## 13. Metrics and closure

<!-- Guidance: Compute metrics from the timeline; keep definitions stable so incidents can be compared. Close the record only when notifications are complete and corrective actions are tracked elsewhere. -->

| Metric | Definition | Value *(Example)* |
|---|---|---|
| Dwell time | First malicious activity to detection | 5 hours 30 minutes |
| Time to declare | Detection to declaration | 1 hour 10 minutes |
| Time to contain | Detection to containment | 3 hours 50 minutes |
| Awareness to containment | Awareness to containment | 1 hour 15 minutes |
| Time to recover | Detection to recovery complete | 6 days 6 hours 20 minutes |
| Notifications on time | Notifications met / notifications due | 5 of 5 so far (NIS2 final report pending) |

Closure criteria: [all required notifications sent, including final reports; evidence retained; corrective actions in the risk register; lessons learned review held]. Closed by [@ciso] on YYYY-MM-DD.

## 14. Glossary and references

<!-- Guidance: Define the terms that decide legal clocks, and keep references dated. -->

### 14.1 Glossary

| Term | Meaning |
|---|---|
| Event | An observable occurrence in a system or network |
| Incident | An occurrence that jeopardises the confidentiality, integrity or availability of information or systems, or violates security policy |
| Awareness | The moment the organisation has a reasonable degree of certainty that a reportable incident occurred; the start of most clocks |
| Dwell time | Time an attacker was present before detection |
| Personal data breach | A breach of security leading to destruction, loss, alteration, unauthorised disclosure of, or access to, personal data (GDPR Article 4(12), paraphrased) |
| Significant incident | NIS2 term for an incident causing or able to cause severe operational disruption or financial loss, or considerable damage to others |

### 14.2 References

| Reference | Version or date | Use |
|---|---|---|
| NIST SP 800-61 Rev. 3, https://csrc.nist.gov/pubs/sp/800/61/r3/final | April 2025 (supersedes Rev. 2, 2012) | Incident response as a CSF 2.0 Community Profile |
| NIST Cybersecurity Framework (CSF) 2.0 | February 2024 | Six functions and categories in section 11 |
| Regulation (EU) 2016/679 (GDPR), Articles 4(12), 33 and 34; UK GDPR and ICO guidance (page updated 28 May 2025, under review after the Data (Use and Access) Act 2025) | Consolidated text | Personal data breach notification |
| Directive (EU) 2022/2555 (NIS2), Article 23; Commission targeted amendment proposal of 20 January 2026 | Check national transposition and amendment status | Significant incident reporting |
| Regulation (EU) 2022/2554 (DORA), Article 19; Delegated Regulation (EU) 2025/301 | Applies since 17 January 2025 | Major ICT incident reporting |
| Regulation (EU) 2024/2847 (CRA), Article 14; Commission CRA reporting page, https://digital-strategy.ec.europa.eu/en/policies/cra-reporting | Reporting since 11 September 2026 | Manufacturer reporting |
| SEC Release 33-11216, Form 8-K Item 1.05 (sec.gov press release 2023-139) | Compliance from 18 December 2023 | Public company disclosure |
| CISA, Cyber Incident Reporting for Critical Infrastructure Act (CIRCIA) page | NPRM 4 April 2024; final rule pending | Future US reporting |
| MITRE ATT&CK, https://attack.mitre.org | Current version | Technique IDs and names in section 7.1, used with attribution |

## Standard and licence note

Based on NIST SP 800-61 Rev. 3 (April 2025) and the NIST Cybersecurity Framework 2.0, works of the US Government, and on the EU and UK legal texts and US rules listed in section 14.2, which are summarised in original wording with article numbers only. MITRE ATT&CK technique IDs and names are used with attribution to The MITRE Corporation. The structure, tables and fictional example are original text written for this collection. Reporting clocks were checked on 2026-10-30 and change with new laws, delegated acts and national transposition: check the current official texts and a qualified professional before deciding on any notification. This is a documentation format, not legal advice. Template licence: MIT.