What Financial Entities Must Prove About Access Control Under DORA

DORA does not reduce access control to multifactor authentication or an annual user review. For financial entities in scope, the legal framework connects access to ICT risk management: people and systems must be uniquely identifiable, accounts must be governed throughout their lifecycle, rights must follow need-to-know, need-to-use and least-privilege principles, incompatible rights must be separated, and unnecessary access must be withdrawn without undue delay.

The most detailed rules are not all in the main DORA text. Regulation (EU) 2022/2554 establishes the digital operational resilience framework and has applied since 17 January 2025. Commission Delegated Regulation (EU) 2024/1774 specifies ICT risk-management policies and contains explicit requirements for identity management and access control. Reading only a short summary of DORA therefore misses the operational detail that supervisors can test.

The practical answer: a financial entity should be able to show who or what received access, why it was necessary, who approved it, which controls limited it, when it was reviewed, how quickly it changed or ended, and which evidence proves that the action reached every relevant ICT asset.

This guide explains that evidence chain. It is based on EU legal texts and European Supervisory Authority material checked on 12 September 2026. Applicability, proportionality and supervisory expectations still depend on the entity, its sector, its ICT risk profile and the competent authority.

Start with the legal layers

DORA is directly applicable EU law. It covers a broad range of financial entities, including credit institutions, payment institutions, investment firms, insurance and reinsurance undertakings, institutions for occupational retirement provision, crypto-asset service providers and several other categories identified in Article 2. It also creates an oversight framework for critical ICT third-party service providers.

The framework is deliberately broader than access control. It addresses ICT risk management, incident management and reporting, resilience testing, third-party risk and information sharing. Access governance sits inside that system. A weak joiner, mover or leaver process is not an isolated directory-administration problem when it can expose critical or important functions, frustrate investigation or prevent an entity from proving accountability.

The detailed access obligations relevant to most financial entities appear in Delegated Regulation 2024/1774:

• Article 20 covers identity management;
• Article 21 covers access control;
• Article 19 links human-resources policy to ICT security responsibilities and return of ICT and information assets;
• Article 12 addresses logging procedures, systems and retention;
• other provisions connect asset classification, change management, incident handling and business continuity to the same ICT risk-management framework.

Articles 20 and 21 are in Title II. Entities covered by Article 16(1) of DORA instead follow the simplified framework in Title III, including Article 33 on access control. Article 33 requires periodic review and withdrawal of unnecessary rights, but does not repeat Article 21’s annual and six-month intervals. Confirm the applicable regime before adopting those intervals as a legal minimum.

What Article 20 requires from identity management

Article 20 requires documented and implemented identity-management policies and procedures that enable unique identification and authentication of natural persons and systems accessing the financial entity’s information. It is not limited to employees. Staff of ICT third-party service providers who access information or ICT assets are expressly relevant.

The policy must provide a unique identity corresponding to a unique user account for each member of staff or relevant third-party staff member. The entity must keep records of assigned identities, subject to applicable EU and national retention rules. It must also operate a lifecycle process covering the creation, change, review, update, temporary deactivation and termination of all accounts.

The regulation says automated solutions should be deployed for identity lifecycle management where feasible and appropriate. That wording matters. It does not create a universal obligation to buy one named IGA product. It does make a permanently manual process harder to defend when automation is feasible, risks are material and the manual process cannot produce timely or complete evidence.

A useful identity record therefore links at least:

1. the person, service or system identity;
2. the authoritative source and employment or contract status;
3. the unique accounts associated with that identity;
4. the owner and business purpose of non-human identities;
5. the rights, groups, roles and privileged assignments attached to each account;
6. approval, effective dates and expiry conditions;
7. review and revocation history; and
8. exceptions, compensating controls and accountable risk owners.

Without those links, an entity can disable a directory account and still leave access active in a local application, cloud service, database, emergency account or third-party portal.

Article 21 translated into control evidence

Article 21 requires a documented and implemented access-control policy. The table below separates the legal control area from evidence an organisation can use to demonstrate operation. The evidence examples are practical implementation choices, not extra legislative wording.

Review frequency is explicit

The delegated regulation does not leave every review interval undefined. Article 21(e)(iv) requires access rights to be updated when changes are necessary and at least annually for ICT systems other than those supporting critical or important functions; for those supporting systems, the interval is at least every six months. An access review should identify the necessary updates and verify their completion. A review that records decisions without applying them does not satisfy the update requirement.

