Prepare decisions before the crisis
A useful incident plan tells available people what to do when information is incomplete and ordinary communication or administrator access may be compromised. It should protect people and evidence while enabling proportionate containment and recovery.
Name the incident lead, technical authority, decision-maker, communications owner, privacy or legal contact, key suppliers and record keeper. Protect alternative contact routes, define first-hour actions and rehearse a realistic scenario at least far enough to expose missing access and decisions.
Put the operating plan on one usable page
- How anyone reports a suspected incident, including outside normal hours
- Primary and backup incident leads with protected contact details
- Authority to isolate systems, disable access, engage specialists and spend emergency funds
- Critical services, recovery order and maximum tolerable disruption
- Technical, cloud, identity, domain, backup and managed-service contacts
- Legal, privacy, insurer, regulator, law-enforcement and sector reporting prompts
- Alternative communications if email or messaging cannot be trusted
- A time-stamped decision and evidence log
First-hour actions
- Protect people and essential safety. Address any physical, welfare or safety consequence before technology recovery.
- Confirm what is known. Record who reported what, when, which service or account is affected and which evidence exists.
- Use trusted communications. Move the response team away from a channel that may be monitored or controlled by the attacker.
- Contain proportionately. Disable or isolate affected access where authorised, while avoiding unnecessary evidence destruction or business harm.
- Preserve evidence. Keep relevant messages, alerts, logs, device state, times and actions. Obtain specialist guidance before making destructive changes.
- Assess and escalate. Consider critical services, data, people, fraud, safety, legal duties, suppliers and the likelihood that compromise is continuing.
Use clear incident levels
| Level | Example position | Response expectation |
|---|---|---|
| Event or concern | Suspicious message, blocked sign-in or lost device with no confirmed compromise | Record, triage, protect the account or device and monitor for related evidence |
| Contained incident | Confirmed compromise with limited scope and no current critical-service failure | Activate named roles, investigate scope, contain, assess reporting and complete controlled recovery |
| Major incident | Critical outage, widespread compromise, material fraud, sensitive-data exposure or significant harm to people | Executive authority, specialist response, protected communications, frequent decisions and coordinated external obligations |
| Crisis | Sustained threat to safety, essential operations, solvency, rights or public confidence | Integrate cyber response with business continuity, crisis leadership, legal duties and verified public communication |
Communicate facts, decisions and uncertainty
Internal teams
Tell people what has changed, which channel to trust, which actions to avoid and how to report new evidence.
Affected people
Where required or useful, explain what happened, likely consequences, protective actions, contact routes and what remains uncertain.
Authorities and partners
Assess regulator, law-enforcement, insurer, customer, contractual and sector duties against the correct country and timetable.
Public statements
Use verified information, avoid speculation and align operational, legal, privacy and customer communication without concealing material facts.
Set recovery gates
- Identity: Trusted administrators, recovery methods and privileged sessions have been re-established.
- Environment: Systems are rebuilt or checked to an agreed confidence level before restored data is introduced.
- Information: Integrity, completeness, permissions and the safe recovery point are validated.
- Operations: The minimum viable service works, owners accept the residual risk and enhanced monitoring is active.
- People: Staff and affected users receive clear instructions and support.
- Learning: Root causes, control gaps, response friction and overdue improvements are tracked after stabilisation.
Incident-response sources
NIST SP 800-61 Revision 3 integrates incident response with CSF 2.0 risk management. The NCSC response and recovery guide covers preparation, identification, resolution, reporting and learning. For a UK personal-data incident, check the current ICO breach-reporting guidance; notification depends on risk and circumstances. Other countries and sectors use different authorities and deadlines.
If an attack is active or material, use a qualified incident-response provider and the appropriate local authority rather than relying on a general web guide.
Cyber incident response plan FAQs
Who should lead a cyber incident?
Name the role in advance. The lead needs authority to coordinate decisions and resources, but technical investigation, privacy, legal, communications and business-recovery decisions may require different specialists.
Should a compromised device be switched off immediately?
Not in every case. Isolation may stop harm, but switching off or changing a system can destroy volatile evidence or disrupt essential work. Follow the authorised plan and obtain specialist advice for a material incident.
How should an incident response plan be tested?
Run a short tabletop exercise using a realistic scenario and incomplete information. Test contacts, authority, alternative communications, evidence, suppliers, reporting decisions, recovery access and the next shift or out-of-hours handover.
Continue your cybersecurity decision
Use the next guide that matches the exposure, control or recovery question you still need to resolve.
