ID.IM-04 Incident response and operational plans

What ID.IM-04 asks for and why operational plans fail when it matters

A customer questionnaire, a contract clause or an internal review asks whether your incident response and operational plans are current and actually used. ID.IM-04 is the NIST CSF 2.0 Subcategory requiring that incident response plans and other cybersecurity plans that affect operations are created, communicated, maintained and improved. It sits in the Improvement Category of the IDENTIFY Function, and it is the successor to CSF 1.1 PR.IP-9 under a new identifier, with parts of PR.IP-10, RS.IM-1 and RC.IM-1 folded in. The risk it addresses is simple to state: a plan that is missing, out of date, unknown to the people who must carry it out, or never exercised will fail at the moment it is needed. NIST does not certify anyone against CSF 2.0 and has no conformity assessment program, so no one will hand you a certificate for this. The organization owns its plans, and an assessor will judge them by whether they exist, reflect current systems and are known to staff.

Plans usually fail for ordinary reasons. The incident response runbook lives in one wiki, the business continuity plan sits on a shared drive, the vulnerability management procedure was last edited in an email attachment, and the contact list points to people who left two reorganizations ago. Each plan has an owner, but the owner may have moved on, and nobody has been assigned to review the set together. The result is several versions of the truth and no clear answer to which one governs during an outage. The five Implementation Examples NIST publishes for ID.IM-04 describe what a working set looks like: contacts, common scenarios and escalation criteria in the incident response and continuity plans, a vulnerability management plan, communication of plans to the people who carry them out, and an annual review or an earlier review after major change.

Before you commit to any remediation, inventory every plan that affects operations and record its owner, location, last review date and the people expected to act on it. Confirm with your own leadership which plans are in scope, because NIST does not set that list for you. Then check whether a sample of staff can find the current version and name their role in it. Those three checks show quickly whether the gap is in the content, the distribution or the ownership, and they give an independent assessor evidence to test against. Any outside partner can prepare the systems and the evidence, but the plans, their approval and their upkeep remain your responsibility.

Which plans, teams and third parties ID.IM-04 covers in scope

ID.IM-04 reaches further than an incident response binder. Scoping it means deciding which plans count, which systems each plan depends on, who must act on them, and which external control references your auditors will accept. The cards below set out those decisions in the order most organizations work through them.

Which plans fall in scope

ID.IM-04 covers incident response, business continuity, disaster recovery, vulnerability management and other plans that affect operations. Start with an inventory of every plan that would be used during an outage, breach or service failure, including plans owned by other departments. Record the owner, the review date and the last exercise for each one. A plan missing from this list is a gap an assessor can find by asking how a recent disruption was handled.

Systems each plan depends on

Each plan is only as current as the systems it relies on. For every plan, list the applications, identity services, backups, networks and data stores it needs to restore or operate, and the owner of each. A disaster recovery plan that names a server retired last year will fail its first test. Tie each dependency to the asset inventory so changes in one place trigger review of the plan.

Teams who must act on each plan

A plan has to reach the people who execute it, not only the people who wrote it. Map each plan to the responders, executives, communications staff, facilities and on-call engineers who carry out specific steps, and confirm they hold the current version. Ask whether each named person can find the plan during an incident when primary systems are down. Record acknowledgment, since communicating plans to those who carry them out is part of the outcome.

Suppliers and service providers

Plans often depend on third parties such as cloud providers, managed security providers, data center operators and software suppliers. Identify which supplier contacts, escalation paths and recovery commitments each plan requires, and check that the relevant parts of each plan are shared with those suppliers. Contract terms, notice periods and joint exercises should match what the plan assumes. Confirm these arrangements with your legal and procurement teams before an assessor asks.

Informative references and mappings

NIST's Reference Tool maps ID.IM-04 to SP 800-53 Rev. 5.2.0 controls CP-2, IR-8, PL-2 and SR-2, to ISO/IEC 27001:2022 clause 9.1 and Annex A controls 5.24, 5.26 and 5.27, and to SP 800-171 Rev. 3 requirements 03.06.05, 03.15.02 and 03.17.01. These are NIST's published mappings, not a determination by NIST that your program satisfies them. Confirm with your auditor which references they accept as evidence for ID.IM-04.

Plan review and change triggers

