DORA for financial entities: the access-control playbook

who is in scope, and the proportionality point

DORA is Regulation (EU) 2022/2554. It has applied directly across the EU since 17 January 2025. Because it is a Regulation rather than a Directive, the core text applies as written in every Member State, without waiting for national transposition.

Article 2 brings roughly twenty categories of financial entity into scope: credit institutions, payment and electronic money institutions, investment firms, crypto-asset service providers, insurers and reinsurers, intermediaries, fund managers, central securities depositories, and more. ICT third-party service providers are pulled in through the third-party-risk pillar and the oversight framework. If you run technology for a regulated financial business in the EU, you are almost certainly in scope.

DORA scales with size and risk. A simplified ICT risk-management framework (Article 16) applies to designated smaller or lower-risk entities, such as small and non-interconnected investment firms, certain exempt payment and e-money institutions, small institutions for occupational retirement provision, and small ancillary insurance intermediaries. The simplified regime has its own access-control article in the RTS, Article 33. Microenterprises get further proportionality relief on specific obligations. Proportionality runs through the whole Regulation rather than acting as a single blanket exemption, so the question is not whether the access rules apply to you but how much detail you owe given your profile.

the five pillars in brief

1. ICT risk management. Governance and a risk-management framework: identify, protect, detect, respond, recover, learn. The management body is accountable. Articles 5 to 16.
2. ICT incident management, classification and reporting. A process for handling incidents, criteria for classifying major incidents, and mandatory reporting to the competent authority. Articles 17 to 23.
3. Digital operational resilience testing. A testing programme for everyone, plus threat-led penetration testing for designated significant entities at least every three years. Articles 24 to 27.
4. ICT third-party risk. Managing third-party ICT risk, key contractual terms, the register of information, and an oversight framework for critical ICT third-party providers led by a Lead Overseer. Articles 28 to 44.
5. Information sharing. Voluntary arrangements to share cyber-threat intelligence. Encouraged, not required. Article 45.

Access control lives inside pillar one. This guide goes deep on that slice and leaves the rest at the level of brief above, except where access touches incident reporting and third-party access directly.

the access-control requirements, control by control

There are two layers. The Level 1 obligation sits in DORA itself, Article 9. The detail sits in the Level 2 standard, RTS 2024/1774, Title II, Chapter II. Article 9(4)(c) requires you to limit physical and logical access to information and ICT assets to what is needed for approved functions only. That is least privilege. Article 9(4)(d) requires strong authentication mechanisms based on relevant standards. Article 19 covers the human resources policy, Article 20 covers identity management, and Article 21 is the central access-control article. Article 33 mirrors these for the simplified regime.

least privilege and need-to-know

What it means in practice. Access rights are assigned on a need-to-know, need-to-use, and least-privilege basis, including for remote and emergency access. People hold the access their current role requires and no more. Default-deny, not default-allow.

How to evidence it. A documented access-management policy that states the principle. A role-to-entitlement mapping. Provisioning records that tie each grant to an approved request and a business reason. The gap between what people hold and what their role requires is the metric a reviewer will probe.

identity management and named, accountable accounts

What it means in practice. Every action is attributable to a known person or system. Generic and shared accounts are limited to the extent possible. Users are identifiable for their actions at all times.

How to evidence it. A unique-identity inventory. A list of any remaining shared or generic accounts with a justification for each and a plan to reduce them. Logs that resolve activity to a named identity rather than a role label such as admin or service.

segregation of duties

What it means in practice. Access is arranged so that no single person holds a combination of rights that lets them both perform and conceal a sensitive action. The classic example is the same account being able to both create and approve a payment.

How to evidence it. A documented segregation-of-duties matrix for sensitive processes. A toxic-combination ruleset. Evidence that conflicting entitlements are detected and either prevented or compensated by a control.

account management: grant, change, and revoke

What it means in practice. Clear roles and responsibilities for granting, reviewing, and revoking access: the joiner-mover-leaver discipline. The RTS calls out two parts specifically. Privileged, emergency, and administrator access is granted on a need-to-use or ad-hoc basis for all ICT systems, not standing. Access rights are withdrawn without undue delay when employment ends or when the access is no longer necessary.

How to evidence it. A joiner-mover-leaver procedure with named owners. Termination tickets that show access removal timestamps against departure dates, so you can demonstrate the without-undue-delay standard. A record of privileged-access grants that shows they were time-bound or approved per use rather than left standing.

privileged and emergency access on a need-to-use basis

What it means in practice. Administrative access is granted when needed, used, and removed or expired, never held as a permanent attribute of a person. Emergency, or break-glass, access follows a defined procedure that is logged and reviewed after the fact. The RTS also points to dedicated accounts for administrative tasks and, where feasible, automated privileged-access management.

