Why does DORA make third-party oversight more demanding?

Why DORA Makes Third-Party Oversight More Demanding

DORA treats outsourced ICT as a regulated dependency, not a procurement detail. That shift matters because the firm still owns the operational risk, even when the technology, support, or access path sits with a provider. The result is more than vendor vetting: it becomes ongoing control over contract terms, service assurance, recovery expectations, and who can touch the environment.

What Changes in Practice When a Provider Runs Part of the Service

The core change is accountability. If a third party can affect availability, integrity, or confidentiality, the regulated firm has to be able to show that the relationship is governed, monitored, and recoverable. That is why DORA pushes firms to define access scope, audit rights, incident cooperation, and exit expectations up front, rather than assuming the provider’s internal controls are enough.

It also changes how oversight works over time. A one-time due diligence review does not capture drift in privileged access, subcontracting, resilience posture, or service dependencies. A better model is continuous oversight of the relationship, including evidence that the provider’s controls still match the risk the firm accepted and that critical access paths remain bounded and reviewable.

For financial entities, this is why DORA turns third-party governance into an operational discipline rather than a legal formality. The demand is not only “is the vendor approved?”, but “can the firm prove it can still operate safely if that vendor fails, degrades, or is compromised?”

Why Contractual Rights, Monitoring, and Recovery Planning Are Central

DORA makes the relationship enforceable. Contracts need to support access to information, cooperation during incidents, testing, and termination or transition when a provider no longer meets the required standard. Without those rights, the firm may know a control is weak but still be unable to verify it, challenge it, or exit safely.

The recovery angle is especially important for critical services. If the outsourced service supports a core business process, the firm must understand recovery time, recovery dependencies, and whether the provider’s own outage assumptions are consistent with the firm’s tolerance. That is a governance issue as much as an operational one, because a weak recovery model can become a firm-level resilience failure even if the provider is technically “secure”.

Third-party access is part of the same problem. Once a supplier, contractor, or managed service provider has a live pathway into the environment, access is no longer a static procurement approval. It needs lifecycle control, including time bounds, revocation, recertification, and evidence that dormant access is removed when the relationship changes. The oversight burden exists precisely because outsourced access can become persistent exposure if nobody owns it.

What Good Oversight Looks Like Under DORA

Good practice is to treat critical ICT providers as part of the control plane, not as external utilities. That means mapping which services are critical, what data and privileges the provider can reach, which subprocessors are involved, and what the firm will inspect on an ongoing basis. It also means making sure business, security, and resilience owners share the same view of the dependency, rather than leaving the relationship entirely to procurement or legal review.

Where the service is truly critical, firms should expect stronger evidence than generic assurances. Independent assurance, incident reporting paths, recovery testing, and termination planning matter because they show whether the provider can support the firm’s resilience obligations in practice. For a useful control baseline on third-party access governance, Third-Party, B2B and Contractor Access Guide frames the access lifecycle issues that sit behind this requirement.

For regulated organisations, DORA also aligns with broader identity and governance expectations. If a provider’s staff, service accounts, or integrations can act inside your environment, then access review, privilege limits, and offboarding are not optional hygiene, they are part of operational resilience. NHIMG’s Identity Security Regulatory Map is useful where teams need to connect those obligations to the wider regulatory picture.

Practitioner Guidance

What to prioritise: Start with the providers that support critical or important functions, then map exactly what each one can access, what recovery commitments they have made, and what evidence you can actually obtain on demand. If you cannot evidence the access path or the recovery path, the oversight model is incomplete.

Decision rule: If a provider can create, change, or restore material production access, treat the relationship as a live control dependency and require lifecycle review, not annual paperwork. If it cannot, keep the review lighter but still verify that subcontracting and exit terms do not quietly expand the risk.

Common mistake: Teams often overfocus on onboarding due diligence and underinvest in ongoing verification. That leaves the firm exposed to control drift, especially when credentials, support channels, or subcontractors change without the contract or the review cadence changing with them.

Practitioner takeaway: DORA raises the bar because resilience is no longer something firms can outsource. The firm must retain enough contractual leverage, monitoring visibility, and access governance to prove the service remains controllable throughout the relationship, not just at signature.

Related resources from NHI Mgmt Group

• Why do third-party dependencies make DORA compliance harder for financial entities?
• Why does weak third-party oversight create outsized DORA risk for banks and other financial entities?
• What should teams do when DORA creates overlapping obligations across internal security, incident reporting, and third-party oversight?
• What are the signs that a third party risk programme is not ready for DORA style oversight?