Why do third-party ICT dependencies create the biggest operational resilience risk under DORA?

Third-party ICT dependencies matter because outages, data gaps, or weak contractual controls can interrupt essential services even when internal controls are sound. DORA forces organisations to look beyond their own perimeter and assess vendor criticality, exit plans, and contractual obligations. The main risk is hidden dependency, where a supplier failure becomes a regulatory and business continuity failure.

Why This Matters for Security Teams

Under DORA, third-party ICT dependencies are not just procurement concerns. They are operational resilience risks because a supplier outage, software defect, identity failure, or data-access breakdown can stop a critical business service even when internal systems remain healthy. The practical challenge is that many dependencies are indirect, shared, or hidden inside managed services, cloud platforms, and software supply chains. DORA expects firms to understand these links, classify critical dependencies, and prove that continuity planning exists in more than name only. See also the EU Digital Operational Resilience Act (DORA) and the NIST Cybersecurity Framework 2.0 for the control objectives behind resilience and dependency management.

The biggest mistake is assuming that a well-secured internal environment can absorb a partner failure without service impact. In reality, resilience often collapses at the seams between organisations: authentication, API connectivity, logging, backup access, patch delivery, and support escalation. For NHI-heavy environments, service accounts, tokens, and machine-to-machine credentials can become single points of failure if supplier-controlled secrets are unavailable or poorly governed. In practice, many security teams encounter this only after a supplier incident has already interrupted service, rather than through intentional resilience testing.

How It Works in Practice

Operational resilience under DORA starts with dependency visibility. Organisations need an inventory of third-party ICT providers, the services they support, the business functions they enable, and the specific failure modes that would affect continuity. That includes cloud infrastructure, SaaS platforms, managed security services, outsourced development, and identity or secrets management components. DORA is not satisfied by a vendor list alone; it requires firms to identify critical and important functions, assess concentration risk, and align contractual terms with recoverability expectations.

Practitioners usually build this in layers:

• Map each essential service to underlying ICT providers, sub-processors, and shared utilities.
• Document data flows, authentication paths, support channels, and recovery dependencies.
• Set minimum requirements for availability, incident notification, audit access, and exit support.
• Test exit plans, restoration procedures, and alternative operating models before a disruption occurs.
• Review whether privileged access, API keys, and service tokens are owned, rotated, and revocable by the client, not only by the supplier.

This is where identity governance often becomes a resilience issue. If a third party controls machine identities, certificate renewal, or break-glass access, then recovery may depend on the very provider that has already failed. That is why NHI governance matters alongside contract and architecture reviews, and why controls from sources such as OWASP Non-Human Identity Top 10 are increasingly relevant to DORA implementations. NIST SP 800-53 Rev. 5 also remains useful for mapping continuity, incident response, and supplier controls into a working control set.

These controls tend to break down when service ownership is fragmented across legal entities, regional cloud tenants, and inherited managed services because no single team can evidence end-to-end dependency recovery.

Common Variations and Edge Cases

Tighter third-party oversight often increases operational and legal overhead, requiring organisations to balance resilience assurance against contract complexity and vendor resistance. There is no universal standard for how much testing is enough yet, so current guidance suggests focusing on the dependencies that can materially disrupt critical services rather than treating every supplier equally.

Edge cases usually appear in one of three forms. First, concentration risk: multiple critical services rely on the same cloud, identity, or telecom provider, so a single event has broad impact. Second, fourth-party exposure: a vendor appears stable, but its own upstream dependency fails and the customer has little visibility. Third, exit friction: technical portability exists on paper, but data formats, identity bindings, and integration logic make switching slow or operationally unsafe.

For identity and NHI-heavy environments, the most overlooked edge case is revocation and re-issuance of non-human credentials during a supplier transition. If secrets, certificates, or API tokens are embedded in automation, the exit plan may fail at the exact moment it is needed. Best practice is evolving here, especially for agentic systems and delegated access, but the direction is clear: resilience requires recoverable control of machine identities, not just written assurance from the provider.

Related resources from NHI Mgmt Group

• Why do third-party dependencies create resilience risk for IAM programmes?
• Why does third-party access create so much regulatory risk under DORA and NIS2?
• Why do third-party credentials create DORA compliance risk?
• Why do third-party incidents create identity governance risk as well as operational risk?