Incident Reporting, Communication and Mitigation

A significant incident in a large European organisation becomes, within hours, a set of legal obligations, each with its own recipient, trigger and clock: the national computer security incident response team (CSIRT), the financial supervisor, the data protection authority or a market surveillance authority must be told, while the people who know most are busy containing the incident. Meanwhile, AI increases the speed and complexity of attacks (39, Five Eyes agencies, 2026), so containment that waits for a meeting may arrive too late.

This chapter treats two Categories of NIST CSF 2.0: RS.CO Incident Response Reporting and Communication, whose outcomes are that internal and external stakeholders are notified of incidents and that information is shared with designated stakeholders, and RS.MI Incident Mitigation, whose outcomes are that incidents are contained and eradicated (19, NIST, 2024). It shows how one incident record can start every applicable reporting clock under NIS 2, DORA, the AI Act and the data-protection regime, how AI can draft reports without becoming the author of record, and which containment and eradication actions AI may take, at which autonomy level. It begins where Chapter 20 ended, once the incident has been declared and scoped.

Figure 21.1: Incident detection leading to reporting clocks, an AI-drafted report signed off by people, and mitigation by autonomy level.

Reporting across regimes

AI Platform and Security, Chapter 21, concluded that AI incident management adds an AI classification step under AI Act Articles 3 and 73 and DORA, an impact query against the event log and a path back to evaluation, and that the runbook stages are detection, triage, containment, notification, recovery and post-incident review (73, Nordqvist, 2026). This chapter builds on that conclusion (F24 in the series foundations) and widens it to every incident that reaches a regulator. NIST's incident response recommendations likewise treat the preparation that makes reporting possible, such as knowing who must be told and who may decide, as outcomes of Govern, Identify and Protect (21, NIST, 2025).

Four regimes, four triggers

Each regime starts its clock from a different event, asks a different question and sends the answer to a different authority.

NIS 2. Article 23(1) of the NIS 2 Directive requires essential and important entities to notify their CSIRT or competent authority, without undue delay, of any significant incident, and where appropriate to notify the recipients of their services (3, European Union, 2022). Under Article 23(3) an incident is significant if it has caused or can cause severe operational disruption or financial loss, or considerable damage to other persons. Article 23(4) sets the sequence: an early warning within 24 hours of becoming aware, an incident notification within 72 hours with an initial assessment, an intermediate report on request, and a final report within one month of the notification, or a progress report if the incident is ongoing. The clock starts from awareness, so the moment the organisation records that judgement matters.

DORA. Article 17 of DORA requires financial entities to implement an ICT-related incident management process, Article 18 sets the classification criteria (among them clients affected, duration, geographical spread, data losses, criticality of services and economic impact), and Article 19 requires major ICT-related incidents to be reported to the competent authority as an initial notification, an intermediate report and a final report (2, European Union, 2022). The time limits are laid down in technical standards under Article 20, which the compliance function maintains in the configuration. Article 19(3) adds that clients whose financial interests are affected must be informed without undue delay. Under NIS 2 Article 4, where a sector-specific act such as DORA imposes at least equivalent reporting requirements, the corresponding NIS 2 provisions do not apply (3, European Union, 2022). The DORA clock starts from classification as major, so classification must be fast and recorded.

The AI Act. Article 73 of the AI Act requires providers of high-risk AI systems to report any serious incident to the market surveillance authorities of the member states where it occurred (1, European Union, 2024). Article 3(49) defines a serious incident as one that directly or indirectly leads to death or serious harm to health, a serious and irreversible disruption of critical infrastructure, an infringement of obligations protecting fundamental rights, or serious harm to property or the environment. Under Article 73(2) the report is made immediately after a causal link, or its reasonable likelihood, is established, and not later than 15 days after awareness; Article 73(3) shortens this to two days for a widespread infringement or an incident affecting critical infrastructure, and Article 73(4) to ten days in the event of a death. Article 73(5) allows an initial, incomplete report. Under Article 26(5), a deployer that identifies a serious incident must immediately inform first the provider and then the importer or distributor and the market surveillance authorities. Most cyber incidents never qualify; those that do involve a compromise leading to an outcome in Article 3(49), for example a tampered model whose decisions infringe fundamental rights.

