Incident Response complete

Control over security incident detection, response, and recovery processes

L0 Unaware

No incident response plan exists; security incidents are discovered accidentally and handled ad-hoc with no defined process

Criteria

IR-L0-C1 The organisation has no documented incident response plan, and no individual or team is responsible for security incident management

Evidence guidance

Ask for the incident response plan and the name of the accountable responder. The absence of a written plan, or a plan that names no owner, confirms this criterion. A generic IT support rota or a help-desk ticket queue does not constitute incident response ownership.
IR-L0-C2 No security monitoring or alerting is in place; incidents are typically discovered by end users or external parties

Evidence guidance

Request the list of monitoring and alerting tools and a sample of how the last incident was first detected. If the detection source was a user complaint, a customer report, or a third-party notification rather than an internal alert, this criterion is met. Provider-default dashboards that nobody monitors do not count as alerting.

Indicators

Past security incidents were discovered days or weeks after initial compromise, usually by someone outside the security function
No post-incident review or lessons-learned process has ever been conducted
When asked who handles a suspected breach, staff give different or uncertain answers

Regulatory mappings

Regulation	Articles	Risk	Note
`GDPR`	art-33, art-34	critical	GDPR Art 33 requires notification of a personal-data breach to the supervisory authority within 72 hours of becoming aware of it. With no detection capability, the organisation cannot establish awareness, cannot scope the breach, and cannot meet the Art 34 obligation to inform affected data subjects.
`NDSG`	art-24	high	nDSG Art 24 requires the controller to notify the FDPIC as soon as possible where a data-security breach is likely to result in a high risk to data subjects. The absence of detection means breaches go unnoticed and unreported.
`NIS2`	art-21, art-23	high	NIS2 Art 21 requires incident-handling measures and Art 23 sets staged reporting deadlines (early warning within 24 hours, notification within 72 hours). An in-scope entity with no response capability is non-compliant on both.
`DORA`	art-17, art-19	high	DORA Art 17 requires a defined ICT-related incident management process to detect, manage and notify incidents. For a financial entity, the total absence of such a process also makes the Art 19 major-incident reporting timeline unachievable.

Upgrade path

Designate an incident response lead with named deputies and draft a basic plan covering detection, containment, eradication, and recovery. Enable security alerting on critical systems so that at least the most serious events surface internally rather than via outside parties. Define how a suspected breach is escalated and who decides on regulatory notification.

Risk if stagnant

Without any response capability, breaches go undetected and uncontained. The organisation cannot meet the GDPR 72-hour notification deadline or the NIS2 staged reporting deadlines, and it learns nothing from past failures. Attackers who have already gained access retain it for extended periods, and the organisation has no record from which to reconstruct what happened.

L1 Dependent

Incident response depends entirely on external providers; the organisation relies on its cloud or managed service provider to detect and respond to security events

Criteria

IR-L1-C1 Security monitoring and incident detection are handled exclusively by the cloud or managed service provider with no independent organisational capability

Evidence guidance

Ask where detection happens and who operates it. If every detection control lives in the provider's platform and the organisation runs no independent monitoring, this criterion is met. The presence of a provider security dashboard the organisation can view, but not the underlying detection logic it can run or tune itself, still counts as exclusive provider dependency.
IR-L1-C2 Incident response is reactive, triggered by provider notifications, with no organisational playbooks for containment or recovery

Evidence guidance

Request the response playbooks and the trigger for the last response action. If the organisation acts only after a provider notification and has no written containment or recovery procedure of its own, this criterion is met. Forwarding a provider alert to a distribution list is not a playbook.

Indicators

The organisation learns about security incidents from provider email notifications rather than its own monitoring
No internal staff have incident response training or defined roles during a security event
When an incident requires log data older than the provider's default retention window, that data is already gone

Regulatory mappings

Regulation	Articles	Risk	Note
`GDPR`	art-33, art-34	high	The GDPR Art 33 awareness clock and the Art 34 duty to inform data subjects remain the controller's obligation, but the controller cannot establish awareness independently. Notification timing is hostage to the provider's own detection and disclosure timeline.
`NDSG`	art-24	high	nDSG Art 24 places the breach-notification duty on the controller, who at this level depends on the provider to recognise and report the breach in the first place. The controller cannot verify completeness of what it is told.
`NIS2`	art-23	high	NIS2 Art 23 staged reporting (24-hour early warning, 72-hour notification) requires the entity to act on its own knowledge. Sole reliance on provider notification means the reporting clock may start late and the entity cannot independently corroborate the facts it reports.
`DORA`	art-17, art-19	high	DORA Art 17 requires the financial entity to own the incident-management process. Outsourcing detection without an internal capability creates concentration risk and undermines the Art 19 obligation to report major incidents from the entity's own assessment rather than the provider's.
`CLOUD-ACT`	18-usc-2703	high	Forensic data needed to investigate an incident sits with the provider. A US-headquartered provider may be compelled under 18 USC 2703 to disclose that data, and the organisation may neither obtain the same data on demand nor learn that disclosure occurred.

