Guides·28 August 2026

IT Director's Guide to Ransomware Recovery, Backups and Infrastructure Resilience

The practical recovery guide: immutable versus offline, Active Directory rebuild, management plane compromise, clean recovery environments, restore testing and realistic RTO and RPO.

Mark Fermor
Mark FermorDirector & Co-Founder, Firevault
6 min read
Share
IT Director's Guide to Ransomware Recovery, Backups and Infrastructure Resilience
Guides

Why it matters

What this means for organisations holding critical data

The practical recovery guide: immutable versus offline, Active Directory rebuild, management plane compromise, clean recovery environments, restore testing and realistic RTO and RPO.

Who this guide is for

This guide is written for IT directors, heads of infrastructure and the people who would actually run the rebuild. It concentrates on recovery mechanics rather than strategy.

What infrastructure leadership is actually responsible for

  • Backups that exist, verify and restore, in that order.
  • A rebuild sequence that starts from nothing and reaches a trading business.
  • Protection of the management planes that recovery depends on.
  • Recovery credentials and configuration held outside the estate.
  • Restore testing that is measured, dated and honest about failures.

Immutable, air-gapped and offline are not the same thing

  • Immutable means the data cannot be altered for a retention window. It usually still sits inside the same account, tenancy or administrative boundary as the estate.
  • Logically air-gapped means the connection is controlled by software or configuration. Whoever controls that configuration controls the gap.
  • Physically offline means there is no electrical path to reach the data at all. It is slower to restore from, which is why it suits a defined critical set rather than everything.

Our comparison of air gap versus immutable backup sets out the trade-offs in more detail.

The recovery sequence people get wrong

  1. Establish a clean environment that is not administered from the compromised one.
  2. Rebuild identity first. Test an authoritative Active Directory or directory restore end to end, including the recovery of tier-zero credentials.
  3. Restore the management planes: virtualisation, backup infrastructure and network administration.
  4. Restore the minimum viable estate, verified against a known-good baseline before reconnection.
  5. Stage reconnection, monitoring for reinfection at each step.

Recovery credentials, the backup catalogue and the runbooks all need to exist outside the failure domain. This is the most common reason a technically sound backup estate still results in a multi-week outage.

Restore testing that means something

  • Test a full rebuild, not a file restore.
  • Use the clock, and record where it went wrong.
  • Include the systems people forget: certificate authorities, DNS, DHCP, licence servers, MFA.
  • Test with the assumption that the primary administrator account is unavailable.
  • Publish the measured RTO and RPO back to the business and to finance.

The questions to ask

  1. Can a domain administrator delete or encrypt every copy of our data today?
  2. Where do our recovery credentials live, and would we reach them during an incident?
  3. How long did the last full identity restore take?
  4. Which restores have we never actually performed?
  5. What would we do if the backup console itself were compromised?

The evidence to expect

  • A dated restore test report with durations and failures.
  • A rebuild runbook available offline.
  • An inventory of the critical set: the data that must survive at any cost.
  • Evidence of separation between production and recovery administration.
  • Reconnection and verification criteria agreed in advance.

What happens when preventative controls fail

Prevention buys time. It does not remove the need to answer a simple question: if an attacker holds your identity platform and your management console tonight, what still works tomorrow morning? Most organisations discover that their backup catalogue, their recovery credentials and their runbooks all depend on the systems that have just been taken. That is the dependency worth removing first.

No control removes the possibility of a serious incident. The realistic goal is a smaller blast radius, a recovery path that does not depend on the compromised estate, and evidence that both were tested.

Deciding what you actually need

Offline Secure Storage® belongs around a defined critical and clean recovery set. It is not a replacement for your normal backup infrastructure, and anyone who tells you otherwise is selling rather than advising. Firevault is the company. It provides three distinct things, and the honest answer is often that you need one of them rather than all of them.

  • Offline Secure Storage® holds a defined set of critical records and clean recovery data physically disconnected from the live estate. It is a protected set, not a replacement for your backup infrastructure.
  • Control Modules are a suite of nine purpose-built tools and techniques that give you physical control over the paths into and across your estate. Introduce only the modules that map to the risk you are treating.
  • Control Blueprints are proven combinations of those modules assembled for a named outcome, such as containing a live breach or governing third-party access.

If your existing controls already deliver a tested recovery path that survives the compromise of your identity and management planes, and you can evidence it, you may not need any of this. Test that assumption before you buy anything. If you are unsure which of the three applies, the Firevault Concierge walks through the question set without a sales conversation.

The Control Blueprints most relevant to this role

These are the patterns that touch infrastructure and recovery directly. Control by Firevault is a set of nine Control Modules, grouped into the FIRE layer (Firebreak, Isolate, Relay, Execute) and the VAULT layer (Validate, Archive, Unlink, Lock, Transfer). Seven Control Blueprints combine those modules for a specific outcome. You do not need all nine modules, and most organisations start with one blueprint.

The full set is on the Control overview and the Control Blueprints index.

Where to go next

For the architecture behind these choices, read the CIO and CTO guide. For threat framing, read the CISO guide. Our note on recovery independence covers the credential problem specifically.

Sources and further reading

About this guide

Author Mark Fermor, Firevault. Reviewed by Firevault engineering review. Last reviewed 28 August 2026.

This guide draws on primary regulatory and technical sources together with Firevault's own field work on physical isolation and offline recovery. It is guidance, not legal advice. Where a legal or regulatory duty is in question, take advice on your own circumstances.

Other guides in this series are listed on the role guide hub.

About the author

Mark Fermor

Mark Fermor

Director & Co-Founder

Co-founder of Firevault, focused on offline secure storage and protecting individuals and businesses from fraud, fines, loss and damage. Speaker, owner and advisor.

How Firevault would handle this

A recovery copy an attacker cannot reach

Offline Secure Storage® keeps a clean copy of your data on hardware that is physically disconnected, so backup and recovery do not depend on systems an intruder can touch.

HardwareYour copy sits on dedicated encrypted hardware
DisconnectOffline by default, connected only when you say so
RecoveryA known-clean copy to rebuild from, on your timetable
LocationHeld in a secure Firevault Bunker
Mark Fermor
David Bailey
Kenny Phipps
Online Now
Concierge

Put this guide into practice

Ready to apply what you have learned? Explore how Firevault delivers the offline protection covered in this guide.

Takes about 2 minutes. No account needed.

Free2 minsNo sign-up