Why does DORA create risk for firms that rely on third-party ICT providers?

Why This Matters for Security Teams

DORA changes third-party ICT risk from a procurement issue into a supervisory and operational resilience issue. For financial firms, the question is no longer only whether a supplier is secure enough for business use, but whether the supplier can support incident reporting, resilience testing, contract enforceability, and oversight obligations. That broadens the control perimeter to include service dependencies that often sit outside the security team’s direct administration.

This is why third-party concentration, opaque subcontracting, weak exit arrangements, and poor evidence of control performance become material risks. A vendor can be technically useful and still create regulatory exposure if the firm cannot prove governance over access, availability, logging, or change management. Current guidance suggests that firms need a clear view of how each critical service is delivered, monitored, and recovered, not just who signed the contract.

For practitioners, the practical challenge is that many of the highest-risk dependencies are not obvious infrastructure providers but identity services, orchestration layers, managed security tools, and automation platforms that hold privileged access or secrets. The NIST Cybersecurity Framework 2.0 is useful here because it frames third-party oversight as part of broader governance and risk management, while the DORA — Digital Operational Resilience Act makes the regulatory expectation explicit.

In practice, many security teams encounter vendor risk only after an incident, contract renewal, or audit request has already exposed the missing controls.

How It Works in Practice

Operationally, DORA pushes firms to treat third-party ICT services as part of the resilience architecture. That means mapping which providers support important or critical functions, assigning ownership for each dependency, and maintaining evidence that security and recovery requirements are actually being met. The control objective is not just supplier assurance at onboarding, but continuous oversight across the lifecycle of the service.

A workable implementation usually includes:

• service criticality mapping to identify which providers affect regulated business functions;
• contract clauses for logging, incident notification, audit rights, subcontractor transparency, and exit support;
• periodic control testing for availability, recovery, and change resilience;
• access reviews for privileged and machine-to-machine accounts used by the provider;
• board-level reporting on concentration risk and unresolved supplier findings.

This is also where identity governance becomes important. Providers often authenticate through non-human identities, API keys, service accounts, certificates, and automation tokens. If those credentials are not inventoried, rotated, and monitored, the firm may have no practical way to verify who or what can act inside critical environments. The OWASP Non-Human Identity Top 10 is relevant because it highlights exactly the kinds of credential and trust failures that often sit inside supplier-delivered services. The key point is that contractual accountability must be matched with technical visibility, otherwise the firm is relying on assurances it cannot independently validate.

These controls tend to break down when providers deliver shared, highly abstracted cloud services because the firm cannot easily inspect underlying recovery mechanisms, logging fidelity, or subcontractor dependencies.

Common Variations and Edge Cases

Tighter third-party oversight often increases procurement friction and operating cost, requiring organisations to balance resilience against vendor agility and commercial dependency. That tradeoff becomes sharper when a provider is embedded across multiple business lines or when switching costs are high enough that exit planning is only theoretical.

There is no universal standard for how deep supplier assurance must go in every case. Best practice is evolving, but current guidance suggests a risk-based approach: critical services deserve deeper evidence, more frequent testing, and stronger contractual rights than commodity tools. A low-risk collaboration platform is not assessed the same way as a provider that hosts customer-facing payments, authentication, or recovery tooling.

Edge cases often appear in cloud-native and automation-heavy environments. A supplier may not hold customer data directly, yet still operate privileged workflows, deploy code, manage secrets, or trigger service changes through API access. In those cases, the real risk is often hidden in non-human identities rather than human administrator accounts. That is why firms should review not only supplier reports and attestations, but also how provider accounts are created, scoped, monitored, and revoked across production environments.

The main failure mode is assuming that a strong annual assurance pack is enough. DORA risk usually emerges when a firm discovers too late that resilience evidence, audit rights, and access governance were never operationalised in the first place.

Related resources from NHI Mgmt Group

• Why do third-party ICT dependencies create the biggest operational resilience risk under DORA?
• Why do third-party credentials create DORA compliance risk?
• Why do third-party access paths create DORA risk?
• Why does third-party access create so much regulatory risk under DORA and NIS2?