Criteria Library

Review onboarding documentation and system admin interfaces; check whether a directory service (LDAP, AD, cloud IdP) exists

Audit login records and account inventories across critical systems; look for accounts used by more than one natural person

Confirm that the identity provider is a SaaS-only service; verify there is no secondary IdP or directory synchronisation to an on-prem store

Verify that MFA methods (push notifications, TOTP seeds, SMS) are entirely managed within the provider's console; confirm the organisation does not operate any independent authentication factor (e.g., own FIDO2 key management, own TOTP issuer)

Check the IdP's data-residency settings; review the provider's sub-processor list for identity-related data flows

Ask whether the organisation maintains any access inventory outside the provider's console; determine if access data can be exported in a machine-readable format for independent analysis

Obtain the signed DPA; verify it includes jurisdiction-specific data-residency commitments (e.g., EU-only processing), a sub-processor notification mechanism, and the right to conduct or commission audits

Review federation configurations; confirm the organisation controls the SAML/OIDC metadata URLs and signing certificates, and that relying parties are registered under organisation-owned domains

Request evidence of the last two access review cycles; confirm that review results are archived outside the provider's platform (e.g., in an internal GRC tool or document management system)

Inspect the identity architecture diagram; confirm the self-managed IdP is the master directory and that cloud IdPs (e.g., Entra ID, Google Workspace) are configured as federation targets or downstream consumers via SAML/OIDC

Confirm that the MFA enrolment, seed generation, and verification for privileged accounts are handled by the self-managed IdP or organisation-owned hardware, not by an external provider's authentication service

Request documentation of the DR/migration plan; verify that identity data is regularly exported in a portable format (SCIM, LDIF, or equivalent) and that a failover test has been conducted within the past 12 months

Audit the complete identity stack; confirm that no component relies on an external SaaS provider for runtime operation. Verify hosting location through infrastructure documentation and physical or virtual audit.

Conduct an isolation test: simulate complete external connectivity loss and verify that internal authentication and authorisation continue to function. Review the dependency map for any external call-outs during authentication flows.

Inspect HSM deployment and key-management procedures; confirm that identity-critical keys are generated on-premises, never exported in plaintext, and rotated on a documented schedule

Review whether DID/VC infrastructure is deployed or a documented implementation plan exists; confirm that the organisation can issue and verify credentials without depending on a third-party identity federation service

Request the organisation's encryption policy or information security policy. Absence of any documented encryption requirements satisfies this criterion.

Interview IT leadership regarding who holds encryption keys and where key material resides. Lack of knowledge or 'the cloud provider handles it' responses confirm this criterion.

Request documentation of key rotation policies or automated rotation configurations. Complete absence satisfies this criterion.

Review the organisation's encryption policy or relevant section of the information security policy. Confirm it requires encryption for data at rest and in transit.

Request an inventory of encryption services in use. Verify that specific provider encryption mechanisms are named and mapped to workloads.

Review risk registers or dependency documentation for explicit acknowledgement that the cloud provider controls key material.

Review the DPA for clauses covering encryption key management, key access conditions, and key custody responsibilities. Confirm these are specific rather than generic security references.

Review service agreements or order forms for BYOK/CMK entitlements. Confirm the organisation has the contractual right to manage its own keys.

Request the key management procedure. Verify it covers the full key lifecycle and assigns responsibilities for each stage.

Review risk assessments or technical architecture documentation acknowledging that BYOK in cloud KMS does not fully eliminate provider access to key material in memory during cryptographic operations.

