Incident governance

Scope: one incident process, event to verified closure · Who: the officer who owns that process · Prerequisites: an incident record and the regimes in scope · First result: the regime map

1. Why this exists (the failure mode it prevents)#

Incidents get handled better than they get governed. The response works. The record of what was decided, by whom, and what changed afterwards does not.

Four moves recur. The fix is applied and the cause is never examined, so the same incident returns. A clock is discovered after it ran out, because nobody classified the event against the criteria that start it. The review becomes an account of who did what. Corrective action is recorded as a single word: fixed.

Each move surfaces predictably. A missed early warning shows in the timestamps, because the clock runs from becoming aware of the significant incident, not from the decision to report ¹. An assessor asking for evidence of learning wants a record: the control expects knowledge from incidents to be used to strengthen and improve controls ². Where no corrective-action record exists, the four acts the management system asks for cannot be shown ³.

This is governance, not a runbook. It extends the finding-to-closure discipline of Running the external audit, section 3.9, to incidents.

2. Definitions (only the ones that cause disputes)#

Requirement text from the licensed standard is paraphrased; only numbers and titles are cited. Regulation wording is described as printed.

Term	Working definition	Source
Event and incident	An event is observed. An incident is an event the organisation has assessed and decided to categorise as one. In NIS2 an incident is an event compromising availability, authenticity, integrity or confidentiality of data or services.	ISO/IEC 27002:2022 control 5.25 4; Directive (EU) 2022/2555 Art. 6(6) 5
Significant incident	One that has caused or is capable of causing severe operational disruption of the services or financial loss for the entity, or of affecting others by causing considerable material or non-material damage.	Directive (EU) 2022/2555 Art. 23(3) 6
Major ICT-related incident	An ICT-related incident with a high adverse impact on the systems behind the entity's critical or important functions.	Regulation (EU) 2022/2554 Art. 3(10) 7
Personal data breach	A breach of security leading to accidental or unlawful destruction, loss, alteration, unauthorised disclosure of, or access to, personal data transmitted, stored or otherwise processed.	Regulation (EU) 2016/679 Art. 4(12) 8
Root cause and contributing factor	Not a defined term. The root cause is the condition whose removal stops recurrence. A contributing factor made the incident worse or later to detect, and earns an action of its own.	Working distinction; the acts it feeds sit at ISO/IEC 27001:2022 clause 10.2 3
Correction and corrective action	Working distinction: correction deals with the detected instance; corrective action removes the cause. The management system separates reacting, examining the cause, acting on the cause, and reviewing effectiveness.	ISO/IEC 27001:2022 clause 10.2 3
The reporting clock	The interval between a defined start point and a statutory deadline. Under NIS2 the start is becoming aware of the significant incident, which is why awareness is recorded in its own right.	Directive (EU) 2022/2555 Art. 23(4) 1

3. The method — numbered steps, each with input, activity, output and owner#

Ten steps, in the order an incident imposes them.

3.1 One process, many regimes#

An organisation rarely sits under one reporting duty, and a process per regime lets the slowest set the pace. Run one, and let a regime map decide which duties an incident opens. The control set expects this: external reporting requirements within a defined time frame are considered when incident procedures are implemented ⁹.

Regime	What triggers the duty	Who receives it	The clocks
NIS2 — Directive (EU) 2022/2555	An incident with a significant impact on service provision, per the two-part test 10	The CSIRT or the competent authority; service recipients likely to be adversely affected, where appropriate 11	Early warning 24 hours from awareness, notification 72 hours, final report one month; intermediate report on request (Art. 23(4)(c)) after that notification 1
GDPR — Regulation (EU) 2016/679	A personal data breach, unless unlikely to result in a risk to the rights and freedoms of natural persons 12	The supervisory authority; the data subject where a high risk is likely 13	Without undue delay and, where feasible, within 72 hours of awareness; a later one carries reasons for the delay 12
DORA — Regulation (EU) 2022/2554	A major ICT-related incident, classified against six impact criteria 14	The relevant competent authority 15	Initial notification, intermediate report, final report once root cause analysis is done; clocks in RTS 2025/301, see the DORA playbook 16
CRA — Regulation (EU) 2024/2847	An actively exploited vulnerability, or a severe incident affecting product security 17	The CSIRT designated as coordinator and ENISA, via the single reporting platform 18	Early warning 24 hours, notification 72 hours, final report on a track-dependent deadline 19

