Dora compliance shifts third-party risk into financial resilience governance

At a glance

What this is: DORA extends operational resilience governance to ICT third parties, fourth parties, and related evidence and reporting obligations across the financial sector.

Why it matters: It matters because IAM, PAM, and NHI-adjacent teams often sit inside the control chain for third-party access, account lifecycles, and audit evidence needed to prove resilience.

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.

👉 Read OneTrust's analysis of DORA compliance and third-party risk

Context

DORA moves ICT risk from a general security concern into a regulated resilience obligation for financial entities and their extended service ecosystems. The primary issue is not just compliance paperwork, but whether organisations can evidence control over third-party access, information registers, and incident handling across the full supply chain.

For IAM and NHI practitioners, that shifts the focus to the identity layer inside third-party risk management. Service accounts, API keys, and delegated access paths become part of operational resilience because unmanaged credentials and weak offboarding can undermine the evidence chain that DORA expects.

This is not a niche financial-services issue confined to banks alone. The article reflects a broader pattern in which regulatory resilience requirements increasingly depend on identity governance, lifecycle discipline, and auditable third-party access controls.

Key questions

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. If third-party accounts, service keys, and delegated access are not lifecycle-managed, the organisation can no longer prove who had access, when it changed, or whether revocation actually happened.

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. In those cases, vendor governance alone is too coarse. The programme needs access inventories, revocation triggers, and auditable evidence at the identity layer.

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. Questionnaires can document intent, but they do not reveal whether API keys still work, service accounts remain privileged, or subcontractors inherit access after a change in scope.

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.

Technical breakdown

How DORA turns third-party access into a resilience problem

DORA does not treat third-party risk as a procurement checkbox. It folds ICT suppliers, subcontractors, and connected services into the financial entity’s own operational resilience obligations. That means access governance, contractual controls, and evidence collection must extend across the service relationship, not stop at the initial due diligence review. In practice, the most fragile point is often the identity plane: who can authenticate, what privileges persist, and how quickly access can be revoked when the relationship changes.

Practical implication: map every external access path to an owner, a lifecycle step, and a revocation trigger.

Why information registers matter for identity governance

The register of information is not just a documentation task. It becomes the authoritative record for which external services support critical or important functions, what data they touch, and where operational dependencies sit. For identity teams, that record should connect to human and non-human access, including service accounts, API keys, tokens, and delegated administrative roles. Without that linkage, the register may look complete while the actual access estate remains invisible.

Practical implication: tie third-party registers to actual account inventories and access reviews, not static vendor lists.

Evidence-ready control design for audits and incident reporting

DORA’s annual review and audit expectations mean control design has to produce evidence, not just intent. That includes access logs, risk assessments, renewal decisions, offboarding records, and documented exception handling. Where third parties use non-human identities, the evidence burden is higher because credentials can outlive business need, spread across tools, or remain valid after a service change. Auditability therefore depends on lifecycle discipline, not on after-the-fact explanation.

Practical implication: design controls so audit evidence is generated as part of normal access governance workflows.

NHI Mgmt Group analysis

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.

The named concept here is third-party identity spillover: access granted for one relationship often persists into adjacent systems, subcontractors, or service layers after the original business need has changed. That spillover creates audit gaps because the paperwork may show a terminated contract while the credential remains active elsewhere. The governance lesson is that lifecycle offboarding must follow the access path, not the procurement record.

DORA validates continuous evidence collection over periodic attestation. Annual reviews and formal registers are necessary, but they are not sufficient if access states change weekly or daily. The control question is whether the organisation can prove who had access, when it changed, and who approved it across all fourth-party dependencies. Practitioners should align resilience reporting with live identity telemetry.

Identity, third-party risk, and resilience teams need a shared control model. The article shows why isolated ownership fails when third-party dependencies span security, legal, procurement, and IT. A segmented programme can document risk without actually constraining access. The practical conclusion is that control ownership must cross those silos if the organisation wants evidence it can defend to regulators.

DORA is a signal that regulators now expect machine-readable governance, not narrative assurances. The more distributed the ecosystem becomes, the less value there is in static attestations that cannot be reconciled with actual access and service dependency data. For identity programmes, this points toward lifecycle automation, inventory accuracy, and audit-grade evidence generation as baseline capabilities.

What this signals

DORA will push many organisations toward tighter joins between third-party risk platforms, identity inventories, and audit evidence stores. The practical pressure point is lifecycle accuracy: if access removal, privilege change, or supplier termination cannot be reconciled quickly, resilience reporting becomes fragile.

Third-party identity spillover: the next control challenge is not just external access, but the persistence of that access across subcontractors, tokens, and inherited service pathways. Teams that can already trace service accounts and API keys across suppliers will be better placed to meet both operational and regulatory demands.

The broader market signal is that resilience programmes are becoming identity-dependent. That creates a stronger case for linking third-party risk processes to the NHI Lifecycle Management Guide and external control references such as the NIST Cybersecurity Framework 2.0, especially where access governance must be evidenced rather than asserted.

For practitioners

• 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.
• Generate audit evidence from normal workflows Design access reviews, risk assessments, and exception approvals so logs and approvals are created automatically during the workflow instead of reconstructed for the audit season.

Key takeaways

• DORA turns external access into a regulated resilience control, which places identity governance at the centre of third-party oversight.
• The evidence problem is real: without linked inventories, revocation records, and audit trails, organisations cannot prove that supplier access was actually controlled.
• Practitioners should align third-party registers, account inventories, and lifecycle offboarding so resilience reporting reflects live access, not static documentation.

Key terms

• Digital Operational Resilience Act: DORA is an EU regulatory framework that requires financial entities and their critical ICT providers to prove they can withstand, respond to, and recover from disruption. For identity teams, it turns authentication, access, and recovery into evidence-bearing controls rather than background IT functions.
• Fourth-party risk: Fourth-party risk is the exposure created by a vendor’s own vendors, sub-processors, and downstream service dependencies. It matters because direct contractual control usually stops at the first tier, while operational and data-risk propagation often continues much further through the chain.
• Register Of Information: A Register of Information is the live record a regulated organisation uses to describe its assets, dependencies, and controls. Under DORA, its value depends on accuracy, completeness, and the ability to reflect changes in the operating environment rather than storing a stale compliance snapshot.
• Third-Party Identity: An identity issued to a partner, vendor, contractor, or external service that can access internal systems. These identities often sit outside normal employee governance and can become persistent trust paths if they are not reviewed, expired, and revoked on schedule.

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.

👉 The full OneTrust article covers its DORA workflow, evidence mapping, and compliance tooling in more detail.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, identity lifecycle, and secrets management for practitioners building auditable access controls. It helps security and identity teams connect lifecycle discipline to the broader programmes they already run.