Data protection. A personal-data breach starts a separate clock under the GDPR (9, European Union, 2016): Article 33 requires notification of the supervisory authority without undue delay and, where feasible, within 72 hours of awareness, and Article 34 requires communication to the people affected where the breach is likely to result in a high risk to their rights and freedoms. This trigger often arrives before anyone has decided whether the incident is significant or major. Entities outside the Union, such as in the United Kingdom or Switzerland, add local clocks maintained by the local security officer.

The incident record as the single source

With four triggers, a manual process will miss one, so the obligation is codified and the record drives it. The incident record from Chapter 20 carries the classification facts: personal data involved, entities and services affected, any AI system and its role, and each regime's result. Recording a fact starts the clocks that depend on it. The reporting configuration lives in version control and maps each regime to its trigger, recipient, sequence, signatory and source article, in line with the Evidence as Code principle of Architecture as Code (Chapter 15A) (71, Nordqvist, 2025).

Three design rules follow: a clock starts on the earliest plausible trigger and stops only by recorded decision, never by silence; each time limit names the article or standard it comes from; and every report is attached to the record version it was based on.

Practical guide: Mapping one incident to every reporting obligation

Purpose. Ensure that one incident reaches every applicable reporting regime, on time, with one consistent account of the facts.

Roles. Incident commander (record), compliance function (configuration and time limits), data protection officer (personal data), AI system owner or deployer's oversight officer (AI classification), and a named signatory per regime and entity.

Steps.

1. Declare once. Create the incident record at declaration and treat it as the only source for every report.
2. Ask the four classification questions within a fixed time. Is personal data involved? Which entities, services and member states are affected? Does the incident meet NIS 2 Article 23(3) or the DORA Article 18 criteria? Is a high-risk AI system involved that could lead to an outcome in AI Act Article 3(49)? A default of one hour from declaration suits most large organisations; adapt it to the risk appetite and record each answer, including "unknown", with its time.
3. Start every clock on the earliest plausible trigger. Where an answer is "unknown", start the clock and assign an owner to resolve it. Close a clock only with a recorded decision.
4. Map each clock to its sequence and signatory, as set out for each regime above, including DORA client information and the deployer's duty under AI Act Article 26(5).
5. Draft from the record, sign by a person. AI drafts each report from the record; the named signatory approves, edits or rejects it, and the approval is recorded.
6. Reconcile before each submission. Differences from reports already sent under other regimes must be explained by new facts in the record, not by different wording.
7. Keep the evidence. Attach each submitted report, its approval and the record version to the incident's evidence manifest.

Definition of done. Every clock started within the window, every report on time and traceable to a record version, and no two reports inconsistent.

Worked example: Reporting-clock configuration for a multi-regime incident

The following configuration is illustrative. In Hansa Mutual's incident INC-HM-2027-0412, a stolen service-account credential at the Polish service centre let an intruder read claims data for the German, Dutch and Swedish entities and some UK customers, degrade claims processing, and access the feature store of the underwriting-support model for life and health products, a high-risk AI system under Annex III point 5(c) for which Hansa is the provider.

# Illustrative: Hansa Mutual, reporting clocks for INC-HM-2027-0412
incident: INC-HM-2027-0412
declared_at: "2027-03-09T02:40:00Z"
classification_window_minutes: 60
clocks:
  - id: dora-major-ict
    instrument: "Regulation (EU) 2022/2554, Articles 18, 19 and 20"
    entities: [HM-DE, HM-NL, HM-SE]
    trigger: classified_major
    time_limits_source: "technical standards under Article 20, kept by group compliance"
    signatory: entity-chief-risk-officer
  - id: gdpr-breach
    instrument: "Regulation (EU) 2016/679, Articles 33 and 34"
    trigger: personal_data_breach_confirmed
    deadline_hours: 72
    signatory: entity-data-protection-officer
  - id: ai-act-serious-incident
    instrument: "Regulation (EU) 2024/1689, Articles 3(49) and 73"
    system: underwriting-support-life-health
    role: provider
    trigger: causal_link_or_reasonable_likelihood
    deadline_days: 15
    hold_before_altering_system: true
    signatory: ai-system-owner
  - id: uk-entity-regime
    entities: [HM-UK]
    time_limits_source: "UK regime, kept by the UK local security officer"
    signatory: uk-local-security-officer
