1. Docs
2. Concepts

Third Parties

The ICT providers the estate relies on, how concentrated critical and important applications are on any one of them — designated critical third parties marked — and the exit plan each of those reliances needs, derived from resource types and tags, never guessed.

#Why Third Parties

Three sets of rules ask about the providers an estate runs on:

• DORA Art. 28(8) requires exit strategies for ICT services that support critical or important functions, and the register of information asks how substitutable each provider is (ITS template B_07.01).

• PRA SS2/21 chapter 10 expects documented, tested exit plans for material outsourcing.

• The UK critical third parties regime adds a concentration question. HM Treasury designated four providers as critical third parties, effective 13 July 2026, under The Critical Third Parties (Designation) Regulations 2026 (SI 2026/777):

  • Amazon Web Services EMEA SARL;
  • Google Cloud EMEA Limited;
  • Microsoft Ireland Operations Limited;
  • Oracle Corporation UK Limited.

  HM Treasury designates on a rolling basis and further designations are expected, so the list is reference data the platform admin keeps current (see The Designations).

A firm therefore needs to know how much of its critical estate sits on any one provider. In an Azure estate the honest answer is usually "all of it". The Third Parties page states that plainly, and the exit plans are how a firm shows it has thought about it. As with the rest of the derived model, the answer is derived, not authored:

• the providers come from facts collection already holds;
• the designations are reference data with their legal source;
• each exit plan is a governance record with a named author;
• a rule turns a missing or out-of-date plan into a finding.

#Providers Are Derived

A resource relies on the providers its type and its tags name, and each reliance keeps how it was found: the resource type, or the tag that named it.

One tag can name several suppliers, separated by ;, , or |. A tag that names a platform — Microsoft or Azure, AWS or Amazon Web Services, Google or GCP, Oracle or OCI — counts towards that platform, not as a separate supplier. For example, a virtual machine tagged

vendor   = Ledgerline
supplier = Azure | Northwind Messaging

relies on Microsoft (from its type, and the Azure value adds nothing new), Ledgerline and Northwind Messaging. In a CSV import, where ; and | already separate tags, separate several suppliers with , and quote the field.

Archigov does not guess a supplier from a resource's name or anything else. Only tags name suppliers; see Connect Azure.

#Concentration

For each provider, Archigov counts the applications that rely on it and, among them, the ones that need exit plans: those classified critical or important, or supporting a regulated service (see Criticality). Its share is that count divided by the number of applications in the estate that need exit plans.

When one provider carries half or more of the applications that need exit plans, a warning names it, for example 6 of 6 critical or important applications rely on Microsoft. If the provider is a designated critical third party, the warning names the designated entity and the instrument. It says that concentration on one provider is a risk to weigh, and that an exit plan per reliance is how it is evidenced. It never says whether the concentration is acceptable: your boards weigh it.

#The Designations

A provider is marked Designated when it is on the designations list in force. Each release ships the four entities designated under SI 2026/777, with the instrument and its effective date. The platform admin replaces the list as HM Treasury designates more; there is no editor in the UI yet, so the change goes through the API:

PUT /api/third-parties/ctp

{
  "instrument": "The Critical Third Parties (Designation) Regulations 2026 (SI 2026/777)",
  "effective": "2026-07-13",
  "entries": [
    { "provider": "aws", "entity": "Amazon Web Services EMEA SARL" },
    { "provider": "google", "entity": "Google Cloud EMEA Limited" },
    { "provider": "microsoft", "entity": "Microsoft Ireland Operations Limited" },
    { "provider": "oracle", "entity": "Oracle Corporation UK Limited" }
  ]
}

The body replaces the whole list, so send every entry in force. provider is the provider's id: microsoft, aws, google or oracle for a platform, or supplier:<name in lowercase, hyphenated> for a named supplier. The instrument and every entry's provider and entity are required. The change is audited as ctp:set, and the page's footer names the designations in force.

#Exit Plans

Every application that is classified critical or important, or that supports a regulated service, needs an exit plan for each provider it relies on: the cloud platform and every named supplier. An author records it under their own name with Record Exit Plan on the Third Parties page:

• Substitutability — how readily the provider could be replaced, in the vocabulary of the DORA register of information (B_07.01):

  Choice in the form	In the DORA register
  Not substitutable	Not substitutable
  Highly complex	Highly complex substitutability
  Medium complexity	Medium complexity in terms of substitutability
  Easily substitutable	Easily substitutable

• Last Tested (optional) — when the plan was last exercised. A date in the future is refused.

• Adequacy — Satisfactory, Satisfactory with remarks or Unsatisfactory.

