Incident Register Template (ISO/IEC 27001 A.5.24 to A.5.28)

Event and incident register: field rules, category and regime codes, register rows, GDPR, NIS2 and DORA notification tracking, status lifecycle, period summary

ISMS & ISO/IEC 27001StandardISO/IEC 27001:2022 + Amd 1:2024 A.5.24 to A.5.28, A.6.8 (cited only); ISO/IEC 27035-1:2023incident registerUpdated Nov 1, 2026

Open in editorDownload .md

How to use: Use it from the day the incident response plan is approved to log every event, near miss and incident from report to closure. Fill the field rules and code lists first, then add a row per record with the awareness time and regulatory flags. The main pitfall is a register that holds only the big incidents, which auditors detect by comparing it with tickets and reports.

Preview

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.

Document control

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]

Field rules
Code lists
Register
Regulatory notification tracking
Status lifecycle
Period summary
Size tiers
Records and evidence
References

1. Field rules

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

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

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

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

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

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

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

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

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.

Related templates

ISMS & ISO/IEC 27001