This page is part of our guide to building an incident response plan and works through step 7: the checklist for the first hour and a playbook for each of five common incidents. The plan contents guide covers the roles, escalation and severity levels these playbooks rely on.
A first-hour checklist
The first hour sets up everything that follows. Treat this list as things to start, not a strict sequence. Containment may need to happen in the first few minutes, while evidence preservation and the notification assessment run alongside it, and some items will take well over an hour to finish. Skip what does not apply to the incident in front of you; the incident lead's job is to make sure every item that does apply has an owner.
- Start the decision log: when the incident was spotted, who reported it and what they saw
- Appoint the incident lead and confirm who deputises
- Assign a first severity level, knowing it may change
- Move the response team to the out-of-band channel if email, chat or single sign-on could be compromised, and confirm each person's identity there
- Contain without destroying evidence: disconnect affected systems from the network rather than powering them off or wiping them
- Preserve logs that overwrite quickly, such as firewall, VPN, identity provider, email audit and endpoint detection logs
- Protect the backups: confirm they are offline or immutable, and cut the backup system's network access if it may be compromised
- Call your cyber insurer's incident line and legal counsel; many policies require you to notify them before you engage outside responders
- If personal data may be involved, record the time you became aware and start the notification assessment
- Brief the executive sponsor: what is known, what is not, what has been done and when the next update is due
Playbooks for specific incident types
A generic plan covers structure. Playbooks cover scenarios. The plan tells people what process to follow; the playbook tells them what to do for this specific type of incident. Build playbooks for the incident types most relevant to your organisation. These five cover the scenarios most organisations face.
Ransomware
Detection indicators (file extension changes, mass file access events, ransom notes appearing, backup deletion activity). Immediate isolation steps: disconnect affected systems from the network without powering them off where forensic preservation is required. Verify backup integrity and recovery point before proceeding. Establish whether data was copied out before encryption, because many ransomware groups now steal data as well, which changes both the notification assessment and the extortion risk. Restore into a known-clean environment, not onto systems that may still hold attacker tooling. Engage legal counsel and cyber insurer before any external communication or payment decision. Determine whether a breach notification is triggered (was personal data accessed or encrypted?). Establish a clean communications channel outside the affected environment. The ransom payment decision must be a structured process involving legal, insurance, and leadership, not a reactive call made under pressure.
Business email compromise and payment diversion
If a fraudulent payment instruction is discovered, contact the sending bank immediately. Many banks operate fraud recall processes that can recover funds within hours if contacted before the receiving account is drained. Preserve all email evidence including headers before resetting accounts. Then reset the password, revoke active sessions and refresh tokens, and check the registered MFA methods, because attackers often add their own; where compromise is suspected, remove them and have the user register again. Identify whether any other accounts were involved, whether forwarding or inbox rules were set, and whether any OAuth applications were granted access. Notify affected parties such as suppliers or clients if their data or payments were involved.
Personal data breach
A personal data breach is wider than theft. It covers personal data sent to the wrong person, a lost or stolen laptop, records altered or deleted without authority, and data made unavailable, for example when ransomware encrypts the only copy. Scope the affected data: what categories, how many individuals, what time period. Assess the risk to individuals. Determine whether you must notify a data protection regulator, and which one. Under UK and EU GDPR the notification must reach the regulator within 72 hours of becoming aware; other countries set different clocks, summarised below. High-risk breaches require direct notification to affected individuals. Preserve the evidence chain. Document the decision-making process even for breaches you determine do not require notification; regulators expect this documentation.
Account compromise
Before returning the account to use, reset the password, revoke all active sessions and refresh tokens, and remove and re-register the MFA methods where compromise is suspected. A password reset on its own may leave existing sessions working. Audit all actions taken by the compromised account during the window of compromise: emails sent, files accessed, permissions changed, rules created, applications authorised. Check for email forwarding rules, new administrator accounts and privileged role assignments, OAuth consent grants to connected applications, changes to federation settings or trusted domains, and changes to authentication or conditional access policies. A compromised account used to grant persistent access elsewhere is the most commonly missed element of account compromise recovery.
Supplier breach or outage
Some of the most disruptive incidents start outside your network. Your managed service provider is breached, a cloud platform goes down for two days, or a faulty update from a security vendor takes out your laptops, as the CrowdStrike update did to millions of Windows machines on 19 July 2024. When ransomware hit the Synnovis pathology service in June 2024, London NHS trusts that relied on it postponed thousands of appointments and operations. You cannot investigate systems you do not own and you may never see their logs, so this playbook is about the decisions you control. For each critical supplier it answers three questions: how will we know, what do we switch off, and how do we keep operating?
Confirm the incident through a contact you already hold, not a number or link in the alert itself; attackers impersonate suppliers. Then establish whether the supplier has been breached or is down but uncompromised, because the two call for different action.
If the supplier has been breached and has access into your environment, decide early whether to cut it. Disable its remote access tools and VPN accounts, suspend integrations and API connections, and rotate any passwords or keys it holds. An MSP's remote management tool reaches every machine it manages, so treat a breached MSP as a possible breach of your own network. Work out what data the supplier holds or processes for you and whether any of it is personal data.
If the supplier is down but there is no sign of compromise, cutting its access gains you little and can slow its recovery and yours. Keep the connection, watch it, and move to the workaround you agreed in advance (a manual process, a second supplier, or a reduced service). In either case, tell staff what changes for them.
Ask the supplier, in writing, what happened and when, which of your systems and data are affected, and what indicators of compromise you should look for. Log each request and each answer. Under UK and EU GDPR a processor must tell you about a personal data breach without undue delay, but the decision to report to the regulator stays with you as the controller, and your 72 hours run from when you become aware of the breach. The supplier's report usually starts that clock, but a news report, a customer complaint or your own monitoring can start it sooner, so assess straight away and record when and how you first learned of it. Brazil's LGPD splits the duty the same way. If the supplier is slow to share detail, report on time with what you know and follow up. Our supply chain security guide covers the contract terms and access controls that make this playbook easier to run.
If you are a supplier yourself, the same applies in reverse. Your customer contracts and data processing agreements may set notification deadlines shorter than any regulator's. Put those deadlines, the customer contacts and the person who decides what to tell customers into the plan.
Ryland has delivered cybersecurity, compliance, and IT management programmes for regulated organisations across the UK and the Netherlands for over 20 years. View full profile