Upgrade path

Negotiate contractual incident-response SLAs with providers covering notification timelines, forensic-data access, and joint response procedures. Begin building internal playbooks for the most critical threat scenarios, including provider-driven sovereignty events such as account suspension or compelled disclosure. Start retaining a copy of security-relevant logs outside the provider so investigation does not depend solely on provider cooperation.

Risk if stagnant

Complete reliance on providers for incident response leaves the organisation unable to detect, investigate, or contain events on its own terms. Provider response priorities may not match the organisation's urgency, forensic evidence may be inaccessible or already expired, and the organisation has no fallback if the provider is itself the source of the incident, whether through compromise, compelled disclosure, or unilateral account action.

L2 Contractual

Incident response SLAs are contractually defined with providers, and the organisation has basic internal playbooks and notification procedures

Criteria

IR-L2-C1 Contracts with service providers include incident notification SLAs, forensic data access rights, and defined escalation procedures

Evidence guidance

Obtain the signed contract or its security schedule. Verify it states a maximum notification time for security incidents, grants the organisation access to the log and forensic data relevant to an incident, and names an escalation path with contacts. A clause promising notification without a deadline, or without a right to the underlying evidence, does not satisfy this criterion.
IR-L2-C2 The organisation maintains basic incident response playbooks covering the most likely threat scenarios, with designated internal contacts

Evidence guidance

Request the playbooks and the date of their last review. Confirm they cover the organisation's most likely scenarios, assign named internal contacts and roles, and have been reviewed within the past 12 months. A single generic document that names no owners and maps to no specific scenario does not meet this criterion.

Indicators

Provider contracts specify a maximum notification time for security incidents and guarantee access to the relevant log data
Internal incident response playbooks exist and have been reviewed within the past 12 months
Named internal contacts know their role in an incident and can be reached out of hours

Regulatory mappings

Regulation	Articles	Risk	Note
`GDPR`	art-33	medium	A contractual notification SLA and forensic-access right give the controller a defined route to the facts needed for Art 33 reporting. The route is paper-based: the controller still depends on the provider honouring the SLA to start the 72-hour clock on time.
`NDSG`	art-24	medium	Contractual notification timelines support the nDSG Art 24 duty to report to the FDPIC, but enforcement is contractual rather than technical, so the controller cannot independently verify that all reportable breaches reached it.
`NIS2`	art-23	medium	Agreed notification SLAs help the entity meet the NIS2 Art 23 staged deadlines. Without independent detection the entity still cannot corroborate the provider's account or detect an incident the provider misses.
`DORA`	art-17, art-19	medium	DORA Art 17 expects the incident-management process to extend to ICT third parties; contractual SLAs and escalation paths are the mechanism. The entity remains dependent on the provider for the detection feeding its Art 19 major-incident assessment.
`CLOUD-ACT`	18-usc-2703	medium	A contractual forensic-access right does not override compelled disclosure under 18 USC 2703, and a US-headquartered provider may still be barred from disclosing a government access request. A contractual notification-of-access clause provides early warning, not a veto.

Upgrade path

Stand up an internal security operations capability with monitoring tooling and trained analysts. Deploy a SIEM or equivalent that aggregates logs independently of provider-native tooling, so detection no longer depends on the provider noticing first. Run incident response tabletop exercises, including sovereignty scenarios such as compelled disclosure and account suspension, and feed the findings back into the playbooks.

Risk if stagnant

Contractual SLAs and basic playbooks provide a framework but not operational capability. Without independent detection and trained responders, the organisation cannot validate a provider-reported incident, cannot detect a threat the provider misses, and has only contractual recourse, typically termination, when the provider fails to perform. In a sovereignty event the contract is enforceable in court long after the operational window to respond has closed.

Typical characteristics

Negotiated incident SLAs. The contract states how quickly the provider must notify the organisation of a security event, and it grants access to the logs and forensic artefacts relevant to that event. Escalation contacts are named on both sides.
Scenario-based playbooks. Rather than a single generic document, the organisation maintains playbooks for the threats most likely to affect it, each assigning roles to named internal contacts and reviewed at least annually.
A defined notification decision. Someone is accountable for deciding whether an event meets the threshold for regulatory notification under GDPR, nDSG, NIS2, or DORA, and the playbooks record how that decision is made and on what clock.

The contractual gap

The limitation of Level 2 is that the controls are paper, and their strength is the enforcement behind them.

