If You Are the Critical Third Party: Building the Self-Assessment and Incident Pipeline

Designation did not hand you a document to file. It handed you a recurring, evidenced obligation to the regulators and to the firms that depend on you — and that is an operating-model problem long before it is a compliance one.

On 13 July 2026 four providers — Amazon Web Services EMEA SARL, Google Cloud EMEA Limited, Microsoft Ireland Operations Limited and Oracle Corporation UK Limited — became designated critical third parties to the UK financial sector under the Critical Third Parties (Designation) Regulations 2026. Joint oversight by the Bank of England, the PRA and the FCA began the same day, against the final rules the regulators set out in PS16/24 and the accompanying supervisory statement SS6/24. If you are one of the four, or you expect to be named in a later round, the two obligations that will define your first year are the self-assessment and the incident-notification pipeline. Both are, at heart, data problems. Firms that treat them as writing exercises will produce something that reads well once and drifts out of date within a quarter.

What designation actually starts

The regime layers several duties onto a designated provider: six Fundamental Rules, eight Operational Risk and Resilience Requirements, notification and information duties, a testing and exercise programme, record-keeping, and a UK address for service. Five of the Fundamental Rules apply only to the systemic third-party services you provide; the sixth — deal with each regulator openly and disclose anything they would reasonably expect notice of — applies across everything. That last rule is the one that turns a supervisory relationship into a continuous obligation rather than an annual filing.

The clock that matters first is the interim self-assessment, due within three months of designation — for the initial cohort, around the middle of October 2026 — with a full self-assessment annually thereafter. It goes to the regulators and to the firms you provide systemic services to, with redactions permitted for genuinely sensitive detail, and you must retain the supporting evidence. If you are still working out what the regime means from the reliant firm’s side as well, the technology implications of the FCA’s critical third party regime and the parallel DORA critical third-party oversight are worth reading alongside this, because your customers will be reading them and asking you to evidence the same things.

The self-assessment is a query, not a Word document

The instinct is to commission a narrative document, staffed by a small team, delivered as a PDF. Resist it. The self-assessment has to evidence resilience across each systemic service you provide — mapped dependencies, scenario testing, incident history, change control — and it has to do so again next year, and the year after, against an estate that changes every week. A document authored by hand is out of date the day it is signed.

The durable version treats the self-assessment as a report generated from a register you already maintain, not a narrative you compose from scratch. That means instrumenting the underlying data first: a service catalogue that names each systemic service, a dependency and supply-chain map beneath it, the mapping that shows how each service supports customer firms’ important business services, the results of your scenario tests and playbook exercises, and the change records that explain what moved and why. Once those exist as structured data, the self-assessment becomes largely a matter of rendering them into the regulators’ expected shape. The narrative is the thin layer on top; the register is the thing a supervisor can actually test against reality.

Where firms underestimate the incident pipeline

The notification duty is the part that catches engineering teams out. When a CTP operational incident occurs — judged on its actual impact, not on the type of event — you must notify both the regulators and the affected firms, and you must do it in stages: an initial notification without undue delay, intermediate updates while the incident runs, and a final report once it is closed. Confirm the precise windows against SS6/24 before you wire anything, because the exact hours are set by the rules, not by convention.

Two things make this harder than the standard firm-side incident report. First, the clock starts at detection, which means your detection-to-classification path has to be instrumented well enough to prove when you knew — a supervisor will reconcile your notification timestamps against your own monitoring. Second, you are not notifying one regulator; you are also fanning out to potentially many affected firms, each with its own contractual contact and channel. That fan-out is an integration problem, and improvising it under a live incident is exactly when it fails. The discipline is the same one behind the 72-hour incident reporting muscle and the engineering that sits behind the AI Act’s serious-incident reporting clock: build the contract once, test it cold, and make the timer a first-class object rather than a diary reminder.

Build the notification contract before you need it

One payload schema, two audiences, three stages. Define it as configuration so the same structured record drives the regulator submission and the firm fan-out, and so the SLA timers are computed from a single detection timestamp rather than tracked by hand.

# ctp-incident-notification.yaml
# Notification contract for a CTP operational incident.
# One schema, two audiences: the regulators and every affected firm.
# Confirm the exact reporting windows against SS6/24 before wiring the timers.

schema_version: "1.0"

payload:
  incident_ref: string          # stable id, minted at detection
  report_stage: enum            # initial | intermediate | final
  detected_at: timestamp        # UTC; starts every SLA clock
  systemic_services: [string]   # which systemic services are affected
  impact:
    availability: bool
    integrity: bool
    confidentiality: bool
    firms_affected: [firm_id]   # drives the fan-out to customer firms
  summary: string
  remediation: string           # populated from the intermediate stage onward
  root_cause: string            # required at the final stage

# SLA timers, all measured from detected_at.
# Replace the placeholder windows with the confirmed regulatory durations.
sla_timers:
  initial:
    audience: [regulators, affected_firms]
    due_within: CONFIRM         # "without undue delay" -- set the hard window
    escalate_at: 0.75           # page the on-call at 75% of the window
  intermediate:
    audience: [regulators, affected_firms]
    cadence: recurring          # until the incident is closed
  final:
    audience: [regulators, affected_firms]
    due_within: CONFIRM         # post-closure window
    requires: [root_cause, remediation]

The value is not the file. It is that every stage produces the same structured record, that the affected-firms list is data rather than a distribution list someone maintains by hand, and that the timers escalate on their own. A supervisor asking how you met the initial window should be answered from this log, not from memory.

What a supervisor will ask to see

Assume the questions are evidential rather than conceptual. Show us the self-assessment, and show us it reconciles to the register it claims to summarise. Show us the mapping from your systemic services to the firms that rely on them. Show us the incident log with detection and notification timestamps, and show us they satisfy the windows. Show us the first incident-management exercise — the rules expect one within twelve months of designation and periodically after — and show us what it changed. Each of those is a query against a system you either built or did not. The provider that instrumented the data can answer in an afternoon; the provider that wrote a document is reconstructing the truth under supervisory pressure.

Designation makes you a supervised entity whose resilience is now other firms’ resilience. The self-assessment and the incident pipeline are not the paperwork of that relationship. They are the relationship, rendered in data you can produce on demand — and the year to build them is the one that has already started.