Encryption at Rest for SMBs: CNIL and ANSSI Compliance, Plus a Checklist

Encryption at rest makes data stored on a disk, a backup or a database unreadable to anyone without the decryption key. It ensures that a stolen drive or a copied backup file yields nothing usable. Its major limitation: it protects nothing once a system is running and a legitimate — or hijacked — account reaches the decrypted data.

In short:

• Encryption at rest only protects against physical media theft or backup copies, not against access on a running system or through a compromised account.
• There are four encryption layers: full disk, file system, database, and application-level, each addressing specific threats.
• Effective key management calls for a suitable model such as HSM or BYOK, backed by strict processes for generation, rotation and revocation.
• Encryption alone does not guarantee regulatory compliance, which also requires sound key management practices and a risk assessment.
• Data classification, planned restore testing and separation of duties significantly improve operational security.

Table of contents

• What is encryption at rest, and how does it differ from the other data states?
• The four technical layers of encryption at rest, from disk to application
• Key management: KMS, HSM, BYOK and HYOK models, and operational best practices
• What encryption at rest does not protect
• Compliance and recommendations: GDPR, CNIL and ANSSI
• Implementing encryption at rest: practical decisions and trade-offs
• A quick operational checklist for small businesses, SMBs and technical users
• The Yundera perspective: does a managed private server simplify key management?
• Yundera, an alternative to public clouds for anyone who wants to keep control of their keys and data
• Sources

What is encryption at rest, and how does it differ from the other data states?

Data “at rest” is data stored on physical or virtual media: a hard drive, an SSD, a virtual machine snapshot, a backup file, an idle database. Encryption at rest turns that content into an unreadable block without the matching key, protecting stored data from being read directly.

Three distinct states govern the life of a piece of data, and confusing the first two explains most poorly calibrated security projects:

• At rest: the data sits on storage media (disk, backup, archive) and is not being handled by any active process.
• In transit: the data travels between two points — a workstation and a server, for example — typically protected by TLS.
• In use: the data is loaded into memory by an application that processes, computes or displays it, often in the clear at that precise moment.

A concrete example makes the distinction clear. A laptop stolen on a train, with an encrypted disk, gives nothing away to whoever takes it apart: the files remain an opaque block. The same laptop powered on with a session open, however, offers direct access to those files in the clear, because the operating system has already decrypted the disk in order to run. Encryption at rest did its job in the first case and has no purchase at all in the second.

It is precisely this constant shifting between states that leads the CNIL to recommend an approach tailored to each data state rather than a single protection meant to cover everything. An encrypted disk, an encrypted backup and a TLS connection address three different threats, and none of the three replaces the other two.

The four technical layers of encryption at rest, from disk to application

Encryption at rest does not happen at a single level. It breaks down into four stacked layers, each protecting against a different threat scenario and each carrying a higher operational cost than the last.

The full-disk layer encrypts the entire physical volume: BitLocker on Windows, LUKS on Linux, FileVault on macOS. It protects against hardware theft and lost drives, but becomes transparent as soon as the system boots. An attacker who gains remote access to a running machine bypasses this protection entirely.

The file system layer encrypts specific directories or logical volumes rather than the whole disk, which makes it possible to use different keys per user or per service on the same machine. This is the level multi-user systems rely on to isolate each account's data.

The database layer, often called TDE (transparent data encryption), encrypts the database files without SQL queries having to care about it. It covers database file theft well, but an account with legitimate read permissions sees the data in the clear, query after query.

The application layer, or field-level encryption, encrypts a specific piece of data — a card number, a medical field — before it ever reaches the database. It is the only layer that remains effective even against a malicious database administrator or a full backup leak, at the cost of heavier integration into application code.

Choosing the algorithm follows a simple but frequently ignored rule: AES in XTS mode suits block encryption (disks, volumes), while AES in GCM mode — a form of authenticated encryption — is the right fit for application-level and object encryption. Using XTS to encrypt an application field, or GCM for an entire volume, creates performance constraints or integrity weaknesses that few teams anticipate before running into them in production.

Key management: KMS, HSM, BYOK and HYOK models, and operational best practices

Encryption, however robust, is only worth as much as the management of its key. A strong algorithm protecting a key stored in a text file next to the encrypted data offers no real protection at all.

A KMS (key management service) orchestrates the creation, distribution and rotation of encryption keys across an infrastructure. An HSM (hardware security module) is the physical or logical component that generates and protects the root key, the one every other key depends on. ANSSI recommends that a root of trust ideally rest on a certified HSM rather than on a simple password-protected file.

Four models shape the market today, with very different implications for sovereignty and cost:

1. Provider-managed: the cloud provider generates and holds the keys. Easy to switch on, but the provider technically retains the ability to decrypt your data.
2. CMK (customer-managed key): you keep control of the keys through a vault such as Azure Key Vault, while encryption runs on the provider's side.
3. BYOK (bring your own key): you generate the key outside the provider, then import it into their environment for day-to-day use.
4. HYOK / XKS (hold your own key): the key never leaves your infrastructure, and the provider has to call it for every encryption or decryption operation.

These four models answer a simple question that the CNIL rightly raises: who, technically, can request a decryption, and where does that request travel? Client-side encryption keeps the answer entirely out of the cloud provider's reach, unlike provider-managed models.

A key's life cycle has six critical moments: generation, storage, distribution, rotation, revocation, destruction. Each one needs a written procedure that is tested and rehearsed periodically, not merely documented on a wiki gathering dust.

Pro tip: Never test key rotation solely in production. A failed rotation can render large volumes of data permanently unreadable; validate the full procedure — rotation and restore — on a test dataset before every real deployment.

Separating duties remains the most neglected practice: the person who administers the servers should not be the one holding access rights to the KMS. A centralized, logged service makes it possible to know exactly who requested which decryption operation, and when.

What encryption at rest does not protect

The very phrase “data at rest” is misleading: in most production environments, data never really sleeps — it is constantly read, written and copied by active processes. Encryption at rest is therefore only one building block among others in a defence-in-depth strategy.

Here are the scenarios where this protection simply does not come into play:

• A compromised account with legitimate permissions sees the data exactly as its owner does, encryption or not.
• SQL injection or an application flaw extracts data the application has already decrypted to answer a normal query.
• Ransomware running on a server encrypts, in turn, data already decrypted on the fly, making the underlying protection layer useless.
• Human error or insider risk (unauthorized export, copy to a USB stick) bypasses the protection as soon as the person has normal access.

Against ransomware in particular, the real line of defence is not disk encryption but the existence of immutable backups, isolated from the network and tested by restoring them. An encrypted disk gives back no data at all if the file has been destroyed or corrupted by an attacker who is already connected.

This is exactly where application-level encryption regains its meaning: encrypting a sensitive field before it reaches the database limits what an SQL injection or a compromised account can actually extract, even if the protection adds complexity to the code.

Compliance and recommendations: GDPR, CNIL and ANSSI

Article 32 of the GDPR explicitly cites encryption as an example of an appropriate technical measure for protecting personal data, without ever imposing it as an absolute, uniform obligation. The text asks for a measure proportionate to the risk, which means encrypting a database of sensitive customer records does not call for the same effort as a simple file of public business contacts.

The CNIL and ANSSI round out this legal framework with concrete operational recommendations:

• The CNIL distinguishes four levels of encryption applicable in a cloud environment and recommends matching the chosen level to the real sensitivity of the data, not to a generic standard.
• ANSSI sets out the cryptographic primitives to favour (AES, AEAD modes, minimum key sizes) and insists on a hardware rather than software root of trust.
• NIS2 and DORA, which apply to essential entities and the financial sector respectively, tighten the requirements for traceability and resilience of encryption measures.
• PCI-DSS mandates strict encryption at rest for any stored payment card data, with regular audit controls.
• ISO 27001 includes encryption in its information security control framework, without turning it into a checkbox isolated from the rest of the management system.

These texts converge on a point that is often forgotten: encryption alone is never enough to demonstrate compliance. An organization must also prove that it manages its keys properly and that it assessed the real risk before choosing its level of protection — an exercise detailed in our guide to GDPR compliance in the cloud.

Implementing encryption at rest: practical decisions and trade-offs

Diving into encryption at rest without a method almost always leads to one of two pitfalls: encrypting too much, at the expense of performance, or encrypting too little and letting the genuinely sensitive data slip through.

