New Guidance on Recovering Data After a Ransomware Attack

Recovering from ransomware is no longer as simple as removing malware and restoring yesterday’s backup.

Modern ransomware groups often spend time inside an organisation before encryption begins. They may steal confidential information, compromise administrator accounts, disable security tools and attempt to delete or corrupt backups.

If a business restores data without first removing the attacker’s access, it may restore the ransomware alongside it—or allow the criminals to compromise the environment again.

Recent guidance from the UK’s National Cyber Security Centre places particular emphasis on ransomware-resistant backups, clean recovery environments and verifying that data is safe before restoration. The NCSC describes regular backups as one of the most effective ways to recover from destructive ransomware, but stresses that backup systems must themselves be protected against deletion, alteration and unauthorised access. 

For UK businesses, the message is clear: recovery must be planned, secured and tested before an attack occurs.

What Happens During a Ransomware Attack?

Ransomware is malicious software designed to prevent an organisation from accessing its systems or information.

Attackers may encrypt:

• Servers
• Employee devices
• Shared folders
• Databases
• Virtual machines
• Business applications
• Cloud storage
• Connected backups

Many ransomware incidents also involve data theft.

Before encrypting systems, criminals may copy customer information, employee records, contracts, emails or intellectual property. They can then threaten to publish or sell the information if the organisation refuses to pay.

This means recovery involves more than making files accessible again.

The business must determine:

• How the attacker gained access
• Which accounts were compromised
• Whether data was stolen
• Whether backups were affected
• Whether the attacker still has access
• Which systems can be trusted
• Whether legal or regulatory reporting is required

Why Traditional Backup Strategies May Not Be Enough

Businesses frequently assume that having a backup means they can recover safely.

Unfortunately, ransomware operators actively look for backups.

If backup storage is permanently connected to the live environment, protected by the same administrator accounts or accessible through the same management network, an attacker may be able to encrypt or delete it.

The NCSC recommends maintaining backups that are separated from the main network or held within a cloud service specifically designed to protect them. 

A backup strategy can still fail when:

• The attacker obtains backup administrator credentials
• Retention settings allow old copies to be deleted
• Backups are overwritten with encrypted data
• Storage is connected permanently to compromised systems
• Recovery keys are unavailable
• Important applications were never included
• Nobody has tested a full restoration
• Malware was present before the backup was created

The goal is not simply to create copies. It is to ensure at least one trustworthy copy survives the attack.

The Main Principles of Ransomware-Resistant Backups

The NCSC’s ransomware-resistant backup guidance focuses on several important outcomes.

1. Backups Must Resist Destructive Actions

Attackers should not be able to use one compromised account to erase every recovery copy.

Protection may include:

• Immutable backup storage
• Write-once retention
• Delayed deletion
• Separate administrative identities
• Offline copies
• Protected recovery points
• Additional approval for destructive changes

Immutability prevents stored recovery data from being altered or deleted during a defined retention period.

This can provide an essential last line of defence when live systems and ordinary backups have been compromised.

2. Backup Access Must Be Separated

Using the same credentials for everyday administration and backup management creates unnecessary risk.

Backup systems should use:

• Separate administrator accounts
• Strong multi-factor authentication
• Limited management access
• Role-based permissions
• Restricted network connectivity
• Secure emergency-access procedures

An attacker who compromises a Microsoft 365 administrator, domain administrator or server account should not automatically gain control of the backup platform.

3. Unusual Activity Must Be Detectable

Backup platforms should produce alerts for suspicious events such as:

• Large-scale deletion
• Retention-policy changes
• Administrator creation
• Disabled protection
• Unusual logins
• Failed jobs
• Sudden reductions in protected data
• Changes to encryption or recovery settings

These alerts need to be monitored.

A warning generated overnight has little value when nobody reviews it until several days later.

4. Recovery Must Be Tested

A successful backup report does not confirm that the business can restore its services.

Recovery testing should cover:

• Individual files
• Mailboxes
• Databases
• Virtual machines
• Servers
• Cloud applications
• Authentication services
• Full disaster-recovery scenarios

Testing can reveal missing data, damaged applications, expired credentials and unrealistic recovery times before an emergency occurs.

5. Backups Must Be Protected for Long Enough

Attackers may remain inside an environment for weeks before deploying ransomware.

If the business retains only a few recent backup copies, every available version may already contain malicious tools or unauthorised changes.

Retention should therefore reflect:

• How long compromise may remain undetected
• The importance of the data
• Legal retention requirements
• Available storage
• The organisation’s recovery objectives
• The time needed to investigate an incident

Longer retention does not automatically solve the problem, but it provides more possible recovery points.

What Should You Do Immediately After Discovering Ransomware?

Isolate Affected Systems

Disconnect compromised devices and servers from the network where this can be completed safely.

This can reduce the risk of ransomware reaching additional systems.

Avoid destroying potential evidence or making widespread changes without coordination. Incident-response specialists may need system logs, memory data, malicious files and ransom notes to understand what happened.

