BCM-010 Third-Party and AI Provider Service Continuity
Description
Third-party services whose loss would breach a recovery objective are listed. Each entry names the function the service performs, the internal service that depends on it, the continuity commitment the provider has given and the contingency that runs while the service is unavailable. Entries for model and inference providers also name the model versions in production, the deprecation and end-of-life notice the provider is committed to giving and the behaviour the dependent service falls back to when the provider is unreachable or a version is withdrawn. Each listed service has an exit plan naming the alternative, the work required to move to it and the data to be retrieved. The contingency is exercised at defined intervals with the result recorded. Where the loss of a listed third party would breach a recovery objective for a service the organisation has committed to a customer, the entry names the clause of that third party's own contract obliging it to hold and test a contingency plan, together with the service level that plan is held to.
Rationale
A model API that returns errors, or a version withdrawn on 90 days notice, takes a product feature down as surely as a failed database. Neither the vendor risk assessment nor the contract keeps the feature running. Naming the pinned versions and the fallback behaviour makes a deprecation notice actionable instead of a fire drill. Exercising the contingency proves the fallback still works after a year of unrelated changes. AIG-032 holds the pre-integration assessment, VND-002 the contractual terms, VND-004 cloud provider exit provisions and BCM-008 the dependency picture this list is drawn from. Issued in S4 from G-BCM-3 in docs/review-canonical-quality.md section 7.3. A continuity commitment given to a customer is worth what the weakest contract behind it says. The register already named the commitment the provider gave; the addition is that the same obligation exists one link further down in writing rather than by assumption, with a service level attached so that holding a plan is decidable rather than asserted. VND-015 discloses the subcontractors and governs changing them; BCM-010 holds the continuity obligation each one carries.
Applicability (9 profiles)
The continuity control for every AI system the deployer does not host.
The continuity control for every AI system the deployer does not host.
Recorded to mark the seat, not to add a duty. BCM-010 is the exit planning the organisation does as a buyer. Art. 25(2)(b) is the mirror: supporting the customer's exit strategy, including by providing all relevant information. The two are easy to confuse and the proposed switching controls, not this one, carry the customer-facing half.
EX-98 written in S8 wave B (migration 057). An entry for a third party whose loss would breach a recovery objective for a customer-committed service now names the clause of that third party's own contract requiring a contingency plan and its testing, with the service level that plan is held to, which is RTS 2025/532 Art. 4(1), points (g) and (h). Art. 29 still scores the provider on substitutability and on the length of its subcontracting chain before a contract exists, which is a commercial consequence of the register rather than a further control requirement.
Framework Mappings (13)
| MDS-11 | Model Failure | informative |
| DORA-Art.28.8 | Exit strategies for ICT services supporting critical or important functions | informative |
| DORA-Art.29 | Preliminary assessment of ICT concentration risk at entity level | informative |
| DORA-Art.30.3.c | Business contingency plans and ICT security measures | informative |
| DORA-RTS-2025/532-Art.4.1 | Contract conditions for subcontracting critical or important functions | partial |
| EU-DA-Art.23 | Removal of Switching Obstacles | informative |
| 5.23 | Information security for use of cloud services | informative |
| A.10.3 | Suppliers | informative |
| SA-9 | External System Services | informative |
| GV-6.2-001 | Third-Party Failure Contingency Processes | GV-6.2-001 | full |
| GV-6.2-006 | Third-Party Failure Contingency Processes | GV-6.2-006 | full |
| GOVERN 6.2 | Third-Party Failure Contingency Processes | full |
| CC9.1 | Risk Mitigation | partial |
Evidence (3)
Register of third-party and model providers whose loss would breach a recovery objective, with the dependent internal service, the provider commitment, the contingency and the exit plan for each.
Example: Critical third-party and model provider register v3, dated 2026-08-09, covering 11 services including two inference providers, each with its dependent service, pinned model versions, fallback behaviour and exit plan reference
Test: Read the register against the business impact analysis. Verify: (1) every third party a priority process depends on appears, (2) each entry names the dependent internal service and the provider's continuity commitment, (3) model and inference providers name the versions in production and the deprecation notice period committed to, (4) each entry has an exit plan naming the alternative, the migration work and the data to retrieve, (5) entries are dated and were reviewed within the defined interval. (6) for each listed third party whose loss would breach a recovery objective for a customer-committed service, the entry cites the clause of that third party's contract requiring a contingency plan and its testing, and states the service level the plan is held to.
Configuration of the fallback path in a service that depends on an external provider, showing the pinned version, the failure detection and the behaviour the service adopts when the provider is unreachable.
Example: Inference gateway configuration of 2026-08-21 showing the pinned model version, the timeout and error thresholds, the secondary provider route and the degraded-mode response used when both are unavailable
Test: Export the fallback configuration for a service that depends on an external provider. Verify: (1) the provider version in use is pinned rather than floating, (2) a failure threshold is configured that triggers the fallback without a person intervening, (3) the fallback behaviour matches the contingency the register describes, (4) the degraded behaviour is defined for the case where no alternative provider is available.
Result of the most recent contingency exercise for a listed provider, recording what was simulated, what the dependent service did and what needed fixing.
Example: Provider outage exercise report of 2026-06-11 simulating a total inference provider outage, recording the failover time, the degraded responses served and three follow-up actions
Test: Read the most recent contingency exercise report. Verify: (1) the exercise removed or blocked the provider rather than describing its loss on paper, (2) the dependent service behaved as the register says it would, (3) the time to fall back is recorded and compared to the recovery objective for the dependent service, (4) follow-up actions from the previous exercise were closed before this one, (5) the exercise fell within the defined interval.
Questions (3)
Is there a list of third-party services whose loss would breach a recovery objective?
This is a shorter list than the vendor inventory: only the services whose unavailability would stop a process from meeting its recovery objective. Model and inference providers count.
Which of the following does each entry record?
A contingency is what the service does, not what the incident team would decide at the time. For model providers the pinned version matters because a withdrawn version is an outage with a date on it. The last item is the one usually taken on trust: a provider that promises a customer continuity through a chain it has not contracted for is promising something it cannot enforce.
How is the contingency for a listed provider exercised?
Options run from strongest to weakest. Blocking the provider in a production-equivalent environment is what finds the retry loop, the missing timeout and the fallback that was never wired up.