Third-Party Risk When One Vendor Runs Your Whole Platform

Every third-party risk programme has the same shape. A register of suppliers. A questionnaire per supplier. A score, an owner, a review date. It was designed for many comparable vendors — a payroll SaaS, a log shipper, a background-check API — where the sensible question is which is well run, and a bad answer means finding another next quarter.

One row in that register is not like the others. It is the provider whose control plane, identity, object storage, egress path, managed database and billing relationship sit underneath most of what you ship. It is one row because procurement signs one contract, and one row is the wrong resolution for it. The fix is not a better questionnaire: the axis that determines your exposure already has a published, closed-value schema, written by a regulator, that you can adopt uninvited.

The questionnaire scores the wrong thing about your biggest vendor

Take the most widely used instrument in the genre. The CSA Cloud Controls Matrix is a cybersecurity control framework for cloud computing composed of 197 control objectives structured in 17 domains. Its questionnaire form, CAIQ v4, shipped in 2021 with 261 questions, down from 310 in v3.1 — CSA has since combined CCM and CAIQ at v4.1, so treat 261 as the v4 figure, not today's count.

That is a control-assurance instrument, and a good one. It produces a maturity picture of the provider's own controls — key management, incident response, logging, personnel screening — and a hyperscaler outscores every small supplier in your register because it genuinely has more control maturity. The score is about the provider. Nothing in it carries what happens to *you* when that provider stops, changes terms or exits a region. Look for the field in your own questionnaire that holds that; where it exists, it is usually free text beside a maturity score, and free text does not aggregate.

The mismatch is easy to underestimate, because the market itself is concentrated. Synergy Research Group's Q2 2026 estimate, published 30 July 2026, put worldwide cloud infrastructure share at 28% for Amazon, 20% for Microsoft and 15% for Google, with the top three at 67% of public cloud specifically. One analyst firm's estimates, not audited figures — but the concentration in your register is also the concentration in everyone else's.

Click to zoom

Concentration stopped being a metaphor and became a named object

Supervisors reached this conclusion first, and several now require the judgement in writing. DORA Article 29(1) makes it a precondition of signing: before concluding an arrangement for ICT services supporting critical or important functions, a financial entity must take into account whether it would mean contracting a provider that is not easily substitutable — and, separately, whether it is accumulating multiple such arrangements with the same or closely connected providers.

Canada's OSFI Guideline B-10 splits the idea in two: institution-specific concentration risk, overreliance on a single third party, subcontractor or geography for multiple activities; and systemic concentration risk, concentration in the provision of services by one third party or geography to multiple institutions. India's Reserve Bank takes the first half in its Outsourcing of Information Technology Services Directions, 2023, requiring regulated entities to consider risks arising from concentration of outsourcing arrangements with a single or a few service providers.

Two adjacent instruments are worth telling apart from those, because programmes routinely treat them as the same requirement. NIS2 Article 21(2)(d) mandates supply chain security framed around the relationships between each entity and its direct suppliers or service providers — a real obligation that asks for no substitutability class. And the UK's Critical Third Parties regime, under which the Bank of England, PRA and FCA began overseeing the first designated providers on 13 July 2026 after HM Treasury designated four cloud and technology firms, is oversight of the provider, not relief for the firm: the regulators state it complements but does not replace existing rules, and that firms remain responsible for their own third-party arrangements including due diligence and contingency planning.

Borrow the regulator's schema: B_07.01 as a data model

The useful part of DORA for an engineering organisation is not the regulation — its resilience obligations are covered separately — but the schema underneath it. Article 28(3) requires a register of information covering all contractual arrangements on the use of ICT services, not only critical ones, and Commission Implementing Regulation (EU) 2024/2956 defines its templates. B_07.01 is the assessment template filled for ICT services supporting a critical or important function — one template among several, with B_01 to B_06 carrying the rest. It is the one worth stealing.

Its fields are closed value sets, which is the point. A closed list forces a decision and aggregates across a register; a maturity score does neither.

