Ransomware protection and response: keep services recoverable
Dealing with a possible incident now? Activate your incident plan and contact your security or IT response lead using a trusted channel. Prioritise safety and containment, protect evidence and avoid reconnecting or rebuilding systems before the response team has assessed the situation. Use the immediate actions below.
Ransomware and data extortion can disrupt services, encrypt information, steal data or combine these effects. Recovering files does not demonstrate that stolen data is safe or that an attacker’s access has been removed.
Reviewed: 26 October 2026.
Immediate actions during an incident
- Establish control: appoint an incident lead, use a trusted communication route and record decisions and times.
- Contain safely: identify affected systems and coordinate isolation with operational owners. Consider safety-critical and dependent services before disconnecting them.
- Preserve evidence: retain relevant logs, ransom notes and system information. Avoid unnecessary wiping or rebooting that could remove useful evidence.
- Protect recovery: restrict access to backups and management systems; check whether identity and backup administration are compromised.
- Get specialist support: involve the appropriate response, legal/privacy, insurance and supplier contacts, and report through relevant official routes.
- Assess impact: consider disrupted services, altered information and possible data theft, not just the encrypted devices.
Disconnecting and powering down are different decisions. Shutdown may halt activity but can destroy volatile evidence; isolation may preserve evidence but not stop activity already running. Balance containment, safety and investigation with specialist advice. NCSC immediate recovery activities.
Understand the incident, not just the label
| Pattern | Meaning | Response implication |
|---|---|---|
| Encryption | Information or systems are made unusable. | Recovery needs known-good data, systems and dependencies. |
| Data theft / extortion | An attacker threatens disclosure or misuse. | Restoring availability does not undo disclosure; assess what was accessed or taken. |
| Destructive or disruptive activity | Systems or data may be damaged without a reliable recovery route. | Validate integrity and plan continuity, not only decryption. |
| Ransomware as a service | A criminal operating model involving developers, affiliates or other participants. | This describes how attackers organise, not a separate technical impact on the victim. |
Do not assume a familiar malware name explains the full intrusion. Investigate initial access, identities, persistence, lateral movement and affected suppliers or cloud services.
Recognise entry routes and limit subsequent movement
| Entry or progression path | Preventive action | What to verify |
|---|---|---|
| Deceptive messages or downloads | Use layered email/web protection, safe software installation and a usable reporting route. | An employee can report promptly and the team can investigate related recipients or accounts. |
| Exposed remote access or edge service | Restrict access, protect authentication and prioritise relevant security fixes. | The actual external exposure and update state match the approved inventory. |
| Compromised administrator or supplier account | Limit privileges and remote paths; monitor sensitive actions and remove unused access. | Sessions and credentials can be revoked without depending on the compromised account. |
| Movement to other systems | Separate important services and administration, with controlled connections. | A compromised ordinary endpoint does not automatically have administrative access everywhere. |
| Attack on backups or recovery services | Protect management identities, deletion settings and recovery copies separately. | A compromised production administrator cannot easily remove every usable recovery path. |
Endpoint protection and application controls can help detect or restrict execution, but they need coverage, maintenance and someone able to act. Treat ransomware as a possible wider compromise: encryption may occur after identity theft, persistent access and data exfiltration. Removing the visible malware alone does not establish containment.
Reduce exposure and protect recovery capability
| Priority | Action | Evidence to keep |
|---|---|---|
| Identity | Protect privileged, remote and backup administration; remove obsolete access. | MFA/access coverage and tested recovery or emergency access. |
| Exposure and updates | Maintain an asset inventory and address vulnerable internet-facing services. | Verified remediation and controlled exceptions. |
| Separation | Limit unnecessary paths between users, administration, critical services and backups. | Access rules and safe validation of the intended boundaries. |
| Backups | Maintain protected copies that an ordinary compromised account cannot alter. | Access controls, retention and restoration results. |
| Detection | Collect useful events and investigate suspicious account, endpoint and backup activity. | Alert ownership and exercised escalation. |
| Continuity | Plan temporary operation and recovery order for important services. | Dependency map, contacts and tested workarounds. |
The joint StopRansomware Guide provides prevention and response checklists. Adapt them to your environment and UK reporting duties rather than copying overseas contact details.
Test recovery as a business service
Agree recovery time and data-loss objectives with service owners. Test the applications, identities, keys, network services, supplier connections and staff actions required to make the service usable. A successful backup job is not an end-to-end recovery test.
Use an isolated recovery environment where appropriate. Check backups and rebuild sources, remove the cause of compromise, rotate affected credentials and validate access before reconnecting. Restore in a controlled order and monitor for renewed malicious activity.
For example, restoring an order database is insufficient if the identity provider, payment integration or fulfilment system remains unavailable. A recovery exercise should reveal those dependencies and assign corrective actions.
Design and demonstrate a usable recovery capability
Inventory what recovery needs: business data, application and infrastructure configuration, identity services, licences, encryption keys, supplier access and written instructions. Identify a route to the backup system that remains usable if the usual domain, email or cloud administrator is compromised.
Maintain protected copies with appropriate separation, retention and offline or immutable protection where suitable. The familiar 3-2-1 pattern is a planning aid, not a guarantee: three copies can still fail together if one attacker can delete them all or every copy contains the same corrupted state. Confirm which identities can change retention and deletion controls.
- Choose a priority service and agree acceptable downtime and data loss with its business owner.
- Select a plausible failure scenario, including loss of normal administrative access or a supplier dependency.
- Restore into an appropriately isolated, trusted environment using validated recovery material. Record delays and missing dependencies.
- Have the business check that the data and workflows are correct, including changes made during downtime.
- Rehearse the decision to reconnect and the additional monitoring needed afterwards. Resolve defects and repeat the affected checks.
During a real incident, coordinate recovery-point selection and rebuilding with the investigation; a recent backup can contain an existing compromise. If a reputable decryptor is available for a particular variant, evaluate it with specialists on copies under controlled conditions. Do not upload confidential files to an unknown online tool. CISA’s StopRansomware guide provides prevention and response guidance, including protected backups and recovery planning.
Assess data protection and communication duties
Loss of availability or integrity of personal data can itself be a personal data breach, even without proven exfiltration. Assess risks to people and document decisions. Under UK GDPR, notify the ICO without undue delay and within 72 hours of awareness where feasible unless the breach is unlikely to create a risk to rights and freedoms. Higher-risk breaches may require informing affected people without undue delay. ICO ransomware guidance.
Check contractual, sector and other applicable reporting duties as well. Keep communications factual: distinguish confirmed findings from investigation hypotheses and explain what customers or staff need to do.
Payment is not a recovery guarantee
UK and international official guidance discourages ransom payments. Payment does not guarantee a working decryptor, removal of access or deletion of stolen information. It can also raise legal and sanctions issues; obtain appropriate advice for the actual circumstances rather than assuming payment is lawful or necessary.
Record the evidence and decisions, and pursue safe recovery and investigation regardless of any attacker promise. Official Counter Ransomware Initiative guidance.
Common questions
Are immutable backups enough?
They help protect copies, but access, retention, recovery keys, restore capacity and service dependencies still need testing. No single backup feature resolves every incident.
Should we immediately turn everything off?
Not as a universal rule. Coordinate containment with safety and operational owners; shutdown can affect services and evidence. Follow the incident plan and specialist advice.
When can we say recovery is complete?
When the agreed services work safely, integrity and access are validated, material incident paths are addressed and remaining risks and monitoring are owned—not merely when files open again.
Prepare before the next incident
After an incident, review more than the malware. Reconstruct the timeline with the people who investigated, operated affected services and coordinated suppliers. Identify how access was obtained, why the intrusion was not stopped earlier, and what delayed decisions or recovery. Record uncertainty where evidence is missing.
Turn each material lesson into an owned action with a deadline and a test of completion. Address systemic causes, such as an incomplete asset inventory or untested supplier escalation, as well as the individual weakness. Update the response plan, verify the corrections and brief management on unresolved risks.
Further guidance: NCSC CAF: Principle D2, Lessons Learned.
Run a tabletop exercise involving management, IT, business owners and key suppliers. Test contact routes, containment authority, recovery dependencies and communication decisions. Keep response contacts available outside the systems that may be unavailable.
For an active incident, use your established response arrangements. A website enquiry alone is not confirmation of an emergency response engagement or response time.
Need Help?
If you have any questions about cyber security or would like a free consultation, don't hesitate to give us a call!
For More Information Please Contact Us
ACCREDITATIONS