• Exit Plan — at least ten characters, written under the template's headings: Reliance, Exit triggers, Exit strategy, Data and portability, Timeline and resources and Testing. The headings are prompts, never regulation text.

• Reference (optional) — an http or https link to where the full plan lives. The document itself is never uploaded.

A plan for a provider the application does not rely on is refused. An exit plan is valid for 12 months by default; the validity is the lifecycle.assessment_months setting the legacy assessment uses too. Each plan is a new record, and the latest one for that application and provider counts. Every reliance has a status:

The status says whether a plan is in date, not whether it is adequate. An unsatisfactory plan is recorded as such and counts as in date; what follows is for your boards to decide.

#The Third Parties Page

Risk → Third Parties brings it together:

• Counts in the hero band: providers, designated critical third parties relied on, critical applications on a designated critical third party, and exit plans due.
• The concentration warning, when one provider carries half or more of the applications that need exit plans.
• Providers — one row per provider: its kind (Cloud platform or Named supplier), whether it is a designated critical third party (the Designated tag names the entity, the instrument and its effective date on hover), the applications that rely on it, how many of them are critical or important with their share, the regulated services behind them, its resources and regions.
• Exit Plans — one row per application and provider that needs a plan, due first: the application and its criticality, the provider, the status, the substitutability, when it was last tested, who recorded it and until when it is valid, and Record Exit Plan.
• The footer — the designations in force, with the instrument and its effective date.

Statuses are status tags (colour, icon and word) and explain themselves on hover.

#The DORA Register

The DORA register of information takes B_07.01 substitutability from the latest exit plan for that application and provider, in the ITS wording above. Where there is no plan the cell is blank; it is never inferred.

Each supplier named on resource tags also gets rows of its own as an ICT third-party provider, with the substitutability from its own exit plan. Where and how it serves — the service type, the countries, the data — is left blank for your organisation to fill.

#Rules

assessmentCurrent (application scope) with kind exit_plan produces a finding when the application relies on a provider with no exit plan in date. The finding names those providers. An application that needs no exit plan never produces one.

{ "scope": "application", "assert": { "op": "assessmentCurrent", "kind": "exit_plan" } }

A missing kind, or a kind other than legacy or exit_plan, is refused when the rule is authored and is a rule error, never a pass. See the Rule DSL.

#The DORA Pack

The dora-ict-architecture pack (version 1.1.0, eight standards) carries the rule as a standard. Like the rest of the pack, it imports as a draft: it is evaluated only once a board adopts it.

See Governance catalogue.

#Who Can Do What

The platform admin, the auditor and a board member who holds only a seat (no system role) are refused with 403 when recording an exit plan: a plan is content, and the platform admin's flag is operational only. An author is refused with 403 on the designations list. See Roles and capabilities.

#Evidence and Audit

Every change is in the audit chain: exit_plan:record on the application, with the provider, the adequacy, the substitutability, the test date, the validity and the reference; ctp:set, with the instrument, its effective date and the designated entities. The evidence pack carries each application's third parties: every provider, its kind, the designated entity where there is one, its resources, and — where a plan is needed — the exit plan's status, adequacy, substitutability, test date, who recorded it and until when it is valid.

#Heuristics and AI

Everything that decides a reliance, a status or a finding is deterministic:

• Providers come from resource types and supplier tags only, never from names.
• The need for a plan comes from the stored classification.
• The status comes from the latest plan's validity.
• The concentration warning is a fixed threshold: half or more of the applications that need exit plans.
• The designations are reference data with their legal source, not code.

AI is optional and advisory. Draft with AI in the exit-plan form uses the existing Assessment Drafting feature, so there is no separate switch; with the feature off, the button is greyed with the reason (see AI in Archigov). The draft fills the template's headings from what Archigov knows about the reliance: the application's criticality and services, its resources and regions, the provider's designation and the previous plan. Where the facts are silent — alternatives, timelines, costs, owners, test results — it writes To be confirmed: …. It never invents a provider, a timeline, a cost or a test result. Nothing is stored: the author edits it and records the plan as their own. No AI derives providers or sets a status.

#What It Deliberately Does Not Do

• It does not discover contracts, LEIs or sub-contracting chains. Those stay for your organisation to fill in the DORA register.
• It does not guess a supplier from a resource's name. Only tags name suppliers.
• It does not judge concentration. It shows the reliance and the plans; your boards weigh them.
• It does not store the plan document. It keeps a link only.
• It has no designations editor in the UI yet. The platform admin updates the list through the API.

Note

The page shows which providers the estate relies on, which of them are designated, and who recorded which exit plan and when. Archigov never asserts that you meet DORA, the PRA's expectations or any other framework: it shows evidence, not assurance.

Something unclear or out of date? Write to hello@archigov.com or open an issue on GitHub.