Detection still belongs to the provider. The organisation cannot independently see an incident the provider does not report. The notification SLA only helps once the provider has noticed.
Jurisdictional override stands. A contractual forensic-access clause does not defeat a compelled-disclosure order, and a notification-of-access clause may be unenforceable where the provider is gagged. The CLOUD Act overrides the contract for a US-headquartered provider.
Recourse is slow. When a provider misses an SLA, the organisation's remedy is contractual: a credit, a dispute, or termination. None of these contain an incident in progress.

When Level 2 is appropriate

Level 2 is a reasonable resting point for organisations whose regulatory environment accepts contractual safeguards, whose incident data is not subject to strict localisation, and who lack the internal capability to run detection themselves, provided a credible path to Level 3 exists and can be triggered if the risk posture changes.

L3 Controlled

Self-managed security operations function with independent detection, investigation, and containment capabilities across all environments

Criteria

IR-L3-C1 The organisation operates an internal SOC or equivalent security operations function with independent monitoring, detection, and investigation capabilities

Evidence guidance

Ask to see the detection architecture and who operates it. Confirm the organisation runs its own detection logic over logs it controls, rather than only consuming a provider's findings. A SIEM that aggregates logs from critical systems independently of provider-native tooling, staffed by analysts who can investigate without provider assistance, satisfies this criterion. A managed SOC may qualify if the organisation retains the detection rules, the log data, and the ability to investigate on its own.
IR-L3-C2 Incident response procedures are regularly tested through tabletop exercises and simulated attacks, including at least one scenario in which a provider is unavailable, uncooperative, or itself the source of the incident, with findings incorporated into updated playbooks

Evidence guidance

Request the records of the last two exercises and the resulting playbook changes. Confirm exercises run at least quarterly, are documented with outcomes, and produce tracked improvement actions. Confirm that at least one exercised scenario withdraws provider cooperation: the provider is unavailable, compelled to disclose and gagged, or is itself the source of the incident. A testing programme that only rehearses externally-originated attacks does not satisfy this criterion, and neither does a plan that is written but never rehearsed.
IR-L3-C3 The organisation retains a copy of security-relevant logs and forensic data in infrastructure it controls, sufficient to investigate an incident without requesting data from a provider

Evidence guidance

Ask where security-relevant logs and forensic artefacts are stored and who controls that infrastructure. Confirm that log sources covering the critical systems are continuously copied to an organisation-controlled store with defined retention, and that at least one past investigation or exercise was completed using only organisation-held data. A provider-side log archive does not satisfy this criterion regardless of its retention period, and neither does a copy that omits the systems most likely to be investigated.

Indicators

A SIEM or equivalent platform aggregates logs from all critical systems independently of provider-native tooling
Incident response exercises run at least quarterly, with documented outcomes and tracked improvement actions
At least one rehearsed playbook covers a sovereignty event, such as loss of provider access, sanctions, or compelled disclosure
Analysts can investigate and contain an incident without waiting on provider support

Regulatory mappings

Regulation	Articles	Risk	Note
`GDPR`	art-33	low	Independent detection lets the controller establish Art 33 awareness on its own timeline and scope a breach from its own evidence, so the 72-hour clock is no longer hostage to provider notification.
`NDSG`	art-24	low	Self-managed detection and retained forensic data allow the controller to recognise and substantiate a breach for nDSG Art 24 reporting without relying on the provider to surface it.
`NIS2`	art-21, art-23	low	An internal security operations function with tested procedures addresses the NIS2 Art 21 incident-handling requirement, and independent detection makes the Art 23 staged reporting deadlines achievable from the entity's own knowledge.
`DORA`	art-17, art-18, art-19	low	A self-operated, regularly tested incident-management process meets DORA Art 17 and supports the Art 18 classification and Art 19 reporting of major incidents from the entity's own assessment, reducing concentration risk on any single ICT provider.
`CLOUD-ACT`	18-usc-2703	low	Retaining detection and forensic data in infrastructure the organisation controls means an investigation does not depend on data a foreign provider could be compelled to disclose or withhold. Residual exposure remains for incident data still held within federated cloud services.

Upgrade path

Extend detection with proactive threat hunting and integrated threat intelligence so threats are found before automated alerts fire. Automate response for common incident types through orchestration, keeping a human decision point for sovereignty-sensitive actions. Establish a forensic capability that can complete an investigation entirely on organisation-held data, and remove the remaining incident-data dependencies on federated cloud services.

Risk if stagnant

A self-managed security operations function requires sustained investment in staff, tooling, and threat intelligence. Without it, detection rules go stale, analyst skills atrophy, and effectiveness degrades against evolving threats. The residual dependency is the incident data still held inside federated cloud services; if that is not progressively brought under the organisation's control, an investigation can still stall on data a provider holds.

