Banks should treat DORA implementation as an operational resilience programme that includes identity scope, runtime logging, least privilege, and supplier access. The regulatory expectation is not a document set alone. It is evidence that identity can be governed continuously across internal and external boundaries.
Why DORA Readiness Has to Include Identity Governance
DORA readiness is often framed as a resilience and documentation exercise, but the ECB’s expectation is operational: banks must prove they can control access, logging, and third-party connections continuously. That makes identity governance part of the control plane, not a separate IAM workstream. If identities, entitlements, and supplier access are not governed in a live state, the DORA programme will look complete on paper and weak in practice.
For banks, the practical implication is that identity scope has to extend across internal staff, administrators, applications, service accounts, and outsourced providers. The control question is not only who has access, but whether access can be evidenced, reviewed, and withdrawn fast enough to support resilience obligations. That is why identity governance belongs in the same operating rhythm as incident response, logging, and third-party oversight.
The same logic applies to access boundaries and lifecycle control. If role design is unstable, entitlements are overbroad, or suppliers retain stale connectivity, the institution cannot demonstrate durable control over the systems DORA depends on. A useful starting point is the Identity Security Regulatory Map, which connects identity controls to DORA and other regulatory regimes, and the IAM and IGA Basics guide, which anchors the difference between access administration and governance.
What ECB-Grade Evidence Looks Like for Access, Logging, and Suppliers
Under an ECB-style readiness expectation, banks need evidence that identity governance is operational, not static. That means showing joiner-mover-leaver controls, privileged access review, supplier access approval and expiry, and logging that ties actions back to accountable identities. The evidence should demonstrate that access is both limited and observable across production, support, and shared-service environments.
Runtime logging matters because access governance is only convincing when access use can be traced after the fact. Logs should support investigations into who accessed what, from where, under what authority, and whether the access was appropriate for the function performed. Without that traceability, least privilege is difficult to prove and supplier access cannot be risk-ranked properly.
Supplier access is especially important because it often bypasses normal employee lifecycle controls. Banks should treat third-party connectivity as governed access with explicit owners, expiry, and review evidence rather than as a permanent exception. The Financial Services Identity Security Guide is useful here because it places DORA, privileged access, and third-party exposure in the banking context, while the Access Reviews and Certification Guide shows how to make reviews produce actual removals instead of rubber-stamped approvals.
Operational resilience evidence should also cover offboarding and dormant-access cleanup. If a bank can show that orphaned access is detected, privileged roles are revalidated, and external accounts are time-bounded, the identity layer becomes part of the DORA evidence trail rather than a gap the assessor has to infer. The NHI Lifecycle Management Guide and Joiner-Mover-Leaver (JML) Guide both reinforce the lifecycle discipline needed for this kind of evidence.
How to Organise DORA and Identity Governance as One Programme
The cleanest operating model is to treat DORA implementation as the umbrella programme and identity governance as one of its control domains, with shared metrics and shared ownership. That avoids the common failure mode where resilience teams document requirements while identity teams run access administration in isolation. The bank then ends up with two partly aligned programmes and no single view of whether access is actually under control.
Practically, this means the bank should align control owners around a few measurable outcomes: privileged access recertification is current, supplier access has expiry and sponsorship, logging covers sensitive identity events, and emergency access is governed through exception handling. The role of IGA is to make these controls repeatable at scale, not to create another policy layer. The IGA Buyer’s Guide and Role Mining and Role Design Guide are relevant because poor role structure is one of the fastest ways for readiness to drift into excessive access and review fatigue.
For banks with heavy outsourcing or shared platforms, the governance question is whether access decisions are still intelligible when the service model changes. If a supplier, platform team, or managed service can grant or retain access outside the bank’s normal review cycle, that is a resilience issue, not just an IAM issue. The operating model should therefore tie access review cadence, logging, and supplier oversight into the same control calendar.
Risk and Threat Considerations
When identity governance is treated as a documentation exercise, the main risk is that hidden access paths remain available long after the bank believes DORA readiness is complete. Stale supplier accounts, excessive privileges, and weak logging create a control gap that can be exploited during an incident, or simply become the reason the bank cannot contain one quickly.
Failure mechanism: Access is approved once but not continuously governed, so entitlement drift, dormant accounts, or unmanaged third-party connections accumulate outside the bank’s live control cycle.
Impact: The bank loses confidence in who can act in production, which weakens incident containment, complicates root-cause analysis, and creates assessor-visible evidence gaps under DORA.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5, NIST CSF 2.0 and CSA Cloud Controls Matrix set the technical controls, while ISO/IEC 27001:2022 and DORA define the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | AC-6 — Least Privilege | DORA readiness depends on limiting access to what each identity needs. |
| AU-2 — Event Logging | The question requires runtime logging to evidence governed access. | |
| IA-5 — Authenticator Management | Supplier and internal access rely on controlled credential lifecycle and revocation. | |
| Recommendation — Enforce least privilege for staff, service, and supplier access paths. Log identity and access events needed to prove controlled operations. Manage credentials so access can be revoked, rotated, and evidenced. | ||
| ISO/IEC 27001:2022 | A.5.15 — Access control | Banks need governed access boundaries as part of resilience readiness. |
| A.5.18 — Access rights | Identity governance hinges on reviewable and revocable access rights. | |
| A.5.23 — Information security for use of cloud services | Supplier access and outsourced services are central to DORA readiness. | |
| Recommendation — Define and enforce access control rules for internal and third-party users. Review, adjust, and remove access rights on a controlled schedule. Apply security controls to third-party and cloud-connected access paths. | ||
| NIST CSF 2.0 | PR.AA-05 — Least Privilege Access Permissions and Separation of Duties | The answer is about controlling entitlement scope across roles and suppliers. |
| DE.CM-09 — Monitoring for Unauthorized Personnel, Connections, Devices, Software and Code | Runtime logging and supplier oversight require continuous monitoring. | |
| Recommendation — Limit permissions and separate duties for sensitive identities. Monitor identity-related connections and alert on unauthorized access paths. | ||
| DORA | Digital Operational Resilience Act | The question is specifically about aligning bank readiness with ECB DORA expectations. |
| Recommendation — Tie identity governance evidence to resilience, incident, and third-party controls. | ||
| CSA Cloud Controls Matrix | IAM — Identity & Access Management | Cloud and outsourced banking services need governed access across boundaries. |
| Recommendation — Apply IAM controls to provision, review, and revoke access consistently. | ||
Practitioner Guidance
What to prioritise: Start with privileged users, service accounts, and supplier access before broadening to the full workforce. Those populations create the highest resilience and audit exposure because they can bypass ordinary user controls and are most likely to remain active across boundary changes.
What to verify: Confirm that every sensitive access path has an accountable owner, a review date, and logs that can explain the action after the fact. If any of those three are missing, the control is not yet evidence-grade for DORA purposes.
Practitioner takeaway: The right test is not whether the bank has an identity policy set, but whether it can prove access stays bounded, reviewable, and revocable while the business keeps operating.