DORA encryption and cryptographic key management requirements

What the encryption policy must cover in practice

Article 6 of Delegated Regulation (EU) 2024/1774 builds the encryption policy from the approved data classification and the ICT risk assessment. The components below follow that chain, from what data is protected to how its keys are run, and each one needs its own evidence.

How to handle data in use and cases where leading practice cannot be met

How the key lifecycle under Article 7 is evidenced

The sequence below follows a cryptographic key from generation to destruction, naming the record an assessor expects at each phase. Each step produces documents or system logs that together show the entity controls its keys across the full lifecycle, not only at the moment of deployment.

1. Approve the key management procedure

   The entity's security function writes a key management procedure that sets out who may generate, hold, rotate, replace and destroy each class of key, and which keys are tied to data classified under the encryption policy. The procedure is approved by the accountable owner and linked to the encryption policy. The output is a version-controlled, signed procedure that an assessor can compare against what the systems actually do.

2. Generate keys in a controlled system

   Keys are generated inside an approved key management system or hardware-backed module, not on ad hoc workstations or in configuration files. The record of each generation event should capture the key identifier, purpose, owner, algorithm and creation time. The evidence is the generation log plus an inventory entry, and the entity should confirm that its chosen platform records these events in a form it can export.

3. Store and protect keys against misuse

   Keys are held in protected storage with access limited to named service identities and administrators, and the design keeps key material out of application code and logs. Where an application only needs encryption or decryption, the design can keep the key inside the key system so that the application never sees the raw key. Evidence includes the access control list for key objects, the role assignments and records showing that the protection controls were tested. OpenBao's transit secrets engine (MPL-2.0) is one open-source option for this pattern, because it encrypts and decrypts application data without storing that data and supports signing and verification. The entity must confirm that these capabilities match its architecture, its hardware or cloud key requirements and its performance needs before adopting it.

4. Monitor and log key access

   Every use of a key, along with every change to key policy, is logged and the logs are protected from alteration and reviewed. This step converts the access control design into proof that unauthorised access and modification would be visible. The output is an audit log extract for a sample period, alert rules for unexpected key use, and a record of who reviewed them. Retention periods should follow the entity's own logging rules, which the logging requirements page covers in more detail.

5. Rotate keys on a documented schedule

   Keys are rotated according to the schedule in the procedure, with rotation triggered earlier when a risk assessment or a change in cryptanalysis calls for it. Versioned keys allow older ciphertext to remain decryptable while new data uses the current version. The evidence is the rotation record for each key (old version, new version, date, approver) and proof that dependent systems picked up the new version. Assessors will look for rotation that actually happened, so the schedule should match the logs.

6. Replace lost, compromised or damaged keys

   The procedure sets out how a key is replaced when it is lost, suspected of compromise or damaged, including who decides, how data protected by the old key is re-encrypted or re-protected, and how the old key is revoked. The incident or change record for each replacement is the primary evidence, showing the trigger, the decision, the steps taken and the verification that services work with the new key. Where the entity keeps a record of exceptions or alternative measures under the encryption rules, that record should be cross-referenced here.

7. Destroy keys and record the destruction

   When a key is retired, the entity confirms that no system, backup or archive still depends on it for data it must keep, then removes the key material according to the procedure. The destruction is recorded with the key identifier, date, approver and method, and the record is kept with the key inventory. Backups that still contain material encrypted under a retired key need a documented decision about how long they are kept and when they are destroyed.

8. Keep the key and certificate register current

   The register of keys and certificates is updated at each phase above, and it records certificates and the devices that store them, at least for ICT assets supporting critical or important functions. Renewal dates are tracked so certificates are renewed before expiry. The assessor typically samples register entries and checks them against live systems, so the reconciliation between the register and the running environment is itself a piece of evidence that the entity should produce on request.

What the certificate register and renewal process must show

Article 7(4) and (5) of Delegated Regulation (EU) 2024/1774 turn certificates into a managed inventory with named owners and renewal before expiry. The cards below cover what the register must contain, how to surface upcoming expiries, and how an assessor tests that the process works in practice.

Who owns the controls, who prepares the evidence and who assesses it

What drives the cost of encryption and key work under DORA

