After a ransomware attack, the fastest path to recovery is also the most dangerous one: restore the last backup straight back into the production environment that was just compromised. If the attacker's persistence mechanisms, stolen credentials or dormant malware are still present, the restored systems can be encrypted again within hours. A recovery clean room breaks that loop by giving the organization a segregated place to rebuild before anything touches production again.
Attackers typically spend days or weeks inside a network before encryption, harvesting credentials, disabling security tooling and tampering with backups. By the time the ransom note appears, neither production nor the backup catalog can be trusted, and recovery becomes a forensic and engineering exercise rather than a restore job. This article explains what a clean room is, how it differs from a DR site and an air-gapped vault, what it needs, how a recovery runs through it, how to size it and how to test it.
A clean room, also called an isolated recovery environment (IRE), is a segregated network, compute and storage environment in which backup data is restored, scanned, validated and rebuilt before being promoted back to production. It assumes production is hostile: nothing from the compromised estate is trusted, including its directory services and its administrators' credentials.
Good backups are necessary but not sufficient. A backup taken the night before the encryption event almost certainly contains the attacker's foothold, because the intrusion predates the detonation. Restoring it into production hands the environment back to the attacker. The clean room adds the missing step: a controlled space to find and remove the compromise before the data goes live.
A disaster recovery site is designed for availability. It replicates production continuously so that services can fail over after a fire, flood or power loss. In a ransomware scenario that replication is the problem: the DR site faithfully receives the encrypted data, the stolen credentials and the attacker's tooling.
An air-gapped vault is designed for survivability of the data. It holds an immutable, disconnected copy of backups that an attacker with production access cannot delete or alter. It is a source of truth, but not a place to run or investigate workloads.
A clean room takes the trustworthy copy from the vault and gives it somewhere safe to be restored, examined and repaired. Mature organizations operate all three.
A working clean room needs six elements.
The incident is formally declared and the recovery team is stood up with clear authority. Declaration triggers the runbook and freezes changes to backup infrastructure.
Production is contained: network segments are cut, remote access is revoked and compromised credentials are disabled.
Forensic analysis establishes when the intrusion began. The recovery point must predate that moment, not just the encryption event. This is often the longest step and the most tempting to rush.
Systems are restored from the immutable copy, starting with the dependencies everything else needs: identity, DNS, DHCP and core network services, followed by the critical application tier.
Every restored system is checked for malware, persistence mechanisms, scheduled tasks and rogue accounts. Anything that fails is discarded and restored from an earlier point.
Systems are patched, credentials and certificates are rotated, and the weakness that allowed the initial intrusion is closed. Promoting an unpatched system re-creates the original risk.
Validated systems move to a rebuilt production network in a controlled sequence, with monitoring in place to detect recurrence.
The whole workflow depends on step 4 starting from data that has not been tampered with. Object storage with object lock provides this: each backup object is written once and cannot be modified or deleted until its retention period expires, even by an administrative account. In compliance mode, no user or role can shorten the retention window.
This matters because attackers routinely target backup infrastructure first, since destroying backups removes the victim's alternative to paying. An immutable object store denies that option and gives the recovery team a copy whose integrity does not depend on the security of the backup server or the stolen credentials. It also holds many recovery points across a long retention window, which matters when the last known good point is weeks old. Because the store is reached over S3, a backup server inside the clean room can read the same buckets directly.
Suppose an organization's critical tier totals 200 TB and the business requires those systems validated within 48 hours. If scanning and validation consume half of that, roughly 24 hours remain for data movement, implying a sustained restore rate of about 2.3 GB per second. That figure drives storage, network and parallel-stream requirements.
Few organizations can afford a clean room that mirrors all of production. The usual approach is to tier applications and size for the minimum viable business: identity, communications, core transaction systems and their dependencies. Everything else is rebuilt in later waves through the same environment.
An on-premises clean room offers full control over isolation, predictable restore performance from local storage and no dependency on external connectivity during an incident. Its cost is idle capacity.
A cloud-hosted clean room can be provisioned on demand and scaled to the incident, lowering standing cost. Its challenges are restore throughput over a WAN, egress and compute charges during a multi-week recovery, and the need for a cloud identity and network design genuinely independent from production. Hybrid designs are common: a modest always-on clean room and the immutable copy stay on-premises, with cloud capacity as overflow for lower tiers.
| Attribute | DR site | Air-gapped vault | Clean room / IRE |
|---|---|---|---|
| Purpose | Service availability after site loss | Survivability of backup data | Safe restore, validation and rebuild after compromise |
| Isolation level | Low: continuously replicated from production | High: disconnected and immutable | High: segregated network and identity, controlled ingress only |
| Data source | Live replication | Scheduled immutable backup copies | Immutable copies from the vault |
| Typical use | Failover for outages and disasters | Last-resort copy attackers cannot alter | Active ransomware or breach recovery |
| Limitations | Replicates malware and encryption; shares credentials | Cannot run or validate workloads | Standing cost; requires runbooks and rehearsal |
An untested clean room is a diagram, not a capability. Tabletop exercises walk incident, security, infrastructure and business teams through a simulated attack against the runbook. They expose decision gaps: who declares, who approves a recovery point, who signs off promotion.
Full rehearsals actually restore a representative tier from the immutable copy, scan it and time each step. A rehearsal should answer:
The clean room workflow depends on an immutable recovery source that survives the compromise of production. Scality ARTESCA is S3 object storage designed for backup, with object lock immutability and validation with the major backup applications, so backup copies cannot be altered or deleted within their retention period and can be read directly by a backup server inside the clean room.
Scality's CORE5 approach frames cyber resilience across five levels: API, data, storage, geographic and architecture. A clean room design maps onto that model: immutability at the data and storage levels, geographic separation of the vault, and an architecture that assumes production cannot be trusted.
For more on how immutable storage fits into recovery planning, see Scality's cyber-resilience use case and the glossary entry on breach containment.
The practical takeaway: decide now where a compromised estate will be rebuilt, make sure the source copy is immutable, and rehearse the restore before an attacker sets the schedule.