Compliance

DORA Compliance Checklist: What Financial Entities Must Implement in 2026

Nikolai Fomm

COO and co-founder

August 17, 2026

minute of reading

What is DORA compliance?
Who DORA applies to
What changed in 2026
The DORA compliance checklist, pillar by pillar
Where financial entities actually fail: identity and the SaaS estate
Mapping DORA requirements to identity and SaaS management
DORA vs NIS2 vs ISO 27001
A 90-day priority sequence for a lean IT team
How Corma helps with DORA compliance
FAQ

Most DORA compliance programmes were built in a hurry before January 2025. They produced policies, a Register of Information, and a board sign-off. What almost none of them produced was an accurate picture of the software actually running inside the business.

That gap is now the problem. According to PwC UK, DORA applies to more than 22,000 financial entities and ICT service providers across the EU, and 2026 is the year supervisors move from collecting documents to testing whether those documents match reality. A register that lists 40 vendors when finance is paying 90 is not a documentation issue. It is a finding.

This checklist covers the five DORA pillars with their governing articles and technical standards, then goes further than the usual list: it isolates the identity, access and SaaS visibility requirements that mid-market financial entities consistently fail, and states plainly which of them a SaaS management and IAM platform can close and which ones it cannot.

What is DORA compliance?

DORA compliance is the demonstrable state in which an EU financial entity meets every requirement of the Digital Operational Resilience Act, Regulation (EU) 2022/2554, across ICT risk management, incident reporting, resilience testing, third-party risk and information sharing. It has applied since 17 January 2025, and because DORA is a regulation rather than a directive, it took effect directly without national transposition.

The regulation itself runs to 64 articles. The operational detail sits in the technical standards adopted underneath it, which is where most implementation work actually happens:

Delegated Regulation (EU) 2024/1774: ICT risk management tools, methods, processes and policies, plus the simplified framework
Delegated Regulation (EU) 2024/1772 and (EU) 2025/301: incident classification and reporting content and deadlines
Implementing Regulation (EU) 2024/2956: the standard templates for the Register of Information
Delegated Regulation (EU) 2024/1773 and (EU) 2025/532: third-party policy and subcontracting
Delegated Regulation (EU) 2025/1190: threat-led penetration testing, applicable since 8 July 2025

Compliance is proven by evidence, not by intent. Every item below should map to a document, a log, or an export you can hand a supervisor.

Who DORA applies to

DORA covers 20 categories of EU financial entity plus their ICT third-party service providers. The scope is broader than "banks and insurers", and the exemptions are narrower than most teams assume.

Who DORA applies to

Category	Typical examples	What it means in practice
Credit and payment institutions	Banks, neobanks, payment institutions, e-money institutions	Full ICT risk management framework, incident reporting, Register of Information, resilience testing
Investment firms and asset managers	Investment firms, UCITS and AIF managers, portfolio managers	Same five pillars, with proportionality applied to size and risk profile under Article 4
Insurance sector	Insurance and reinsurance undertakings, intermediaries, pension funds	ICT governance owned by the management body, third-party contract clauses under Article 30
Crypto-asset service providers	CASPs authorised under MiCA, issuers of asset-referenced tokens	In scope from day one, often with the least mature ICT documentation
Market infrastructure	Trading venues, central securities depositories, central counterparties	Threat-led penetration testing typically mandatory, not optional
Other regulated entities	Crowdfunding platforms, credit rating agencies, data reporting providers	Full scope, with the simplified framework available only if microenterprise criteria are met
ICT third-party service providers	Cloud providers, SaaS vendors, managed service providers, data centres	Contractual obligations, audit rights, incident notification duties; direct EU oversight if designated critical
Microenterprises	Fewer than 10 staff and turnover or balance sheet below 2 million euros	Simplified ICT risk management framework under Article 16, but incident reporting still applies
Mid-market financial entities (50 to 500 staff)	Regional banks, asset managers, insurance brokers, fintechs, payment institutions	Full DORA scope with no simplified regime, and usually a two to four person IT team to deliver it

Two points that catch teams out:

The simplified framework under Article 16 is genuinely narrow. It is available to entities meeting microenterprise criteria (fewer than 10 staff and turnover or balance sheet below 2 million euros) and to a small set of other entities. A 120-person payment institution does not qualify.
Proportionality under Article 4 reduces the depth of the framework, not the list of obligations. A smaller entity can implement lighter controls. It cannot skip the Register of Information or incident reporting.

