On 3 April 2025 NIST finalized Special Publication 800-61 Revision 3, "Incident Response Recommendations and Considerations for Cybersecurity Risk Management". It replaces Revision 2, the long-standing Computer Security Incident Handling Guide. NIST's announcement says incident response should be "integrated across organizational operations" and that all six functions of CSF 2.0 (Govern, Identify, Protect, Detect, Respond and Recover) contribute to it.
For a small software company, the practical result is a shift in framing. Incident response is no longer a separate document that sits in a drawer. It is part of how you run the business, and customers, insurers and auditors now ask to see it.
What's affected
Every software company that gets asked "do you have an incident response plan?" in a questionnaire, a SOC 2 audit, an insurance application or a contract. The old four-phase picture (prepare, detect, contain, recover) is still a useful mental model, but NIST now ties the work to risk management and to lessons learned feeding back into preparation.
You do not need a 40 page document. You need a short plan that people can find at 2 a.m., and evidence that you have exercised it.
How to check if you're exposed
Run this five-minute test with your team:
- Who declares an incident? If the answer is "whoever notices", name one person and one backup.
- Where do you talk during an incident? A dedicated channel and a call link, decided in advance.
- Where is the contact list for your cloud provider, your lawyer and your insurer, and can you reach it if email is down?
- Who tells customers, and who approves the message?
- When did you last practice?
If you stall on any of these, those are the lines of your plan.
What to do now
Write a single page with these sections.
1. Roles. Incident lead, technical lead, communications lead, and a scribe. In a small team one person holds two roles. Write names, not job titles.
2. Severity levels. Keep three.
| Level | Meaning | First response target |
|---|---|---|
| 1 | Customer data exposed, production down, or active attacker | Start now, page the lead |
| 2 | Suspected compromise or a serious vulnerability under active exploitation | Start within the working day |
| 3 | Minor event, no customer impact | Log and review weekly |
3. First hour checklist.
- Open the incident channel and name a lead.
- Start a timeline with times in UTC. The scribe keeps it.
- Preserve evidence before you change anything: logs, snapshots, the affected account's access history.
- Contain: disable the compromised account or key, isolate the host, revoke tokens.
- Decide whether customer data is involved.
4. Notification clock. If personal data of EU residents is affected, remember Article 33 of the GDPR: a controller must notify the supervisory authority "without undue delay and, where feasible, not later than 72 hours after having become aware". As a processor, you must tell your customer without undue delay, so internal escalation speed matters. Add the same rule to your customer contracts so you know what you promised.
5. Communications. A holding statement, a rule that only the communications lead speaks externally, and a place to publish updates.
6. Recovery. Who decides when it is over, how you verify, and how you restore.
7. After action review. Within a week, write what happened, what worked, and what to change. NIST's profile places lessons learned within the preparation work, because the review is what improves the next response.
A minimal timeline format for the scribe
The scribe's notes become your evidence and your after action review. A plain format is enough:
2026-10-18 02:14 UTC Alert: unusual login to cloud console from new region
2026-10-18 02:20 UTC Lead declared incident, severity 1, channel opened
2026-10-18 02:31 UTC Access key revoked, session tokens invalidated
2026-10-18 02:55 UTC Logs exported to storage with write protection
2026-10-18 03:40 UTC Scope: one key, read access to one bucket, no customer data found
Keep entries factual and timed. Do not record guesses as facts. When the incident ends, add a line for each decision and who made it. Auditors and insurers read timelines like this far more readily than a narrative written later.
How to avoid this trap
- Do not copy a template full of roles you do not have. If your team has six people, you do not have a "CISO liaison".
- Do not keep the plan only in the system that might be down. Store a copy offline or in a second tool.
- Do not skip exercises. A 45 minute tabletop with a made-up scenario, such as a leaked cloud key, finds gaps faster than any review.
- Do not forget your vendors. Keep each critical vendor's security contact on the list.
- Do not rely on memory for what you promised customers. Put the notification terms in the plan.
Why it matters
Auditors, insurers and customers do not judge your plan by its length. They look for three things: that it names real people, that it is dated, and that there is evidence you tested it.
NIST's new structure helps here. By tying response to governance and lessons learned, it gives small teams a reason to treat each incident, and each drill, as input to the next version of the plan. The goal is a plan that is slightly better every quarter.
Try it yourself
Schedule a 45 minute exercise this month. Scenario: a developer's cloud access key was committed to a public repository six hours ago. Walk through the first hour checklist, keep a timeline and write down the three gaps you find. Update the plan with those fixes, date it, and save the timeline as your evidence.
Click through it at your own pace, or open it full screen.
Quick check
What did NIST publish on 3 April 2025?
SP 800-61 Revision 3, which replaces Revision 2 and aligns incident response with CSF 2.0.
Under GDPR Article 33, what does a processor owe its customer after a breach?
Notification without undue delay after becoming aware, so the controller can meet its own 72 hour limit.
What evidence shows an incident response plan is real?
A dated plan with named people, plus records from an exercise or a real incident, such as a timeline and an after action review.
