⏱ 11 min read | Structured incident response guide |
What to do if your business is hit by ransomware: A practical incident response guide
A ransomware attack is no longer simply an IT problem. It can become a business continuity, data protection, legal, regulatory, financial and reputational crisis within hours.
Many businesses still assume that ransomware means their files have been encrypted and that restoring a backup will solve the problem. Modern ransomware attacks are often much more complicated.
Attackers may spend days or weeks inside an environment before encryption takes place. During that time, they may compromise accounts, escalate privileges, move between systems, identify backups, search for sensitive information and potentially copy data out of the organisation.
By the time the ransom note appears, the encryption may therefore be only one part of the incident.
The most important thing to understand about ransomware: recovering encrypted files is only one part of recovering from the attack. You also need to understand how the attackers got in, whether they still have access, what systems and data they may have accessed, what reporting or notification obligations exist, and what needs to change before the incident can genuinely be considered closed.
Before restoring backups, rebuilding servers or wiping devices, stop and complete these actions first.
2. Protect backups
3. Preserve evidence
4. Get specialist help
Do not wipe or rebuild systems until evidence has been preserved and the attack scope has been understood. This guide is a practical framework, not a substitute for specialist incident response, legal advice or regulatory advice.
Ransomware incident response: Quick navigation
If you are dealing with an active incident, use the sections below to jump directly to the information you need.
First hours
Containment
How ransomware works
Data theft
Digital forensics
Recovery
ICO & reporting
Communications
Ransom demand
Dark web
First 30 days
Prevention
FAQs
Before you start: Separate what you know from what you think you know
One of the biggest mistakes organisations make after a ransomware attack is assuming they already know what happened.
You may believe the attacker entered through a VPN, that a phishing email caused the incident, that a firewall vulnerability was exploited, that only a handful of systems were affected or that no data was stolen.
Unless you have detailed logging, endpoint visibility, network monitoring and appropriate forensic evidence, these may only be working theories.
VPN, stolen credentials, phishing, exposed services, vulnerable software or another route?
The encryption date may not be the date the compromise began.
Privileged access can dramatically increase the scope of an incident.
Servers, endpoints, cloud services, file shares, backups and identity systems may all matter.
Access, exposure and confirmed exfiltration are different questions.
Recovery can be risky if an attacker still has access to the environment.
Do not confuse an assumption with an established fact. The purpose of the investigation is to replace assumptions with evidence.
What should you do in the first few hours after a ransomware attack?
The first few hours are about containment, preservation and control. They are not about making the environment look normal again as quickly as possible.
Your immediate objectives should be to prevent the attack spreading, protect recovery systems, preserve evidence and establish who is responsible for coordinating the response.
Contain
Stop the attack spreading.
Preserve
Protect evidence and logs.
Assess
Understand the scope.
Recover
Restore critical operations safely.
Step 1: Contain the ransomware attack
The first technical priority is to stop the attacker and the malware from causing further damage.
Immediate containment checklist
- Isolate infected computers and servers.
- Disconnect affected systems from network connections where appropriate.
- Consider whether inbound and outbound access needs to be disabled.
- Disable accounts that are known or strongly suspected to be compromised.
- Protect privileged and administrator accounts.
- Review whether backup infrastructure has been targeted.
- Preserve firewall, VPN, endpoint and authentication logs.
- Protect Microsoft 365 and cloud audit information.
- Record the time and reason for every significant action.
- Escalate to specialist incident response where appropriate.
Do not blindly wipe everything. Rebuilding systems immediately may remove evidence that could help establish how the attacker entered, what they did and whether they still have access.
The NCSC advises organisations experiencing ransomware to disconnect infected devices from network connections and, in serious cases, consider wider network isolation. It also recommends resetting credentials while taking care not to lock responders out of systems required for recovery.
Establish an incident lead
A ransomware incident can quickly become chaotic if everyone is making decisions independently.
Someone should coordinate the overall response, even if the organisation is small.
Step 2: Understand what modern ransomware actually does
Ransomware is usually better understood as a process rather than a single piece of malware.
The exact sequence varies between attacks. Attacks could be carried out manually, but the majority are typically automated for the most part. A typical incident may involve several stages.
Initial access
Phishing, stolen credentials, exposed services, vulnerable systems or remote access.
Privilege escalation
The attacker seeks higher levels of access, potentially including administrator privileges.
Discovery
Systems, users, file shares, backups and valuable information are identified.
Data access
Sensitive information may be searched, staged or potentially exfiltrated.
Encryption
Systems and files may be encrypted or otherwise disrupted.
Extortion
The attacker demands payment and may threaten to release stolen information.
Pressure
Attackers may contact customers, employees, suppliers or the media.
Recovery
The business must contain, investigate, recover and rebuild securely.
Step 3: Determine whether data was stolen
This is often the first question management asks after ransomware:
“Did the attackers steal our data?”
Unfortunately, it is often one of the hardest questions to answer with certainty.
Many organisations do not have sufficient logging or security telemetry to establish exactly which files were accessed or copied.
Access, exposure and exfiltration are different
🔓 Access
The attacker was able to reach a system or location containing information.
👁️ Exposure
The attacker had an opportunity to view or discover information.
📤 Exfiltration
Evidence indicates information was actually copied and removed from the environment.
📢 Disclosure
Information has subsequently been published, shared or otherwise exposed outside the organisation.
These outcomes are related, but they are not interchangeable.
Screenshots, file names, folder structures or document previews published by an attacker may demonstrate some level of access or discovery. They do not necessarily prove that every file shown was copied.
The opposite is also true. The absence of obvious evidence of data theft does not prove that no data was exfiltrated.
The absence of evidence is not evidence of absence. Where visibility is limited, the organisation should continue investigating rather than prematurely declaring that no data was stolen.
What information might attackers look for?
- HR records
- Payroll information
- Customer records
- Financial information
- Contracts
- Legal documents
- Identity documents
- Intellectual property
- Credentials and secrets
- Commercially sensitive information
Preparation tip: Many SMEs cannot confidently answer three critical questions: What data do we hold? Where is it stored? And how sensitive is it? If a ransomware incident occurs, those gaps can significantly slow down the investigation. Identifying, classifying and reducing unnecessary data now will make it much easier to determine what attackers may have accessed in the future.
Step 4: Investigate the attack and consider digital forensics
If sensitive information may have been exposed, a specialist incident response or digital forensics investigation can be one of the most important investments following an attack.
The objective is not simply to find the ransomware executable. The objective is to understand the attack path, scope, impact and remaining risk.
What can a forensic investigation help establish?
| Investigation area | Key Question |
|---|---|
| 🔓 Initial access | How did the attackers gain their initial foothold? |
| ⏱️ Dwell time | How long may the attacker have been inside the environment? |
| 🔑 Privilege escalation | Did the attacker obtain administrator or other privileged access? |
| 🔀 Lateral movement | Which systems, devices and accounts did they move through? |
| 📂 Data access | Which information may have been accessible or exposed? |
| 📤 Exfiltration | Is there evidence that data was staged, copied or transferred outside the organisation? |
Evidence worth preserving
- Firewall logs
- VPN logs
- Domain controller logs
- Windows security logs
- Microsoft 365 audit logs
- Entra ID sign-in information
- EDR alerts and telemetry
- RMM activity
- Backup logs
- File access auditing
- Email security logs
- Relevant system images
Indicators worth investigating
A modern attacker may deliberately use legitimate administration tools and encrypted communications, so the absence of one obvious indicator should not be treated as proof that no malicious activity occurred.
- Large or unusual outbound data transfers
- Creation of ZIP, RAR or 7Z archives
- Unexpected PowerShell or scripting activity
- Use of remote administration tools
- Unusual administrator activity
- Unexpected privileged account usage
- Authentication at unusual times
- New accounts or changes to existing accounts
- Attempts to disable security or backup systems
Important: a forensic investigation may not always be able to determine exactly which individual files were stolen. That does not make the investigation pointless. Establishing how the attacker entered, what they accessed, what privileges they obtained and whether there is evidence of exfiltration can materially improve the organisation’s risk assessment and recovery decisions.
Build an incident timeline
Create a single timeline from the moment the incident is discovered. Record facts, actions and decisions rather than relying on memory.
| Time | Event | Evidence | Action / decision |
|---|---|---|---|
| 08:15 | First ransomware alert | EDR / user report | Device isolated |
| 08:40 | File server inaccessible | Server logs | Server isolated |
| 09:10 | Suspicious administrator activity | Identity logs | Account disabled |
| 10:00 | Backup infrastructure reviewed | Backup logs | Recovery paused pending assessment |
The actual timeline will be specific to your incident. The important thing is to establish a consistent record that can be shared with management, insurers, legal advisers, investigators and regulators where appropriate.
Download the ransomware incident response first 24 hours checklist
Don’t try to remember everything during a crisis. A checklist can help your team work through the immediate containment, evidence preservation, account security, backup protection and escalation steps in the right order.
Not sure how to get started?
Step 5: Recover safely – don’t just restore the backup
One of the most dangerous assumptions after ransomware is:
“We have backups, so we can simply restore everything.”
Backups are essential, but restoration is only one part of recovery.
Before restoring systems, you need reasonable confidence that the attacker has been removed, compromised credentials have been addressed and the recovery environment itself can be trusted.
Ask these questions before restoration
For example, has the vulnerable VPN, application, firewall or compromised account been addressed?
If administrator credentials were compromised, restoring a server alone may not remove the attacker’s ability to return.
Establish whether the attacker may have accessed or altered the backup environment.
Identity is a critical dependency. Compromised accounts can undermine otherwise clean recovery.
Recovery should include appropriate monitoring rather than simply reconnecting systems and hoping for the best.
Prioritise business-critical services rather than attempting to restore everything simultaneously.
The NCSC’s current recovery guidance emphasises that organisations should establish whether the attacker has been evicted before proceeding with recovery and should work towards minimum viable operations rather than treating restoration of technology as the entire recovery objective.
Recover to minimum viable operations
Instead of asking “How do we get all our IT back?”, ask:
“What does the business absolutely need in order to operate safely today?”
🔴 Critical
Services required immediately for safety, revenue, customers, payroll or regulatory obligations.
🟠 Important
Services required within the next few days to stabilise normal operations.
🟢 Deferred
Systems that can remain unavailable while critical operations are restored.
Temporary workarounds may be necessary. However, those workarounds should themselves be security reviewed so that the recovery process does not create a second vulnerability.
Do not assume every backup is safe
Attackers increasingly understand that backups are one of the biggest obstacles to successful extortion. Backup infrastructure should therefore be treated as part of the incident investigation.
Consider:
- When was the attacker first present?
- When were backups last known to be clean?
- Were backup credentials exposed?
- Were backup servers encrypted?
- Can backups be restored into a clean environment?
- Have restored systems been scanned and monitored?
- Do backups include identity and application dependencies?
- Can the business actually restore critical services within the required timeframe?
Step 6: Consider your ICO and data protection obligations
Ransomware and data protection are closely connected.
Importantly, a ransomware incident can constitute a personal data breach even where there is no evidence that data was exfiltrated. If personal data has been encrypted and the organisation loses timely access to it, that can itself constitute a breach. Whether the incident must be reported to the ICO depends on the risk to individuals.
Does every ransomware attack need to be reported to the ICO?
No. You need to assess whether a personal data breach has occurred and then assess the likely risk to individuals.
If a personal data breach is likely to result in a risk to people’s rights and freedoms, it should be reported to the ICO without undue delay and, where feasible, within 72 hours of becoming aware of it.
You do not need to have completed the entire forensic investigation before making an initial notification. The ICO recognises that information may be incomplete and allows additional information to be supplied later.
Do not wait for perfect information. If the incident is potentially reportable, begin the assessment early. You can continue developing the factual picture as the investigation progresses.
What should you record?
- Incident timeline
- Investigation findings
- Technical evidence
- Forensic reports
- Risk assessments
- Client notifications
- Board decisions
- Mitigation measures
- Regulatory correspondence
- New evidence as it emerges
The ICO expects organisations to keep records of personal data breaches, including those that do not ultimately require notification.
Should you report a ransomware attack?
Reporting requirements depend on the circumstances, sector and jurisdictions involved.
Consider whether you need to engage:
Where a personal data breach creates a reportable risk.
For significant criminal activity and intelligence sharing.
Some industries have additional incident reporting requirements.
Customers, suppliers or partners may have contractual notification requirements.
Insurance policies may contain specific notification and approved-provider requirements.
Significant incidents may warrant engagement with the appropriate national cyber security or law-enforcement bodies.
Step 7: Prepare for client and stakeholder notifications
Do not wait until information appears on a leak site before thinking about who may need to be contacted.
Start building an inventory of the information potentially affected and the people or organisations who could be impacted.
Identify potentially affected information
- Employee information
- Customer records
- Financial information
- Identification documents
- Legal documents
- Special category data
- Supplier information
- Contracts
- Credentials
- Commercially sensitive information
Identify who may be affected
- Employees
- Customers
- Former customers
- Suppliers
- Business partners
- Professional advisers
- Regulators
- Other affected third parties
Step 8: Develop a clear communication strategy
Many organisations focus almost entirely on technical recovery and underestimate the importance of communication.
During a serious incident, customers may be asking whether their data is safe, employees may be unsure what they can tell people, suppliers may be worried about connecting to your environment and management may be receiving conflicting information.
The objective is not to have every answer immediately.
The objective is to communicate honestly, consistently and clearly about what is known, what is not yet known and what is being done.
✅ Always
- Share confirmed facts.
- Acknowledge uncertainty.
- Explain what actions are being taken.
- Provide realistic updates.
- Coordinate messaging internally.
❌ Avoid
- Guessing the scale of the breach.
- Making assumptions.
- Assigning blame during the investigation.
- Downplaying uncertainty.
- Making promises that cannot be verified.
Step 9: Should a business pay a ransomware ransom?
This is one of the most difficult questions a business can face.
There is no universal answer that can be applied to every incident, and a ransom payment decision should not be made simply because an attacker is applying pressure.
Do not make a ransom payment decision in isolation or under pressure. Involve appropriate legal, insurance, incident response and other specialist advisers before taking action.
What does paying a ransom actually guarantee?
Unfortunately, very little.
- It does not guarantee data deletion.
- It does not guarantee confidentiality.
- It does not guarantee complete recovery.
- It does not guarantee that data will not be published.
- It does not remove the original vulnerability.
- It does not guarantee that the attacker will not return.
The NCSC and UK law enforcement do not encourage, endorse or condone ransom payment. Current NCSC guidance also stresses that payment does not address underlying vulnerabilities and that organisations need to consider legal, operational, ethical and reputational factors.
There may also be sanctions and other legal considerations around payments to particular criminal groups or entities, so appropriate specialist advice is essential before any payment decision is made.
Step 10: Monitor for leaked information and compromised credentials
If attackers claim to have stolen information, monitoring becomes an important part of the incident response.
What should you monitor?
Look for evidence that organisational or personal information has been released.
Monitor for exposed employee accounts, passwords and authentication information.
Watch for personal information appearing in leaked material.
Identify whether client records or documents appear to have been released.
Look for references to your company, brands and domains.
Monitor for phishing, fraudulent domains and brand abuse following the incident.
Do not investigate criminal leak sites yourself
There can be a strong temptation for a business owner or IT administrator to visit a ransomware group’s leak site to see whether their data has been published.
We strongly recommend against sending ordinary staff onto criminal leak sites to investigate an incident.
These environments can expose visitors to malware, malicious downloads, credential harvesting, browser exploits, tracking mechanisms and further attack infrastructure.
Where monitoring is required, use an appropriate cyber intelligence, incident response or digital forensics provider with suitable isolated environments and specialist tooling.
Step 11: What if the attackers eventually publish the data?
A ransomware group’s claims should neither be automatically believed nor automatically dismissed.
Attackers may:
- Publish screenshots.
- Release sample documents.
- Publish partial datasets.
- Release information in stages.
- Sell information privately.
- Use leaked information for further extortion.
- Publish nothing despite making claims.
- Overstate the amount of information they possess.
A screenshot or sample document can demonstrate that an attacker had some level of access, but it may not establish the complete extent of data exfiltration.
Equally, the absence of a leak does not prove that no data was stolen.
Keep investigating even after the immediate crisis appears to be over.The scope of data compromise may only become clearer as forensic evidence, intelligence and leaked information are correlated.
Recovery does not always mean the risk has ended
Even after systems have been restored and operations have returned to normal, organisations should consider ongoing monitoring for stolen data. In many ransomware incidents, threat actors retain copies of exfiltrated information and may publish it weeks or even months later on ransomware leak sites, criminal forums or other underground platforms.
A digital risk protection or dark web monitoring service can help identify newly leaked company data, exposed employee credentials and references to your organisation before customers, suppliers or staff become aware of the disclosure themselves.
Early visibility can provide valuable time to assess the impact, support regulatory decision-making, update communications plans and understand exactly what information has been published.
Evidence preservation is already included within our free “First 24 hours ransomware checklist.”
Download the full checklist for guidance on preserving logs, system evidence, account activity and other information that may be needed during an investigation.
Your first 30 days after a ransomware attack
Recovery is rarely completed in a single day. The first 30 days should be treated as a structured programme rather than a series of disconnected technical tasks.
Contain
Stop the attack spreading and establish control of the incident.
- Isolate affected systems
- Protect backup infrastructure
- Preserve evidence
- Disable compromised accounts
- Establish incident leadership
- Contact specialist responders and insurers
Understand
Determine what happened, what was affected and whether data was exposed.
- Begin forensic investigation
- Determine likely initial access
- Assess privilege escalation
- Assess lateral movement
- Assess possible data exposure
- Begin recovery planning
Stabilise
Restore critical operations while reducing ongoing risk.
- Restore priority business services
- Reset compromised credentials
- Increase monitoring
- Prepare customer communications
- Monitor for credential exposure
- Review critical security controls
Rebuild
Address root causes and strengthen long-term resilience.
- Complete root cause analysis
- Remediate vulnerabilities
- Strengthen identity security
- Review remote access controls
- Improve endpoint monitoring
- Test backup and recovery processes
- Document lessons learned
Beyond 30 days: turn recovery into resilience
The incident should not be considered finished simply because the systems are working again.
The final objective is to understand why the incident happened, close the weaknesses that enabled it and improve the organisation’s ability to detect, contain and recover from the next incident.
Remediate
Close vulnerabilities, strengthen identity, review privileged access, improve network controls and confirm backup integrity.
Validate
Conduct vulnerability assessment, penetration testing, recovery testing and an incident response exercise.
Build resilience
Embed ongoing monitoring, security governance, staff training, supplier assurance and regular recovery exercises.
How to prevent another ransomware attack
Once the immediate incident is under control, the organisation should move from recovery to prevention and resilience.
1. Strengthen identity security
- Enable MFA wherever possible.
- Protect administrator accounts.
- Use separate privileged accounts.
- Review inactive accounts.
- Monitor unusual authentication.
- Review conditional access policies.
- Remove unnecessary privileged access.
- Regularly review service accounts.
2. Improve endpoint protection
Traditional antivirus alone may not provide sufficient visibility into a modern intrusion.
Consider appropriate endpoint detection and response (EDR) or managed detection and response (MDR), particularly where internal teams cannot continuously monitor endpoint telemetry.
3. Improve vulnerability management
Identify and remediate critical vulnerabilities quickly.
Regularly identify weaknesses across the environment.
Review exposed services, rules and unnecessary internet access.
Test whether weaknesses can be chained into meaningful attack paths.
4. Protect backups
A backup that cannot be trusted or restored is not a reliable recovery strategy.
Consider maintaining multiple copies, separate storage mechanisms and an appropriately protected immutable or offline recovery copy. Most importantly, test restoration.
5. Reduce the external attack surface
- Review VPN exposure.
- Remove unnecessary Remote Desktop exposure.
- Review open firewall ports.
- Remove legacy authentication where possible.
- Retire unsupported operating systems.
- Review externally exposed applications.
- Monitor internet-facing assets.
- Review third-party remote access.
6. Improve security awareness
Technology is only part of the defence.
Staff should receive practical, ongoing training covering phishing, malicious attachments, password security, MFA fatigue, social engineering and the correct process for reporting suspicious activity.
7. Test your recovery plan
An incident response plan that exists only as a document has limited value.
Test it.
Questions worth testing
If you cannot answer these confidently, your recovery plan may need work.
How quickly can we respond?
Who gets called first and who has authority to make decisions?
Can we actually restore?
Have backups been tested recently under realistic conditions?
Can the business operate?
What happens if Microsoft 365, file servers or key applications are unavailable?
Can we trust our identity?
What happens if administrator accounts and identity systems are compromised?
Who communicates?
Can you communicate consistently with staff, customers, suppliers and regulators?
Have we rehearsed it?
Have the people responsible actually practised the incident response process?
What good ransomware preparedness looks like
Businesses do not need an unlimited cyber security budget to become more resilient. They do need visibility, preparation, sensible controls and a clear response process.
MFA, privileged access controls and strong authentication.
EDR, patching, firewalls and secure configurations.
Logging, monitoring and meaningful security alerts.
Protected, tested and recoverable backups.
A documented and tested incident response plan.
Business continuity and minimum viable operations planning.
Download the ransomware recovery planner
Use a practical 30/60/90-day planner to track containment, investigation, recovery, remediation and resilience actions after a cyber incident.
Common mistakes businesses make after ransomware
🚫 Wiping systems immediately
Rebuilding before evidence is preserved can make it much harder to understand what happened.
🚫 Assuming the backup solves everything
A clean backup does not automatically remove compromised accounts or an attacker’s persistence.
🚫 Assuming no leak means no theft
Attackers may retain information privately or release it later.
🚫 Treating ransomware as only an IT problem
Recovery also involves business continuity, legal, regulatory, customer and reputational considerations.
🚫 Waiting for perfect information
Some decisions, including regulatory assessments, need to begin before the forensic picture is complete.
🚫 Forgetting to test the recovery plan
A theoretical recovery plan can fail when real systems, people and suppliers are under pressure.
Final thoughts: ransomware recovery is bigger than restoring files
The organisations that recover best from ransomware are not necessarily those with the largest IT budgets.
They are often the organisations that can establish control quickly, preserve evidence, make informed decisions and keep the business operating while the investigation continues.
If there is one lesson to take away from this guide, it is this:
Do not focus solely on recovering encrypted files. Focus on understanding how the attackers got in, whether they still have access, what they may have accessed, what data may have been compromised, what obligations the business has and what needs to change before the incident can genuinely be considered closed.
A ransomware incident is simultaneously a technology incident, a business continuity incident, a potential data protection incident and, in many cases, a significant legal and reputational event.
The technical recovery is important. But understanding the incident, managing the uncertainty and rebuilding the organisation in a more resilient way is what turns recovery into genuine cyber resilience.
Cyber incident response & digital forensics
If your organisation has suffered ransomware or another serious security incident, the priority is to establish control, preserve evidence and understand what happened before making major recovery decisions.
Help isolate affected systems and reduce the risk of further compromise.
Investigate the attack path, affected systems, accounts and potential data exposure.
Protect the technical evidence required for investigation, insurance, legal and regulatory purposes.
Support a controlled recovery rather than simply restoring systems and hoping the threat has gone.
If you are dealing with an active incident, specialist help should be brought in as early as possible.
Ransomware incident response FAQs
Continue your cyber resilience journey
Ransomware response is only one part of building a resilient IT environment. The next step is to understand where your organisation is exposed and prioritise the controls that will make the greatest difference.
Important: This guide is intended to provide general practical information for businesses dealing with cyber incidents. It is not legal, regulatory, forensic or insurance advice. Every incident is different, and organisations should obtain appropriate specialist advice based on the circumstances of the attack.
