AI without data strategy is just expensive experimentation

• Traditional disaster recovery was designed for physical failures like site outages, but modern cyber attacks can simultaneously corrupt primary, secondary and backup environments, demanding a fundamentally different storage architecture

• Genuine cyber recovery depends on three capabilities working together: immutable data protection that withstands compromised admin credentials, a clean room environment that is physically and logically separate from production, and tested recovery sequencing that accounts for foundational service dependencies

• Proving recovery capability is an ongoing discipline, with regulators increasingly setting explicit recovery time objectives and AI platforms introducing new validation challenges that signature-based scanning alone cannot address

Disaster recovery has been the default language for describing what happens when critical systems fail. But the threat landscape has shifted well beyond the physical site failures that traditional DR was built to handle. 

Modern cyber attacks target identity, storage, backup systems and admin accounts in a single campaign, and organisations that discover their recovery architecture wasn't designed for that scenario tend to discover it at the worst possible time. 

Datacom's 2026 Cybersecurity Index reinforces the scale of this challenge. While 77% of Australian security leaders believe they have sufficient visibility across risks and vulnerabilities, only 32% have a business continuity or cyber incident response plan in place.

We spoke to Daniel Bowbyes, Associate Director of Strategy at Datacom, about what cyber-ready storage architecture looks like in practice, why clean room design is widely misunderstood, and how organisations can validate their recovery capability before an incident forces the question.

For many years, disaster recovery has been the catch-all phrase used in IT teams and the business leaders they serve to describe what happens when critical systems fail.

The problem is that now, the assumptions surrounding this phrase are dangerously outdated. Disaster recovery (DR) used to be mainly about having access to backups of mission-critical data, stored somewhere safe, often on tape drives. 

But modern cyber attacks don’t just take down a data centre, they can simultaneously corrupt primary, secondary and even backup environments. The only reliable way back to what I’ve previously referred to as a minimum viable business is through storage architecture designed explicitly for cyber recovery – the process of restoring critical data, systems, and operations after a cyberattack.

When it comes down to it, traditional DR was built for physical failure, maybe an earthquake, fire, or similar site outage. You failed over to a secondary environment, restored from backups, and carried on. 

Modern cyber attacks target identity, storage, backup systems and admin accounts in one campaign, turning a traditional DR strategy on its head. The scramble used to be all about restarting systems to get business operations going again.

Now you have to consider whether you can restart the business with data you can actually trust and in a timeframe regulators and customers will accept.

That’s the essence of cyber recovery, and it lives and dies by how you design storage. Can you recover clean data instead of reviving malware or manipulated records? Is your recovery environment truly isolated when production has been crypto-locked? Does your architecture support the sequence of services you need to bring back first – identity, Domain Name System (DNS), Network Time Protocol (NTP), certificates – before key applications and AI agents?

In my conversations with customers, it's clear this is a growing concern and recent high-profile cyber breaches on both sides of the Tasman have crystallised thinking on cyber recovery. Recovery expectations remain part of the challenge too. Datacom research shows that while leaders commonly anticipate full recovery within days, complex incidents routinely take weeks or months – driven by untested plans, fragmented tooling and unclear decision-making authority.

When I break this down for customers, I think in three blocks: protecting data, designing a clean room, and proving you can recover.

1. Protecting data with genuine immutability

Immutability – protecting data by preventing changes or alterations for either a set or indefinite amount of time, isn’t new. We’ve had write-once-read-many (WORM) drives and tapes for decades. What has changed is the ability to do immutability at enterprise scale, across petabytes of data on modern storage arrays and cyber recovery appliances.

There is a spectrum of immutability, and each point has different risk and cost trade‑offs. There’s snapshot-based, software-controlled immutability on production arrays, off-array cyber recovery appliances (like Dell PowerProtect Data Domain) with configurable retention locks, and fully air‑gapped vaults with separate admin accounts, networks and sometimes even data diodes, hardware-based security devices.

The crucial question is: what can your administrator accounts do? Many attacks now focus on privileged credentials. If a single compromised admin can override retention policies or erase an immutable vault, your “protection” evaporates at exactly the worst moment.

Multi-party authorisation models – requiring, say, four out of seven administrators to approve changes to retention or immutability – are becoming best practice to guard against that. At the same time, you need to avoid the opposite failure mode: setting retention periods that lock you into multi-year storage costs you can’t escape. 

I’ve seen customers stuck with government-grade immutability on arrays they no longer need, paying for capacity they can’t commercially erase. This is not a box you tick and forget – it’s a risk-based decision blending technical design, business requirements and commercial commitments.

2. Designing a clean room that stays clean

A ‘clean room’ is the environment you recover into when production is compromised. It sounds simple, but in practice, it’s one of the most misunderstood pieces of cyber recovery architecture.

First, your clean room must be physically and logically separate from production. Nesting it inside the production environment – carving off a “safe” segment – fails the first real test. If production is crypto-locked, your nested clean room disappears with it.

