Across Boundaries: Cloud Providers, Managed Providers, Outages and Exit

Every operations function described so far stops, at some point, at a boundary that the organisation does not own: a cloud region, a managed service provider's night shift, a software-as-a-service vendor's telemetry, a model provider's fallback. This chapter treats those boundaries and concerns three of the five functions: O1 Observe, because the provider's view of an outage and the organisation's are different measurements and only one is under the organisation's control; O4 Restore, because a recovery that depends on a provider is a claim about the provider as well as the organisation; and O5 Sustain, because contracts, registers, exit plans and switching rights are the lifecycle of a dependency, and a dependency that cannot be left has been accepted without being decided.

The chapter takes over three deferrals. Chapter 15 left open how a fallback provider for an AI service enters the contract set and, for a financial entity, the register of information. Chapter 21 gave the six terms that bring a managed provider's AI under a contract and left the DORA contract provisions and the Data Act's switching terms to this chapter. Chapter 4 fixed that a provider's embedded AI acts at a level the provider chose, which AI Red Team, Chapter 8, called the Mode 0 blind spot.

The chapter builds on the series' conclusions on sovereignty and suppliers. Digital sovereignty is a set of verifiable properties and not a location (AI Platform and Security, Chapter 13) (297, Nordqvist, 2026); a contract right is a promise until the first sample, seed or stop request shows that it works (AI Blue, Chapter 28); and crossing a boundary needs standing consent in the contract, notice before each run and a stop held outside the system stopped on both sides (AI Purple, Chapter 22) (304, Nordqvist, 2026). AI Governance, Chapter 7, treated procurement as governance (296, Nordqvist, 2026); this chapter treats what operations needs from the same contracts.

The service, its providers and second path, the independent probes and stop right outside the providers, and the records that bind them

Figure 24.1: Provider dependencies and exit paths, with the independent probes, the stop right and the records outside the providers.

Concentration

Concentration is a property of the dependency graph and not of the number of vendors. Four providers that all rely on the same name service, identity federation or cloud region are one dependency. The method therefore starts from the dependency map of Chapter 3: for each service, which providers, regions, control planes and shared services (DNS, identity, certificates, monitoring, paging) stand between the user and a working answer.

European law names the forms that matter. DORA requires a financial entity, before contracting, to assess whether an arrangement would add to ICT concentration risk, and Article 29(1) names two forms: a provider that is not easily substitutable, and several contractual arrangements with the same provider or closely connected providers. Article 29(2) adds the subcontracting chain (2, European Union, 2022). Applied to the operations estate, the assessment gives a fourth form: the shared service that every dependency passes through.

Concentration is also observed from above. DORA Article 31(2) lets the European Supervisory Authorities designate critical ICT third-party service providers on criteria that include the systemic impact of a large-scale failure, the reliance of financial entities for critical or important functions and the difficulty of substitution. On 18 November 2025 the three authorities published the designations, which their press release says were based on data from the registers of information that financial entities maintain (7, EBA, 2025). The Lead Overseer can issue recommendations including on single points of failure and concentration risk (Article 35). The register is therefore read by a supervisor, so its accuracy is an operational matter, and designation does not move the entity's responsibility: under Article 28(1) it remains fully responsible whatever the provider does (2, European Union, 2022).

For an entity outside DORA the demand is lighter and of the same shape: NIS 2 Article 21(2)(d) lists supply chain security among the minimum measures and Article 21(3) asks the entity to take into account the vulnerabilities specific to each direct supplier (3, European Union, 2022). That is a duty about security; the book's own reading is that the dependency map lets an operations team answer it for availability as well.

AI services add a concentration of their own: a model served by one provider, or a pool of accelerators reserved from one hosting company, is a dependency with few substitutes whose quality changes when the provider changes the model (Chapter 13). A fallback provider is a new entry in the contract set, and for a financial entity in the register, before it carries traffic.

The two organisations show two shapes. Nordvik Region has one national shared-service provider, SamDrift, behind external DNS, identity federation, the recovery site and the paging of its on-call. Four functions share one failure domain: the DNS fault of 2027-11-08 made the e-services unreachable from outside for 70 minutes (INC-NR-2027-0298), and the portal failover test failed on a DNS time-to-live and an unrenewed certificate at the recovery site (RST-NR-2027-002). Hansa Mutual spreads over its own data centre, two hyperscaler tenancies, a managed service provider and an observability vendor, so its concentration is in the seams and in one provider that appears three times: Cloud B holds analytics, the disaster-recovery copy of the claims core and, since Chapter 15, a managed model service. The recovery path and the fallback path share a provider, the case Article 29(1) describes as multiple arrangements with the same provider.

In an outage

When a provider fails, the question of who is responsible has two answers that are both true. The provider is responsible for its platform and the customer for the continuity of its own service. The customer's design decides how much of the provider's failure reaches the user. Three public post-incident reports show the mechanisms. They are provider-authored, and each is read here for what it states and not beyond it.