Key capabilities at this level

Independent detection. The organisation no longer depends on a provider noticing an incident first. Its SIEM ingests telemetry from across its environments, and its analysts can investigate from data they hold rather than data they must request.
Rehearsed response. Tabletop exercises and simulated attacks run on a regular cadence, and the findings change the playbooks. Critically, at least one rehearsed scenario assumes the loss of provider cooperation, so the response does not silently depend on a counterparty that may be the source of the incident.
Forensic self-sufficiency in progress. The organisation retains the log and forensic data needed to reconstruct an incident, reducing the situations in which an investigation stalls waiting on a provider that is slow, gagged, or unwilling.

Operational considerations

A self-managed security operations function demands operational maturity. Detection rules need continuous tuning against a moving threat landscape. Analysts need ongoing training, or their judgement decays. The telemetry pipeline is itself a critical service that must be monitored, and the playbooks must be revisited as the environment changes rather than left to ossify after a single exercise.

Sovereignty posture

At Level 3 the organisation can detect, investigate, and contain most incidents without relying on an external provider. This is genuine incident-response sovereignty for the systems it operates. The remaining gap is the incident data that still lives inside federated cloud services: where an investigation touches those services, the organisation is back to requesting data it does not hold, and a provider that is compelled to disclose or to stay silent can still shape what the organisation learns.

L4 Autonomous

Fully sovereign incident response with proactive threat hunting, automated orchestration, and complete forensic independence from external providers

Criteria

IR-L4-C1 The organisation conducts proactive threat hunting over telemetry the organisation holds, using detection rules and threat intelligence it authors or owns outright, so the hunting capability survives the loss of any external feed, licence, or provider

Evidence guidance

Ask for evidence of threat-hunting campaigns: hypotheses pursued, detection rules the organisation authored, and findings that predate any automated alert. Confirm hunting runs over telemetry the organisation holds rather than provider-supplied summaries, and that the detection content in active use is authored by the organisation or owned outright. Hunting that would stop functioning if a licensed feed, analytics subscription, or provider relationship ended does not satisfy this criterion; external intelligence may inform hunting, but must not be the capability.
IR-L4-C2 Automated incident response orchestration (SOAR), running on infrastructure the organisation controls, handles common incident types from detection through containment to recovery without depending on a provider's cooperation or availability

Evidence guidance

Request the orchestration playbooks and a log of automated responses actually executed. Confirm that common incident types are contained and recovered automatically, that the orchestration platform itself runs on infrastructure the organisation controls, and that sovereignty-sensitive actions, such as cutting a workload off a provider, retain a human decision point. A SaaS orchestration service reintroduces the provider dependency this level removes and does not satisfy this criterion, and neither does a SOAR platform that is configured but never fires in production.

Indicators

Threat-hunting campaigns run continuously, identifying threats before they trigger automated alerts
Common incidents are contained and recovered by orchestration, with humans retained for sovereignty-sensitive decisions
An investigation can be completed end-to-end on data the organisation holds, with no request to any provider
Response procedures have been exercised against a provider-access-loss scenario and shown to complete without provider cooperation

Regulatory mappings

Regulation	Articles	Risk	Note
`GDPR`	art-33, art-34	minimal	Autonomous detection and complete forensic self-sufficiency let the controller establish awareness, scope a breach precisely, and meet the Art 33 and Art 34 deadlines from its own tamper-evident evidence, with no dependency on provider cooperation.
`NDSG`	art-24	minimal	The controller can recognise, substantiate, and report a breach under nDSG Art 24 entirely from data it holds, independent of any provider's detection or disclosure timeline.
`NIS2`	art-21, art-23	minimal	Autonomous incident handling exceeds the NIS2 Art 21 requirement, and full forensic independence ensures the Art 23 staged reporting deadlines are never constrained by a provider dependency.
`DORA`	art-17, art-18, art-19	minimal	A fully autonomous, automated incident-management process satisfies DORA Art 17, supports Art 18 classification from the entity's own analytics, and makes Art 19 major-incident reporting independent of any single ICT provider, removing concentration risk on the response path.
`CLOUD-ACT`	18-usc-2703	minimal	Forensic and detection data held entirely in infrastructure the organisation controls cannot be withheld from an investigation by a foreign provider compelled or gagged under 18 USC 2703. The organisation no longer depends on data a provider could be ordered to disclose or conceal.

Risk if stagnant

Autonomous incident response requires the highest calibre of security talent and continuous investment. Staff retention, an evolving threat landscape, and the arms race with sophisticated adversaries all erode capability if left unattended. Automation that is not maintained drifts: orchestration playbooks act on stale assumptions, and threat-hunting hypotheses stop reflecting the current environment.