Why does third-party risk management create so much pressure under DORA?

Why This Matters for Security Teams

DORA turns third-party risk management into an operational discipline rather than a periodic procurement check. Financial entities are expected to understand which ICT services are critical, how dependency chains behave, and what happens if a provider fails during a business-critical process. That pressure lands across security, legal, procurement, resilience, and audit teams at the same time, which is why the work often feels heavier than the headline requirement suggests.

The challenge is not only assessing a vendor once, but maintaining evidence that controls remain effective as services, sub-processors, and integration points change. The NIST Cybersecurity Framework 2.0 is useful here because it reinforces the need to identify, protect, detect, respond, and recover across the full dependency chain, not just inside the organisation’s own network. Under DORA, that broader view matters because a provider’s weakness can become the institution’s outage, compliance gap, or incident-handling failure.

Practitioners also underestimate how often third-party exposure includes identities, credentials, and automation accounts owned by suppliers. If a service account, API key, or privileged integration is poorly governed, the vendor relationship becomes an access-control problem as much as a contractual one. In practice, many security teams encounter the true scale of third-party risk only after a supplier incident has already disrupted operations or exposed a hidden control gap.

How It Works in Practice

Effective DORA-aligned third-party risk management starts by classifying ICT providers according to criticality and mapping each service to the business process it supports. That mapping should include downstream dependencies, not just the direct contract. If a cloud platform, managed service, or SaaS application depends on another provider for hosting, identity, monitoring, or support tooling, the resilience assessment needs to follow that chain.

At a practical level, teams usually need to maintain four layers of control:

• Pre-contract due diligence that checks security posture, resilience commitments, subcontracting, and incident notification capability.
• Contract clauses that define audit rights, service levels, data handling, logging access, and termination support.
• Recurring assurance that reviews control changes, issues, testing outcomes, and material service changes.
• Operational readiness that aligns incident response, business continuity, and recovery objectives with the provider.

This is also where identity governance becomes important. Supplier access should be treated as a governed trust relationship, not a permanent exception. Where vendors use non-human identities, machine accounts, or delegated credentials, control ownership often becomes blurred. The OWASP Non-Human Identity Top 10 is relevant because it highlights recurring weaknesses such as overprivileged secrets, weak rotation, and poor lifecycle control that can magnify third-party exposure.

DORA also expects firms to be able to demonstrate that they can identify, monitor, and exit risky arrangements without losing resilience. That means contingency planning is not optional paperwork; it is part of the control design. These controls tend to break down when providers operate through opaque subcontracting layers and the financial entity lacks evidence of who actually administers critical systems.

Common Variations and Edge Cases

Tighter third-party controls often increase onboarding time, negotiation overhead, and assurance costs, requiring organisations to balance resilience against commercial speed. Current guidance suggests that the strongest programmes focus depth where the business impact is highest, rather than applying identical scrutiny to every supplier.

One common edge case is the shared-responsibility gap. Providers may advertise strong baseline security, but DORA obligations still require the financial entity to understand which controls are inherited and which remain its own responsibility. Another is the fast-changing SaaS environment, where features, sub-processors, and access paths can shift faster than annual review cycles. Best practice is evolving toward continuous monitoring for critical services, but there is no universal standard for exactly how often every control should be revalidated.

There is also a practical tension between broad contractual rights and real enforcement. Some organisations secure strong wording but lack the operational capability to exercise it during an incident. Others inherit resilient providers but fail to connect those assurances to internal incident playbooks, evidence collection, and exit planning. The most effective DORA programmes treat third-party risk as a living resilience model, not a procurement checklist.

Related resources from NHI Mgmt Group

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