What DORA Articles 9-13 and the RTS on ICT risk management actually require for encryption, key management and crypto-agility, with a concrete technical checklist.
DORA (Regulation (EU) 2022/2554) has applied to EU financial entities since 17 January 2025, and its own text on encryption is short: a handful of words inside Article 9. Most of what auditors actually check against lives one layer down, in the Regulatory Technical Standard (RTS) that DORA's own Article 15 mandated: Commission Delegated Regulation (EU) 2024/1774, whose Articles 6 and 7 spell out exactly what a "policy on encryption and cryptographic controls" has to contain.
This guide works through DORA Articles 9 to 13 in order, what each one actually requires of your cryptography, and closes with a checklist you can hand to whoever owns your ICT risk management framework.
DORA's Chapter II, "ICT risk management," runs from Article 5 to Article 16. Articles 9 through 13 are the operational core: protection and prevention, detection, response and recovery, backup, and learning and evolving. None of these five articles is exclusively about cryptography; encryption is one control among many inside a broader ICT risk management framework that also covers governance, testing and third-party risk.
The article that actually names cryptography is Article 9(4)(d), which requires financial entities to implement "policies and protocols for strong authentication mechanisms... and protection measures of cryptographic keys whereby data is encrypted based on results of approved data classification and ICT risk assessment processes." That single clause is the hook Article 15 uses to mandate a dedicated RTS, and that RTS, not DORA's own text, is where the checklist below actually comes from.
Article 9 sets four obligations relevant to encryption, each with its own operational weight:
Continuous monitoring and minimisation of ICT risk (Article 9(1)): appropriate security tools and procedures, on an ongoing basis, not a point-in-time control.
Security policies covering resilience, continuity, availability and data protection (Article 9(2)): this is the paragraph the RTS's Article 6 hangs off. Your encryption policy is one of the "policies, procedures, protocols and tools" this paragraph requires you to develop, document and implement.
Prevention of data corruption, loss, unauthorised access and technical flaws, while maintaining confidentiality and integrity (Article 9(3)): the general confidentiality/integrity mandate that a properly scoped encryption policy is one of your main controls for.
Cryptographic key protection specifically (Article 9(4)(d)): strong authentication mechanisms and protection of cryptographic keys, explicitly tied to the outcome of your data classification and ICT risk assessment, not a blanket "encrypt everything" mandate.
Commission Delegated Regulation (EU) 2024/1774, the RTS on ICT risk management framework, operationalises Article 9(2) in its own Article 6, "Encryption and cryptographic controls," and Article 7, "Cryptographic key management." This is the level of detail an auditor actually checks against.
You must develop, document and implement a policy on encryption and cryptographic controls, built on your data classification and ICT risk assessment results, covering:
The policy needs documented criteria for selecting cryptographic techniques, aligned with leading practices and standards, and accounting for the classification of the ICT assets involved. Where an entity cannot meet those standards for a given asset, it must adopt and record mitigation and monitoring measures that keep resilience against cyber threats intact, and provide a reasoned explanation for the deviation.
This is also where the crypto-agility obligation actually sits: the policy must include provisions for updating cryptographic technology as cryptanalysis develops, not a one-time algorithm choice you file and forget.
Article 6 defers key management to Article 7, which sets five concrete requirements:
Detection is where cryptographic key compromise actually gets caught, if it gets caught at all. Article 10 requires mechanisms for prompt detection of anomalous activity, including potential single points of failure, tested regularly (10(1)); multiple layers of control with defined alert thresholds and automatic staff alerting (10(2)); and sufficient resourcing to monitor user activity and ICT anomalies, cyber-attacks specifically included (10(3)).
For cryptography specifically, this means your key management system needs to be a source of monitored events, not a black box: unusual key access patterns, unexpected key export attempts, or certificate/key operations outside a change window should feed the same detection layer as everything else in scope.
Article 11 requires a comprehensive ICT business continuity policy covering incident containment, damage assessment and stakeholder communication, with independent internal audit review of response and recovery arrangements for larger entities. Annual testing is mandatory, including cyber-attack scenarios and infrastructure switchover.
The cryptography-relevant question this article raises is narrow but important: if your primary key management infrastructure is unavailable during an incident, what is your documented recovery path, and has it actually been tested as part of the annual continuity exercise Article 11 requires, or does it just exist on paper?
Article 12 requires documented backup scope and minimum frequency based on data criticality and confidentiality (12(1)); tested backup systems whose activation does not jeopardise the confidentiality, integrity or availability of the data involved (12(2)); recovery systems physically and logically segregated from the source system and protected from unauthorised access (12(3)); redundant ICT capacity for non-microenterprises (12(4)); and, for central securities depositories specifically, geographically separated secondary sites with a distinct risk profile (12(5)).
DORA's own text does not spell out encryption requirements for backups the way the RTS does for live systems. In practice, the confidentiality obligation in 12(2) and the segregation requirement in 12(3) mean your backed-up key material needs the same protection standard as the live keys it backs up, addressed through the same Article 7 lifecycle controls (backing up and archiving are explicitly named lifecycle stages), not a separate, lighter-touch process because "it's just a backup."
Article 13 requires capability to gather and analyse information on vulnerabilities and incidents (13(1)); post-incident reviews after major disruptions, evaluating response promptness, forensic effectiveness and escalation quality, with findings shared with competent authorities on request for non-microenterprises (13(2)); continuous incorporation of testing and incident findings back into the ICT risk assessment (13(3)); ongoing monitoring of resilience strategy effectiveness (13(4)); annual reporting to the management body (13(5)); mandatory security awareness and training programmes (13(6)); and continuous monitoring of technological developments for non-microenterprises (13(7)).
For cryptography, 13(7) is the article that turns "review cryptographic technology as cryptanalysis develops" (the RTS Article 6 language) from a one-off policy statement into an ongoing obligation: you are expected to actually be tracking the state of the art, not waiting for a scheduled policy review cycle to notice an algorithm has been deprecated.
DuoKey's PQC Scanner generates a CycloneDX CBOM covering exactly the asset inventory Article 7's certificate register and Article 6's asset-classification-driven policy both assume you already have; see our CBOM generation guide for how to produce one, including the get_vulnerable_assets and get_qrs_score MCP tools for ongoing monitoring rather than a point-in-time snapshot.
Key lifecycle controls under Article 7 (generation, rotation, revocation) map to DuoKey's KMS and vault capabilities; MPC-based key management specifically addresses the "protection against unauthorised access" requirement by design, since no single party ever holds a complete key. For the crypto-agility obligation in Article 6 and Article 13(7), specifically, our F5 BIG-IP and FortiGate PQC guides cover the execution side: what it actually takes to change an algorithm on infrastructure you already run, once your policy review flags one that needs replacing.
Q: Does DORA mandate specific encryption algorithms?
No. Article 6 of the RTS requires selection criteria aligned with "leading practices and standards," not a fixed algorithm list. In practice this is interpreted against current NIST and ENISA guidance, which is exactly why the policy has to include a review-and-update provision rather than a static choice.
Q: Is DORA's encryption requirement the same as NIS2's?
No, and they come from different documents with different scopes. DORA applies to EU financial entities specifically, with its detailed cryptography requirements in a dedicated RTS (Delegated Regulation 2024/1774). NIS2's equivalent technical detail lives in a separate implementing regulation with its own, narrower entity scope; see our NIS2 crypto-agility guide for that comparison.
Q: Who does the RTS on ICT risk management actually apply to?
The same financial entities DORA itself covers: banks, insurers, investment firms, payment institutions, crypto-asset service providers and other DORA-scoped entities, proportionate to their size and risk profile per DORA's own proportionality principle.
Q: What counts as "data in use" encryption, and do we really need it?
Article 6(2) requires it "where necessary," with an explicit alternative: processing data in use in a separated and protected environment, or an equivalent compensating measure, is acceptable where full in-use encryption is not feasible. This is a risk-based judgement tied to your data classification, not a blanket mandate.
Q: We're a microenterprise. Does any of this not apply to us?
Some obligations are explicitly scaled by size: redundant ICT capacity (Article 12(4)) and continuous technology monitoring (Article 13(7)) are both framed as requirements for non-microenterprises, with a risk-based assessment standard for microenterprises instead. The core encryption and key management requirements in RTS Articles 6 and 7 are not similarly scaled; they apply based on data classification and ICT risk assessment outcomes, not headcount.
DORA's own Articles 9 to 13 read like general ICT risk management principles because that is what they are; the RTS on ICT risk management framework is where "policy on encryption and cryptographic controls" becomes a checklist you can actually be audited against. Build from the classification and risk assessment outward: know what you have, decide what standard each asset needs, document the gaps you cannot close yet, and treat the algorithm review as a standing obligation rather than a project that ends when the policy document is signed off.
Écrit par
Nagib Aouini
Related Resources
Dites-nous où le contrôle est difficile aujourd’hui. Nous vous aiderons à définir une prochaine étape concrète.