Request the AI artefact data map. Each entry should name the artefact class (prompt and completion logs, embedding vectors, vector index, fine-tuned model weights, RAG document store), the storage region, the storage system (vendor-managed, customer subscription, third-party model provider's infrastructure), and which party holds the keys protecting it. A map that covers the primary SaaS data tier but is silent on AI-derived artefacts does not satisfy this criterion. Where the vendor refuses to disclose the storage location or custodian for an artefact class, the gap is recorded as a residual risk.

Review key management architecture documentation. Verify HSM-backed key storage (e.g., AWS CloudHSM, Azure Dedicated HSM, or third-party HSM) is used rather than standard cloud KMS. Confirm the provider cannot extract plaintext key material.

Request HSM deployment location documentation. Verify that HSM instances and key material are deployed in EU/Swiss data centre regions with no cross-border replication.

Review automated key rotation configurations. Confirm that rotation is triggered by customer-managed automation, not by the provider's default rotation mechanisms.

Review key rotation schedules and confirm rotation frequency varies according to data classification policy (e.g., more frequent rotation for higher-sensitivity data).

Review encryption architecture documentation for envelope encryption design. Verify KEKs are stored in customer-controlled HSMs and DEKs are wrapped/unwrapped using customer-controlled operations.

Inspect on-premises HSM deployment (e.g., Thales Luna, Utimaco SecurityServer, Entrust nShield). Verify HSMs are physically located in customer-controlled facilities with no cloud provider involvement in HSM operations.

Review key ceremony documentation including procedures, witness logs, custodian assignments, and tamper-evident bag records. Verify ceremonies are conducted in physically secured, customer-controlled environments.

Review architecture documentation confirming key material never transits provider infrastructure in plaintext. Verify that cryptographic operations occur within customer-controlled boundaries (on-premises HSM, secure enclave, or confidential computing environment).

Inspect the key management system deployment (e.g., HashiCorp Vault Enterprise on-premises, Thales CipherTrust Manager, Fortanix DSM). Confirm it operates on customer-owned infrastructure and manages keys across all environments without provider dependencies.

Absence of any policy document, board resolution, or architectural guideline referencing data location.

Confirm that no data-location register, CMDB entries, or cloud-account region reports have been produced.

Review cloud console settings or infrastructure-as-code templates; default or auto-selected regions indicate this criterion is met.

Cloud console screenshots, provider documentation, or account settings showing region assignments.

Review master service agreements and DPAs - confirm absence of region-restriction clauses.

Internal communications, meeting minutes, or risk assessments acknowledging data location without mandating controls.

Executed DPAs with region-restriction clauses; legal review confirming coverage of all Tier-1 providers.

Signed SCC addenda (EU 2021/914 modules) with documented transfer impact assessments (TIAs).

Completed TIA documents referencing provider jurisdiction, government access laws, and supplementary measures adopted.

Risk register entry or data flow diagram identifying metadata and ancillary data flows that fall outside DPA region restrictions.

For each provider involved in cross-border processing, confirm the named transfer mechanism is recorded in the data transfer register or equivalent. Verify a contingency plan exists describing what the organisation would do if SCCs are tightened by an EDPB or CJEU decision, if the EU-US Data Privacy Framework is invalidated (Schrems III scenario), or if an adequacy decision is withdrawn. The plan should identify the affected workloads, an alternative legal basis or fallback provider, and the expected timeline to switch. Generic statements that 'we would consult counsel' do not satisfy this criterion.

Review the AI clauses of each SaaS DPA. The inference-region restriction must name the regions where the model is hosted and prompts are processed (e.g. EU Data Boundary, Switzerland-only inference, Azure OpenAI EU regions); a clause that restricts only primary data storage and is silent on inference does not satisfy this criterion. For the metadata gap, evidence is a residual-risk register entry that explicitly enumerates AI-feature data flows excluded from the residency commitment, such as prompt preview caches, model-routing telemetry, abuse-monitoring buffers, and aggregated usage metrics. A blanket 'metadata may be processed elsewhere' line in the DPA without an organisation-side acknowledgement is insufficient.

Cloud provider region-lock configurations, infrastructure-as-code templates with explicit region constraints, or sovereign cloud zone assignments.

Replication policies, disaster recovery configurations, and backup target settings showing only approved regions.

Collect both layers. Provider-attested layer: current SOC 2 Type II report, ISO 27001 certificate, or written regional service commitment from the provider. These confirm the provider's general control framework, not your tenant's residency. Organisation-verified layer: your own evidence that the controls held for your workloads, such as resource-level region tags from inventory exports, traceroute or endpoint geo-IP records confirming requests resolve to EU/Swiss regions, contractual residency-incident notification logs, or records of audit rights exercised against the provider in the past 12 months. A SOC 2 report alone does not satisfy this criterion.

Evidence has two layers. Configuration: tenant participation in EU Data Boundary for Microsoft 365 and Copilot, Azure OpenAI deployment in an EU region with regional endpoint enforcement, GitHub Copilot Business with documented inference geography, or an equivalent vendor-specific control. Verification: tenant-scoped logs, region-tagged audit records, or written attestation specific to the tenant confirming the AI feature ran in the named region during the assessment window. A general statement that the vendor 'offers EU inference' without tenant configuration evidence does not satisfy this criterion. Where a vendor cannot expose the routing region per tenant, the criterion is unmet for that vendor.

Data centre contracts and facility addresses confirming all infrastructure resides in approved jurisdictions.

Corporate ownership documentation (commercial register extracts, shareholder disclosures) confirming no US or other foreign-jurisdiction parent entity.

Network flow analysis, firewall rules, and egress monitoring confirming zero cross-border data flows. DNS, NTP, and update channels verified as domestic or EU-based.

Physical access logs, facility security audit reports, and contractual audit-right clauses. For co-location: proof that facility operator is domestically owned.

Access control policies, VPN and bastion host configurations, and HR records confirming all administrative personnel are based in approved jurisdictions.

Request processing location documentation from the provider; review service agreements for any mention of data processing locations or infrastructure details

Review the provider's terms of service and privacy policy for clauses granting broad processing rights; check for opt-out mechanisms

Ask the provider for a sub-processor list; review data flow diagrams if available; check whether sub-processor notifications are part of the contract

Review provider dashboards and service documentation for region settings; confirm whether region selection is advisory or enforced; check for region-pinning capabilities

Review provider architecture documentation; check whether dedicated hosts, isolated VMs, or tenant separation mechanisms are available or in use

Compare the active agreement against a formal DPA template; identify whether purpose limitation, data minimisation, or processing restrictions have been negotiated

Request the AI feature inventory or the AI section of the SaaS register. Each entry should name the tool, the AI capability (chat, code completion, summarisation, embeddings), and the data categories that reach the AI feature (source code, customer records, internal documents, calendar contents). An inventory that lists tools without documenting the data flowing into them does not satisfy this criterion.

Review executed DPAs for completeness against GDPR Art 28(3) requirements; verify that processing purposes are explicitly enumerated and not open-ended

Obtain current sub-processor lists from each provider; verify notification and objection mechanisms in the DPA; check whether sub-processor changes have been reviewed in the past 12 months

Review whether the organisation has any means beyond the provider's word to verify processing location; check for independent audit results, infrastructure transparency reports, or technical verification mechanisms

Review DPA for data minimisation commitments; assess whether the provider's actual data collection aligns with minimisation principles through data flow analysis

For each processor involved in cross-border processing, confirm the named transfer mechanism appears in the Art 30 record of processing activities or equivalent. Verify the contingency plan describes what the controller would do if SCCs are tightened, the EU-US Data Privacy Framework is invalidated (Schrems III scenario), or adequacy is withdrawn. The plan should identify affected processing operations, an alternative legal basis or fallback processor, and the expected timeline. A DPA without this transfer-mechanism layer does not satisfy this criterion.

Review the AI-specific clauses in each DPA. The no-training clause must explicitly cover prompts, uploaded files, completions, and any derived embeddings or fine-tuning signals. A clause that prohibits training only on inputs (and is silent on outputs or derived data) does not satisfy this criterion. Confirm the underlying model provider (OpenAI, Anthropic, the SaaS vendor's own model team, or whichever party operates the inference endpoint) is named in the sub-processor list. Generic 'AI service providers' references without entity names do not satisfy this criterion.

Review deployment configurations for TEE/enclave usage (e.g., Intel SGX, AMD SEV, ARM TrustZone); verify attestation mechanisms are active; check provider documentation for confidential computing guarantees

Review infrastructure-as-code for region-pinning configurations; verify that deployment policies block non-approved regions; test whether workloads can be launched in restricted regions

Review audit log configurations; verify that provider admin access is logged; confirm log storage is in an organisation-controlled location (separate account, SIEM, or on-premises)

Inspect the tenant configuration for each AI-enabled SaaS tool. The no-training control must be a setting the organisation can read back, screenshot, and re-verify (e.g. M365 Copilot tenant data-handling settings, GitHub Copilot Business policy, OpenAI enterprise zero-retention configuration). A contractual no-training clause without a corresponding tenant control does not satisfy this criterion. For inference-region confinement, evidence is the documented model-routing region (EU Data Boundary participation, Azure OpenAI EU region pinning, regional inference endpoint selection) supported by provider attestation specific to the tenant. Where a SaaS vendor cannot expose either control, the criterion is unmet for that tool.

Review infrastructure inventory and hosting contracts; verify that processing hardware is exclusively allocated; confirm no fallback to shared cloud infrastructure exists

Review access control policies and network architecture; verify that remote access by vendors is disabled by default; audit access logs for any third-party access events

Inspect network architecture for air-gapped segments; verify physical isolation (no network interfaces, disabled wireless, controlled USB ports); review data transfer procedures for air-gapped environments

Review hardware procurement procedures for supply-chain integrity; verify firmware signing and validation; audit OS and runtime build pipelines for reproducibility and integrity checks

Request documentation of legal review for the five most critical cloud services. Absence of any review records satisfies this criterion.

Request the register of DPAs or equivalent processor agreements. Complete absence or inability to produce any signed DPA satisfies this criterion.

Interview IT and procurement leadership regarding governing law and dispute resolution clauses in active contracts. Inability to answer confirms this criterion.

Collect signed DPAs and compare them against the provider's publicly available standard DPA. Identical or near-identical text confirms this criterion.

Review the governing law and dispute resolution clauses in the top five cloud contracts. Acceptance of non-local jurisdiction without documented risk assessment confirms this criterion.

Review the change-of-terms and sub-processor notification clauses in active agreements. Unilateral provider rights with notification-only obligations confirm this criterion.

Compare executed DPAs against the provider's standard template. Identify negotiated amendments documented in addenda, side letters, or redlined versions. At least three material amendments must be evidenced.

Request executed SCCs (EU Commission Module 2 or Module 3 as applicable) and associated Transfer Impact Assessments (TIAs) for each cross-border transfer. Both must exist for each transfer to satisfy this criterion.

Request the sub-processor monitoring log showing receipt dates, change descriptions, and tracking entries for all provider notifications within the past 12 months.

Request the sub-processor review procedure, evidence of review assessments when new sub-processors were notified, and any objection correspondence sent to providers.

Request legal review memoranda, risk assessments, or counsel opinion letters for the top five cloud service agreements. Substantive analysis - not mere checkbox review - must be evidenced.

Request the legal review memorandum covering the AI clauses of each material SaaS agreement. The memorandum must address each of the four questions explicitly. Output ownership: who owns the completion or generated artefact, and on what terms. Training-data grants: whether inputs, outputs, or derived signals (embeddings, fine-tuning data, telemetry) may be used to train or improve the vendor's or any sub-processor's models. IP indemnity: whether the vendor accepts liability for third-party IP infringement claims based on outputs, and any caps or carve-outs on that indemnity. Model-swap notice: the contractual notice period, change-of-model categorisation (material vs cosmetic), and customer rights when the underlying model changes. A review that confirms 'AI clauses present' without addressing these four questions does not satisfy the criterion.

Review the master service agreement for each critical cloud service. The agreement must be a bespoke or enterprise-negotiated contract (not amended standard ToS) with an EU or Swiss governing law clause and a local dispute resolution forum.

Review termination clauses in enterprise agreements. Customer termination rights must exist beyond simple convenience termination, covering at least material breach, change of control, and regulatory necessity scenarios.

Review exit and termination clauses for data portability provisions. Contracts must specify the data format (e.g., open standards), extraction timeline (e.g., 90 days), and provider obligations to assist with migration.

Request executed escrow agreements with a reputable escrow agent. Review release conditions and verify that escrow deposits are current (updated within the last 12 months).

Review the CLOUD Act mitigation strategy. Evidence must include both contractual provisions (challenge commitments, notification obligations, EU entity operations) and technical or structural measures (encryption architecture, access controls, EU data boundary programmes).

Review the executed amendments to each material SaaS agreement. The training-grant amendment must narrow or remove vendor rights to use inputs, outputs, embeddings, fine-tuning signals, or telemetry to train or improve any model, and any residual permissions must be specifically scoped (e.g. abuse detection only, with retention and deletion timelines). The IP-grant amendment must remove broad licences over customer content beyond what is needed to provide the AI feature. The bilateral exit trigger must give the customer a documented right to terminate or to suspend the AI feature without standard exit penalties when one of three named events occurs: a material model swap, a weakening of the no-training posture, or a change in the named AI sub-processor chain. Standard 'change of service' clauses without these specific triggers do not satisfy this criterion.

Review the corporate structure and ownership chain of all infrastructure and service providers. Verify through commercial register extracts that no foreign entity has ownership, control, or contractual rights that could trigger foreign government access obligations. Self-hosted infrastructure satisfies this criterion directly.

Request a software bill of materials (SBOM) for critical services. Verify that all components are available under recognised open-source licences (e.g., MIT, Apache 2.0, GPL, AGPL). No proprietary components should exist in the critical path.

Conduct a comprehensive legal review of all contracts, corporate structures, and service arrangements. A legal opinion from qualified counsel confirming zero foreign law exposure must be available.

Ask the organisation to identify where its logs are stored and who can access them. Inability to answer satisfies this criterion.

Review cloud provider logging configurations and ask operations staff whether any log aggregation or review process exists.

Verify that logging services such as AWS CloudWatch, Azure Monitor, or GCP Cloud Logging are enabled. Confirm that no external log aggregation or SIEM is in use.

Review log retention configurations in the provider console. Check whether custom log schemas or formats have been defined. Provider-default settings with no organisational override satisfy this criterion.

Attempt to export a representative log dataset. Check whether automated export pipelines (e.g., to S3, Azure Blob, or an external SIEM) are configured. Absence of automated export satisfies this criterion.

Review the DPA and service agreements for explicit clauses on log retention, log types, and export rights. Generic clauses without specific retention periods do not satisfy this criterion.

Verify the existence of automated log export configurations (e.g., CloudWatch Subscription Filters, Azure Event Hub export, Pub/Sub to external storage). Check that exports are current and not stale.

Request the log retention policy document. Confirm that retention periods meet regulatory minimums (e.g., 1 year for NIS2, up to 5 years for DORA).

Confirm that log data passes through provider infrastructure before reaching the organisation's storage. Verify that no log integrity mechanisms (e.g., hash chains, write-once storage) are in place on the organisation's copy.

Request the vendor's documentation of AI activity logging (e.g. Microsoft Purview audit logs for Copilot, GitHub Copilot Business audit log API, OpenAI enterprise audit log export). For each AI-enabled tool, document four facts: which prompt and completion fields are captured, the retention period (vendor default and any tenant override), who within the vendor can read the logs, and the export channel and conditions available to the customer. A vendor that offers only aggregated usage metrics without per-event prompt and completion records does not satisfy this criterion; record that as a gap rather than treating metrics as audit evidence.

Verify the SIEM deployment (e.g., Wazuh, ELK, OpenSearch, Graylog). Confirm it is the primary platform used for log analysis and security alerting, not a secondary or unused installation.

Verify the physical location of SIEM storage infrastructure. Review data residency configurations and confirm that log replication or backup does not cross jurisdictional boundaries.

Inspect the storage configuration of the organisation's log archive. Confirm one of: WORM media, object-lock retention in Compliance mode (not Governance mode, which providers can override), or a hash-chain implementation with a verification procedure. A retention policy alone does not satisfy this criterion - the control must be technical and verifiable.

Verify that provider admin-action logs (e.g., AWS CloudTrail management events including provider-initiated actions, Azure activity logs covering Microsoft support sessions, GCP Cloud Audit Logs Admin Activity stream) are forwarded into the organisation's SIEM and stored under the organisation's tamper-evident custody. Confirm coverage of provider-side support sessions where contractually surfaced (e.g., Customer Lockbox events, AWS Support session logs).

Verify that AI activity logs from each AI-enabled tool (Microsoft Purview audit events for Copilot, GitHub Copilot Business audit log feed, OpenAI enterprise audit log export, or equivalent) are ingested into the organisation's SIEM and stored under the same tamper-evident custody as other audit data. Run a reconstruction test on a recent AI-feature event: evidence is satisfactory if the SIEM record names the user, the prompt content (or a deterministic reference to retrievable prompt content), the completion or output identifier, and the model or model version that produced the response. A trail that shows only that an AI feature was used, without the content needed to reconstruct what happened, does not satisfy this criterion. Where a vendor cannot expose this surface, the gap is recorded and the criterion is unmet for that tool.

Verify that the SIEM, log storage, and analysis platforms run on infrastructure owned or directly leased by the organisation (co-location or on-premises). Confirm that no component of the logging pipeline depends on a cloud provider's compute, storage, or networking services.

Review the cryptographic signing mechanism for log entries. Verify that signing keys are held in an HSM or equivalent secure key store under organisational control. Confirm that timestamps are obtained from a qualified TSA (e.g., RFC 3161 compliant) independent of the cloud provider.

Inspect the air-gapped archive facility. Verify physical isolation (no network connectivity). Review the procedures for transferring log data to the archive and for retrieving records during investigations. Confirm that archive integrity is periodically verified.

Verify that the organisation operates independent telemetry collection (e.g., osquery, Beats, Fluentd, custom agents) that provides forensic coverage without relying on provider-generated log data as the sole source.

Request documentation of DNS registrars, nameserver providers, CDN services, and ISP contracts; verify whether a network dependency register exists in any form (spreadsheet, CMDB, wiki)

Ask who can make changes to DNS records, firewall rules, or routing configuration; determine whether the organisation would know if a provider made unilateral changes to its network setup

Audit DNS registrar account ownership, CDN console access, and ISP portal credentials; check whether accounts are registered under personal email addresses or shared credentials

Identify the DNS registrar and nameserver provider; confirm whether a secondary DNS provider or alternative CDN exists. Check for any documented failover or disaster recovery plan for network services.

Attempt to identify how DNS changes are made; verify whether the organisation has API or console access, or whether all changes require a support ticket with the provider

Review monitoring tools in use; confirm whether any external or self-hosted monitoring (e.g., uptime checks, synthetic tests) exists independently of the primary network provider

Confirm API or console access to DNS and CDN management; verify that the contract grants the organisation self-service capability for record changes, cache purges, and configuration updates without requiring provider intervention

Review signed DPAs for DNS, CDN, and ISP providers; confirm that they address the processing of network metadata (IP addresses, query logs, access logs) and specify geographic restrictions on where this data is processed and stored

Verify that CDN access logs, DNS query logs, and firewall logs are forwarded to an organisation-controlled SIEM or log management platform rather than retained solely in the provider's console

Confirm that retention policies for network logs exceed the provider's default and satisfy applicable regulatory requirements (typically 12+ months); verify that retention is enforced through automated lifecycle policies

Inspect the authoritative DNS infrastructure; confirm that the organisation operates its own nameservers (e.g., PowerDNS, Knot DNS, BIND) or controls the configuration of a dedicated DNS provider. Verify automated failover through DNS health checks and secondary provider configuration.

Confirm DNSSEC signing is active on all authoritative zones; verify that DNSSEC validation succeeds using external validation tools (e.g., DNSViz, Verisign DNSSEC Debugger). Check that DS records are published in parent zones.

Identify all CDN and DDoS mitigation providers; confirm their legal incorporation jurisdiction. If self-managed, verify the geographic distribution and capacity of edge nodes. Acceptable European providers include those headquartered and incorporated in EU/EEA or Swiss jurisdictions.

Verify the organisation's ASN and IP allocations in the RIPE database. Check that RPKI Route Origin Authorisations (ROAs) are published for all announced prefixes. Verify the organisation appears in public BGP routing tables under its own ASN.

Confirm BGP peering sessions at two or more European IXPs (e.g., DE-CIX, SwissIX, AMS-IX). Verify active session status and review peering agreements. Check that the organisation maintains both public peering (route servers) and private peering with critical partners.

Audit the complete DNS stack; confirm that authoritative nameservers and recursive resolvers run on organisation-owned or exclusively leased infrastructure. Verify DNSSEC signing (authoritative) and validation (recursive). Confirm that no external recursive resolver (e.g., Google 8.8.8.8, Cloudflare 1.1.1.1) is used as a fallback for organisational systems.

Review DDoS mitigation architecture; confirm the organisation can implement BGP Remotely Triggered Black Hole (RTBH) routing and/or BGP flowspec rules at its IXP peers. If scrubbing centres are used, verify they are European-operated and that the organisation maintains independent mitigation capability.

Request documentation of network isolation testing; confirm that internal DNS resolution, authentication, and critical application access function when external connectivity is severed. Verify that an isolation test has been conducted within the past 12 months.

Ask operations or platform engineering to list every environment running production code: VMs, container clusters, serverless platforms, managed PaaS runtimes. Inability to produce a complete list, or production of a list that omits known shadow deployments, satisfies this criterion.

Compare deployments across teams. If different teams use different platforms (Vercel, Netlify, Heroku, AWS Lambda, GCP Cloud Run, on-prem VMs) without coordination and no central register exists, the criterion is met.

Pick three production workloads at random and ask in which country and under which legal entity they execute. If the answer requires a support ticket to the provider, or if it is not known at all, the criterion is met.

Confirm the provider behind each production workload (e.g., AWS Lambda, Azure App Service, GCP Cloud Run, fully-managed EKS/AKS/GKE). If every workload traces back to one provider's managed runtime stack, the criterion is met.

Inspect representative production codebases for direct dependencies on provider-only SDKs (AWS SDK invocations of proprietary services, Azure-specific bindings, GCP-only client libraries) and for proprietary deployment manifests (CloudFormation, ARM templates, App Service config). Presence of these without an abstraction layer satisfies the criterion.

Confirm who operates the orchestration plane: provider-managed (EKS, AKS, GKE control planes; Lambda scheduler; App Service control), or organisation-operated. If provider-managed and no migration plan exists, the criterion is met.

Review the risk register for an explicit entry naming the compute provider and the runtime lock-in it creates. A generic 'cloud dependency' entry without naming the runtime stack does not satisfy the criterion.

Review service agreements, order forms, and DPAs for clauses naming the execution region (not just 'Europe'), the contracting legal entity (e.g., AWS Europe SARL vs Amazon Web Services Inc.), and where the orchestration plane is operated. Generic 'data residency' clauses without runtime-execution detail do not satisfy the criterion.

Inspect the sub-processor list referenced by the DPA. Confirm it covers operational support entities for the compute platform (for hyperscalers, this typically means parent-company global support and SRE teams) and not just data-handling processors.

Request the runtime dependency register. Verify it names specific provider features (Lambda, Step Functions, App Service deployment slots, Cloud Run revisions, BigQuery scheduled queries) per workload, and that each entry has an owner and a portability assessment.

Request the portability strategy document. It should name the target portable runtime (typically OCI containers on Kubernetes, or an equivalent standard), estimate effort per workload, and prioritise workloads by sovereignty exposure rather than only by technical feasibility.

Review the DPA and master agreement for clauses on provider administrative access to running workloads, break-glass procedures, support session logging, and notification obligations when access occurs or is compelled by legal order. Generic confidentiality clauses do not satisfy the criterion.

Confirm that production workloads ship as OCI images. Identify who operates the control plane: the organisation itself, a European-jurisdiction managed Kubernetes provider (e.g., Exoscale SKS, Scaleway Kapsule, OVHcloud Managed Kubernetes), or a self-operated cluster on rented infrastructure. Fully provider-managed offerings from US-headquartered hyperscalers (EKS, AKS, GKE) do not satisfy this criterion at L3.

Inspect the build pipeline and the registry it publishes to. Verify that admission control (e.g., Kyverno, Sigstore policy-controller, OPA Gatekeeper with cosign verification) is configured to reject unsigned images and images whose provenance cannot be verified against organisation-held signing keys. A registry that accepts public images without verification does not satisfy the criterion.

Request the migration runbook and the most recent rehearsal evidence (logs, timing, outcome). The rehearsal must move a real production workload (not a toy example) to an alternative orchestration operator and demonstrate that the workload remained operable. Tabletop discussions do not satisfy the criterion.

Confirm that worker nodes use platforms with measured boot (UEFI Secure Boot with TPM-backed quotes, AMD SEV-SNP attestation, Intel TDX attestation, or equivalent). Verify the cluster's node-attestation policy: nodes that fail to produce a valid quote against the expected baseline must be denied join. This is a runtime-integrity control, not a data-confidentiality control. PROC-L3 covers the data-in-use protection angle of confidential computing separately.

Inspect the orchestration plane's audit logging configuration. Verify that any operator action that touches running workloads (kubectl exec, debug containers, node SSH) is logged into organisation-controlled storage and that the provider, where one is involved, has no path to running workloads that bypasses these controls. Cross-reference AUDIT-L3-C4 for log custody requirements.

Inspect the hosting arrangement: organisation-owned data centre, dedicated co-location cage, or sovereign-cloud single-tenant infrastructure. Verify exclusivity (no shared hypervisor, no fallback to multi-tenant capacity), documented physical-access procedures, and the operating entity's legal jurisdiction. Confirm there is no operational path that would silently move a workload onto shared infrastructure.

Review the attestation architecture. Confirm a hardware root of trust is in use; that firmware, host OS, and orchestration components produce measurements that extend into the chain; that the appraisal service verifying these quotes is operated by the organisation, not by the hardware vendor or hosting provider; and that workloads with non-matching measurements are denied execution. This criterion is about runtime integrity (is the execution environment what it claims to be), not data-in-use confidentiality, which sits in PROC-L4.

Review the operational model for vendor and provider access. Confirm that there is no standing remote-administrative access from the hardware vendor, hosting provider, or orchestration vendor; that any support session requires explicit organisational authorisation, is time-bounded, and is logged; and that the logs are stored in custody the external party cannot reach.

Inspect firmware and host-OS lifecycle procedures. Confirm explicit version pinning, signature validation against a trust store the organisation administers, and a baseline-comparison process that flags any deviation in measurements between expected and observed firmware. Pure 'we patch promptly' processes without measurement and pinning do not satisfy the criterion.

Inspect the isolated tier's network architecture (no internet path, controlled physical-media transfer, or one-way diodes), the data-transfer procedure, and evidence that the tier has been used operationally rather than existing only as a design. The tier need not host every workload, but must be available for those whose threat model requires it.

Request the AI feature inventory. For each AI-enabled SaaS tool in use, the inventory should name the model family and version where the vendor discloses it (e.g. GPT-4o behind a given Copilot capability, Claude 3.5 Sonnet behind a given assistant) and the legal entity operating the inference endpoint (OpenAI, Anthropic, the SaaS vendor's own model team, an Azure OpenAI deployment). An entry that lists only the SaaS vendor and a marketing name for the AI feature does not satisfy this criterion. Where the vendor refuses to disclose the model or provider, record that refusal explicitly so the gap is visible rather than hidden.

Review the AI-specific clauses in each SaaS contract. The clause should name a minimum notice period (typically 30 to 90 days) before any model swap, version upgrade, or change of the underlying model provider takes effect for the tenant. Acceptable evidence includes a contractual right to a written change notice describing what changes (model family, version, provider), a defined evaluation window during which the organisation can assess impact, and a documented escalation path. A general 'service may be updated from time to time' clause does not satisfy this criterion. Where the SaaS vendor refuses such terms, document the refusal and the residual risk rather than treating silence as agreement.

Applies only to SaaS tools where the customer's data is used to fine-tune or otherwise adapt a model (vendor-managed fine-tunes, customer-specific embeddings backed by a vendor model, retrieval-augmented configurations that produce a customer model artefact). For each such tool, the contract or vendor documentation should describe the base model's training-data provenance at a useful level of detail (publicly disclosed corpora, vendor-curated datasets, third-party licensed data) and the licensing terms attached to outputs derived from that base. A clause that names only the customer's own fine-tune contribution and is silent on the base model's training data does not satisfy this criterion. Tools that do not offer fine-tuning are out of scope for this criterion and should be marked not applicable.

Request the model card library. For each model behind an in-production AI feature (vendor-hosted SaaS model, self-hosted model, fine-tune of a base model), the record should cover: model identity and version, the legal entity producing the model, training-data categories at the level the provider discloses (e.g. publicly disclosed corpora, licensed datasets, vendor-curated data), declared intended use and out-of-scope use, known limitations and bias evaluations, and version history with the date of the most recent change. Acceptable formats include the original Hugging Face model card, the provider's published model documentation (OpenAI system card, Anthropic model card, Microsoft Responsible AI transparency note), or an internally maintained record where the provider does not publish one. A marketing page describing the AI feature does not satisfy this criterion. Records older than the current model version in production are out of date and should be flagged as such.

Request the AI-artefact portability map. For each AI-enabled SaaS tool, the map should answer: which AI artefacts exist (fine-tunes, embeddings, vector indices, RAG document stores, prompt libraries), in what format (if any) the vendor will export each artefact, and in which formats it cannot be exported (e.g. proprietary embedding spaces tied to a specific model). Where artefacts cannot be exported, the re-creation cost should be estimated: re-embedding the document corpus on a new model, retraining a fine-tune on equivalent data, rebuilding vector indices. A portability map that lists primary tenant data without naming the AI artefact tier does not satisfy this criterion.

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 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 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.