DORA turns third-party cyber risk into a compliance requirement

At a glance

What this is: This is an Expel analysis of DORA, the EU’s financial-sector resilience regulation, and its main compliance pillars for firms and critical third-party ICT providers.

Why it matters: It matters to IAM practitioners because DORA pushes identity, access, incident reporting, and third-party governance into a regulated resilience model that affects both direct controls and supplier accountability.

By the numbers:

• Non-compliant insurance brokers could be fined up to 2% of their annual global turnover.
• Entities are generally given 24 hours from detection to notify the relevant authorities.
• 72 hours to share an intermediate report on the impact and planned recovery measures.
• 30 days to file the final report detailing root cause analysis, learnings, and the resolution.

👉 Read Expel's analysis of DORA compliance, third-party ICT risk, and incident reporting

Context

DORA matters because it turns operational resilience from a technical aspiration into a regulated obligation for financial entities and their critical third parties. The first challenge for many programmes is not a lack of tools, but uneven ownership across security, risk, identity, and supplier management. In identity terms, the regulation raises the bar on knowing who and what can access financial systems, how that access is monitored, and how quickly risk can be evidenced when something goes wrong.

For IAM and PAM teams, the practical issue is that resilience now depends on access governance, incident traceability, and third-party lifecycle control as much as on monitoring and response. Where service accounts, privileged access, or supplier credentials are poorly tracked, financial institutions will struggle to demonstrate the control maturity DORA expects. That makes identity evidence part of compliance evidence, not a separate workstream.

Key questions

Q: What breaks when third-party access is not lifecycle managed?

A: Access outlives accountability. When vendor credentials are not tied to a clear offboarding process, old support paths, dormant accounts, and overbroad entitlements remain available after the business need has ended. That creates a standing exposure window that attackers can exploit and auditors will struggle to explain.

Q: Why does DORA make access governance a resilience issue?

A: DORA ties operational resilience to the ability to withstand, respond to, and recover from ICT disruptions. Access governance sits at the centre of that because compromised or poorly managed identities determine how far an incident spreads and how quickly it can be contained. If you cannot answer who had access, resilience claims are weak.

Q: How do financial firms know whether identity controls are strong enough for DORA?

A: Look for evidence, not policy language. Strong controls produce complete identity inventories, current privilege maps, fast revocation, logged third-party access, and incident records that can be reconstructed quickly. If access data is fragmented across tools, the programme is not yet ready for the reporting and resilience expectations DORA creates.

Q: Who is accountable when supplier access is abused in a breach?

A: Accountability sits with the organisation that granted the access and with the supplier governance process that failed to constrain it. If a third-party platform can be abused to expose customer data, then access scope, offboarding, and monitoring were not aligned to the relationship. IAM and third-party risk teams should review supplier access as a lifecycle control, not a one-time approval.

Technical breakdown

DORA’s five pillars map to control domains, not just compliance checklists

DORA is built around ICT risk management, incident reporting, operational resilience testing, third-party ICT risk, and information sharing. These are not isolated obligations. They form a control system that expects firms to understand assets, classify incidents, test response paths, and govern suppliers under the same resilience model. The important architectural point is that resilience is measured across the whole operational stack, including identity, privileged access, and service-provider dependencies.

Practical implication: treat DORA as a control architecture exercise and map each pillar to named owners, evidence sources, and review cycles.

Third-party ICT risk is also an identity problem

The article’s supplier focus matters because critical providers often hold the access paths, credentials, and administrative reach that can bypass local controls. In practice, that means the resilience of a financial entity depends on how third-party access is provisioned, monitored, and removed. If supplier accounts, API tokens, or remote support paths are not lifecycle-governed, the organisation may satisfy a contract on paper while remaining exposed at runtime.

Practical implication: inventory all third-party identities and align their access, logging, and offboarding to the same control standard as internal privileged access.

Incident reporting timelines require identity-grade evidence

DORA’s 24-hour, 72-hour, and 30-day reporting expectations force teams to assemble facts quickly: what was accessed, which accounts were involved, what changed, and how containment was achieved. That is difficult if identity telemetry is fragmented across cloud, SaaS, endpoint, and directory systems. The operational issue is not only detection speed, but the ability to reconstruct access pathways confidently enough to support regulatory reporting.

Practical implication: ensure identity logs, privilege records, and supplier access events are centrally queryable before an incident occurs.

NHI Mgmt Group analysis

DORA pushes identity governance into resilience governance. The regulation is not just about cyber controls in the abstract. It makes access visibility, incident traceability, and third-party accountability part of a financial entity’s resilience posture. For identity teams, that means IAM, PAM, and supplier access controls are now evidence-bearing controls, not just operational hygiene.

