Answer yes only if you have a written plan, named roles and a record that someone has practised it. Then say what the plan covers, how customers are notified, and offer to share a summary. A bare yes with no owner or test date invites follow-up questions you may not be able to answer.
What a reviewer is really checking
The question looks simple, but the reviewer is testing three things: whether a plan exists, whether it is used, and whether it reaches the customer. A plan that lives in one engineer's head fails all three.
NIST published SP 800-61 Revision 3 in April 2025, which supersedes the 2012 revision. It frames incident response as part of overall cybersecurity risk management, tied to the NIST Cybersecurity Framework 2.0, rather than a separate document pulled out after something breaks. That framing is a useful guide to what a good answer sounds like: preparation, detection, response and recovery are ongoing activities.
Answer structure that works
Use four short parts in your answer.
- Existence. A written plan exists, with the date of the last review.
- Ownership. Name the role that leads an incident and the backup. Roles are fine; you do not need to give personal names.
- Practice. State the last time the plan was exercised and what changed afterward.
- Customer impact. Say how and through which channel affected customers are told, and who decides.
What to offer as evidence
| Evidence | What it shows | Share by default? |
|---|---|---|
| Plan summary, one or two pages | Scope, roles, severity levels | Yes, under NDA if needed |
| Exercise record | A tabletop or drill happened, with actions | Yes, redacted |
| Contact path for customers | Who they hear from | Yes |
| Past incident post-mortems | Real handling | Case by case |
| Full internal runbook | Operational detail | Usually no |
Wording to avoid
Do not write "we have never had an incident" unless you can show monitoring that would have detected one. Absence of reports is not the same as absence of events. Do not write "24/7 response" unless there is a rota that proves it. And do not claim your plan "meets" a framework when you have only compared it against one. Say "aligned with the structure of NIST SP 800-61 Rev. 3" if that is what you did, and only if you did it.
Keeping it current
Review the plan after every real incident and at least once a year. Record the date in the evidence register next to an owner. When the team changes, update the contact roles the same week.
If you are a small company, a one page plan with severity levels, a decision maker, a communication template and a list of who to call is better than a forty page document nobody has opened. Run a thirty minute tabletop twice a year and write down what you learned.
Where Safeguard fits
Safeguard's compliance and evidence automation helps you keep the plan review date, the exercise record and the owner together, and its asset discovery and dependency scanning give the response team a current inventory to work from. A free scan is available at https://gold.safeguard.sh/scan.
Quick check
Can we say yes if the plan is untested?
You can say a plan exists, but say it has not been exercised yet and give a date for the first exercise. That is more credible than implying it has been tested.
Should we share the full runbook with customers?
Usually no. Share a summary of scope, roles, severity levels and customer notification steps, and keep operational detail internal.
Sources
Last reviewed: 19 October 2026.
