Answer with who declares an incident, the phases you follow, how and when customers are told, and when you last practiced. Give a plain description of roles and steps, and attach the plan summary. Avoid naming a notification time unless your contracts and process can meet it.
What reviewers look for
- A written plan with an owner and a review date.
- Named roles, including who decides to notify customers.
- A way to detect and report issues, internally and from outside.
- Customer notification terms.
- Evidence you have rehearsed it.
NIST's incident response guidance, updated to align with the Cybersecurity Framework 2.0, aims to help organizations incorporate incident response into their wider cybersecurity risk management, preparing for responses, reducing the number and impact of incidents, and improving detection, response and recovery. Describing your plan in terms of preparation, detection, response and recovery matches how many reviewers think.
A structure for the answer
- Preparation. Plan, roles, contact list, on call rota, runbooks for likely cases such as credential leak or data exposure.
- Detection and reporting. Alert sources, an internal channel for staff to report concerns, and an external path through your security page or security.txt file.
- Triage and declaration. Severity levels, who may declare an incident, and when leadership and legal advisers join.
- Containment and recovery. Typical actions: revoke credentials, isolate systems, restore from backups, rotate keys.
- Customer communication. Who writes it, who approves it, and what it contains.
- Learning. A written review after each significant incident, with tracked actions.
The notification question
This one trips up vendors. Buyers ask "within how many hours will you notify us?" Your contract may set a period; if so your plan must be able to meet it. If it does not, do not agree to it. Legal terms are for your counsel. Operationally, you need to know three things within hours of detection: whether customer data is involved, which customers, and what you can say. Practice finding those answers. See vendor breach notification clause: what to ask for for the buyer's view and how to answer have you had a security breach questionnaire for the history question.
Prove you practice
A tabletop exercise is a short, scheduled walk through a scenario with the people who would respond. Keep notes: scenario, attendees, decisions, gaps and actions. One recorded exercise a year is far stronger evidence than a polished plan that has never been used.
Evidence worth attaching
| Item | Detail |
|---|---|
| Plan summary | Roles, phases, severity levels |
| Exercise record | Date, scenario, actions |
| Contact path | How customers reach you in an incident |
| Post incident review sample | Redacted, shows learning |
Common weak spots
- A plan that lists a single person as the owner. Name a deputy.
- No path for customers to report a suspected incident out of hours.
- Mixing up a security incident with an outage. Both need a process, but the notification duties differ.
- Claiming a 24 hour response team when staff work business hours.
Check consistency with other answers
Your logging answer, your backup answer and your notification terms should tell one story. See how to answer logging and monitoring questions from enterprise buyers.
Safeguard's zero-day discovery and continuous monitoring can help you learn quickly when a new vulnerability affects a component you ship, which feeds the detection phase.
Quick check
How often should we run an incident exercise?
At least yearly is a common expectation, and after major changes to your product or team. Keep a written record each time.
Do we notify customers of every incident?
Only those that meet your contractual and legal triggers, which counsel should help define. Decide the triggers in advance so the call is quick.
Sources
Last reviewed: 19 October 2026.
