Assessment criteria

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.

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.

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.

Audit reports, compliance certificates, or third-party attestation reports confirming data residency enforcement.

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

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

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)

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.

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

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.

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.