An incident response readiness assessment answers one question: if something went wrong right now, would the organization know what to do in the first hour, or would it spend that hour finding out who is in charge? Score yourself across seven domains, decision rights, a written plan, an offline contact sheet, a first-hour guide, detection and reporting, tabletop testing, and after-action tracking, each on a 0 to 3 scale. A total under 11 out of 21 means readiness exists on paper more than in practice. This article is the scorecard, how to use it this month, and what the score should change about what you do next.
Working through this in production? See how we run a cybersecurity risk assessment.
This is a self-assessment, not an audit. Nobody certifies the result and no score is a guarantee against anything. It is a fast, honest way to find the gaps before an incident finds them for you.
What “incident response readiness” actually measures
Incident response (IR) readiness is different from having an IR plan. A plan is a document. Readiness is whether the people named in that document would actually act the way the document says, under time pressure, with incomplete information, possibly outside business hours. Two organizations can have an identical plan and very different readiness, because readiness lives in whether the plan was rehearsed, whether the contacts are current, and whether anyone remembers where the plan is stored.
A few terms worth defining before the scorecard, since a readiness conversation gets confusing fast without them. DFIR (digital forensics and incident response) is the specialist, hands-on work of determining what happened on compromised systems, containing an active intruder, and preserving evidence; it is a distinct capability from planning and is almost always outsourced by an organization without a security team. MDR (managed detection and response) is a 24/7 monitoring service that watches for and triages alerts; it is a detection function, not a planning function. An IR plan is the written document; IR readiness is whether the organization can execute it.
The seven-domain self-scoring scorecard
Score each domain honestly, not aspirationally. If you are not certain, score it as the lower number; uncertainty about whether something exists is itself evidence that it is not ready.
| Domain | 0: Not in place | 1: Informal only | 2: Documented, not tested in 12 months | 3: Documented and verified in the last 12 months |
|---|---|---|---|---|
| Decision rights | No one is named to declare an incident, take a system offline, approve emergency spend, or approve external communication | People generally know who would decide, but nothing is written down | Named decision-makers and alternates are written down | Decision-makers confirmed their roles and thresholds within the last year |
| Written plan | No written plan exists | A plan exists informally, in someone’s head or a scattered set of emails | A written plan exists covering declaration, containment, communication, and recovery | The written plan has been reviewed or updated within the last 12 months |
| Offline contact sheet | No consolidated contact list | Contacts exist but are scattered across systems that could be the thing that is down | A single contact sheet exists with insurer, counsel, DFIR provider, and IT escalation contacts | The sheet is stored offline, accessible if the network is down, and was checked for accuracy this year |
| First-hour guide | No guidance for the first actions after detection | General awareness, nothing written | A one-page first-hour guide exists (isolate, preserve, call, contain, stay quiet externally) | The guide is printed, stored off-network, and was reviewed within the last year |
| Detection and reporting path | Staff would not know who to tell if they saw something suspicious | An informal “tell your manager” expectation, undocumented | A documented reporting path exists for staff to report a suspected incident | Staff were reminded of the reporting path within the last 12 months |
| Tabletop testing | Never rehearsed | Discussed informally, never walked through a scenario | A tabletop exercise has been run at some point | A facilitated tabletop exercise ran within the last 12 months with a written scenario |
| After-action tracking | No record of what a past exercise or incident revealed | Issues were discussed but not written down | Findings from the last exercise or incident were written down | Those findings were assigned owners and tracked to closure |
Add the seven domain scores. Maximum is 21.
How to score it this month
Block ninety minutes with the people who would actually be involved: a general IT lead, an operations manager, a finance lead, and an executive who can authorize spend. Walk the seven rows in order and score them out loud, as a group, rather than having one person fill it out alone. Disagreement between scorers on any row is itself a finding, it means the organization’s understanding of its own readiness is inconsistent, which is a gap in the “decision rights” and “written plan” domains regardless of what either person scored.
Write the score down with the date. Rescore on the same cadence as your tabletop exercise, roughly every six months, so the trend line is visible rather than a single snapshot.
What your score means
| Total score | Readiness band | What it means |
|---|---|---|
| 0 to 5 | No real plan | Readiness exists only as intention. Start with decision rights and the first-hour guide, the two highest-return, lowest-cost items on the list. |
| 6 to 10 | Early stage | Some pieces exist but are undocumented or untested. The plan would likely fail under real time pressure because nobody has practiced the handoffs. |
| 11 to 15 | Developing | Most pieces are written down. The gap is usually testing: a plan that has never been rehearsed tends to reveal its missing pieces during the actual incident instead of during a drill. |
| 16 to 21 | Practiced | The organization has tested its plan within the last year and tracked what the test revealed. This is the band where readiness and the written document actually match. |
A score in the bottom two bands is common, not alarming, for an organization with no internal security function. It is also the band most worth fixing first, because the cheapest readiness gains, naming decision-makers, writing a one-page first-hour guide, building an offline contact sheet, require organizational decisions rather than security expertise or budget.
Where this differs from a written incident response plan
This scorecard measures whether a plan would hold up, not how to build one. If your score on “written plan” or “decision rights” is a 0 or 1, the next step is building those artifacts, not scoring them again. Incident response planning without a security team walks through exactly how to write the decision-rights table, the contact sheet, and the first-hour guide that this scorecard checks for. Use that guide to build; use this scorecard to check your work, and to check it again in six months when memories have faded and staff have turned over.
What already obligates you to show this evidence
Readiness is not only a resilience question. NIST SP 800-61r3, finalized April 3, 2025, replaced the prior four-phase incident response life cycle with a model built on the six NIST CSF 2.0 Functions, GOVERN, IDENTIFY, PROTECT, DETECT, RESPOND, and RECOVER, and NIST’s own rationale is that incidents now happen frequently enough, and recovery now takes long enough, that response has to be a continuous part of risk management rather than a separate capability a separate team owns only during a crisis. A readiness score that has never moved is a sign that response has not actually been integrated into how the organization operates.
Non-banking financial institutions under the FTC Safeguards Rule have a direct obligation here: 16 CFR 314.4(h) requires a written incident response plan addressing seven specified areas, and 16 CFR 314.4(j) requires FTC notification no later than 30 days after discovering a notification event involving at least 500 consumers. Organizations handling protected health information carry parallel obligations under the HIPAA Security Rule at 45 CFR Part 164 Subpart C. An insurer reviewing a renewal application, or a customer running a security questionnaire, is effectively asking a version of this scorecard, and “we have a plan” is a different answer than “we tested it in April and fixed what it found.”
CISA’s Cyber Essentials organizes this same readiness territory into six plain-language elements for small-organization leaders, one of which, Your Crisis Response, maps directly onto the domains scored above. It is a useful companion read if any of the terminology here is new.
Where outside help fits, and where it does not
A readiness assessment and a tabletop facilitation are advisory work: reviewing what exists, finding the gaps, running the exercise, and helping track the findings to closure. That is the scope of our incident response and ransomware readiness engagement, and it is also the scope most relevant to a low score on decision rights, written plan, contact sheet, first-hour guide, or testing.
It is not the scope for everything the scorecard touches. If an incident is actually underway, live digital forensics and incident response is a specialist, hands-on capability that an advisory relationship does not substitute for, and it should be a named firm in the contact sheet before it is needed, not searched for during the incident. The same is true of breach counsel, malware eradication, and 24/7 monitoring or managed detection and response, none of which DSE provides directly. On the testing side, DSE’s penetration testing scope covers LLM application testing, external network and web application testing, and cloud configuration and identity testing; it does not include internal network or assumed-breach testing, which is a separate specialist engagement if your plan needs to account for an attacker already inside the network.
Questions buyers ask
Is a 0 to 21 score actually meaningful, or is this just a marketing worksheet?
The score is a relative, self-reported indicator, not a certified rating, and it should be treated that way. Its value is in making the comparison honest over time: the same group scoring the same seven domains every six months will see whether readiness is improving, stalling, or quietly decaying as staff and systems change. It is a diagnostic tool, not an attestation.
We scored low. Does that mean we are out of compliance with something?
Not necessarily, and this scorecard does not determine legal compliance. Some obligations are specific and mandatory, the FTC Safeguards Rule’s written-plan requirement for covered financial institutions is one, and the HIPAA Security Rule carries parallel duties for entities handling protected health information. A low score on this worksheet is a signal to investigate your specific obligations with counsel, not a determination of what they are.
How is this different from a tabletop exercise?
The scorecard is faster and broader; it is a single-session inventory of whether the pieces exist and have been tested recently. A tabletop exercise is a facilitated, ninety-minute walk through a specific incident scenario that tests whether the people in the room actually make the right calls under simulated pressure. The scorecard tells you whether you have run a tabletop recently; the tabletop is where you find out what the written plan actually missed.
Who should be in the room when we score this?
The same people who would be involved in a real incident: a general IT lead, an operations manager, a finance lead, and an executive authorized to make a business call. Scoring it alone, especially scoring it as an IT function only, tends to produce an optimistic result that does not reflect whether decision rights actually extend beyond the technical team.
How often should we rescore?
Roughly every six months, and again after any material change, a new system holding customer or regulated data, a change in who holds the named decision-maker roles, or a real incident. Score drift between sessions, not just the absolute number, is often the more useful signal: a declining score after a leadership change means the plan now depends on people who are no longer there.
What this guide is / What it is not
What it is: A self-scoring diagnostic for incident response readiness, anchored to NIST SP 800-61r3 (April 3, 2025), NIST CSF 2.0, CISA’s Cyber Essentials, and the FTC Safeguards Rule at 16 CFR 314.4. What it is not: An audit, a certification, an attestation, legal advice, or a guarantee of any regulatory, insurance, or incident outcome. The score is self-reported and reflects only what the scoring group knows and can verify at the time. DSE provides incident response readiness assessment, tabletop facilitation, and after-action advisory work. DSE does not provide live digital forensics and incident response, breach counsel, malware eradication, or 24/7 monitoring and managed detection and response. DSE’s penetration testing covers LLM application, external network and web application, and cloud configuration and identity testing; internal network and assumed-breach testing fall outside that scope. Specific legal and regulatory obligations should be confirmed with qualified counsel.
The Bottom Line
A score is only useful if it changes what happens next. Run the seven-domain scorecard with the people who would actually respond, not just IT. If you land in the bottom two bands, fix decision rights and the first-hour guide first, both are organizational decisions rather than technical projects and both are cheap to put in writing. If you land in the top two bands, the next move is testing the plan against a scenario it has not seen yet, because an untested plan is a hypothesis, not a capability.
Metro Atlanta and Georgia organizations without an internal security function can start with a fractional CISO for Atlanta and Georgia small businesses, who can run the scorecard, facilitate the tabletop, and own the plan between sessions.
Key facts
- NIST SP 800-61r3, finalized April 3, 2025, replaces the four-phase incident response life cycle of SP 800-61r2 with a model built on the six NIST CSF 2.0 Functions and is published as a CSF 2.0 Community Profile for cyber incident risk management (NIST, 2025).
- The FTC Safeguards Rule requires covered financial institutions to establish a written incident response plan addressing seven specified areas under 16 CFR 314.4(h), and to notify the FTC no later than 30 days after discovering a notification event involving at least 500 consumers under 16 CFR 314.4(j) (eCFR, current 2026).