Third-party access without lifecycle governance becomes a regulatory liability. DORA extends expectations to critical ICT suppliers, which means organisations can no longer separate their own access model from the access model of vendors and intermediaries. If third-party accounts, remote access, and service credentials are not inventory-backed and offboarded consistently, the compliance gap is structural. Practitioners should reframe supplier access as a regulated control surface.

Operational resilience testing only works when the underlying identity data is trustworthy. Threat-led testing, tabletop exercises, and incident rehearsal depend on knowing which identities can move through the environment and which ones can be revoked quickly. Without reliable identity evidence, resilience testing risks becoming a procedural exercise rather than a control validation. The lesson for financial programmes is to connect testing outcomes to entitlement data and access review evidence.

DORA is accelerating convergence between cyber compliance and access governance. Financial firms are being pushed toward a model where access review, incident classification, and supplier assurance are part of the same control narrative. That reinforces the need for cross-functional ownership across IAM, PAM, GRC, and resilience teams. Practitioners should expect audit demands to focus on proof of control effectiveness, not policy existence.

Named concept: compliance-grade access evidence. DORA effectively creates demand for identity data that can survive regulatory scrutiny, not just operational use. That includes who had access, when it was granted, how it was monitored, and how quickly it could be removed. The practitioner conclusion is simple: if access evidence cannot be produced rapidly, the control is not mature enough for regulated resilience.

What this signals

Compliance-grade access evidence is becoming a practical requirement for regulated resilience programmes. As financial firms operationalise DORA, they will need identity data that can support incident reconstruction, third-party assurance, and access removal evidence without manual scrambling. The control question is no longer whether access is documented, but whether the documentation can survive regulatory scrutiny. See also NIST Cybersecurity Framework 2.0 and NIST SP 800-53 Rev 5 Security and Privacy Controls.

Third-party governance will increasingly merge with identity lifecycle management, especially where suppliers hold privileged or persistent access. That means IAM and GRC teams should expect contract language, access review workflows, and offboarding evidence to become more tightly linked. Programmes that still treat supplier access as a procurement issue rather than an identity issue will struggle to prove resilience at audit time.

The practical signal for practitioners is to tighten the loop between identity telemetry, resilience testing, and incident reporting. If tabletop exercises do not test credential revocation, supplier lockout, and privilege traceability, they are not validating the failure modes DORA is trying to reduce.

For practitioners

• Map DORA obligations to identity control owners Assign specific owners for access governance, privileged access, supplier identity oversight, incident evidence, and reporting timelines so each DORA pillar has a named operational accountable party.
• Inventory third-party identities and remote access paths Build a complete register of supplier accounts, API tokens, support channels, and admin access, then require offboarding and monitoring evidence for every one of them.
• Centralise identity telemetry for incident reporting Ensure directory logs, privileged session records, cloud auth events, and SaaS access logs can be queried together so the 24-hour and 72-hour reporting windows are achievable.
• Test containment with identity-centric tabletop exercises Run exercises that force teams to revoke access, disable supplier accounts, and trace privileged activity under time pressure so response plans reflect actual control dependencies.
• Align access reviews to regulated evidence needs Update review workflows so they produce auditable records of entitlement scope, business justification, and removal outcomes for internal and third-party identities alike.

Key takeaways

• DORA makes access governance part of regulated resilience, so identity evidence now matters for compliance as much as for security.
• Third-party ICT access is a major control surface under DORA, especially where supplier credentials and remote support paths persist.
• Financial programmes should connect IAM, PAM, and incident reporting so they can prove control effectiveness under regulatory timelines.

Key terms

• 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.
• Third-Party Cyber Risk: Security exposure introduced by an external vendor, supplier, or service provider that has access to systems, data, or infrastructure. It is not limited to contract risk. In practice, it is the combination of access, trust, and dependency that can be abused if identity and lifecycle controls are weak.
• Identity Telemetry: Identity telemetry is the collection of signals generated by authentication, session, and access events across human and non-human identities. It becomes useful for governance when teams can baseline normal behavior and detect drift in source, privilege, or access frequency.
• Compliance-Grade Access Evidence: Access records that are complete, time-linked, and reliable enough to support audit or regulatory review. This goes beyond routine logging and includes entitlement scope, approval history, usage, and revocation proof. If evidence cannot be produced quickly, the control is operationally weak.

What's in the full article

Expel's full analysis covers the operational detail this post intentionally leaves for the source:

• The regulation’s full list of affected financial entities and third-party ICT providers, including the supply-chain scope that determines who must comply
• The 24-hour, 72-hour, and 30-day incident reporting timelines in context, including what each report must contain
• The five DORA pillars with the practical cyber and governance obligations mapped to each one
• The article’s discussion of contractual supplements and how a third-party provider aligns to DORA requirements

👉 Expel's full article covers the five DORA pillars, reporting timelines, and supplier compliance expectations in more detail.

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 identity and security practitioners connect lifecycle controls to audit, risk, and operational evidence.