The regulated financial entity remains accountable. DORA treats third-party risk as part of the firm’s own operational resilience obligations, even when the issue originates with a vendor, supplier, or open-source dependency. That means the organisation must maintain oversight, document controls, and show that it can detect, assess, and recover from the disruption.
Why This Matters for Security Teams
Under DORA, third-party disruption is not treated as an excuse for weakened resilience. The regulated financial entity still has to prove it understands the dependency, has assessed the impact, and can continue or recover critical operations. That expectation is consistent with NIST Cybersecurity Framework 2.0, which puts governance, risk management, and recovery at the centre of operational security.
The practical challenge is that many firms only map direct suppliers and miss the deeper chain of service providers, managed platforms, identity services, open-source packages, and machine-to-machine dependencies that keep regulated workflows running. When those hidden dependencies fail, the operational impact is often wider than the original contract suggests. DORA’s accountability model means the firm cannot outsource responsibility, even if delivery is outsourced.
This matters especially where identity and access are part of the dependency. Service accounts, API keys, certificates, and other non-human identities can become single points of failure if they are not governed with the same discipline as human access. The OWASP Non-Human Identity Top 10 is useful here because it highlights how unmanaged credentials and weak lifecycle control can turn a supplier incident into a broader control failure. In practice, many security teams encounter the accountability gap only after an outage has already exposed weak supplier visibility, rather than through intentional resilience testing.
How It Works in Practice
In a DORA-aligned operating model, accountability sits with the regulated entity, while responsibility is shared through contracts, control testing, and ongoing oversight. That means procurement, legal, risk, security, and operational resilience functions all need a common view of which services are critical, how failures are detected, and what recovery paths exist.
The operational workflow usually includes dependency classification, exit planning, scenario testing, and evidence collection. For regulated firms, the question is not only whether a vendor has controls, but whether those controls are sufficient for the firm’s own resilience obligations. A service may be external, but its failure still needs to be reflected in business impact analysis, incident response playbooks, and recovery time objectives. NIST’s control catalogue in NIST SP 800-53 Rev 5 Security and Privacy Controls is useful for translating that obligation into specific requirements for contingency planning, monitoring, and supplier oversight.
Practitioners typically need to prove four things:
- Critical services and dependencies have been identified, including sub-processors and shared platforms.
- Supplier performance and security obligations are measured, reviewed, and escalated when thresholds are missed.
- Identity, secrets, and privileged access used by third parties are inventoried and rotated or revoked when required.
- Incident response and recovery exercises include realistic third-party outage scenarios, not only internal system failures.
Identity controls are particularly important when access is mediated through service accounts or federated trust. The NIST SP 800-63 Digital Identity Guidelines help teams think about identity assurance, authentication strength, and lifecycle governance in a way that supports operational resilience. These controls tend to break down when cloud-native dependencies are shared across multiple business units because ownership becomes fragmented and recovery responsibilities are assumed rather than formally assigned.
Common Variations and Edge Cases
Tighter supplier oversight often increases governance overhead, requiring organisations to balance resilience assurance against contract complexity and operational speed. That tradeoff becomes sharper when a firm relies on open-source components, managed SaaS, or group-wide shared services, because the party causing the disruption may not be the party with the most direct contractual relationship.
There is no universal standard for how deep supplier mapping must go, but current guidance suggests financial institutions should go beyond tier-one vendors when a deeper dependency could interrupt regulated operations. That includes cloud hosting layers, identity brokers, observability tools, and CI/CD dependencies that can affect service continuity without appearing in a standard procurement register. Where those components are used to authenticate machines or applications, identity governance becomes part of resilience governance, not a separate topic.
The edge case to watch is where a dependency is technically available but functionally degraded. In those cases, the issue may not trigger a classic outage, yet still prevent transaction processing, customer authentication, or regulatory reporting. DORA accountability still applies because the operational effect, not the fault origin, determines the resilience impact. Firms should therefore test degraded-mode behaviour, manual workarounds, and fallback authentication paths under realistic conditions. The guidance is strongest for regulated financial services, but it becomes less clear in mixed environments where the same dependency supports both regulated and non-regulated workloads.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 address the attack surface, NIST CSF 2.0, NIST SP 800-53 Rev 5 and NIST SP 800-63 set the technical controls, and DORA define the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| DORA | Article 5 | Governance requires firms to own resilience even when third parties fail. |
| NIST CSF 2.0 | GV.RM-01 | Risk management must cover suppliers that can disrupt critical operations. |
| NIST SP 800-53 Rev 5 | CP-2 | Contingency planning is essential when supplier disruption affects regulated workflows. |
| OWASP Non-Human Identity Top 10 | NHI lifecycle and secrets governance | Third-party service accounts and secrets often become the hidden failure point. |
| NIST SP 800-63 | AAL and lifecycle assurance concepts | Federated and service identities need assurance and lifecycle control in resilient operations. |
Assign clear board and management accountability for third-party resilience risk and evidence it in governance records.
Related resources from NHI Mgmt Group
- Who is accountable when a third-party platform outage disrupts academic operations?
- Who is accountable when a third-party service provider mishandles personal data under the Colorado Privacy Act?
- Who is accountable when third-party or service access is still routed through a VPN?
- Who is accountable for AI agent actions under regulated environments like DORA?
