The CIO & CTO Guide to Cyber Resilience, Architecture and Recovery

Share

Who this guide is for

This guide is written for chief information officers, chief technology officers and heads of technology who own the architecture that resilience depends on, alongside a delivery agenda that rarely pauses.

What technology leadership is actually responsible for

• The dependency map: what depends on identity, on the network, on a single provider and on a single team.
• Recovery architecture, as distinct from backup tooling.
• Technical debt decisions, including which legacy systems will never be recoverable at speed.
• Cloud and platform concentration, and the exit or degraded-mode plan for each.
• How AI adoption changes data flow, access and retention.
• The convergence of IT and OT, where availability and safety outrank confidentiality.

The decisions you own, and what you can delegate

• Own the recovery architecture, the target state and the sequencing of remediation.
• Own the position on identity concentration and administrative dependency.
• Delegate tooling selection and platform operations, against stated recovery objectives.
• Delegate control testing, but review the failure list yourself.

The dependencies that break recovery

• Identity. If the directory is compromised, most restore paths and consoles go with it.
• Management planes. Hypervisor, backup and endpoint consoles are now primary attacker targets.
• Backup catalogue. Immutable storage is of limited use if the index that finds the data is gone.
• Network. Flat internal routing turns a local compromise into an estate-wide one.
• Third parties. Managed service access often bypasses the controls applied to employees.
• Documentation. Runbooks and credentials stored inside the estate they describe.

Designing a recovery architecture

1. Define a minimum viable estate: the smallest set of systems that lets the business trade.
2. For each element, record what it needs in order to be rebuilt, including credentials and configuration.
3. Remove circular dependencies, so that nothing needed for recovery lives only inside the failure domain.
4. Hold a clean, verified copy of that recovery set away from the live estate and away from live credentials.
5. Rehearse a rebuild against a fixed clock and publish the honest duration.

The questions to ask

1. What is our minimum viable estate, and who agreed it with the business?
2. Which recovery steps require credentials that live inside the compromised environment?
3. What is our real time to rebuild identity, and have we done it end to end?
4. Where does a single provider or tenancy create a single point of failure?
5. Which OT or engineering environments are reachable from the corporate network today?

The evidence to expect

• A current dependency map with the recovery set marked.
• A rebuild rehearsal report with elapsed times and failures.
• Evidence that recovery credentials are held outside the estate.
• Segmentation evidence between IT, OT and engineering networks.
• A written degraded-mode plan for each critical platform provider.

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

Technology leaders should treat this as an architecture decision. The test is whether a control removes a dependency you cannot otherwise remove. 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

Most technology estates map onto two or three of these, and CP-07 applies in aviation and aerospace. 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.

• CP-01 Stop Kill-Chain Ransomware uses Firebreak, Isolate, Execute. Read the stop kill-chain ransomware guide.
• CP-02 Contain Active Breaches uses Firebreak, Isolate, Execute. Read the contain active breaches guide.
• CP-03 Control Third-Party Access uses Validate, Relay, Lock. Read the control third-party access guide.
• CP-04 Enforce Physical Segmentation uses Firebreak, Isolate, Unlink. Read the enforce physical segmentation guide.
• CP-05 Protect Critical Infrastructure uses Firebreak, Isolate, Relay, Execute. Read the protect critical infrastructure guide.
• CP-06 Prove Compliance Through Control uses Validate, Lock, Archive. Read the prove compliance through control guide.

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

Where to go next

For the deep technical treatment, read the security architecture guide. For the operational recovery detail, read the IT director guide. For the threat and containment view, read the CISO guide.

Sources and further reading

• NIST Cybersecurity Framework 2.0
• NIST SP 800-34, Contingency Planning Guide
• NCSC, Business continuity and disaster recovery
• IEC 62443 series
• MITRE ATT&CK

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.

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.