An incident response plan your team can actually use

A suspicious sign-in, an unavailable file share, or a report from a supplier can leave a small team asking the same questions: is this an incident, who needs to know, and what are we allowed to change? A short response plan gives those questions an owner before the pressure arrives.

Preparation is part of incident response. NIST’s guidance connects it with detection, response, recovery and the wider management of cybersecurity risk. For a small team, start with a plan people can actually find during an outage and use without guessing who is in charge.

Start with what you know

“An unrecognized administrator was added at 14:20 UTC” is a useful starting point. “The whole company is breached” may be an unsupported conclusion. An alert needs assessment; confirming an incident takes evidence of security impact. Record the observation, affected systems and unanswered questions separately.

Open a case record with an identifier, reporter, affected device or service, event time and timezone, collection time, evidence location, business impact and decision owner. Keep hypotheses separate from observations so an early guess does not become an accepted fact as the case changes hands.

Build a timeline that can be checked

Logs from an identity provider, application and endpoint may use different timezones or clocks. Keep the original timestamps as well as the times normalized for comparison, and record any known clock skew. Missing logs leave a gap in the account of events; they do not establish that nothing happened.

For exported records, retain the original file, source system, query period, collector and collection time. A cryptographic hash can help detect later changes to that export. It does not prove that the source system recorded every event or that the underlying event was legitimate. Restrict evidence access and keep a record of authorized transfers.

This is one reason preparation matters in NIST’s incident-response model. Logging access, decision authority and recovery dependencies are much easier to arrange before the systems and people involved are under pressure.

NIST SP 800-61 Revision 3

Choose containment for the system involved

For an account incident, containment may mean blocking sign-ins and ending relevant sessions. For an endpoint, it may mean isolating the device while keeping a management route available to authorized responders. For a web application, restricting one function may reduce exposure while preserving useful service logs. Name the person who can authorize each kind of action, and account for the business interruption it could cause.

Containment reduces ongoing exposure. Eradication addresses the cause and any unauthorized changes. Recovery returns a service to an accepted operating state. These activities can overlap, but calling a device “recovered” immediately after disconnecting it hides work that may still be necessary. Record the purpose and observed result of each action.

Agree what must be true before service resumes

Before approving recovery, assess the entry point, required fixes, affected credentials and sessions, chosen recovery point and essential business functions. Document what remains uncertain and what monitoring will continue after the service returns. A clean malware scan does not settle questions about stolen sessions or an application permission that still exposes data.

Where possible, run a harmless test transaction through the recovered workflow. Compare the records with the selected recovery point and note any expected loss of recent work. Record the approval to resume operations separately from the evidence behind it, even if one person in a small team handles both.

Use a tabletop exercise to find missing decisions

Walk through an invented account compromise, then add complications: the administrator is away, normal email cannot be trusted, or a customer deadline is approaching. Ask who can authorize the next step and what they need to know first. Leave the meeting with updated contacts, a decision timeline and named owners for the gaps. A discussion exercise can uncover these problems without disabling real accounts.

Name the people and their decisions

• Response lead: coordinates the work and keeps a decision record.

• Technical contact: investigates with the required authority and expertise.

• Business owner: approves interruptions, priorities, and outside support.

• Communications contact: coordinates accurate updates to the team and other affected parties.

• External contacts: relevant providers, insurer, and qualified advisers where applicable.

A small team may assign several roles to one person. Give each role a backup contact and keep provider support routes and phone numbers current. Store a protected copy of the plan somewhere you can reach when normal business systems are unavailable.

Make reporting straightforward

Staff should be able to report what they noticed, when it happened, the system involved and anything they already did. They should not have to diagnose a breach before asking for help. Make prompt reporting an expected and supported part of the process.

Choose an alternative communication method in case business email or chat is affected. Establish how participants will verify each other. A plan that depends entirely on the unavailable or compromised service may be difficult to use when it matters most.

Coordinate changes and preserve useful information

The response lead should coordinate investigation, containment, and recovery with the appropriate technical help. Record times, observations, decisions, and authorized actions. Avoid ad hoc wiping or rebuilding that could remove information needed to understand the event.

Agree in advance who can authorize disconnecting a system or interrupting a business service. The right response depends on the incident and its operational consequences. Have qualified advisers assess any contractual, insurance, or notification obligations rather than making that decision from a generic checklist.

Test whether people can find and use the plan

A short rehearsal can answer a basic question: if suspicious email activity is reported while the administrator is away, can the team find the contacts, reach the decision-maker and identify the next authorized action? Update the plan wherever the answer depends on somebody’s memory.

Read next: Could your backups survive a ransomware incident?

Sources & further reading

NIST SP 800-61 Revision 3: Incident Response Recommendations and Considerations for Cybersecurity Risk Management

Technical review: September 8, 2026. This is Short Circuit LLC’s original guidance, with primary sources linked beside the relevant explanations. Examples are illustrative.