• 0050 Substitutability of the provider — one of four official values: *Not substitutable*, *Highly complex substitutability*, *Medium complexity in terms of substitutability*, *Easily substitutable*. Map them to machine-safe identifiers, but the official labels are the definition.
• 0060 Why it is hard to substitute — a closed list of reasons. The first names a lack of real alternatives: few providers in the market, the provider's market share, or technical complexity including proprietary technology. The second names migration or reintegration difficulty, due to significant financial costs, time or other resources, or increased ICT or operational risk.
• 0080 Existence of an exit plan — a bare Yes/No, per provider and per specific ICT service.
• 0090 Possibility of reintegration — *Easy*, *Difficult* or *Highly complex*, restricted to services from a provider that is not an ICT intra-group provider.
• 0100 Impact of discontinuing the service — *Low*, *Medium*, *High*, or *Assessment not performed*.
• 0110 Are alternative providers identified? — *Yes*, *No*, or *Assessment not performed*; required for every provider supporting a critical or important function.

Two limits matter before building on it. First, 0060 is conditional: mandatory only where one of the two hardest substitutability values has been selected. The Official Journal states that condition as a cross-reference to a column code, B_07.01.0041, that the template does not define — 0040 is the type of ICT services, 0050 is substitutability — so read the condition by meaning and do not add 0041 to your schema.

Second, the template has no numeric field for exit cost or time-to-migrate. 0060's second reason option already treats significant financial costs and time as a qualitative *reason* a provider is hard to substitute; it asks for no measurement of either. That gap is where your own engineering work starts.

# substitutability-register/payments-api.yaml
#
# Example record. Field names mirror DORA assessment template B_07.01, defined
# by Commission Implementing Regulation (EU) 2024/2956. Values are illustrative:
# the derived figures come from your own cost model and dated rehearsal.
critical_function: payments-api
provider: cloud-provider-a
ict_service: managed_kubernetes_control_plane

# --- B_07.01 closed-value fields: assessed by a person, not computed ---
b_07_01_0050_substitutability: not_substitutable
b_07_01_0060_reason: no_real_alternatives_market_share_or_proprietary_technology
b_07_01_0080_exit_plan_exists: true
# 0090 applies only where the provider is NOT intra-group; such rows unset it.
b_07_01_0090_reintegration: highly_complex
b_07_01_0100_discontinuation_impact: high
b_07_01_0110_alternatives_identified: false

assessed_by: platform-risk-owner
assessed_on: 2026-08-14
evidence_path: evidence/2026-08-14/payments-api.json

# --- derived: own measurements. The regulation has no field for cost or time.
derived:
  last_exit_rehearsal: 2026-06-02
  measured_time_to_migrate_days: 41
  modelled_exit_cost_eur: 780000

Derive the register from the estate, not from the spreadsheet

That the register of information is a live technical artefact reconciled against deployed topology, rather than an annual spreadsheet, is already argued at length in EU AI Act, NIS2 and DORA: Moving Workloads Self-Hosted — take it as read. What follows is the step after it: where each field's evidence comes from.

Start with the estate, because the estate cannot flatter you: a cluster binds to specific provisioners, controllers and annotations, and unlike a questionnaire response those facts are re-derivable on any Tuesday.

# Excerpt; the per-function mapping loop is elided at the end.
set -euo pipefail
out="evidence/$(date -u +%F)" && mkdir -p "$out"

# Provider-specific annotations: where "just Kubernetes" goes to die.
kubectl --context "<CLUSTER_CONTEXT>" get svc,pv,storageclass -A -o json \
  | jq -r '.items[] | (.metadata.annotations // {}) | keys[]' \
  | grep -E '(amazonaws|azure|cloud\.google|oraclecloud)\.com/' \
  | sort | uniq -c | sort -rn > "$out/provider-annotations.txt"

