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.
Document control
| 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
1. Summary
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
| 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
| 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
| 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 |
5. Scope and impact
| 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
| 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
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
| 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
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
| 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
| 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
| 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
| 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
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.