drafting:
  usage_mode: "Mode 4 Built AI applications"
  autonomy_level: "Level 1 Assisted"
  submission_rights: none
reconciliation:
  block_on_unexplained_difference: true

The AI Act clock exists from the moment the feature-store access was recorded, although Hansa had not yet established whether manipulated features had reached any pricing decision. The flag hold_before_altering_system reflects Article 73(6), under which the provider must not carry out an investigation that involves altering the AI system in a way that may affect a later evaluation of the causes of the incident before informing the competent authorities (1, European Union, 2024). The drafter has no submission rights at all.

AI-assisted communication

Notifications, client messages and management briefings draw on the same facts but differ in form. Drafting them by hand takes skilled people away from containment, so an assistant that drafts each form from the record, linking every statement to its source fact, removes that load. The signature, however, stays with a person.

Where drafting goes wrong

Fabrication and over-precision. A model can state a cause or a number the record does not support; OWASP lists misinformation among the main risks of large language model applications (14, OWASP, 2025). In a regulatory report an invented detail is worse than a gap, because its correction undermines every later statement.

Attacker-controlled content. Much of an incident record was written by the attacker: file names, email bodies, command lines, ransom notes and log entries. A drafter that reads them is exposed to prompt injection, which OWASP ranks first (14, OWASP, 2025). AI Platform and Security, Chapter 16, concluded that prompt injection is a property of the architecture, so controls must sit outside the model (73, Nordqvist, 2026). The drafter therefore works from structured, analyst-confirmed facts, and raw artefacts reach it only as quoted, labelled evidence that cannot change its instructions or output format.

Inconsistency across regimes. Drafts from different record versions drift apart, which is why the guide reconciles them.

Sign-off that is not a formality

The rule from Architecture as Code (Chapter 20), "agents draft; humans approve", applies without exception: every external statement is approved by a named person, recorded with the version of the draft and the record (71, Nordqvist, 2025). AI Governance, Chapters 10 and 21, added that oversight must be designed rather than declared, and that approvals given in seconds signal rubber-stamping (72, Nordqvist, 2026).

Sign-off therefore needs support: the drafting tool shows each statement beside its source fact, marks unsourced statements, highlights differences from earlier reports, and records how long the signatory spent and what was edited. Messages to staff, residents, clients and the press follow the same pattern under the communications lead and are reconciled with regulatory reports, so that the public and the supervisor are not told different things. Chapter 24 returns to communication during recovery.

Containment at machine speed

Architecture as Code (Chapter 9B) concluded that manual incident response cannot scale when attacks develop within minutes, that compromised components should be redeployed from known-good definitions, and that mean time to detect, mean time to respond and the false-positive ratio are the programme metrics (71, Nordqvist, 2025). This chapter builds on that conclusion (F5). The average time to exploit a vulnerability, measured against the release of its patch, had already fallen to five days in 2023 (44, Charrier & Weiner, 2024), so mitigation that keeps pace must act at machine speed for at least some actions.

A catalogue of bounded, reversible actions

A security agent therefore gets a catalogue: a short, reviewed list of containment actions, each with its autonomy level, scope limits, reversal and evidence. MITRE D3FEND gives the vocabulary: Isolate covers techniques such as network isolation and access mediation, which limit what a compromised asset can reach, while Evict covers removal of an adversary from a computer network, for example by credential eviction or session termination, so that some Evict techniques serve containment and others eradication (12, MITRE, n.d.).

