# Incident Register: [Organization name]

> The single register of information security events and incidents: one
> row per record from first report to closure, with dates, category,
> severity, impact on confidentiality, integrity and availability,
> personal data involvement, regulatory notification flags and clocks,
> status, and the link to the post-incident review. It is the main
> record for ISO/IEC 27001:2022 + Amd 1:2024 Annex A controls A.5.24 to
> A.5.28 and feeds clause 9.1 and 10.2. Replace every `[bracketed]` value
> and every row marked *Example*. The regulatory deadlines shown are
> international examples; this is a documentation format, not legal
> advice.

<!--
Guidance: How to use this template
- Use it from the day the incident response plan is approved. Every
  event that triage does not close as harmless gets a row, so the
  register also shows near misses and events that never became
  incidents.
- Fill first: the field rules in section 1 and the code lists in
  section 2, then add rows in section 3 as events arrive from
  `isms/security-event-reporting-procedure` (DOC-ISMS-023).
- Main pitfall: a register that holds only the big incidents. Auditors
  compare the register with tickets, alerts and staff reports; missing
  small items suggest the process is not used.
- The worked rows describe Quillmere Health Systems (medium tier), a
  processor for hospitals and a managed service provider.
- Related templates: `compliance/incident-response-plan` (DOC-ISMS-020),
  `isms/post-incident-review` (DOC-ISMS-022),
  `ops/incident-severity-matrix`,
  `compliance/personal-data-breach-assessment`,
  `compliance/nis2-security-measures`,
  `compliance/dora-major-incident-report`,
  `isms/control-evidence-matrix` (DOC-ISMS-033).
-->

## Document control

<!-- Guidance: The register is a living record. Version it when the field rules change and archive a closed copy at year end. Restrict access: rows can describe weaknesses and personal data. -->

| Field | Value |
|---|---|
| Document ID | DOC-ISMS-021 |
| Version | [2027.1] |
| Status | [Open register / Closed for year YYYY] |
| Owner | [@security-operations-lead] |
| Approvers/reviewers | [@isms-manager], [@privacy-lead] |
| Last updated | YYYY-MM-DD |
| Classification | [Confidential] |
| Standard and edition | ISO/IEC 27001:2022 + Amd 1:2024 (A.5.24 to A.5.28, A.6.8); ISO/IEC 27035-1:2023 |
| Governing plan | [Incident response plan DOC-ISMS-020] |
| Severity scale | [SEV1 (most severe) to SEV4, from `ops/incident-severity-matrix`] |
| Register period | [2027-01-01 to 2027-12-31] |
| Next scheduled review | YYYY-MM-DD |

### Approvals

| Role | Name | Decision | Date |
|---|---|---|---|
| Register owner | [@security-operations-lead] | [Field rules issued] | YYYY-MM-DD |
| ISMS manager | [@isms-manager] | [Approved / Year closed] | YYYY-MM-DD |

### Revision history

| Version | Date | Author | Change |
|---|---|---|---|
| 2027.1 | YYYY-MM-DD | [@owner] | Register opened for 2027 |
| [x.y] | YYYY-MM-DD | [@author] | [Change summary] |

## Contents

