DORA vs ISO 27001: 2026 Guide for EU Fintechs on…

In this article ↓

DORA vs ISO 27001 in one table
The short answer for fintechs
Scope: mandatory regulation vs voluntary certification
Enforcement difference
Incident reporting: DORA has a statutory clock, ISO 27001 does not
ISO/IEC 27001:2022 points that matter for DORA teams
Third-party risk: DORA is wider than supplier-relationship controls
Testing and audits: do not confuse a certification audit with a DORA test programme
Build-once evidence model
Example control mapping
Common mistakes
Treating ISO 27001 certification as DORA compliance
Treating DORA compliance as ISO 27001 certification-ready
Confusing a certification audit with a supervisory examination
Assuming the ISO incident process satisfies DORA's reporting clock
Letting the ISMS scope quietly exclude what DORA actually covers
2026 operating checklist
Bottom line
FAQ
Does ISO 27001 certification make an EU fintech DORA compliant?
Does DORA compliance replace the need for ISO 27001 certification?
Is ISO 27001 certification mandatory under DORA?
Can DORA testing evidence be reused for an ISO 27001 audit, or the other way round?
Who enforces DORA and who enforces ISO 27001?
Should a fintech pursuing both start with DORA or with ISO 27001?
Related reading
Primary sources

Last reviewed: 14 July 2026

Key takeaways

DORA is an EU regulation for financial entities; ISO/IEC 27001:2022 is a voluntary international standard for an information security management system (ISMS).
ISO 27001 certification is strong assurance evidence, but it does not satisfy DORA on its own: no Register of Information, no TLPT, no statutory incident-reporting clock.
Partners and enterprise customers often ask for both: DORA readiness for regulators, ISO 27001 certification for commercial assurance.
Fastest path: run one ICT risk and control system, then produce a DORA evidence view and a separate ISO 27001 certification view from it.

DORA and ISO 27001 sit next to each other on almost every EU fintech's compliance list, but they are not two versions of the same thing.

DORA is a financial-sector regulation. It applies by force of law to financial entities such as payment institutions, electronic money institutions, investment firms, crypto-asset service providers, insurers and other regulated firms, plus certain critical ICT third-party providers. There is no opt-out and no certificate: a national competent authority (NCA) supervises the entity directly.

ISO/IEC 27001:2022 is an international management-system standard published by ISO/IEC. An organisation chooses to build an ISMS against it, then chooses whether to have that ISMS certified by an accredited certification body. Nobody is legally required to hold an ISO 27001 certificate to operate a regulated financial service in the EU.

For an EMI, PI, CASP or fintech vendor, the practical question in 2026 is not "which one is stricter?"

The better question is:

Does the organisation need to prove statutory operational resilience to a financial supervisor, commercial security assurance to customers and partners, or both at once?

DORA vs ISO 27001 in one table

Question	DORA	ISO/IEC 27001:2022
Legal nature	EU regulation, directly applicable: Reg (EU) 2022/2554	Voluntary international standard; adoption and certification are not mandated by law
Core purpose	Digital operational resilience of financial entities	Establish, operate and continually improve an information security management system (ISMS)
Scope trigger	Being a financial entity in DORA scope, or a critical ICT third-party provider under oversight	An organisation choosing to define an ISMS scope and, optionally, pursue certification
Main owner	Regulated financial entity; management body is directly accountable and cannot delegate that accountability	Whichever legal entity or business unit defines the ISMS scope
Main evidence	ICT risk framework, incident classification and reports, resilience testing records (incl. TLPT), Register of Information, supplier oversight	Statement of Applicability, ISMS documentation, internal audit records, management review minutes, certification audit reports
Enforcement	National competent authority supervision, examination and administrative penalties	Accredited certification body issues, suspends or withdraws the certificate; no government supervisor
Status in 2026	Applies since 17 January 2025	2022 edition is the current published edition (3rd edition, October 2022)

The short answer for fintechs

Scenario	DORA relevance	ISO 27001 relevance
EU payment institution operating its own platform	Directly in scope as a financial entity	Optional; often pursued for customer and partner assurance
EMI whose enterprise customers demand a security certificate	DORA governs the EMI regardless of any certificate	ISO 27001 certification can be a commercial precondition for enterprise contracts
CASP that treats ISO 27001 as its main security programme	DORA obligations (Register of Information, testing, incident reporting) apply in full, certificate or not	Certification does not substitute for any specific DORA obligation
SaaS vendor serving financial entities, ISO 27001 certified	DORA can reach the vendor through customer due diligence, contractual clauses or critical ICT third-party oversight	Certification is strong assurance evidence for the financial entity's supplier review and Register of Information entry
Fintech group with several regulated entities across member states	DORA obligations attach per financial entity, supervised by its own NCA	One group-wide ISMS scope can cover multiple entities if the scope statement is drawn correctly