The autonomy levels of Chapter 6 decide who decides each action. Actions reversible within minutes and limited in blast radius, such as isolating one endpoint or revoking a session, are candidates for Level 3 Bounded: the agent executes them within the catalogue, and a person is informed at once and can stop or reverse them. Actions with wider effect, such as disabling an account used by many services or changing a firewall rule, stay at Level 2 Supervised. Irreversible actions, actions on tier-0 assets such as identity infrastructure, and changes to the agent's own permissions are never catalogued, and Level 4 Autonomous is not used for containment.

Containment that does not depend on intent

AI Platform and Security, Chapter 19, concluded that containment must not depend on intent: task-scoped credentials, default-deny egress, control artefacts outside the agent's reach, budgets and a stop path outside the system they stop, recorded approvals, and detection from telemetry and decoys rather than self-report (73, Nordqvist, 2026). This chapter builds on that conclusion (F23) and applies it to the containing agent itself. A Mode 5 agent that can isolate hosts is a privileged insider; if crafted alert content steers it, it can cause the outage the attacker wanted. The controls are therefore the same as for any agent:

• Own identity, narrow scope: its own workload identity, with a permission manifest that grants only catalogued actions.
• Policy outside the model: a policy decision point checks each request against catalogue, exclusion list and budget.
• Budgets: a cap on actions per incident and per hour, beyond which actions fall back to Level 2.
• A stop path outside the agent: a named person on every shift can suspend its credentials at the identity provider. AI Governance, Chapter 19, showed in the July 2026 incident how an alert that on-call responders judge not to require a stop, while decision rights over pausing the activity are still to be clarified, lets an incident run on (72, Nordqvist, 2026) (64, OpenAI, 2026).
• Logged per action, with identity, incident, evidence, policy decision and reversal handle.

# Illustrative: Hansa Mutual, containment catalogue for HM-SEC-001
agent: HM-SEC-001
usage_mode: "Mode 5 Autonomous production agents"
identity: wi-hm-sec-001
stop_path: {holder: soc-shift-lead, mechanism: suspend-workload-identity}
budget: {max_actions_per_incident: 10, max_actions_per_hour: 20, on_exhaustion: fall_back_to_level_2}
exclusions: [tier-0-identity, domain-controllers, payment-gateways]
actions:
  - {id: isolate-endpoint, level: "Level 3 Bounded", reversal: release-isolation, auto_release_hours: 4}
  - {id: revoke-session, level: "Level 3 Bounded", reversal: none-needed}
  - {id: disable-account, level: "Level 2 Supervised", approver: incident-commander}
  - {id: block-firewall-rule, level: "Level 2 Supervised", approver: network-on-call}

With auto_release_hours, an unconfirmed isolation is lifted after a fixed time and raised as an alert; whether lifting or keeping is safer depends on the asset class.

Containing AI systems

AI Platform and Security, Chapters 4 and 12, made the AI gateway the single seam for model and tool calls (73, Nordqvist, 2026), so containing a compromised AI application or agent means revoking its workload identity, refusing its traffic at the gateway, withdrawing tool permissions and freezing its retrieval sources, all reversibly. Because Article 73(6) of the AI Act constrains what a provider may do before informing the authorities (1, European Union, 2024), suspension preserves the model version, configuration and data.

Eradication

Containment stops the spread; eradication removes the footholds: persistence mechanisms, added accounts and credentials, modified configurations, implanted code and, for AI systems, poisoned data, altered prompts or tampered model artefacts. CSF 2.0 lists eradication as a distinct outcome of RS.MI (19, NIST, 2024), and with good reason: it is less reversible than containment, and an incomplete eradication tells the attacker they have been discovered without removing them.

Rebuild rather than clean

The preferred form follows from Architecture as Code (Chapter 9B): redeploy compromised components from known-good definitions rather than clean them (71, Nordqvist, 2025). For infrastructure this means rebuilding from versioned code and signed images; for AI systems, restoring model artefacts, prompts, guardrail policies and retrieval indexes from their registries at a version that predates the compromise, and re-running the evaluation suite. The impact query from F24 tells the organisation which outputs the compromised version produced, so that decisions based on them can be reviewed.