1. [Field rules](#1-field-rules)
2. [Code lists](#2-code-lists)
3. [Register](#3-register)
4. [Regulatory notification tracking](#4-regulatory-notification-tracking)
5. [Status lifecycle](#5-status-lifecycle)
6. [Period summary](#6-period-summary)
7. [Size tiers](#7-size-tiers)
8. [Records and evidence](#8-records-and-evidence)
9. [References](#9-references)

## 1. Field rules

<!-- Guidance: Define each field once so every analyst records the same way. Times in UTC. Pitfall: no awareness time, which makes every legal clock impossible to prove later. -->

| Field | Rule |
|---|---|
| Record ID | INC-YYYY-NNN, never reused; corrections are new rows that cite the old ID |
| Type | Event (assessed, not an incident), Near miss, or Incident |
| Occurred | Earliest known time of unauthorised activity (for example the first unauthorised access), updated as facts emerge |
| Detected | First time the organisation had a signal (alert, report, notice from a third party) |
| Awareness (T0) | Time the organisation had a reasonable degree of certainty that an incident (or personal data breach) occurred; normally the declaration time. Legal clocks run from awareness, so do not let a late formal declaration move T0. For DORA, also record the time the incident was classified as major, because the 4-hour clock starts there |
| Closed | Date the record was closed under section 5 |
| Category | Code from section 2.1, aligned with the incident response plan categories |
| Severity | SEV1 to SEV4 from the severity matrix; record each change with the reason |
| CIA impact | C, I, A, or a combination, with a short description |
| Personal data | Yes or No; if Yes, data categories, approximate number of people and our role (controller or processor) |
| Regulatory flags | Each regime assessed (section 4) with the outcome: Notify, Not required (with reason) or Not in scope |
| Assets | Asset IDs from `compliance/asset-inventory` (DOC-ISMS-012) |
| Owner | The incident commander or analyst accountable for the record |
| Status | Value from section 5 |
| Review link | Post-incident review ID (PIR-YYYY-NNN) or "not required" with the rule applied |
| Evidence | Ticket, evidence record and breach assessment references |

## 2. Code lists

<!-- Guidance: Keep codes identical to the incident response plan, so register statistics and playbooks line up. -->

### 2.1 Categories

| Code | Category |
|---|---|
| CAT-01 | Malware or ransomware |
| CAT-02 | Account or credential compromise |
| CAT-03 | Data exfiltration or unauthorised disclosure |
| CAT-04 | Business email compromise or payment fraud |
| CAT-05 | Denial of service |
| CAT-06 | Exploited vulnerability in our product |
| CAT-07 | Third-party or supply chain compromise |
| CAT-08 | Insider misuse |
| CAT-09 | Cloud resource misuse or key leak |
| CAT-10 | Other or unknown, including lost or stolen equipment |

### 2.2 Regulatory regimes to assess *(international examples)*

| Code | Regime | Typical trigger and clock *(check the current text and national law)* |
|---|---|---|
| REG-GDPR | GDPR (Regulation (EU) 2016/679) | Controller: notify the supervisory authority without undue delay and, where feasible, within 72 hours of awareness unless the breach is unlikely to result in a risk (Art. 33); inform individuals when the risk is high (Art. 34). Processor: inform the controller without undue delay (Art. 33(2)). Document every personal data breach, notified or not (Art. 33(5)) |
| REG-NIS2 | NIS2 (Directive (EU) 2022/2555), as transposed nationally | Significant incident: early warning without undue delay and within 24 hours of awareness, incident notification within 72 hours of awareness, intermediate report if the CSIRT or authority asks, final report within one month of the incident notification; a progress report instead if the incident is still ongoing then (Art. 23(4)(a) to (e)) |
| REG-DORA | DORA (Regulation (EU) 2022/2554) | Major ICT-related incident at a financial entity (Art. 19, time limits in Delegated Regulation (EU) 2025/301 Art. 5): initial notification within 4 hours of classification as major and no later than 24 hours of awareness; intermediate report within 72 hours of the initial notification; final report within one month of the latest intermediate report. Weekend and holiday relief does not apply to every entity; see section 10 of `compliance/incident-response-plan` |
| REG-US | US state breach laws and sector rules | Clocks and thresholds vary by state and sector; record the rule assessed by name |
| REG-CONTRACT | Customer contracts and data processing agreements | Contractual notice period, for example 24 or 48 hours to the customer |

## 3. Register

<!-- Guidance: One row per record. Keep the row short and put detail in the ticket. Never delete a row; mark it as an error with a reason instead. Auditors sample rows and trace them to tickets, breach assessments and reviews. -->

| Record ID | Type | Occurred (UTC) | Detected (UTC) | Awareness T0 (UTC) | Category | Severity | CIA | Personal data | Regulatory flags | Owner | Status | Closed | Review link |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| INC-2027-001 *(Example)* | Incident | 2027-01-08 17:31 | 2027-01-09 07:50 | 2027-01-09 10:05 | CAT-02 | SEV3 | C | Yes: hospital staff names and work contacts, 23 people, processor | REG-GDPR processor: Notify controllers; REG-NIS2: Not required (not significant); REG-CONTRACT: Notify | [@security-operations-lead] | Closed | 2027-01-12 | PIR-2027-001 |
| INC-2027-002 *(Example)* | Incident | 2027-01-21 18:00 | 2027-01-22 08:30 | 2027-01-22 09:00 | CAT-10 | SEV4 | C | Possible: laptop of a project manager, full-disk encrypted | REG-GDPR controller: Not required (encrypted, key not exposed), documented under Art. 33(5) | [@it-lead] | Closed | 2027-01-23 | Not required (SEV4, known cause) |
| INC-2027-003 *(Example)* | Incident | 2027-02-14 09:55 | 2027-02-14 10:02 | 2027-02-14 10:20 | CAT-05 | SEV2 | A | No | REG-NIS2: Notify (significant, managed service in scope under national law); REG-CONTRACT: Notify | [@incident-commander] | Closed | 2027-02-18 | PIR-2027-002 |
| INC-2027-004 *(Example)* | Incident | 2027-03-03 14:12 | 2027-03-03 15:40 | 2027-03-03 16:00 | CAT-03 | SEV3 | C | Yes: appointment list with patient names, 61 people, processor | REG-GDPR processor: Notify controller; REG-CONTRACT: Notify | [@privacy-lead] | Closed | 2027-03-10 | PIR-2027-003 |
| INC-2027-005 *(Example)* | Event | 2027-03-11 11:20 | 2027-03-11 11:20 | Not declared | CAT-01 | None | None | No | None | [@security-analyst] | Closed | 2027-03-11 | Not required (malware blocked by EDR) |
| INC-2027-006 *(Example)* | Incident | 2027-03-24 (supplier notice) | 2027-03-27 09:00 | 2027-03-27 11:30 | CAT-07 | SEV3 | C | Under assessment: support ticket attachments held by a SaaS supplier | REG-GDPR: Assessing; REG-CONTRACT: Assessing | [@isms-manager] | Investigating | | Planned |

## 4. Regulatory notification tracking

<!-- Guidance: One row per regime per incident that needs a notice. Compute deadlines from the awareness time and record the actual submission time and reference. Pitfall: deadline computed from closure, or from the time legal was consulted. -->

| Track ID | Record ID | Regime and step | Recipient | Deadline (UTC) | Submitted (UTC) | Reference | Owner |
|---|---|---|---|---|---|---|---|
| NTF-2027-001 *(Example)* | INC-2027-001 | REG-GDPR processor notice | Two hospital customers (controllers) | Without undue delay; contract 24 h: 2027-01-10 10:05 | 2027-01-09 17:10 | [Customer case refs] | [@privacy-lead] |
| NTF-2027-002 *(Example)* | INC-2027-003 | REG-NIS2 early warning (24 h) | [National CSIRT or competent authority] | 2027-02-15 10:20 | 2027-02-14 18:05 | [CSIRT case number] | [@reporting-owner] |
| NTF-2027-003 *(Example)* | INC-2027-003 | REG-NIS2 incident notification (72 h) | [National CSIRT or competent authority] | 2027-02-17 10:20 | 2027-02-16 15:00 | [CSIRT case number] | [@reporting-owner] |
| NTF-2027-004 *(Example)* | INC-2027-003 | REG-NIS2 final report (1 month after notification) | [National CSIRT or competent authority] | 2027-03-16 15:00 | 2027-03-12 10:30 | [CSIRT case number] | [@reporting-owner] |
| NTF-2027-005 *(Example)* | INC-2027-004 | REG-GDPR processor notice | One hospital customer (controller) | Without undue delay; contract 24 h: 2027-03-04 16:00 | 2027-03-03 18:20 | [Customer case ref] | [@privacy-lead] |
| NTF-2027-006 *(Example)* | INC-2027-003 | REG-CONTRACT service incident notice | Hospital customers of the managed service | Contract 24 h: 2027-02-15 10:20 | 2027-02-14 12:30 | [Customer case refs] | [@service-delivery-lead] |

In the *Example*, INC-2027-003 has awareness at 2027-02-14 10:20 UTC, so
the 24-hour point is 2027-02-15 10:20 and the 72-hour point is
2027-02-17 10:20. The final report is due one month after the incident
notification submitted on 2027-02-16 15:00, which is 2027-03-16 15:00.
Contacts for each authority come from
`isms/authority-special-interest-contacts` (DOC-ISMS-069).

## 5. Status lifecycle

<!-- Guidance: Use these statuses only. Closing requires the conditions in the table, including the review decision. -->

```mermaid
stateDiagram-v2
  [*] --> Reported
  Reported --> Triage
  Triage --> Closed: event or near miss, reason recorded
  Triage --> Investigating: incident declared, T0 recorded
  Investigating --> Contained
  Contained --> Recovering
  Recovering --> Review: review rule applies
  Recovering --> Closed: review not required, reason recorded
  Review --> Closed: review approved, actions tracked
  Closed --> [*]
```

| Status | Exit condition |
|---|---|
| Reported | Report logged with time and channel |
| Triage | Outcome recorded: event, near miss or incident |
| Investigating | Scope known; severity confirmed or changed with reason |
| Contained | Attacker access or spread stopped; evidence preserved |
| Recovering | Service and data restored and verified by the owner |
| Review | Post-incident review in `isms/post-incident-review` approved |
| Closed | Notifications complete, actions in the CAPA register, register row checked by the owner |

## 6. Period summary

<!-- Guidance: Compute monthly or quarterly from the register and send it to the ISMS performance report and management review. Recompute before every report. -->

*Example*, Q1 2027 (rows in section 3):

| Measure | Value |
|---|---|
| Records | 6 (5 incidents, 1 event) |
| Incidents by severity | SEV1: 0, SEV2: 1, SEV3: 3, SEV4: 1 |
| Incidents with personal data involved or under assessment | 4 (INC-2027-001, 002, 004, 006) |
| Notifications made | 6 (two GDPR processor notices that also met the contract clock, three NIS2 steps, one contractual service notice) |
| Notifications on time | 6 of 6 (100%) |
| Reviews held or planned | 4 (PIR-2027-001 to 003 approved, one planned for INC-2027-006) |
| Open at period end | 1 (INC-2027-006) |

## 7. Size tiers

<!-- Guidance: Keep the register proportionate. These tiers are the library's working tiers, not official definitions. -->

| Aspect | Small: Quillmere Analytics Ltd (46 staff) | Medium: Quillmere Health Systems (320 staff) | Large: Quillmere Group (2,400 staff, 6 sites) |
|---|---|---|---|
| Tool | This table in the ISMS document store, linked to tickets | Incident module of the IT service tool, exported monthly to this format | Group case management with one view per site and an OT category set for the 3 plants |
| Records per year *(Example)* | 10 to 20 | 40 to 80 | Several hundred, rolled up quarterly by the CISO office |
| Regulatory flags | GDPR processor notices to customers; contract clocks | GDPR in both roles, NIS2 as a managed service provider, hospital contracts | GDPR, NIS2 in several countries, sector rules per site |
| Register owner | Head of Engineering Operations (0.5 FTE ISMS manager) | Security operations lead in the 3-person security team | Group SOC lead, with site security coordinators |

## 8. Records and evidence

<!-- Guidance: List the register in `isms/control-evidence-matrix` (DOC-ISMS-033) against A.5.24 to A.5.28 and A.6.8. Keep retention long enough to answer a regulator after the certification cycle. -->

| Record | Owner | Location *(Example)* | Retention *(Example)* |
|---|---|---|---|
| This register (yearly closed versions) | Register owner | ISMS document store | Certification cycle plus 1 year (at least 4 years); longer where law requires |
| Personal data breach documentation (GDPR Art. 33(5)) | Privacy lead | `compliance/personal-data-breach-assessment` records | As set by the privacy retention schedule |
| Notification submissions and receipts | Reporting owner | Notification folder per incident | Same as the register |
| Post-incident reviews | ISMS manager | `isms/post-incident-review` documents | Same as the register |
| Evidence and chain of custody | Security operations lead | `security/forensic-evidence-record` | Per legal hold or evidence rule |

## 9. References

<!-- Guidance: Check each regulation's current text and national transposition before relying on a clock. -->

- ISO/IEC 27001:2022 + Amd 1:2024: https://www.iso.org/standard/82875.html
  and https://www.iso.org/standard/88435.html
- ISO/IEC 27002:2022: https://www.iso.org/standard/75652.html
- ISO/IEC 27035-1:2023: https://www.iso.org/standard/78973.html
- NIST SP 800-61 Rev. 3 (April 2025)
- GDPR, Regulation (EU) 2016/679, Art. 33 and 34; NIS2, Directive (EU)
  2022/2555, Art. 23; DORA, Regulation (EU) 2022/2554
- Related templates: `compliance/incident-response-plan` (DOC-ISMS-020),
  `isms/post-incident-review` (DOC-ISMS-022),
  `isms/security-event-reporting-procedure` (DOC-ISMS-023),
  `isms/authority-special-interest-contacts` (DOC-ISMS-069),
  `ops/incident-severity-matrix`, `compliance/capa-nonconformity`,
  `isms/control-evidence-matrix` (DOC-ISMS-033)

## Standard and licence note

Structure aligned with ISO/IEC 27001:2022 + Amd 1:2024 (Annex A controls
A.5.24 to A.5.28 and A.6.8) and ISO/IEC 27035-1:2023. Control numbers are
cited only; no ISO or IEC text is reproduced, and you need the official
standards to implement and audit the controls. Regulatory clocks are
summarised in original wording as international examples and are not
legal advice. The field rules and worked rows are original. Check the
current editions and legal texts before use.

Template licence: MIT.