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.
What is a ransomware recovery clean room?
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.
How does a clean room differ from a DR site or an air-gapped vault?
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.
What are the components of an isolated recovery environment?
A working clean room needs six elements.
- Isolated network segment. No routed path to production by default.
- Independent identity. The clean room runs its own directory and privileged access management. It does not trust production Active Directory, because credential theft is central to almost every ransomware campaign.
- Compute for restore and forensics: enough capacity to bring up the critical application tier, plus separate hosts for forensic imaging.
- Scanning and validation tools: endpoint detection, malware scanners, file integrity checks and indicator-of-compromise sweeps, ideally from a different vendor than the one that missed the attack.
- An immutable backup copy as the source of truth, written to storage with object lock or equivalent write-once protection.
- A promotion path: a documented route to move validated systems back into a rebuilt production network, including how identity, DNS and network policy are cut over.
How does a recovery run through the clean room?
1. Declare
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.
2. Isolate
Production is contained: network segments are cut, remote access is revoked and compromised credentials are disabled.
3. Identify the last known good recovery point
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.
4. Restore into the clean room
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.
5. Scan and validate
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.
6. Harden
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.
7. Promote
Validated systems move to a rebuilt production network in a controlled sequence, with monitoring in place to detect recurrence.
Why does immutable object storage fit as the recovery source?
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.
How large does a clean room need to be?
Restore throughput
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.
Parallel rebuild scope
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.
Should the clean room be on-premises or cloud-hosted?
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.
Comparing DR site, air-gapped vault and clean room
| 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 |
How should a clean room be tested?
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:
- Did measured restore throughput match the sizing model?
- Could identity services be brought up without touching production Active Directory?
- Did scanning tools flag anything in a backup believed to be clean?
- Were any dependencies missing from the critical tier definition?
- How long did the promotion cutover take, and what broke?
How Scality supports clean room recovery
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.
