Everything leaders should know about Offline Secure Storage

Share

Boards are accountable for cyber risk without running security, and that is an uncomfortable position. The technical detail is delegated, the budget is approved at a summary level, and the assurance arrives as a dashboard. Then an incident happens and the question changes from whether controls exist to whether the organisation can still function.

This explainer sets out what Offline Secure Storage® is in board language, why it exists as a separate control rather than another line in the backup budget, and what a director should ask and expect to see in return.

What it is, in one paragraph

Offline Secure Storage® is dedicated physical storage capacity, held on real drives in a professionally secured facility, with no live network path to it. The connection is physically open at Layer 1. It closes only when an authorised out-of-band command asks for it, for a defined window, and it opens again afterwards. Firevault calls the principle Disconnect to Protect®.

The board-relevant point is not the engineering. It is that the copy of the data on which recovery depends cannot be reached by anything inside the organisation's network, whatever privileges an attacker acquires.

The distinction that matters at board level

Backup and recovery are not the same subject, and confusing them is the most common failure in board reporting.

Backup is a copy. It is measured in coverage and success rates, and it is usually reported as green. Recovery is the ability to rebuild the organisation from that copy, in a defined time, while the environment that produced it is compromised or untrusted. It is measured in tested restores, and it is rarely reported at all.

Modern ransomware is deliberately aimed at that gap. Attackers reach recovery infrastructure using legitimate administrative credentials, then delete snapshots, alter retention policies and disable jobs before encrypting anything. MITRE ATT&CK records that behaviour formally under Inhibit System Recovery, T1490, and its own mitigation advice is to keep recovery copies off system.

So the honest board question is not "do we back up?" It is "is there a copy that a compromised administrator account cannot reach, and have we restored from it recently?"

Why this sits on the board agenda

Three reasons, and none of them are technical.

Accountability is personal and increasing. Directors carry duties for the resilience of the business, and regulators across regimes such as NIS 2, DORA, GDPR Article 32 and sector-specific rules are asking for demonstrable resilience rather than documented intent. Under the UK Corporate Governance Code, boards are expected to describe how they monitor risk management and internal control effectiveness.

Downtime is the loss, not the ransom. The material cost of a serious incident is trading interruption, lost orders, contractual failure, remediation, legal cost and reputational damage. Ransom payment is a small and unreliable part of the picture, and paying does not restore the estate.

Insurance transfers less than boards assume. Cyber insurers increasingly ask directly whether an offline or immutable copy exists and whether restores are tested. Answers determine premium, retention and, at claim stage, whether the loss is covered at all.

What the board is actually buying

A defensible answer to a single question: if the connected estate is untrusted tomorrow morning, what do we rebuild from, how long does it take, and who has proved it?

That answer has four components, and a director can hold management to all four without any technical knowledge.

A defined data set. Not the whole estate. The records the business cannot be reconstituted without: the last known good backup set, financial and payroll records, contracts, intellectual property, regulatory evidence, identity system backups and the configuration needed to rebuild the environment itself.

An isolated copy. Held where no network path exists to it from the operating estate.

A named authority. A defined, small list of people who can request access, with a control path separate from the data path and a full audit record.

A tested restore. A dated record of a restore from that copy, with the time it took.

The questions to put to management

Which data would we be unable to trade without, and where is the copy that an attacker inside our network cannot reach? If the answer describes policy, virtual separation or cloud retention settings, the copy is still reachable by whoever controls the configuration.

When did we last restore from it, and how long did it take? A recovery objective that has never been tested is an aspiration.

Who can authorise access to that copy, and how is that request made? The right answer is a short named list using a path that does not run through the corporate network.

Could we rebuild our identity system from it? Almost every recovery plan assumes identity is available. Attackers know this.

What does our insurer ask about offline copies, and what did we answer? Compare the answer with the evidence.

What would the first 72 hours look like? Ask for the sequence, not the intention.

Evidence to expect back

A one-page schedule of the protected data set and who owns it. Written confirmation of where the isolated copy is held and under which jurisdiction. The named-authority list and the access procedure. Dated restore test results with elapsed times. The audit record of access windows over the last period. The current insurance questionnaire responses on backup and recovery.

That package is short, readable without technical training, and holds its shape under audit, regulatory questioning and litigation.

What good looks like

The organisation can name the data it cannot lose. There is a copy of it that no credential inside the estate can reach. Access to that copy is a deliberate, recorded act by a named person. A restore has been performed and timed within the last quarter. The board sees that evidence at least annually, and after any material change to the estate.

Where Firevault fits

Firevault provides Offline Secure Storage® as the isolated copy behind existing backup arrangements, held on dedicated drives in Firevault Bunkers, with access controlled from outside the data network. Instances run from LUV at 300GB through Vault at 2TB, 4TB and 8TB, Storage from 20TB and Enterprise from 300TB. Jurisdiction is the customer's choice, with Bunkers live across Europe, including the United Kingdom, and the United States and the Middle East next.

Beyond stored data, Control by Firevault governs the physical paths into an estate through Control Modules and eight Control Blueprints, for organisations that need the same physical logic applied to operating systems rather than records.

Where to go next

For the complete subject in one place, read Offline Secure Storage®: everything you need to know. For the governance-led treatment, see Cyber Security for Boards. To size an instance without a sales conversation, use the OSS Concierge.

The board test is simple. Not whether the organisation is defended, but whether it could rebuild itself if the defences failed, and whether anyone has checked.

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.