TL;DR: DORA makes financial entities accountable for ICT third-party risk across extended networks, with unified requirements for risk management, auditability, and incident reporting ahead of January 2025, according to OneTrust. The practical shift is that resilience governance now depends on inventory, lifecycle oversight, and evidence-ready controls rather than periodic vendor checks.
NHIMG editorial — based on content published by OneTrust: Navigating the Digital Operational Resilience Act (DORA) With OneTrust
By the numbers:
- 92% of organisations expose NHIs to third parties, raising concerns about supply chain security.
- Only 20% have formal processes for offboarding and revoking API keys, and even fewer have procedures for rotating them.
Questions worth separating out
Q: What fails when third-party access is not tied to identity governance under DORA?
A: The control gap is usually not the supplier contract, but the unmanaged credentials and privileges that remain after the business relationship changes.
Q: When should financial entities prioritise DORA controls over broader vendor management processes?
A: They should prioritise DORA controls whenever a third party supports critical or important functions, handles regulated data, or holds authenticated access into production systems.
Q: What do teams get wrong about ICT third-party risk in resilience programmes?
A: A common mistake is treating third-party risk as a questionnaire exercise instead of a runtime access problem.
Practitioner guidance
- Map third-party identities to critical services Create a join between third-party contracts, service accounts, API keys, and the systems they can reach so DORA evidence can show actual access scope, not just supplier names.
- Build lifecycle offboarding into third-party controls Require revocation checks for every external account when a supplier relationship ends, when scope changes, or when a service is decommissioned, and capture the revocation record as audit evidence.
- Synchronise registers with live identity inventories Keep the register of information aligned to real account inventories and access reviews so changes in privileges, ownership, or third-party dependencies appear in the control record quickly.
What's in the full article
OneTrust's full article covers the operational detail this post intentionally leaves for the source:
- A breakdown of how OneTrust positions third-party management, compliance automation, and audit management across the DORA control set.
- Details on the register-of-information workflow and the way the vendor maps evidence tasks to regulatory expectations.
- Examples of pre-mapped policies, controls, and assessment workflows that support implementation planning.
- The article's explanation of how regulatory insights and regional content are packaged for ongoing compliance work.
👉 Read OneTrust's analysis of DORA compliance and third-party risk →
Dora compliance and third-party risk: what should financial teams do now?
Explore further
Third-party resilience is now an identity governance problem as much as a legal one. DORA makes external access part of the regulated control surface, which means the old boundary between vendor management and identity governance is no longer defensible. If third-party accounts, service credentials, and delegated privileges are not owned and reviewed like internal access, the resilience model is incomplete. Practitioners should treat third-party identity governance as core operational resilience work.
A question worth separating out:
Q: Who is accountable when identity controls fail under DORA?
A: Accountability sits with the institution, not just the IAM team. Financial firms must show that identity services, governance processes, and recovery paths were designed and tested as part of operational resilience, because DORA evaluates whether the business can withstand disruption, not whether a tool was installed.
👉 Read our full editorial: Dora compliance shifts third-party risk into financial resilience governance