The Incident Response Guide
Prepare your team to identify an incident, coordinate a response and learn from what happened. A guide to planning before, during and after a security event.
Request the guideTry the vendor-alert exercise
Original guide: March 2025 · Exercise: October 2026
Request the guide
Loading the form…
Incident Identification & Classification
Communication & Escalation Protocols
Containment & Mitigation Strategies
Recovery & Post-Incident Review
Regulatory & Compliance Considerations
A vendor alert arrives. Your records disagree.
Try this exercise before an incident. The aim is to see whether your team can turn conflicting information into a checkable handoff when its usual communication channel is unavailable.
This is a fictional coordination exercise. It is not guidance on deciding whether an incident has occurred, who must be notified or what a live response requires. Use your existing response plan and involve your security lead and counsel in adapting the exercise.
The exercise packet
A fictional company uses Vendor A for support analytics. At 09:00, the facilitator gives participants four records:
- Procurement inventory, reviewed six weeks ago: Vendor A receives aggregated usage counts. Owner: procurement.
- Engineering diagram, updated yesterday: Vendor A receives support-ticket text and internal ticket IDs. Owner: integration engineer.
- Vendor message at 08:55: unusual access to the support analytics service is under investigation. The message does not say whether this company’s account is affected or which information was accessed.
- Response plan summary (map these roles to your own plan): the incident lead coordinates the response; security establishes technical facts; counsel assesses legal obligations; an authorized vendor contact communicates with Vendor A; the designated communications approver approves external wording. The team normally coordinates in its corporate chat channel.
After participants read the packet, add one condition: corporate chat is unavailable for this exercise. Keep real customer and system data out of the exercise. Nobody should disable a real system or contact real vendors, customers or authorities. Begin every exercise message with “EXERCISE,” and stop the exercise if a real incident arises.
Make one shared fact record
Ask the group to produce a short record that keeps each statement attached to its source, then compare it with this worked example:
| Question | What the packet establishes | What remains unresolved | Next owner and check |
|---|---|---|---|
| What information does Vendor A receive? | The procurement inventory and engineering diagram describe different data flows. | What the running integration actually sends; what the ticket text can contain. | Integration engineer checks the running flow with security. Keep both source versions until reconciled. |
| Was our information accessed? | The vendor is investigating unusual access to its service. | Whether our account is affected and, if so, what was accessed. | Incident lead assigns the authorized vendor contact to seek the missing facts. Security evaluates the technical evidence. |
| How does the response group reconnect? | Its normal corporate chat is unavailable in this exercise. | Whether your plan names an approved alternate channel and participants can use it. | Incident lead checks the existing plan and tests the approved alternative within the exercise. If none is available, record the gap; do not improvise an unapproved channel. |
| Can an external update be approved? | The plan names an approval role. | Whether the person in that role is available, what the current evidence supports and which decisions counsel must make. | Incident lead locates the designated approver; counsel and the approver review any proposed wording through the plan’s process. |
Do not collapse the first two rows into “customer data was breached.” Nothing in the packet establishes that. A newer diagram also does not, by itself, prove what the running integration sends. Keep the shared fact record separate from counsel’s legal analysis. Track questions for counsel and who must approve external wording through your existing process.
Test the handoff
The facilitator now asks the incident lead for a brief status update. After the lead answers, compare it with this example:
We have a vendor alert, but our exposure is unresolved. The procurement inventory and engineering diagram disagree about what we send. The next checks are for the integration engineer to verify the running flow with security and for the authorized vendor contact to seek account-specific facts. Neither check is confirmed as started. Our normal chat is unavailable. We have not yet briefed counsel, verified an approved alternate channel or reached the designated communications approver. Those are open coordination tasks, not completed handoffs.
Participants then attempt the open tasks through the alternate channel your plan approves. If the plan names none, record that gap and role-play the remaining handoffs verbally. An unacknowledged message is not a completed handoff. If the usual owner is unavailable, use the backup process already authorized by your plan and record any gap in that process.
End with changes someone owns
Keep the debrief concrete. For each gap, name the person who will fix it, the agreed completion date and the evidence the team will check in a repeat exercise. For example: “The incident lead will update the alternate-channel instructions by October 30. In the repeat exercise, every member of the response group must acknowledge a test message sent through that channel.”
The exercise is useful when it reveals where an assumption became a fact, a message became an assumed handoff, or an owner existed only on paper.
The original March 2025 Incident Response Guide is available through the request form above.