Contact Your IT and Security Providers

Escalate the incident immediately.

The response may involve:

• Your managed IT provider
• Cyber security specialists
• Cyber insurer
• Legal advisers
• Senior management
• Data-protection personnel
• Communications teams

The earlier appropriate specialists become involved, the more effectively the organisation can contain the attack and preserve evidence.

Activate the Incident-Response Plan

The plan should identify:

• Who has authority to make decisions
• Which systems should be isolated
• How communication will continue
• Who contacts insurers and legal advisers
• How evidence will be preserved
• Which systems must be restored first
• How customers and employees will be updated

Copies of the plan should be available away from the normal IT environment because email, cloud storage and shared folders may be unavailable.

Protect Unaffected Backups

Do not immediately connect every backup system to the compromised network.

Confirm which copies remain protected and prevent further deletion or overwriting.

This may involve:

• Suspending automated backup jobs
• Locking recovery points
• Restricting administrator access
• Contacting the backup provider
• Preserving logs
• Creating additional protected copies

Changes should be coordinated with the incident-response team to avoid damaging evidence or viable recovery options.

Reset Compromised Credentials Carefully

Passwords, authentication tokens, application secrets and administrator credentials may have been stolen.

However, changing everything without a plan could lock the recovery team out of essential systems.

The NCSC advises organisations to reset credentials, particularly administrator and system accounts, while taking care not to lose access to systems required for recovery. 

Credential resets may need to include:

• Domain administrators
• Microsoft 365 administrators
• Backup administrators
• Service accounts
• Remote-access accounts
• Firewall credentials
• Cloud accounts
• Application passwords
• API keys
• Recovery codes

Active sessions should also be revoked where possible.

Do Not Restore Into a Compromised Environment

One of the most important recovery principles is that clean data must be restored into clean systems.

Restoring files onto an infected server can lead to immediate reinfection.

Before restoration, the business should establish:

• Whether the operating system can be trusted
• Whether administrator accounts remain compromised
• Whether malicious persistence has been removed
• Whether the original vulnerability has been fixed
• Whether the backup contains malware
• Whether network connections are safe

The NCSC advises safely wiping infected devices, reinstalling their operating systems and confirming that backups are free from malware before restoration. 

Build a Clean Recovery Environment

A clean recovery environment is separated from systems that may still be compromised.

It may use:

• Newly installed devices
• Clean virtual networks
• Fresh administrator accounts
• Updated operating systems
• Reconfigured firewalls
• New authentication credentials
• Controlled access from trusted devices
• Enhanced monitoring

Critical systems can then be restored and tested before being reconnected to the wider business network.

The environment should not simply recreate the same weaknesses that allowed the initial attack.

How Do You Select a Safe Recovery Point?

The newest backup is not always the safest backup.

If attackers gained access two weeks before encryption, a backup from yesterday may contain:

• Malicious remote-access tools
• Unauthorised administrator accounts
• Changed security settings
• Scheduled malicious tasks
• Compromised applications
• Backdoors

The investigation should help estimate when the compromise began.

Recovery teams can then examine possible restore points and select a copy created before the earliest known malicious activity.

This may require reviewing:

• Authentication logs
• Endpoint alerts
• Firewall logs
• Email records
• Administrator changes
• Application events
• Backup activity
• Threat-intelligence information

Where certainty is impossible, systems should be rebuilt and monitored closely rather than assumed to be safe.

Recover Systems in Business-Priority Order

Attempting to restore everything simultaneously can slow recovery and create confusion.

The organisation should define which services are needed first.

A typical order may include:

1. Identity and authentication
2. Core networking and security
3. Communication systems
4. Essential business applications
5. Customer-facing services
6. File and document platforms
7. Less critical applications
8. Archive and historical information

The correct order depends on how the business operates.

Dependencies must also be considered. A finance application may be the highest business priority, but it may depend on identity services, databases and network components that must be recovered first.

Understand Your Recovery Objectives

Two important measures should guide backup and recovery planning.

Recovery Time Objective

The Recovery Time Objective, or RTO, defines how quickly a system needs to be restored.

A customer-ordering platform may require recovery within hours, while an archive may tolerate several days.

Recovery Point Objective

The Recovery Point Objective, or RPO, defines how much recent data the organisation can afford to lose.

A four-hour RPO means the business accepts that up to four hours of information might be missing after restoration.

RTO and RPO requirements affect:

• Backup frequency
• Storage
• Replication
• Infrastructure design
• Supplier contracts
• Recovery costs

They should be agreed by business leaders rather than determined only by the IT department.

Validate Data Before Returning to Normal Operations

After restoring systems, the recovery team should verify:

• Data completeness
• Application functionality
• User permissions
• Security controls
• Network configuration
• Backup operation
• Logging and monitoring
• Integration with other platforms
• Malware status
• Administrator access

Employees may also need to review business records for changes made during the outage or shortly before the attack.

