Give the team a named coordinator, a backup, a trusted communication route and clear authority for the first decisions. Then walk through a scenario together.

Name the people who need to respond

Identify an incident coordinator and a backup. Record how to reach your IT team, relevant providers and the business decision maker. Keep the contact list where the authorised people can find it if normal systems are unavailable.

CIS Control 17 emphasises designated incident personnel and reporting contacts. For a small business, one person may hold several roles, but the responsibilities still need to be explicit.

Decide who can authorise action

Write down who can approve account restrictions, device isolation and changes that interrupt a service. Where appropriate, define actions that IT is authorised to take immediately and decisions that require management approval.

Discuss the business context in advance. Restricting a compromised account may be urgent, but the team also needs to know whether it supports a critical process and how to keep the business informed.

Prepare an alternative way to communicate

Choose a fallback channel in case company email or the usual messaging system cannot be trusted or accessed. Record how participants verify each other and who communicates with staff, clients or external parties.

The plan should identify the person who checks any external reporting obligations. The relevant requirements depend on the incident and the organisation, so do not rely on a generic deadline copied into a template.

Keep a simple incident record

Use one agreed record for the facts, decisions and work in progress. Give each entry a time and an owner. Separate confirmed observations from assumptions so later decisions can be understood.

Agree how relevant records will be preserved by the authorised team. Avoid destructive changes that could remove information needed for the investigation unless the response decision requires them.

RecordUseful detail
What is knownAffected systems, observations, times and evidence references
What was decidedThe action, reason and authorising person
What is nextThe task, owner and next update time

Try the plan with a short scenario

Bring the relevant people together and describe a plausible problem. For example: an employee reports an unfamiliar account sign-in while the usual IT contact is unavailable.

Ask who receives the report, who checks it, who can approve restrictions and how the team shares an update. Note the gaps without turning the discussion into a test of individual employees.

Assign the improvements and revisit the plan

Turn the discussion into a short improvement list with an owner for each item. Add missing contact details, check that the contacts can be reached and clarify any unclear permissions. Then update the guide.

NIST SP 800-61 Rev. 3 places incident response within wider cybersecurity risk management. In practice, keep preparation connected to changes in your people, providers and systems, rather than treating the plan as a document completed once.

Sources and further reading

  1. CIS Control 17: Incident Response Management
  2. NIST SP 800-61 Rev. 3: Incident Response
Related servicesIncident readiness