Where AI helps and where it stops

AI helps in eradication as an analyst rather than an actor, at Level 1 Assisted: it compares hosts with their known-good definitions, searches for the incident's indicators and drafts a dependency-aware rebuild plan. The steps remain human decisions because they are often irreversible, must be timed so that the attacker is removed everywhere at once, and may touch evidence that authorities still need.

Verifying removal

Eradication is complete when verified, not when executed: the detections that found the attacker no longer fire, rebuilt components match their definitions, every exposed credential is rotated, and decoys and honeytokens watch for re-entry for a defined period. The finding then enters the purple loop of Chapter 26.

Across the usage modes

The table states, for each of the usage modes, how reporting and mitigation differ.

Mode	Opportunity	Characteristic vulnerability	Who judges	Whose identity
Mode 0 Ambient AI	Vendor protection contains threats at once	Uncatalogued automatic actions	The vendor's model	The product's
Mode 1 Conversational assistants	Analysts structure facts quickly	Incident data in an unapproved tool	The analyst	The analyst's
Mode 2 Embedded workplace assistants	Drafts where the record lives	Summaries that drop a caveat	The signatory	The user's, by delegation
Mode 3 Agentic work tools	Actuators and templates built quickly	Engineer's credentials between instruction and review	The reviewing engineer	The engineer's
Mode 4 Built AI applications	Drafts in every regime's form	Prompt injection from attacker-written artefacts	The signatory	A read-only service identity
Mode 5 Autonomous production agents	Containment within seconds	Steered into harmful containment	Policy point and catalogue; people hold the stop path	The agent's own workload identity

Across the autonomy levels

Level	Reporting and communication	Containment	Eradication
Level 0 Advisory	AI flags possible triggers	AI recommends; analysts act	AI points to likely footholds
Level 1 Assisted	AI drafts; a person signs and submits	AI prepares; a person executes	AI drafts the plan; people execute
Level 2 Supervised	Not used for submission	Wider actions after per-action approval	Not used
Level 3 Bounded	AI starts clocks; never submits	Catalogued reversible actions; a person can stop	Not used
Level 4 Autonomous	Not used	Not used	Not used

Verifying with security chaos engineering

One experiment, run within the safety boundaries of Chapter 25, exercises both halves.

Condition injected. A synthetic incident, marked as an exercise, is declared with classification facts that touch several regimes: personal data, two entities and a high-risk AI system. A catalogued benign emulation produces an alert on a test endpoint, and a crafted test request asks the agent to act outside its catalogue. Submission endpoints are stubbed.

Steady-state hypothesis. Every applicable clock exists with owner and signatory; a draft per regime waits for sign-off; the agent isolates the endpoint with its own identity; the out-of-catalogue request is refused; and the stop path suspends the agent.

Time bound. All clocks within 60 minutes of declaration; isolation within five minutes of the alert; refusal immediately; suspension within one minute of the stop decision. Any miss is routed into the purple loop of Chapter 26.

The three AI focus areas

The NIST Cyber AI Profile reads every Category through three focus areas (20, NIST, 2025).

Securing AI systems. Incidents in the organisation's own AI systems reach the AI Act regime when they meet Article 3(49) (1, European Union, 2024); containment uses the gateway and preserves the system for evaluation.

AI-enabled cyber defence. AI drafts reports under sign-off and executes catalogued reversible containment at Level 3 Bounded.

Thwarting AI-enabled attacks. Bounded machine-speed containment closes the gap automated attackers open, and verified eradication by rebuild keeps an adaptive attacker from returning through a foothold left behind.

Nordvik Region and Hansa Mutual

