DORA and financial-sector obligations

The Digital Operational Resilience Act has applied to EU financial entities since 17 January 2025. It is the most consequential piece of regulation in this space, and it never mentions post-quantum cryptography. Understanding how it nonetheless creates an obligation you can fail is the difference between an evidence pack that survives a supervisory review and one that does not.

#What DORA is, in one paragraph

DORA is Regulation (EU) 2022/2554. Being a regulation rather than a directive, it applies directly across member states without national transposition, which is why the date is the same everywhere. It entered into force in January 2023 with a two-year runway and became applicable on 17 January 2025.

Its scope is broad: credit institutions, payment and electronic-money institutions, investment firms, insurance and reinsurance undertakings and their intermediaries, asset managers, market infrastructures including central counterparties and central securities depositories, trading venues, credit rating agencies, crowdfunding service providers, institutions for occupational retirement provision, crypto-asset service providers authorised under MiCA, and others. Critically, it also reaches the ICT third-party service providers those entities depend on, through contractual requirements and a direct oversight framework for providers the European Supervisory Authorities designate as critical.

• ICT risk management. A governed framework, owned by the management body, covering identification, protection, detection, response and recovery.
• Incident management and reporting. Classification of ICT-related incidents and staged reporting of major ones to competent authorities.
• Digital operational resilience testing. A programme of tests, with threat-led penetration testing for entities the authorities identify.
• ICT third-party risk management. Contractual requirements, a register of information, and concentration-risk analysis.
• Information sharing. Voluntary arrangements for exchanging cyber threat intelligence between entities.

#Where cryptography actually enters

There is no post-quantum article. The obligation is constructed out of three ordinary requirements that happen to bite hard on cryptography once you take them seriously.

The first is identification. Article 8 requires financial entities to identify, classify and document their ICT-supported business functions, the information assets and ICT assets supporting them, and their dependencies, and to maintain the relevant inventories and keep them updated. Cryptography is not called out, but an inventory of ICT assets that cannot say which algorithms and keys protect which function is not doing the work the article asks of it.

The second is protection. Article 9 requires policies and controls to protect the confidentiality, integrity and availability of data, and refers explicitly to the protection of cryptographic keys. The regulatory technical standards adopted under DORA go further, setting out requirements for a policy on encryption and cryptographic controls and for cryptographic key management, including keeping records for cryptographic assets and monitoring developments in cryptanalysis so that cryptographic technology can be updated when it weakens. That last element is crypto-agility in regulatory language, and it is the closest DORA comes to the subject of this section of the Knowledge Base.

The third is testing. Chapter IV requires a resilience testing programme, with appropriate tests applied to critical ICT systems at least yearly and threat-led penetration testing at least every three years for entities identified by their competent authority. A test programme that never examines whether a deprecated cipher is still negotiable is a test programme with a hole in it.

#The register of information and third-party oversight

Article 28 requires each financial entity to maintain and keep updated a register of information on all contractual arrangements with ICT third-party service providers, distinguishing those that support critical or important functions. The format is prescribed by implementing technical standards, and entities report the register to their competent authority on a defined cycle. This is the part of DORA that most often lands on a security team by surprise, because it is a data-collection exercise with a schema rather than a policy document.

• The register identifies each provider, the function it supports, whether that function is critical or important, and the sub-outsourcing chain behind it.
• Contracts for critical or important functions must carry specified provisions, including access, audit and inspection rights, exit strategies and service-level requirements.
• Providers designated as critical by the European Supervisory Authorities come under a direct oversight framework and can be examined without going through their customers.
• Concentration risk is an explicit concern: several entities depending on the same provider for the same function is a supervisory question in itself.

For cryptography, the register matters because the boundary of your cryptographic estate rarely matches the boundary of your infrastructure. If a content delivery network terminates TLS on your behalf, the negotiated cipher suite is a control you depend on and do not operate. An inventory that stops at your own perimeter will not tell you that. Ours records the boundary explicitly, and what we hold about it is described in What we hold, and what we never take.

#Mapping an inventory onto the duties

The table below is how we would expect a reviewer to test the connection. The third column is the one that matters, and it is the column most vendor mapping tables omit.

One point of substance about how these artefacts are received. Supervisors and internal auditors care less about the sophistication of the analysis than about whether the population is complete and the method is stated. A modest inventory with an honest scope note and a published method is stronger evidence than an impressive one that cannot say what it missed. The boundaries of ours are written down in What discovery will not do.

#The wider picture

DORA is not the only instrument in play, and it is worth being accurate about the others rather than listing regulators for effect.

• NIS2. Directive (EU) 2022/2555, with a transposition deadline of 17 October 2024, sets cybersecurity risk-management obligations across a wider set of sectors than DORA. Because it is a directive, the detail differs by member state. Financial entities in scope of both need to understand which regime takes precedence for a given obligation.
• The Commission Recommendation of 11 April 2024 on a coordinated implementation roadmap for the transition to post-quantum cryptography. This is a recommendation, not binding law, and it is the clearest statement of EU policy direction on the subject.
• Coordinated EU roadmap work. Member-state work under the NIS Cooperation Group has produced transition milestones for post-quantum adoption. [PLACEHOLDER: the milestone years, confirmed against the published roadmap text]
• Other jurisdictions. Several major financial regulators have operational resilience or technology risk regimes that reach cryptographic controls by a similar route. We do not publish a mapping for each, because a mapping we have not read the current text of is a liability. [PLACEHOLDER: jurisdictions we hold reviewed mappings for]