NIST's Implementation Examples call for reviewing plans annually or when major improvements are needed. Define the events that also trigger a review, such as a new critical system, a changed supplier, a failed exercise or a regulatory change. Set the review cadence in a written procedure and retain dated versions of each plan. Version history is the evidence that shows the plan was maintained rather than written once.

How an assessor tests ID.IM-04 and which evidence passes

This table walks through the usual test steps an assessor may run against ID.IM-04, the evidence each step requests, and the findings that most often appear. Assessors vary in depth and sample size, so confirm the expected sampling with your auditor or customer before testing begins. Only an independent assessor issues any report or conclusion; the organization and its implementation partner prepare the evidence.

Test approach	Evidence requested	Common findings
Request the plan set and version history	Current incident response, business continuity, disaster recovery and vulnerability management plans, plus the change log showing prior versions and approvals	Plans exist as drafts, lack version numbers, or have no record of who approved each change
Interview the plan owners	Named owners for each plan, their stated responsibilities, and examples of decisions they have made under the plan	Owners cannot describe the plan's current contents, or the named owner has left the organization
Check communication to the people named in the plans	Distribution records, acknowledgment logs, access permissions to the plan repository, and copies sent to named third parties where relevant	Plans are stored where only a few staff can find them, or named responders never received the current version
Sample a plan against a recent exercise or incident	Exercise reports or incident records, lessons-learned notes, and the plan revision that followed them	The exercise did not follow the documented escalation criteria, and no plan update was recorded afterward
Confirm the review date and change record	Documented review cycle, the most recent review date, and records of out-of-cycle updates after major changes to systems or organization	Review dates have passed without review, or major infrastructure changes were never reflected in the plans
Check contacts and escalation paths	Current contact lists with roles, escalation criteria by scenario, and third-party contacts for suppliers the plans depend on	Contact details are outdated, or escalation criteria do not match the scenarios the plan covers
Confirm consistency across related plans	Cross-references between incident response, continuity, recovery and vulnerability plans showing shared roles, timelines and dependencies	Plans contradict each other on who declares an incident or which recovery targets apply

Sequence for building and maintaining the plan set

This sequence turns scattered continuity, response and recovery documents into one controlled, tested and reviewed set that operations staff can find, use and trust. Each step closes with a record that an assessor can inspect.

Inventory operational plans and owners
Start by listing every plan that affects how services run: incident response, business continuity, disaster recovery, vulnerability management and any other plan with an operational role. For each plan, name a single accountable owner and the teams that carry it out, and check the list against the services in your asset inventory so no critical service is left without a plan. The output is a plan register with an owner, a scope statement and a list of carriers for each entry, approved by the people who own the services.
Set minimum content for each plan
Define the content every plan must contain before anyone writes it: current contacts with alternates, the common scenarios the plan covers, escalation criteria with the people who decide, recovery steps in order, and, for the vulnerability management plan, the workflow from discovery through prioritization to remediation and verification. Use one template so responders find the same sections in every document. The output is an approved template and a checklist that each plan is measured against before it is published.
Store plans under version control
Place each plan in a controlled repository such as a self-hosted wiki or document system that records every change, the author, the date and the reason, and that lets reviewers compare versions and restore an earlier one. Each plan carries a named owner and a next review date in its header. The output is a repository where the current version of every plan is the only one visible to carriers, with its change history retained for audit.
Communicate plans and record acknowledgement
Send each plan to the people who will carry it out, including staff outside the security team and relevant third parties where the plan depends on them. Ask carriers to confirm they received and understood their responsibilities, and track the confirmations against the list of carriers from the first step. Follow up with anyone who has not acknowledged. The output is a dated acknowledgement record per plan and per carrier, which shows that the plan reached the people who must act on it.
Test plans and feed results into revisions
Run exercises that exercise each plan, such as tabletop walkthroughs of incident scenarios, continuity exercises with key suppliers and recovery tests of backups. Record what did not work, such as an outdated contact, a missing escalation step or an unclear recovery order, and assign each gap to the plan owner. Make the revision through the version-controlled repository and communicate the changed sections again. The output is an exercise report with a list of corrective actions and the revised plan version that resolved each one.
Run annual reviews and event-driven updates
Review every plan at least once a year and whenever a major change occurs, such as a new critical system, a change of provider, a significant incident or a restructured team. The review checks that contacts, scenarios, escalation criteria and recovery steps still match the environment, and it confirms the next review date. Changes return to the earlier steps for communication and acknowledgement. The output is a signed review record for each plan showing the date, the reviewer and any changes made, which feeds the improvement cycle for the whole plan set.