That CRA deadline differs by track. It is 14 days from a corrective or mitigating measure becoming available for a vulnerability, and one month from the 72-hour notification for a severe incident ¹⁹. Sector detail sits in CRA obligations by product class and DORA implementation.

• Input: the regimes in scope; the service and product inventory.
• Activity: build one row per regime; mark the triggers that can fire together.
• Output: regime map, maintained as a controlled document.
• Owner: the incident process owner; counsel confirms scope.

3.2 Roles and decision rights#

Four decisions carry an incident: is this an incident, how severe is it, does it get reported, and what do outside parties get told. Each needs one accountable role.

The control asks for incident management processes, roles and responsibilities to be defined, established and communicated, with only competent personnel handling incident matters. Objectives are agreed with management, including the resolution time frame implied by consequences and severity ⁹. The management system puts the same duty at clause 5.3 ²⁰, and the framework carries it as a Category outcome ²¹.

Four roles are enough. The incident manager runs the process and owns the record. The incident owner is accountable for the affected service. The reporting decision-maker signs the regulatory call and holds a named deputy, because clocks run at night. Communications owns what reaches recipients and the public. It carries a duty of its own: recipients potentially affected by a significant cyber threat are told what remedies they can take ²².

• Input: the roles matrix; the on-call rota; the delegation rules.
• Activity: name one accountable role per decision, plus a deputy for the reporting call; record their training.
• Output: incident roles and decision-rights table, inside the incident policy.
• Owner: top management approves; the incident manager maintains.

3.3 Detection to declaration#

Declaration is the hinge. Before it there are observations; after it, clocks run and records are mandatory.

Three controls sit either side of it. Personnel need a mechanism to report observed or suspected events through appropriate channels in a timely manner ²³. Networks, systems and applications are monitored for anomalous behaviour, with appropriate actions taken to evaluate potential incidents ²⁴. Logs of activities, exceptions, faults and other relevant events are produced, stored, protected and analysed ²⁵.

Declaration itself is a decision with a scheme behind it. A categorisation and prioritisation scheme is agreed, including the criteria that categorise an event as an incident, and the point of contact assesses each event against it. Results of the assessment and decision are recorded in detail, for later reference and verification ⁴. That is the governance ask, because a declaration without a record is a decision nobody can audit. The framework declares incidents once adverse events meet defined criteria ²⁶. One field decides more than any other: the awareness timestamp, recorded as an observed fact with its source.

• Input: monitoring alerts; reports from personnel; the categorisation scheme.
• Activity: assess each event against the scheme; declare or reject with a reason; stamp awareness.
• Output: declaration record: event, assessment, decision, awareness timestamp, assessor.
• Owner: the point of contact assesses; the incident manager confirms.

3.4 Response governance: the decision log and the evidence#

Response itself is out of scope here. What governs it is not.

Two records carry it. The first is a decision log. Response activities are logged for later analysis, communication follows the need-to-know principle, and escalation happens as required, including crisis management and activation of continuity plans ²⁷. A decision log is narrower than an activity log and more useful afterwards: what was decided, on what information, by which role, and what was rejected. Escalation, categorisation and prioritisation are managed outcomes in the framework too ²⁸.

The second is evidence. Procedures for the identification, collection, acquisition and preservation of evidence are established, allowing for different jurisdictions, so records are complete and untampered ²⁹. The governance question is who decides at declaration whether evidence handling is engaged, because that call cannot be made retrospectively. Preserving investigation records and their provenance is an analysis outcome ³⁰. Two escalation gates belong in the procedure: informing the management body, and activating continuity plans.

• Input: the declaration record; the response procedure; the evidence procedure.
• Activity: log every decision with time, role and basis; make the evidence call at declaration.
• Output: incident decision log; evidence handling record.
• Owner: the incident manager owns the log; the incident owner the service.

3.5 The reporting decision#

This is the decision most often made late and the easiest to make on time. It needs written criteria, a named decision-maker, and drafts already written. Criteria come from the regime map, and most read on capability rather than outcome. The NIS2 test is two-part: severe operational disruption or financial loss for the entity, or considerable material or non-material damage to others ⁶. The CRA test covers effects on a product's ability to protect sensitive or important data or functions, and the introduction or execution of malicious code ³¹. Under GDPR the question inverts, since notification is the default and the exemption is that a risk to rights and freedoms is unlikely ¹².

Pre-drafted submissions turn a deadline into form-filling. The NIS2 early warning indicates whether the incident is suspected of unlawful or malicious acts, or could have cross-border impact. The 72-hour notification adds an initial assessment of severity and impact. The final report carries the likely threat type or root cause and the mitigation applied ¹. A GDPR notification names the nature of the breach, the contact point, the likely consequences and the measures proposed ³².

Notifying is not an admission: the mere act of notification does not subject the entity to increased liability ¹¹. Reporting also buys something back, since the CSIRT or competent authority responds where possible within 24 hours of the early warning ³³. Duties by entity class sit in NIS2 for the security officer.

• Input: the regime map; the declaration record; the draft submissions.
• Activity: run each regime's criteria against the facts; record the decision either way; keep the receipt.
• Output: reporting decision record, covering decisions not to report; timestamped submissions.
• Owner: the named reporting decision-maker, or the deputy.

3.6 Recovery and closure criteria#

Closure is a decision, not an atmosphere. Two questions must be answerable: what had to be true for recovery to start, and what for the incident to end.

The response control is explicit that once an incident has been successfully addressed, it is formally closed and recorded ²⁷. The framework separates the two decisions. Criteria for initiating recovery are applied ³⁴. The end of recovery is declared against criteria, with incident-related documentation completed ³⁵. Recovery communication is a separate outcome again ³⁶.

Write the closure criteria before the incident. Four conditions cover most cases: the service is confirmed restored, containment is permanent or carries a dated plan, reporting duties are discharged or booked, and the review is scheduled.

• Input: the decision log; the recovery criteria; the outstanding reporting duties.
• Activity: test each closure condition and record the result; book the review; move open actions to a register.
• Output: closure record naming the criteria met and the residual actions.
• Owner: the incident owner proposes closure; the incident manager records it.

3.7 The post-incident review#

A review has one purpose: to produce a cause that can be acted on. Three rules make it work. It is blameless, which is a design choice about output rather than a courtesy, because blame produces defended accounts and no usable cause. It is timeboxed and booked at closure, since a review deferred until convenient does not happen. And facts precede interpretation: the log and timeline are read into the room first.

The method matters less than its rigour. Five whys and a causal chain both work, provided the chain ends at a condition the organisation controls. The control asks for post-incident analysis to identify root cause, and for managing weaknesses in controls that caused, contributed to or failed to prevent the incident ²⁷. That is the licence to record contributing factors as findings of their own. What is learned then enhances the incident management plan and identifies recurring incidents and their causes, so the risk assessment is updated ².

• Input: the decision log; the timeline; the closure record; the affected controls.
• Activity: read the facts first; run the cause method to a controllable condition; list contributing factors.
• Output: post-incident review record: timeline, cause, contributing factors, actions, attendees by role.
• Owner: the incident manager facilitates; the incident owner presents the facts.

3.8 Corrective action, verified closed#

An audit finding and an incident cause are the same object: a demonstrated weakness needing a correction, a cause analysis, an action and a verification. The management system separates four acts: react to the nonconformity, examine its cause, act on the cause, and review the effectiveness of what was done ³. NIS2 adds a duty in the same shape, since an entity finding that it does not comply with the risk-management measures takes corrective measures without undue delay ³⁷.

Five fields make an action closable: the cause in the review's own words, the correction applied to the instance, the corrective action that removes it, the owning role, and a dated effectiveness check. A row missing the last field is parked, not closed. The register that carries audit findings carries these rows unchanged: see Findings-to-closure tracker. Corrections are never filed as corrective actions, because the cause survives them.

• Input: the review record; the corrective action register; the risk register.
• Activity: open one row per cause and per contributing factor; separate correction from action.
• Output: corrective action register rows, closed only on evidence and a verification date.
• Owner: the role owning the affected control; the incident manager tracks closure.

3.9 Metrics and the management review input#

Incident data earns its place only when it changes a decision. Procedures are established to quantify and monitor the types, volumes and costs of incidents, and that information identifies recurring or serious incidents and their causes ². Those three are the minimum honest set, and the ones the control names.

