Ransomware response playbook for leaders

A ransomware response playbook is a tested, step-by-step plan that tells the team how to respond to an attack. Without one, precious hours are lost to confusion whilst attackers encrypt your systems and exfiltrate your data.

Ransomware can encrypt data, disrupt services and involve data theft. This guide gives IT leaders a framework to adapt to their systems, response authority and recovery dependencies. It does not promise a recovery time.

Why you need a ransomware response playbook

NCSC guidance recommends preparation, layered controls and tested backups. A restoration runbook also needs a coordinated security response when an attacker may still have access.

A dedicated ransomware response playbook differs from your standard disaster recovery plan in several critical ways. It brings together forensic preservation, notification assessment and decisions about attacker communications alongside restoration. Check whether your existing DR plan covers those responsibilities rather than assuming it does.

Phase 1: detection and initial assessment

The first phase of your ransomware response playbook focuses on confirming the attack and understanding its scope.

Recognising the signs

Ransomware does not always announce itself with a dramatic ransom note. Early indicators include:

Unusual file extension changes across network shares
Spike in CPU usage on servers or endpoints
Users reporting inability to open files
Antivirus or EDR alerts for known ransomware signatures
Unexpected encryption processes in task manager
Canary files triggering alerts (if you have deployed them)

Immediate actions, with containment in parallel

Limit active harm: Authorised responders should isolate suspected affected systems promptly under the incident plan while confirming the nature and scope. Consider safety and critical-service dependencies. Do not wait for a complete investigation.
Alert your incident response team: Use out-of-band communication (phone calls, not email, as your email may be compromised)
Document everything: Start a timeline immediately, noting when the attack was discovered and by whom
Preserve evidence where feasible: Avoid unnecessary restarts. If you cannot disconnect an affected device from the network, shutdown may be necessary to stop spread, at the cost of volatile evidence. Record the decision.

Assess scope while containment continues

Determine how far the attack has spread:

Which systems are affected?
Is encryption still actively spreading?
Are backups accessible and uncompromised?
Has data been exfiltrated (check for unusual outbound traffic)?

Phase 2: containment

Containment limits further harm. CISA's response checklist calls for immediate isolation of impacted systems; the phases here are workstreams, not waiting periods.

Network isolation

Disconnect affected systems from the network immediately by disconnecting cables or disabling Wi-Fi
Isolate network segments to prevent lateral movement
Block known malicious IPs and domains at the firewall
Restrict compromised accounts and sessions through the identity platform, checking service dependencies and emergency access with the response lead
Consider isolating your entire network from the internet if the attack is widespread

Preserve evidence

Before you start recovery, preserve forensic evidence:

Take memory dumps of affected systems where possible
Capture network logs, firewall logs, and authentication logs
Screenshot ransom notes and any attacker communications
Preserve email headers if the attack arrived via phishing

This evidence is essential for law enforcement, your cyber insurance claim, and understanding how the attackers gained access.

Phase 3: eradication

Establish a clean, isolated recovery boundary and address the entry route and persistence before reconnecting restored services. Recovery preparation and investigation can proceed in parallel; reconnection requires an explicit safety decision.

Identify the attack vector

Work backwards to find how the attackers got in:

Was it a phishing email? Check email logs for the initial delivery
Was it an exploited vulnerability? Review patch status of affected systems
Was it compromised credentials? Check for brute force attempts or credential stuffing
Was it a supply chain compromise? Review recent software updates and third-party access

Clean the environment

Remove all identified malware, backdoors, and persistence mechanisms
Reset affected credentials from a clean administrative environment and revoke relevant sessions and tokens; coordinate service-account changes to avoid breaking recovery
Revoke and reissue certificates if there is any indication they were compromised
Patch the vulnerability that allowed initial access
Review all scheduled tasks, startup items, and services for hidden persistence

Phase 4: recovery

Recovery depends on clean backups and tested restoration procedures.

Backup validation

Before restoring anything:

Verify whether backups have also been encrypted or corrupted.
Check the timestamp of the last clean backup.
Test restoration on an isolated system before connecting to production
Scan restored systems for malware before bringing them online

Prioritised restoration

Set the order from the critical-service list and dependency map. Health and safety, essential operations and recovery dependencies take precedence over a generic list of system types. Establish trusted administrative access and the network/DNS services needed for each restoration, then validate the application with its business owner.

For example, a hypothetical order-processing application may need DNS, a database and identity services before staff can use it. Restoring its web server first would not restore the business process. Test data integrity, authentication and a representative transaction in isolation before reconnecting it. A failed test means the service remains unreleased while the owner resolves the gap.