This table breaks encryption and key management spending into its separate components, showing who is paid, whether each cost is one-time or recurring, and what moves it up or down. Use it to structure requests for written quotes so each component can be compared on its own. The main takeaway is that tooling is often the smaller part of the cost, while internal ownership of keys and evidence drives most of the ongoing effort.

How to prepare encryption and key controls before an assessment

This sequence turns Article 6 and Article 7 of the ICT risk management RTS into a set of approved documents, inventories and records that an assessor can trace from data classification through to key and certificate evidence. Each phase produces an output that the next phase depends on.

1. Confirm the approved data classification

   Start by checking that the organization has a current, approved data classification scheme, since Article 6 ties the encryption policy to it. The information security or data governance owner, with business data owners, confirms the classes, the criteria for each, and who approved them. Done means a signed classification standard exists, every class has a defined protection expectation, and the ICT risk assessment refers to the same classes. If the classes differ between documents, fix that before anything else, because every later step inherits the mismatch.

2. Inventory data stores and data flows

   Build a list of where classified data is stored, processed and transmitted, covering databases, file stores, backups, message queues, SaaS services, internal network links and external connections. The ICT asset owners and architects produce this, usually from the asset inventory and network documentation. Done means each store and flow is tagged with its classification, its state (at rest, in transit or in use), and the system that holds the keys. Gaps found here often reveal copies of data that were never in scope for encryption.

3. Write the encryption policy

   Draft the encryption policy so it sets the required protection for each data class at rest, in transit and in use, covers internal network connections and external traffic, and states the expectations for cryptographic key management. The information security function drafts it and the management body approves it under the entity's governance arrangements. Done means the policy is approved, version controlled, and cross-referenced to the classification standard and the ICT risk assessment, with a named owner for review.

4. Document the data in use position

   For each class where encryption in use is not practical, record the separated and protected environment or the equivalent measures that replace it. Architects and system owners describe the isolation, access restriction and monitoring used. Done means every case where data in use is not encrypted has a written description that an assessor can test against Article 6(2), and each description is linked to the systems in the data flow inventory.

5. Implement and document key lifecycle procedures

   Write procedures covering key generation, distribution, storage, use, rotation, backup, revocation, replacement and destruction, which together cover the full lifecycle that Article 7 describes. Platform and security engineers implement them, and in a self-hosted setup a secrets and key management service can enforce much of this. OpenBao's transit secrets engine, for example, supports versioned keys and key rotation, but the procedures and the configuration choices still need to be confirmed by the organization. Done means each lifecycle stage has a procedure, access to key material is restricted and logged, and a documented method exists for replacing keys that are lost, compromised or damaged.

6. Build the certificate register

   Create a register of certificates and the devices that store them, starting with ICT assets supporting critical or important functions as Article 7 requires. Platform teams populate it from certificate authority records, load balancers, endpoints and application configurations, and record owner, expiry date and renewal method. Done means the register is complete for in-scope assets, each entry has a renewal owner, and there is a documented process that renews certificates before they expire. A discovery scan run against the network can validate the list, but the organization should confirm its coverage.

7. Record exceptions with reasons

   Where a leading practice or standard cannot be met, record the mitigation and monitoring measures in a formal exception log, as Article 6(3) to (5) describe. The control owner writes the reasoned explanation, the compensating measure, the monitoring applied, and the review trigger, including the update plan for cryptographic technology as cryptanalysis develops. Done means every exception has an approved entry, an owner and a review date, and the register is linked from the encryption policy so an assessor can follow it.

8. Collect evidence and run an internal check

   Gather the artefacts an assessor will ask for: the approved policy and classification, the data flow inventory, key lifecycle procedures, key and certificate logs, the certificate register, and the exception log. Then run an internal check that samples a few systems and tests whether the documents match the running configuration. Done means each control has a mapped evidence set, the internal check findings are logged and tracked to closure, and the remaining gaps are known. Independent assessors, not the implementation partner or the organization's internal reviewers, decide whether the controls meet the requirement.

Questions buyers ask about DORA encryption and key requirements

How to choose an implementation partner or independent assessor

Preparing encryption and key management evidence for DORA involves two different parties: the firm that builds or configures the controls and the independent assessor that tests them. Keep these roles separate, and check each candidate on the points below before signing anything.