Cyber Resilience Board Briefing Series 4: The Illusion of Clean Backups
Why having historical data does not automatically mean trusted recovery
The Issue
One of the most dangerous assumptions in cyber recovery is that a backup is clean simply because it is historical.
It is a comforting idea: if ransomware encrypted systems today, surely yesterday's backup is safe? If yesterday is questionable, perhaps last week is safe? If last week is questionable, perhaps last month is safe? Unfortunately, destructive cyberattacks do not work to neat operational timelines or your backup schedules.
In many ransomware and wiper incidents, the attacker has been inside the environment long before encryption,[RS1][JB2] extortion or destruction becomes visible. During that period, they may have compromised credentials, moved laterally, disabled security tooling, modified configurations, created persistence mechanisms, staged tooling, exfiltrated data, weakened recovery paths or altered identity permissions. They may have even have gotten in via vulnerabilities in operating systems, applications or configurations.
That means historical data is not automatically trusted data. A backup may pre-date encryption, but still contain the conditions that allowed the attack to succeed.
Boards are often reassured that the organisation has immutable backups, protected snapshots and isolated recovery copies. Those capabilities are essential, but they do not by themselves answer the most important recovery question:
Can we restore from this backup and have confidence that we are not restoring the attacker, the vulnerability, the misconfiguration, the compromised identity path or the original failure condition back into production?
That is why backup remediation assurance is no longer a technical detail, it is a board-level resilience issue.
There is also a seductive myth in the market that cyber recovery can be reduced to a big red button: press once, automatically identify the last clean backup, restore the estate and return to normal.
That message is attractive because it makes a deeply complex operational problem sound simple. It is especially persuasive for teams whose primary experience is in backup administration rather than cyber incident response, destructive cyber recovery or understanding nation-state cyber tradecraft. The danger is that it turns a nuanced investigation and risk decision into a product feature, implying that the platform can determine “clean” with a level of certainty that real incidents rarely permit.
Some data management and backup vendors imply that automated detection, anomaly scoring, malware scanning or threat intelligence matching can identify and select a clean backup snapshot. These capabilities are hugely valuable in accelerating investigation, overcoming defence evasion, highlighting suspicious changes, detecting known malware, identifying encryption patterns and supporting recovery point selection, but they do not replace incident response.
They do not prove root cause.
They do not prove the attacker has been evicted.
They do not prove identity can be trusted.
They do not prove vulnerable configurations have been remediated.
They do not prove vulnerable applications and operating systems have been patched.
They do not prove persistence has been removed.
They do not prove that restored systems are safe to reconnect.
The danger is not automation itself, the danger is treating automation as assurance. A tool may help identify a candidate recovery point. It cannot, by itself, declare a recovered business service as trusted.
Why This Matters at Board Level
Boards do not need to understand every forensic and incident response technique used to inspect backup data. They do need to understand the governance risk created by assuming that recoverable data is trustworthy data.
There is a material difference between: “we can restore the system” and “we can restore the system to a state that is sufficiently understood, validated and trusted to resume business operations”.
The first is a recovery mechanics statement, the second is a risk decision.
During a serious destructive cyberattack, management may face intense pressure to restore services quickly. Customers may be unable to access products and services. Operations may be halted. Regulators may be asking questions. Employees may be unable to work. Revenue may be impaired. Public confidence may be declining. In that environment, the organisation may be tempted to treat the existence of a backup as sufficient for recovery.
That is where the illusion begins: a backup is a copy of a previous state. It is not a certificate of trust.
The board-level risk is that the organisation restores systems that appear operational, but remain unsafe, compromised, vulnerable or incapable of withstanding reattack.
In practical terms, that can mean:
Restoring compromised accounts
Restoring vulnerable software or configurations
Restoring attacker-created persistence
Restoring malware staging locations
Restoring disabled security controls
Restoring unpatched systems
Restoring corrupted or manipulated data
Restoring systems into an environment where identity is still compromised
Restoring applications before the root cause has been understood
Resuming business operations before the risk has been consciously accepted
The organisation may believe it has recovered because systems are back online. In reality, it may have rebuilt the same battlefield and invited the attacker back in.
The False Comfort of "Pre-Encryption" Backups
A common recovery question during ransomware incidents is: “Can we identify the backup snapshot from before encryption?”. That is a necessary question, but it is not sufficient for trusted recovery.
Encryption is often the final visible stage of an intrusion, not the beginning of it. By the time ransomware detonates, the attacker may already have completed reconnaissance, privilege escalation, persistence, lateral movement, defence evasion, data staging and backup targeting.
In nation-state wiper incidents, this can be even more pronounced. The destructive payload may be delivered only after extended reconnaissance, access preparation, credential compromise, operational staging and careful selection of targets. The visible destruction may be the final act of a campaign that may have taken several months to prepare.
A backup taken before encryption may therefore still contain:
The vulnerable internet-facing system initially exploited
The compromised service account used for lateral movement
The misconfigured administrative group that enabled privilege escalation
The attacker's tools staged on a file share
A scheduled task, registry key, web shell or remote access mechanism
Logs showing early compromise, but not yet reviewed
Security tools that had already been disabled or weakened
Backup credentials that had already been exposed
Group Policy changes that reduced security controls
Application or database changes made by the attacker
The backup may be technically restorable, but operationally unsafe. This is why cyber recovery cannot be treated as a simple rollback exercise.
Restoring to a point before encryption may remove the encrypted files, but it may not remove the reason the organisation was encrypted in the first place.
Different Data, Different Recovery Points
There is also a more subtle recovery problem: not all data has the same recovery point objective in a cyberattack.
In conventional disaster recovery, the Recovery Point Objective is often discussed as a single measure: how much data loss the business can tolerate. For cyber recovery, that view is too simplistic.
Encryption of business data is the last stage of a ransomware attack. By that point, the adversary may have already spent days, weeks or even months inside the environment, particularly in more strategic nation-state wiper scenarios. That means there may be two very different recovery timelines:
| Recovery Object | Typical Cyber Recovery Question | Recovery Point Consideration |
|---|---|---|
| Documents, files, records and database tables | When was this data last known to be usable and not encrypted, corrupted or manipulated? | The safest usable point may be close to the encryption or destruction event |
| Applications, libraries, binaries, drivers, configurations and identities | When was this component last known not to contain attacker access, persistence, vulnerable configuration or malicious modification? | The safest trusted point may be much earlier, potentially before initial compromise. Rebuilding from trusted install images and configurations may be faster./td> |
A document repository encrypted at 02:00 may be recoverable from 01:30, but an application server restored from 01:30 may still contain the vulnerable library, malicious driver, modified configuration, compromised service account, attacker-created scheduled task or altered identity permission that enabled the incident.
The same is true for Active Directory, Entra ID, privileged access systems, backup administration roles, endpoint management platforms, scripts, deployment tools, infrastructure-as-code repositories and administrative workstations.
The data may need one recovery point; the control plane may need another and the application stack may need another again.
This is why ”find me the clean backup” is the wrong framing. In a destructive cyberattack, there may not be a single clean backup. There may be multiple candidate recovery points for different components, each requiring different levels of investigation, validation and risk acceptance.
In cyber recovery, RPO is not only about data loss: it is also about trust loss.
Backup Integrity vs Backup Trustworthiness
Boards should distinguish between backup integrity, immutability, recoverability, cleanliness and trustworthiness. They are related, but not the same.
| Concept | What It Means | Why It Matters |
|---|---|---|
| Backup integrity | The backup is complete and has not been corrupted or unexpectedly altered | Confirms that the recovery data is structurally usable |
| Backup immutability | The backup cannot easily be changed or deleted within the protected retention periodReduces the likelihood that the attacker can destroy recovery options | Reduces the likelihood that the attacker can destroy recovery options |
| Backup recoverability | The backup can be successfully restored into a target environment | Confirms that restoration is technically possible. In many organisations, this is all that is tested | Backup cleanliness | No known malicious artefacts or suspicious indicators have been found within the scope of inspection | Provides useful but bounded assurance |
| Backup trustworthiness | The recovery point has been assessed in context of compromise timeline, root cause, identity, persistence, configuration, vulnerabilities and business risk | Supports safe and defensible business resumption |
This distinction is important because a backup can be intact, immutable and recoverable while still being unsafe to use without further validation.
An immutable backup can still contain malware.
An isolated backup can still contain compromised accounts.
A technically successful restore can still reintroduce a vulnerable configuration.
A historical copy can still reflect an already-compromised state.
A malware scan can return no findings and still miss novel tooling, credential abuse, living-off-the-land activity or a vulnerable driver that enables the next compromise.
A vendor dashboard can label a snapshot as clean while the real root cause remains unresolved.
The question is not only whether the backup can be restored. The question is whether the organisation understands what it is restoring and if risks are being reintroduced with it.
The Folly of the Big Red Button
Boards should be cautious of any vendor’s recovery narrative that makes cyber recovery sound like pressing a big red button. The promise usually sounds something like this: “Our platform detects ransomware detonation, automatically identifies the last clean snapshot and restores it automatically allowing business to resume.”
That may work well in a controlled demonstration, but it does not reflect the operational reality of a destructive cyberattack. Nor does it align with recognised cyber response and recovery practice from organisations such as NIST, International Standards Organisation, SANS Institute, MITRE, Forum of Incident Response and Security Teams or the UK National Cyber Security Centre.
In a real incident, recovery is not just a storage decision, it is a risk decision. Before restoring at scale, an organisation must understand what happened, how the attacker gained access, whether identity and administrative control can be trusted, whether persistence remains, whether backups contain compromised systems or vulnerable configurations and which services should be recovered first.
A destructive cyberattack is not just a data corruption event: it is an adversary-led crisis involving uncertainty, intent, privilege, persistence, evasion and changing evidence.
The attacker is not a power outage. The attacker has made choices. They may have prepared the environment before detonating the payload. They may have weakened controls, manipulated identity, tampered with logs, disabled agents, altered configurations, hidden persistence mechanisms and targeted recovery systems.
Automation can help:
It can reduce the search space.
It can detect encryption patterns.
It can identify unusual change rates.
It can find known malware.
It can compare snapshots.
It can flag suspicious files.
It can support triage.
But it cannot answer the full set of trusted recovery questions:
How did the attacker get in?
When did compromise begin?
Which identities were compromised?
Which systems were used for lateral movement?
Which configurations were changed?
Which controls were disabled?
Which persistence mechanisms were created?
Which vulnerabilities remain exploitable?
Which recovery points are suitable for which workloads?
What compensating controls are required before reconnection?
Who accepts the residual risk of resuming operations?
Automated detection and recovery tooling can be valuable, but it should support human-led incident response and recovery governance, not replace it. The board should be wary of any proposition that implies cyber recovery can be fully automated while the organisation is still uncertain about root cause, blast radius, identity compromise and recovery sequencing.
A last clean backup button may identify a point before encryption. It may even identify a point before known indicators appeared. But that is not the same as identifying a point before compromise, before persistence, before vulnerable configuration drift, or before identity abuse.
The board should not ask whether the organisation has an automated clean-backup button. Iit should ask whether the IT and Security teams are collaborating on an evidence-led process for selecting, validating and approving recovery points under uncertainty.
The Limitations of Threat Intelligence
Threat intelligence is valuable in cyber recovery. Indicators of Compromise, malware signatures, YARA rules, known filenames, command-and-control domains in logfiles, hashes and adversary tradecraft reporting can all help identify suspicious artefacts in backup data and historical snapshots. However, boards should understand one critical limitation: no threat intelligence feed is exhaustive.
Threat intelligence always lags reality to some degree.
Attackers change infrastructure.
Tooling evolves.
Malware is recompiled.
Scripts are renamed.
Living-off-the-land techniques avoid obvious signatures.
Credentials are abused without malware.
Commercial remote monitoring tools are repurposed.
Novel tradecraft may not yet be documented.
Private tooling may never appear in a public feed, especially important for Critical National Infrastructure that may be facing nation-state actors.
That means the absence of known indicators is not proof of cleanliness. It only means that no known indicators were found using the available detection logic at that point in time. That is a very different assurance statement.
This is also where threat intelligence and backup data become powerful together. As new indicators, behaviours, malware families, vulnerabilities and adversary techniques are identified during an investigation or added to a threat intelligence feed, the organisation can use the backup platform to look back across the incident timeline.
That historical view is materially different from relying only on endpoint detection and response telemetry. EDR is vital, but it tends to focus on what is happening now or what was recently observed on live endpoints. In destructive cyberattacks, EDR agents may be disabled, tampered with, bypassed, or destroyed before the final impact. A data management platform, by contrast, can retain historical copies of systems, files, logs, configurations and application data across the full dwell-time of the incident without being susceptible to endpoint-level evasion techniques.
Threat intelligence helps narrow the search. It can point investigators towards suspicious hosts, accounts, files, behaviours or timeframes. It can identify known tooling and known infrastructure. It can accelerate triage. But it is important to understand that threat intelligence cannot replace investigation.
Understanding Indicators of Compromise
Finding an Indicator of Compromise is not the end of an investigation; it is the point at which the real investigation begins. The clue is in the name: it is an indicator, not an explanation. It tells you that something happened, but not how it happened, when it happened, what enabled it, what the adversary did next, or whether they are still present. The most important question is not “What indicator did we find?” but “How did it get there?”
Every indicator is a signpost pointing towards an attack path. A malicious file may reveal the delivery mechanism. A registry change may reveal persistence. A suspicious account may reveal credential theft. A command execution artefact may reveal lateral movement. Until you understand the sequence of events that led to the indicator appearing, you do not understand the compromise.
Organisations that stop at identifying indicators often end up treating symptoms rather than causes. Organisations that follow the trail behind the indicator are far more likely to uncover the root cause, identify additional compromised assets, understand the adversary’s objectives, and remove persistence mechanisms before recovery begins.
An Indicator of Compromise is the broken window discovered after a burglary. Reverting to a snapshot without investigating the IoC is like replacing the window and tidying the room while the burglar is still inside the building.
Why "No Indicators Found" Is Not the Same as Clean
One of the most common misunderstandings in recovery assurance is the interpretation of negative findings.
A scan may report no known malware. A threat hunt may find no listed indicators. A YARA rule may not match. A hash search may return no results. A sandbox detonation may not show malicious behaviour. A vulnerability scan may not identify the exploited weakness.
These are useful data points, but they are not absolute proof. They are bounded by:
The quality and coverage of the detection logic
The freshness of the threat intelligence
The visibility available in the backup data
The completeness of the logs
The age and scope of the snapshot
The attacker's use of legitimate tools
The ability to inspect encrypted, compressed or proprietary data
The skill and hypothesis set of the investigation team
The time available before recovery decisions must be made
The right conclusion is: “we have not identified evidence of compromise in the areas inspected”, not “the backup is clean”. That wording may sound cautious, but it matters: in a board setting, precision is not pedantry, it is governance. This is also why automated clean backup detection must be treated carefully.
A platform may be able to say:
No known malware was detected.
No encryption pattern was observed at this point.
No listed indicators of compromise were found.
This snapshot predates the observed ransomware activity.
Those are useful statements, but they are not the same as saying: “this recovery point is absolutely safe to restore into production.”
That final judgement requires context: compromise timeline, root cause analysis, identity assurance, vulnerability exposure, persistence review, application validation, control-plane trust and business risk acceptance.
In board terms, the difference is simple: a platform can provide evidence, management must make the risk decision.
Where Organisations Commonly Fail
1. Treating the Backup Date as the Trust Boundary
Organisations often choose a recovery point based primarily on when encryption began. If the attacker entered the environment three weeks earlier, a backup from two days before encryption may still contain attacker changes, compromised credentials or the vulnerable condition that enabled the incident.
The critical question is not only: When did encryption occur? It is also: When did compromise begin, what changed after that point, and what evidence do we have?
This is often difficult to answer quickly, which is why recovery decisions must combine forensic investigation, business impact and risk acceptance.
2. Restoring Before Root Cause Is Understood
There are situations where organisations must restore before the full root cause is known. Business survival may demand it. However, that should be a conscious risk decision, not an accidental assumption.
If the organisation restores before understanding root cause, it should know what compensating controls are required. These may include network isolation, enhanced monitoring, credential resets, privileged access restrictions, vulnerability remediation, endpoint inspection, staged reconnection and heightened detection.
The risk is not restoring early. Sometimes that is necessary, the risk is restoring early while pretending the organisation has achieved trusted recovery.
Where recovery time objectives are particularly aggressive, organisations can often achieve both greater confidence and faster recovery by maintaining vaulted repositories of trusted installation media, golden images, application packages, configurations and validation artefacts. Rebuilding from known-good components provides a far more deterministic path to trust than simply restoring entire volumes from historical backups, particularly when the timing and scope of attacker activity remain uncertain.
The objective should not be to choose between speed and trust, the objective should be to engineer recovery processes that deliver both.
3. Over-Reliance on Known Indicators
Known indicators are helpful, but attackers are not static. An organisation may search for published ransomware hashes, known filenames or command-and-control domains and find nothing. That does not mean the backup is clean. It may mean the attacker used different tooling, changed filenames, used legitimate administrative utilities, deployed payloads only in memory, or operated before those indicators were known.
Threat intelligence should inform recovery assurance, but it should not define its outer boundary.
4. Ignoring Identity and Control Plane Compromise
Many recovery efforts focus heavily on data and workloads, but insufficiently on identity.
If Active Directory, Entra ID, privileged access pathways, backup administration accounts or management tooling have been compromised, then restoring application data may not solve the underlying problem.
A clean-looking application restored into an untrusted identity environment can quickly become compromised again.
Trusted recovery requires confidence not only in the recovered workload, but in the control planes used to administer, authenticate, monitor and protect it.
5. Restoring Applications That Should Be Rebuilt
In some cases, the safest recovery path is not to restore an application server at all. It may be safer to rebuild it from trusted source, redeploy the application, replace vulnerable libraries, rotate secrets, reissue certificates, remove risky drivers, validate configurations and then restore only the business data required.
This is particularly important where the application stack itself may contain the attack surface or persistence mechanism.
The recovery decision is therefore not simply: Which backup do we restore? It may be: Which components should be restored, which should be rebuilt, and which should be replaced?
6. Failing to Preserve Evidence During Recovery
In the urgency to restore, organisations may overwrite, delete or fail to preserve evidence needed to understand the incident.
That evidence may be needed to answer:
What was the initial access vector?
Which systems were compromised?
Which accounts were used?
What data was accessed or exfiltrated?
Which recovery points are safest?
What must be remediated before reconnection?
What must be reported to regulators, insurers or customers?
Recovery and investigation need to be coordinated. The organisation should not have to choose blindly between restoring the business and understanding the attack. It needs an operating model that allows both to proceed in a controlled way.
What Good Looks Like
A mature organisation does not claim that backups are clean by default. It builds an assurance process around recovery data.
1. Evidence-Led Recovery Point Selection
Recovery points should be selected based on more than age. They should be assessed using available evidence, including:
Timeline of attacker activity
Encryption or destruction timing
Known compromised accounts
Indicators of compromise
System and application logs
Endpoint telemetry
Backup snapshot analysis
File system changes
Configuration changes
Vulnerability exposure
Business impact tolerances
The goal is not perfect certainty. Perfect certainty is rarely available during a live incident.
The goal is informed confidence.
2. Historical Snapshot Analysis
Backups can support far more than restoration. Used properly, they provide historical visibility into how an environment changed before, during and after compromise. Unfortunately, some data management vendors find it easier to sell the fiction of “automagical” recovery than to focus on the genuinely game-changing value backup platforms can provide to security operations teams.
The real power is not just in putting data back, it is in using historical recovery points as evidence.
Comparing snapshots over time can help identify:
When suspicious files first appeared
When binaries, scripts or libraries changed
When registry keys or scheduled tasks were modified
When privileged groups changed
When large-scale file changes began
When unusual administrative tools were introduced
When logs or security tooling were altered
When system configurations drifted from baseline
This can help investigators move from visible impact to probable compromise timeline.
The value is not only recovering data, it is using historical data to understand the attack.
3. Layered Inspection and Validation
No single test proves that a backup is clean. A stronger approach combines multiple forms of validation, such as:
Malware scanning
YARA and custom rule hunting
Hash searches
Threat intelligence matching
Mounting snapshots for vulnerability scanning
Configuration review
Identity and privilege review
File system change analysis
Log review, including cold logs in backup snapshots that never made it to the SIEM, having been deleted or rotated
Behavioural analysis
Sandbox detonation of suspicious artefacts
Manual investigation of anomalies
Each technique has limitations, and many can be accelerated or empowered by information held in backup snapshots. Together, they each improve confidence.
This is similar to aviation safety. A pilot does not rely on one instrument to decide whether the aircraft is safe to fly. They cross-check altitude, speed, heading, engine performance, weather, fuel and control response.
Recovery assurance should work the same way.
4. Clean Room Recovery
Where possible, critical systems should be restored into an isolated response and recovery environment before being reconnected to production.
A clean room allows teams to:
Restore systems away from compromised infrastructure
Inspect workloads before reconnection
Scan for malware and suspicious artefacts
Validate configuration and patch levels
Confirm identity and access controls
Test application behaviour
Apply compensating controls
Stage recovery in a controlled sequence
A clean room gives the organisation a safer place to inspect, validate and prepare recovery before reintroducing services into the business environment.
5. Different Recovery Points for Different Recovery Objects
A mature cyber recovery process does not assume there is one universal recovery point for the whole organisation.
It recognises that different types of assets may require different recovery strategies.
Business data, such as documents, file shares, records and transactional tables, may need to be recovered to the latest point before encryption, destruction or unauthorised manipulation.
Application components, libraries, scripts, drivers, configurations, identity objects and administrative control planes may require a much earlier recovery point, or may need to be rebuilt from trusted source rather than restored at all.
For example:
A database table may be restored from minutes before encryption
A file share may be restored from the last known unencrypted version
An application server may need to be rebuilt from a known-good image
A vulnerable library may need to be replaced rather than restored
A malicious or vulnerable driver may need to be removed before recovery
Active Directory objects may need to be reviewed across a much longer compromise window
Privileged accounts may need to be reset, disabled or reconstructed rather than restored
Group Policy changes may need to be compared against a known-good baseline
Infrastructure-as-code repositories may need to be reviewed for malicious or risky modifications
This creates a more nuanced recovery model.
The objective is not to roll everything back to the same point in time. The objective is to restore each component to the safest usable state based on its role, risk and evidence.
6. Clear Risk Acceptance
At some point, recovery decisions become business decisions.
The organisation may not have complete forensic certainty, but it may still need to resume operations. That is acceptable if the decision is explicit, evidenced and governed.
The board should expect management to be able to say:
What evidence was reviewed
What was inspected
What was not inspected
What assumptions were made
What residual risks remain
What compensating controls are in place
Who approved restoration
How the environment will be monitored after recovery
This is how cyber recovery becomes defensible.
Not risk-free, defensible.
The Board's Role
Boards should not ask management to guarantee that backups are clean. A better question is: ”How do we establish sufficient confidence that a recovery point is safe to use, and who decides when that confidence is enough?”
That shifts the discussion from false certainty to governed assurance.
What the Board Should Challenge
Boards should challenge any statement that sounds absolute without evidence.
For example:
The backups are clean.
We restored from before the attack.
No indicators were found, so we are safe.
The immutable copies are fine.
The malware scan passed.
The platform identified the last clean backup.
We can just roll back.
Each of these may be directionally reassuring, but incomplete. The board should ask for the evidence behind the conclusion and the limits of that evidence.
What the Board Should Expect
The board should expect a recovery assurance process that includes:
Defined criteria for selecting recovery points
Ability to inspect historical backups and snapshots
Integration between incident response and recovery teams
Threat intelligence enrichment, with recognition of its limits
Malware and suspicious artefact analysis
Vulnerability and configuration assessment
Identity and privileged access validation
Clean room or isolated restoration capability for critical services
Different recovery strategies for data, applications, configurations, identities and control planes
Documented residual risk and approval thresholds
Post-recovery monitoring and heightened detection
The key issue is not whether the organisation can prove perfection, it is whether the organisation can make recovery decisions based on disciplined evidence rather than hope.
Key Takeaways for the Board
A historical backup is not automatically a clean backup.
A backup taken before encryption may still contain compromise, persistence, vulnerable configurations or attacker-created access paths.
Encryption is often the last visible stage of an attack, while the adversary may have dwelled for days, weeks or months before detonation.
Immutability protects the availability of recovery data; it does not prove the data is safe to restore.
Automated clean backup detection can support recovery triage, but it cannot replace root cause analysis, identity validation or governed risk acceptance.
No threat intelligence feed is exhaustive, and all intelligence lags changes in adversary tooling and tradecraft.
Finding an indicator of compromise is a starting point for investigation, not a complete root cause analysis.
No indicators found does not mean clean; it means no known indicators were found within the scope and limits of the inspection.
Trusted recovery requires layered validation across data, systems, identity, configurations, vulnerabilities and control planes.
Different recovery objects may require different recovery points. Documents and tables may be recoverable from near the encryption event, while applications, libraries, drivers, configurations and identities may require earlier recovery points or complete rebuild.
Boards should focus on evidence, residual risk and decision rights rather than binary assurances.
The right recovery question is not only Can we restore? but Can we explain why this recovery point is sufficiently trusted to resume operations?
What to Ask Your Executive Team
How do we determine whether a backup is safe to restore after a destructive cyberattack?
Do we distinguish between backup integrity, immutability, recoverability, cleanliness and trustworthiness?
Do any of our vendors or internal teams describe recovery in terms of automatically identifying a clean backup, and what evidence supports that claim?
Do we understand the difference between a backup that predates encryption and a backup that predates compromise?
Can we inspect historical snapshots to identify when suspicious changes first appeared?
How do we identify a recovery point that predates compromise, not just encryption?
Do we define different recovery point objectives for encrypted business data versus applications, libraries, drivers, configurations, identities and control planes?
Which components should be restored, and which should be rebuilt from trusted source?
How do we prevent a restored workload from reintroducing the vulnerable condition, persistence mechanism or compromised identity path that enabled the original attack?
What role do threat intelligence feeds, YARA rules, malware scanning and hash searches play in backup validation?
How do we account for the fact that threat intelligence is incomplete and may lag adversary tradecraft?
What do we do when no indicators are found, but root cause remains unknown?
Can we restore critical systems into an isolated clean room before reconnecting them to production?
How do we validate identity, privileged access and control planes before resuming operations?
Can our recovery tooling identify suspicious change, or does it also support investigation into how and why that change occurred?
Who is accountable for deciding that a vendor-identified clean recovery point is sufficiently trusted for business restoration?
Who has authority to accept residual risk if recovery is required before full forensic certainty is available?
What evidence would we provide to regulators, insurers, customers or internal stakeholders to justify our recovery decision?
How do we monitor restored services for signs of reinfection, persistence or renewed attacker activity?
A Practical Analogy
A backup is like a photograph of a room taken yesterday.
It can show you what the room looked like at that moment, but it does not prove the room was safe. The faulty wiring may already have been behind the wall. The gas leak may already have started. The spare key may already have been stolen. The intruder may already have hidden something in the ceiling.
Restoring the room to yesterday's photograph may remove today's visible damage, but it does not automatically remove yesterday's hidden danger.
That is why trusted recovery requires inspection, investigation and judgement.
Historical data helps you go back in time. It does not, by itself, tell you which point in time was safe.
Closing Thought
Backups are essential to cyber resilience, but they are not magic, and they are not a big red button.
They preserve options. They provide evidence. They enable restoration. They can support investigation. They can help reconstruct the timeline of an attack.
But they do not automatically prove that an environment is clean, safe or trusted.
The organisations that recover well from destructive cyberattacks are those that treat backups not as a simple rollback mechanism, but as part of an evidence-led recovery process. They understand that encryption is often the last visible stage of an attack, not the beginning. They recognise that documents and tables may have one recovery point, while applications, libraries, drivers, configurations, identities and control planes may require a very different recovery point or a complete rebuild from trusted source.
They also understand the limits of automation.
A platform may highlight the last point before encryption. It may detect known malware. It may identify suspicious change. It may enrich findings with threat intelligence. Those are valuable capabilities. But no vendor, no feed and no scan can remove the need to investigate root cause, understand persistence, validate identity and make a governed decision about residual risk.
The board does not need to ask whether every byte in every backup has been proven safe.
It does need to ask whether management has a defensible way to decide which recovery points are trustworthy enough to use, which components should not be restored at all, and who accepts the risk of resuming operations.
Because in a destructive cyberattack, the wrong recovery point can bring the business back online while quietly bringing the attacker, the vulnerable condition or the persistence mechanism back with it.
That is not trusted recovery, it’s restoration with a false sense of safety.
Next Briefing
Minimum Viable Company: Why Recovery Priorities Must Be Decided Before the Crisis.
