Incident Response Maturity Model: 5 Levels, 10 Dimensions

Most organisations have an incident response plan, but few can show with evidence that it works under pressure, at 3am, with the identity platform compromised and a regulator's clock running. Maturity is how quickly an alert becomes a declared incident, whether evidence survives the first hour, and whether every stolen credential is revoked before closure. This five-level model, using the same Ad hoc to Optimised scale as the NHI Mgmt Group NHI Governance Maturity Model, scores incident response across ten dimensions and maps them to NIST SP 800-61 Rev. 3, the CREST Cyber Security Incident Response maturity assessment and CIS Control 17. It is for incident response leads, SOC managers and CISOs who need an honest baseline and a roadmap.

Key takeaways

Score ten dimensions separately, from plan and governance through identity compromise response to post-incident learning, using evidence from real incidents and exercises.
Your level is set by the weakest dimension that a serious incident would depend on. A fast SOC with no tested way to communicate out of band is not mature.
Level 3 (Defined) is the right first target for most organisations: a plan with named decision makers, playbooks for the top incident types, a retainer agreed in advance and at least one exercise a year.
Identity is where incidents are won or lost. Many serious incidents involve valid accounts, tokens or keys, and an incident is not over until every exposed human and machine credential has been rotated.
Measure response, not activity: time to declare, time to contain, credential rotation completeness, notification deadlines met and the closure rate of post-incident actions.

The five levels

Level	Name	Description
1	Ad hoc	No current plan, or one nobody has read. Response depends on whoever is available, incidents are not formally declared, evidence is lost in rebuilds and notification is decided late.
2	Developing	A written plan and contact list exist, a few playbooks are drafted and a tool or MDR service raises alerts. Roles are understood by the security team but not by legal, communications or the business. Exercises are rare.
3	Defined	An approved plan with severity criteria, named decision makers and deputies, playbooks for the top three to five incident types, an incident response retainer, out-of-band communications and an annual exercise with tracked actions.
4	Managed	Response is measured and rehearsed across the organisation. Timings are tracked for every incident, evidence collection is routine, identity eviction is scripted, regulatory notification is rehearsed, and suppliers take part in exercises.
5	Optimised	Response improves continuously from incidents, exercises and threat intelligence. High-confidence containment is automated and improvements are verified by retesting.

The ten dimensions

Levels 2 and 4 sit between the descriptions shown; the roadmap below lists what moves you from each level to the next.

Dimension	Level 1 Ad hoc	Level 3 Defined	Level 5 Optimised
Plan and governance	No plan, or one written for an audit and never used	Approved plan with scope, severity matrix (Critical, High, Medium, Low), escalation criteria and authority to take systems offline; reviewed yearly	Plan integrated with business continuity, disaster recovery and crisis management; updated after every major incident and exercise
Roles and on-call	Whoever answers the phone	Named incident lead, decision makers and deputies; 24x7 on-call rota; two contact methods per person	Roles exercised across security, IT, legal, HR and communications; surge capacity planned for multi-week incidents
Detection to triage	Alerts emailed to a shared inbox	Documented declaration criteria; triage, categorisation and prioritisation by an owned SOC or MDR service	Time from detection to declaration measured; high-confidence detections trigger automated containment with human review
Playbooks	None	Playbooks for the top three to five incident types covering at least the first few hours	Playbooks version-controlled, tested in exercises, partly automated in SOAR and retired when stale
Evidence and forensics readiness	Systems wiped and rebuilt before anyone looks	Logs retained to policy; memory and disk capture procedure; chain of custody available when prosecution or litigation is likely	Evidence collection at scale across endpoint, cloud and SaaS; forensic copies of cloud volumes and identity logs collected by default
Identity and NHI compromise response	Passwords reset on the obvious account only	Playbook for account, token and secret compromise; inventory shows which service accounts, API keys and OAuth grants a system holds	Scripted eviction: krbtgt and signing key rotation, session and refresh token revocation, NHI credential rotation, verified complete before closure
Communication and regulatory notification	Decided on the day, often by email on a compromised system	Out-of-band channel and always-available bridge; notification decision tree for GDPR, NIS2, SEC and sector rules with owners	Notification rehearsed against real deadlines; holding statements pre-approved; regulator and law enforcement contacts current
Third-party coordination	Searching for a responder during the incident	Incident response retainer and cyber insurer contacts in the plan; contracts require suppliers to notify and cooperate	Retainer, insurer panel firm and key suppliers in joint exercises; responsibilities and authority to act defined in contract
Exercises	None	Annual tabletop for leadership and technical teams with an after-action report and owned actions	Programme of tabletops, technical drills and supplier exercises; scenarios drawn from threat intelligence and past incidents
Post-incident learning and metrics	Incident closed when service returns	Lessons-learned review for every significant incident; actions tracked to closure; core timings recorded	Trend analysis across incidents feeds control investment; improvements verified by retesting; metrics reported to the board

