NIST CSF 2.0 ID.IM-04: Keep Incident and Security Plans Current

ID.IM-04 says incident response plans and other cybersecurity plans that affect operations are established, communicated, maintained, and improved. Four verbs, and the last three are where most plans fail. Writing the plan is the easy part. Making sure the right people have read it, and updating it when reality changes, is the work.

CSF is voluntary guidance. There is no CSF certification, and having plans does not make anyone "NIST compliant".

What good looks like

You have a small set of plans: incident response, business continuity, disaster recovery and a vulnerability management plan. Each includes contacts, common scenarios, and clear criteria for prioritization, escalation and elevation. The people who carry them out have received them. They are reviewed at least once a year or after a major change.

How to implement it

1. Start with incident response. Define what counts as an incident, severity levels, who leads, who communicates and who decides to notify customers or regulators.
2. Add contact and communication details: on call roster, executives, legal, key suppliers, and an out of band channel for when your normal tools are down.
3. Write short playbooks for the three most likely scenarios, for example credential theft, ransomware and a vulnerable dependency in production.
4. Write the vulnerability management plan: how findings are discovered, validated, prioritized, tested and fixed, with target timelines per severity.
5. Add business continuity and disaster recovery plans with recovery targets for your Tier 1 systems.
6. Communicate. Send each plan to its owners, get an acknowledgment, and cover it in onboarding.
7. Maintain. Put a review date on every plan, update after every incident and exercise, and keep a change log.

A minimum viable plan set

For a company of fifty to five hundred people, a workable set fits in a handful of short documents rather than a binder.

• Incident response plan, three to five pages, with severity levels, roles, contact tree and a decision log template.
• Three scenario playbooks of one page each.
• Business continuity plan listing Tier 1 services, who owns them, the maximum acceptable outage and manual workarounds.
• Disaster recovery plan with backup locations, restore steps and tested recovery times.
• Vulnerability management plan with severity definitions and target fix times.

Short plans get read. Long plans get filed. Aim for the shortest document that lets a tired person act correctly at three in the morning.

Prioritization, escalation and elevation

The outcome calls out criteria for prioritization, escalation and elevation. Prioritization is how you rank competing incidents or vulnerabilities. Escalation is moving an issue up the chain when it exceeds a responder's authority or a time limit. Elevation is raising the severity classification when facts change. Write each as a rule, for example: any incident involving customer data is at least high; an incident not contained within four hours goes to the executive on call; a medium incident becomes high if a second system is involved.

Keeping plans from going stale

Put plan maintenance on the same calendar as other recurring work. Assign each plan an owner. Add review dates to the document header. Attach plan updates to three triggers: after every incident or exercise, after every change in personnel who appear in the plan, and after every major architecture change. Run a quarterly check of the contact list by actually calling or messaging a sample of the people on it.

Communicating plans

Communication has two audiences: the people who carry the plan out and the people it affects. For the first group, hold a short walkthrough when the plan is created or revised and record attendance. For the second, such as customers or key suppliers, share the relevant parts: who to contact, expected notice times and status channels. Include the plan in onboarding for anyone with a role in it.

Try it yourself

The demo walks through an incident from detection to postmortem, which is a good way to check that a plan covers each step.

Click through it at your own pace, or open it full screen.

Evidence to collect

• Current versions of each plan with review dates and change logs.
• Acknowledgment records from plan owners.
• Contact lists checked within the last quarter.
• Postmortems showing plan updates after incidents.
• Exercise notes from ID.IM-02 that feed back into the plans.

Common gaps

• The plan names people who left the company.
• Severity levels are defined but nobody knows who may declare one.
• The vulnerability management plan is a policy paragraph with no timelines.
• Plans live in a wiki nobody can reach during an outage.
• No out of band contact method.

Quick check

Sources

• NIST, The NIST Cybersecurity Framework (CSF) 2.0, NIST CSWP 29: https://nvlpubs.nist.gov/nistpubs/CSWP/NIST.CSWP.29.pdf