Governance & Compliance complete

Ask who owns the question of provider dependency and data jurisdiction at the organisation, and request whatever policy or terms of reference governs it. The expected answer at this level is that no such role or document exists: nobody is accountable for which providers the organisation cannot tolerate losing, where regulated data is processed, or under which legal regime a counterparty could be compelled to disclose it. The existence of an IT or security policy that never names jurisdiction, provider concentration, or exit does not satisfy any higher level and confirms this one.

Request any record showing the organisation has assessed the legal jurisdiction of its critical providers or the location of its regulated data on its own initiative. Look for the trigger behind any assessment that does exist: if the only such records were produced in response to an external audit, a regulator query, or a renewal deadline, the posture is reactive and sits at this level. A reactive answer to a CLOUD Act or transfer question, produced once under pressure and never maintained, confirms the criterion rather than refuting it.

Ask the organisation to evidence its compliance posture and observe what it produces. At this level the answer is the provider's certificates and attestations rather than the organisation's own assessment of its provider dependency, data jurisdiction, or exit options. Confirm the distinction the organisation itself may not draw: an ISO 27001 or SOC 2 report describes the provider's controls over the provider's environment, not the organisation's governance of which providers it depends on or where its regulated data is processed. A compliance file that consists only of supplier certificates, with no organisation-authored assessment of jurisdiction or concentration risk, places the organisation at this level.

Request the terms of reference, charter, or process description for whatever body reviews technology procurement and architecture decisions, and check whether sovereignty is a stated review dimension. At this level either no such body exists, or it reviews cost, security, and functionality but never asks where a new service processes data, which legal regime governs the provider, or how the organisation would leave. Minutes or decision records that never reference jurisdiction, provider concentration, or exit confirm the criterion. A body that discusses these questions informally but records no decision against them does not lift the organisation above this level, because the evaluation is not governed.

Request the AI tool onboarding log. Each entry should cover at minimum: the SaaS tool and the specific AI feature being enabled, the categories of data the feature will be exposed to (personal data, customer content, source code, internal documentation), the named business owner accountable for usage, and the date the review was completed. The review process itself can sit inside an existing procurement, change management, or vendor onboarding workflow; it does not need a dedicated committee at this level. Acceptable evidence is a populated review record per AI-enabled tool now in use, not the existence of a blank template. A blanket statement that 'all SaaS goes through procurement' without an AI-specific review step does not satisfy this criterion, because the AI feature surface routinely activates after the SaaS tool itself was onboarded.

Request the compliance programme's policy set and read it for sovereignty substance, not just structure. The policies should state the organisation's own position: in which jurisdictions regulated data may be processed, what degree of provider concentration is acceptable for critical functions, and the expectation that critical services remain exitable. Confirm each policy names an accountable owner and a review cadence. A policy suite that covers data protection and security in the abstract but never commits the organisation to a stance on jurisdiction, provider dependency, or exit is a generic compliance programme and does not satisfy this criterion, which is specifically about governing sovereignty. Templated policies adopted without tailoring to the organisation's actual provider estate also fall short.

Sample the executed contracts for the organisation's critical services and confirm they bind the provider to the obligations the governance framework requires: defined compliance commitments, audit or inspection rights, disclosure of sub-processors and the jurisdictions in which the service operates, and regular reporting against those obligations. The test is alignment, so cross-check the contract terms against the policy positions from C1: a contract that omits jurisdiction transparency or sub-processor disclosure leaves the organisation unable to govern the dependency it has accepted. Standard provider terms accepted without amendment, where they lack these provisions, do not satisfy this criterion. Audit rights that exist on paper but are contractually impossible to exercise against a hyperscaler should be recorded as a known residual limitation.

Request the AI usage policy and the description of how it is enforced. The policy text should at minimum enumerate approved AI tools, prohibited tools or categories (for example consumer-tier chat assistants for confidential data), the data classes that may flow to AI features and those that may not, and the consequences of breach. The enforcement description should name a mechanism: tenant-level allowlists at the identity provider or proxy, DLP rules that block submission of restricted data classes to AI endpoints, browser-extension governance, periodic attestation by line managers, or a documented disciplinary route. A policy that exists as a PDF on an intranet with no described enforcement path does not satisfy this criterion. Awareness training alone is awareness, not enforcement.

