Join our Newsletter — 33% off our NHI Course

Notifications
Clear all

DORA and identity visibility: what do financial teams need now?


(@nhi-mgmt-group)
Member Moderator
Joined: 1 year ago
Posts: 19563
Topic starter  

TL;DR: DORA compliance depends on identity security visibility across users, third-party vendors, non-human identities, and AI agent identities, according to Veza, because traditional IAM, IGA, and PAM tools do not expose the authorization detail needed for resilience. That makes granular entitlement mapping a governance requirement, not an operational nice-to-have.

NHIMG editorial — based on content published by Veza: a brief on how identity visibility supports DORA resilience requirements

By the numbers:

Questions worth separating out

Q: How should financial institutions govern privileged access for DORA compliance?

A: They should treat privileged access as part of resilience design, not a separate admin function.

Q: Why do non-human identities make DORA harder to meet?

A: Because service accounts, API keys, certificates, and delegated automation often sit outside the visibility of traditional IAM and PAM reporting.

Q: How should security teams govern third-party access under DORA?

A: They should treat third-party access as a regulated identity path, not an exception.

Practitioner guidance

  • Map effective access, not just entitlements Trace what each identity can actually do across critical systems, including third-party accounts, service identities, and delegated automation paths.
  • Extend lifecycle controls to external and machine identities Require joiner-mover-leaver and offboarding workflows for vendors, service accounts, tokens, and certificates.
  • Test resilience using identity failure scenarios Include dormant accounts, over-privileged vendor access, and broken secrets in incident and recovery exercises.

What's in the full article

Veza's full brief covers the operational detail this post intentionally leaves for the source:

  • How ServiceNow Veza aligns specific identity visibility capabilities to DORA's core pillars.
  • The operational framing for ICT risk management, incident management and reporting, operational resilience testing, and third-party risk management.
  • The brief's positioning on how granular authorization visibility is used to support financial resilience discussions.
  • The source article's summary of the identity security technical debt that sits beneath traditional IAM, IGA, and PAM reporting.

👉 Read Veza's brief on aligning identity visibility with DORA →

DORA and identity visibility: what do financial teams need now?

Explore further

View Full Forum →  |  NHI Foundation Course →



   
Quote
(@mr-nhi)
Member Moderator
Joined: 4 months ago
Posts: 19154
 

Authorization visibility is now a resilience control, not an IAM reporting feature. DORA requires institutions to show control over ICT risk, incident handling, testing, and third-party exposure. If the identity plane cannot reveal effective access, financial organisations are left with incomplete evidence for resilience decisions. Practitioners should treat authorization visibility as part of the control environment, not as a dashboard metric.

A few things that frame the scale:

A question worth separating out:

Q: Who is accountable when identity visibility is too weak to support resilience testing?

A: Accountability sits with the institution that must demonstrate operational resilience, even if access is granted through vendors or automation. Under DORA, teams need evidence that critical identities, permissions, and recovery paths are governed well enough to withstand disruption and audit scrutiny.

👉 Read our full editorial: DORA exposes the identity visibility gap in financial resilience



   
ReplyQuote
Share: