A DPO receives an ISO 27001 certificate, an "AES-256" tick on a security questionnaire, and a reassuring line about encrypted disks. Internal audit asks a simple question: if the host receives a legal request tomorrow, can they decrypt our data without us? Silence. The answer is not in the badge — it is in the key trust chain.
Encryption at rest protects data stored on disk, tape, or object storage against physical or unauthorized access to the medium. But as long as the provider holds the master key, they remain technically able to read your files. The real contractual question is therefore not "do you encrypt?" It is "who can decrypt, under what conditions, and with what audit trail?"
Three models — and what they actually change
In hosting and cloud markets, three dominant architectures appear.
Transparent provider-managed encryption. Disks or buckets are encrypted automatically. Easy to enable, often included. Major limit: keys live in the provider's infrastructure. During an incident, admin access, or a disclosure request, they may decrypt without your explicit approval.
Customer-managed keys (CMEK / BYOK). You import or generate a key in a management service (KMS, HSM). The host encrypts at rest but should not decrypt if you revoke the key. Useful for projects with heightened requirements — provided you document revocation and exit procedures.
Application-layer encryption upstream. You encrypt before upload (database, files, sensitive fields). The host sees noise. Higher operational cost, but maximum control if your team masters rotation and key loss scenarios.
| Model | Ease | Customer control | Watch point |
|---|---|---|---|
| Provider-managed | High | Low | Admin access and backups |
| BYOK / customer KMS | Medium | High | Revocation, key availability |
| Application encryption | Variable | Very high | Lost key = lost data |
Checking "encryption enabled" without a key model is like locking a door and leaving the key under the mat at the neighbor's.
What product pages leave out
Marketing talks algorithms (AES-256, TLS). Operations live elsewhere.
Administrator access. A tier-3 engineer with hypervisor or storage access may bypass "end-to-end encryption" messaging if keys are centralized on the host side. Ask who accesses keys, under what approval process, and whether those actions are logged.
Backups and snapshots. An encrypted VM may produce restorable backups without an extra layer, or copies in a region where keys are replicated differently. Trace the full path: production → snapshot → cold archive → cross-region replication.
Sub-processors. A European host may rely on underlying public cloud. Visible product encryption does not necessarily cover the whole chain. Read the sub-processor annex and DPA.
Questions to require before signing
Build a short evaluation grid, even for modest shared hosting.
- Who generates, stores, and rotates keys? Written documentation, not a product screenshot.
- What happens if we revoke the key? Unreadable data? Restorable? How long?
- Do backups use the same keys or separate ones? Where are they stored?
- Which internal roles can force decryption? Audit trail included?
- On exit, how are keys exported or destroyed?
For sensitive projects (health, finance, large-scale personal data), require a demo or audit note on these five points. A host unable to answer clearly is not "bad" — simply at the wrong risk level for you.
The climax: the padlock does not replace the key
Here is what product sheets dodge when they show a padlock icon.
That is the core issue: in compliance, you do not sell an algorithm. You sell a trust model. If you cannot explain that model to an auditor in ten minutes, the "encryption" checkbox on your questionnaire does not protect you.
Decide and move forward without blind spots
First map data at rest: databases, uploads, logs, backups, staging environments. Classify by sensitivity. For each layer, note the current or desired key model.
Then compare two or three hosts on the same scenario — not on the AES slogan. Use our compare tool and directory to filter providers with BYOK or clear documentation. The guide GDPR, HDS, SecNumCloud — who needs what? helps calibrate requirements by sector.
Finally, test revocation or restore on a non-critical environment. Modest proof beats a PDF policy.
Frequently asked questions
Is encryption at rest mandatory under GDPR?
GDPR requires appropriate measures for the risk, not a specific encryption checkbox. In practice, for sensitive data hosted by a third party, encryption at rest is often expected — provided you control who holds the keys.
What is the difference between provider-managed encryption and BYOK?
With provider-managed encryption, the provider holds or can access the keys. With BYOK or customer keys, you keep decryption control — the host cannot read data without your cooperation.
Is an encrypted disk enough for an audit?
Rarely on its own. Auditors also ask about key management, rotation, admin access, encrypted backups, and procedures when keys are revoked or you exit the provider.
Are backups covered by encryption at rest?
Not automatically. Production may be encrypted while snapshots, SQL dumps, or cold copies remain readable. Map production, replicas, and backups separately.
Next time a sales rep says "everything is encrypted," ask one thing: show me who holds the key.