ANSSI backup guidance is the reference French public bodies are measured against when their backups are audited or when a tender for backup infrastructure is written. ANSSI, the national cybersecurity agency of France, published its guide on the fundamentals of information system backup in October 2023 and revised it to version 1.1 in November 2025. The guide contains 32 numbered recommendations covering architecture, operations and data protection. It is short, concrete and written with ransomware in mind.
This post summarizes what the guide asks for, how binding it is and what its recommendations mean for the storage that holds backup copies. It is a general overview. The guide itself, referenced as ANSSI-BP-100, is the authoritative text.
The guide states that its recommendations are not normative unless a regulation provides otherwise. For a French ministry, local authority or public hospital, that qualification matters, because other texts do bind them. The general security framework known as RGS requires administrative authorities to analyze risks and formally accredit their systems, and auditors use ANSSI guides as the yardstick for whether the measures chosen are reasonable. Sector rules add further obligations, such as certification for hosts of health data. In practice a public body that departs from the guide is expected to be able to explain why.
Most of the 32 recommendations concern how the backup system is built and administered. The ones below shape the choice and configuration of backup storage directly.
| Topic | What the guide recommends | What it means for storage |
|---|---|---|
| Copies | Three distinct copies on different media, at least one offline | A second target, plus a copy that cannot be reached over the network |
| Segregation | Backup servers in the administration zone or a separate network zone | Storage endpoints on a dedicated, filtered network |
| Directory independence | Backup servers kept out of the production directory domain | Local or dedicated accounts on the storage system |
| Datastore access | Datastores reachable only from backup servers | Network and credential scoping on each bucket or share |
| Administration | Named, dedicated administrator accounts and separate roles | Role separation on the storage platform itself |
| Restore testing | Regular tests against a written restore procedure | Capacity and throughput reserved for test restores |
| Encryption | Encrypted, mutually authenticated backup flows; key management studied | TLS to the storage endpoint and a plan for key custody |
| Logging | Actions on the backup infrastructure logged and centralized | Storage audit logs exported to a separate system |
One recommendation deserves particular attention because it runs against a common convenience. The guide asks that backup servers are not members of the production directory domain and that they authenticate independently, with local accounts or a dedicated administration directory. The reasoning is that attackers who take over the directory inherit every system that trusts it. A backup store that accepts production directory accounts falls with the rest.
The same logic applies one layer down, to the storage. Its administrative accounts should not come from the production directory, and its credentials should be scoped so that the backup server can write and read but cannot change retention. The posts on backup credential security and Active Directory recovery and backup access cover how to set that up and how to recover the directory itself when it is the casualty.
The guide treats an offline copy as indispensable, even if it is refreshed less often than online backups. It accepts write-once storage as a protection, and it is candid about the trade-off: it asks organizations to verify how robust the immutability mechanism is and it considers offline media more robust than online write-once storage. The compromise it describes is frequent online write-once copies combined with less frequent offline ones.
For a storage team, that translates into two questions. Is immutability enforced by the storage platform in a way that administrative credentials cannot undo, as discussed in the post on backup deletion protection? And has that been tested from the attacker's position, which is the subject of backup isolation testing? An online immutable copy that passes both tests covers the frequent recovery cases. The offline copy remains the last resort.
The guide asks for backups to be tested regularly against a written procedure, and it goes further than most by asking organizations to define the order in which systems are restored. Name resolution, time synchronization and the directory come before the applications that depend on them. It also warns that restored data may contain whatever the attacker planted, so restored systems should be rebuilt from trusted images and checked before they rejoin the network. The post on backup recovery dependencies maps those sequences, and ransomware recovery exercises describes how to rehearse them.
Where backups are held by an external provider, the guide recommends keeping the data within the European Union, watching for replication that the provider performs on its own initiative, and encrypting data with the organization's own means before it leaves. Keys stay with the organization. For the most sensitive public data, French state doctrine points to cloud services qualified under SecNumCloud, described in the post on SecNumCloud storage requirements. A backup target operated by the public body in its own facilities avoids the question of provider access altogether.
Scality RING is software-defined object and file storage that runs on standard x86 servers in the organization's own data centers. It exposes an S3 interface and supports versioning and S3 Object Lock, so backup software can write copies under a retention period that is protected until it elapses. RING is multi-tenant, with accounts, buckets and policy-based isolation, which supports the separation between backup operators and storage administrators that the guide asks for.
RING can span multiple sites, with erasure coding and replication selectable per policy, which provides the second online copy at a distance. Metrics and logs are kept locally and can be forwarded to the body's own monitoring. The offline copy the guide calls for remains a separate medium and a separate process.
The guide is advisory in form and influential in effect. A public body that can answer its 32 recommendations with configuration and test records, instead of intentions, is in a strong position with auditors and in a far stronger one on the day a restore is needed.