All 41 substantive articles of Commission Delegated Regulation (EU) 2024/1774 set against ISO/IEC 27001:2022, ISO 22301:2019 and PCI DSS v4.0.1. The full framework under DORA Article 15 and the simplified framework under Article 16, side by side, with the correspondence between them shown article by article.
Open the mapping What the simplified regime dropsCommission Delegated Regulation (EU) 2024/1774 is the regulatory technical standard that turns DORA's ICT risk management obligations into concrete articles. It has two operative halves, and no financial entity is subject to both.
Title II, Articles 2 to 27, is the full ICT risk management framework, adopted under DORA Article 15. Title III, Articles 28 to 41, is the simplified framework for the entities listed in DORA Article 16(1). Article 1 applies to both and makes everything proportionate to your size, risk profile and complexity.
The interesting part is the relationship between the two. Title III is not a separate regime invented from scratch — it is a compression of Title II. 7 of its articles each absorb several full-framework articles, and 3 Title II articles have no Title III counterpart at all. Those are set out below, because that is the difference people actually want to know.
Which regime you fall under is not something you can read off a public register, and this page does not tell you. It depends on your authorisation type, your size and your interconnectedness, and it is a determination to make deliberately rather than assume. What this page does is show you what each regime actually requires once you know.
This is the opposite of our NIS2 mapping page, and the difference matters. There, ENISA had published an official correlation between the NIS2 implementing regulation and nine frameworks, and our job was to reproduce it faithfully. For DORA, we have found no equivalent. Not from the European Supervisory Authorities — neither the final report on this RTS (JC 2023 86) nor the consultation paper before it (JC 2023 39) contains a standards concordance — not from ENISA, whose only mapping product is scoped to NIS2, not from any national competent authority we checked, and not from ISO, NIST or the PCI Security Standards Council. If one is published, we will say so and reconcile this page against it.
The article structure, numbering and titles on this page come directly from the published text of Commission Delegated Regulation (EU) 2024/1774 on EUR-Lex, parsed article by article rather than transcribed by hand. Everything in the three framework columns is NexGenio's own analysis. It carries no regulatory authority whatsoever. It carries our reasoning, which you can check against the standards and disagree with specifically.
One claim worth retiring while we are here: it is often repeated that this RTS was drafted in alignment with ISO 27001. ISO 27001 is not cited in the regulation, in the consultation paper or in the final report. The resemblance is structural — risk assessment, treatment, controls, review — and structural resemblance is a reason a mapping is possible, not evidence that one is official.
Read it as a navigation aid between documents, not as a compliance claim, and certainly not as a statement that holding any of these certificates satisfies DORA. It does not, and the gaps section says exactly where.
You will read that the RTS was "aligned with ISO 27001" or "based on international standards". The recitals to the RTS do refer to international standards in general terms. That is not the same as a published concordance, and we have not found one from the European Supervisory Authorities, from ENISA, from any national competent authority, or from ISO.
So where the columns below line up neatly, that is our reading of two texts that were written independently. Where they do not line up, we say so rather than force a reference into the cell.
All three columns are ours. None is a reproduction of anyone else's work.
PCI DSS is not legislation. It is a contractual scheme administered by the payment card brands and enforced through acquirers. Its own applicability text is explicit that it covers entities that "store, process, or transmit cardholder data and/or sensitive authentication data, or could impact the security of" that data.
That is a completely different scoping trigger from DORA's. A card issuer, an acquiring bank, a payment institution or a processor in a card flow will be in scope of both. An investment firm, an IORP or a fund manager that never touches card data has no PCI DSS obligation at all, and for those entities the PCI column is context rather than a requirement. We have mapped it because the overlap is real for part of the sector, not because it applies across the sector.
The current version is v4.0.1, published June 2024. Version 3.2.1 was retired on 31 March 2024, and the future-dated requirements introduced in v4.0 became mandatory on 31 March 2025 — two separate dates that are frequently conflated. The standard is available from the PCI Security Standards Council document library.
Grouped by the Titles and Chapters of the regulation. Start by choosing your regime — the two are alternatives, so showing one at a time is usually what you want. Each article carries its correspondence to the other regime, and each has its own anchor link so you can cite a single article.
Proportionality. Everything in both Titles is read against your size, risk profile and the complexity of what you do — this is the article that makes the rest scalable.
The umbrella article. Your ICT security policies must sit inside the ICT risk management framework, be approved, be reviewed, and assign owners.
Documented ICT risk management policies and procedures, including an approved risk tolerance and the method by which ICT risk is identified and treated.
A policy for managing ICT assets, covering criticality, ownership and the treatment of assets supporting critical or important functions.
The operating procedure behind that policy, including how you assess asset criticality and maintain records of ICT assets and their dependencies.
A policy on encryption and cryptographic controls, including where encryption is applied at rest, in transit and in use.
Key management across the full lifecycle — generation, renewal, storage, backup, archiving, retrieval, destruction and compromise handling.
Documented ICT operations procedures, covering how systems are run day to day, and how operational changes are controlled.
Capacity and performance management, so that resources are monitored and provisioned before shortfalls affect service.
Vulnerability management and patching, including scanning frequency, prioritisation, and tracking third-party components.
Data and system security measures — access restrictions, secure configuration, and protection of data at rest.
Logging procedures, protocols and tools: what is logged, how long it is retained, how it is protected, and clock synchronisation.
Network security management, including segmentation, filtering and the design of network architecture.
Protecting information in transit, including the confidentiality, integrity and authenticity of data moving across networks.
An ICT project management policy covering how projects are governed and how security is built in from the start.
A policy governing acquisition, development and maintenance of ICT systems, including secure development and separation of environments.
ICT change management — how changes are requested, tested, approved, documented and rolled back.
A physical and environmental security policy protecting premises, data centres and equipment against physical and environmental threats.
ICT security elements of the human resources policy: responsibilities, awareness, conditions of employment and termination.
Identity management — unique identification and authentication of every person and system accessing your ICT assets.
Access control on need-to-know, need-to-use and least privilege, including privileged accounts, review and revocation.
An ICT-related incident management policy: how incidents are recorded, classified, escalated, communicated and closed.
Detection of anomalous activity, with defined roles, triggers and criteria for declaring and responding to an ICT-related incident.
What the ICT business continuity policy must contain, including objectives, scope, and the link to your business impact analysis.
Testing of ICT business continuity plans against the business impact analysis and the ICT risk assessment, with results acted on.
ICT response and recovery plans built on the results of the business impact analysis, with recovery objectives and communication.
The format and content of the report on the review of the ICT risk management framework, submitted in a searchable electronic format.
Internal governance and control framework for entities on the simplified regime — clear responsibilities and management body involvement.
An information security policy setting high-level principles for confidentiality, integrity, availability and authenticity.
Identify, classify and document critical or important functions, the information assets supporting them, and their ICT assets.
The simplified ICT risk management framework itself: risk tolerance, identification, assessment, treatment and monitoring.
Physical security measures based on the threat landscape and the classification carried out under Article 30.
Procedures for logical and physical access control, enforced, monitored and periodically reviewed.
ICT operations security — asset lifecycle, supported versions, capacity, backups, vulnerability and patch handling in one article.
Data, system and network security in one article: network safeguards, encryption, and protection of data at rest and in transit.
An ICT security testing plan validating that the measures under Articles 33 to 35 actually work.
A risk-based procedure for acquiring, developing and maintaining ICT systems, including testing before deployment.
ICT project and change management combined — roles, documentation, approval and testing of changes.
What the ICT business continuity plan must contain, built on analysis of exposure to severe business disruption including a cyber-attack scenario.
Annual testing of business continuity plans, including the scenarios identified under Article 39.
Format and content of the report on the review of the simplified ICT risk management framework.
This is the question every entity that might fall under DORA Article 16 asks first, and the answer is derivable from the regulation's own structure rather than from anyone's opinion. Title III is a compression of Title II. Some articles are merged, some disappear.
7 of the fourteen Title III articles each cover ground that Title II spreads across multiple articles. The obligation is not removed — it is stated once, at a higher level, with less prescription about how you meet it.
Article 35 is the clearest example. In the full framework, encryption, key management, data and system security, logging, network security management and securing information in transit are six separate articles with their own detailed paragraphs. In the simplified framework they are one article. That is a genuine reduction in prescription, and it is also where entities most often under-build, because a single article invites a single thin control set where six articles did not.
3 articles in Title II have no corresponding article in Title III. Read these carefully — in most cases the underlying duty still exists somewhere in DORA itself, and only the RTS-level elaboration falls away.
This is the single most important caveat on this page, and it is where simplified-framework programmes go wrong. The RTS elaborates DORA. It does not replace it. Where Title III is silent, the parent regulation still speaks.
Incident handling is the clearest case. There is no incident management policy article in Title III, but DORA Articles 17 to 23 — the classification of ICT-related incidents and the initial, intermediate and final reporting obligations — apply to financial entities regardless of which framework they are on. An entity that reads the silence in Title III as an exemption from incident reporting has misread the instrument badly.
The same holds for the management body. Title III has no human resources article, but DORA Article 5(2) still places ultimate responsibility for ICT risk on the management body, and Article 13(6) still requires ICT security awareness and training.
Every honest mapping needs this section. There are DORA duties that no certificate closes, because they are not control objectives — they are obligations owed to a supervisor, and to your counterparties.
None of that is a criticism of the standards. They were written to manage risk, not to satisfy a European supervisory regime. The practical shape of a DORA programme is the management system as the engine, with the regulatory duties bolted on as a defined, separately evidenced layer.
We publish no coverage percentage for DORA, for the same reason we publish none for NIS2. There is no reproducible method behind the figures that circulate, no regulator has endorsed one, and a number invites exactly the false comfort this page is trying to prevent. A list of what is missing is less satisfying and considerably more useful.
Reproducing a regulation and adding analysis to it means separating the two clearly.
Found something wrong, or disagree with a row? Tell us and we will correct it and say so here. A mapping nobody argues with is usually a mapping nobody has checked.
Article structure and titles sourced from Commission Delegated Regulation (EU) 2024/1774 as published in the Official Journal. Framework references are NexGenio analysis. PCI DSS facts verified against PCI DSS v4.0.1 (June 2024). This page is reviewed when any source is revised. Last reviewed 17 September 2026.
A short call establishes which framework you fall under, what your existing certifications already cover, and which of the duties outside them you still need to build. From there you get something you can take to your board.
Book a scoping call