If you sell software to financial entities, DORA reaches you too. A SaaS vendor supporting a critical or important function is an ICT third-party service provider with contractual, audit and notification obligations, and potentially direct EU oversight if designated critical.

What changed in 2026

Nothing in the legal text changed. The supervisory posture did.

Registers of Information have been collected and cross-checked. Supervisors now hold a sector-wide view of who depends on which provider, which makes an incomplete register easy to spot.
The TLPT standard is live. Delegated Regulation (EU) 2025/1190 has applied since July 2025, and the first wave of threat-led penetration testing notifications is landing in 2026.
Contract remediation deadlines have passed. The Article 30 clauses that were "in progress" in 2025 are now expected to be signed.
The question changed. In 2025 supervisors asked whether you had a framework. In 2026 they ask whether it is operating, and ask for the evidence trail that proves it.

This is why a checklist built on documents alone is no longer sufficient. What matters now is whether the documents describe what the systems actually do.

The DORA compliance checklist, pillar by pillar

The five DORA pillars, article by article

Pillar	DORA articles	Technical standard	Evidence a supervisor will ask for
1. ICT risk management and governance	Articles 5 to 15	Delegated Regulation (EU) 2024/1774	Framework approved by the management body, ICT asset inventory, identity and access control policies, encryption and logging policies, annual framework review
2. Incident management and reporting	Articles 17 to 23	Delegated Regulation (EU) 2024/1772 and (EU) 2025/301, Implementing Regulation (EU) 2025/302	Incident classification criteria, detection and escalation procedure, initial, intermediate and final report templates, incident log
3. Digital operational resilience testing	Articles 24 to 27	Delegated Regulation (EU) 2025/1190	Annual testing programme, vulnerability assessments, scenario tests, TLPT scoping and attestation where in scope
4. ICT third-party risk management	Articles 28 to 44	Delegated Regulation (EU) 2024/1773 and (EU) 2025/532, Implementing Regulation (EU) 2024/2956	Register of Information in the official template, third-party strategy, contract clauses under Article 30, concentration risk assessment, exit plans
5. Information and intelligence sharing	Article 45	No dedicated standard	Documented decision on joining threat intelligence arrangements, and the arrangement itself if joined
Most common gap in 2026	Articles 8, 9 and 28	Delegated Regulation (EU) 2024/1774	An asset inventory and a Register of Information that both miss the SaaS applications nobody in IT formally approved

Pillar 1: ICT risk management and governance (Articles 5 to 15)

The management body has formally approved the ICT risk management framework and retains responsibility for it under Article 5
An ICT risk management function exists with appropriate independence from ICT operations
A complete inventory of ICT assets and their interdependencies exists under Article 8, and is maintained rather than rebuilt annually
Business functions are classified, with critical or important functions explicitly identified
Identity management and access control policies exist in the form required by Delegated Regulation (EU) 2024/1774
Logging, encryption, network security, change management and human resources security policies are documented
The framework has been reviewed at least once in the last 12 months, and the review is minuted

Pillar 2: Incident management and reporting (Articles 17 to 23)

A single incident management process covers detection, classification, escalation and root cause analysis
Classification against the criteria in Delegated Regulation (EU) 2024/1772 is documented, not improvised during a crisis
Reporting timelines are rehearsed: initial notification, intermediate report, then final report using the templates in Implementing Regulation (EU) 2025/302
The reporting channel to the competent authority is tested, with named backups
An incident register exists, including incidents that were assessed and classified as non-major

Pillar 3: Digital operational resilience testing (Articles 24 to 27)

A risk-based testing programme runs at least annually, covering vulnerability assessments, scenario tests and, where relevant, source code review
Findings feed a tracked remediation backlog with owners and dates
Entities in scope for threat-led penetration testing have scoped it under Delegated Regulation (EU) 2025/1190 and notified their authority
Testers meet the independence and competence requirements set out in the standard

Pillar 4: ICT third-party risk management (Articles 28 to 44)

A documented ICT third-party risk strategy covers selection, onboarding, monitoring and exit
The Register of Information is maintained in the official template from Implementing Regulation (EU) 2024/2956, and is available to the competent authority annually and on request
Contracts for critical or important functions contain the mandatory Article 30 clauses: audit and access rights, security requirements, subcontracting limits, termination rights
Concentration risk is assessed, including the case where several apparently distinct vendors run on the same underlying cloud
Exit plans exist for critical or important functions, and have been tested rather than written

