An article by Uwe Graf, Head of Consulting at EasiRun.
When cybersecurity is discussed today, the focus is often on prevention and detection. Access is controlled, data is encrypted, networks are segmented, and suspicious activity is identified as early as possible. All of these measures are essential, but they do not answer the question that becomes critical after a successful attack: How can an organization restore its business-critical systems to a state it can genuinely trust?
This is where the distinction between traditional backups and cyber resilience begins.
A backup initially answers one question: Is a copy of the data available? Following a cyber incident, however, that information alone is not enough. Organizations must also determine whether the backed-up data is still clean, when potential manipulation began, and whether the selected recovery point can be used to restore consistent business operations.
This distinction is particularly important for banks, insurance companies, and other organizations running business-critical mainframe applications. In these environments, a business process rarely depends on a single data set. Databases, VSAM files, CICS applications, batch processing, MQ connections, schedulers, and numerous interfaces are closely interconnected. Successfully restoring one component therefore does not necessarily mean that the entire business process will function reliably again.
Cyber Resilience Goes Beyond Data Backup
Traditional backups remain indispensable. They protect against hardware failures, human error, and many other types of disruption. Cyberattacks, however, introduce an additional challenge: The moment an attack is detected is not necessarily the moment the compromise began.
An attacker may have been moving through an environment for days or even weeks before the incident becomes apparent. During that time, data may have been altered or systems compromised without immediately raising suspicion. If backups are created regularly, they may be technically valid while already containing manipulated information.
This changes the fundamental question. It is no longer simply whether a backup exists, but which backup can still be trusted.
Cyber resilience therefore brings together protection, detection, and recovery. Data should be protected through immutable backups wherever possible, unusual changes should be detected early, and organizations need a tested process for returning to a known and verified state when an incident occurs.
NIST also explicitly recognizes recovery as a distinct component of a cybersecurity strategy and recommends regularly planning and testing recovery procedures. Its Guide for Cybersecurity Event Recovery is available at https://www.nist.gov/publications/guide-cybersecurity-event-recovery.
For financial institutions in particular, this approach is also becoming increasingly important from a regulatory perspective. DORA requires documented backup, restoration, and recovery procedures, along with regular testing of these processes. Organizations must also ensure that data integrity is maintained during recovery. The regulation is available at https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=uriserv%3AOJ.L_.2022.333.01.0001.01.ENG.
This makes one thing clear: Cyber resilience is not simply another term for backup. It is about being able to resume business-critical operations after an incident in a controlled, transparent, and verifiable manner.
The Most Difficult Question Is Often: Which Recovery Point Is Still Clean?
Following a conventional technical failure, the appropriate recovery point is often relatively clear. If a component fails at 10:15 a.m., restoring a suitable backup from shortly before that time is usually a logical choice.
A cyberattack can present a very different situation. If suspicious data changes are discovered on Friday, but the original compromise began on Monday, a backup from Thursday may be recent but already compromised.
This is precisely why simply restoring the most recent backup is not enough.
With IBM Z Cyber Vault, IBM takes an approach that more closely integrates immutable backup copies, validation, and recovery. IBM describes Cyber Vault as a framework for business-critical IBM Z environments that combines isolated and immutable copies, automated validation, and a separate environment for analysis and recovery. Further information is available at https://www.ibm.com/de-de/products/z-cyber-vault.
One important technical foundation can be DS8000 Safeguarded Copy. These copies are designed so that they cannot be modified directly by the host system, providing stronger protection against manipulation originating from the production environment. IBM describes this technology at https://www.ibm.com/docs/en/csm/6.3.18?topic=copy-safeguarded-in-ds8000.
The crucial point, however, is that an immutable copy is not automatically a clean copy. If the data had already been manipulated before the copy was created, that manipulation will still be present in the immutable backup. A recovery strategy must therefore include the ability to examine multiple points in time and identify a reliable recovery point.
This distinction between “available” and “trustworthy” is what makes cyber recovery significantly more complex than conventional recovery following a hardware failure.
Detection and Recovery Must Work Together
The earlier a cyber incident is detected, the easier recovery will generally be. If manipulation remains undetected for an extended period, not only does the time window requiring investigation grow, but the number of potentially affected systems, data sets, and dependencies often increases as well.
With IBM zSecure Detection, IBM has introduced a solution designed to detect and investigate unusual activities in z/OS environments more effectively. Examples include suspicious access to data sets, privileged activities, and unusual cryptographic operations. IBM describes this approach at https://www.ibm.com/products/zsecure-detection.
This connection is important for a resilience strategy because detection and recovery should not be treated as separate disciplines. The sooner unusual activity becomes visible, the easier it is to narrow down which data states can still be considered trustworthy.
In hybrid environments, there is another consideration: Attacks do not stop at platform boundaries. A compromised user account or manipulated system can trigger activity across mainframes, distributed systems, and cloud environments. Mainframe events should therefore also be integrated into an overarching security operations model.
The Real Challenge Begins After the Restore
Even when a clean data set has been identified and technically restored, this does not automatically mean that the underlying business process will function correctly again.
Consider a payment processing application. If a database is rolled back to an earlier state, the organization must then determine which payments have already been transmitted to external systems, which transactions can safely be processed again, and whether other participating systems are still consistent with the restored state.
Insurance companies face similar questions involving claims, premium postings, or policy changes. Here, too, a technically successful restore can create business-level problems if dependent systems have already moved to a different state.
Cyber recovery is therefore not just a storage or security issue. It is equally a matter of application understanding, documentation, testing, and operational processes.
Without knowing how applications are connected, which data sets are processed together, and which batch chains or interfaces depend on one another, organizations may be able to restore individual components but struggle to determine whether those components can once again support a consistent business process.
This is precisely where cyber resilience intersects with traditional application modernization. Thorough application analysis does more than support the evolution of existing systems. It also creates the transparency required for a reliable recovery process.
RPO and RTO Are Not Always Enough in a Cyberattack
Traditional recovery strategies are often defined using two metrics: Recovery Point Objective (RPO), which specifies the maximum tolerable amount of data loss, and Recovery Time Objective (RTO), which defines the maximum acceptable recovery time.
Both metrics remain important. In the event of a cyberattack, however, another dimension becomes essential: trust in the restored state.
An RPO of five minutes offers little value if the data has already been manipulated for several days. Likewise, an excellent RTO means little if a system is back online within an hour but no one can reliably determine whether its data is accurate from a business perspective and free from manipulation.
Cyber resilience planning should therefore also address how a trustworthy state can be identified and verified.
DORA addresses this very issue by requiring controls that ensure data integrity during recovery. This reinforces the point that rapid restoration alone is not a sufficient measure of recovery quality.
Recovery Must Be Tested Before It Is Needed
Many organizations know exactly when their last backup was created. A more difficult question is often when they last verified, under realistic conditions, that an entire business process could actually be restored from it.
A technical restore test may demonstrate, for example, that a Db2 data set can be recovered. A robust cyber recovery test, however, should also verify that dependent applications start correctly, interfaces function as expected, batch processing can resume, and business departments can actually work with the restored state.
The more complex the application, the more important a reproducible testing process becomes.
IBM Z Cyber Vault supports the creation of an isolated environment in which recovery and analysis can be performed without affecting production. This is particularly valuable because it allows organizations to test recovery procedures before a real attack occurs.
NIST also explicitly emphasizes the importance of regularly testing backups and recovery procedures. Relevant guidance is available at https://csrc.nist.gov/pubs/other/2020/04/24/protecting-data-from-ransomware-and-other-data-los/final.
For banks and insurance companies in particular, being able to demonstrate this capability is becoming increasingly important. It is not enough to explain how recovery would theoretically work. What matters is whether the process has already been tested in practice.
Modernization and Cyber Resilience Belong Together
Modernization projects almost always change the recovery landscape. A mainframe application that was originally largely self-contained may, after modernization, consist of z/OS components, APIs, cloud services, and distributed applications.
This creates new dependencies. If only the mainframe is rolled back to an earlier data state during recovery while an external service retains its current state, business-level inconsistencies may arise.
Modernization should therefore address more than how an application will be developed and operated in the future. It should also consider how the complete business process can be restored following a serious cyber incident.
This makes application analysis an important part of resilience. Only when data flows, dependencies, and business relationships are understood can organizations determine which components must be recovered together and which checks are required afterward.
Automation can help, but it cannot replace this understanding. Tools such as GDPS can orchestrate recovery processes and make them repeatable. However, an automated process is only as effective as the rules and dependencies defined beforehand.
If that knowledge is missing, automation may simply execute an incomplete recovery process more quickly.
Cyber Resilience Begins Long Before an Attack
The most important lesson is that cyber resilience does not begin when an organization comes under attack. It begins by identifying which business processes are truly critical and which systems support them.
This includes immutable backup copies, monitoring, anomaly detection, documented dependencies, and regularly tested recovery procedures. For banks and insurance companies, these requirements are also becoming increasingly significant from a regulatory perspective.
The European Commission explicitly describes cyber resilience as the ability not only to prevent cyber threats but also to withstand them and recover from incidents. Further information is available at https://finance.ec.europa.eu/digital-finance/cyber-resilience_en.
This fundamentally changes how organizations should view backups. A backup is not a complete resilience strategy. It is a necessary foundation for recovery.
The decisive question is therefore not simply whether a copy exists. What matters is whether organizations know which recovery point can be trusted, which components must be restored together, and whether the process has been tested under realistic conditions.
For business-critical applications in particular, this creates a challenge that brings together security, storage, mainframe operations, application development, business departments, and business continuity.
And perhaps the distinction between backup and cyber resilience can be summarized in two simple statements:
A backup demonstrates that data has been protected.
A robust resilience strategy demonstrates how that data can be used to restore fully functioning business operations.