Download the response plan and tabletop exercise
The editable plan includes scope, contacts, authority, triage, evidence references, containment decisions, recovery checks, communications ownership, and a review record. The separate tabletop pack provides an original fictional scenario and injects for a facilitated discussion.
The exercise concerns a suspected exposed integration credential in a fictional SaaS called QueueNote. Every account, event, and result is invented. No live system is tested, no credential is supplied, and no actual message is sent by these resources.
Adapt the plan to your service and established authority before operational use. A template helps expose missing decisions; it does not establish that your team has an effective response capability or meets a particular standard.
What is an incident response plan?
An incident response plan is a prepared way to coordinate decisions and actions during a suspected or confirmed incident. For security incidents, it needs technical response, appropriate evidence handling, escalation, and the people who can make consequential decisions.
NIST SP 800-61 Revision 3, published in April 2025, places incident response within broader cybersecurity risk management and supersedes Revision 2. Treat preparation and learning as ongoing work rather than assuming response begins only after an alarm.
The UK NCSC's planning guidance identifies contacts, escalation criteria, an incident process, and support for legal or regulatory questions among the ingredients of a basic plan. This guide applies those principles to an original small-team exercise without claiming NIST compliance.
Distinguish a service failure from a security concern
An export worker stopping after a routine failure may be an operational incident. Evidence that a credential was exposed or that another account accessed protected material introduces a security concern. The same visible outage can have more than one cause and require parallel investigation.
Write criteria for escalation before the emergency. The exercise escalates suspected credential exposure and possible unauthorized access to the designated security responder, while the service owner continues coordinating the permitted service response.
Do not declare that no data was affected merely because the application is available again. Record what is known, the time and scope examined, and what remains uncertain. An unverified suspicion also should not become a public statement of confirmed compromise.
Name authority, contacts, and fallback arrangements
Identify who coordinates the incident, who can authorize containment, who provides technical investigation, and who owns communications. In a small team one person may hold several roles, but the plan still needs a fallback when that person is unavailable.
Keep actual contacts in an appropriately controlled location and make sure authorized responders can reach them if the main application or ordinary chat is unavailable. The public download contains fields, not real staff names, phone numbers, or escalation addresses.
Use the RACI matrix for a related responsibility discussion, then put the executable handoff in the response plan. A role letter alone does not specify which evidence to provide or which access an operator actually has.
Triage and preserve useful evidence
Begin an incident record with the report, time, affected service, reporter, observations, and initial uncertainty. Separate the start of observed impact from the time the team detected it. Keep a dated sequence of decisions and actions as the situation changes.
In the fictional exercise, a support report says an integration key may have appeared in a shared diagnostic note. The first task is to establish which note, which credential reference, its permitted scope, and who has authority to investigate. Do not copy the suspected secret into the general incident channel.
Preserve relevant records through the approved evidence process and record their source and access restrictions. Avoid deleting logs or modifying systems merely to make the incident view look clean. When specialist handling is needed, route the evidence reference and known facts to the responder.
Choose containment and recovery with explicit checks
The exercise asks the authorized owner to consider the established credential-revocation or rotation process and its service consequences. The worksheet records the decision, permitted action, owner, expected effect, and a verification observation. It provides no live command or universal containment sequence.
Containment can affect legitimate users, queued work, and integrations. Record what remains active and which side effects already occurred. A feature flag can affect future evaluations but cannot undo a request already accepted by another system.
Before restoring ordinary operation, define the checks that address the actual incident: credential state, required permissions, synthetic authorized behavior, relevant monitoring, and unresolved exposure questions. A healthy status page alone does not establish that the security concern is resolved.
| Decision | Evidence needed | Verification question |
|---|---|---|
| Limit use of suspected credential | Credential reference, scope, authorized owner | Did the approved action change the intended credential state? |
| Maintain or pause affected workflow | Current exposure and service dependencies | Which work remains active or already accepted? |
| Restore ordinary operation | Agreed technical and response checks | Which conditions are verified and which remain open? |
Plan communication and specialist escalation
Name one owner for status updates and distinguish internal coordination from customer-facing communication. A useful update states the known impact, current action, uncertainty, and the next update point. Avoid speculative attribution or promises that the investigation cannot support.
The tabletop pack includes a clearly fictional draft update for discussion. It is not a message ready to send about a real event. Actual communications should follow the incident's decision process and verified facts.
Notification, contractual, insurance, and legal questions depend on the situation. Record the route to qualified support and the information it needs; do not invent one universal notification deadline from a generic template.
Practice and learn before relying on the plan
Run the tabletop as a discussion with synthetic evidence. The facilitator introduces an unavailable decision owner, an ambiguous activity record, a legitimate integration failure after containment, and a customer asking whether their data was affected.
Observe whether participants can find the authorized next decision, preserve uncertainty, and hand over work. Record gaps as follow-up actions with owners and verification methods. A meeting's completion is not proof that a technical recovery path works.
After an actual incident is stable, use the RCA worksheet to examine contributing conditions and preventive work. The downloadable plan and exercise were checked for coherent decision branches and fictional labels; no live incident procedure was executed. Sources checked October 28, 2026.