# Managed-service types and provider blocks, straight from IaC state.
tofu show -json \
  | jq -r '.values.root_module.resources[]? | "\(.provider_name)\t\(.type)"' \
  | sort | uniq -c | sort -rn > "$out/managed-types.tsv"

# ... then map each managed type onto the function it serves

Then stop, because this is where register projects go wrong. Cluster state does not emit "Not substitutable." No script can select a closed-list value. The estate supplies what the value rests on — provider identity, exclusive APIs with no equivalent elsewhere, managed-service types with no portable substitute, data with real gravity — and a named person reads that evidence and records a judgement against it. The evidence_path in the YAML above is the discipline: dated, attributable, re-checkable against an artefact rather than a memory. The same restraint governs 0090 — for an intra-group provider that column is not yours to fill, and unset is the correct answer, not a data-quality gap.

Click to zoom

One closed-list class, and two measurements nobody asks you for

Be precise about what kind of quantity each is. Substitutability is a *class*: four values, chosen by a person, defensible from evidence. Exit cost and time-to-migrate are *measurements*, and no instrument here defines either.

For the class, the honest test is what would have to be rebuilt rather than reconfigured — the question the repatriation playbook answers at length. An object store behind an S3-compatible client, or a Postgres you could restore anywhere, sits near the easy end. A workload wired into a proprietary identity model, or a serverless runtime with no off-platform equivalent, sits near the other. Most estates hold both, which is why the assessment is per critical function and per specific ICT service, not per logo.

Exit-cost modelling — egress, data gravity, dual-running, engineering time — is a discipline of its own, worked through in Vendor Lock-In in the Cloud: Pricing Your Exit as a Number. For time-to-migrate there is one honest source: a rehearsal you actually ran, with a start timestamp and an end timestamp. Anything else is a planning-meeting estimate wearing a unit, and it tends to err optimistic by more than teams expect.

#!/usr/bin/env python3
# Concentration and exit-readiness checks. Input: the register as JSON, one
# object per critical or important function. Exit 1 = unrehearsed hard exit.
import json
import sys
from collections import Counter
from datetime import date, datetime

HARD = {"not_substitutable", "highly_complex_substitutability"}


def main(path, window_days):
    with open(path, encoding="utf-8") as handle:
        rows = json.load(handle)

    for provider, n in Counter(r["provider"] for r in rows).most_common():
        print(f"{provider}: {n} of {len(rows)} functions")
    blind = [r for r in rows if not r.get("b_07_01_0110_alternatives_identified")]
    print(f"no alternative: {len(blind)} of {len(rows)}")

    failures = []
    for row in rows:
        name = row["critical_function"]
        if row.get("b_07_01_0050_substitutability") not in HARD:
            continue
        if not row.get("b_07_01_0080_exit_plan_exists"):
            failures.append(f"{name}: hard to substitute, no exit plan")
            continue
        last = row.get("derived", {}).get("last_exit_rehearsal")
        if not last:
            failures.append(f"{name}: exit plan recorded, never rehearsed")
            continue
        day = datetime.strptime(last, "%Y-%m-%d").date()
        if (date.today() - day).days > window_days:
            failures.append(f"{name}: rehearsed {day}, past the {window_days}-day window")

    for line in failures:
        print(f"FAIL {line}", file=sys.stderr)
    return 1 if failures else 0


if __name__ == "__main__":
    # The window is a governance decision, not a statutory deadline.
    sys.exit(main(sys.argv[1], int(sys.argv[2])))

How the register goes wrong

A register does not create evidence; it records a judgement and points at some. That distinction is where most of these programmes fail, and the failures rhyme. Five reliable ways to end up with a document that looks like risk management and is not:

1. Stale rows. An assessment dated eighteen months ago describes an architecture that has since absorbed three managed services. If assessed_on predates the function's last material IaC change, the row is a historical note.
2. Self-graded substitutability. Asking a provider how replaceable it is produces a predictable answer. 0050 is the entity's own assessment; a vendor questionnaire is an input, never the source.
3. Fourth-party blindness. The tier below your direct supplier is where surprises live, and the adjacent frameworks are scoped above it: NIS2 Article 21(2)(d) frames its supply chain duty around direct suppliers and service providers, and NIST SP 800-161r1's SR-13 scopes the supplier inventory to tier one suppliers presenting cybersecurity risk — with market concentration something the same publication says an enterprise *may consider*. Subcontractor mapping is yours to build.
4. Intra-group laundering. Routing a dependency through a group entity changes the contractual counterparty, not the substitutability of the platform underneath. 0090 is unset for intra-group rows because reintegration means something different there — not as licence to reclassify a hyperscaler dependency as internal.
5. "Assessment not performed" as the resting state. 0100 and 0110 both offer it, and reporting it beats inventing a value. But 0110 requires the assessment for every provider supporting a critical or important function, so the value records unfinished work — and a register where it never changes is one nobody is working.

Making the exit ramp testable

DORA Article 28(8) is blunt about the difference between a plan and a document. Exit plans must be comprehensive, documented and sufficiently tested and reviewed periodically; entities must identify alternative solutions and develop transition plans enabling them to remove the contracted services and data from the provider and transfer them to alternative providers or reincorporate them in-house. Notice what it does not say: it names no interval.

So the review window is yours to set, and setting it is the decision. Separately, the EU Data Act imposes a statutory switching clock on providers — notice period, transitional period, an unfeasibility track and a customer extension right — worked through in full on the exit-cost article; it also removes switching charges from 12 January 2027. That clock binds your provider's contract, not your rehearsal cadence, and conflating the two hard-codes a legal deadline into a pipeline.

# .github/workflows/exit-rehearsal-gate.yml
name: exit-rehearsal-gate

on:
  schedule: [{ cron: "0 6 * * 1" }]
  pull_request:
    paths: ["substitutability-register/**"]

env:
  # Your own governance window, in days. DORA Article 28(8) requires periodic
  # testing and names no interval, so this is a policy choice you own. The EU
  # Data Act's switching clock binds the provider, not your cadence.
  REHEARSAL_WINDOW_DAYS: "180"

jobs:
  register:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-python@v5
        with: { python-version: "3.13" }
      - run: python tools/register_to_json.py substitutability-register > register.json
      - name: Concentration and exit-readiness gate
        run: python tools/register_check.py register.json "$REHEARSAL_WINDOW_DAYS"

A rehearsal record needs four things to be worth gating on: what was moved, from where to where, wall-clock start and end, and what broke. The last matters most — a rehearsal that surfaces nothing was probably a tabletop walkthrough. Feed the observed duration back into measured_time_to_migrate_days, and the register holds an observation rather than an aspiration.

When the build goes red, the honest outcomes are to rehearse, to re-assess the class against fresh evidence, or to record a dated, owner-approved exception. Deleting the row is not one. The point of gating in CI is that accepting a stale exit plan becomes a visible act by a named person rather than the default of a spreadsheet nobody opened.

Substitutability is an architectural property, not a procurement one

None of this is really a governance exercise. A register only reports the substitutability an architecture already has, and the decisions that set it were made years before anyone opened a questionnaire. Four do most of the work.

• Keep the interface portable even where the implementation is managed. An S3-compatible API or a Postgres wire protocol is a different commitment from a proprietary control surface with no second implementation.
• Broker identity rather than inheriting it. Workload identity terminating in one provider's IAM model is the dependency hardest to see and slowest to unpick.
• Treat managed-service resource types as a budget. Each one is a line item in a future migration; count them in IaC state and watch the trend.
• Keep one alternative alive rather than theoretical. 0110 asks whether alternatives are identified — and one you have never restored into is identified in the weakest sense.

This is the long game, and the argument for running your own infrastructure in a form procurement can read. A platform you can leave is one you can renegotiate, re-price, re-site under a new residency rule, and keep running when a supervisor designates your provider systemically important. The register is where that property is written down in values someone else can check — the difference between believing you have optionality and demonstrating it.