Cyber resilience has moved from a security concern to a boardroom issue.

Recent high-profile cybersecurity incidents against the likes of Harrods, Jaguar Land Rover, and Asahi have shown how quickly and frequently disruption can take hold. Regulations including DORA, NIS2 and the forthcoming U.K. Cyber Security and Resilience Bill are adding to this strain by raising the bar for how organizations prepare and respond.

Boards are asking more direct questions about how attacks are stopped and how quickly the business can restore operations when systems go down. In practice, resilience is now evaluated by recovery rather than prevention. Perhaps most concerningly, many boards are overestimating their ability to restore systems. Backups are the foundation of that confidence, often seen as a last line of defense. They’re like an emergency exit: you only know they work when you need them.

The burden on IT teams is real

Ransomware attempts are near-constant, recovery targets are tighter, and expectations are higher.

The human impact is being overlooked. Most IT professionals now report feeling uncomfortably stressed at work as cybersecurity threats increase.

When an incident occurs, a small group of people is expected to step in, diagnose the issue, and restore operations, often under intense time constraints.

This is a human process as well as a technical one. Its success depends on how quickly those individuals can make the right decisions, under stress, with incomplete information.

Meanwhile, it’s important to understand that attackers’ tactics have changed. Backups are being targeted up to 96% of the time, with the aim of removing any way to get back online after ransomware is deployed. Backups are no longer just a safety net, but a part of the attack surface.

When systems go down, the impact is immediate

The way organizations operate today leaves very little room for downtime. Services are always-on. Systems are connected across cloud platforms, AI-driven services, partners, and supply chains, which means failures propagate faster and further than before.

When disruption hits, the impact is immediate. Productivity drops, services become unavailable, and organizations can no longer operate or generate revenue effectively. The longer systems remain down, the greater the knock-on effects – from financial losses and potential regulatory penalties to reputational damage and mounting pressure on already stretched IT teams.

Given that every minute counts, it’s no surprise that organizations are setting increasingly aggressive recovery point objectives (RPOs) and recovery time objectives (RTOs). That, in turn, places greater demand on both the technology and the people responsible for restoring systems quickly and effectively.

The key question is can the organization bounce back quickly enough to avoid lasting damage? For many businesses, even a relatively short period of downtime could be an existential threat.

Why many backup strategies fall short

For many organizations, the answer is less certain than it should be. Often, they still rely on backup systems that were not designed for this kind of threat environment.

On paper, these systems often look robust, but they can introduce risk. Data may be vulnerable to tampering or exfiltration while in transit from backup software to backup storage, if the storage method precludes end-to-end encryption. Immutability may not be applied immediately, creating a window where backups could be maliciously encrypted by an attacker. In some cases, administrative access may allow the removal of backups altogether.

Furthermore, recovery processes may depend on multiple steps that have never been fully tested.

This is why recovery attempts sometimes fail when it matters most. Not because backups do not exist, but because they cannot be trusted or restored quickly enough.

Recovery needs to be proven

Regulation is pushing organizations to address this gap, and requirements like DORA’s Article 11 are becoming more specific about recovery time and resilience testing.

There are also higher expectations from insurers. Prerequisites to get policies are changing. It is no longer enough to simply say that backups exist.

Organizations are being asked to show that they can restore systems after incidents, under real conditions. Those that can demonstrate this are in a stronger position when it comes to coverage and claims.

Why absolute immutability is the way forward

This is where absolutely immutable backup storage comes into focus.

Absolute immutability means that once data is written, it cannot be changed or deleted. It ensures protection is enforced at the storage level and that no one, not even the most privileged administrator or a successful attacker, can modify or delete backup data.

Architecturally, backup storage with absolute immutability uses the S3 protocol; rather than being an added-on feature, immutability is “baked in” with object lock and versioning in compliance mode. This allows zero access to destructive actions, irrespective of credentials held – whether legitimately or when stolen by an attacker.

Similarly, this architecture removes risks associated with systems that rely on delayed immutability or snapshots that can leave a gap where data is still exposed. Coupling that with end-to-end encryption reduces the risk of exfiltration while data is in transit.

Immutability is quickly moving from being a specialist feature to a basic requirement. As expectations from regulators, insurers and boards increase, organizations need to know that their data will be secure and recoverable without question.

Control is becoming part of resilience

Resilience is also becoming a question of control, in light of regulations like the EU’s NIS2 directive. Organizations are being asked where their data sits, who can access it and how it can be restored if primary systems are unavailable. This is particularly relevant in regulated sectors, where data residency and operational independence are under closer review.

From a design perspective, this is driving a move towards architectures that reduce reliance on shared systems and limit the impact of compromised credentials. It also puts more focus on separation between backup software and storage so a single point of failure does not affect both.

Preparing for the moment when it matters most

Organizations can no longer afford to hope recovery will succeed.

For years, organizations have invested heavily in keeping attackers out. Despite growing awareness of zero-trust principles, fewer organizations have as yet invested with the same urgency in what happens when those attackers get in.

That imbalance is being exposed; the cost of it is measured in downtime, lost revenue, and reputational damage that takes far longer to recover from than the incident itself. In today’s threat landscape, resilience is proven by recovery under pressure, not prevention.

Most organizations still measure security by what they are able to stop. The real test is how their systems and processes will cope when a bad actor breaches those defenses, and most importantly whether their backup infrastructure can be relied upon to restore operations without compromise, delay, or failure.