Pillar 5: Information and intelligence sharing (Article 45)

The decision on whether to join a threat intelligence sharing arrangement is documented, in either direction
If joined, the arrangement respects confidentiality and personal data rules
Threat intelligence received is routed into the ICT risk process rather than into an unread inbox

Where financial entities actually fail: identity and the SaaS estate

Every checklist above this line exists in a dozen other articles. This section is the part that supervisory findings actually turn on.

Why an incomplete Register of Information starts with shadow IT

Article 28 requires a register of all contractual arrangements for ICT services. Article 8 requires an inventory of ICT assets and their dependencies. Both assume you know what is running.

In practice, the register is usually assembled from procurement records and the finance system. That method captures anything bought through a purchase order and misses everything else: the analytics tool a team started on a credit card, the AI assistant someone connected to the CRM with an OAuth grant, the file-sharing account inherited from an acquisition. This is SaaS sprawl, and under DORA it stops being a cost problem and becomes a regulatory one.

The failure mode is specific. Your register is complete and accurate on the vendors you know about. The supervisor's question is about the ones you do not. Continuous SaaS discovery is the only way to answer that honestly, because a point-in-time audit is stale the week after it finishes.

What DORA actually requires on identity and access management

This is the requirement most checklists compress into one line, and it is far more prescriptive than that.

Delegated Regulation (EU) 2024/1774 requires financial entities to develop, document and implement identity management policies ensuring the unique identification and authentication of every person and system accessing their information, in order to assign access rights properly. It requires records of all identity assignments to be kept after a reorganisation or after the end of a contractual relationship. And it states that entities should deploy automated solutions for the identity lifecycle process where feasible and appropriate.

Read that last point again. The standard does not merely permit automation of identity lifecycle management. It expects it where it is reasonably available. For a mid-market entity running 80 to 200 SaaS applications with a two-person IT team, a quarterly spreadsheet is difficult to defend as the appropriate method.

Orphaned accounts and offboarding gaps

An orphaned account is an active account belonging to someone who has left the organisation or changed role. Under DORA they hit three requirements at once: least privilege under Article 9, asset accuracy under Article 8, and the demonstrable control of access rights required by the RTS.

They accumulate for a mundane reason. Offboarding is usually reliable in the identity provider and unreliable everywhere the identity provider does not reach: tools without SCIM support, applications with local logins, admin consoles configured before SSO existed. Automated deprovisioning across the full estate, not just the federated subset, is what closes the gap.

Audit trails you cannot produce on demand

Article 10 and the ICT risk management RTS require logging sufficient to detect and reconstruct events. In an access review context, that means being able to show who granted a specific entitlement, when, on whose approval, and when it was removed.

Most teams can reconstruct this. Few can export it in an afternoon. The distinction matters, because a control you cannot evidence quickly is treated, in practice, as a control that was not operating. Automated access reviews with per-campaign exports turn that from a reconstruction exercise into a report.

Mapping DORA requirements to identity and SaaS management

Vendor content on DORA tends to imply that one platform covers all five pillars. None does. Here is the honest version, which is also the more useful one when you are deciding where to spend budget.

DORA requirements mapped to identity and SaaS management, and what stays out of scope