Amazon Web Services, US-EAST-1, 19 to 20 October 2025. AWS reports a latent race condition in the DNS management system of DynamoDB that left the regional endpoint with an empty DNS record. DynamoDB API errors ran from 11:48 PM to 2:40 AM Pacific time, about 2 hours 52 minutes; instance launches in EC2 failed until 10:36 AM, connection errors on Network Load Balancer ran until 2:09 PM, and the whole event lasted about 14 hours 32 minutes. AWS disabled the DNS automation worldwide pending a fix (75, AWS, 2025). The mechanism is a dependency the customer did not name: a team that never called DynamoDB directly was exposed through the services that did. A design that needed to launch new capacity during the event had a longer exposure than one that did not, which is the book's inference from the report and from the static-stability principle that a system should keep working through a dependency failure using resources it already has (262, Weiss & Furr, 2019).

Google Cloud, 12 June 2025. Google reports that a policy change with unintended blank fields was written to regional database tables and replicated globally within seconds, and that Service Control binaries, whose new quota-check code path had not been exercised in the regional rollout and lacked a feature flag, entered a crash loop in every region. The incident ran from about 10:51 PDT to 18:18 PDT, about 7 hours 27 minutes. Two statements bear on this chapter. The first incident report appeared about an hour after the crashes began, which the report attributes to the Cloud Service Health infrastructure being down with the outage. And some customers' monitoring, which ran on Google Cloud, failed with it. Among the corrective actions is keeping monitoring and communication infrastructure operational when the platform and its primary monitoring are down (76, Google Cloud, 2025). The mechanism is a global change that multi-region deployment within one provider could not contain, and an observer that sat on the platform it observed.

Cloudflare, 18 November 2025. Cloudflare reports that a database permissions change caused a query to return duplicate rows, which doubled a configuration file for its Bot Management module beyond a limit in the core proxy, and the proxy failed with HTTP 5xx errors. Impact began at 11:28 UTC, the main impact was resolved at 14:30 and all services at 17:06. The team first suspected a large-scale attack, because the alternation of good and bad files resembled one, and the independently hosted status page also failed, which the post calls a coincidence. Dashboard login was impaired because the login challenge service was unavailable (77, Prince, 2025). The mechanism is a provider's first diagnosis being wrong for a period, and a customer's tool for changing configuration sharing a fate with the failure.

The three reports have a common reading, which is the book's own. The provider's timeline is a later account of events that the customer lived through earlier and with less information. The customer's tools for acting (a console, an API, a login) may be among the failed components. And the customer's monitoring is only as independent as its hosting.

Shared responsibility as a runbook

The practical form of shared responsibility is a runbook class for provider outages that acts in a fixed order. It classifies: the on-call engineer checks the independent probes of the observer manifest (Chapter 17) and the provider feeds, and records whether the fault is inside the organisation's domain, the provider's, or unknown. It protects: a change freeze starts at declaration, because an agent with deploy rights has a ceiling of Level 2 inside a freeze (Chapter 4). It degrades: the service moves to its documented degraded mode (Chapter 19). And it communicates what is known, what is not and when the next update comes. It does not fail over across providers by reflex. A failover across providers for a critical function is a Level 1 action in the book's ceilings, decided by the incident commander, because it is reversible only at cost and time and the second provider may be affected by the same event or untested for this load.

What can be undone, and who can stop it

A cross-provider failover changes where data is written, so failback is a second operation with its own risk and measured time, and the decision record states what can be undone and how long it takes. Hansa Mutual's two cross-provider tests show why: the failover of payments from Frankfurt to Cloud A took 1 hour 35 minutes against 2 hours and passed (RST-HM-2027-007), and the restore of the claims core into Cloud B took 5 hours 40 minutes against 4 hours and failed on time (RST-HM-2027-004). One path is proven and the other is a declared design. The stop for a provider's agents acting on the customer's estate is the customer's, held outside the provider's platform: the customer revokes the provider's credentials in its own identity service (Chapter 21).

Provider status as telemetry

A status page is a statement by the provider about itself, and the reports above and the baseline incidents show three limits. It can be late: Nordvik Region's own monitoring saw the SamDrift fault 22 minutes after the provider's status page did, which means the Region's independent probe did not exist. It can fail with the provider: Google's status infrastructure was down with the outage it was meant to report. And it can be the only signal: Hansa Mutual was blind on 14 services for 3 hours 10 minutes when its observability vendor's ingestion failed (INC-HM-2027-0572), and the vendor's status page was the only indication.

The rule of Chapter 17 applies: provider status is telemetry and not a verdict. The design has four parts. The observer polls each provider's feed, machine-readable where offered, and stores each statement with the time it was published and the time it was received. The operations team records when its own independent probe first failed and when the provider declared the incident; the difference, in both directions, measures the observer's quality and the provider's candour, and is reported by provider and service, never by person. A declared incident is mapped to the services that depend on the component, so that the incident commander sees which services are affected and not a list of regions. And an agent may read the feed and annotate the incident record (Level 4 for read and annotate) and notify the internal on-call (Level 3), but it does not fail over, restart or reconfigure on the strength of a feed, because the text is third-party input that can be wrong, late or crafted (Chapter 18). The independent view comes from probes on another network and a heartbeat receiver outside the platform. Hansa Mutual's OBS-HM-0001 lists the feeds of Cloud A, Cloud B and Lumenscope as telemetry and places its probes in Cloud B and the Polish service centre network; Nordvik Region's OBS-NR-0001 places its observer at its hosting provider's Nordic data centre, with a probe that resolves names against authoritative servers directly.

Observable: providers publish post-incident reports of the kind cited above. Expected: contract annexes will increasingly require a machine-readable incident feed with declaration timestamps, since oversight of designated providers runs through records of this kind; the ground is the DORA oversight framework, and this author knows of no data on how many contracts include such a term.

