Who is accountable when a third-party provider fails DORA expectations?

Why This Matters for Security Teams

DORA does not let a financial entity outsource accountability with the service. If a critical provider misses resilience, incident handling, or continuity expectations, the regulated entity still carries the compliance burden, because oversight, evidence, and exit readiness remain part of the operating model. That is why supplier risk is not a procurement issue alone; it is a governance issue tied to operational resilience and board-level responsibility.

This is especially important where providers handle secrets, privileged workflows, or automation that can affect production systems. NHIMG research on The State of Secrets in AppSec found organisations maintain an average of 6 distinct secrets manager instances, which fragments control and makes oversight harder to prove. In practice, many teams discover these gaps only after a supplier issue has already disrupted service or exposed access paths, rather than through deliberate resilience testing.

Current guidance aligns with the broader expectation in the EU Digital Operational Resilience Act (DORA) and the control discipline described in the OWASP Non-Human Identity Top 10, where external dependency does not equal delegated accountability.

How It Works in Practice

In practice, accountability is managed through evidence, not assumptions. The regulated entity needs named owners for each critical outsourcing relationship, contractual controls that support audit and exit rights, and a monitoring model that can detect whether the provider is meeting resilience commitments. DORA expects that oversight to continue for the life of the arrangement, including periodic review of service levels, incident performance, subcontracting, and concentration risk.

For technical teams, this means the third-party provider may operate systems, but the regulated entity must still be able to explain who approved access, how secrets are issued and revoked, how service continuity is tested, and how termination would happen without leaving residual trust behind. That is why identity and credential governance matters here as much as supplier management. If a provider uses shared credentials, long-lived tokens, or opaque automation, the customer may still be accountable for the resulting control failure.

• Maintain a complete inventory of outsourced services, including critical dependencies and subcontractors.
• Define evidence requirements for monitoring, incident reporting, testing, and exit support.
• Validate that access paths, secrets, and privileged automations are reviewable and revocable.
• Test whether the organisation can continue operations or switch providers under stress.

NHIMG analysis of 52 NHI Breaches Analysis shows how quickly identity sprawl and supply chain exposure can translate into real compromise, which is why oversight must include non-human access paths, not only human vendor contacts. These controls tend to break down when the provider’s service is deeply embedded in production, because exit testing and access validation become operationally disruptive and are often deferred.

Common Variations and Edge Cases

Tighter supplier oversight often increases legal, operational, and audit overhead, requiring organisations to balance resilience assurance against delivery speed and commercial constraints. The hard cases are usually not simple outsourcing deals. They involve cloud platforms, managed security services, software supply chain components, or multi-tier subcontracting where the regulated entity has limited direct visibility.

Where the service is highly commoditised, some obligations can be contractually standardised, but current guidance suggests that accountability still stays with the regulated entity if the service is material to resilience. There is no universal standard for this yet on how much technical evidence a provider must expose, so firms should define their own minimums for monitoring, logging, access review, and exit readiness.

This is also where identity risk becomes a board issue. If a third party controls privileged non-human identities, the customer still needs assurance that those identities are bounded, monitored, and revocable. The same applies to agentic or automated workflows that can call APIs on the customer’s behalf. NHIMG research on LLMjacking: How Attackers Hijack AI Using Compromised NHIs shows how quickly exposed credentials can be abused once they leave the intended control plane. The practical takeaway is simple: contracts may allocate duties, but they do not transfer resilience ownership when the service is critical.

Related resources from NHI Mgmt Group

• Who is accountable when a financial institution fails to meet cybersecurity requirements for access control and third-party oversight?
• Who is accountable for protecting patient identity data as it moves between providers and third-party services?
• Who is accountable for reducing SAML exploit exposure across inherited and third-party applications?
• Who should be accountable for third-party non-human identity risk when business tools request elevated access?