Evidence that shows ID.IM-04 is met, and how to keep it current

An assessor testing ID.IM-04 looks for plans that exist, are current, reached the people who run them and get better after exercises. The six artifacts below cover that chain, and each needs a recurring task so it stays accurate between assessments.

Approved plan set with an index

This is the controlled list of every incident response, continuity, disaster recovery and vulnerability management plan that affects operations, with one approved version of each. The index should show the plan owner, approver, approval date and next review date for every entry. Check that the index matches what staff can actually open, since a plan missing from the index is hard to defend as maintained. Recurring task: reconcile the index against the document store each quarter and confirm that no plan has passed its review date.

Version history of changes

Version history shows what changed in each plan, when, and by whom, which is the core proof that ID.IM-04 plans are maintained rather than written once. Wiki and document platforms such as XWiki keep page revisions under version control and let users compare versions and roll back, which supports this record if the platform is configured and retained correctly. Check that reviewers record the reason for each change, not only the edit. Recurring task: require a change note on every edit before publication.

Distribution and acknowledgement records

ID.IM-04 expects plans to be communicated to the people who carry them out, so the evidence is a record that named roles received and accepted the current version. Access control also matters here: permissions should be set per role and per content level, so the right people can read the plans and the plan owners can edit them. Check that acknowledgements are tied to the current version number and that they are re-collected after a material change. Recurring task: send each plan revision to its role holders and track acknowledgements to closure.

Exercise reports and resulting actions

Tabletop exercises, failover tests and recovery drills show whether plans work, and the report should list each gap found and the plan change it produced. An assessor will look for a traceable line from an exercise finding to an updated plan version. Store the reports with the participants, scenario and date so the record stands alone. Recurring task: after each exercise, open tracked improvement actions with owners and due dates, and close them only when the plan revision is approved.

Annual review record

The Implementation Examples for ID.IM-04 call for plans to be reviewed annually or sooner when major improvements are needed, so the review record is the clearest evidence of that cycle. A good record shows the reviewer, the date, the plans checked, the outcome and any triggered changes, including reviews that found no change. Check that reviews after major incidents or significant system changes also appear, not only the calendar review. Recurring task: schedule the annual review and an event-driven review trigger in the change process.

Contact lists within each plan

Each incident response and continuity plan should carry named contacts, escalation paths and the criteria that trigger escalation, which is what the ID.IM-04 Implementation Examples describe. Contact data goes stale faster than any other part of a plan, so confirm that each entry names a role and a current person, and that the list includes out-of-hours and third-party contacts. Recurring task: verify contacts at a fixed interval and whenever staffing or supplier arrangements change, then record the verification date inside the plan.

What meeting ID.IM-04 costs in money and effort

This table compares the cost components of keeping incident response, continuity, recovery and vulnerability management plans current under ID.IM-04, showing who is paid, whether each cost is one-time or recurring, and what drives it. No price or duration is given here, so ask any vendor or partner for a written scope and quote before budgeting.

Cost component	One-time or recurring	What drives it	How to reduce it
Document platform licenses	Recurring if commercial, none if self-hosted open source	Number of users who edit or approve plans, and whether the vendor charges per seat or per instance	Choose a self-hosted open-source wiki with version control, then budget for hosting and administration instead
Writing the plan set	One-time, then updated	Number of plans in scope (incident response, business continuity, disaster recovery, vulnerability management), their depth, and how many systems each covers	Start from NIST's Implementation Examples for ID.IM-04 and reuse one template across plans
Maintaining plans after changes	Recurring	Frequency of architecture, vendor and staffing changes, and how many plans reference the changed system	Link plans to asset inventories so changes trigger a targeted update rather than a full rewrite
Communicating plans to responders and third parties	Recurring	Number of staff and relevant third parties who must acknowledge plans, and how often versions change	Publish plans in one controlled location and record acknowledgements in the same system
Exercise delivery	Recurring	Exercise type and frequency, staff time to prepare and attend, and whether an outside facilitator is used	Run tabletop exercises internally on a fixed schedule and bring in external facilitation only for selected scenarios
Annual review cycle	Recurring	Number of plans, number of owners who must sign off, and whether reviews are triggered only by the calendar or also by major changes	Assign a single plan owner per document and schedule reviews with change management
External review of the plan set	Recurring or per engagement	Scope of an independent review or assessment, and whether the organization is also preparing for a framework assessment	Ask the reviewer for a written scope, and keep evidence of the last review organized for the assessor