Contracts and registers

A contract is where the provider's duties become something the operator can use. DORA sets out what contracts for ICT services must contain, and its text is the most specific European statement of the terms operations needs. The reading below attributes each provision to its Article and is an organisational implication and not legal advice.

Article 30(2) of DORA requires every contract on ICT services to contain, among other elements, a description of the services and whether subcontracting of services supporting critical or important functions is allowed (point (a)); the locations of service and data processing, with advance notice of change (point (b)); access to, recovery and return of data in an easily accessible format on the provider's insolvency, resolution or discontinuation or on termination (point (d)); service level descriptions (point (e)); assistance with incidents at no extra cost or at a cost fixed in advance (point (f)); and termination rights with minimum notice periods (point (h)) (2, European Union, 2022).

For services supporting critical or important functions, Article 30(3) adds service levels with precise quantitative and qualitative targets (point (a)); notice periods and reporting obligations, including notice of developments that might materially affect the provider's ability to meet the service levels (point (b)); the provider's testing of its contingency plans (point (c)); its full participation in the entity's threat-led penetration testing (point (d)); unrestricted rights of access, inspection and audit for the entity and the competent authority (point (e)); and exit strategies with a mandatory adequate transition period (point (f)) (2, European Union, 2022).

Two further instruments fill in the detail. Delegated Regulation (EU) 2024/1773 requires in its Article 10 a documented exit plan for each arrangement supporting a critical or important function, periodically reviewed and tested, considering at least unforeseen and persistent service interruptions, failed service delivery and unexpected termination (21, European Commission, 2024). Delegated Regulation (EU) 2025/532 requires the contract to state when subcontracting is allowed, to flow monitoring duties down to subcontractors and to give the entity notice of material changes, with a right to object and, in defined cases, to terminate (its Articles 4 to 6) (22, European Commission, 2025).

What the statute does not provide is the operational detail an on-call engineer needs at three in the morning: the format and timeliness of the provider's incident feed, notice of a release to the control plane the customer depends on, the right to run an independent probe, the declaration of the provider's own AI and the stop right over it. These belong in an annex, shown in the worked example below, and extend the six terms of Chapter 21 to the whole provider relationship.

The register of information as an operations artefact

DORA Article 28(3) requires a financial entity to maintain a register of information on all contractual arrangements for ICT services, with those that support critical or important functions distinguished, to report on it yearly to the competent authority and to inform the authority in good time of a planned arrangement that supports a critical or important function (2, European Union, 2022). Commission Implementing Regulation (EU) 2024/2956 sets the templates, which are tables with a fixed set of columns, requires a legal entity identifier (or the European Unique Identifier) for the providers, extends the identifier requirement to subcontractors that effectively underpin services supporting critical or important functions, and holds for each service an assessment of substitutability on four values (not substitutable, highly complex, medium complexity, easily substitutable) and a field recording whether an exit plan exists (20, European Commission, 2024).

The register is a compliance artefact for the second line and, to an operations team, a dependency map in a standard format. The two uses meet at a gate: a fallback that is not in the register is a shadow dependency that carries traffic with no assessed substitutability or exit. The control is a policy check in the change pipeline that refuses a routing or deployment change naming a provider with no register entry (outside DORA, no contract-set entry).

Worked example: register entry for the fallback model service at Cloud B

The record below is illustrative and fictional. It shows how Hansa Mutual's head of operational resilience might record the managed model service of Cloud B that Chapter 15 introduced as the fallback for the claims-triage agent service, written under AIDR-0974 (dated 2029-02-20; reviewers the head of operational resilience, the head of the group AI platform and the chief risk officer). The service supports SVC-HM-002, a critical or important function, for claims whose data tier is internal, so the entry is made as supporting such a function and the competent authority is informed before first use. The field names paraphrase the templates of Implementing Regulation (EU) 2024/2956 and are not their codes.

register_entry:
  arrangement: HM-PROC-CLB-2028-04     # new contract line, existing Cloud B master agreement
  decision: AIDR-0974
  provider: {name: "Cloud B", lei: "held in the register", legal_entities: "EU"}
  other_arrangements_with_provider:    # Article 29(1): multiple arrangements, one provider
    - analytics
    - disaster_recovery_claims_core    # SVC-HM-001; RST-HM-2027-004 failed on time
  service: managed-model-inference     # fallback rung for SVC-HM-002
  supports:
    services: [SVC-HM-002]
    critical_or_important_function: true
    data_tier_max: internal            # routing follows the data class (Chapter 15)
  subcontractors_underpinning_service: "per provider declaration, reviewed yearly"
  locations: {processing: [EU], change_notice_days: 30}
  substitutability: medium_complexity
  alternative: "self-hosted second model, hansa-dc-frankfurt (rung 2, tested 2028-10-26, pass 0.91)"
  exit_plan:
    exists: true
    triggers: [persistent_interruption, failed_delivery, unexpected_termination]
    test: {kind: route-switch-to-rung-2, date: 2028-10-26, result: passed, clock_days: 180}
    next_test_due: 2029-04-24
  authority_informed: 2029-02-27       # before first production use
  change_gate: "routing to this provider refused unless this entry is active"
  review: {every_days: 90, owner: head-of-operational-resilience}

