What happens when a critical ICT provider is compromised and there is no tested exit plan?

How a Compromised Critical ICT Provider Turns Into an Exit Problem

A critical ICT provider compromise is not only a security event, it is also a continuity and transition problem. The issue is whether the institution can still obtain its data, preserve service delivery, and move processing elsewhere without depending on the very provider that has failed. A tested exit plan is what turns that theoretical requirement into an executable recovery path.

That is why a provider compromise can quickly become an operational choke point. If the institution has not rehearsed data return, alternative processing, interim workarounds, and cutover sequencing, the exit itself becomes part of the incident.

For financial entities, the DORA Guide is the clearest internal reference point for how exit strategies, ICT third-party risk and resilience testing fit together in practice. The key lesson is that exit capability has to be usable under stress, not merely documented.

What Breaks When the Exit Plan Was Never Tested

Untested exit plans usually fail in predictable ways. Data export formats may be incomplete, backups may not be usable by the replacement provider, access dependencies may be hidden, and contractual exit rights may not match the technical reality. When the compromise is severe, the institution may discover too late that switching providers requires manual reconstruction of workflows, identities, integrations, and control evidence.

That is where service continuity and data portability separate from paper compliance. A plan can look complete on review and still fail if no one has validated who can export the data, how long the transition takes, what must stay live during handoff, and which functions can tolerate partial degradation.

The Third-Party Risk Management Guide is useful here because vendor offboarding and concentration risk are not abstract governance concepts, they are the mechanics that determine whether a compromised supplier can be replaced before the outage spreads.

Recovery Priorities When the Supplier Is the Weakest Link

The recovery order is usually to stabilise service, preserve evidence, and then decide whether the compromised provider can still be trusted for limited continued use. If the compromise affects integrity, availability, or access control, the safer assumption is that provider-managed paths, tokens, and administrative channels may also be unreliable until proven otherwise.

Practically, the institution should confirm three things first: whether it can retrieve current data in a usable form, whether a parallel or interim service path exists, and whether the replacement path can be activated without waiting on the compromised supplier. Those checks determine whether the response is containment, controlled transition, or full service suspension.

In an incident of this kind, the DORA framework matters because it treats ICT third-party resilience, incident handling and exit readiness as connected obligations rather than separate paperwork exercises.

Risk and Threat Considerations

A compromised critical ICT provider creates concentrated exposure because one supplier can hold data, integration logic, and continuity dependencies for many downstream services at once. If the institution has no tested exit plan, the main risk is not just breach impact, but prolonged operational paralysis while teams improvise access, exports and replacement processing.

Failure mechanism: The provider compromise disrupts trust in the outsourced environment, while the lack of a rehearsed exit leaves the institution unable to verify data return, re-establish service elsewhere, or preserve control over the handoff.

Impact: Recovery slows, outage duration increases, regulatory deadlines become harder to meet, and the institution may be forced into a risky stay-or-stop decision instead of a controlled transition.

Practitioner Guidance

What to verify: Test the exit path end to end, including data extractability, portability into an alternate environment, interim continuity arrangements, and the ability to revoke or re-issue provider-dependent access without relying on the compromised platform.

Decision rule: If the provider controls a critical business function, treat exit readiness as an operational control, not a procurement artifact. If the transition cannot be exercised in a realistic scenario, assume the exit plan is not yet usable.

Common mistake: Teams often validate the contract, the architecture, or the backup policy separately and assume that means the exit works. In practice, the failure is usually at the seams between data, identity, integrations, and operational ownership.

Practitioner takeaway: A critical provider compromise becomes materially worse when exit capability has never been rehearsed, because the organisation then has to solve continuity, recovery and vendor replacement at the same time.

Related resources from NHI Mgmt Group

• What happens when a shadow identity is compromised and there is no incident response plan?
• Why is NHI governance critical in the age of AI attacks?
• Why is single-provider AI agent governance not enough for enterprise security?
• How can organisations reduce the blast radius of compromised agent identities?