The management system is the second consumer. Monitoring, measurement, analysis and evaluation sit at clause 9.1 ³⁸, and review results are recorded at clause 9.3.3 ³⁹. Four figures are enough: incidents declared by category, awareness to declaration, declaration to submission where a duty applied, and corrective actions overdue or closed without a verification date. A fifth is worth more and is rarely produced: incidents whose cause matches an earlier one. Records themselves are governed under the documented-information clause ⁴⁰.

• Input: the incident register; the corrective action register; the review calendar.
• Activity: produce the four figures plus the repeat-cause count; table them at the review.
• Output: incident metrics pack; review minute recording decisions with owners and dates.
• Owner: the incident manager produces; the management system owner tables it.

3.10 Exercising the process#

A process never timed is an assumption. The exercise that matters is the governance one. Give a scenario, start a fictional awareness timestamp, and require three artefacts under time: the declaration record, the reporting decision with its criteria applied, and a draft early warning. Measure two intervals only, awareness to declaration and declaration to a signed draft, because those are what an authority can reconstruct afterwards.

Run it against the tightest clock in scope, usually a 24-hour early-warning duty, and tighter in finance, where the linked DORA playbook recommends rehearsing the four-hour path twice a year: DORA implementation, section 3.6. The incident management plan is expected to consider different scenarios ⁹. Deputies attend, because the roster that matters is the night one.

• Input: the regime map; the roles table; a written scenario naming no real event.
• Activity: run the exercise against the clock; capture both intervals; raise actions for what failed.
• Output: exercise record: scenario, participants by role, intervals, actions raised.
• Owner: the incident manager runs it; the reporting decision-maker takes part.

4. Deliverables#

Six artefacts carry the method. Retention periods are organisational choices, not requirements of any instrument cited here.

Deliverable	Produced by	Format	Retention
Regime map	Step 3.1	controlled document	current, plus superseded versions
Incident classification procedure	Steps 3.2 and 3.3	procedure with the categorisation scheme	current, plus superseded versions
Incident decision log	Step 3.4	per-incident record	the cycle, plus one
Post-incident review record	Step 3.7	record with timeline and cause	the cycle, plus one
Corrective action register	Step 3.8 · template	spreadsheet or register	the cycle, plus one
Exercise record	Step 3.10	record with measured intervals	the cycle

The decision log needs no template file. Nine fields carry it: incident reference, timestamp, decision taken, options rejected, information it rested on, deciding role, escalation gate crossed, clock started, next review point.

5. What the auditor or authority will ask#

An assessor who stays on the policy is being polite. One who takes a single incident from awareness to a verified corrective action is running the real test.

6. Failure modes and how they surface as findings#

The root of all five is the same: response is treated as the deliverable and the record as paperwork about it.

7. Mapping to controls, clauses, framework and regulation#

Control numbers and titles were read from the licensed standard; requirement wording is paraphrased. Clause titles come from the publisher's contents listing. A verified marker appears where a row's clause, Category or article is not already registered above.

Governance element	ISO/IEC 27002:2022 control	ISO/IEC 27001:2022 clause	CSF 2.0 Category	Regulation article	Evidence
Process, roles, plan, channel	5.24 Information security incident management planning and preparation; 6.8 Information security event reporting	5.3 Organizational roles, responsibilities and authorities	Roles, Responsibilities, and Authorities (GV.RR)	NIS2 Art. 21(2)(b) 41	Policy; roles table; contacts
Detection signal	8.15 Logging; 8.16 Monitoring activities	9.1 Monitoring, measurement, analysis and evaluation	Adverse Event Analysis (DE.AE)	DORA Art. 17(3) 42	Logging policy; monitoring records
Declaration recorded	5.25 Assessment and decision on information security events	7.5.3 Control of documented information	Incident Management (RS.MA)	NIS2 Art. 23(3)	Declaration record
Response governed	5.26 Response to information security incidents	8.1 Operational planning and control	Incident Mitigation (RS.MI) 43	DORA Art. 17(2) 44	Decision log
Evidence handled	5.28 Collection of evidence	7.5.3 Control of documented information	Incident Analysis (RS.AN)	GDPR Art. 33(5) 45	Evidence record
Reporting decided	5.24 Information security incident management planning and preparation	5.3 Organizational roles, responsibilities and authorities	Incident Response Reporting and Communication (RS.CO) 46	NIS2 Art. 23(4)	Decision record; submissions
Recovery and closure	5.26 Response to information security incidents	8.1 Operational planning and control 47	Incident Recovery Plan Execution (RC.RP)	DORA Art. 19(4)	Closure record
Learning used	5.27 Learning from information security incidents	10.2 Nonconformity and corrective action	Improvement (ID.IM) 48	NIS2 Art. 21(4)	Review record; register
Effectiveness reviewed	5.27 Learning from information security incidents	9.3.3 Management review results	Improvement (ID.IM)	NIS2 Art. 21(2)(f) 49	Metrics pack; minute
Communication out	5.26 Response to information security incidents	7.5.3 Control of documented information	Incident Recovery Communication (RC.CO)	GDPR Art. 34(1)	Recipient notices