Those intervals are maximum gaps, not an instruction to wait. A termination, transfer, access-risk change or discovery that access is no longer necessary should trigger an event-based update. A six-month certification does not repair a leaver account that remained active for five months.

An effective review campaign should show the reviewer the person or system, current rights, business purpose, owner, last use where available, privileged status, conflicting combinations and the impact of removing access. The decision must then reach the target system, and the entity should reconcile the result. A spreadsheet containing “approved” values without evidence of fulfilment is an incomplete control record.

Privileged, emergency and shared access need their own path

Privileged access can change configurations, security settings, data or identities. Article 21 requires privileged, emergency and administrator access to be assigned on a need-to-use or ad hoc basis for ICT systems. It also requires strong authentication for privileged access and for access to ICT assets supporting critical or important functions, as well as for remote and publicly accessible assets.

The strongest operating model separates the normal identity from the administrative identity, approves elevation for a defined task, limits its duration, records use and reviews exceptional activity. A permanent administrator role granted because someone “may need it later” conflicts with the purpose of need-to-use and least privilege.

Generic and shared accounts deserve similar scrutiny. DORA does not state that they can never exist. It requires their use to be limited as far as possible and requires users to remain identifiable for actions performed. A defensible exception names the owner, purpose, users or retrieval mechanism, authentication control, logging method, expiry date and review cadence. If several people know the same password and no reliable mechanism attributes an action, accountability is missing.

Where feasible and appropriate, the delegated regulation also expects automated privileged-access management. Automation should reduce standing privilege, enforce expiry and create evidence. It should not simply automate approval of badly designed permanent roles.

Test access removal during offboarding

Article 21 requires withdrawal of access rights without undue delay when employment ends or access is no longer necessary. Article 19 requires staff to return ICT assets and tangible information assets belonging to the entity upon termination. Article 20 requires lifecycle management to include termination of accounts.

These provisions make offboarding a useful test of the entire identity architecture. The organisation should know the authoritative termination time, identify every connected account, revoke active access, address privileged and emergency rights, recover equipment and prove the final state. Contractors and third-party staff require the same discipline when their contractual need ends.

“Without undue delay” is context-dependent; the regulation does not publish one universal number of minutes for every departure. The entity should define risk-based service levels. An involuntary departure involving privileged production access may require coordinated revocation at the meeting time. A planned retirement with no privileged access may support a scheduled workflow. The rationale and result must be recorded.

Include system identities in access governance

Article 20 refers to natural persons and systems accessing information. Service accounts, workloads, integrations, robots, API clients and automation identities can therefore fall within the identity-management problem. They often outlive projects, use non-interactive credentials and accumulate broad permissions.

For each non-human identity, record a human owner, a technical custodian, purpose, environments, permissions, authentication method, credential location, rotation rule, last observed use, dependencies and retirement condition. Ownership should be reassigned when staff leave. Disabling a departed employee while leaving a script, token or integration under that person’s informal ownership creates an orphaned control.

The access review process should distinguish between a user account and a service identity. Asking a manager whether a cryptically named service account is “still needed” is unlikely to produce reliable evidence. The reviewer needs purpose, dependency and usage context.

Third-party access remains the financial entity’s risk

DORA gives substantial attention to ICT third-party risk. Contractual controls do not replace internal access governance. The financial entity needs visibility into the external people and systems that can reach its ICT assets, including subcontractors where relevant.

At minimum, third-party access should have a sponsor, contract or service reference, approved scope, start date, expiry date, authentication control and review owner. Remote and privileged access should follow the stronger controls described above. When a contract, assignment or individual engagement ends, the revocation event must reach the affected systems.

The entity should also be able to connect access evidence with its register of contractual arrangements where this helps identify exposure to ICT services. The European Banking Authority’s DORA register material confirms that DORA has applied since 17 January 2025 and that in-scope entities must maintain comprehensive information about contractual arrangements with ICT third-party providers. The register and the identity inventory answer different questions, but each can expose gaps in the other.

Build a supervisory evidence pack

A policy is evidence of design. Supervisors and auditors also need evidence of operation. A useful access-control evidence pack can be organised around five questions.

1. What should happen?

Retain approved identity-management, access-control, authentication, privileged-access, SoD, physical-access and retention policies. Show scope, owners, effective dates, review history and the link to ICT risk and asset classification.

2. Why was access granted?

For a sample of high-risk access, retain the request, business purpose, system and entitlement, approver, policy evaluation, SoD result, effective period and fulfilment result. Emergency access should show why the emergency path was justified.

