TL;DR: DORA creates a single EU cyber resilience framework for financial entities and their critical third-party ICT providers, with 24-hour, 72-hour, and 30-day incident reporting expectations plus mandatory resilience testing, according to Expel. The practical shift is from ad hoc security oversight to documented, auditable operational resilience across the supplier chain.
At a glance
What this is: DORA turns third-party ICT risk into a compliance obligation for EU financial entities and the suppliers that support them.
Why it matters: It matters because IAM, PAM and third-party access programmes now have to prove governed lifecycle control, not just rely on security assurances from vendors or service partners.
By the numbers:
- Financial entities are expected to notify relevant authorities within 24 hours of detecting a significant incident.
- They must share an intermediate report within 72 hours on impact and planned recovery measures.
- The final report is due within 30 days and must include root cause analysis, learnings and resolution.
- Non-compliant insurance brokers could be fined up to 2% of their annual global turnover.
Context
DORA is a European Union resilience regulation for financial entities and the third-party ICT providers that support them. The governance gap it addresses is familiar across identity and access programmes: organisations often know their direct systems better than the suppliers, service partners and outsourced platforms that can still affect operational resilience.
For IAM and third-party access teams, the practical issue is not just cyber hygiene but evidencing control over external access, reporting readiness and contractual obligations. That makes supplier oversight, access governance and incident accountability part of the same compliance chain, especially where outsourced services can affect financial operations.
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: Why does DORA make supplier risk a regulatory issue instead of just a security issue?
A: Because a supplier can now affect whether a regulated firm can detect, report and recover from an ICT incident on time. DORA ties operational resilience to contractual and evidential control, so supplier failures can become compliance failures for the financial entity as well.
Q: Where do financial organisations most often fall short on third-party resilience?
A: They usually have supplier lists and contracts, but weak evidence of control execution. The common gaps are incomplete access inventories, poor incident timestamping, and unclear ownership for escalation, revocation and recovery when a third party is involved.
Q: Which is harder under DORA, passing a questionnaire or proving recovery readiness?
A: Proving recovery readiness is harder, and regulators will care more about it. A questionnaire may show intent, but DORA expects practical evidence that access can be controlled, incidents can be reported on time, and recovery steps can be executed across the supplier chain.
Technical breakdown
How DORA expands third-party ICT governance
DORA extends resilience obligations beyond the regulated financial entity to critical ICT providers such as cloud, software, data centre and hosting suppliers. That matters because the regulation treats the supply chain as part of the control surface, not as an external dependency outside audit scope. In practice, third-party risk management has to move from periodic assurance checks to documented expectations, testing, incident notification and contractually enforced obligations. Where access paths, logs or recovery responsibilities cross organisational boundaries, governance has to be explicit rather than assumed.
Practical implication: Map all material third-party ICT relationships to clear contractual and operational control ownership.
Why incident reporting becomes a control discipline
DORA’s reporting model turns incident handling into a timed governance process rather than an ad hoc response. A firm must classify significant ICT incidents, notify authorities quickly, then follow with impact and recovery updates before final root-cause closure. That changes the design of logging, triage, escalation and evidence collection because the organisation must be able to prove when detection occurred, what changed, and how recovery was coordinated. For identity teams, this also means third-party access events and privileged actions need to be attributable and retrievable under pressure.
Practical implication: Build incident workflows that preserve timestamps, attribution and recovery evidence from first detection onward.
What resilience testing means for suppliers and access paths
DORA makes resilience testing mandatory for the most critical entities, including threat-led penetration testing for high-priority environments. The point is to validate how controls behave under realistic attack conditions, not just whether policies exist on paper. In identity-heavy environments, the most meaningful tests examine delegated access, dormant accounts, privilege escalation paths and service-provider dependencies. A supplier can satisfy contractual language and still fail operationally if access revocation, monitoring or recovery processes are weak. The test is therefore as much about governance execution as technical vulnerability.
Practical implication: Test third-party access, recovery and escalation paths as part of resilience validation.
Threat narrative
Attacker objective: The objective is to exploit weak third-party governance to increase operational disruption and complicate regulatory response.
- Entry occurs through a third-party ICT service path that supports a regulated financial environment.
- Escalation follows when supplier oversight, access control or monitoring is insufficient to constrain the operational impact.
- Impact is expressed as delayed recovery, incomplete incident visibility or regulatory non-compliance across the financial entity and its suppliers.
Breaches seen in the wild
- Salesloft OAuth token breach: hackers stole OAuth tokens to access Salesforce data via Salesloft.
- Klue OAuth Supply Chain Breach: OAuth tokens compromised in Klue integration breach affecting 700+ organisations via Salesforce data access chain.
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 turns third-party access into a governed control domain, not a procurement afterthought. The article is clear that third-party ICT providers are inside the compliance perimeter, which means access, monitoring and recovery responsibilities have to be contractually and operationally defined. That is especially relevant to IAM and PAM programmes, where external accounts often exist without the same lifecycle rigour as internal access. Practitioners should treat supplier access as a controlled part of the resilience model.
Third-party resilience debt: is the gap between supplier assurances and evidence of recoverable control. Many organisations can describe their critical suppliers but cannot yet prove how those suppliers would support rapid incident reporting, recovery coordination or access revocation under stress. DORA exposes that gap directly. The practical conclusion is that governance must shift from trust in vendor statements to proof of control execution.
DORA validates the move from periodic third-party review to continuous third-party accountability. Annual questionnaires and contract templates are not enough when regulators expect tight timelines and auditable resilience outcomes. For identity programmes, that means supplier onboarding, privileged access review and offboarding need the same discipline as internal access governance. The practitioner lesson is to align external access governance with incident and recovery obligations, not keep them in separate silos.
The regulation will likely push identity teams to become evidence producers for resilience, not just access administrators. In a DORA context, proving who had access, when it was used, and how it was revoked becomes part of regulatory readiness. That raises the bar for logging, entitlement tracking and third-party oversight. Teams that cannot produce this evidence quickly will struggle to show operational resilience in a supervisory review.
From our research library:
- 92% of organisations expose NHIs to third parties, raising concerns about supply chain security, according to the Ultimate Guide to NHIs.
- Read next: Third-Party, B2B and Contractor Access Guide
What this signals
Third-party access governance is now part of operational resilience, not a separate vendor-management workstream. Financial teams should expect identity, incident response and legal contract owners to share responsibility for supplier oversight. Where privileged access or hosted services support regulated processes, the evidence burden moves from “we trust the vendor” to “we can prove control.”
Supplier accountability debt: the hidden risk is not whether a third party has controls, but whether the regulated firm can show those controls are enforceable when an incident occurs. That means access review cadence, logging, notification clauses and offboarding proof all need to be testable. If the control cannot be evidenced quickly, it is not resilient enough for DORA.
Identity teams should prepare for more frequent questions about who can access critical systems outside the organisation, how quickly that access can be removed, and what evidence exists after a major incident. The practical change is to treat external identities and supplier dependencies as part of the same resilience narrative.
For practitioners
- Strengthen third-party access inventories Document every external ICT supplier, the access paths it uses, and the business service it supports. Tie each supplier to an owner who can evidence oversight, incident escalation and offboarding decisions.
- Align incident reporting playbooks to DORA timelines Map detection, triage, intermediate reporting and final root-cause closure into one workflow so the team can meet 24-hour, 72-hour and 30-day obligations without reconstructing events after the fact.
- Test supplier recovery and access revocation Include critical third parties in tabletop exercises and resilience tests that validate whether privileged access can be removed, monitored and evidenced during an incident.
- Update contracts for evidence and accountability Require suppliers to support audit trails, notification timing, recovery participation and control attestation so contractual language matches the operational expectations of DORA.
Key takeaways
- DORA makes third-party ICT oversight a regulated responsibility for financial entities, which pushes supplier access and incident accountability into the same control chain.
- The compliance burden is not only policy design. It is the ability to evidence detection, reporting and recovery across external providers within strict timelines.
- Identity and access teams should treat third-party access inventories, offboarding and incident workflows as resilience controls, not administrative tasks.
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 NIST SP 800-53 Rev 5 set the technical controls, and DORA and ISO/IEC 27001:2022 define the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| DORA | Art. 11 — ICT third-party risk | DORA is the regulation at the centre of the article's third-party ICT governance obligations. |
| Recommendation — Map critical suppliers to DORA ICT third-party obligations and document enforceable resilience responsibilities. | ||
| NIST CSF 2.0 | GV.SC-01 — Cybersecurity Supply Chain Risk Management | The article focuses on supply-chain oversight, contractual control and third-party resilience. |
| RS.CO-02 — Coordination with Stakeholders | DORA incident reporting depends on timely coordination across internal teams and external parties. | |
| Recommendation — Apply GV.SC-01 to formalise supplier risk reviews, evidence requirements and control ownership. Use RS.CO-02 to coordinate incident communications and reporting with regulators and suppliers. | ||
| NIST SP 800-53 Rev 5 | SA-9 — External System Services | The article is about managing risk from external ICT services that support regulated operations. |
| Recommendation — Apply SA-9 to define, monitor and enforce controls for external system services. | ||
| ISO/IEC 27001:2022 | A.5.19 — Information security in supplier relationships | Supplier governance and evidence of control execution are central to the article's compliance theme. |
| Recommendation — Use A.5.19 to impose security obligations, monitoring and review on third-party relationships. | ||
| MITRE ATT&CK | TA0006;TA0008 — Credential Access; Lateral Movement | Third-party access paths can be abused to reach regulated environments and expand impact. |
| Recommendation — Map supplier access paths to TA0006 and TA0008 to spot credential abuse and downstream movement. | ||
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.
- Third-Party ICT Risk Oversight: Third-party ICT risk oversight is the practice of governing technology risk introduced by external service providers. It includes due diligence, contractual security requirements, monitoring, testing, and exit planning. The goal is to ensure outsourced services do not undermine resilience, accountability, or recovery during disruption.
- Threat-Led Penetration Testing: Threat-Led Penetration Testing is a security exercise that simulates realistic attacks based on current threat intelligence. It uses adversary tactics, techniques, and procedures to test whether controls, people, and processes can detect, resist, and respond to likely attack paths. The goal is to validate real-world resilience, not just compliance.
- 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 security and identity practitioners connect access control to operational resilience in real programmes.
Published by the NHIMG editorial team on August 20, 2026.
Updated on October 12, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org