Spokesperson: Dan Box, Chief Technology Officer for UK&I, NetApp
In financial services, disruption is no longer a remote possibility. It is an operational certainty. The question is not whether systems will fail, but how quickly they can be restored when they do.
That distinction is becoming critical. Customers expect uninterrupted access to accounts and payments. Markets operate continuously across time zones. Regulators increasingly assess firms not only on their ability to prevent incidents, but on whether they can sustain important business services through them. In this environment, recovery, not prevention, has become the defining measure of resilience.
Yet much of the industry is still operating with recovery models designed for a different era.
Why the traditional backup is no longer fit for purpose
Conventional backup architectures were built around predictable failure scenarios and slower-moving systems. Data was copied at intervals, stored separately, and restored when required, while recovery time objectives were measured in hours. Recovery point objectives assumed some degree of acceptable data loss. However, today those assumptions no longer hold.
This is because modern banking runs on real-time processes. Consumers expect instant payments, always-on digital channels, while institutions require trading environments where latency is measured in milliseconds. In this context, a recovery window of even a few minutes is a business failure, not an inconvenience. A delay in restoring services can interrupt settlement flows, disrupt liquidity management, or in more real terms can result in employers unable to pay their employees or suppliers, or critical mortgage payments to fail.
At the same time, the threat landscape has shifted. Ransomware attacks are no longer confined to encrypting primary systems. More importantly, they also look to actively compromise backup environments, corrupt recovery points, and remove the option of clean restoration altogether. The objective is simple: make recovery uncertain, slow, and operationally risky.
This exposes a fundamental weakness in periodic backup models. Gaps between snapshots leave recent data vulnerable. Recovery processes often require manual validation of data integrity at precisely the moment speed matters most. And in complex, distributed environments, restoring systems is rarely a single action. Usually, it’s a coordinated sequence that is difficult to execute under pressure. The result is a growing disconnect between having backups and being able to recover.
Designing recovery-first infrastructure
Closing this gap requires a shift in architecture, not just process. Recovery cannot remain a secondary workflow triggered after an incident. It must be embedded within the core data layer that supports daily operations.
That starts with how data is captured and protected. Continuous data protection, meaning that changes are captured in real time instead of at fixed intervals, reduces recovery point objectives to near zero. Instead of reverting to the last available snapshot, institutions can restore systems to a precise moment before disruption occurred. This materially changes the trade-off between speed and data integrity.
To facilitate this, attack detection must also move closer to the data itself. Integrated monitoring that identifies anomalous behaviour within primary data environments can shorten the time between compromise and response. In ransomware scenarios, this can mean the difference between isolating an incident early and facing widespread corruption across systems.
Equally important is execution. Recovery processes that depend on manual intervention do not scale in modern banking environments. Automation and orchestration are essential, especially across hybrid and multi-cloud infrastructures where services, data, and dependencies are distributed. The ability to fail over cleanly between environments, with consistent data states, is rapidly becoming a must-have, rather than an added extra.
Increasingly across the UK and Europe, this goes beyond operational strategy. Regulations like DORA make it a non-negotiable requirement. Firms must be able to define important business services, set impact tolerances, and demonstrate that they can remain within those tolerances during disruption.
This raises the bar for recovery. Recovery capabilities are often fragmented across legacy systems, bolt-on solutions, and disparate cloud environments. Bringing them together into a coherent, testable, and reliable framework is now a strategic priority.
From backup to resilience
Resilience is now determined by what happens after controls fail. That shifts the focus from infrastructure to data: its integrity, its availability, and the speed with which it can be trusted again. Backups, in isolation, do not solve this problem. In some cases, they exacerbate it by creating a false sense of security while masking the complexity of recovery under real-world conditions.
The institutions that will lead in this environment are those that treat recovery as a primary capability. They design systems that assume disruption, minimise data loss, and enable rapid, automated restoration of critical services.