1. Map and classify your data first. Encrypting indiscriminately costs performance and needlessly complicates key management for data that does not warrant the effort.
2. Choose between client-side and provider-side encryption based on actual use. Consumer-facing use often benefits from the convenience of provider-side encryption; regulated or strategic data justifies the full control that client-side encryption offers.
3. Match the algorithm to the target layer. XTS for a volume or a disk, GCM for an application field or a stored object: reversing the two creates security blind spots.
4. Plan operational tests from the design stage, not after deployment: key rotation, a full restore from an encrypted backup, and a simulated key-loss incident.

Data classification deserves a moment's attention. Public data on a marketing site does not call for the same treatment as an HR file or a health database. Justifying the encrypted perimeter through this classification, rather than through a generic security reflex, also makes it easier to justify the costs to a finance department.

Pro tip: For each data category, document the encryption layer you chose and the reason behind that choice. This traceability, often neglected, becomes valuable during a GDPR audit or an ISO 27001 certification, when you have to justify why a given piece of data is protected one way and not another.

The most common failure does not come from a bad algorithm but from a recovery procedure never tested under real conditions. A key rotation that fails silently can render entire volumes of data permanently inaccessible — a risk at least as serious as a leak.

A quick operational checklist for small businesses, SMBs and technical users

Before launching a full encryption project, a few hours of checks are enough to spot the most common gaps.

• Workstations: is the disk on every work computer encrypted (BitLocker, FileVault, LUKS), and is that configuration verified at inventory time, not just at initial setup?
• Backups: are backup files encrypted with a key distinct from the one used for production data, and stored on media isolated from the main network? To learn more, see our practical guide on backup dati nel gestionale ristorante.
• Access and permissions: who, precisely, can request a decryption operation, and has that list been reviewed within the last six months?
• KMS or key vault: are keys centralized in a dedicated, logged service rather than scattered across configuration files?
• A question to ask any cloud provider: do they offer a customer-managed key (CMK) model, or do they stick to provider-managed encryption by default?
• Restore test: has a full restore from an encrypted backup been successfully rehearsed within the last twelve months?

One figure worth remembering: according to ANSSI, the strength of encryption depends less on key length than on the rigour of the controls over who can request its use — something many SMBs only discover after an incident.

This checklist is no substitute for a full audit, but in a few hours it reveals the most frequent blind spots. Our GDPR cloud compliance checklist goes deeper into the regulatory side for teams that need to document these controls.

The Yundera perspective: does a managed private server simplify key management?

The complexity of encryption at rest rarely comes from the algorithm, but from scattered responsibilities: who holds the key, who handles rotation, who can export the data in the event of a dispute with the provider. A private server hosted in France, with guaranteed data export at any time, removes part of that structural uncertainty, since the data holder remains identifiable and the exit path always stays open.

That does not exempt you from the best practices described above: data classification, restore testing and separation of duties remain necessary whatever infrastructure you choose. A managed server simplifies day-to-day operations; it does not replace operational discipline. For an organization handling very specific data volumes or heavy sector-specific regulatory constraints, a bespoke application architecture is sometimes still the better choice.

— Yundera

Yundera, an alternative to public clouds for anyone who wants to keep control of their keys and data

Some alternatives to the public cloud let you know exactly where your data lives and get it back without negotiation. Unlike a provider-managed setup where encryption stays under the provider's control, Yundera hosts your private server in France, guarantees you can export your data at any time, and never collects or resells anything.

The solution can include open source applications for a range of uses, accessible through a custom domain with no technical skills required. For a business or a freelancer who has read this guide and understood how important it is to control the encrypted perimeter and access to the keys, some ethical infrastructures let that control stay in your hands. Small businesses and SMBs looking to reduce their dependence on a third-party provider while simplifying day-to-day management will find concrete use cases on our page dedicated to small businesses. Explore the Yundera private server offering and decide, based on your own data classification, whether sovereign hosting fits your needs.

Sources

• What is data at rest?
• Encryption practices in public cloud computing
• ANSSI — Guide to cryptographic mechanisms
• Data encryption: essential protection for small businesses and SMBs
• Azure data encryption at rest

Recommendations

• GDPR compliance in the cloud: a checklist for French companies
• End-to-end encryption: the complete 2026 guide
• Secure remote access: a guide for CIOs and IT managers
• Data hosting in France: a guide for CIOs and decision-makers