A backup is only the beginning of recovery

Most firms have backups. Fewer know what a restore would look like on a bad Monday: which system comes back first, how much work is lost, and who decides. A backup is a copy. Recovery is a procedure, with an owner, an order and a clock.

This article uses public guidance available in January 2026. It is general information for planning, not a compliance checklist or legal advice.

Three numbers the firm owns

NIST’s contingency planning guide, SP 800-34 Rev. 1, defines the terms most recovery plans use. The NIST glossary carries its definitions:

• Recovery point objective (RPO): the point in time to which data must be recovered after an outage. In practice, the most recent work the firm can afford to lose.
• Recovery time objective (RTO): the overall length of time a system’s components can be in the recovery phase before the business is harmed.
• Maximum tolerable downtime (MTD): the amount of time a business process can be disrupted without significant harm.

The order matters. The firm sets the MTD for each process from its own work: client deadlines, transactions in progress, staff who cannot work. Recovery time for each system must fit inside it. The RPO then sets how often copies are taken, and the RTO sets how the restore is built.

On the timeline at the top of this article, the RPO looks backwards from the incident to the last good copy. Everything between them is lost or must be re-entered. The RTO looks forward from the incident to the point where the system works again. Neither is a technical setting. Both are business decisions that technical design must then meet.

What a private AI system must bring back

A private AI system is several systems. A restore that brings back only the documents leaves it unusable. The inventory usually covers:

• Source documents and their access permissions.
• The document index and embeddings built from them.
• The permission map that decides who may retrieve what.
• Model files, by exact version, with their hashes.
• Configuration, prompts, and deployment definitions.
• Logs kept for audit, within their retention limits.
• Secrets and keys, held separately, as described below.

Some items can be rebuilt instead of restored. An index can be regenerated from source documents. That saves backup space but costs time, and the time grows with the collection. The choice belongs in the plan, with the rebuild time measured, because it lands inside the RTO.

The NSA-led Deploying AI Systems Securely guidance recommends keeping hashes and encrypted copies of each model release, storing hashes apart from the files, and keeping a route back to the last known good state. Restoring the wrong model version is a quiet failure: the system answers, but differently.

Offline, encrypted, and tested

CISA’s #StopRansomware Guide asks for offline, encrypted backups of critical data, and for regular tests of their availability and integrity in a recovery scenario. It gives the reason: many ransomware variants search for reachable backups and delete or encrypt them. The same guide recommends golden images of critical systems, configuration kept as code with offline copies, and source code or executables stored with backups, together with escrow and licence agreements.

Encryption brings a dependency. An encrypted backup is useless without its key, and a key stored on the system it protects is lost with that system. Key custody needs its own plan: where keys live, who holds them, and how two people can retrieve them when the usual administrator is absent.

Restore in dependency order

Systems depend on each other. A document store that authenticates users cannot start before the identity service. A retrieval service cannot answer before its index and model are in place. A written restore order, drawn from those dependencies, avoids an improvised sequence under pressure. A typical order runs from network and identity, through storage and databases, to applications, and last to the AI services that sit on top.

NIST’s SP 800-184, Guide for Cybersecurity Event Recovery, frames recovery as planning done before an event: identify and prioritise resources, then build realistic test scenarios around them. The NIST Cybersecurity Framework 2.0 keeps Recover as one of its core functions. Neither prescribes a method. Both place recovery in ordinary planning, not in the incident itself.

A restore test that proves something

A restore test answers questions a backup log cannot:

1. Did every item in the inventory come back?
2. How long did each step take, against the RTO?
3. How recent was the restored data, against the RPO?
4. Does the restored AI system still pass the firm’s reference questions?
5. Were the keys, credentials and documentation where the plan said?

The fourth check is specific to AI systems. Language models do not always phrase an answer the same way twice, so the test does not compare wording. It checks that each reference question retrieves the expected sources, that a user sees only what their permissions allow, and that a reviewer judges the answer as useful as it was at the last accepted evaluation. That catches a wrong model version, a stale index or a broken permission map.

Most tests belong on spare hardware or an isolated environment, where a failed restore harms nothing. Some firms also run a controlled failover of live systems, planned in advance with a way back. Each test ends with a dated record and a list of fixes. The frequency follows the firm’s risk and rate of change.

Where the law meets the plan

Monaco’s Loi n° 1.565, Article 31, lists among appropriate security measures the means to restore the availability of personal data and access to it in appropriate time after a physical or technical incident, and a procedure to test, analyse and evaluate security measures on a regular basis. How that applies to a given firm is a question for its counsel.

The plan on paper

A recovery plan fits on a few pages. It names the MTD for each process, the RPO and RTO for each system, the restore order, the key custodians, the fallback way of working while systems are down, and the date and result of the last test. Printed copies belong somewhere other than the systems they describe.

To plan recovery for a private system, write to contact@desgarde.com.