Nordvik Region reports significant incidents to its national CSIRT under the national transposition of NIS 2, and personal-data breaches to its data protection authority. An assistant on its self-hosted capacity drafts the notifications from the record, and the CISO or a named deputy approves them. Where an incident affects the benefits-triage system, which the Region deploys and TriageSoft provides, the configuration also starts the deployer's duty under AI Act Article 26(5). Containment stays with people and the MSSP: the Region's security AI recommends at Level 0 Advisory or Level 1 Assisted. Its vendor endpoint protection already acts automatically, however, so the Region records those actions as part of the incident.

Hansa Mutual routes one incident to DORA for the EU entities, the AI Act where the underwriting-support model is involved, data protection, and the UK and Swiss regimes, with drafts signed off by the accountable owner in each entity. For mitigation, HM-SEC-001 executes the catalogued actions approved for Level 3 Bounded and logs each with its workload identity; anything else, and every eradication step, waits for the incident commander. The SOC shift lead in Hamburg or at the Polish service centre holds the stop path. Nordvik's challenge is therefore meeting two clocks reliably with a small team; Hansa's is keeping several regimes consistent while letting containment act at machine speed within its bounds.

Summary

RS.CO Incident Response Reporting and Communication works only if the incident record starts every applicable clock automatically, under NIS 2 Article 23, DORA Article 19, the GDPR and, for high-risk AI systems, AI Act Article 73, and stops a clock only by recorded decision.

AI may draft reports in Mode 2 and Mode 4 tools from confirmed facts, but people sign off every external statement, because an inaccurate notification is itself a failure.

RS.MI Incident Mitigation must keep pace with automated attackers without creating new harm. Machine-speed containment is therefore acceptable only as a catalogue of bounded, reversible actions executed by a Mode 5 agent with its own identity, checked by a policy point outside the model, limited by a budget and stoppable by a person. Eradication rebuilds from known-good definitions, verifies removal, and remains a human decision. Chapter 22 turns to the Function organisations most often neglect: recovery plan execution with AI.

Sources

1. National Institute of Standards and Technology. The NIST Cybersecurity Framework (CSF) 2.0. (19, NIST, 2024)
2. National Institute of Standards and Technology. Incident Response Recommendations and Considerations for Cybersecurity Risk Management: A CSF 2.0 Community Profile. (21, NIST, 2025)
3. National Institute of Standards and Technology. Cybersecurity Framework Profile for Artificial Intelligence (Cyber AI Profile). (20, NIST, 2025)
4. European Parliament and Council of the European Union. Directive (EU) 2022/2555 on measures for a high common level of cybersecurity across the Union (NIS 2 Directive). (3, European Union, 2022)
5. European Parliament and Council of the European Union. Regulation (EU) 2022/2554 on digital operational resilience for the financial sector (DORA). (2, European Union, 2022)
6. European Parliament and Council of the European Union. Regulation (EU) 2024/1689 laying down harmonised rules on artificial intelligence (Artificial Intelligence Act). (1, European Union, 2024)
7. OWASP Foundation. OWASP Top 10 for Large Language Model Applications, 2025 edition. (14, OWASP, 2025)
8. MITRE Corporation. MITRE D3FEND: A knowledge graph of cybersecurity countermeasures. (12, MITRE, n.d.)
9. Charrier, C. and Weiner, R. How Low Can You Go? An Analysis of 2023 Time-to-Exploit Trends. (44, Charrier & Weiner, 2024)
10. Nordqvist, G. Architecture as Code. (71, Nordqvist, 2025)
11. Nordqvist, G. AI Governance: Governing Artificial Intelligence in European Enterprises and Public Authorities. (72, Nordqvist, 2026)
12. Nordqvist, G. AI Platform and Security: Building and Securing AI Platforms in European Enterprises and Public Authorities. (73, Nordqvist, 2026)
13. European Parliament and Council of the European Union. Regulation (EU) 2016/679 on the protection of natural persons with regard to the processing of personal data (General Data Protection Regulation). (9, European Union, 2016)
14. OpenAI. OpenAI – Hugging Face Incident Technical Report. (64, OpenAI, 2026)
15. Five Eyes cyber security agencies. The AI shift in cyber risk: why leaders must act now. (39, Five Eyes agencies, 2026)