Which self-hosted open-source tools keep plans and incident records

ID.IM-04 expects plans to be communicated, maintained and improved, and incident work to leave a traceable record. The three tools below cover the two sides of that evidence: versioned plan documents and structured incident case records. None of them makes an organization compliant on its own, so each capability should be confirmed in the target environment before it is relied on.

XWiki for versioned plan documents

XWiki (LGPL-2.1-or-later) keeps every change to a page under version control, recording what changed, when and by whom. Users can compare any two versions and roll back to an earlier one. For ID.IM-04, this gives an auditor a history of when the incident response, business continuity and disaster recovery plans were revised and who approved the change. Check that page approval and review dates are recorded in the team's own process, since version history alone does not show that a plan was reviewed.

BookStack for role-based plan access

BookStack (MIT) assigns abilities through roles, and permissions can be overridden per role at the shelf, book, chapter or page level. For ID.IM-04, this lets the team publish each plan to the people who carry it out, such as responders, recovery staff or facilities teams, while limiting edit rights to plan owners. Confirm in a test instance that restricted pages stay hidden from roles that should not see them, because the effective permission depends on how the overrides are configured.

DFIR-IRIS for incident case records

DFIR-IRIS (LGPL-3.0-or-later) keeps each case as one record of assets, indicators of compromise, tasks and evidence, with a full audit trail. It triages alerts from SIEM, EDR and REST sources into cases and builds a consolidated investigation timeline. Evidence is logged with SHA-256 verification and chain of custody. For ID.IM-04, these records show whether plans were followed during real incidents, which feeds the lessons learned that drive plan updates. Confirm the alert sources and evidence workflow the team needs before committing to the tool.

Who writes, tests and attests the plans

Your organization owns ID.IM-04. Plans that affect operations only work when named people write them, keep them current and accept the risk they describe. Each plan needs an owner who maintains the content, business and technical leads who supply accurate facts about services, recovery priorities and dependencies, and an approver, usually a executive or board-delegated authority, who accepts the plan on the organization's behalf. Your team also runs the exercises, records the lessons and decides which changes to make.

Plan owners: Assign one accountable owner per incident response, business continuity, disaster recovery and vulnerability management plan, plus a named backup.
Business and technical leads: Provide recovery priorities, service dependencies, contacts and escalation criteria that only your staff know.
Approvers: Record who approved each plan version, when, and under what authority.
Exercise and improvement decisions: Decide which findings from tests and incidents change the plans, and track them to closure.
Staff communication: Distribute the plans to the people who carry them out and confirm they have read them.

Before engaging anyone outside, confirm that each plan has a named owner, an approver and a review date.

Where ID.IM-04 plans usually fall short and how to close each gap

ID.IM-04 asks that incident response and other operational plans are created, communicated, maintained and improved. The gaps below usually appear after the plans are written, when people, versions and lessons drift apart. Each card pairs one gap with a fix and the evidence an assessor or internal reviewer can check.

Plans exist but nobody has been told

A plan that sits in a document repository does not operate anything. Staff who carry out the incident response, continuity or recovery steps often have never read the sections that assign them tasks. The fix is to communicate each plan to the people and third parties who must act on it, using role-specific extracts, short briefings and an acknowledgment record. Check whether named responders can state their first three actions without looking them up. Keep distribution lists and acknowledgment dates as evidence.

Plans name people who have left

Contact trees and escalation paths go stale quickly, especially after reorganizations, contractor rotations or vendor changes. A plan that routes a severity-one call to a departed engineer fails at the first hour of an event. Tie every role in the plan to a position rather than a person, keep a named deputy, and review contacts on a fixed schedule. Evidence includes a dated contact review, the role-to-holder mapping, and a test call to each primary and backup contact.

Plans are never exercised