Request the AI Act risk register. Each entry should name the AI system, its purpose in the organisation, the role the organisation plays under the AI Act (provider, deployer, importer, distributor), the provisional risk classification, the AI Act articles or Annex III categories used to reach that classification, and the date of the most recent classification review. Where the system is provisionally classified as high-risk, the register should reference the additional obligations triggered (Art 16 onwards for providers, Art 26 for deployers) even if the implementation work itself sits in other dimensions. A register that lists tools without rationale, or that classifies everything as minimal-risk by default, does not satisfy this criterion. Tools where classification is genuinely uncertain should be recorded as 'pending classification' with an owner and a target date, not omitted.

Request the register. Each critical provider entry should record the legal regimes the provider is subject to, including parent-company exposure (a European subsidiary with a US parent remains reachable under the CLOUD Act regardless of where the data sits), the transfer mechanism relied on (adequacy decision, standard contractual clauses, certification framework), and the date of last review. Confirm the register is updated when the provider estate changes, not on an annual cycle alone. A register that records only the contracting entity's jurisdiction and ignores corporate parentage, or one that has not tracked a known provider change, does not satisfy this criterion.

Request the board's charter, membership, and recent decision records. Confirm it has executive sponsorship, draws members from beyond IT (legal, procurement, data protection, the business), and treats jurisdiction, provider concentration, and exit as standing review criteria rather than occasional topics. The decisive evidence is authority: look for at least one decision where the board blocked, deferred, or attached sovereignty conditions to a technology choice that would otherwise have proceeded. A board that reviews decisions but cannot influence them, or whose minutes show only ratification of choices already made, sits below this criterion. A purely advisory forum with no decision rights does not satisfy it.

Ask how the organisation would learn that a provider moved processing to a new region, added a sub-processor in a different jurisdiction, or that a critical function had become concentrated on a single supplier, and how quickly. Acceptable evidence is monitoring that draws on data the organisation holds or controls: configuration and residency checks against cloud accounts, automated tracking of sub-processor disclosures against the approved baseline, and a posture dashboard fed by those signals. The criterion is about monitoring sovereignty drift specifically, not general control health, so a SOC-style controls dashboard that reports security posture but never surfaces a residency or jurisdiction change does not satisfy it. Monitoring that depends entirely on the provider self-reporting a change, with no organisation-held check, is a weaker form and should be recorded as a residual dependency.

Request the shadow-AI control inventory. Acceptable mechanisms include identity-provider blocks on unsanctioned AI SaaS sign-ins, network egress controls or secure web gateway rules that prevent or log access to consumer AI endpoints, browser-extension governance through the managed browser policy, an enterprise AI gateway that all approved AI traffic is routed through, and DLP detections specific to AI submission patterns. Evidence is the configured rule set or policy plus a recent review log showing the control surface is updated when vendors add AI features to existing approved SaaS tools (a frequent gap, since the SaaS itself was approved before the AI feature existed). A statement that 'the AI usage policy prohibits this' without a corresponding technical control does not satisfy this criterion at Level 3, where contractual posture is expected to be backed by enforcement. Where blocking is not feasible for a category, monitoring with a defined review cadence is acceptable, and the residual risk should be recorded.

Ask where the organisation's sovereignty policy and risk positions originate, and trace the most recent significant change to its source. At this level the policy is authored and maintained internally from the organisation's own assessment of its provider estate, data flows, and legal exposure, rather than adopted wholesale from a supplier framework or a consultancy template the organisation cannot evaluate or amend. External standards and advice may inform the position, but the organisation must be able to set, justify, and revise its own direction without that input being load-bearing. A governance model whose direction would lapse if a particular external assessor or provider relationship ended does not satisfy this criterion.

Request the organisation's most recent internal sovereignty assurance cycle: who ran it, what it covered, and what it produced. Confirm the organisation can assess its own posture across the control matrix from capability it holds, audit its critical dependencies, and evidence the result without that verification resting on an external party it cannot replace. Provider attestations and third-party audits may still be used as inputs, but the assurance judgement and the evidence must be the organisation's own. An assurance posture that exists only as a purchased annual assessment, with no internal capability to verify posture between or independently of it, sits below this criterion.

Request the continuity plan for the governance function. Confirm it names deputies or successors for policy authorship and for running the assurance cycle, that the assessment methodology is documented well enough for a successor to re-run it without its original author, and that the arrangement has been demonstrated, through an actual personnel change or a deliberate handover exercise. A plan in which one person is simultaneously the policy author, the assurance operator, and the only named reviewer does not satisfy this criterion.