8. Checklist#

Each item is observable. "Reviewed" is not; a dated row in a register is.

• The regime map names every reporting duty in scope, with trigger, recipient and clock.
• One accountable role is named for declaration, severity, reporting and communication.
• The reporting decision-maker has a named deputy who has taken part in an exercise.
• The scheme states the criteria that turn an event into an incident.
• Every declaration record carries an awareness timestamp and its source.
• Assessed events that were not declared are recorded with the reason, and the declaration form asks whether evidence handling is engaged.
• Every incident has a decision log carrying time, role, basis, options rejected and the escalation gates crossed.
• Draft early-warning and notification texts exist before an incident needs them.
• Decisions not to report are recorded with the criteria applied.
• Closure criteria are written, and each closure record states which were met.
• Review records name roles, and every cause and contributing factor has a register row with correction, action and owner.
• No register row is closed without evidence, a verification date and a named verifier.
• The metrics pack reports types, volumes, costs and repeated causes.
• The process has been exercised against its tightest clock, with both intervals measured.

References#

Primary sources only. The controls standard was read as a licensed document: numbers and titles are cited, requirement text paraphrased. Clause titles were read on the publisher's browsing platform. The EU instruments were read as Publications Office texts, by CELEX number.

1. ISO/IEC. Information security, cybersecurity and privacy protection — Information security controls. ISO/IEC 27002:2022. Edition 3, 2022-02, corrected version 2022-03. https://www.iso.org/standard/75652.html; read from a licensed single-user copy ⁵⁰
2. ISO/IEC. Information security, cybersecurity and privacy protection — Information security management systems — Requirements. ISO/IEC 27001:2022. Clause titles read at https://www.iso.org/obp/ui/#iso:std:iso-iec:27001:ed-3:v1:en ⁵¹
3. National Institute of Standards and Technology. The NIST Cybersecurity Framework (CSF) 2.0. NIST CSWP 29, 26 February 2024, Appendix A. https://nvlpubs.nist.gov/nistpubs/CSWP/NIST.CSWP.29.pdf ⁵²
4. European Parliament and Council. Directive (EU) 2022/2555, measures for a high common level of cybersecurity across the Union. CELEX 32022L2555. https://eur-lex.europa.eu/eli/dir/2022/2555/oj/eng ⁵³
5. European Parliament and Council. Regulation (EU) 2016/679, General Data Protection Regulation. CELEX 32016R0679. https://eur-lex.europa.eu/eli/reg/2016/679/oj/eng ⁵⁴
6. European Parliament and Council. Regulation (EU) 2022/2554, digital operational resilience for the financial sector. CELEX 32022R2554. https://eur-lex.europa.eu/eli/reg/2022/2554/oj/eng ⁵⁵
7. European Parliament and Council. Regulation (EU) 2024/2847, horizontal cybersecurity requirements for products with digital elements. CELEX 32024R2847. https://eur-lex.europa.eu/eli/reg/2024/2847/oj/eng ⁵⁶

Retention periods, the four-role split, the decision-log fields and the exercise design are organisational choices, not requirements of any instrument here.

Standards and certification names are the property of their respective owners. GRCIDE is an independent publication and is not affiliated with, authorized, sponsored or endorsed by ISO, IEC, NIST or any other standards body.