For example, finance teams may need to reconcile invoices and transactions, while customer-service teams check whether requests were lost.

What About Data Stolen by Attackers?

Restoring backups does not resolve data theft.

If information was exfiltrated, the organisation must determine:

• What data was accessed
• Whose information was involved
• Whether encryption was used
• Whether the data can be misused
• Whether customers, employees or suppliers are at risk
• Whether notification is required

Where a personal data breach is likely to risk individuals’ rights and freedoms, the organisation may need to report it to the Information Commissioner’s Office within 72 hours of becoming aware of it, where feasible. Higher-risk breaches may also require affected individuals to be informed without undue delay. 

Legal and data-protection advice should be obtained early.

Should You Pay the Ransom?

Paying does not guarantee that systems will be restored or stolen information deleted.

The decryption tool may be slow or unreliable, and compromised systems may still need to be rebuilt.

Payments can also involve sanctions risks.

UK financial sanctions prohibit making funds or economic resources available to designated individuals or entities, including through ransomware payments. Breaching financial sanctions can result in criminal or financial penalties. 

Any organisation considering a payment should obtain specialist legal, sanctions, insurance and incident-response advice.

A robust recovery plan should aim to ensure the business is not dependent on a criminal keeping their promise.

Common Recovery Mistakes

Restoring Too Quickly

Pressure to resume work can result in systems being restored before the attacker has been removed.

Trusting the Latest Backup Automatically

Recent backups may contain malicious changes.

Using Compromised Administrator Accounts

This can allow attackers to retain access to recovered systems.

Reconnecting Everything at Once

A staged recovery provides greater control and makes problems easier to identify.

Ignoring Cloud Data

Microsoft 365, cloud applications and hosted databases may also require restoration or investigation.

Assuming Backup Success Means Recovery Success

Backups must be tested through genuine restoration exercises.

Failing to Preserve Evidence

Logs and affected devices may be essential for investigating data theft and initial access.

Rebuilding the Same Vulnerable Environment

Recovery should correct weak remote access, missing patches and poor permissions rather than recreating them.

How to Prepare Before an Attack

The most effective recovery work is completed before ransomware arrives.

Maintain Multiple Backup Copies

The commonly used 3-2-1 principle involves maintaining at least three copies of important information, on two different types of storage, with one copy held offsite.

The NCSC recommends multiple copies in different locations so that one compromised copy does not remove every recovery option. 

Modern strategies may also add:

• An immutable copy
• An offline copy
• A separately administered cloud backup
• Geographic separation

Use Separate Backup Credentials

Backup accounts should not be used for everyday administration.

Protect them using MFA and restrict where they can sign in from.

Test Full Recovery

Do not limit testing to restoring a single document.

Practise recovering an entire critical application or service.

Monitor Backup Changes

Alerts should identify deletion attempts, policy changes and unusual administrator activity.

Keep Systems Updated

Known vulnerabilities in internet-facing systems, firewalls and remote-access platforms are frequently used to gain initial access.

Segment the Network

Network segmentation can limit how far ransomware spreads and help isolate backup infrastructure.

Maintain Offline Documentation

Keep recovery procedures, supplier contacts, licence details and system diagrams available outside the main network.

Run Tabletop Exercises

Simulate a ransomware incident with technical staff, management, finance, legal and communications teams.

This reveals unclear responsibilities before a real crisis.

Review Backup Suppliers Carefully

Ask providers:

• Can backups be made immutable?
• Who can delete recovery points?
• Is MFA enforced?
• Are administrators separated from ordinary users?
• How quickly can large quantities of data be restored?
• Are unusual actions monitored?
• What support is available during an incident?
• How is backup data encrypted?
• Where is it stored?
• How often is recovery tested?

A low-cost backup service may become extremely expensive if it cannot deliver when the business is under attack.

Recovery Is About More Than Data

Successful ransomware recovery means restoring the business safely—not just restoring files.

The organisation must recover:

• Trusted identities
• Secure devices
• Applications
• Networks
• Data
• Customer services
• Supplier connections
• Monitoring
• Confidence

It must also learn how the incident occurred and implement improvements that reduce the likelihood of it happening again.

The recovery process should result in a stronger environment than the one that was compromised.

How Hamilton Group Can Help

Hamilton Group can help businesses prepare for ransomware, protect their backup systems and recover safely after an incident.

Our services can include:

• Backup and disaster-recovery reviews
• Ransomware-resistant backup design
• Immutable and isolated backups
• Backup monitoring
• Recovery testing
• Incident-response planning
• Microsoft 365 backup
• Server and cloud recovery
• Endpoint protection
• Vulnerability scanning
• Patch management
• Security monitoring
• Managed IT support

We can review whether your existing backups are genuinely protected against ransomware, establish realistic recovery objectives and help create a documented recovery plan.

To discuss ransomware recovery and backup resilience for your organisation, contact Hamilton Group on 0330 043 0069 and book an appointment with one of our experts.