Continual Data Protection Isn’t a Panacea for Cyber Resilience
Continual Data Protection (CDP) sounds seductive in the aftermath of a ransomware attack. The promise is simple: lose almost no data. In a world where boards, regulators and operational leaders are increasingly focused on minimising disruption, that sounds like exactly the answer organisations have been looking for, but it isn’t.
CDP can improve your Recovery Point Objective: the amount of data you lose between the last good state and the moment of impact. That matters. For some workloads it matters a great deal. What it does not do is magically deliver cyber resilience.
That is because cyber resilience is not about how little data you lose, it is about how quickly and safely you can restore the organisation to a trusted operating state. Those are very different things, and confusing them is where a lot of organisations get themselves into trouble.
Low data loss is not the same as trusted recovery
If you recover from a point that sits only moments before detonation, there is a good chance you are also recovering the very conditions that allowed the attack to succeed in the first place. That recovery point may contain vulnerable configurations and applications, excessive privileges, evaded and missing controls, adversary persistence mechnisms, poisoned identity infrastructure, unauthorised scheduled tasks, tampered scripts, backdoored golden images or adversary manipulation of management tooling. In the case of Living-off-the-Land attacks, it may not even contain anything that looks obviously malicious at first glance. So yes, CDP may mean you lose no data, but it may also mean you restore the attacker’s foothold or vulnerable state that allowed the attack in the first place.
That is the problem. CDP is often discussed as though it solves cyber recovery. In reality, it solves only one narrow part of the problem: data currency. It says little about whether the recovered environment is trustworthy, defensible or safe to reconnect to production. Recovering compromised infrastructure quickly is a bit like rushing to move back into a house while the fire is still burning in the walls. From the street it may look intact, but that does not mean it is safe to live in.
CDP does nothing to reduce the response work
One of the most dangerous misunderstandings in cyber recovery is the belief that a lower RPO automatically drives a lower RTO, it doesn’t.
The time to recovery to a safe state in a destructive cyberattack is rarely consumed by moving data. It is consumed by everything that has to happen before you can trust that data and the surrounding infrastructure again.
You still need to investigate root cause.
You still need to understand how the adversary got in, what they touched, what they changed and whether they still have a route back in.
You still need to identify persistence mechanisms.
You still need to remediate the vulnerabilities, gaps in controls and architectural weaknesses that enabled the compromise.
You still need to establish whether identity systems can be trusted, whether the network control plane can be trusted, whether hypervisors can be trusted, whether endpoint tooling can be trusted and whether the security tools you intend to rely on for investigation have themselves been tampered with.
None of that is accelerated simply because your data copy is more recent.
CDP can shrink the amount of business data you lose. It does very little by itself to shrink the time required to restore trust and in real incidents, restoring trust is the slow part.
You still need backups and immutable baselines
There is another uncomfortable truth here: to understand a malicious change, you need comparison points. You need known-good baselines. You need historical restore points. You need the ability to compare current state against earlier states to determine what changed, when it changed and whether those changes were authorised, benign or malicious Without these comparison points, investigation becomes guesswork.
Backups are not just there to restore data, in a mature cyber resilience capability, they are a forensic and analytical advantage. They let responders compare states across time, identify drift, trace the spread of compromise and understand whether the attacker manipulated data, tampered with configuration or staged persistence long before the final impact. They can reveal endpoint logs that never made it into the SIEM, show the precise attack surface on patient zero at the moment of compromise, and expose artefacts the adversary thought they had already cleaned up. They are also not susceptible to many of the evasion techniques routinely used to blind EDR, and they often provide a far deeper historical view than most EDR or XDR platforms retain. Just as importantly, they allow passive threat hunting without tipping off the attacker. These are the superpowers modern data management platforms can offer. Unfortunately, many Security Operations teams still fail to exploit them, largely because backup is still dismissed as unglamorous compared with the shinier parts of the security stack.
That matters enormously in modern attacks, particularly where the adversary has moved quietly, used valid credentials, abused administrative tooling or blended into normal operations. If all you have is a very recent recovery point, you may have a perfect copy of a compromised estate and very little context for understanding how compromised it is.
A trusted recovery needs an environment to rebuild trust
A secure recovery is not just a Restore operation as in a traditional business continuity and disaster recovery incident, it is an exercise in re-establishing confidence across the core layers of the technology stack. That means having the ability to restore trust in:
Networks and segmentation controls
Identity and authentication services
Hypervisors and virtualisation layers
Endpoint and server build standards
Logging, monitoring and detection tooling
Configuration management and orchestration systems
Administrative jump points and remote access paths
The evidence stores and collaboration tooling used by responders
This is where so many conversations around CDP become too narrow. They focus on the application data and ignore the supporting infrastructure that determines whether recovered services can remain online without immediate reinfection.
If Active Directory is compromised, a low-loss restore of application data does not solve your problem. If your hypervisor management plane is untrusted, a low-loss restore does not solve your problem. If the EDR console is blind, the SIEM is incomplete, and your incident response tooling was sitting in the blast radius, a low-loss restore does not solve your problem.
You need somewhere safe to investigate, validate, rebuild and test before reconnecting to production. You need clean operational footing, not just recent data.
Threat hunting still matters, especially in quieter intrusions
Not every destructive attack leaves an obvious trail of malware binaries and ransom notes from the outset. Many of the most capable adversaries live off the land. They use native tooling, legitimate credentials, approved remote management utilities and normal administration pathways. Their actions may look like routine operations until viewed in sequence and in context. That means recovery cannot just be about bringing systems back.
It has to include the ability to threat hunt, to search for indicators of compromise, to review identity abuse, to trace lateral movement, to inspect privilege escalation, to validate whether recovered systems contain evidence of dormant or re-establishable access. This is another area where CDP adds little by itself. A more recent copy of data is not a substitute for investigative capability.
You still need A CLEAN ROOM and controlled validation
Before recovered systems, scripts, binaries or datasets are trusted, they often need controlled inspection. You need the ability to detonate suspicious artefacts, test behaviours in isolation, validate system states and understand whether a recovered workload is actually safe to return to service. That means having a clean room, isolated testing and controlled promotion back into production only after sufficient confidence has been established. Again, CDP does not provide this. It gives you a point from which to recover. It does not give you the operational machinery needed to validate what you are recovering.
The blast radius includes more than production data
Another common mistake is assuming the recovery challenge begins and ends with business systems. In serious attacks, the adversary may have targeted the very infrastructure you rely on to respond:
Privileged access tooling
Remote administration platforms
Monitoring stacks
Ticketing and collaboration tools
Documentation repositories
Automation scripts
Software repositories
Certificate services
DNS, DHCP and core network services
If those capabilities are untrusted, even a perfect CDP stream on application workloads will not help you recover quickly. In fact, it can create false confidence, because the data may be present while the operational capability needed to recover safely is absent. This is why cyber resilience has to be designed as an end-to-end operating model, not a storage feature. At Cohesity I was one of the co-creators of the concept of the Digital Jump Bag™ to reestablish the trust in these components.
CDP can even increase risk when used lazily
Used carelessly, CDP reinforces bad habits. It can encourage the belief that because you can roll back close to the moment of impact, you do not need disciplined backup strategy, immutable recovery points, clean room capability, hardened administration paths or a well-rehearsed shared responsibility model between security and IT operations. That is a dangerous mindset.
The more recent the recovery point, the more likely it is to include the debris of the attack. Without the ability to assess and remediate that debris, CDP risks becoming a very efficient way of restoring compromise. A faster conveyor belt does not help if it is carrying contaminated goods.
Where CDP does have value
None of this is to say CDP is useless, it has real value. For the right workloads, it can materially reduce data loss. It can improve business outcomes where the integrity of the surrounding environment is already understood. It can be a useful component in a broader resilience architecture, but component is the key word. It is one element in the chain, not the chain itself.
If organisations want genuine cyber resilience, CDP needs to sit alongside immutable backups, historical baselines, investigative tooling, threat hunting capability, isolated recovery environments, trusted rebuild assets, strong identity recovery planning, sandboxing capability and regular end-to-end exercising. Otherwise it is just a more precise way of recovering uncertainty.
Cyber resilience is about trusted state, not just recent state
The real objective in cyber recovery is not to get back to the latest possible copy of data, it is to get back to a state the organisation can trust. That means a state where root cause has been understood sufficiently, vulnerabilities have been addressed, persistence has been removed, critical control layers have been validated and the organisation can resume operations without immediately handing the attacker a second victory.
CDP can help with the recency of recovery, but it does not, by itself, help with the trustworthiness of recovery. If your organisation’s recovery strategy optimises for recency while neglecting trust, you have not built cyber resilience you’ve just built a faster route back to compromise.