DORA requirement	Source	What a SaaS management and IAM platform closes	What still needs another owner
ICT asset identification and mapping	Article 8	Continuous discovery of SaaS applications, accounts, business owners and spend, including tools bought outside IT	On-premise infrastructure, network devices, endpoints, physical assets
Identity management	RTS 2024/1774	Unique identification per user, joiner, mover and leaver automation, records of identity assignments retained after departure	Identity provider configuration, HR data quality at source
Access rights and least privilege	Article 9, RTS 2024/1774	Role-based provisioning, approval workflows for access requests, removal of standing entitlements nobody uses	Privileged infrastructure and database accounts, which usually need a dedicated PAM tool
Periodic access review and recertification	Article 9, RTS 2024/1774	Scheduled campaigns, sign-off by application owner, exportable evidence per review cycle	Defining which business roles are legitimate in the first place
Timely deprovisioning	Article 9, RTS 2024/1774	Automated revocation across every connected application when someone leaves or changes role	Applications with no API or SCIM support, physical access, badge revocation
Logging and audit trail	Article 10, RTS 2024/1774	Immutable history of who granted what access, when, and on whose approval	SIEM correlation, network telemetry, endpoint detection logs
Register of Information completeness	Article 28, ITS 2024/2956	Full vendor inventory with contract dates, owner, cost and usage, so the register reflects reality rather than memory	Legal drafting of register fields, formal annual submission to the competent authority
Contractual arrangements	Article 30, RTS 2024/1773	Central contract repository with renewal dates and owners, so no agreement renews unnoticed	Negotiating and inserting the mandatory clauses themselves
Concentration risk and exit strategies	Article 29	Visibility on overlapping and duplicate tooling across the estate	Designing, documenting and testing the exit plan
Incident management and reporting	Articles 17 to 23	Access and entitlement evidence to attach to an incident file	Incident classification, timelines, notification to the regulator
Resilience testing and TLPT	Articles 24 to 27	Not covered	Specialist testing providers, TIBER-EU accredited testers for TLPT
Information and intelligence sharing	Article 45	Not covered	CISO function, sector threat intelligence arrangements

The pattern is clear. A converged SaaS management and IAM platform does real work on Pillar 1 and Pillar 4, contributes evidence to Pillar 2, and does nothing at all for Pillar 3 and Pillar 5. Any vendor telling you otherwise is selling, not advising.

DORA vs NIS2 vs ISO 27001

Financial entities rarely face DORA alone. Many are also in scope for NIS2, and many hold or want ISO/IEC 27001 certification. DORA is the sector-specific regime, so for financial entities it takes precedence over NIS2 where the two overlap.

DORA, NIS2 and ISO 27001 compared

Criterion	DORA	NIS2	ISO/IEC 27001:2022
Legal nature	EU regulation, directly applicable with no national transposition	EU directive, transposed into national law by each member state	Voluntary international standard, certified by an accredited body
Who is covered	EU financial entities and their ICT third-party providers	Essential and important entities across 18 sectors	Any organisation that chooses to certify
In force since	17 January 2025	Transposition deadline 17 October 2024, national timelines vary	Current version published October 2022
Precedence	Takes precedence for financial entities as the sector-specific regime	Applies to financial entities only where DORA does not	Supports both, replaces neither
Third-party requirements	Register of Information, mandatory contract clauses, exit plans, EU oversight of critical providers	Supply chain security measures, less prescriptive on registers	Annex A supplier controls, no regulatory register
Incident reporting	Initial, intermediate and final reports on a fixed statutory timeline	Early warning within 24 hours, notification within 72 hours	Internal process only, no external reporting duty
Consequence of failure	Supervisory measures, fines, and for critical providers periodic penalty payments based on daily worldwide turnover	Administrative fines and management liability	Loss or suspension of certificate
Shared ground you can build once	Asset inventory, identity and access control, access reviews, audit logging, supplier inventory	Same control families, different reporting wrapper	Annex A controls 5.15 to 5.18 and 8.2 to 8.5 cover the same territory

The practical takeaway: the control layer is largely shared. Asset inventory, identity management, access reviews and audit logging satisfy DORA Article 9, the equivalent NIS2 requirements, and ISO/IEC 27001:2022 Annex A controls 5.15 to 5.18 and 8.2 to 8.5. Build the control once, then present the evidence in three different wrappers. Our ISO 27001 and IAM implementation guide covers the certification path in detail, and the user access reviews roadmap covers the review cycle itself.

A 90-day priority sequence for a lean IT team

If your DORA programme is documented but thin on evidence, the order of operations matters more than the effort.

90-day DORA priority sequence for a lean IT team

Phase 1 Days 1 to 30

See the estate

Run a full SaaS discovery across the identity provider, expense data and browser signals
Reconcile the discovered list against the current Register of Information and list every gap
Assign a named business owner to each application
Flag applications that support a critical or important function

Phase 2 Days 31 to 60

Close the access gaps

Identify and remove orphaned accounts from former staff and contractors
Automate deprovisioning on every application connected to the identity provider
Replace manual access grants with a documented approval workflow
Move admin and shared logins onto named identities

Phase 3 Days 61 to 90

Make it auditable

Launch the first access review campaign with owner sign-off
Produce an exportable evidence pack per application and per reviewer
Set the recurring review cadence and log every exception
Update the Register of Information and brief the management body

