For a financial entity, an ISO 27001 ISMS covers a good part of DORA's ICT risk management framework in Articles 5 to 16 and the delegated regulation that details it: the policies, asset management, access control, change, logging, vulnerability management, backup and continuity are the same controls. DORA then adds what no ISMS contains: the management body's ultimate and personal responsibility and training, a framework that is documented and reviewed as a whole at least yearly, major ICT incident classification and reporting on a fixed clock, digital operational resilience testing including threat-led penetration testing for larger entities, and third-party risk duties with a register of information and prescribed contract terms. For an ICT provider, the certificate is useful evidence in a customer's DORA due diligence and no substitute for the contract terms Article 30 requires.
DORA, Regulation (EU) 2022/2554, has applied to financial entities since 17 January 2025 and reaches their ICT providers through contracts and, for the critical ones, direct oversight. Many of those entities and providers hold ISO 27001 certificates and want to know what the certificate buys them. This article maps the ISMS onto DORA's five pillars and lists what has to be added.
DORA's pillars against the ISMS
| DORA | What ISO 27001 already gives | What DORA adds |
|---|---|---|
| Art. 5–16 ICT risk management framework and Delegated Regulation (EU) 2024/1774 | Policies, risk assessment, asset inventory, access control, change management, logging, vulnerability and patch management, backup, continuity, supplier controls | Management body ultimate responsibility and training (Art. 5); a documented framework reviewed at least yearly and audited (Art. 6); identification of all ICT-supported business functions and dependencies (Art. 8); specific RTS content on encryption, network security, logging and change |
| Art. 17–23 ICT-related incident management and reporting | Incident process, event reporting, lessons learned (A.5.24 to A.5.28, A.6.8) | Classification of major incidents against the criteria in Delegated Regulation (EU) 2024/1772; initial notification within four hours of classification, intermediate report within 72 hours, final report within a month, in the format of Delegated Regulation (EU) 2025/301 |
| Art. 24–27 digital operational resilience testing | Security testing in development (A.8.29), independent review (A.5.35), vulnerability management (A.8.8) | A testing programme with annual tests of critical systems by independent parties, and threat-led penetration testing at least every three years for entities the authorities designate |
| Art. 28–30 ICT third-party risk | Supplier risk assessment, agreements, monitoring, cloud rules (A.5.19 to A.5.23) | A strategy on ICT third-party risk, pre-contract due diligence, concentration risk, the register of information in the format of Implementing Regulation (EU) 2024/2956, and the mandatory contract provisions of Art. 30 |
| Art. 31–44 oversight of critical ICT third-party providers | Nothing directly | Direct oversight by the lead overseer for providers designated critical, with powers to inspect and recommend |
| Art. 45 information sharing | Contact with special interest groups (A.5.6), threat intelligence (A.5.7) | Arrangements for sharing cyber threat information among financial entities, notified to authorities |
The DORA framework page covers each pillar and the reporting clock in detail.
Making the ISMS the ICT risk management framework
Delegated Regulation (EU) 2024/1774 lists the elements an ICT risk management framework must contain and says the policies should take into account leading practices and standards. It names none, so an ISMS can be the framework if three conditions are met. It is documented as the framework, with the DORA elements traceable to the ISMS documents rather than assumed. The management body approves it and reviews it at least once a year, which is more than clause 9.3 requires if the management review is not yearly. And it covers ICT risk in DORA's sense, which includes the identification of all ICT-supported business functions, their dependencies and the ICT assets behind them, usually a wider inventory than the ISMS scope. The gaps that remain after that are the ones in the table: classification and reporting, testing, and third-party duties.
For ICT providers: what the certificate does in a DORA review
A financial entity doing Article 28 due diligence on a provider reads the ISO 27001 certificate for scope, the Statement of Applicability for the controls it depends on, and the surveillance status for currency. The certificate answers most of the security questions. It does not answer the Article 30 contract: the right to audit, the service levels, the incident support, the exit and termination terms, data location and the subcontracting rules all have to be in the agreement. Providers that prepare a DORA addendum and a mapping from their SoA to the Article 30 points shorten every financial customer's review. The SOC 2 and DORA article covers the same review from the other common report, and the TPRM solution how the register of information is built from the vendor register.
A sequence that works
- Map the ISMS documents to the Delegated Regulation (EU) 2024/1774 elements and document the result as the ICT risk management framework, approved by the management body.
- Extend the inventory to ICT-supported business functions and their dependencies, and reassess risk against them.
- Add the incident classification procedure and the reporting templates, and test them.
- Define the testing programme, and find out whether you are in scope for threat-led testing.
- Build the register of information from the supplier inventory and review contracts against Article 30.
- Put the management body's training and annual review on the calendar.