DORA encryption requirements: what financial firms must control

The EU Digital Operational Resilience Act (DORA) does not ask financial entities to “encrypt more.” It asks them to prove they can keep critical ICT services running and that third-party cloud and SaaS providers cannot silently become the single point of failure for the business.

For CISOs, CTOs and compliance leads, the practical question is narrower: who can unlock the data that keeps the franchise running and can you show that answer under stress?

What DORA is really testing

DORA (Regulation (EU) 2022/2554) ties operational resilience to ICT risk management, incident reporting, resilience testing and oversight of critical ICT third-party providers. Encryption sits inside that story as a control on confidentiality, integrity, and, when keys are customer-held, concentration risk.

Boards and supervisors will not score you on algorithm fashion. They will ask:

• Can a cloud order, breach, or vendor outage unlock customer or market data without your say-so?
• Can you rotate, revoke and recover keys on a calendar the business can keep?
• Can you produce a coherent evidence trail of who approved key access and when?

Encryption obligations that matter in practice

DORA’s ICT risk framework expects proportionate cryptographic protection for data at rest and in transit, aligned with the sensitivity of the service. In regulated cloud deployments that usually means:

1. Clear ownership of keys, not only “encrypted by the provider,” but named accountability for who can decrypt.
2. Separation from the operator, especially for critical or important functions hosted in hyperscale SaaS or IaaS.
3. Lifecycle discipline, generation, rotation, revocation and destruction that survive staff change and vendor change.
4. Auditability, approvals and access events that legal, audit and supervisors can read without reverse-engineering tickets.

Where DORA’s third-party risk chapter bites hardest is concentration: if the same provider stores the data and holds the last encryption key, resilience language on the contract does not change the technical fact that one party can unlock production.

Customer-held keys as a resilience control

Customer-managed and dual-control key architectures (BYOK, HYOK, external key stores, double-key encryption) are how many firms shrink that concentration. The business outcome is simple:

• The cloud or SaaS platform can run the workload.
• It cannot complete decryption alone.
• Revoking or refusing a key share stops access without rewriting the application overnight.

DuoKey’s approach keeps key authority outside the operator using multi-party computation so no single vault, cloud account, or administrator holds a complete key, which maps cleanly to DORA’s insistence on reducing single points of failure in ICT supply chains.

Evidence supervisors expect to see

When resilience testing or an ICT incident review asks for proof, thin policy PDFs fail. Useful artefacts include:

• A map of critical functions and where their encryption keys live
• Named owners for key domains (not a shared break-glass account)
• Rotation and revocation events tied to change windows
• Third-party arrangements that document who can compel or deny decryption

If those artefacts only exist inside the cloud provider’s console, you have outsourced the evidence as well as the infrastructure.

A bounded next step

1. Inventory critical and important functions that depend on cloud encryption.
2. Mark where the provider alone can unlock the data.
3. Prioritise customer-held key control for those domains before the next supervisory or audit cycle.
4. Align key lifecycle evidence with your DORA ICT risk and third-party registers.

DORA will not be satisfied by a logo on a compliance slide. It will be satisfied by controls that keep the business able to operate and able to prove who held the last word on the keys.

Further reading

• NIS2 encryption requirements
• Financial data in the cloud
• Who controls the keys?