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.
At a glance
What this is: OneTrust frames DORA as a unified resilience regime that pulls ICT third-party risk, auditability, and management accountability into the same governance model for financial entities.
Why it matters: For IAM, PAM, and third-party risk teams, the article matters because DORA pushes access, lifecycle, and evidence controls beyond direct vendors into extended service networks that must be governed continuously.
By the numbers:
- DORA is the first regulation to oversee the security functions of financial entities across the European Union, covering 21 distinct types of financial entities.
- DORA goes into force in January 2025.
Context
DORA is best understood as a resilience governance regime, not just a compliance deadline. It pulls information and communication technology risk, third-party oversight, audit evidence, and incident readiness into one operating model for financial entities and their service networks. The core problem is that traditional vendor reviews were never designed to govern nested third-party dependencies at this scale, especially where access and operational dependence extend beyond the first contract layer.
For identity and access teams, the practical significance is that DORA creates a stronger expectation of inventory, lifecycle control, and demonstrable accountability across external relationships. That includes the governance of privileged access, service accounts, and delegated responsibilities used by vendors and downstream providers. In other words, the article is about financial resilience, but the control reality still depends on identity discipline across the extended ecosystem.
Key questions
Q: What breaks when third-party risk is treated as a periodic review under DORA?
A: Periodic review fails because DORA expects continuous accountability across the full ICT dependency chain, including downstream providers and lifecycle changes. If teams only reassess vendors at renewal or annually, they miss access drift, control ownership gaps, and evidence gaps that matter most during audit or incident review. Resilience governance has to operate on change, not calendar cadence.
Q: When should financial teams prioritise DORA evidence over more questionnaires?
A: They should prioritise evidence as soon as the programme needs to prove control effectiveness, not just collect responses. DORA is about demonstrated resilience, so inventory records, access trails, control mappings, and audit artefacts carry more weight than repeated form-filling. Questionnaires still matter, but they are only useful when tied to verifiable operational records.
Q: Where does third-party governance fail in practice under DORA?
A: It fails when organisations stop at direct vendors and ignore the operational dependencies beneath them. DORA’s scope includes third, fourth, and Nth parties, so a narrow supplier view leaves blind spots in access governance, service continuity, and accountability. The practical failure is not lack of policy, but lack of network visibility.
Q: Which regulatory controls matter most for DORA-ready resilience programmes?
A: The controls that matter most are the ones that make risk decisions provable: documented policies, mapped controls, audited evidence, and repeatable lifecycle reviews. DORA is not satisfied by intent alone. Teams need a governance stack that can show how third-party risk is identified, monitored, escalated, and reviewed across the full service chain.
Technical breakdown
How DORA changes third-party risk governance
DORA shifts third-party risk from a procurement or vendor-management concern into a regulated control domain tied to operational resilience. The regulation expects financial entities to understand which ICT services support critical or important functions, maintain a register of information, and evidence due diligence and ongoing assessment. That changes the technical burden from point-in-time reviews to lifecycle governance across onboarding, monitoring, escalation, and offboarding. In practice, the governance model has to account for direct suppliers, sub-processors, and the operational dependencies they introduce.
Practical implication: Map every critical ICT dependency to an owner, an evidence source, and a review cadence that can survive audit scrutiny.
Why inventory and evidence matter more than periodic reviews
DORA makes inventory quality and evidence quality foundational because regulators need to see how risk decisions were made, not just that a questionnaire was completed. A centralised register, tracked touchpoints, and linked controls help demonstrate that the entity can explain who has access, what service is used, and how changes are handled across the relationship lifecycle. This is where identity intersects governance: service accounts, delegated admin paths, and third-party access rights become part of the evidence chain, not a separate technical issue.
Practical implication: Tie third-party registers to access records and audit artefacts so the control story is complete end to end.
What resilience control looks like across extended enterprise risk
Resilience under DORA depends on operationalising risk management across the entire ecosystem, including risk ratings, contracting workflows, mitigation paths, and ongoing monitoring. The technical challenge is that downstream providers can change exposure without changing the primary contract, so controls need to detect relationship drift, not just formal renewal events. That makes lifecycle visibility more important than static approval gates. For IAM and PAM teams, this is the point where third-party access governance, entitlement review, and evidence retention become resilience controls rather than administrative overhead.
Practical implication: Use lifecycle-triggered reviews and access recertification for third-party relationships instead of annual-only checks.
Threat narrative
Attacker objective: Exploit weak oversight in the extended ICT ecosystem to create access, resilience, or compliance failure across financial operations.
- Entry occurs through the extended ICT supply chain, where a financial entity depends on a third-party or fourth-party service that is now inside DORA scope.
- Credential or access exposure can propagate through those dependencies when third parties retain operational access without complete lifecycle oversight.
- Escalation happens when unmanaged downstream relationships create gaps in accountability, audit evidence, or control ownership across the network.
- Impact is regulatory and operational, because the entity can no longer demonstrate resilient oversight of critical or important functions.
Breaches seen in the wild
- BeyondTrust breach 2024: A stolen BeyondTrust Remote Support API key let a China state-sponsored actor reset accounts and reach US Treasury workstations in 2024.
- reviewdog Action compromise 2025: A stolen maintainer token poisoned reviewdog/action-setup, leaking CI secrets including the tj-actions bot token used in the next attack.
Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
DORA is really a governance reset for extended enterprise risk. The article shows that financial entities can no longer treat third-party oversight as a periodic review exercise. Once fourth parties and Nth parties are in scope, the control problem becomes lifecycle visibility across relationships, access paths, and evidence trails. Practitioners should treat third-party governance as part of resilience architecture, not an adjacent compliance task.
Extended-ecosystem accountability: is the named concept this regulation sharpens. DORA makes the hidden dependency chain visible by forcing organisations to account for downstream risk, not only direct suppliers. That matters because the failure mode is often not the first vendor but the untracked service or access path underneath it. The practitioner takeaway is that inventory depth now determines how credible resilience claims really are.
Identity controls become part of resilience evidence under DORA. The article is about operational resilience, but the mechanisms it relies on include who can access what, how third-party access is governed, and whether those decisions can be proved later. That means IAM, PAM, and third-party risk teams have to work from one control narrative rather than separate records. The practical conclusion is that access governance and audit readiness now rise or fall together.
Management-body ownership changes how teams should build the control stack. DORA places responsibility on the financial entity’s management body, which means teams need controls that support board-level assurance, not just operational convenience. Pre-mapped policies, evidence tasks, and audit trails matter because they translate technical risk into governance proof. Practitioners should expect resilience programmes to be judged on demonstrability, not intent.
DORA validates continuous third-party governance as the new baseline for regulated financial services. The article signals that annual review cycles are too slow for networked ICT dependency risk. A continuous model, with monitored relationships and evidence-ready controls, is now the more defensible operating stance. Teams that still run third-party oversight as a point-in-time exercise will struggle to meet the regulation’s accountability standard.
From our research library:
- 52% of respondents see AI security decision-making power shifting toward platform and infrastructure teams rather than the executive suite, according to the 2026 Infrastructure Identity Survey.
- Only 44% of organisations have implemented any policies to manage their AI agents, despite 92% agreeing that governing AI agents is critical to enterprise security, according to the 2026 Infrastructure Identity Survey.
- Read next: Financial Services Identity Security Guide
What this signals
Extended-ecosystem risk is now a resilience problem, not a vendor-management problem. DORA forces financial entities to govern the service chain as an operational dependency tree, which means the programme boundary has to move outward from first-party systems to the access and service layers provided by third parties. For practitioners, that raises the bar on inventory accuracy, offboarding discipline, and evidence capture across the full relationship lifecycle.
Identity governance becomes a supporting control for financial resilience. When third-party access, delegated administration, and service accounts are part of the resilience story, IAM and PAM teams need to provide evidence that controls are current, traceable, and reviewable. The practical shift is toward lifecycle-linked governance, where access is not only granted and revoked, but also continuously explainable to auditors and management.
Extended-ecosystem accountability: teams should expect this concept to show up more often in regulatory and audit conversations. The main implication is that resilience metrics will increasingly depend on whether organisations can prove what sits underneath the contract layer, not just who the signed vendor is.
For practitioners
- Build a complete ICT third-party inventory Map every provider that supports critical or important functions, including downstream dependencies, and assign clear owners for each relationship.
- Connect access governance to third-party records Link vendor access, service accounts, delegated admin paths, and entitlement reviews to the third-party register so evidence is traceable.
- Set lifecycle triggers for evidence collection Trigger due diligence updates, risk re-assessments, and offboarding checks when relationship scope, access, or services change.
- Prepare board-ready resilience evidence Maintain policies, control mappings, and audit artefacts in a form that can support annual review and internal audit without manual reconstruction.
Key takeaways
- DORA reframes third-party oversight as a financial resilience requirement that extends across downstream service relationships.
- The key implementation issue is not whether a vendor has been reviewed, but whether the full dependency chain is inventoried, monitored, and auditable.
- Identity, access, and evidence controls now form part of the resilience case for regulated financial entities.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK addresses the attack surface, NIST CSF 2.0 and CIS Controls v8 set the technical controls, and ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | GV.SC-01 — Cybersecurity Supply Chain Risk Management | DORA governance here is fundamentally about ICT supply-chain and third-party risk. |
| GV.OV-02 — Cybersecurity Oversight | The article stresses management-body oversight, auditability, and documented review. | |
| Recommendation — Apply supply-chain risk governance to third-party dependencies that support critical or important functions. Use board-level oversight to ensure third-party controls are reviewed and evidenced annually. | ||
| CIS Controls v8 | CIS-5 — Account Management | Third-party access, service accounts, and lifecycle tracking are central to the article. |
| Recommendation — Track and review third-party and service accounts throughout their full lifecycle. | ||
| ISO/IEC 27001:2022 | A.5.19 — Information security in supplier relationships | DORA's extended-network focus aligns directly with supplier relationship security governance. |
| Recommendation — Govern supplier relationships with documented security requirements and continuous monitoring. | ||
| MITRE ATT&CK | TA0006;TA0008 — Credential Access; Lateral Movement | The article highlights risk propagation across third parties and downstream access paths. |
| Recommendation — Map downstream access exposure to credential access and lateral movement risks in supplier chains. | ||
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.
- AI Third-Party Risk: AI third-party risk is the exposure created when an organisation relies on external AI tools that process sensitive or regulated information. The concern includes data retention, model training use, access paths, and governance gaps. Security teams should review these tools with the same discipline applied to other vendors handling confidential data.
- 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.
- Operational Resilience: Operational resilience is the ability to keep critical services running or recover them quickly after disruption. In identity-led environments, that depends on authentication services, privilege management, and recovery procedures that can be tested under realistic failure conditions.
Deepen your knowledge
The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, and secrets management. It helps practitioners connect identity control discipline to broader security and compliance programmes.
Published by the NHIMG editorial team on July 11, 2026.
Updated on October 11, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org