DORA vs ISO 27001: does an ISMS already get you toward DORA?
If your firm already holds an ISO/IEC 27001 certificate and falls within DORA's scope, your ISMS is a strong foundation, but it is not a DORA attestation. ISO does not certify organizations; accredited certification bodies do, and they audit against ISO/IEC 27001:2022 and ISO/IEC 27006-1:2024. DORA, by contrast, is directly applicable EU law with no certification scheme. Your national competent authority supervises compliance using its powers under Article 50, and the only authority-issued attestation the Regulation provides is the one confirming that a threat-led penetration test met the requirements (Article 26(7)). An ISO certificate cannot stand in for that supervisory relationship. For most firms, the practical answer is to do both, with the ISMS as the base: it already supplies governance, risk assessment, asset inventories, access control and operational security processes that DORA's ICT risk management chapter builds on.
The certificate alone is a weaker fit when DORA requires something an ISMS does not define in the same form. Confirm these gaps early. The register of information on all ICT service contracts, kept in the templates of Implementing Regulation (EU) 2024/2956 and reported annually through your competent authority (Article 28(3)), is a specific deliverable that most ISMS scopes do not produce. The same applies if your competent authority has identified you for threat-led penetration testing, which must run at least every three years under Article 26(1), with the authority able to require more or less frequent testing. Fixed frequencies in the technical standards also go beyond typical ISMS cycles. Delegated Regulation (EU) 2024/1774 sets weekly automated vulnerability scanning for assets supporting critical or important functions, and six-monthly firewall rule and access rights reviews for those systems. Ask your certification body and your supervisor which of these you must evidence, and map each one to an existing control before you plan new work.
Treat the ISMS audit cycle as the evidence engine and add the DORA-specific layer on top. Use the ISO/IEC 27001 Annex A controls as a starting point, then add the items your ISMS does not yet cover, such as incident classification and major-incident reporting, the register of information, provider contract terms and testing records. Check the official mappings carefully: ENISA states that its mapping is not a measure of equivalence and does not assess whether a standard fully covers the regulation's requirements. Ask your supervisor what evidence it expects for each DORA chapter, and whether your existing ISO surveillance audits can reuse the same records. Document which scope boundaries differ between the ISMS and DORA, since DORA applies to ICT systems supporting your regulated activities and to your ICT third-party providers, which may fall outside your certified scope.
How DORA and ISO 27001 differ on scope, structure and proof
This table compares who each framework applies to, whether it is binding, how its requirements are structured, what proof it produces and what it costs to run. Read it as a map of where an existing ISMS already helps and where DORA adds obligations that a certificate does not cover.
| Dimension | ISO/IEC 27001:2022 | DORA (Regulation (EU) 2022/2554) |
|---|---|---|
| Who it applies to | Any organization that chooses to adopt an ISMS, scoped by the organization | 20 types of financial entity in Article 2(1), plus ICT third-party service providers in point (u) |
| Legal status | Voluntary international standard; becomes binding only if a contract or regulator requires it | Binding EU regulation, directly applicable in member states since 17 January 2025 |
| Structure | Annex A lists 93 controls in four themes: organizational, people, physical and technological | 64 articles in nine chapters, supported by delegated and implementing technical standards |
| Proof produced | Third-party certificate issued by an accredited certification body after audit | No certificate. Competent authorities supervise compliance and can require evidence at any time |
| Only authority-issued attestation | Not applicable. Certification is issued by a certification body, not ISO | Attestation that a threat-led penetration test met the requirements (Article 26(7)) |
| Fixed review frequencies | Certificate cycle of three years with at least one audit each calendar year (per ISO/IEC 17021-1 practice) | Yearly reviews under Article 6(5) and Article 8, weekly vulnerability scanning for critical or important functions under Delegated Regulation 2024/1774 |
| Testing requirements | Internal audit and management review are required; technical testing depth is set by the organization | TLPT at least every three years for identified entities (Article 26(1)), plus testing of continuity plans and systems supporting critical functions |
| Third-party reporting | Supplier controls under Annex A; no regulator-defined register | Register of information on all ICT service contracts, kept in 15 templates under Implementing Regulation 2024/2956 |
| Cost of ownership | Certification audit fees and recurring surveillance audits are paid to the certification body; the ISMS itself is internal effort | No certification fee. Costs come from supervisory readiness, TLPT procurement, register maintenance and incident reporting capability |
What the DORA baseline adds beyond an ISMS
An ISMS built to ISO/IEC 27001:2022 sets a management system that you run and improve, but DORA adds binding, prescriptive rules on top of the Regulation itself. A complete DORA baseline combines Regulation (EU) 2022/2554 with its technical standards: Delegated Regulations (EU) 2024/1774 (ICT risk management), 2024/1772 (incident classification), 2025/301 (incident reports), 2024/1773 (ICT services policy), 2025/532 (subcontracting) and 2025/1190 (threat-led penetration testing), and Implementing Regulations (EU) 2025/302 (incident templates) and 2024/2956 (register of information). Your ISMS policies will not satisfy these texts on their own. Start by mapping each of these eight instruments to an owner and to the evidence your supervisor will ask for.
Several DORA obligations are fixed in time, not left to your risk appetite. Article 6(5) requires the ICT risk management framework to be reviewed at least yearly, and Articles 8(1), 8(2), 8(7), 11(6), 13(5) and 24(6) set yearly reviews, risk assessments, continuity tests and reporting to the management body. Delegated Regulation 2024/1774 goes further for systems supporting critical or important functions: weekly automated vulnerability scanning (Article 10), firewall rule checks at least every six months (Article 13) and access rights reviews at least every six months (Article 21). Check whether your ISMS scanning and access review cycles are calendar-based or event-based, and whether they reach the specific assets in scope for critical or important functions.
If your entity is identified by its competent authority, Article 26(1) requires threat-led penetration testing at least every three years, and the authority may set a shorter or longer interval. Under Article 26(7), the only authority-issued attestation DORA provides for is confirmation that a TLPT met the requirements, and that confirmation is not a certificate you can obtain from an ISMS audit. Ask your competent authority whether you are identified and what testing cadence it expects, then confirm with the TLPT framework in 2025/1190 how the test scope and the external testers are determined. Each of these items should be planned as a funded work package, not as an extension of the annual surveillance audit.
Where an ISO 27001 ISMS already covers DORA work
Each card pairs an ISMS area with the DORA requirement it helps with and the condition that decides whether the ISMS evidence holds. Official mappings are a starting point only: ENISA states its mapping is not a measure of equivalence, and NIST does not check the correctness of non-NIST mappings. Use them to find overlap, then test each item against the frequencies and scope DORA sets.
Asset inventory and classification
An ISMS asset register is the starting point for DORA's classification work. DORA expects the classification of ICT functions and assets to be reviewed at least yearly (Article 8(1)), and Delegated Regulation (EU) 2024/1774 adds weekly automated vulnerability scanning for assets supporting critical or important functions. The ISMS evidence is sufficient only if the register records which assets support those functions, who owns each one and which third party runs it. A register built only for the certification scope often lacks those tags, so check it before reusing it.
Risk assessment and scenarios
The ISMS risk assessment supports DORA's risk management chapter, but DORA asks for more specific outputs. Article 8(2) requires risk scenarios to be reviewed at least yearly, and Article 8(7) requires a yearly risk assessment of legacy ICT systems. The ISMS method is sufficient when its scenarios cover ICT disruption, third-party failure and legacy platforms and the review cycle runs at least annually for those systems. Confirm that risk treatment records link to named scenarios and are not only generic threat lists.
Access rights reviews
ISO/IEC 27001 Annex A includes controls on access rights, and most certified ISMS run periodic access reviews. DORA's technical standard sets a floor for systems that support critical or important functions: Article 21 of Delegated Regulation (EU) 2024/1774 requires access rights review at least every six months. An annual ISMS review cycle would not meet that floor for those systems. Check the review frequency for those systems and keep evidence that privileged accounts are included.
Vulnerability scanning and TLPT
ISMS vulnerability management usually sets scan frequency by risk, which may be less often than DORA requires for critical assets. DORA's technical standard is specific: weekly automated vulnerability scanning for assets supporting critical or important functions (Article 10 of 2024/1774). Threat-led penetration testing sits outside the ISMS. Identified entities must run TLPT at least every three years under Article 26(1), and the TLPT attestation is an authority-issued confirmation under Article 26(7), so no ISO certificate can stand in for it.
Continuity and recovery testing
An ISMS typically includes business continuity controls, and DORA's ICT continuity requirements build on the same planning. DORA requires testing of continuity and recovery plans at least yearly (Article 11(6)) and testing of systems supporting critical or important functions at least yearly (Article 24(6)). The ISMS is sufficient when its exercises include recovery tests on the systems behind critical or important functions, record the results and feed corrective actions to the management body. A plan supported only by discussion exercises does not give the reader this evidence.
Major incident classification and reporting
ISO/IEC 27001 requires an incident management process, which is a sound base for detection, triage and lessons learned. It does not by itself set the classification criteria, templates or report timings DORA requires. Those come from Delegated Regulation (EU) 2024/1772 on classification, Delegated Regulation (EU) 2025/301 on incident reports and Implementing Regulation (EU) 2025/302 on templates. Map classification thresholds, templates and report timings to your procedure, and confirm them with your competent authority before relying on the ISMS procedure.
What to add on top of an ISMS for DORA
An ISMS covers much of the control design DORA expects, but four obligations sit outside it and need their own owners and evidence: the register of information, incident classification and major incident reporting, threat-led penetration testing, and provider contract terms. Article 28(3) requires a register covering all ICT service contracts, kept in the 15 templates of Implementing Regulation (EU) 2024/2956 and reported each year through the competent authority to the ESAs. ISO/IEC 27001 has no equivalent inventory of contracts in that form, so most banks and insurers will need to build the register from procurement records, then confirm with their supervisor which entity-level and contract-level fields apply to them.
Incident handling needs its own classification criteria under Delegated Regulation (EU) 2024/1772 and reporting timelines under Delegated Regulation (EU) 2025/301, using the templates in Implementing Regulation (EU) 2025/302. A major incident is reported in three stages, so the incident process must produce the right facts at each stage, not only a closure record. Threat-led penetration testing under Article 26 applies only if the competent authority has identified the entity, and it repeats at least every three years under Delegated Regulation (EU) 2025/1190. When the test meets the requirements, the Article 26(7) attestation is the only authority-issued attestation DORA provides for, so ask early how your authority expects the test to be scoped and reported.
Article 30 sets the contract terms for ICT third-party providers, and an ISMS supplier clause rarely meets them on its own. Article 6(10) allows you to outsource the verification of ICT risk management compliance to intra-group or external undertakings, but the entity remains fully responsible for that verification. Use a written check of who performs each verification, what evidence they return, and who signs off the result. Confirm the Article 30 terms and subcontracting expectations against Delegated Regulation (EU) 2025/532 with your legal and third-party risk teams before renewing key contracts.
Who assesses each framework and what it issues
This table compares who checks compliance with ISO/IEC 27001 and DORA, and what each process produces. Read it to see which evidence your existing certificate carries into a DORA supervisory review and which items still need a regulator-facing answer.
| Dimension | ISO/IEC 27001 | DORA |
|---|---|---|
| Who assesses | Accredited certification bodies, working to ISO/IEC 17021-1:2015 and ISO/IEC 27006-1:2024. ISO itself does not certify organizations. | National competent authority for each type of financial entity (Article 46). The ECB supervises significant credit institutions. ESAs act as Lead Overseers for critical ICT third-party providers. |
| What it issues | A certificate for the scope stated in the certification body's report, backed by audit findings. | No certificate. Supervisors use their Article 50 powers, such as inspections and information requests. |
| Only attestation issued | Not applicable. The certificate itself is the output. | The Article 26(7) attestation that a threat-led penetration test met the requirements. |
| Assessment cycle | Three-year certification cycle with at least one audit in every calendar year (ISO/IEC 17021-1, as explained by European Accreditation). | Set by the authority. Yearly activities in the technical standards apply, and TLPT applies at least every three years for identified entities. |
| Who can be assessed | Any organization that sets a scope, subject to accredited certification body rules. | Only the financial entities listed in Article 2(1), plus designated critical ICT third-party providers. |
| What to confirm | Your certification body's accreditation and the scope on the certificate, checked in the IAF CertSearch database. | With your competent authority: which supervisor applies, whether you are identified for TLPT, and how it expects evidence to be submitted. |
Doing both: order of work and shared evidence
This sequence shows how an existing ISO/IEC 27001 certificate can form the base of a DORA program, which gaps need separate work, and where one evidence set can serve both frameworks without being presented as proof of DORA compliance.
Confirm scope and identified-entity status
Start by establishing which legal entities and ICT services fall under DORA, using the list of financial entity types in Article 2(1). Check with your competent authority whether you are identified as a TLPT entity, because that status drives the testing obligation later. Compliance and legal teams own this step, and the output is a written scope statement that names each entity, each ICT service and the supervisor responsible. Your ISMS scope statement will rarely match this exactly, so record the differences now so they do not surface during a supervisory request.
Map the ISMS to DORA chapters
Build a crosswalk from your Annex A controls and ISMS processes to the DORA chapters on ICT risk management, incident management, resilience testing and ICT third-party risk. Treat the crosswalk as your own working document, since ENISA states that its mapping is not a measure of equivalence and does not assess whether a standard fully covers the regulation. The owner is the ISMS lead with a DORA-experienced risk or compliance lead. The output is a gap list that marks each DORA requirement as covered, partly covered or absent in the ISMS.
Close the DORA-specific control gaps
Work through the gap list and add the requirements that a typical ISMS does not set at the frequencies DORA uses. Delegated Regulation (EU) 2024/1774 sets weekly automated vulnerability scanning for assets supporting critical or important functions, firewall rule checks at least every 6 months for those systems, and access rights reviews at least every 6 months for them. Confirm each cadence against the regulation text, then update procedures and tooling. The output is revised procedures plus evidence from the first run of each new cycle, kept in a form an auditor or supervisor can trace.
Stand up the register of information and incident process
Build the register of information required by Article 28(3), kept in the templates of Implementing Regulation (EU) 2024/2956, and cover all ICT service contracts, not only the cloud contracts your procurement team tracks. Extend the incident process to the classification criteria in Delegated Regulation (EU) 2024/1772 and the report content in Delegated Regulation (EU) 2025/301, with templates from Implementing Regulation (EU) 2025/302. ISO 27001 incident management controls give you the workflow, but the register and reporting clocks are DORA-specific. The output is a tested register and a tabletop-verified incident path with named reporting roles.
Align third-party contracts and subcontracting
Review ICT third-party arrangements against the contract requirements in Articles 28 to 30 and the subcontracting rules in Delegated Regulation (EU) 2025/532. ISO supplier controls usually cover security clauses but may not cover DORA's exit and subcontracting provisions. If you use Article 6(10) to outsource verification to an intra-group or external undertaking, document that the entity remains fully responsible for that verification. The output is an updated contract inventory showing which clauses are in place for each provider and which renewals need negotiation.
Plan TLPT and the ISO cycle together
If you are identified for TLPT, schedule the first test within the at-least-every-three-years rule of Article 26(1) and coordinate its scope with your ISMS internal audit and vulnerability management calendar. Note that ISO/IEC 17021-1 requires at least one surveillance or recertification audit in every calendar year of the three-year cycle, so the certification audit cadence is fixed by the certification body, not by DORA. Use the Article 26(7) attestation only as the regulator-issued proof that a test met requirements. The output is one joint calendar showing TLPT dates, the certification body's audit windows and the annual DORA reviews listed in Article 6(5) and Article 8.
Separate shared evidence from DORA-only evidence
Assemble one evidence repository tagged by control, and mark each item as shared or DORA-only. Risk assessments, access reviews, backup test records, vulnerability reports and supplier reviews can often serve both an ISO audit and a DORA supervisory request, provided they show the DORA frequency and scope. DORA-only evidence includes the register of information, the incident classification and reports, TLPT reports and the Article 26(7) attestation, and the management body's oversight records. Ask your certification body and your supervisor which formats they accept, since neither will certify DORA compliance. The output is an evidence index with an owner and retention note for each item.
Review the program after each cycle
Close the loop by reviewing the framework itself, since Article 6(5) requires at least yearly review, and by updating the crosswalk when ISO transition rules or the DORA technical standards change. Check whether the Commission's review due by 17 January 2028 under Article 58(1) or the proposed Digital Omnibus changes any obligation you rely on, and confirm the current text before updating. The output is a dated review record approved by the management body, plus a revised gap list that feeds the next planning cycle.
Questions buyers ask before hiring outside help
Does an ISO 27001 certificate satisfy DORA?
No. An ISO/IEC 27001 certificate shows that an accredited certification body found your information security management system conforms to the standard at the time of audit, but DORA sets no certification scheme and no equivalent attestation. DORA is directly applicable EU law that competent authorities supervise, and it adds requirements an ISMS does not cover on its own, including the fixed review and testing frequencies in the technical standards, the register of information under Article 28(3), incident classification and reporting, and threat-led penetration testing for entities identified by their authority. An ISMS is a strong starting point, but the gap work is what turns it into DORA evidence.
What drives the cost and effort of DORA gap work on top of an ISMS?
The main drivers are how much of your ISMS already maps to the DORA chapters, how many ICT services and third-party contracts you run, the number of systems supporting critical or important functions, and how far your current testing and review cadences match the yearly and six-monthly frequencies in the delegated regulations. Costs split into internal staff time, external advisory fees and any tooling or testing you buy. Most of the cost is one-time for the gap assessment and remediation, while register maintenance, scanning, access reviews and annual reporting recur. Ask any provider to price each of these components separately in a written scope.
How long does a DORA gap assessment take?
No duration is supplied for this work, so do not plan against a number from a vendor until the scope is written. The timeline depends on the number of entities in your group, how many ICT services and contracts need mapping, the state of your existing evidence and how quickly your risk, IT and legal teams can review drafts. Ask the provider for a written scope that lists the deliverables, the assumptions behind each phase, the staff you need to provide and the milestones at which you will review findings before work proceeds.
Can our team run the DORA gap work internally?
Often yes for a first pass, if you have people who know both the ISMS and the DORA text well enough to map one against the other. The harder parts are the register of information, which requires structured data on every ICT service contract, and the testing obligations, which need independent planning and evidence. Internal teams also tend to struggle with objectivity when they assess their own controls. A practical approach is to run the mapping internally and buy an independent gap assessment or review of the highest-risk areas, then decide later whether to bring remediation in-house.
What does the work need from risk, IT and compliance staff?
Risk staff must confirm the classification of functions and assets and the risk scenarios, which Article 8 requires to be reviewed at least yearly. IT staff must produce the inventory of systems that support critical or important functions, the vulnerability scanning and firewall rule and access rights evidence that the delegated regulations set at higher frequencies, and the continuity and recovery test records. Compliance staff own the register of information, the mapping between the ISMS controls and the DORA articles, and the evidence file that the competent authority may request. Name an owner for each deliverable before the engagement starts.
How do the register of information and TLPT change the effort?
The register of information under Article 28(3) covers all ICT service contracts and is kept in the 15 templates of Implementing Regulation (EU) 2024/2956, so it adds a data collection exercise that an ISMS does not produce by default. Many firms find that supplier records are spread across procurement, IT and business teams, which makes this the longest data task. Threat-led penetration testing applies only to entities identified by their competent authority and must run at least every three years, with the authority able to ask for more or less frequent testing. Its effort depends on scoping, the testers you use and the remediation that follows, so ask for those items in writing.
What should a fixed-scope quote from a provider include?
Ask for a written scope that names the DORA articles and technical standards in scope, the ISMS documents and systems reviewed, the entities and ICT services covered, and the evidence the provider will prepare. The quote should list deliverables, acceptance criteria, your staff commitments, the assumptions about existing evidence, the exclusions and the change process if scope grows. Also ask who issues any attestation, since DeployOpen prepares systems, controls and evidence for assessments but does not issue audit reports or certifications, and independent auditors and certification bodies do. Confirm how ongoing support and retesting are priced separately.
Official sources to read next
Start with the primary text. The DORA Regulation itself is the only binding source for the obligations discussed on this page, and it is available in full on Regulation (EU) 2022/2554 on EUR-Lex. Read Chapter II (ICT risk management, Articles 5 to 16) against your existing ISMS scope, then read Article 26 on threat-led penetration testing and Articles 28 to 30 on ICT third-party risk, because those are the chapters an ISO 27001 certificate does not reach by itself. Check the dated obligations in the Regulation against the Delegated Regulations listed in the topic facts, since the frequencies you will be audited on sit in those standards rather than in the Regulation's own text. Confirm with your competent authority which of those standards it applies in its supervisory guidance.
Next, read the ISO side from the source. The *ISO/IEC 27001:2022* requirements and Annex A are published on the ISO/IEC 27001:2022 standard page, and you should purchase and read the text rather than rely on summaries. Map your Annex A controls to DORA articles yourself and record where the mapping stops, for example at the register of information under Article 28(3) or the weekly vulnerability scanning in the 2024/1774 technical standard. The standard's own wording on certification scope is also relevant: ISO does not certify organizations, so confirm that your certificate's scope covers the ICT services and sites your DORA scope names.
Finally, read the certification rules if your ISMS certificate is going to be the evidence you hand to supervisors. The IAF transition documents, IAF MD 26:2023 for the 2022 revision and IAF MD 29:2024 for the ISO/IEC 27006-1:2024 audit rules, tell you what your certification body must now apply and when. Ask your certification body in writing which edition and transition status applies to your certificate, and whether the audit scope will be reviewed against your DORA register. Certification shows an ISMS was audited, not that DORA is met, so keep that distinction in every board and supervisor document.
How DeployOpen prepares DORA and ISO 27001 readiness
DeployOpen is a Chainscore Labs company that plans, implements, hardens, documents and supports self-hosted open-source platforms inside the client's own infrastructure. We prepare the systems, controls and evidence that DORA and an ISO/IEC 27001 management system ask for, while the independent auditors and supervisors make their own determinations.
How we scope
- We start by reviewing which DORA chapters and ISO/IEC 27001 clauses your current ISMS already covers.
- Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.
- The written scope names the ICT systems, third-party services and register of information areas in your environment.
How we build
- We set up review calendars for the yearly DORA activities and the more frequent vulnerability scanning and access reviews.
- We configure the scanning, logging and access review tooling inside your own cloud accounts or data centers.
- We document how the ISMS controls map to DORA articles, so gaps are visible to your team and your auditor.
How we hand over
- You receive the documented controls, procedures, review records and evidence catalog in a form your team can maintain.
- We walk your staff through the runbooks for scanning, access reviews, backups and incident escalation.
- Clear ownership is assigned for each recurring activity, so the calendar keeps running after the engagement ends.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers after handover.
- Retainers can cover recurring DORA review cycles, scanning follow-up and updates when standards or mappings change.
- Penetration testing for threat-led testing preparation is scoped separately and agreed in writing before it starts.