How the model maps to NIST, CREST and CIS

NIST SP 800-61 Rev. 3 (April 2025) replaced the four-phase lifecycle of Rev. 2 with a CSF 2.0 Community Profile: preparation now maps to Govern, Identify and Protect, detection and analysis to Detect, containment, eradication and recovery to Respond and Recover, and post-incident activity to the Identify Improvement category (ID.IM), which also feeds the two middle phases. CREST's Cyber Security Incident Response maturity assessment scores 15 steps across three phases, Prepare, Respond and Follow Up, on a scale of 1 (least effective) to 5 (most effective), with high-level and detailed spreadsheet versions. For CSIRTs and SOCs, the Open CSIRT Foundation's SIM3 (Security Incident Management Maturity Model) measures "how well a team governs, documents, performs and measures their function" through parameters grouped as Organisation, Human, Tools and Processes; FIRST, ENISA and the EU CSIRTs Network have adopted SIM3 v2 interim or are moving to it. Treat the mapping below as a sense check, not an equivalence. If the detection to triage dimension is your weakest, score it in more depth with the SOC Maturity Model.

Dimension	NIST CSF 2.0 (SP 800-61 Rev. 3)	CIS Controls v8.1	CREST CSIR phase
Plan and governance	ID.IM-04, GV.RR-02	17.4, 17.9	Prepare
Roles and on-call	GV.RR-02	17.1, 17.5	Prepare
Detection to triage	DE.AE-08, RS.MA-02, RS.MA-03, RS.MA-04	17.3	Respond
Playbooks	RS.MA-01, RS.MI-01, RS.MI-02	17.4	Prepare, Respond
Evidence and forensics	RS.AN-03, RS.AN-07	8 (audit logs)	Respond, Follow Up
Identity and NHI compromise	RS.MI-01, RS.MI-02	5, 6	Respond
Communication and notification	RS.CO-02, RS.CO-03, RC.CO-03	17.2, 17.6	Follow Up
Third-party coordination	GV.SC-08, RS.MA-01	15	Prepare
Exercises	ID.IM-02	17.7	Prepare
Post-incident learning	ID.IM-03, RC.RP-06	17.8	Follow Up

NIST SP 800-53 Rev. 5 covers the same ground in IR-2, IR-3, IR-4, IR-6, IR-7 and IR-8; ISO/IEC 27001:2022 in Annex A 5.24 to 5.28.

Identity and NHI compromise response

This dimension separates Level 3 from Level 4 more than any other. Attackers using valid accounts (ATT&CK T1078) or adding their own keys or certificates to cloud service principals (T1098.001 Additional Cloud Credentials) survive a response that only reimages machines. NIST SP 800-61 Rev. 3 expects procedures for urgent emergency tasks and gives "redeploying the organization's primary authentication platform" as an example. Microsoft's incident response guidance for systemic identity compromise sets out what a mature eviction looks like:

Active Directory: reset the krbtgt password twice, waiting at least 10 hours (the default maximum ticket lifetime) between resets, and include read-only domain controllers.
Federation: rotate the AD FS token-signing certificate twice, because "rotating the Token Signing certificate a single time would still allow the previous Token Signing certificate to work".
Sessions: revoke refresh tokens after credential rotation, accepting that users will be signed out.
Applications and NHIs: review enterprise applications for consent grants, hunt for the audit operations "Add service principal credentials." and "Add OAuth2PermissionGrant.", and rotate API keys, CI/CD secrets and service account passwords the attacker could have read.
Clean administration: perform recovery from a trusted device built from a clean source, and coordinate on channels the attacker cannot read.

The Cloudflare Thanksgiving breach shows the cost of an incomplete rotation: four credentials left unrotated after an earlier third-party breach gave a nation-state attacker a way in. See the Leaked Credential Response Playbook and the Service Account Security Guide.

Self-assessment questions

Score each dimension from 1 to 5 using evidence from the last real incident or exercise, not the plan. Take the lowest score among the dimensions your most likely serious incident (usually ransomware or identity compromise) would depend on as your overall level.

Plan: who has written authority to take a critical service offline at 3am, and who deputises if they are on a plane?
Roles: do legal, HR and communications know their role, and is there a contact list with two methods per person stored somewhere that works if email is down?
Triage: what are your written criteria for declaring an incident, and how many hours did it take from first alert to declaration last time?
Playbooks: which are your top five incident types, and does each have a playbook that covers the first few hours?
Evidence: could you capture memory and a disk image from a server before it is rebuilt, and snapshot a cloud volume, within an hour?
Identity and NHI: do you have a tested procedure to rotate krbtgt and signing certificates and revoke refresh tokens, and can you list every service account, API key and OAuth token a compromised system held within an hour?
Notification: who decides whether a breach is reportable, and could you meet a 24-hour NIS2 early warning or a four-business-day SEC Form 8-K deadline?
Third parties: is a responder on retainer, does your insurer require you to use its panel, and do your contracts oblige suppliers to tell you when they are breached?

