Encryption and key management: what to encrypt, by what criteria, and who holds the keys
Encrypting data is like locking it in a safe. But a safe with the key taped to the door protects nothing. What matters, and what almost nobody has documented, is what gets encrypted, by what criteria, and who holds the keys.
Encryption in transit and at rest
- In transit: when data travels (web, email, APIs, connections between systems). Always use encrypted connections with current TLS versions.
- At rest: when data is stored (databases, disks, backups, cloud storage). Turn it on in services that offer it and check that it covers backups too.
Encryption protects against loss or theft of the medium or improper access to the infrastructure, but not against someone with legitimate permissions. That is why it goes together with access control.
What to encrypt: decide by classification
There is no need to encrypt everything with the same rigour. Start from your data classification:
- Public: no specific encryption-at-rest requirement.
- Internal: encryption in transit and, preferably, at rest.
- Confidential and restricted (personal, financial data, trade secrets): encryption in transit and at rest, and encrypted copies.
Key management: where it is won or lost
- Keep keys apart from the data. Store them in a key management service or a dedicated module, not next to the database.
- Limit who can access them. Few people, with a log of every use, and no shared accounts.
- Rotate keys on a defined schedule and whenever compromise is suspected.
- Keep safe copies of keys. Losing a key can mean losing the data for good.
- Define the lifecycle: generation, use, rotation, retirement and destruction.
Encryption, pseudonymisation and anonymization are not the same
Encrypted data is still personal data under the GDPR if it can be decrypted. Pseudonymisation lowers the risk, but does not take data out of the GDPR either. Only true anonymization does. For more, read anonymization vs pseudonymisation.
With AI: points to watch
- Data you send to AI providers: check it travels encrypted and what the provider does with it.
- Training sets and embedding stores: keep them encrypted, like the source data.
- API keys and credentials used by agents: never leave them in code or documents.
What the rules say
The GDPR (Art. 32) mentions encryption and pseudonymisation as examples of appropriate technical measures. NIS2 (Art. 21) includes among the minimum measures policies and procedures on the use of cryptography and, where appropriate, encryption. No rule sets a specific algorithm: they ask for measures proportionate to the risk and the state of the art.
Frequently asked questions
Which encryption standard should I use?
Widely used, current ones, such as AES-256 for data at rest and TLS 1.2 or 1.3 in transit. Review the policy every year, because what is adequate today may stop being so.
Do I need a key management service if I am a small company?
Most cloud providers include one. Using it is safer and cheaper than improvising with key files.
How often should keys be rotated?
There is no single period; between 90 days and a year is common depending on sensitivity. What matters is setting it and sticking to it.
Informational content, not legal advice. AI regulation changes quickly: always check the current official text before deciding. Information reviewed as of October 15, 2026.
This gives you the method. If you want the finished document: Encryption & Key Management Policy.
What's your Data Governance maturity?
Free assessment with your priority gaps, plus the self-assessment quiz and savings calculator on the Data Governance path.