Most businesses know they need backups. Fewer know whether those backups would still be usable after a serious ransomware attack.
That distinction matters because ransomware operators may deliberately target recovery systems before encrypting production data. If attackers can delete backup copies, disable backup administrators, corrupt recent versions, or compromise the systems needed for restoration, a business can have a backup platform and still be unable to recover.
A ransomware readiness assessment looks beyond whether backups exist. It examines whether they are isolated appropriately, protected from destructive actions, monitored for suspicious changes, and capable of restoring the systems the organisation actually needs.
NCSC guidance specifically warns that attackers may target backup infrastructure early in destructive ransomware incidents to make recovery harder and increase pressure on victims.
Having Backups Is Not the Same as Being Ready to Recover
Consider a company that backs up every production server each night.
On paper, the arrangement sounds reassuring. However, the same domain administrator credentials can manage both production servers and the backup platform. Backup storage remains permanently reachable from the corporate network, while nobody has completed a full restoration test for eighteen months.
Now imagine an attacker gains domain administrator privileges.
Instead of encrypting systems immediately, they first locate the backup platform. Retention settings are changed, recent copies are deleted, administrator accounts are disabled, and several days of corrupted data are allowed to enter the backup cycle.
Only then does the ransomware payload activate.
At that point, the organisation does not merely have an encryption problem. Its recovery plan has also been attacked.
For this reason, a ransomware readiness assessment should test the separation between compromise and recovery, not simply confirm that scheduled backup jobs show a green status.
Six Questions a Ransomware Readiness Assessment Should Answer
A useful assessment should approach the backup environment from an attacker’s perspective while staying within agreed safety boundaries.
The goal is to understand what would happen after a serious compromise and whether recovery controls remain available when ordinary production systems can no longer be trusted.
1. Can an Attacker Reach Backups Using the Same Credentials?
Credential separation is one of the most important ransomware controls.
If a domain administrator, cloud administrator, or other broadly privileged identity can also control the backup platform, compromising one account may provide control over both production and recovery.
NCSC guidance recommends isolating backup credentials from those used to administer the wider network. It also advises organisations to restrict backup-management interfaces and apply least privilege to both logical and physical access.
During an assessment, testers can examine whether backup administrators use separate identities, whether MFA protects destructive actions, and whether ordinary privileged accounts can reach the backup-management interface.
Where Active Directory or another central identity system controls large parts of the environment, Active Directory and identity VAPT can provide additional insight into how credential compromise might spread.
The key question is simple: does compromising production automatically compromise recovery?
2. Can Backup Data Be Deleted, Altered, or Encrypted?
A backup that attackers can destroy on demand offers limited protection against ransomware.
Consequently, organisations increasingly use controls such as immutability, write-once storage, soft deletion, delayed deletion, offline media, or administrative separation to make destructive actions more difficult.
NCSC’s ransomware-resistant backup principles recommend designing backup systems so data cannot easily be altered or deleted after creation. For on-premises environments, the guidance also discusses network segregation and physically disconnected backup media where appropriate.
A readiness assessment should therefore examine what happens if an administrator attempts to remove or modify large amounts of backup data.
Important questions include:
- Can one administrator delete all recovery points?
- Does deletion require additional authentication?
- Is there an immutable or protected retention period?
- Can backup policies be weakened without approval?
- Are deletion requests delayed?
- Would mass changes trigger an alert?
The strongest design assumes that privileged credentials may eventually be compromised and makes destructive actions difficult even in that situation.
3. Can You Restore from a Clean Point Before the Attack?
Recent does not always mean safe.
An attacker may remain inside an environment for some time before ransomware is deployed. During that period, compromised files, malicious configurations, or encrypted data can enter routine backups.
Restoring only the most recent version could therefore reintroduce the problem.
NCSC recommends retaining version history and using time-based retention so organisations can restore from a point before corruption occurred. It also recommends regular testing to identify whether backups themselves have become unusable.
For businesses, this means recovery planning should answer:
How far back could we realistically restore if we discovered the attacker had been present for two weeks?
The answer depends on retention policies, backup capacity, application requirements, and how quickly compromise can be identified.
A readiness assessment can expose situations where nominal retention sounds sufficient but practical recovery options are much narrower.
4. Do You Know What Needs to Be Restored First?
During an incident, restoring everything simultaneously may not be possible.
Businesses therefore need to know which services matter most and what those services depend on.
For example, restoring a customer application may achieve little if the identity platform, database, DNS service, storage layer, and supporting network services remain unavailable.
Recovery priorities should follow business dependencies rather than an arbitrary list of servers.
A practical restoration sequence might consider:
- Identity and essential infrastructure
- Backup-management and recovery systems
- Critical databases
- Revenue-generating or customer-facing applications
- Essential employee services
- Lower-priority systems
The exact order will differ between organisations.
CISA’s ransomware guidance recommends restoring from offline encrypted backups according to the priority of critical services rather than reconnecting systems indiscriminately.
A readiness assessment can help determine whether recovery documentation reflects those dependencies or simply lists systems without explaining the order in which they need to return.
5. Can You Recover Without Trusting the Compromised Environment?
A serious ransomware incident can make familiar infrastructure unsafe.
Domain controllers may be compromised. Administrator workstations could contain malware. Passwords may have been stolen. Existing servers might need rebuilding rather than simply decrypting.
Consequently, recovery plans should not assume that every system required for restoration will still be trustworthy.
CISA advises organisations to reconnect clean systems carefully and warns against reinfecting recovered environments during restoration.
Assessment questions may therefore include:
- Can backup administrators authenticate if the normal identity platform is unavailable?
- Are clean administrator devices available?
- Can critical servers be rebuilt from trusted images?
- Are software installers, configuration templates, licences, and keys recoverable?
- Can the business access backup data if ordinary corporate infrastructure is offline?
- Are recovery credentials stored securely outside the compromised environment?
This is where a recovery plan starts to become operational rather than theoretical.
6. Would You Notice Someone Attacking the Backup System?
Backup infrastructure often receives less security monitoring than production systems.
That creates an opportunity for attackers.
A threat actor who changes retention settings, disables jobs, creates new administrators, alters encryption policies, or attempts mass deletion may be preparing the organisation for a much more damaging ransomware event.
NCSC recommends generating alerts for significant backup changes and privileged actions, including deletion attempts, retention changes, administrator modifications, and backups unexpectedly stopping.
However, an alert has little value if it disappears into an unattended mailbox.
The assessment should therefore examine both detection and response.
If somebody attempted to delete every backup at 2:00 am, who would know, how quickly would they know, and what could they do about it?
What Can VAPT Safely Test Around Backup Infrastructure?
Backup systems are sensitive. A poorly controlled test could disrupt recovery capability rather than validate it.
Therefore, testing should use an agreed methodology and avoid destructive actions unless a dedicated test environment exists and explicit approval has been given.
Useful VAPT activities may include:
| Assessment area | What testing can establish |
| Backup management access | Whether unauthorised systems or users can reach management interfaces |
| Privileged identities | Whether credentials are separated and appropriately protected |
| Network segmentation | Whether compromised production systems can connect directly to backup infrastructure |
| Backup software exposure | Whether vulnerable or unnecessary services are accessible |
| Administrative controls | Whether sensitive changes require stronger authentication or approval |
| Monitoring | Whether suspicious administrative activity generates useful alerts |
| Recovery procedures | Whether selected systems can be restored successfully |
| Integration security | Whether agents, APIs, service accounts, or automation introduce excessive access |
The objective is not to prove that an assessor can delete the organisation’s backups.
Instead, testing should establish whether architecture provides a realistic path towards that outcome and whether preventive controls would stop it.
Where an attacker could move freely from an ordinary internal system towards privileged infrastructure, an internal network VAPT assessment may also help expose the access paths that make backup compromise possible.
A Successful File Restore Does Not Prove Ransomware Readiness
Many organisations test backups by restoring one document.
That confirms something useful: the selected file existed in the backup and could be retrieved.
However, ransomware recovery requires much more.
A business may need to restore complete servers, databases, identity services, configuration, encryption keys, application dependencies, cloud resources, and network functionality.
Performance matters too.
Suppose a company holds 80 TB of production information. A backup platform may technically contain every byte, yet restoring it across available bandwidth could take far longer than the business can tolerate.
Therefore, a meaningful recovery test should consider:
Recovery Point Objective (RPO): How much recent data could the business afford to lose?
Recovery Time Objective (RTO): How long can the service remain unavailable?
A backup can be technically successful while failing both business requirements.
For example, nightly backups might satisfy an RPO of 24 hours. However, if restoration takes five days and the business requires its ordering system back within eight hours, the recovery design still has a serious gap.
Test Recovery as a Service, Not as Individual Servers
Modern applications rarely operate independently.
Consider an e-commerce platform.
The web server may depend on a database, identity service, object storage, payment integration, DNS, certificates, API services, and cloud networking.
Restoring only the web server does not restore the store.
The same issue affects healthcare platforms, SaaS products, file environments, accounting systems, manufacturing technology, and internal business applications.
For this reason, recovery exercises should test complete business services where practical.
A useful test might ask:
Can we restore the customer portal, its database, authentication, required network services, and necessary secrets into a trusted environment within our target recovery time?
That question produces far more useful assurance than asking whether a single virtual machine can be recovered.
A Ransomware Scenario Can Reveal Gaps That Backup Dashboards Cannot
Consider a business with 200 employees. An employee device is compromised through phishing. The attacker obtains reusable credentials, moves through the internal network, and eventually gains a privileged identity. Rather than deploying ransomware immediately, the attacker spends several days preparing.
Backup management interfaces are discovered. Retention is shortened. Several recovery points are deleted. Endpoint security exclusions are created. Additional administrator accounts provide persistence.
Only after weakening recovery does encryption begin. A normal backup dashboard may have looked healthy for much of that period. A ransomware readiness exercise asks a different set of questions:
- Could segmentation have prevented access to the backup platform?
- Were separate backup credentials protected from compromise?
- Would privileged changes have triggered alerts?
- Could protected recovery points survive the attack?
- Could administrators still reach backups after identity systems were compromised?
- How quickly could critical business services return?
Those answers provide a much clearer picture of ransomware resilience.
What Should “Ready” Actually Mean?
No organisation can guarantee that ransomware will never cause disruption. A useful readiness standard is more practical. The organisation should be able to demonstrate that:
- Critical information is backed up according to defined recovery requirements.
- Attackers cannot easily destroy every usable recovery copy.
- Backup administration is separated from normal production administration.
- Important changes and deletion attempts generate monitored alerts.
- Multiple recovery points allow restoration from before a compromise.
- Critical systems have an agreed restoration order.
- Recovery does not depend entirely on infrastructure that may itself be compromised.
- Restore procedures have been tested recently enough to remain credible.
- Recovery times have been compared with actual business requirements.
NCSC’s ransomware-resistant backup guidance provides useful principles for evaluating both cloud and on-premises backup designs against destructive ransomware threats. Check out NCSC ransomware-resistant backup guidance.
CISA’s StopRansomware Guide also provides practical recommendations covering offline encrypted backups, regular recovery testing, critical-system restoration, and post-incident recovery. Refer to CISA StopRansomware Guide for further information.
Final Thoughts
Backups are essential, but ransomware readiness depends on whether those backups remain protected and usable when the rest of the environment is under attack. Organisations should test credential separation, backup isolation, destructive-action controls, monitoring, retention, restoration, and recovery dependencies before an incident forces them to discover weaknesses under pressure.
Aegixis VAPT Services can help assess the technical controls surrounding backup and recovery infrastructure as part of a broader ransomware readiness review. By testing relevant access paths, privilege boundaries, network exposure, and recovery assumptions, Aegixis can help identify weaknesses that could prevent successful restoration and provide practical remediation guidance before those gaps are tested by a real attack.