Scope: mandatory regulation vs voluntary certification

DORA starts with a legal question: is the organisation a financial entity in scope, or an ICT third-party provider subject to contractual requirements or direct oversight? There is no "opt in" and no certificate to hold or not hold.

ISO 27001 starts with a management decision: what should the ISMS scope cover, and does the organisation want a third-party certification audit against it? A company can run an excellent ISMS and never certify it, or certify only part of the business.

This difference has practical consequences:

a fintech is in DORA scope the moment it meets the entity definition, independent of any certification decision;
an ISO 27001 certificate can be scoped narrowly (one product line, one data centre, one legal entity) in a way DORA's entity-level obligations cannot be;
holding an ISO 27001 certificate says nothing, by itself, about whether the certified scope also covers everything a DORA supervisor would examine.

Enforcement difference

DORA enforcement is public-law supervision. The competent financial authority can examine the entity's ICT risk framework, incident classification and reporting, testing programme and third-party arrangements, and can apply administrative penalties under DORA and national law.

ISO 27001 enforcement runs through the certification body, not a government supervisor. A certification body conducts the initial audit, then annual surveillance audits, then a recertification audit at the end of the certification cycle (typically three years). Non-conformities can lead to corrective-action requirements, certificate suspension or withdrawal, but there is no regulator, no administrative fine and no direct notification duty to a financial authority built into the standard itself.

Issue	DORA consequence	ISO 27001 consequence
Weak ICT risk framework	Supervisory findings, remediation requirements, potential administrative penalties	Non-conformity at internal or certification audit; corrective action required to keep the certificate
Missing Register of Information	DORA evidence gap, a supervisory finding in its own right	Not an ISO 27001 artefact; the standard has no equivalent register requirement
Failed TLPT (where required)	DORA Article 26 finding for entities identified by the competent authority	Not applicable; ISO 27001 does not require threat-led penetration testing
Certificate lapses or is withdrawn	No direct DORA consequence by itself, but can weaken supplier due-diligence evidence a financial-entity customer relies on	Loss of the certificate; recertification audit needed to regain it

Incident reporting: DORA has a statutory clock, ISO 27001 does not

DORA's incident reporting duty is a fixed regulatory timeline. Once an ICT-related incident is classified as major, the initial notification is due within 4 hours of classification and no later than 24 hours after detection, the intermediate report within 72 hours of the initial notification, and the final report within one month. Templates are set by the adopted implementing technical standard.

ISO 27001 requires an incident-management process as part of the ISMS (the Annex A control set covering incident planning, assessment, response and lessons learned), reviewed through internal audit and management review under the standard's continual-improvement clause. It does not set an hours-based reporting clock to a government authority, and it does not require notifying a financial supervisor at all.

The practical risk is assuming one process covers both. An ISO-certified incident process can be a good operational foundation, but it still needs a DORA-specific classification step that decides whether an event is a "major ICT-related incident" under DORA's criteria, on DORA's clock, to DORA's competent authority.

Running ISO 27001 and DORA at the same time?

A 15-minute call can separate the statutory DORA evidence from the ISO 27001 certification evidence, before an auditor or a supervisor asks first.

Book a free 15-min call →

ISO/IEC 27001:2022 points that matter for DORA teams

The 2022 edition restructured Annex A into 93 controls across four themes: organisational, people, physical and technological, down from 114 controls in 14 domains in the 2013 edition. Several of these themes map directly onto ground DORA also covers, even though the two use different language and neither obligation satisfies the other automatically.

ISO/IEC 27001:2022 theme	Why DORA teams should care
Organisational controls (incl. supplier relationships, incident management)	Overlaps with DORA's ICT third-party risk and incident-classification evidence, though DORA's Register of Information and Article 30 contractual content go further
People controls	Supports DORA's governance expectation that staff understand ICT risk, without replacing the management body's own Article 5 accountability
Physical controls	Feeds ICT asset and environment evidence relevant to DORA's identification duty
Technological controls	Access control, cryptography, logging and vulnerability-related controls feed DORA's ICT risk treatment evidence
Statement of Applicability	A useful internal control inventory, but it is not a substitute for the Register of Information's contractual-arrangement focus
Internal audit and management review (Clause 9)	Structurally similar in spirit to DORA's Article 6(5) annual framework review, but the two reviews are legally distinct and should not be merged into one undifferentiated exercise

