control

encryption and key management

Encryption protects data only as long as the keys are safe and recoverable. NIS2 asks for a policy on cryptography and encryption, DORA names key protection, GDPR names encryption of personal data.

last checked 2 November 2026
what it protects
data on lost devices, in stolen backups and in transit, for as long as the keys are safe and recoverable
who owns it
head of IT, with the data protection lead
start with
a short policy and a list of keys and certificates with owners

what it is

Encryption turns data into something unreadable without a key. It protects data on a lost laptop, in a stolen backup and on the way between systems. It also moves the risk from the data to the key: whoever holds the key reads the data, and whoever loses it may lose the data for good.

NIS2 asks for policies and procedures on the use of cryptography and, where appropriate, encryption. DORA asks financial entities to protect cryptographic keys and to link encryption to data classification and risk assessment. GDPR lists encryption of personal data as an appropriate measure.

Start with a short policy and a list: what is encrypted, with which methods and who owns each key. Then deal with the weak points. Keys belong apart from the data, they need a recovery route, and certificates need an expiry date and an owner.

basis NIS2 Art. 21(2)(h); DORA Art. 9(4)(d); GDPR Art. 32(1)(a). The key handling steps are practice.

the life of an encryption key

  1. 1createwith an approved method and a named owner
  2. 2store apartaway from the data it protects
  3. 3use and recordevery use and change is logged
  4. 4rotatereplaced on a schedule without stopping the service
  5. 5retiredestroyed once nothing needs it, recovery copy included

certificates run the same loop, with an expiry date and a warning before it

basis working practice. No legal text sets this.

an example

Picture a company of a few hundred people that turned on disk encryption and encrypted backups.

weak

The backup key sits on the same server as the backup. One person alone knows where the recovery copy is, certificates expire when nobody is looking, and nobody can say which systems are encrypted. When that person leaves or the server fails, the data is gone.

solid

A one-page policy says what is encrypted and with which methods. Every key and certificate has an owner and an expiry date. The recovery copy needs two people, and the company has rotated a key once without stopping the service.

An illustration. It is not a real case.

what it has to do for each rule

rulewherewhat the text askswhat the control has to do
NIS2NIS2 Art. 21(2)(h)Policies and procedures regarding the use of cryptography and, where appropriate, encryption.Write down where you encrypt data in storage and in transit, which methods you accept and who owns the keys. Record where you do not encrypt and why.
DORADORA Art. 9(4)(d)Protection measures of cryptographic keys, whereby data is encrypted based on the results of approved data classification and ICT risk assessment.Link the encryption choice to your data classes and keep a documented way to generate, store, rotate and retire keys.
GDPRGDPR Art. 32(1)(a)As appropriate, the pseudonymisation and encryption of personal data.Encrypt personal data where the risk calls for it and be able to show where that is.

basis NIS2 Art. 21(2)(h); DORA Art. 9(4)(d); GDPR Art. 32(1)(a). What the control has to do is practice.

what to look for when you choose

  • Does it keep keys apart from the data they protect, in a store only a few people and systems can reach?
  • Can you list every key, who owns it, where it is used and when it was last changed?
  • Can you rotate a key without taking a service down, and have you done it once?
  • What happens to the data if a key is lost? Is there a recovery copy, held where the administrator of the data cannot read it alone?
  • Does it record every use and every change of a key?
  • How does it handle certificates, and does it warn you before one expires?
  • If a supplier holds the keys for a cloud service, can you hold your own, and what does that change for you?
  • Which methods does it support, and can you retire a weak one without rebuilding?

basis working practice. No legal text sets this.

three levels, from first step to strong

Each level adds something visible. Stop where the risk you accepted allows.

  1. start

    Write a short cryptography policy, list the keys and certificates in use and give each one a named owner.

  2. solid

    Keep keys apart from the data, add a recovery copy that needs two people and warn on expiry dates well before they arrive.

  3. strong

    Rotate keys on a schedule without downtime, test key recovery once a year and review who can reach the key store.

basis working practice. No legal text sets this.

where it goes wrong

the key sits next to the data

A key stored on the same server or in the same backup as the data it protects gives little protection. Keep them apart.

the key nobody can recover

A lost key can mean lost data, backups included. Keep a recovery copy under a rule that needs two people.

expired certificates

A certificate that runs out takes a service with it, often at the worst moment. Keep an inventory with expiry dates and an owner for each.

encryption nobody wrote down

Disk encryption may be on in one place and off in another. Without a short policy and a list, you cannot answer the question where your data is encrypted.

basis working practice. No legal text sets this.

the proof it leaves

what you can showwho owns itrefresh
cryptography policy: where data is encrypted, accepted methods, key ownershead of ITyearly
key and certificate inventory with owners and expiry dateshead of ITquarterly
record of key rotations and of key recovery testshead of ITyearly
list of systems and data classes that hold personal data, with the encryption status of eachhead of IT, with the data protection leadyearly

basis practice. The rhythms are your choice.

09

check it yourself

your next step

List the keys and certificates in use today and mark the ones with no named owner.