Plans that have never been run tend to fail in their first real use because steps assume tools, access or approvals that nobody has tested. Schedule tabletop exercises for incident response and walkthroughs of continuity and disaster recovery procedures, and include suppliers where the plan depends on them. Record the scenario, attendees, decisions made, gaps found and owners for each fix. An assessor will look for the exercise record and proof that findings changed the plan.

Versions are scattered across shared drives

When copies of a plan live in email attachments, local folders and several shared drives, responders can open an outdated version during an incident. Keep one controlled repository with a single current version, a named owner, an approval record and a change history that shows what changed, when and by whom. A wiki or documentation platform with version control and role-based permissions can hold this record. Check that every printed or offline copy matches the controlled version.

Lessons are not written back into the plans

Improvements from incidents, tests and daily operations often stay in post-incident notes and never reach the plan itself. ID.IM-04 expects plans to be improved, so each lesson needs a path into a revision. Route findings from incident reviews and exercises to a tracked list, assign an owner and due date, and record the plan revision that closed each item. Incident case records with timelines and tasks can show where the lessons came from. Review the plan annually or when a major improvement is needed.

Vulnerability management left out of the plan set

Many organizations write incident response and continuity plans but treat vulnerability management as an IT routine outside the plan set. ID.IM-04 includes a vulnerability management plan among the plans that affect operations, so the escalation, prioritization and emergency patching steps belong in the same controlled set. Confirm that the plan defines scope, roles, timeframes for critical findings and how it links to incident response. Evidence includes the approved plan, its review record and its inclusion in exercises.

How ID.IM-04 replaces the CSF 1.1 plan outcomes

ID.IM-04 takes over the plan outcome that CSF 1.1 tracked under PR.IP-9, now with a new identifier. According to NIST's CSF 1.1 to CSF 2.0 Core Transition Changes spreadsheet, ID.IM-04 also absorbs part or all of three earlier Subcategories: PR.IP-10, RS.IM-1 and RC.IM-1. PR.IP-9 concerned response and recovery plans being in place and managed, RS.IM-1 concerned incorporating lessons learned from response into response plans, and RC.IM-1 concerned doing the same for recovery plans. The practical effect is that plan content once spread across the Protect, Respond and Recover Functions now sits under one Identify Subcategory in the Improvement Category. Read the spreadsheet directly before relying on this summary, because the degree of absorption differs for each older Subcategory, and PR.IP-10 in particular may have been only partly carried over.

If your organization assessed against CSF 1.1, your existing plan evidence probably still counts. Incident response plans, business continuity and disaster recovery plans, and their test records are the material an assessor will look for under ID.IM-04. What changes is the organization of that evidence. Each plan should show a current version, named owners, communication to the people who carry it out, and a record of the annual review or the update made after a major change, which are the points NIST's Implementation Examples for ID.IM-04 describe. Map each old PR.IP-9, PR.IP-10, RS.IM-1 and RC.IM-1 artifact to ID.IM-04 in your gap analysis, and note which gaps are new, such as a vulnerability management plan that was previously tracked elsewhere.

Confirm the mapping in three places before you rebuild any assessment record: the official transition spreadsheet, the current CSF 2.0 Reference Tool entries for ID.IM-04, and your own prior assessment workpapers, which show which 1.1 outcomes you scored and what evidence you cited. If a 1.1 score was based on a plan that has not been reviewed since before the transition, treat that score as unsupported under 2.0 until a current review exists. Tell your assessor, or the independent auditor who will review the work, how you traced each old outcome, because a documented crosswalk is far easier to test than a claim that the old evidence still applies.

What buyers ask about ID.IM-04 cost, effort and outside help

Does NIST certify compliance with ID.IM-04?

No. NIST does not offer certifications or endorsements of CSF-related products, implementations or services, and it has no plans for a conformity assessment program. Readiness for ID.IM-04 is judged by whoever your organization answers to, such as a customer running a supplier assessment, an internal audit function, or an independent assessor you engage for a formal review. Your organization owns its incident response, continuity, disaster recovery and vulnerability management plans. An implementation partner can prepare the plans, the version history and the exercise records, but only an independent assessor or the party requesting the assessment can conclude that the outcome is met. Ask any firm offering a "NIST CSF certificate" to explain who issues it and under what authority.

How long does it take to get ID.IM-04 plans ready?