The ransom question

Every IT leader dreads this decision. NCSC and law enforcement consistently advise against paying ransoms because:

Payment funds criminal organisations and encourages further attacks
There is no guarantee you will receive a working decryption key
Payment does not establish that the attacker has removed access or will not attack again
You may face legal complications if the attacker is a sanctioned entity

Any proposed response to a demand requires accountable leadership and specialist legal advice, including assessment of applicable sanctions restrictions. Cyber insurance does not override legal constraints or guarantee payment or recovery. Your playbook should identify the decision owner and keep individual staff from engaging independently.

Assess notifications while containing the incident

For a UK GDPR personal data breach, the controller must notify the ICO unless the breach is unlikely to result in a risk to people's rights and freedoms. Notify without undue delay and, where feasible, within 72 hours of awareness. A late notification needs reasons for the delay. If the breach is likely to create a high risk, inform affected individuals without undue delay, subject to the applicable exceptions. A processor must notify its controller without undue delay.

The ICO's breach guide permits information in phases when full details are unavailable. An initial report does not pause a clock or remove the duty to provide further information without undue further delay. Record all personal data breaches, including the reasoning for a decision not to notify. Assess awareness and risk promptly; do not wait for recovery or a complete forensic report.

Assign one person to record obligations, awareness times, owners and deadlines. Sector rules, overseas operations and contracts may add separate duties. Use qualified advice for the organisation's circumstances.

Phase 5: post-incident review

After restoring systems, review the response and assign improvements.

Conduct a blameless post-mortem

Arrange a prompt review when responders can participate and evidence is available. Two weeks is a possible planning target, not a regulatory deadline. Review:

Timeline: What happened and when? Where were the delays?
Detection: How quickly was the attack identified? Could it have been faster?
Response: Did the playbook work? What was missing?
Communication: Were stakeholders informed appropriately and promptly?
Recovery: How long did restoration take? What slowed it down?

Update your defences

Use the lessons learned to strengthen your position:

Patch the specific vulnerability that was exploited
Improve detection rules based on the indicators of compromise you observed
Update your security awareness training to cover the attack vector used
Review and tighten network segmentation
Test your updated playbook with a tabletop exercise

Building your playbook

Document roles and responsibilities

Your ransomware response playbook must specify:

Incident Commander: Who leads the response? (Usually IT Director or CISO)
Technical Lead: Who coordinates the hands-on technical work?
Communications Lead: Who handles internal and external communications?
Legal Contact: Who manages regulatory notifications and legal obligations?
Executive Sponsor: Who makes decisions about ransom payment and business impact?

Establish communication channels

Assume your primary communication tools are compromised. Prepare alternatives:

Personal mobile phones with a pre-shared contact list
A dedicated Signal or WhatsApp group created before an incident
Physical meeting point if digital communication fails entirely

Maintain a contact list

Keep an offline copy of:

Incident response team members and their personal contact details
Cyber insurance provider and policy number
Legal counsel specialising in cyber incidents
Appropriate police or fraud-reporting routes, plus NCSC cyber-incident reporting; verify the current routes in the contact list
Key vendors and their emergency support numbers
PR or communications agency if you use one

Test regularly

Schedule tabletop exercises according to risk, material changes and the team's needs. A quarterly exercise may suit some organisations, but is not a universal requirement. Record gaps, update the playbook and retest failed decisions. Practice provides evidence about the exercise, not a guarantee of performance during every incident.

Common mistakes to avoid

Check the exercise for these avoidable failures:

Delaying containment to "investigate further" whilst the attack spreads
Communicating over compromised channels and tipping off the attacker
Not checking backup integrity before relying on them for recovery
Skipping the post-mortem and getting hit by the same attack vector again
Rebuilding without eradicating: attackers often maintain persistent access
Focusing only on technology and neglecting communication with staff, customers, and regulators

Your next steps

If you do not have a ransomware response playbook, start building one this week. If you have one, test it. Practising the response helps the team identify gaps before an incident.

Print the key steps. Store contact lists offline. Run a tabletop exercise next month. Use the exercise to check responsibilities, recovery dependencies and communication arrangements. For support developing a comprehensive ransomware response capability, my security consulting practice covers incident response planning, playbook design, and recovery architecture.

Book a consultation with your existing playbook and recovery dependencies. We can design a tabletop exercise that tests containment authority, notification ownership and clean restoration without disrupting production.