Building a Hyperscaler Dependency Register After the CTP Designations

The critical-third-party regime assumes you already know exactly where your firm depends on a hyperscaler. Most firms cannot answer that question at the granularity the regime now takes for granted.

On 10 July 2026 HM Treasury designated the first critical third parties to the UK financial sector, and on Monday 13 July the Bank of England, the PRA and the FCA began overseeing them. The four are Amazon Web Services EMEA SARL, Google Cloud EMEA Limited, Microsoft Ireland Operations Ltd and Oracle Corporation UK Limited. The oversight framework itself, set out in the FCA’s PS24/16 and the corresponding PRA rules, has been in force since 1 January 2025; what changed in July is that named providers are now inside it.

The regime regulates the providers, not the firms that rely on them. That is the point most commentary misses, and it is precisely why the firm-side work is quiet and easy to defer. Nobody is going to serve you a CTP notice. But the moment a supervisor asks which of your important business services would be affected by a Microsoft region outage, or how much of your estate concentrates on a single designated provider, you need an answer that holds up. A static spreadsheet updated once a year does not.

Why a spreadsheet fails here

The typical outsourcing register lists suppliers and contracts. It records that you use AWS. That is the wrong resolution entirely. “We use AWS” tells you nothing about whether your customer-payments service and your regulatory-reporting service share a single availability zone, or whether your identity provider and the database it authenticates against sit in the same region such that one failure takes out both.

Concentration and failure domains are properties of the mapping between business services and infrastructure, not of the supplier list. To see them you need the register to carry three things the outsourcing sheet never has: which cloud account and organisation a workload actually runs in, which region and availability zone it depends on, and which specific managed service — not just “AWS” but Amazon RDS, Amazon Route 53, AWS KMS — it cannot function without. A dependency register is only useful if it is queryable at that granularity, and kept current from the systems that already know the answer.

Anchor it to important business services, not applications

UK operational resilience policy already made you define your important business services and set impact tolerances for them. The CTP regime consumes that work rather than replacing it. The register’s top-level entity should therefore be the important business service, because that is the unit a supervisor reasons in and the unit against which your impact tolerance is set. Everything else hangs off it: the services decompose into the applications and workloads that deliver them, and those in turn resolve to accounts, regions and provider services.

Get this ordering right and the useful questions become single queries. Which important business services have any dependency on a designated CTP? Of those, which have no viable failover to a different region or provider inside their stated tolerance? Where does a single provider service — a DNS zone, a managed database, a key-management endpoint — sit underneath more than one important business service, so that its failure is correlated across services the board treats as independent? This is the same reasoning that sits under the tolerance work described in our note on critical operations and tolerance levels; the CTP register is where that reasoning gets its data.

A schema that carries the granularity

The core is a small relational model. Business services, the workloads that compose them, and the provider dependencies each workload has — with the designation status of the provider recorded so that “is this a CTP dependency” is a filter, not a manual judgement each time.

-- Hyperscaler dependency register: core schema (PostgreSQL)

CREATE TABLE provider (
    provider_id   text PRIMARY KEY,          -- 'aws', 'azure', 'gcp', 'oracle'
    legal_entity  text NOT NULL,             -- 'Amazon Web Services EMEA SARL'
    is_ctp        boolean NOT NULL DEFAULT false,
    designated_on date                       -- 2026-07-10 for the first four
);

CREATE TABLE important_business_service (
    ibs_id            text PRIMARY KEY,       -- 'ibs-customer-payments'
    name              text NOT NULL,
    impact_tolerance  interval NOT NULL,      -- e.g. '2 hours'
    owner             text NOT NULL           -- accountable exec/SMF
);

CREATE TABLE workload (
    workload_id  text PRIMARY KEY,            -- 'wl-payments-api'
    ibs_id       text NOT NULL REFERENCES important_business_service,
    account_ref  text NOT NULL,               -- cloud account / subscription ID
    org_unit     text                         -- landing-zone OU, if any
);

-- One row per (workload, provider service, region, AZ) it cannot run without.
CREATE TABLE dependency (
    workload_id       text NOT NULL REFERENCES workload,
    provider_id       text NOT NULL REFERENCES provider,
    provider_service  text NOT NULL,          -- 'rds', 'route53', 'kms'
    region            text NOT NULL,          -- 'eu-west-1'
    availability_zone text,                   -- null if regional/global
    is_hard           boolean NOT NULL,       -- hard = no run without it
    failover_target   text,                   -- region/provider, or null
    PRIMARY KEY (workload_id, provider_id, provider_service, region)
);

-- Which important business services ride on a designated CTP, and where
-- they have a hard dependency with no failover inside tolerance.
SELECT i.name,
       p.legal_entity,
       d.provider_service,
       d.region,
       d.is_hard,
       d.failover_target
FROM   important_business_service i
JOIN   workload    w ON w.ibs_id = i.ibs_id
JOIN   dependency  d ON d.workload_id = w.workload_id
JOIN   provider    p ON p.provider_id = d.provider_id
WHERE  p.is_ctp
  AND  d.is_hard
  AND  d.failover_target IS NULL
ORDER  BY i.name, d.region;

The shape matters more than the dialect. If your estate is heavily interconnected — shared platform services, a mesh of internal dependencies — a property graph (Neo4j, or an equivalent) models the same entities as nodes and the depends-on relationships as edges, and answers “what else fails if this region goes” as a traversal rather than a recursive join. The relational model is the right starting point; reach for the graph when correlated-failure reachability becomes the question you ask most.

Populate it from inventory, not from a survey

A register built by emailing teams a form is stale the day it is finished and wrong within a quarter. The account, region and service fields already exist in machine-readable form: in your cloud tagging, your infrastructure-as-code state, your CMDB. The population job is a reconciliation between those sources and the important-business-service mapping, run on a schedule, with drift flagged rather than silently overwritten. The one field that genuinely needs human judgement is is_hard — whether a dependency is load-bearing or merely convenient — and even that should be reviewed against reality, not asserted once. This is the discipline our reading of the FCA’s critical-third-party regime keeps returning to: the evidence has to be generated by the estate, not narrated about it.

What this buys you

A queryable register turns three separate obligations into one artefact. It feeds your operational-resilience mapping, because it says which services a provider outage touches. It feeds your concentration analysis, because it makes single-provider and single-region exposure countable rather than anecdotal. And for firms that also fall under the EU regime, it is most of the substance behind the DORA third-party oversight register too — the same dependencies, described for a second supervisor. The firms that named their first Monday actions well, in the sense set out in what reliant firms do on Monday morning, are the ones already holding this data.

The designation did not create the dependency. It only removed your excuse for not being able to see it.