No duration is published for this work, so ask for a scope-based estimate instead of a generic timeline. The main drivers are the number of plans in scope (incident response, business continuity, disaster recovery, vulnerability management and any operational plans), how old and fragmented the existing documents are, how many systems and teams the plans must cover, and how much exercise history exists to show that the plans work. A plan set that exists but has never been tested usually needs more work than one that has been exercised and revised. Ask the partner to break the estimate into discovery, drafting, review, communication to plan holders and first exercise.

What does our team need to provide for these plans?

Three things matter most. First, a named owner for each plan, with authority to change it and the time to keep it current. Second, time on the calendar for exercises, including tabletop exercises with the people who would carry out the plans and continuity exercises with key suppliers. Third, a sign-off authority, usually a senior executive, who approves each plan and accepts residual risk. Your staff also need to supply system inventories, contact lists, recovery time expectations for critical services and any contractual notification duties. Without these inputs, drafting the plans becomes guesswork, and an assessor will find that the plans were never agreed by the people responsible for them.

Can we maintain ID.IM-04 plans in-house without a partner?

Yes. Many organizations maintain these plans internally once the structure is set. The practical requirements are a documented process for drafting, reviewing and approving each plan, a schedule for annual review and for reviews after major changes, a record of exercises and the lessons taken from them, and a version-controlled repository so every change is traceable. Self-hosted wiki and documentation tools can provide this history. For example, XWiki keeps every page change under version control with the author and time recorded, and it allows comparison and rollback between versions. BookStack lets you set role-based permissions at the shelf, book, chapter or page level so plan owners can edit and approvers can sign off. Confirm that any tool you choose meets your own retention and access requirements.

What should we ask a partner to include in a quote?

Ask for a written scope that lists each plan to be produced or revised, the systems and business services each plan covers, and the exercises to be run. The quote should state which deliverables you receive, such as plan documents, contact matrices, escalation criteria, exercise reports and a maintenance procedure. It should name your responsibilities as well as theirs, including the owners and approvers you must supply. Ask how the work is fixed in scope, how changes are handled in writing, whether post-engagement support is a separate retainer, and how the partner will hand over repository access and documentation. DeployOpen works from a written, fixed scope agreed before work starts, and does not publish a price list, so a quote follows from that scope.

Why should the auditor be independent of our implementation partner?

An assessor who helped write the plans is testing their own work, which weakens the evidence for anyone relying on the result. Independence means the party that prepares the plans and exercise records is separate from the party that tests whether they meet the requirement and reports on it. Only an independent auditor, assessor or certification body issues reports or certificates. Keep the implementation partner responsible for preparing systems, plans and evidence, and keep the assessment engagement with a separate firm chosen by you or the requesting customer. This separation also makes it clearer to your board and regulators who is accountable for each conclusion.

How DeployOpen scopes and prepares ID.IM-04 evidence

DeployOpen works on ID.IM-04 by helping your team turn incident response, continuity, recovery and vulnerability management plans into maintained, tested and evidenced documents inside your own infrastructure. The organization owns its plans and decisions, and only an independent auditor or certification body issues reports or certificates.

How we scope

The written scope names which plans are in play, such as incident response, business continuity, disaster recovery and vulnerability management.
Scope lists the systems, business services and suppliers each plan must cover, agreed with plan owners before work starts.
Engagements are fixed-scope, with deliverables and timelines confirmed in writing, and ongoing support available as a retainer.

How we build

We set up a self-hosted wiki or documentation platform in your environment with version history for each plan.
Plans are structured with contacts, common scenarios, escalation criteria and review dates, matching the Implementation Examples NIST publishes for ID.IM-04.
Where incident cases are tracked, we configure a self-hosted case management tool so that response actions leave an audit trail.

How we hand over

You receive the plan set, role-based access settings, review schedule and a record of who approved each version.
We document how plans were communicated to the people who carry them out, so your team can show distribution and acknowledgment.
We provide a list of evidence items mapped to the ID.IM-04 outcome, so your assessor can see where each artifact lives and who maintains it.

How we support

Plan reviews can be scheduled annually or after a major change, with updates recorded in the same version history.
Exercise findings from tabletop or continuity tests can be fed back into plan revisions under the same change record.
Retainers cover upgrades, backups and continued documentation support for the platforms we deploy, scoped in writing.