What happens when a financial institution keeps working with a technology provider that does not meet DORA expectations?

What DORA Changes When a Provider Falls Short

DORA is not just a procurement preference, it is an operational resilience standard that changes what a financial institution can safely tolerate from a technology provider. If the provider cannot meet the required expectations for ICT risk, oversight, incident handling, or support for critical functions, the institution has to treat that as a governance problem, not a relationship-management issue. The practical consequence is pressure to remediate, renegotiate, or exit.

The point of the rule is to stop regulated firms from inheriting unmanaged operational fragility through outsourced technology. That is why the institution has to assess whether the provider can support continuity, evidence, and control obligations across the life of the relationship, not only at onboarding. For the underlying regulation, see EU Digital Operational Resilience Act (DORA).

What Usually Happens in Practice

When a provider cannot meet DORA expectations, the relationship often moves into a formal remediation track. That can include tighter contractual terms, additional control requirements, stronger reporting obligations, or a defined deadline to fix the gap. If the provider supports a critical or important function, the institution will usually face a higher bar because the tolerance for unresolved weakness is much lower.

If remediation fails, the institution may have to reduce scope, replace the provider, or terminate the arrangement. That decision is rarely immediate, because replacement can be costly and operationally disruptive, but DORA pushes firms to avoid indefinite dependence on a supplier that cannot demonstrate resilience or accountability. The broader regulatory and audit expectations are summarised in Ultimate Guide to NHIs, Regulatory and Audit Perspectives.

Why the Gap Becomes a Business Decision, Not a Technical One

In a DORA context, provider weakness matters because it can create concentration risk, continuity risk, and control failure at the institution level. A supplier that cannot evidence access control, logging, recovery, testing, or incident cooperation leaves the customer exposed even if day-to-day service appears stable. Financial institutions must therefore judge whether the residual risk is acceptable, temporary, or incompatible with continued use.

This is also why oversight has to stay alive after contract signature. A provider can look acceptable during selection but drift out of compliance through staffing changes, subprocessor growth, tooling gaps, or poor incident discipline. Where technology is tied to a critical function, the institution should expect that unresolved deficiency will eventually force a hard choice between remediation and exit.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

CIS Controls v8 and NIST CSF 2.0 set the technical controls, while DORA define the regulatory obligations.

Framework	Control / Reference	Relevance
DORA	ICT third-party risk management — ICT Third-Party Risk Management	Directly governs provider oversight and exit when a supplier fails resilience expectations.
	incident reporting — Incident Reporting	Provider weakness matters when it prevents timely detection and reporting of operational incidents.
	operational resilience testing — Operational Resilience Testing	A non-compliant provider can undermine the testing needed to prove service resilience.
Recommendation — Strengthen contractual oversight and exit planning for providers that cannot meet resilience obligations. Require incident notification and escalation terms that support timely regulatory reporting. Verify the provider can participate in resilience testing that supports the institution's critical services.
CIS Controls v8	CIS Control 6 — Access Control Management	Weak provider compliance often shows up as poor access governance and privilege control.
Recommendation — Restrict and review provider access paths before allowing continued production use.
NIST CSF 2.0	GV.SC — Supply Chain Risk Management	The question is about managing third-party service risk and contractual dependence.
Recommendation — Use supply-chain governance to track provider obligations, evidence, and remediation status.

Practitioner Guidance

What to verify: Confirm whether the provider can evidence the specific controls DORA expects for the service being delivered, especially around resilience testing, incident response, and third-party oversight. If the provider cannot produce supportable evidence, treat that as a material control gap rather than a documentation issue.

Decision rule: If the provider can close the gap within a credible timeframe and without weakening the institution’s own control posture, remediation may be the right path; if not, begin transition planning early. For critical services, assume that delay increases business risk because exit options become narrower the longer the dependence continues.

Practitioner takeaway: DORA turns weak vendor performance into an institutional accountability issue, so the right question is not whether the provider is still useful, but whether the relationship can remain defensible under regulatory scrutiny.

#1 Authority in NHI Education, Research and Advisory, empowering organizations to tackle the critical risks posed by Non-Human Identities (NHIs), including AI Agents.