"Everything is encrypted" is a starting point, not an answer. Ask what is encrypted at rest, in transit and in backups, who controls the keys, how they are rotated and who can use them. Then ask what encryption does not stop, such as an authorised employee reading data in the clear.
What encryption does and does not do
Encryption protects data from people who get the storage but not the keys: a stolen disk, a misconfigured storage bucket, a copied backup. It does not protect data from anyone who can use the keys through the running system, including an application bug, a compromised admin account or a support tool with broad access. So the useful questions are about keys and access, not just the word "encrypted".
The GDPR names encryption and pseudonymisation among the measures to consider for security of processing, alongside the ability to keep systems confidential, intact, available and resilient and to restore data after an incident, and a process for regular testing of these measures. It frames them as appropriate to the risk, not as a checkbox. This is general information, not legal advice.
The question list
| Topic | Ask |
|---|---|
| In transit | Which protocol versions are enforced? Are internal service calls also encrypted? |
| At rest | Which stores: database, object storage, search index, cache, logs? |
| Backups | Are they encrypted separately? Same keys or different? |
| Key custody | Who holds the keys: the vendor, a cloud key service or you? |
| Key use | Which services and people can use them? Are uses logged? |
| Rotation | How often, and what happens to old data? |
| Per tenant keys | Does each customer have its own key? |
| Customer controlled keys | Is that an option, and what changes if you revoke? |
| Key loss | What if a key is destroyed by accident? How is it backed up? |
Customer controlled keys: when they help
If you hold the key, you can cut the vendor's access to stored data by revoking it. That is a strong control for some buyers, and it comes with costs: more setup, possible performance effects, and a risk of locking yourself out. It also does not hide data from the running service, which must be able to decrypt in order to scan. Ask exactly what is protected from whom.
Per tenant keys are a middle option. They limit the blast radius of a key problem to one customer and make deletion easier. See crypto-shredding: when deleting the key deletes the data for the exit angle, and backup encryption keys: do not lose the key for the other side of the coin.
Gaps encryption leaves
- Data in use. Scanning requires reading data in memory in the clear.
- Metadata. Names, sizes and timings may stay visible.
- Logs and tickets. They can capture content that skipped the encrypted store.
- Exports. A file downloaded by a user is only as safe as that user's device.
- Weak access control. Encrypted storage behind a shared admin password is not strong.
Pair every encryption answer with an access answer, see can a vendor's support staff see your code and findings.
How Safeguard fits
When key custody has to stay entirely with you, running the platform on-prem or air-gapped puts storage and keys in your control. Safeguard supports those deployments, plus SaaS and private VPC. Try the free scan for a first look.
Quick check
Is TLS enough?
TLS protects data in transit only. Ask about storage, backups and key control too.
Do I need customer controlled keys?
Only if your risk or policy calls for it. Many buyers are well served by per tenant keys plus strong access controls.
Sources
Last reviewed: 19 October 2026.