3. What changed?

Preserve authoritative joiner, mover and leaver events and the resulting account actions. The record should distinguish requested, approved, attempted, completed and reconciled states. Failed fulfilment should open an owned exception rather than disappear into a technical log.

4. Was access reviewed?

Retain campaign scope, reviewer identity, context shown, decision, timestamp, escalation, removal action and completion evidence. Be able to prove the six-month population for systems supporting critical or important functions and the annual population for other ICT systems.

5. Did the control work?

Use reconciliations, target-system samples, overdue-action metrics, orphan detection, dormant privileged-account reporting and tests of termination scenarios. Demonstrate correction of failed or late actions.

A 90-day access-control improvement plan

The following sequence creates useful evidence without pretending that governance can be completed through a one-time certification.

Days 1 to 30: define and discover. Confirm the applicable DORA provisions. Identify critical or important functions and supporting ICT assets. Map authoritative identity sources, privileged stores, third-party access and non-human identities. Approve owners and risk-based revocation service levels. Document known coverage gaps.

Days 31 to 60: control and connect. Establish a consistent request and approval record. Connect the highest-risk systems to lifecycle events. Implement time-bound privileged access where feasible. Define SoD rules for material conflicts. Configure review populations and escalation. Ensure terminated identities cannot retain active sessions or alternative local accounts.

Days 61 to 90: prove and improve. Run one end-to-end leaver test, one privileged-access sample and one review campaign for a critical population. Reconcile target results. Measure late revocations, failed fulfilment, orphaned accounts and unresolved review decisions. Present exceptions and remediation dates to the accountable ICT risk owner.

Common mistakes that create false assurance

“MFA makes the account compliant.” Strong authentication protects how an identity signs in. It does not prove that the identity should have the account or rights.

“Our directory is disabled, so access is gone.” Local accounts, application sessions, tokens, service identities and physical access may remain.

“The manager approved the spreadsheet.” Approval without accurate entitlement context and completed fulfilment is weak evidence.

“The vendor owns its users.” The vendor may administer accounts, but the financial entity still needs governance over access to its assets and information.

“Annual review means annual cleanup.” Event-driven changes and the six-month requirement for systems supporting critical or important functions make that interpretation unsafe.

“DORA requires this product.” DORA and the delegated regulation describe outcomes, policies and controls. Technology should be selected because it reliably delivers those outcomes for the entity’s scale and risk.

Questions management should ask

1. Which ICT systems support our critical or important functions, and can we prove their six-month access reviews?
2. Can every privileged action be tied to an identifiable person and an approved need?
3. How many active accounts lack a current person, system purpose or accountable owner?
4. What is our measured time from an authoritative termination event to verified revocation in every critical target?
5. Which important applications remain outside automated identity lifecycle management, and why is that still proportionate?
6. Can we reconstruct one access decision from request through approval, policy evaluation, fulfilment, review and removal?
7. Which third-party and non-human identities would remain active if their current sponsor left today?

Clear answers turn access control from a collection of settings into an operational resilience capability. That is the standard DORA makes relevant: documented governance, proportionate control and evidence that the control works across the ICT estate.

Confirm the product scope before choosing a platform

Compare the easyIGA evidence coverage with the records your control requires. easyIGA retains captured approval stages and identifies access granted elsewhere; missing historical records remain explicit. Decision-time policy-conflict checks are available, while rule authoring and simulation in easyIGA are planned. Our team’s 14+ midPoint implementations provide delivery experience for scoping and operating these processes.

Continue with the implementation

For the implementation detail behind account removal, use the employee offboarding playbook. For the broader category and selection criteria, read the IGA guide.

Sources and verification record

Product scope and editorial wording updated on 24 September 2026. The original source-check dates below remain the dates of those checks.

All sources and the image licence were checked on 12 September 2026.

1. Regulation (EU) 2022/2554 on digital operational resilience for the financial sector, EUR-Lex
2. Commission Delegated Regulation (EU) 2024/1774, EUR-Lex
3. Consolidated Delegated Regulation 2024/1774, EUR-Lex
4. DORA register-of-information preparation, European Banking Authority
5. Harmonised DORA incident reporting applies from 17 January 2025, European Banking Authority
6. Photo by Jakub Żerdzicki, Unsplash, free to use under the Unsplash License

This article provides operational guidance and a reading of the cited EU texts. It is not legal advice. Confirm applicability and national supervisory expectations with qualified legal and compliance advisers.