DORA · Identity and access management # Make access control part of operational resilience. DORA has applied since 17 January 2025. For financial entities, identity records, access rights and evidence of revocation belong in the ICT risk-management framework. [Read the detailed DORA guide](https://easyiga.com/blog/dora-and-access-control) [Explore access evidence](https://easyiga.com/demo) ## Start with the applicable framework [Regulation (EU) 2022/2554](https://eur-lex.europa.eu/eli/reg/2022/2554/oj/eng) defines its entity categories and exclusions in Article 2. Article 4 establishes proportionality. Certain entities fall under the simplified ICT risk-management framework in Article 16. Do not assume every financial organisation has the same obligations or that small size automatically removes them. DORA is directly applicable. That does not remove the need to identify your competent authority or check related national supervisory and enforcement provisions. Critical ICT third-party providers also have a distinct oversight framework; they should not be described as if they were simply another financial-entity category. ## What Article 9(4)(c) means for access Access to ICT assets must be limited to what legitimate and approved functions require. Financial entities must establish policies, procedures and controls for access rights and sound account management. The accompanying [Delegated Regulation (EU) 2024/1774](https://eur-lex.europa.eu/eli/reg_del/2024/1774/oj/eng) provides further identity-management and access-control requirements in Articles 20 and 21 for the framework to which those provisions apply. Governance evidence should connect a person or system identity to its accounts, approvals, current rights and lifecycle changes. It must distinguish a workflow decision from the result in the target system. ## Important distinction The full-framework access-rights requirements include updates when necessary and at least annually for other ICT systems, and at least every six months for systems supporting critical or important functions. Classify the supported function. A schedule based only on whether an account is privileged can miss that distinction. Apply the rules of the framework relevant to your entity. ## A control map your team can test Selected requirements from Delegated Regulation 2024/1774, Articles 20 to 21; not a complete DORA assessment. | Area | Requirement to address | Example evidence | Identity lifecycle | Manage identity and account lifecycles, including creation, change, review, temporary deactivation and termination. | Identity-to-account mapping, responsible owner and dated lifecycle records. | Least privilege and separation | Apply need-to-know, need-to-use and least privilege; manage segregation of duties and accountability. | Role definitions, approvals, conflict handling and controlled exceptions. | Access no longer needed | Withdraw rights without undue delay on termination or when no longer necessary. | Departure or role-change event, revocation result and unresolved exceptions. | Review and update | Update rights when necessary; respect the annual / six-month minimum distinction for the full framework. | System criticality, reviewed scope, decisions, follow-up and completion. | Strong authentication | Address remote, privileged and specified critical or exposed access under Article 21(f). | IdP and application configuration, enforced methods and tested coverage. ## Test outcomes, including failures A useful pilot covers more than an approval screen. Select a critical or important function, identify the systems supporting it, and reconcile accounts and rights. Sample a new grant, a role change, a leaver and a privileged account. Confirm the target outcome and record how a failed or unavailable connector is escalated. Keep responsibility for outstanding actions explicit. An export showing that access was approved for removal is not equivalent to evidence that removal succeeded. Similarly, an identity record does not prove every active session, local account or emergency path is controlled. ## Where easyIGA fits, and its limits easyIGA provides a business-facing governance layer over midPoint. Evaluate its requests, reviews, ownership and evidence workflows against your scope and supported connectors. [Evidence records](https://easyiga.com/product/audit-evidence) can support your ICT risk-management process when coverage and data quality have been verified. IGA does not replace a PAM vault, privileged-session controls, incident reporting, resilience testing or ICT third-party risk management. Procurement must also assess [security and processing boundaries](https://easyiga.com/security). No product guarantees compliance or a favourable supervisory finding. ## Primary sources - [EUR-Lex: DORA, Articles 2, 4, 9, 16 and 64](https://eur-lex.europa.eu/eli/reg/2022/2554/oj/eng) - [EUR-Lex: Delegated Regulation 2024/1774, Articles 20 to 21 and simplified framework provisions](https://eur-lex.europa.eu/eli/reg_del/2024/1774/oj/eng) Source review: 12 September 2026. Read the [full guide](https://easyiga.com/blog/dora-and-access-control) for a more detailed implementation discussion.