The entry shows three decisions. The arrangement is classified as supporting a critical or important function because SVC-HM-002 is one, whatever the data tier of the fallback. The alternative is the self-hosted rung that the group tests itself, which makes the exit test cheap and frequent. And the same provider appears three times, so if Cloud B fails while Frankfurt is down, the claims core's disaster-recovery copy and the fallback fail together.

For Nordvik Region, outside DORA, the same discipline applies as the Region's own choice: a contract-set register with the same fields, since NIS 2 Article 21 asks for supply chain measures without prescribing a register (3, European Union, 2022).

Exit and switching

An exit plan answers the question of what the organisation does when a provider can no longer be used, and it has two forms that need different tests. A stressed exit is forced by the provider's failure, withdrawal, insolvency or a legal event, and the organisation must move without the provider's help. A planned exit is chosen, for price, quality, jurisdiction or strategy, and the provider is obliged to assist. DORA Article 28(8) requires exit strategies for services supporting critical or important functions that cover provider failure, deteriorating service quality, material risks to continued deployment and termination for the reasons in Article 28(7), and that allow the entity to leave without disruption to its business activities, without limiting compliance with regulatory requirements and without detriment to the continuity and quality of services to its clients; exit plans must be comprehensive, documented, sufficiently tested and reviewed periodically (2, European Union, 2022).

The Data Act and switching

Chapter VI of the Data Act, Regulation (EU) 2023/2854, supplies the mechanics for a planned exit from a data processing service. The Regulation applies from 12 September 2025 (Article 50). In summary, and subject to the legal adviser's confirmation per service of whether it is a data processing service within the Regulation and whether an exception applies (16, European Union, 2023):

  • Contract terms. The contract must set out the switching rights in writing (Article 25(1)). It must provide for a mandatory maximum transitional period of 30 calendar days in which the provider assists, maintains business continuity and keeps data secure (Article 25(2)(a)), support the customer's exit strategy (point (b)), set a maximum notice period for initiating the switch of at most two months (point (d)), list the exportable data and digital assets (point (e)), allow a data retrieval period of at least 30 calendar days after the transitional period (point (g)) and provide for erasure after successful switching (point (h)).
  • Infeasible periods. If the 30 days are technically unfeasible, the provider must say so within 14 working days of the request, justify it and propose a transitional period of at most seven months, and the customer may extend the transitional period once (Article 25(4) and (5)).
  • Charges. Reduced, cost-based switching charges were allowed from 11 January 2024 to 12 January 2027, and from 12 January 2027 providers may not impose switching charges (Article 29).
  • Technical aspects. Providers of infrastructure-type services must help the customer achieve functional equivalence at the destination, and others must offer open interfaces (Article 30); custom-built services and non-production versions are carved out (Article 31).

The two regimes compose. DORA requires a tested exit plan, and the Data Act gives the customer contractual levers that make a planned exit feasible and, since 12 January 2027, free of switching charges; the Regulation also extends the switching terms to in-parallel use of several services, with egress charges at cost (Article 34). Neither makes the exit work. Observable: the instruments are in force. Expected: customers will exercise switching rights more often as charges fall away and exit tests become a supervisory expectation (the ground is the decided instruments and the testing duty in Article 10 of Delegated Regulation (EU) 2024/1773; this author knows of no data on how often switching occurs). Speculation: a fully portable estate in which any service moves between providers at will.

The exit test

An exit test is a restore test whose scenario is the loss of a provider, and it carries the six parts of the claim in Chapter 19. It has three levels of ambition: export the exportable data and assets into a neutral format and rebuild a service from the bundle in a test environment; run the rebuilt service beside the original on a copy of the traffic against the service's quality gate; and switch production, which is done as an actual exit or not at all.

The test finds what a plan does not. The hidden dependencies are the shared services: keys held by the provider, DNS and certificates, identity federation, the observability agent, the paging route and the runbooks themselves. A bundle that restores the data without them has restored a database and not a service. The evidence age follows Chapter 19: the clock is 180 days for a Tier 1 exit test and 365 for Tier 2, and it ends early on any change to the provider, region, serving stack or contract.

For observability the exit has a particular shape. Chapter 5 set instrumentation to the OpenTelemetry standard so that a service can send its signals to another back end; the exit test is a parallel-use period in which a second back end receives the same signals, dashboards and alert rules are rebuilt from code and the SLO burn alerts are compared, with egress charges limited to cost (Data Act, Article 34).

Worked example: exit-test record for a model-serving service at Nordvik Region

