An incident response plan works at 2 a.m. when a tired on-call engineer who didn't write it can open it and, within five minutes, know who to call, how serious the situation is, what they're allowed to do on their own and what to do first. That takes a short core document, current contact details that work out of hours, clear severity levels and decision rights, and one-page runbooks for the incidents you're most likely to face.
It also has to be reachable when your usual systems aren't.
What changed with NIST SP 800-61 Revision 3?
In April 2025, NIST released SP 800-61 Revision 3, Incident Response Recommendations and Considerations for Cybersecurity Risk Management: A CSF 2.0 Community Profile. It supersedes Revision 2, the Computer Security Incident Handling Guide from 2012, which many existing plans are built on.
The big shift is framing. Revision 3 treats incident response as part of overall cybersecurity risk management and ties it to all six Functions of the NIST Cybersecurity Framework 2.0: Govern, Identify, Protect, Detect, Respond and Recover. Rather than a separate first phase, preparation sits in everyday governance and protection work, and lessons learned feed continuous improvement.
In practice, your plan should connect to your governance structure, asset and risk inventories and recovery processes, rather than only describing what the security team does once an alert fires. A plan built on the Revision 2 structure doesn't need to be thrown out. Use the Revision 3 profile as a checklist for gaps.
What should an incident response plan include?
A usable plan has a short core and separate supporting material. The core should cover:
- A quick-start page: the first five things to do, and where everything else is
- Contact lists, internal and external, with out-of-hours numbers
- Severity levels with clear criteria
- Roles and decision rights, including who can approve which actions
- Communications, including an out-of-band option
- Notification obligations and their deadlines
- Evidence handling basics
- Outside support: retainers, insurers and key vendors
Keep scenario runbooks in an appendix or separate documents, and aim for a core plan of around ten pages. Nobody reads 60 pages during an incident.
How do you keep contact lists usable out of hours?
The contact list is the part of the plan most likely to be wrong when you need it. People change roles, phone numbers go stale and vendor support lines move.
For each internal role, list:
- The primary person and at least one deputy
- Mobile numbers, not just desk extensions or chat handles
- When they're typically unreachable (time zone, on-call rotation)
For external contacts, include:
- Outside legal counsel
- Your incident response firm, if you have a retainer
- Your cyber insurer's claims or incident hotline, plus your policy number
- Cloud and hosting providers' support lines, with your account IDs
- Critical vendors and managed service providers
Keep printed copies at home for key responders, plus a copy stored outside your primary identity platform. Test the list every quarter by calling a few numbers.
How should you define incident severity levels?
Severity levels tell responders how fast to move and who to wake up. Keep them to three or four, and define them by business impact rather than technical detail.
| Level | Example criteria | Expected response |
|---|---|---|
| Sev 1 – Critical | Confirmed exposure of sensitive data, or a critical business service down | Immediate, around the clock. Incident lead and executive sponsor engaged within 30 minutes |
| Sev 2 – High | Likely compromise of a system or account with access to sensitive data | Same day, including out of hours. Incident lead engaged |
| Sev 3 – Medium | Contained issue with limited impact, such as a single compromised standard account | Next business day |
| Sev 4 – Low | Policy violation or minor event with no evident impact | Normal ticket queue |
Two rules help: anyone can declare an incident, and when in doubt, go higher. Downgrading later costs little. Escalating late can cost a lot.
Who can make which decisions during an incident?
Incidents often stall because nobody is sure who's allowed to decide. Write it down.
| Decision | Who can approve |
|---|---|
| Disable a user account or revoke credentials | On-call engineer (no approval needed) |
| Isolate a server or workload from the network | Incident lead |
| Take a customer-facing service offline | Incident lead with business service owner, or executive sponsor |
| Engage the outside incident response firm | Incident lead or CISO |
| Notify customers, regulators or law enforcement | Executive sponsor, on advice of legal counsel |
| Make public or press statements | CEO or communications lead, on advice of legal counsel |
Name a deputy for every decision-maker. Also pre-authorize low-risk containment actions, such as disabling an account or rotating a key, so the person on call can act without waiting for someone to wake up.
Assign an incident commander for every Sev 1 and Sev 2 incident to coordinate and track decisions. That person shouldn't also be doing hands-on technical work.
What runbooks should you write?
A runbook is a one- or two-page guide to handling one type of incident. Write them for your most likely scenarios. Each lists the trigger, the first 30 minutes of actions, who to involve, evidence to preserve and when to escalate.
Leaked cloud access keys
Deactivate the key immediately. Before deleting anything, export the provider's audit logs and check what the key was used for, including any new users, keys or roles it created.
A compromised vendor with access to your systems
Suspend the vendor's remote access and service accounts, and rotate any shared credentials. Review what those accounts accessed recently, and ask the vendor for specifics about their incident and timeline.
Exposed data in a misconfigured storage bucket
Restrict access first, then capture the bucket's configuration and access logs. Determine how long it was exposed, what it contained and whether logs show outside access. That answer drives your notification decisions, so bring legal counsel in early.
A lost or stolen unencrypted laptop
Get a written account from the user with time and place. Disable their sessions and reset their credentials. Issue a remote wipe if device management allows it. Work out which data was stored locally, since that determines whether notification laws apply.
Insider data misuse
Involve HR and legal before taking visible action. Preserve logs and account data quietly, then restrict access in coordination with HR. Evidence handling matters especially here, since the case may end up in court or an employment dispute.
How do you communicate if email and chat are down or compromised?
If an attacker has access to your email or collaboration platform, they may be reading your response discussions. If the incident is an outage, those tools may simply be unavailable.
Set up an out-of-band channel in advance:
- A conference bridge or chat workspace that doesn't depend on your main identity provider
- Personal mobile numbers for core responders, stored offline
- A short rule for when to switch, such as any suspected compromise of email, identity or admin accounts
Test it during tabletop exercises, not for the first time in a real incident.
What legal and regulatory notification clocks apply?
Many notification deadlines start when you become aware of an incident or determine it meets a threshold, so record those timestamps carefully. Common obligations include:
| Regime | Deadline |
|---|---|
| GDPR (EU and UK) | Notify the supervisory authority without undue delay and, where feasible, within 72 hours of becoming aware of a personal data breach |
| SEC Form 8-K Item 1.05 (US public companies) | Disclose a material cybersecurity incident within four business days of determining it is material |
| HIPAA Breach Notification Rule | Notify affected individuals without unreasonable delay, and no later than 60 calendar days after discovery |
| NIS2 (in-scope EU entities, via national law) | Early warning within 24 hours of becoming aware of a significant incident, fuller notification within 72 hours |
| DFARS 252.204-7012 (US defense contractors) | Report to the Department of Defense within 72 hours of discovery |
| US state breach notification laws | Vary by state in timing and triggers |
Contracts add their own clocks. Customer agreements and your cyber insurance policy may require notice within set time frames, so list them with the contact method for each. Legal counsel makes the final call on notification. The plan's job is to get counsel involved early enough to meet these deadlines.
How should evidence be handled?
Poor evidence handling makes it harder to determine what happened and can weaken legal positions later. The basics:
- Preserve before you clean. Snapshot affected cloud workloads and image disks before rebuilding them.
- Export logs early. Many logs roll over in days. Copy the relevant ones to separate storage straight away.
- Don't power off by reflex. Memory contents can be valuable. Isolate from the network instead, unless shutdown is needed to limit harm.
- Keep a timeline. One person logs actions, decisions and findings with timestamps.
- Track custody. Record who collected each item, when, and where it's stored. Hash files where practical.
When legal counsel directs the investigation, some findings may be privileged. Involve counsel early in serious incidents so they can structure that.
Which outside retainers should you have in place?
Arranging help in the middle of an incident is slow. Set it up in advance:
- Incident response firm. A retainer gives you agreed rates, response times and a number to call.
- Outside legal counsel with incident and privacy experience.
- Your cyber insurer. Many policies require you to use approved providers or notify the insurer before engaging outside help. Check this now, not during an incident.
- Crisis communications support if you have a large customer base or public profile.
Put each contact, contract reference and activation process in the plan, and share basic environment documentation with your incident response firm ahead of time.
How do you keep the plan short enough to use?
Put a one-page quick-start at the front and move background and policy language to an appendix. Show a version number, owner and last review date on the first page. Review the full plan at least annually, after every significant incident or major change, and test it with a tabletop exercise at least once a year.
Frequently asked questions
How long should an incident response plan be?
Aim for a core of around ten pages plus short runbooks. If responders can't find what they need in a few minutes, the plan is too long or poorly organized.
Do small organizations need a formal plan?
Yes, though it can be shorter. Smaller organizations often have fewer people to cover roles, which makes clear decision rights and outside contacts even more important.
Do we need an incident response retainer?
If you don't have in-house forensic capability, a retainer is usually worth considering. Check first whether your cyber insurer requires specific providers.
Next steps
- Compare your current plan to the elements above and to the SP 800-61 Revision 3 profile.
- Update contact lists with out-of-hours numbers, and store offline copies.
- Add severity levels, a decision rights table and runbooks for your three most likely scenarios.
- Set up an out-of-band channel and confirm your notification obligations with legal counsel.
- Test the result with a tabletop exercise.