You then need to decide whether the clean room is a staging zone, where workloads are recovered, validated and then moved back into a rebuilt production environment, or a new production environment you will operate from for an extended period. That is the distinction that drives critical design decisions.
 

                Performance and capacity: a future production environment cannot run on cheap,
                slow storage.
 

                Scalability: you may need to rapidly increase capacity mid-incident to host core
                systems and associated data.
 

                Sovereignty and regulation: some organisations can recover into hyperscaler tenancies.
                Others, under regimes like CPS 234, the Australian Prudential Regulation Authority's
                (APRA) strict Information Security Standard, really need to build a dedicated,
                 sovereign clean room.
 

Datacom's Cyber Index found 65% of Australian organisations are concerned about sovereignty and the long-term viability of in-country AI compute capacity, underscoring why clean room location and jurisdictional control are becoming design-level decisions rather than afterthoughts.

But where the clean room sits is only part of the equation. Modern cyber recovery products can scan data with antivirus-style signatures and heuristics, but they don't understand business semantics.

The other half of the clean‑room story is how you keep it clean. Modern cyber recovery products can scan data with antivirus-style signatures and heuristics, but they don’t understand business semantics. If a bad actor has manipulated health records or financial transactions in subtle ways, signature scans won’t spot that.

You need a process that can identify when the breach occurred and determine how far back in your vault you must go to find genuinely clean copies. You must then decide when the business value of recent transactions outweighs the risk of importing some contamination and cleaning it manually.

That’s where things get genuinely complex – and where storage architecture, forensic capability and business risk appetite intersect.

3. Proving you can recover – regularly

Cyber recovery isn’t a one‑and‑done project, it’s an ongoing discipline. Regulators are increasingly explicit about recovery time objectives – I’ve seen core banking environments required to recover within four hours, driving investment into high-performance solid‑state cyber vaults purely to meet throughput demands.

Testing has to move beyond “we restored one database from backup” to “we validated full-environment recovery under realistic pressure”.

You need to be running full recovery tests into the clean room, not into production.

We recommend using synthetic workloads to validate behaviour, especially for AI and other non‑deterministic systems. Documenting and rehearsing the sequence regularly is crucial, from foundational services like identity, DNS and certificates, through to business applications and AI agents.

For AI platforms, the challenge is even greater. These are non‑deterministic systems – you can’t just compare before/after data structures and declare success. You need behavioural guardrails and test harnesses that prove recovered agents deliver the right answers and exhibit expected behaviour. It’s an emerging field, but it has to be part of any forward‑looking storage recovery strategy.

If you’re assessing your storage architecture through a cyber recovery lens, these are the questions I’d start with:

Immutability and retention

• Do we have truly immutable copies of our critical data, and where do they live?

• Who can change retention or override immutability? Do we use multi-party approval for those changes?

• Have we modelled the long-term cost and liability of our retention periods?

Clean room design and purpose

• Is our clean room completely isolated from production at the infrastructure, network and identity layers?

• Is it intended as a staging environment or as a potential new production environment, and is capacity/performance sized accordingly?

• Does its design meet our sovereignty and regulatory obligations?

Data scanning and forensic capability

• How do we determine which vault copies are clean, and how far back we must go?

• Can we balance the value of recent transactional data against the risk of importing some contamination and cleaning in situ?

• Who owns the forensic process, and how often do we revisit our assumptions?

Recovery sequencing and performance

• Have we documented and tested the full sequence of services and applications needed to reach minimum viable business?

• Do our vault and clean-room platforms deliver the throughput to meet regulatory recovery timeframes?

• How do we handle recovery of key management systems, public key infrastructure (PKI) and hardware security modules without breaking good cryptographic practice?

Non-deterministic systems and AI

• For AI and other non-deterministic platforms, how do we validate post-recovery behaviour, not just data integrity?

• Do we have synthetic tests and guardrails in place to check that agents are performing as expected?

Commercial and lifecycle considerations

• How exposed are we to current and forecast hardware price and availability volatility in our recovery plans?

• Have we pre-negotiated access to replacement capacity and services, rather than assuming we can buy what we need on the open market mid-incident?

If you can answer those questions with confidence, and back them up with tested evidence, you’re a long way towards genuine cyber recovery readiness. If not, it may be time to treat storage architecture not just as an operational concern, but as a strategic resilience decision.

All of this can sound daunting, and frankly, it is. There are a lot of moving parts and a lot of dragons hiding in the details. This is where Datacom’s Dedicated Storage as a Service with Dell Technologies can offer powerful pain relief.

DSTaaS gives you a spectrum of storage services – from enterprise-grade block storage for production to cyber recovery vaults with configurable immutability.

It also offers a consumption-based model for clean‑room compute and storage, so you pay for what you use during recovery tests or real incidents rather than over‑investing upfront.

Organisations can host resilient storage in sovereign, certified environments, adjacent to public cloud or in your own facilities, depending on your regulatory posture.

In other words, DSTaaS provides the dedicated, flexible infrastructure layer you and your team need to make the cyber recovery patterns above not just well-intentioned plans, but operational reality.

Read more about Datacom’s Dedicated Storage as a Service with Dell Technologies, and our approach to supporting digital resilience for Australian and New Zealand organisations.