Moving up a level

Size changes the route, not the target. A small organisation usually reaches Level 3 by buying capability: a managed detection and response service for triage, a retainer for investigation, and a cyber insurance policy whose panel and notification conditions are written into the plan. See the MDR Guide. A large or regulated organisation needs its own incident lead and on-call rota, Level 4 timings for every incident and supplier exercises, because NIS2, DORA and SEC reporting leave no time to brief an outsider from scratch.

From Ad hoc to Developing

Write a short plan: scope, severity matrix, who declares an incident and who can take systems offline. See the Incident Response Plan Template.
Build a contact list covering IT, management, legal, HR, communications, insurer and responder, with two contact methods each, and keep an offline copy.
Stop rebuilding compromised systems before evidence is captured: agree a minimum capture (memory, disk, relevant logs). CISA's federal incident response playbook is explicit: "When an endpoint requires forensic analysis, capture a memory and disk image for evidence preservation."

From Developing to Defined

Approve the plan at executive level, name deputies and set an always-available conference bridge outside corporate infrastructure.
Write playbooks for the top three to five incident types, starting with ransomware, phishing and business email compromise, and identity or token compromise. See the Ransomware Playbook Template and the Phishing Incident Response Playbook.
Agree an incident response retainer before you need it, and check your cyber insurance policy for panel and notification conditions. In the UK, the NCSC recommends an NCSC-assured Cyber Incident Response provider. See the Cyber Insurance Guide.
Build a notification decision tree: GDPR Art. 33 (72 hours to the supervisory authority where feasible), NIS2 Article 23 (24-hour early warning, 72-hour notification, final report within one month), SEC Form 8-K Item 1.05 (generally four business days after a materiality determination) and sector rules such as DORA for EU financial entities. See the Data Breach Notification Checklist and the DORA Guide.
Run a first tabletop for leadership; CISA's Tabletop Exercise Packages and the NCSC's Exercise in a Box provide ready scenarios. Record actions with owners. See the Tabletop Exercise Guide and the Tabletop Exercise Scenario Pack.

From Defined to Managed

Record timestamps for every incident: detection, declaration, containment, eradication and recovery.
Make evidence collection routine and tool-driven across endpoint, cloud and SaaS logs. See the Digital Forensics (DFIR) Guide and the Cloud Incident Response Guide.
Script identity eviction and test it in a lab, including NHI credential rotation and token revocation.
Include suppliers, the retainer firm and the insurer in at least one exercise a year, and define in contracts who has authority to act.
Add technical drills: restore from backup, isolate a host, rotate a production secret.

From Managed to Optimised

Automate containment for high-confidence detections, with a documented release process. See the SOAR and Security Automation Guide.
Feed trend analysis across incidents and exercises into detection engineering and investment.
Verify that each post-incident improvement works by retesting the scenario that exposed the gap.

Metrics that show maturity

Time to declare: median hours from first alert to formal declaration for significant incidents.
Time to contain: median hours from declaration to containment, by incident type.
Credential rotation completeness: percentage of human and non-human credentials in scope that were rotated or revoked before closure.
Playbook coverage: percentage of the top incident types with a playbook exercised in the last 12 months.
Notification compliance: regulatory and contractual notifications made within deadline.
Action closure: percentage of post-incident and exercise actions closed on time, and the age of the oldest open action.

Common failure patterns

Plan on the compromised system: the plan, contacts and chat channel live in the tenant the attacker controls; a retainer firm with no access or onboarding is a similar trap.
Rebuild before investigate: machines are reimaged within hours, destroying the evidence needed to scope the incident and find persistence.
Closing on service restored: the incident is closed when systems work again, with tokens, keys and service account passwords still valid, as at Cloudflare.
No authority to act: responders know a system must go offline but nobody on call has the authority to decide.
Exercises without follow-through: the same gaps reappear in every after-action report.

Practitioner checklist

Score all ten dimensions with evidence from the last incident or exercise.
Set Level 3 as the 12-month target, with Level 4 for identity compromise response.
Name decision makers and deputies with written authority to take systems offline.
Keep the plan, contacts and a conference bridge available out of band.
Put a retainer in place and align it with your insurer's requirements.
Rehearse identity and NHI eviction, including krbtgt, signing keys, tokens and service credentials.
Baseline the six metrics now and report them quarterly.
Reassess yearly and after every major incident.

Incident Response Maturity Model