What this is really about
Most ransomware-readiness conversations stop at the backup side: immutability, object lock, the 3-2-1-1-0 rule. All necessary — but they answer only one question: *did a copy survive?* They say nothing about the question that decides the outcome: can you put the business back together, fast, without restoring the attacker along with the data?
Normal backup is not a recovery strategy. Real ransomware recovery is a layered architecture — and what matters is the capability each layer must deliver, not which product delivers it.
Why it matters
In a real event, the clock that matters is recovery time under pressure — with a compromised environment, identity you can't trust, and stakeholders demanding answers. Teams with technically perfect immutable backups still lose weeks because they had a backup *copy* but never built a recovery *pipeline*.
A backup you've never restored is a hypothesis. A WORM copy of infected data is a trap. The architecture below exists to avoid both.
IT Intel's recommended architecture
IT Intel's position is straightforward: don't buy a backup product and call it recovery. Build a recovery workflow of deliberate layers, each defined by the capability it must deliver — not by a product.
Think of it as a controlled pipeline:
Air-gap → Analyze → Validate → Restore → Restart
The layers, drawn from real recovery work:
- Air-gapped copy — IT Intel recommends physical over logical. A logical air-gap is a policy; a physical air-gap is a fact. We recommend a genuinely physical air-gap — offline and unreachable over any network — as the default for the protected copy. Logical or network isolation is a fallback where physical truly isn't feasible, not an equal substitute: anything reachable over a network can, in principle, be reached by an attacker who is already inside.
- Analysis before permanent WORM. The layer most designs miss. If you commit backups straight to permanent WORM, you can immutably preserve the malware. The required capability is an analysis stage that scans and validates each copy for encryption anomalies and indicators of compromise *before* it is locked.
- Data landing zone. A staging area where copies land to be inspected, validated, and proven clean before they're trusted as a recovery source — isolated from both production and the immutable vault.
- Clean room. An isolated environment to restore into and verify, so unverified systems never touch production.
- Restart room. Where validated, clean workloads are brought back into service in dependency order — the bridge from "data recovered" to "business running."
Why "analyze before WORM" is the layer everyone misses
Immutability is sold as the answer to ransomware — and it is, for *protecting* the copy. But immutability is indifferent to *what* it protects. Lock infected or encrypted data to permanent WORM and you've done the attacker a favor: a guaranteed, tamper-proof copy of their payload.
The fix is sequence. Data lands, gets analyzed for anomalies and known indicators, and only clean, validated points get committed to permanent immutability. The order is the control — not the storage feature.
Recovery execution readiness — test the restore, not the job
An architecture you've never exercised is still a hypothesis. A green backup job proves data was written; it does not prove you can run the pipeline under incident conditions.
- Tested runbooks — has a full restore through the clean room and restart room actually been performed end-to-end, recently?
- Measured RTO — your real recovery time across the whole pipeline, not a single restore in a lab.
- Dependency order — identity, DNS, databases, then apps; the wrong sequence wastes the hours you can least afford.
If you can't point to a recent, documented full-pipeline drill, your true RTO is unknown.
Trade-offs & risks
Every layer has a cost — pretending otherwise is how plans look good on paper and fail in practice:
- Physical air-gap is the strongest isolation but the slowest to retrieve — it raises confidence and can raise RTO. Match depth of isolation to each workload's recovery objective.
- The analysis-before-WORM stage adds a step and infrastructure, but skipping it risks immutably storing the attack.
- Clean room + restart room cost money to stand up — far less than the downtime and reinfection they prevent.
IT Intel's recommendation
Our recommendation is unambiguous: measure recovery, not backup — and build the whole workflow, not just a protected copy. Prefer a physical air-gap over a logical one, analyze before anything is locked to permanent WORM, validate in a landing zone, restore into a clean room, and restart in dependency order. Then rehearse it end-to-end at least quarterly.
We state this as capabilities by design — independent of any product. Match each layer to whatever meets the requirement in your environment.
In a ransomware event, you don't rise to the occasion; you fall back to the level of recovery you've actually built and rehearsed.