How to evidence it. Records of just-in-time or check-out privileged access if you operate it. Break-glass procedure documentation and a log of every break-glass use with post-use review. Separation of admin accounts from day-to-day user accounts. If you run a PAM tool, its session logs and approval records serve directly.

access recertification on a fixed cadence

What it means in practice. Someone accountable confirms, on a schedule, that each person still needs the access they hold. The RTS sets two cadences (Art. 21(e)(iv) of Delegated Regulation 2024/1774): update access rights at least once a year for normal ICT systems, and at least every six months for ICT systems supporting critical or important functions. Review also happens whenever a change makes it necessary.

How to evidence it. A recertification schedule that maps each system to its cadence and its last completed review. Per-account decisions from the reviewer: confirm, modify, or revoke. Evidence that revocations were executed, not just recorded. The six-monthly cadence for critical-function systems is the detail most often missed, so name it explicitly in your schedule.

strong and multi-factor authentication

What it means in practice. Authentication is matched to the sensitivity of the data and the risk of the asset. Strong authentication, including multi-factor, applies to remote access, privileged access, access to systems supporting critical or important functions, and publicly accessible assets. Partial coverage is the common failure here.

How to evidence it. An MFA coverage map that shows, per application and per access path, whether strong authentication is enforced. Particular attention to remote and privileged paths. Evidence that legacy or fallback authentication methods are closed rather than left as a bypass.

physical access controls

What it means in practice. Physical access to critical assets follows the same least-privilege logic: authorised persons are identified and logged, access is limited, and it is monitored and reviewed.

How to evidence it. Access logs for sensitive facilities. A periodic review of who holds physical access and revocation when it is no longer needed.

the recertification cadences, stated plainly

• At least annually for normal ICT systems.
• At least every six months for systems supporting critical or important functions.

Plus a review whenever a change makes one necessary. Your first step on cadence is to identify which of your systems support critical or important functions, because those carry the six-monthly obligation. The rest of your estate sits on the annual floor.

how access connects to incident reporting and third-party access

Incident reporting. When a major ICT-related incident occurs, DORA requires a three-stage report to your competent authority: an initial notification, an intermediate report, and a final report. Access evidence feeds these. If the incident involved compromised credentials, a lingering leaver account, or an over-privileged identity, your account records, recertification history, and authentication logs are what let you reconstruct what happened and what the attacker could reach. Good access hygiene is also good incident-response telemetry.

Third-party access. The third-party-risk pillar governs the providers who run or touch your ICT. Where those providers hold access to your systems, that access is still your access to control. Vendor and contractor accounts are in scope for least privilege, recertification, and prompt removal. The register of information catalogues your ICT third-party arrangements; the access those arrangements grant should be reflected in your access reviews, not treated as someone else's problem.

where to start: a control checklist

If you are building toward this, the following sequence is a practical order. Each item maps to a requirement above.

1. Inventory identities. Produce a list of every human and non-human account across your in-scope systems. You cannot recertify what you cannot see.
2. Classify your systems. Mark which systems support critical or important functions. This sets the six-monthly cadence and the strong-authentication scope.
3. Map MFA coverage. For each application and access path, record whether strong authentication is enforced. Flag every remote and privileged path that is not covered.
4. Find standing privileged access. List who holds admin rights and whether those rights are standing or granted per use. Identify break-glass accounts and confirm they are logged.
5. Test your leaver process. Sample recent departures and measure the time from exit to access removal. This is your without-undue-delay evidence.
6. Reduce shared accounts. List generic and shared accounts, justify any that remain, and assign each a named owner.
7. Stand up recertification. Build a schedule that names each system, its cadence, its reviewer, and its last review date. Run the first cycle and keep the execution records.
8. Document the policy. Write the access-management policy that ties all of the above together. The policy is what a supervisor reads first.

common gaps

Partial MFA. Strong authentication is enforced on the main identity provider but not on every remote or privileged path. A legacy protocol, a direct database connection, or a vendor portal stays outside coverage. The requirement is strong authentication on remote, privileged, and critical-function access, so partial coverage is partial compliance.

Shared admin accounts. A handful of generic admin logins are used by several people. Activity cannot be attributed to a named person, which fails the accountability requirement and complicates both recertification and incident reconstruction.

Leaver access lingering. Departures are processed in the directory but accounts persist in SaaS applications, cloud consoles, or systems outside the central provisioning path. The without-undue-delay standard applies to all of it, not just the directory.

Service accounts without owners. Non-human identities are created at setup, granted broad access, and never tied to a named owner. They do not appear in HR-driven reviews because they are not people. In a typical environment they accumulate quietly and are the population least likely to be recertified.