[OPERATOR-WEB-VERIFY] Organisations still certified against the 2013 edition should confirm the current transition deadline and status directly with their certification body before treating a 2013 certificate as current; this page does not assert a specific transition cut-off date.

Third-party risk: DORA is wider than supplier-relationship controls

ISO 27001's supplier-relationship controls ask whether information security requirements are agreed, documented and monitored for suppliers that can affect the ISMS scope.

DORA's third-party regime is more specific and goes further for financial entities: a Register of Information covering all ICT contractual arrangements, a concentration-risk assessment, mandatory contractual content under Article 30, and a dedicated subcontracting standard that requires assessing the whole subcontracting chain, not just the direct provider.

Capability	ISO 27001 view	DORA view
Supplier list	Suppliers relevant to the defined ISMS scope	Register of Information covering ICT arrangements across the financial entity, distinguishing those supporting critical or important functions
Concentration risk	Not a named control	Required assessment of ICT concentration risk, including hard-to-substitute providers
Contract content	Security requirements agreed with the supplier, scoped to the ISMS	Mandatory minimum contractual content under Article 30 (access, audit rights, exit strategy and more)
Subcontracting	Addressed only as far as the ISMS scope and Statement of Applicability define it	Whole subcontracting chain assessed under the dedicated subcontracting technical standard
Exit planning	Not a named ISO 27001 control	Required for ICT arrangements supporting critical or important functions

If the ISMS supplier list is well maintained, it can usually seed the DORA Register of Information as a starting inventory. It is very unlikely to be complete enough to serve as the Register itself.

Testing and audits: do not confuse a certification audit with a DORA test programme

An ISO 27001 certification audit tests whether the ISMS conforms to the standard, inside the scope the organisation defined. A DORA testing programme is broader and mandatory for the financial entity, whatever the ISMS scope happens to be.

Testing or audit activity	ISO 27001 contribution	DORA contribution
Internal ISMS audit (Clause 9.2)	Required at planned intervals; confirms ISMS conformance	Useful governance evidence, but not a substitute for any DORA testing type
Management review (Clause 9.3)	Required at planned intervals; feeds continual improvement	Can feed board-level ICT risk reporting evidence
Certification, surveillance and recertification audits	Confirm ISMS conformance to keep the certificate	Not a recognised DORA testing type; do not cover TLPT or DORA's specific test catalogue
Vulnerability assessments and penetration testing performed under Annex A controls	Support technical control assurance inside ISMS scope	Can feed Article 25 testing evidence where scope, methodology and independence line up
Threat-led penetration testing (TLPT)	Not an ISO 27001 requirement	Required at least every 3 years for entities identified by the competent authority under Article 26

Build-once evidence model

The goal is not to merge DORA and ISO 27001 into one document set. The goal is to run one control system and produce two evidence views from it.

Operating artefact	DORA evidence view	ISO 27001 evidence view
ICT asset and information-asset inventory	Systems supporting critical or important functions	Assets within the defined ISMS scope
Risk register	ICT risks, owners, treatment and residual risk	Risk assessment feeding the Statement of Applicability
Incident playbook	Major ICT-incident classification and statutory reporting	Incident-management controls and lessons-learned records
Supplier register	Register of Information and Article 30 oversight	Supplier list and agreed security requirements within ISMS scope
Testing calendar	Article 25 testing programme and, where required, TLPT	Internal audit programme, certification audit cycle
Board and management reporting	ICT risk, incidents, third-party concentration and resilience posture	Management review inputs and outputs (Clause 9.3)

Example control mapping

Control	DORA reason	ISO 27001 reason	Practical implementation
Access control and MFA	Reduces ICT and operational risk	Supported by Annex A technological controls	One access-control standard, evidenced once, referenced from both views
Vendor due diligence	ICT third-party risk management, Register of Information	Supplier-relationship controls within ISMS scope	One supplier-review template with a DORA section and an ISO evidence section
Vulnerability management	Feeds ICT risk treatment and resilience testing evidence	Supported by technological controls and internal audit	One remediation SLA tied to asset criticality, referenced from both regimes
Incident tabletop exercise	Tests classification, escalation and statutory reporting timing	Tests the ISMS incident-management process	One exercise with a DORA notification inject and an ISO lessons-learned inject
Management review cadence	Feeds Article 6(5) annual framework review evidence	Required under Clause 9.3	One board or leadership review with distinct DORA and ISO agenda items