The record below is illustrative and fictional. Nordvik Region tests the exit of the internal staff assistant (SVC-NR-006, Tier 2, Mode 4, about 3,200 users, RTO 24 hours) from its reserved accelerators at the European hosting provider (contract NR-2026-031) to a second regional provider, under AIDR-0924 (dated 2029-02-13; reviewers the CISO, the AI architect, the data protection officer and the chair of the union's joint committee). The service is the one whose model runs on open-weight models on reserved capacity, which makes the bundle portable. The test is an exit rehearsal and does not exercise the switching right itself, which only an actual switch does.

restore_test: RST-NR-2029-001
kind: exit                          # scenario: the hosting provider can no longer be used
status: failed
service: SVC-NR-006
claim: serve-from-second-regional-provider
objective:
  elapsed: P5D                      # five working days from the decision to leave
  quality_gate: {metric: held-out-evaluation-pass-rate, threshold: 0.90}
executed:
  date: 2029-02-27
  runner: platform team, Maja Lindqvist responsible
  bundle: [model-weights, serving-config, retrieval-index, prompt-and-skill-versions,
           dns-and-certificate-config, observer-probe-config]
  destination: "second regional provider (placeholder), test tenancy"
measured:
  elapsed: PT31H40M                 # passed the time objective
  retrieval_reindex: PT6H40M
  quality: 0.87                     # failed the gate of 0.90
  measured_by: probe OBS-NR-0001 plus held-out evaluation, not the runner
findings:
  - {id: F1, cause: "serving stack default differed (quantisation); config not in bundle", action: pin-serving-config}
  - {id: F2, cause: "index re-embedding assumed provider-side service", action: export-embeddings}
retest: {due: 2029-04-24, owner: platform-lead}
expiry: {clock_days: 365, ends_on_change: [provider, serving-stack, model-version, contract]}
attested_by: "named person independent of the runner: data protection officer for data return"

The result is a failure by the book's rule: the time objective was met and the quality gate was not, so no claim that the service can leave the hosting provider stands until the re-test passes. The bundle carried the model and not the serving configuration, so the same weights answered differently at the destination, and the embeddings had come from a service the destination did not offer.

Multi-region and multi-cloud

The choice between redundancy within one provider and redundancy across providers is made by failure class and not by principle. The table sets the common designs against the failure classes that the reports and the baseline incidents show.

Failure class Multi-zone in one region Multi-region, one provider Second provider as a tested recovery target Active-active across providers
Zone or hall failure (Nordvik INC-NR-2027-0034, Hansa INC-HM-2027-0961) Helps Helps Helps Helps
Regional failure No Helps, if the control plane the move needs is not in the failed region Helps Helps
Provider-wide control-plane or configuration failure (Google Cloud, 12 June 2025; Cloudflare, 18 November 2025) No No, a global change reaches every region Helps if the second provider is not behind the same dependency Helps, at the cost of seams
Provider commercial, legal or insolvency event No No Helps, and is the exit path Helps
Seam failure between providers (Hansa INC-HM-2027-0833, a routing push) Not applicable Not applicable Adds a new seam Adds the most seams

The table is the book's reading and not a measurement. Multi-region within a provider addresses regional faults and is the cheapest step, and it does not help against a global change of the kind Google reports. A second provider helps against provider-wide faults and exit, at the cost of seams that Hansa Mutual's records show: a configuration push to the gateway that routes across its providers broke the claims assistant in four markets for 47 minutes (INC-HM-2027-0833), and in the Cloud A degradation of 2026 failover to Cloud B was not attempted because the runbook was out of date (INC-HM-2026-0224). Active-active across providers carries the most seams and is justified only where the recovery time objective is shorter than any cross-provider recovery can meet.

Static stability applies: a system that keeps working through a dependency failure using resources it already has (262, Weiss & Furr, 2019). The design rule for operations is to provision the capacity a failure would need before the failure, and to avoid recovery plans that depend on the failed provider's control plane, as the AWS report on instance launches shows.

The book's default, which is its own design and not a finding, is as follows. For Tier 1 services supporting critical or important functions: multi-zone and multi-region in the primary provider, immutable backups in a separate failure domain and, where the recovery objective allows, a second provider as a tested recovery target and not as a running twin. For Tier 2 services: multi-zone in one provider with a documented, tested exit. For the shared services that every dependency passes through (DNS, identity, certificates, the observer): a second, independent provider, because their failure takes everything else with it. For Nordvik Region this last point means a secondary authoritative name service at another provider, which the operations annex below permits and the observer probes. The choice is recorded per service, with the failure classes it covers and the test that shows it.

A second path counts as recoverability only when its test is current: a second provider that has never carried the load is Asserted in the register of Chapter 19, not Verified.

Sovereignty

Sovereignty overlaps this chapter at two points: where workloads run and under which law, and whether the organisation can continue and can leave. The first two are matters of the contract and of publication by the provider (for data processing services, the jurisdiction information of the Data Act's Article 28 is a statutory form of it); the last two are matters of tests (297, Nordqvist, 2026).

The European Commission's Cloud Sovereignty Framework, version 1.2.1 of October 2025, gives a vocabulary. It defines eight sovereignty objectives (SOV-1 Strategic to SOV-8 Environmental Sustainability, among them SOV-2 Legal and Jurisdictional, SOV-3 Data and AI and SOV-4 Operational) and five assurance levels, SEAL-0 No Sovereignty to SEAL-4 Full Digital Sovereignty. The document describes itself as defining the objectives relevant to the cloud services requested in a particular procurement procedure: tenderers must reach a minimum level for each objective and the authority also computes a Sovereignty Score as an award criterion (23, European Commission, 2025). It is therefore a procurement instrument and not a legal requirement, and nothing in this chapter treats a SEAL level as law.

For operations the useful parts are SOV-4 Operational Sovereignty, whose contributing factors include the ease of migrating workloads without vendor lock-in and the capacity of EU operators to run and support the technology without non-EU vendor involvement, and SOV-3 Data and AI Sovereignty, which includes customer-held control over cryptographic access to data (23, European Commission, 2025). An operations team can lift these as questions for a tender. The caution is that a level is a tenderer's claim assessed on answers and evidence, which is a promise until tested. The tests are the ones of this chapter: an exit test shows ease of migration, a stop drill shows that operational control is real, and a key-custody check shows who holds the keys.

Sovereignty also has a concentration cost: a sovereign option that is the only provider of several functions, as SamDrift is for Nordvik Region, adds operational concentration. The remedy is a second path for the shared services and a tested exit.

Observable: the framework exists as a published document written for a Commission procurement procedure; the Data Act's switching provisions are in force. Speculation: that a sovereignty assurance level becomes a legal precondition for public sector cloud use; no instrument known to this author requires one.

Joint exercises

Provider boundaries are tested jointly or not at all, because a customer cannot rehearse a provider's side alone. Four exercises recur, each with a written scope, notice and a stop held outside both parties' platforms (AI Purple, Chapter 22). A client-side outage game day withdraws the customer's own access to a provider component and exercises the provider-outage runbook; it needs no provider consent but has a scope, an abort rule and a stop (Chapter 19). An exit test runs with the provider's assistance where the contract promises it. A joint incident exercise puts the managed provider's night shift and the incident commander through a scripted incident. And a seeded-event test injects an authorised, labelled event into the provider's monitoring to check that it detects, classifies and pages as the annex says, under an injected-test right agreed in advance (AI Purple, Chapter 13).

DORA places part of this in law for financial entities. Article 30(3)(d) obliges the provider, in contracts supporting critical or important functions, to participate fully in the entity's threat-led penetration testing; Article 26(3) requires the entity to ensure the participation of providers in scope; and Article 26(4) allows pooled testing, in which the provider contracts directly with an external tester under the direction of one designated financial entity, where its participation is reasonably expected to harm the quality or security of its services to customers outside the Regulation's scope or the confidentiality of their data (2, European Union, 2022). Threat-led testing has its own authorisation (Chapter 19; the TIBER-EU framework, (35, ECB, 2025)) and is kept apart from the operations exercises in the contract, the manifest and the evidence.

Worked example: contract annex for operational transparency and exit test

The annex below is illustrative and fictional. It is the operations annex that Nordvik Region proposes to add to its framework agreement NR-2026-088 with SamDrift, the national shared-service provider behind external DNS, identity federation, the recovery site and the network operations centre, under AIDR-0924. It combines the six terms of Chapter 21 with this chapter's transparency and exit terms, and the legal adviser confirms under procurement law that it is a permitted modification before it is offered.

annex: OPA-NR-SD-01
agreement: NR-2026-088
decision: AIDR-0924
effective: 2029-03-01
services_in_scope: [external-dns, identity-federation, recovery-site, noc-paging]
change_notice:
  working_days: 20                  # any change affecting DNS, federation, paging or the recovery site
  emergency: {notice_within_working_days: 2}
  hold_on_request: true             # previous version stays in force during notice
status_and_incidents:
  machine_readable_feed: true
  fields: [declared_at, components, regions, severity]
  independent_hosting: true
  preliminary_statement_hours: 4    # after the provider declares the end of an incident
  post_incident_report_working_days: 10
observer:
  customer_probes_from_other_networks: permitted
  secondary_authoritative_dns: permitted   # zone transfer to a second provider
provider_ai:
  declaration: {actions: [alert_closure, paging, remediation], levels: stated, model_version: stated}
  sampling: {per_class_per_quarter: 50, return_working_days: 5}
  model_change_notice_working_days: 20
stop_right:
  held_by: [duty-manager, platform-lead]
  mechanism: customer revokes provider credentials in its own identity service
  provider_agents_cease_within_minutes: 15
  drill: quarterly
tests:
  recovery_site_failover: {per_year: 2, windows_before: [elections, tax-season], notice_days: 30}
  seeded_event: {per_quarter: 1, provider_named_staff: true}
exit:
  exportable: [dns-zones, federation-metadata, recovery-site-config, runbooks-hosted-by-provider]
  transition_period_days: 90
  data_return_format: open
  erasure_certificate_after_retrieval: true
  exit_test: {per_year: 1, record: "RST-NR-*"}
publicity: "annex and incident reports follow the Region's public-access rules"

Practical guide: writing the operational transparency and exit-test annex to a cloud or managed contract

Purpose. Turn the provider's duties into terms that the operations team can use and test, and prove the exit before it is needed.

Roles. The head of operations sponsors; the service owner and the SRE or platform lead write the technical terms; the procurement lead and the legal adviser check the annex against the framework agreement and procurement law; the data protection officer reviews the data terms; for a financial entity the head of operational resilience checks it against DORA Articles 28 to 30 and owns the register entry; the CISO is consulted; employee representatives are informed where the annex creates logs of operators' work (MBL-NR-IT-2027-01, KBV-IT-2024-OPS-03).

Steps.

  1. Draw the dependency map for the services concerned: providers, regions, shared services, subcontractors, tier and, for a financial entity, critical or important functions. Decide per provider to accept, constrain or exit, and record the decision.
  2. Set the change notice. Default: 20 working days for any change to the control plane, DNS, identity, paging or AI, with the previous version kept in force on request, and notice within two working days of an emergency change.
  3. Set incident transparency. Default: a machine-readable status feed with declaration timestamps, a preliminary statement within four hours of the end of an incident and a post-incident report within ten working days; adapt to the customer's own reporting clocks (Chapter 14).
  4. Secure the observer: customer probes from other networks permitted and, for DNS, a secondary authoritative service at another provider.
  5. Declare the provider's AI: levels per action class, sampling (default 50 actions per class each quarter), notice of model change (default 20 working days) and a stop right (default 15 minutes to revoke and cease acting, tested quarterly).
  6. Agree the test calendar. Default: two recovery-site failovers a year with 30 days' notice, placed before the customer's peaks, and one seeded event a quarter.
  7. Write the exit: exportable data and assets, format, transition period and erasure. For services within Chapter VI of the Data Act, treat Article 25 (notice at most two months, transitional period 30 calendar days unless justified, retrieval period at least 30 days) as the floor. For a financial entity add the triggers and testing of Article 10 of Delegated Regulation (EU) 2024/1773.
  8. Enter the arrangement in the register (or contract set) before signature, and add the pipeline gate that refuses routing to an unregistered provider.
  9. Within 90 days of signature run the first sample, seeded event, stop test and exit test, record each with a date and a result, and set the next date by the evidence-age clock (default 180 days for a Tier 1 exit test, 365 for Tier 2).

Definition of done. The annex is in version control and referenced by the service records; the register entry is active and the gate refuses the unregistered; the first four tests have run and their records carry expiry dates; the stop right has been drilled with a time recorded; and the representatives' agreement is referenced where operators' work is logged.

Across the degrees of delegation

A provider's AI acts at a level the provider chose, across all of its clients, and the customer sees it as an event in its own estate. The table sets provider-side actions against the customer's clause, the legal anchor where one exists and the test that shows the clause works. Provider AI at Level 3 Bounded across clients under one model or rule set is the case to write for, because one change alters behaviour for every client at once.

Provider-side action (Mode 0 from the customer's view) Customer's clause Anchor Test that shows it works
Closing or suppressing alerts for the customer's services Levels per alert class, sampling, notice of change to correlation rules Article 30(3)(a) and (b) of DORA for service levels and notice; the six terms of Chapter 21 Quarterly sample of closed items; a seeded event
Restart or scale on the customer's estate Action classes at stated levels, never-list, evidence per action Article 30(2)(a) description of services; Chapter 4 ceilings Sample of actions with runbook, level and verification result
Failover or re-routing between regions or providers Customer decides for critical functions; provider's agent at Level 1 only Chapter 4: fail over is Level 1 across providers for critical functions Joint exercise; evidence from an actual event
Platform-wide configuration or model change Notice period, hold on request, staged rollout, rollback right Article 30(3)(b) notice of developments; Delegated Regulation (EU) 2025/532 Article 5 for subcontracting changes Notice received and checked against change log
Deletion or retention action on customer data Irreversible actions never delegated to the provider's AI without a named customer approver; erasure only after retrieval Article 30(2)(d) data return; Data Act Article 25(2)(g) and (h) Retrieval test; erasure certificate
Disabling the customer's observer or stop path Never delegated; credential revocation held by the customer Chapter 4 Level 4 prohibitions Quarterly stop drill with a time

Observable: providers' monitoring and remediation already embed AI that the customer did not choose (the profile of Alster Managed Services and Lumenscope at Hansa Mutual). Expected: provider AI acting at Level 3 Bounded across clients, since the step from correlation and classification to catalogued remediation is a small one (Chapter 21). Speculation: a fully autonomous provider-run operation with no named human decider on the customer's side, which would contradict the book's thesis that a person remains accountable.

Nordvik Region and Hansa Mutual

Nordvik Region runs a sovereign regional cloud itself and depends on SamDrift for DNS, identity federation, the recovery site and the paging of its on-call, and on a European hosting provider for reserved accelerators. Its decision under AIDR-0924 (2029-02-13) has two parts. The first is the annex OPA-NR-SD-01 to the SamDrift framework agreement, which extends to SamDrift the release-notice principle that INC-NR-2026-0214 taught for TriageSoft, adds a machine-readable feed that would have let the Region use SamDrift's declaration in INC-NR-2027-0298 without waiting 22 minutes for its own monitoring, permits a secondary authoritative name service at another provider, fixes test windows before elections and tax seasons and secures a stop right outside SamDrift's platform; it also makes possible the re-test of the failed portal failover RST-NR-2027-002 with SamDrift's participation. The second is the first exit test, RST-NR-2029-001 on 2029-02-27 for the staff assistant SVC-NR-006: elapsed time within the objective, quality gate missed at 0.87 against 0.90, re-test due 2029-04-24. The Region has no DORA register, keeps a contract-set register on the same fields as its own choice and plans as if its Tier 1 services were in scope of NIS 2 Article 21, since national transposition decides. The annex and incident reports follow the Region's public-access rules.

Hansa Mutual is under DORA for its EU entities, and the head of operational resilience keeps the register of information. Its decision under AIDR-0974 (2029-02-20) enters the fallback model service at Cloud B (HM-PROC-CLB-2028-04) as an arrangement supporting SVC-HM-002, informs the competent authority on 2029-02-27 before first production use and adds the pipeline gate. The concentration assessment records three arrangements with Cloud B and the shared fate of the claims core's disaster-recovery copy and the fallback; the answer is the self-hosted rung in Frankfurt (tested 2028-10-26, pass rate 0.91) and a re-test of the claims-core restore into Cloud B, which RST-HM-2027-004 failed. Alster Managed Services (HM-PROC-MSP-2025-03) and Lumenscope (HM-PROC-OBS-2026-01) are brought under the annex terms before their scope widens, with a parallel-use period for the observability exit. The group's only cross-provider evidence is the Frankfurt-to-Cloud-A failover of payments (RST-HM-2027-007, passed); the path to Cloud B is a declaration until the re-test passes. KBV-IT-2024-OPS-02 applies: measures are reported by provider and service, never by named engineer.

Nordvik's first deliverable is the annex and a second path for DNS; Hansa's is a register entry that the pipeline enforces and a Cloud B restore that passes.

Summary

This chapter treated the boundaries of operations and concerns three of the five functions: O1 Observe, O4 Restore and O5 Sustain. Concentration is a property of the dependency graph: DORA Article 29 names non-substitutable providers, multiple arrangements with one provider and the subcontracting chain. In an outage the provider owns the platform and the customer owns the continuity of its service, and the three public reports of 2025 show a dependency the customer did not name, a global change that multi-region deployment could not contain and a provider diagnosis that was wrong for a time. Provider status is telemetry and not a verdict, and the observer must not share the provider's failure domain.

Contracts turn provider duties into terms. DORA Article 30, the delegated regulations on the contractual policy and on subcontracting, and the register of information give the key provisions, and the register is also a dependency map that the change pipeline can enforce. The Data Act's Chapter VI gives the mechanics of a planned exit, but neither regime makes the exit work: the exit test, with a date, a result and an expiry, is the evidence, and Nordvik's first test failed on its quality gate. Multi-region and multi-cloud are chosen by failure class, sovereignty is verified by tests and joint exercises prove the contract. Chapter 25 turns from the provider's boundary to the operators on this side of it, and to the on-call burden that these dependencies create.

Sources

  1. European Parliament and Council of the European Union. Regulation (EU) 2022/2554 on digital operational resilience for the financial sector (DORA). Official Journal of the European Union, 27 December 2022. (2, European Union, 2022)
  2. European Parliament and Council of the European Union. Directive (EU) 2022/2555 on measures for a high common level of cybersecurity across the Union (NIS 2 Directive). Official Journal of the European Union, 27 December 2022. (3, European Union, 2022)
  3. European Central Bank. TIBER-EU: Threat Intelligence-Based Ethical Red Teaming framework. ECB, framework document dated January 2025. (35, ECB, 2025)
  4. Nordqvist, G. (2026). AI Governance: Governing Artificial Intelligence in European Enterprises and Public Authorities. The Transformed Architecture, Book 2. (296, Nordqvist, 2026)
  5. Nordqvist, G. (2026). AI Platform and Security: Building and Securing AI Platforms in European Enterprises and Public Authorities. The Transformed Architecture, Book 3. (297, Nordqvist, 2026)
  6. Nordqvist, G. (2026). AI Purple: How Red and Blue Learn Together When AI Joins the Loop in European Enterprises and Public Authorities. The Transformed Architecture, Book 9. (304, Nordqvist, 2026)
  7. Amazon Web Services (2025). Summary of the Amazon DynamoDB Service Disruption in the Northern Virginia (US-EAST-1) Region. AWS post-event summary, 19-20 October 2025. (75, AWS, 2025)
  8. Google Cloud (2025). Multiple GCP products are experiencing Service issues (incident of 12 June 2025). Google Cloud Service Health incident report. (76, Google Cloud, 2025)
  9. Prince, M. (2025). Cloudflare outage on November 18, 2025. Cloudflare Blog, 18 November 2025. (77, Prince, 2025)
  10. Weiss, B. and Furr, M. (2019). Static stability using Availability Zones. Amazon Builders' Library, 5 December 2019. (262, Weiss & Furr, 2019)
  11. European Parliament and Council of the European Union. Regulation (EU) 2023/2854 on harmonised rules on fair access to and use of data (Data Act). Official Journal of the European Union. (16, European Union, 2023)
  12. European Commission (2024). Commission Implementing Regulation (EU) 2024/2956 laying down implementing technical standards for the application of Regulation (EU) 2022/2554 with regard to standard templates for the register of information. Official Journal of the European Union, 2 December 2024. (20, European Commission, 2024)
  13. European Commission (2024). Commission Delegated Regulation (EU) 2024/1773 supplementing Regulation (EU) 2022/2554 with regard to regulatory technical standards specifying the detailed content of the policy regarding the contractual arrangements on the use of ICT services supporting critical or important functions provided by ICT third-party service providers. Official Journal of the European Union, 25 June 2024. (21, European Commission, 2024)
  14. European Commission (2025). Commission Delegated Regulation (EU) 2025/532 supplementing Regulation (EU) 2022/2554 with regard to regulatory technical standards specifying the elements that a financial entity has to determine and assess when subcontracting ICT services supporting critical or important functions. Official Journal of the European Union, 2 July 2025. (22, European Commission, 2025)
  15. European Commission (2025). Cloud Sovereignty Framework, Version 1.2.1. Directorate-General for Digital Services, October 2025. (23, European Commission, 2025)
  16. European Banking Authority, EIOPA and ESMA (2025). European Supervisory Authorities designate critical ICT third-party providers under the Digital Operational Resilience Act. Press release, 18 November 2025. (7, EBA, 2025)