Why this order: access reviews on an incomplete inventory produce evidence that is complete on paper and wrong in reality. Discovery has to come first, remediation second, and audit evidence only once the first two hold.

How Corma helps with DORA compliance

Corma is a European platform that combines SaaS management and identity access management in one product, which is precisely the combination the DORA control layer requires. Discovery and access governance sit in the same system, so the asset inventory that feeds Article 8 and the register that feeds Article 28 are built from the same live data rather than reconciled by hand.

What that means for a DORA programme:

Continuous SaaS discovery surfaces the applications your Register of Information is missing, including tools bought outside IT
Automated joiner, mover and leaver flows deliver the identity lifecycle automation the ICT risk management RTS expects
Scheduled access review campaigns with application owner sign-off and exportable evidence per cycle
A complete audit trail of access grants, approvals and revocations, ready to export
Contract and renewal visibility so Article 30 remediation is not discovered at renewal
EU data residency and GDPR-native hosting, plus ISO/IEC 27001:2022 certification, which matters because under DORA your own provider is part of your third-party risk picture

That last point deserves emphasis. Adding a US-hosted tool to solve a DORA problem adds a transfer question and another Register of Information entry to defend. Corma is built and hosted in Europe, and was recognised in the 2025 Gartner® Magic Quadrant™ for SaaS Management Platforms.

Corma for security teams shows how compliance and access governance work together in practice. For a regulated-sector example, see how Satelia runs identity governance in healthcare, and our security page documents the hosting, certification and subprocessor detail your own vendor assessment will ask for.

Want to see what your Register of Information is missing? Book a demo and we will run a discovery against your estate.

FAQ

What are the five pillars of DORA?

The five pillars are ICT risk management and governance (Articles 5 to 15), ICT-related incident management, classification and reporting (Articles 17 to 23), digital operational resilience testing (Articles 24 to 27), ICT third-party risk management (Articles 28 to 44), and information and intelligence sharing (Article 45). The first four are mandatory. Information sharing is voluntary, but the decision should be documented.

Is DORA compliance mandatory?

Yes. DORA has been legally binding on in-scope EU financial entities since 17 January 2025. As an EU regulation it applies directly, with no national transposition step, which is why there is no country-specific grace period.

What are the penalties for DORA non-compliance?

Financial entities are sanctioned by their national competent authority, which can impose administrative measures and fines, require remediation, and in serious cases restrict activities. Critical ICT third-party service providers fall under EU oversight and can face periodic penalty payments set at 1% of their average daily worldwide turnover in the preceding business year, applied daily for up to six months until they comply.

What is the Register of Information under DORA?

The Register of Information is a structured inventory of every contractual arrangement a financial entity has with ICT third-party service providers, maintained in the standard templates set out in Implementing Regulation (EU) 2024/2956. It must be made available to the competent authority annually and on request. It is the single most common source of findings, because it is only as accurate as the entity's visibility over its own software estate.

Does DORA require automated access management?

Not in those words, but close. Delegated Regulation (EU) 2024/1774 requires documented identity management and access control policies, records of identity assignments retained after departure, and states that entities should use automated solutions for the identity lifecycle process where feasible and appropriate. For an entity running hundreds of SaaS applications, manual review is increasingly difficult to present as appropriate.

How is DORA different from GDPR?

They govern different things. GDPR protects personal data and applies to any organisation processing the data of people in the EU. DORA governs digital operational resilience and applies specifically to EU financial entities and their ICT providers. An entity can be fully GDPR compliant and fail DORA, because DORA is about withstanding and recovering from ICT disruption, not about lawful data processing.

Does DORA apply to UK or US companies?

Not directly, but reach is common. DORA binds financial entities operating in the EU and the ICT providers serving them. A UK or US software vendor supporting an EU financial entity's critical or important function inherits contractual, audit and incident notification obligations through Article 30, and can be designated a critical ICT third-party service provider subject to direct EU oversight.

Can a mid-market financial entity use the simplified DORA framework?

Usually not. The simplified ICT risk management framework under Article 16 is aimed at microenterprises, meaning fewer than 10 staff and turnover or balance sheet below 2 million euros, plus a narrow set of other entities. A 50 to 500 person financial entity is in full scope, and proportionality under Article 4 adjusts the depth of controls rather than removing obligations.