Common mistakes

Treating ISO 27001 certification as DORA compliance

A certificate proves the ISMS conforms to the standard inside its defined scope. It does not prove a Register of Information exists, that TLPT has been run where required, or that the management body meets its Article 5 obligations.

Treating DORA compliance as ISO 27001 certification-ready

A financial entity can meet its DORA obligations and still fail an ISO 27001 certification audit if the ISMS scope, Statement of Applicability or internal audit programme are not built to the standard's specific requirements.

Confusing a certification audit with a supervisory examination

An ISO 27001 auditor checks conformance to the standard for the certification body. A DORA supervisor examines the regulated entity's compliance with the law. Passing one does not pre-clear the other.

Assuming the ISO incident process satisfies DORA's reporting clock

ISO 27001 requires an incident-management process. It does not require a 4-hour classification-to-notification clock to a financial supervisor. Fintechs need a DORA-specific classification step layered on top of the ISMS incident process.

Letting the ISMS scope quietly exclude what DORA actually covers

An ISMS can be scoped to one product or one office. DORA's obligations attach to the financial entity as a whole for the services in its licence. A narrow ISMS scope is a legitimate management choice, but it should never be presented as if it closed DORA gaps outside that scope.

2026 operating checklist

Task	Owner	Output
Confirm DORA financial-entity status and NCA	Compliance / legal	Scope memo
Confirm current ISO 27001 certification status and ISMS scope	Security / quality	Scope and certificate status statement
Map ISMS asset inventory to the DORA ICT/information-asset identification duty	Security	Combined asset view
Build or refresh the DORA Register of Information from the ISMS supplier list	Vendor risk / compliance	Register of Information draft
Confirm whether TLPT applies and, if so, plan the cycle	vCISO / risk owner	Testing programme entry
Align internal audit and management review cadence with Article 6(5) review triggers	Compliance / security	Combined review calendar
Build a board pack that separates DORA resilience posture from ISO 27001 certification status	vCISO / risk owner	Management reporting pack

Bottom line

DORA vs ISO 27001 is not a choice between two competing frameworks. It is a difference between a legal obligation and a voluntary certification.

DORA asks whether a financial entity can remain operationally resilient under ICT disruption, third-party dependency and supervisory scrutiny, and it applies regardless of any certificate.

ISO/IEC 27001:2022 asks whether an organisation has built and can demonstrate a working information security management system, inside a scope it chose, to a standard it can be independently certified against.

For EU fintechs pursuing both, the practical approach is one ICT risk and control system, with a DORA-specific evidence view for the supervisor and an ISO 27001-specific evidence view for the certification body, and a named owner who keeps the two from silently drifting apart.

FAQ

Does ISO 27001 certification make an EU fintech DORA compliant?

No. ISO 27001 certification demonstrates a conforming information security management system inside its defined scope. DORA compliance additionally requires a Register of Information, DORA-specific incident classification and statutory reporting, resilience testing that can include TLPT, and direct management-body accountability under Article 5.

Does DORA compliance replace the need for ISO 27001 certification?

No. DORA does not create an ISO 27001 certificate, a Statement of Applicability or a certification-body audit report. A fintech whose customers or partners commercially require ISO 27001 certification still needs to pursue it separately.

Is ISO 27001 certification mandatory under DORA?

No. DORA does not mandate ISO 27001 certification. A financial entity can be fully DORA compliant without ever certifying an ISMS, though many choose to pursue certification for commercial or customer-assurance reasons.

Can DORA testing evidence be reused for an ISO 27001 audit, or the other way round?

Partially. Vulnerability assessments, penetration tests and internal audits performed for one purpose can support the other where scope, methodology and independence line up, but TLPT is DORA-specific and certification audits are ISO-specific: neither substitutes for the other.

Who enforces DORA and who enforces ISO 27001?

DORA is enforced by the national competent authority responsible for the financial entity, with administrative penalties available under DORA and national law. ISO 27001 is enforced by the accredited certification body that issued the certificate, which can require corrective action or suspend or withdraw the certificate; there is no government supervisor involved.

Should a fintech pursuing both start with DORA or with ISO 27001?

Start with one ICT risk and control system rather than sequencing two separate projects. Build the Register of Information, incident classification and testing programme DORA requires first if a supervisory deadline is closer, then layer the Statement of Applicability and certification-audit preparation on top of the same control set.

DORA vs ISO 27001: 2026 Guide for EU Fintechs on Regulation vs Certification