A&A: Audit & Assurance

A&A-01: Audit and Assurance Policy and Procedures

Control Specification

Establish, document, approve, communicate, apply, evaluate and maintain audit and assurance policies and procedures and standards. Review and update the policies and procedures at least annually, or upon significant changes.

Auditing Guidelines for Cloud Service Providers (CSP)

1. Examine policy and procedures to confirm content adequacy in terms of purpose, authority and accountability, responsibilities, planning, communication, reporting, and follow-up.

2. Examine audit charter and determine if independence, impartiality, and objectivity are guaranteed.

3. Examine policy and procedures for evidence of review at least annually.

(The above auditing guidelines from CCM v4.1 apply here as well.)

A&A-02: Independent Assessments

Control Specification

Conduct independent audit and assurance assessments according to relevant standards at least annually.

Auditing Guidelines for Cloud Service Providers (CSP)

1. Examine the process to determine standards and regulations applicable to the organization’s systems and environments.

2. Determine if the organization maintains and reviews a list of such standards and regulations.

3. Determine if senior management exercises oversight over the independence of the assessment process.

4. Determine if the audit plan is informed by previous assessments and if it is scheduled on an annual basis.

(The above auditing guidelines from CCM v4.1 apply here as well.)

A&A-03: Risk Based Planning Assessment

Control Specification

Perform independent audit and assurance assessments according to risk-based plans and policies, and in response to significant changes or emerging risks.

Auditing Guidelines for Cloud Service Providers (CSP)

1. Examine the process for determining the risks applicable to the organization’s systems and environments.

2. Determine if a list of such risks is maintained and reviewed.

3. Determine if senior management exercises oversight over the applicable risks.

4. Determine if the audit plan is risk-based, scheduled on an annual basis, and updated as needed in response to significant changes or emerging risks.

(The above auditing guidelines from CCM v4.1 apply here as well.).

A&A-04: Requirements Compliance

Control Specification

Verify compliance with all relevant standards, regulations, legal/contractual, and statutory requirements applicable to the audit.

Auditing Guidelines for Cloud Service Providers (CSP)

1. Examine the process for determining the standards and regulations applicable to the organization’s systems and environments.

2. Examine the process to determine contractual, legal, and technical requirements applicable to the organization’s systems and environments.

3. Determine if the organization maintains and reviews a list of relevant standards, regulations, legal/contractual, and statutory requirements.

4. Determine if senior management exercises oversight of this control specification.

5. Determine if the audit plan is informed by the list of the organization’s requirements.

(The above auditing guidelines from CCM v4.1 apply here as well.)

A&A-05: Audit Management Process

Control Specification

Define and implement an Audit Management process aligned with relevant auditing standards, to support audit planning, risk analysis, security control assessment, conclusion, remediation schedules, report generation, and review of past reports and supporting evidence.

Auditing Guidelines for Cloud Service Providers (CSP)

1. Examine policy related to the establishment and conduct of audits.

2. Determine if audit programs are established and aligned to the requirements of the organization, including the audit charter.

3. Determine if the organization upholds the independence of the audit program.

4. Determine if the conduct of audits is defined, approved at the appropriate level, and reviewed for effectiveness.

(The above auditing guidelines from CCM v4.1 apply here as well.)

A&A-06: Remediation

Control Specification

Establish, document, approve, communicate, apply, evaluate and maintain a risk-based corrective action plan to remediate audit findings, regularly review and report remediation status to relevant stakeholders.

Auditing Guidelines for Cloud Service Providers (CSP)

1. Examine if the outputs of audits are defined by the policy.

2. Determine if the audit findings are reviewed and if appropriate reports are made available to users and senior management.

3. Determine if the identification of risks from audit findings, or changes to them, are made available to users.

4. Determine if corrective actions proposed are planned to align with the organization’s risk profile.

5. Determine if a process exists to track changes in risk rating and is used to update risk registers, particularly with regard to residual risk.

6. Examine a sample of proposed corrective actions and determine if they were followed-up in a manner consistent with the organization’s policy.

7. Examine audit programs to determine if they are subject to continuous improvement through feedback, review, and revisions.

8. Examine if a process exists to review the audit program in light of current and past audits.

(The above auditing guidelines from CCM v4.1 apply here as well.)

AIS: Application & Interface Security

AIS-01: Application and Interface Security Policy and Procedures

Control Specification

Establish, document, approve, communicate, apply, evaluate and maintain policies and procedures for application security. Review and update the policies and procedures at least annually, or upon significant changes.

Auditing Guidelines for Cloud Service Providers (CSP)

1. Examine policy and procedures for adequacy, approval, communication, and effectiveness as applicable to planning, delivery, and support of the organization’s application security capabilities.

2. Examine policy and procedures for evidence of review at least annually.

(The above auditing guidelines from CCM v4.1 apply here as well.)

AIS-02: Application Security Baseline Requirements

Control Specification

Establish, document and maintain baseline requirements for securing applications.

Auditing Guidelines for Cloud Service Providers (CSP)

1. Examine policy and procedures for adequacy and effectiveness.

2. Determine if security baseline requirements of respective applications are clearly defined.

3. Examine the process to determine the baseline security for AI-enabling services.

(The above auditing guidelines from CCM v4.1 apply here as well.)

AIS-03: Application Security Metrics

Control Specification

Define and implement technical and operational metrics in alignment with business objectives, security requirements, and compliance obligations.

Auditing Guidelines for Cloud Service Providers (CSP)

1. Verify that technical and operational metrics are defined and documented.

2. Verify that technical and operational metrics are verifiable (specific and measurable).

3. Assess the technical and operational metrics for sufficiency and relevance (e.g., vulnerability management, access control, data protection, incident response).

4. Verify that the technical and operational metrics are being utilized.

5. Evaluate if the technical and operational metrics are aligned with business objectives, security requirements and compliance requirements.

6. Verify that the technical and operational metrics are being monitored and evaluated (e.g., evidence of monthly tracking trends, adjustments from management reports).

7. Confirm metrics around API usage, access control, resource allocation, and network security boundaries.

8. Validate visibility into automated remediation actions triggered by metric thresholds (e.g., anomaly in tenant resource use).

9. Review internal reports used to assess compliance with ISO, CCM, and NIST 800-53 style frameworks.

From CCM v4.1:

1. Examine policy and procedures for definition of operational metrics, security, and compliance requirements.

AIS-04: Secure Application Development Lifecycle

Control Specification

Define and implement a secure SDLC process for application requirements analysis, planning, design, development, testing, deployment, and operation in accordance with security requirements.

Auditing Guidelines for Cloud Service Providers (CSP)

1. Policy Examination: Verify the following: a documented SDLC process exists; the SDLC process explicitly includes all key phases: design, development, deployment, and operations; this SDLC is approved and maintained under formal governance; and that the SDLC defines security roles and responsibilities throughout all phases.

2. Policy Assessment (regards content evaluation)

   • a. Threat Modeling: Verify that the SDLC includes documented AI-specific threat modeling. If not present, assess whether a documented rationale and alternative risk mitigation strategy exists.

   • b. Secure Coding Practices: Verify that the SDLC includes secure coding standards and guidance. If absent, evaluate documented justification and compensating controls.

   • c. Open-Source Component Management: Verify whether the SDLC incorporates a documented program for managing open-source components, including vulnerability scanning and license compliance. If not, assess rationale and alternative practices.

   • d. Vulnerability Management: Verify that the SDLC integrates vulnerability management processes for application code, infrastructure, and third-party components. If missing, confirm documented rationale and risk mitigation.

   • e. Security Testing: Verify that the SDLC includes regular security testing, including AI-specific testing (e.g., adversarial testing, LLM-specific tests). If not conducted, assess rationale and compensating risk controls.

   • f. Verify that the SDLC includes secure deployment pipelines, configuration hardening, and use of version-controlled, auditable configuration tools (e.g., IaC templates). Confirm separation of secrets from application code, use of secure variables, and role-based deployment permissions. Best practice is to assess if the SDLC is inline with best practice guidelines (e.g., OWASP).

   • g. Secure Key and Secret Management: Verify that the SDLC explicitly defines secure key management practices, including: secure generation and storage (e.g., HSMs, KMS services); access control and audit logging for key use; regular key rotation, revocation, and recovery mechanisms; scoped usage policies (least privilege for tokens); avoidance of hardcoded keys or secrets in source code.

3. Software Development Lifecycle (SDLC) Evaluation: Evaluate whether the SDLC aligns with the organization’s documented security requirements and governance expectations, and confirm whether the SDLC considers applicable regulatory requirements (e.g., data protection, AI-specific regulations), and assess alignment with those obligations.

4. Implementation Validation: Validate actual implementation of the SDLC by reviewing supporting documentation and corroborating with operational evidence (e.g., staff interviews, ticketing system analysis), and inspect sample implementation artifacts to verify completeness and accuracy of practices, such as: documented threat models; code samples showing secure coding techniques; evidence of open-source component governance (e.g., SBOMs, SCA reports); vulnerability scanning reports, remediation tickets, and patch evidence; logs or reports from security testing tools (e.g., SAST, DAST, IAST, penetration tests); secure deployment evidence (e.g., IaC templates, CI/CD security gates, monitoring alerts).

From CCM 4.1:

1. Examine policy and procedures for definition of SDLC (Software Development Lifecycle), security, and compliance requirements.

2. Examine the state of implementation of the SDLC process.

3. Verify that the SDLC implementation is in accordance with requirements.

AIS-05: Application Security Testing

Control Specification

Implement a testing strategy, including criteria for acceptance of new information systems, upgrades and new versions, which provides application security assurance and maintains compliance while meeting organizational delivery goals. Automate when applicable and possible.

Auditing Guidelines for Cloud Service Providers (CSP)

1. Examine the policies and procedures that define security testing strategies, the automation of security testing, and change management for continuous improvements.

2. Determine the security provisions and criteria for new information system(s).

3. Determine that the software release process includes AI/ML-specific provisions and is automated where applicable.

4. Verify that continuous security improvement processes are in place.

From CCM v4.1:

1. Examine policy and procedures for definition of testing strategies, automation of security testing, and change management.

2. Determine security assurance and acceptance criteria for the new information system(s).

3. Determine if the software release process is automated where applicable.

AIS-06: Secure Application Deployment

Control Specification

Establish and implement strategies and capabilities for secure, standardized, and compliant application deployment. Automate where possible.

Auditing Guidelines for Cloud Service Providers (CSP)

1. Review Secure Service Catalog and Templates: CSPs must offer “secure-by-default” building blocks (e.g., hardened images, encrypted storage). Examine infrastructure templates or service catalog entries for built-in security controls.

2. Inspect Customer-Facing Deployment APIs: Test APIs for rate-limiting, versioning, and authentication enforcement. Review security regression test results.

3. Evaluate Enforcement of Configuration Policies: Customers rely on CSP tools like config or policy-as-code to stay compliant. Review automated controls for compliance (e.g., CIS benchmarks) and check audit logs for remediation actions.

4. Check Third-Party Offering Vetting: AI software marketplaces or container registries may host vulnerable or unverified runtimes. Inspect the vetting process for containers, models, or functions published to customers.

5. Validate Disaster Recovery Readiness: CSP outages can impact thousands of AI systems and deployment continuity is essential. Request DR test records, review automated failover procedures, and examine data replication configurations.

From CCM 4.1:

1. Examine policy and procedures for implementation of application deployment.

2. Determine if segregation of duties (role and responsibilities) is clearly defined among security and application teams.

3. Determine if Identification and integration process is defined and verified for application deployment processes.

4. Evaluate the extent of automation deployed, and criteria used.

AIS-07: Application Vulnerability Remediation

Control Specification

Define and implement a process to remediate application security vulnerabilities, automating remediation when possible.

Auditing Guidelines for Cloud Service Providers (CSP)

1. Review Vulnerability Scanning for Hosted Services: Confirm use of CSP-native scanners and third-party testing.

2. Validate Customer Notification and Advisory Process as customers need timely info about vulnerabilities in shared services. Check how CSPs disseminate CVEs and issue advisory reports or mitigation scripts.

3. Assess Remediation Timeframes and Automation: Examine auto-remediation engines (e.g., AWS Inspector + Systems Manager) and patch windows.

4. Inspect Secure Image and Runtime Lifecycle: Audit image repositories, attestations, and runtime hardening timelines.

5. Confirm Enforcement of Security Baselines: Test Policy-as-Code rules that detect and fix known configuration vulnerabilities.

From CCM v4.1:

1. Examine the policy and procedures to remediate application security vulnerabilities and automating remediation.

2. Evaluate whether roles and responsibilities, including escalation paths for application security incident response and remediation, are defined and effective.

3. Determine if the organization leverages automation when possible and if this automation increases remediation efficiency.

AIS-08: API Security

Control Specification

Define and implement processes, procedures, and technical measures to secure APIs. Review and update for any improvements at least annually, or upon significant changes.

Auditing Guidelines for Cloud Service Providers (CSP)

1. Evaluate API Security Baseline Controls: Review access control layers (IAM policies), network restrictions (VPC service controls), and token scopes.

2. Review Customer-Facing API Documentation: Verify published APIs clearly outline security best practices (e.g., scope minimization, rate limits).

3. Inspect Abuse Detection and API Throttling: High-availability APIs are attractive targets for DDoS or misuse. Validate enforcement of automatic throttling, blacklisting, or behavior-based blocks.

4. Check for Secure Defaults in API Creation: Developers often accept defaults. Ensure APIs are created with HTTPS-only access, key rotation enabled, and default quotas set.

5. Assess Regular Review and Change Management: Confirm APIs are reviewed post-update and that customer notifications are issued for security-impacting changes.

From CCM v4.1: 1.Examine the policies and procedures related to securing APIs, including those addressing API authentication, authorization, rate limiting, and protection from common threats (e.g., injection, replay attacks). 2.Evaluate whether roles and responsibilities for API security management are clearly defined, including accountability for implementing and maintaining API security controls.. 3.Assess whether technical measures are implemented to protect APIs, such as API gateways, logging and monitoring, threat detection, and encryption of API communications.
4.Determine whether the organization conducts reviews of API security measures at least annually and after significant system changes, and whether those reviews result in necessary updates to address identified risks or emerging threats.

AIS-09: Input Validation

Control Specification

Validate, filter, modify or block, as necessary, input against adversarial patterns, failure patterns and unwanted behaviour according to organisational policies and applicable laws and regulations.

Auditing Guidelines for Cloud Service Providers (CSP)

1. Verify that the CSP has clearly defined processes, procedures, and technical measures in place which are addressing AI input validation. The documentation needs to clearly outline the scope as well as objectives, roles, and responsibilities.

2. Inspect these processes for compliance with applicable regulatory frameworks and AI best practices, specifically covering adversarial prompt attacks, including linguistic manipulations, logic manipulation, malicious programming code, adversarial token-based attacks, multi-language, and multi-modal threats.

3. Ensure that the CSP input validation practices consider the evolving AI threat scenario landscape and that a proactive AI Red Teaming is regularly performed.

4. Confirm that the input validation methods are active and perform detection, rejection, or sanitization of adversarial AI inputs across user-facing and API endpoints.

5. Review documented outputs of input validation assessments to ensure they are systematically analyzed and converted into actionable cybersecurity improvements.

6. Ensure that an ongoing monitoring of input validation mechanisms is in place, for evaluating their effectiveness through clearly defined, AI-specific security metrics and indicators (such as rate of detected adversarial inputs, prompt injection attempts).

7. Verify that validation measures are regularly reviewed and needed updates are implemented in a timely manner for effectively addressing continuous advancements in AI threat intelligence and adversarial attack methodologies.

AIS-10: Output Validation

Control Specification

Validate, filter, modify or block, as necessary, output against adversarial patterns, failure patterns and unwanted behaviour according to organisational policies and applicable laws and regulations.

Auditing Guidelines for Cloud Service Providers (CSP)

1. Verify that the CSP has processes, procedures, and technical measures clearly defined and documented to regularly perform security tests of the AI output validation (AI Red Teaming), specifically addressing risks such as unsafe outputs, OWASP insecure output handling, excessive agency attacks, and adversarial outputs (including adversarial prompts and unsafe multimodal outputs). The documentation should clearly outline the testing scope, objectives, roles, responsibilities, and frequency of which those tests are conducted.

2. Confirm the alignment of these validation measures with relevant regulatory frameworks, industry best practices, and the OWASP Top 10 for Large Language Model applications (including protection against output-driven security risks).

3. Verify that the defined processes specifically test and mitigate AI-generated outputs that may pose security, privacy, reputational, or compliance risks. Tests should explicitly cover unsafe outputs (e.g., harmful, malicious, biased content), OWASP insecure output handling vulnerabilities (e.g., complex markdown injections, conversational exfiltration through malicious formatting or link parameters), and excessive agency attacks (outputs that prompt autonomous unsafe actions or responses from downstream AI agents or users).

4. Validate that the regularly conducted AI Red Teaming exercises encompass realistic adversarial scenarios using linguistic logic manipulation, encoded malicious code snippets, adversarial tokens, multimodal prompt injections, and multilingual attack vectors.

5. Verify that the security testing and AI Red Teaming findings are systematically reviewed, documented, and translated into actionable mitigation and improvement measures for AI services, infrastructure, and controls.

6. Confirm that the CSP has implemented metrics or indicators to continuously monitor the effectiveness and efficiency of output validation measures, ensuring a rapid identification and remediation of emerging adversarial output patterns.

7. Inspect that the CSP regularly reviews, updates, and adapts its output validation controls and procedures in response to rapidly evolving threat landscapes and that these address both newly identified AI vulnerabilities and regulatory requirements.

AIS-11: Agents Security Boundaries

Control Specification

Establish security boundaries for agents.

Auditing Guidelines for Cloud Service Providers (CSP)

1. Review CSP documentation and templates defining secure hosting guidelines for AI agents (e.g., sandbox profiles, scoped IAM roles, API throttling), and confirm that guidance is up‑to‑date and communicated to customers.

2. Inspect network and identity isolation controls (e.g., VPCs, service identities, scoped IAM roles, or equivalent mechanisms) to confirm that agent deployments are securely separated in shared environments.

3. Verify that the CSP’s API gateways or equivalent controls can enforce agent‑specific permission sets, filter unauthorized calls, and produce auditable access logs.

4. Evaluate vendor validation processes and security requirements for any third‑party agent offerings in the CSP’s marketplace or service catalog.

5. Confirm that the CSP offers telemetry and behavior analysis services that enable customers to monitor agent activity, detect abnormal behavior, and investigate elevated access patterns.

AIS-12: Source Code Managemement

Control Specification

Implement source code management practices, such as version control, code review & static code analysis, aligning with the SDLC process.

Auditing Guidelines for Cloud Service Providers (CSP)

1. Policy Examination: Verify that the CSP has established and documented source code management policies and procedures covering version control, code review, and static code analysis as integral parts of the SDLC. Confirm that the documentation explicitly incorporates secure coding practices and specifies integration with CI/CD pipelines (e.g., automated static and dynamic analysis, secure configuration validation), as applicable.

2. Policy Assessment: Assess whether the policies clearly define secure code management requirements, including secure authentication for repository access, change management protocols, and technical controls to protect code integrity. Verify that the policies describe how the CSP identifies, manages, and mitigates risks in code (including vulnerabilities detected during automated CI/CD pipeline execution), and assign clear responsibilities for reviews and remediation actions.

3. Program Evaluation: Evaluate how the CSP’s source code management practices are embedded in the SDLC, particularly through automated CI/CD pipelines that include security testing tools (e.g., static and dynamic analysis). Confirm that version control and code review tools are properly configured to enforce documented controls and that automated mechanisms effectively support vulnerability detection and secure code reviews.

4. Implementation Validation: Examine logs, reports, and audit trails from version control systems and CI/CD pipelines to verify that code reviews and static code analysis are regularly performed and that identified security issues are tracked and remediated in a timely manner. Verify that documented reviews and updates to source code management practices occur following significant changes to the system or its development environment.

AIS-13: AI Sandboxing

Control Specification

Implement sandboxing techniques to execute AI tools and plugins in isolated environments to prevent unintended interactions with critical systems or data and limit the possibility of lateral movement.

Auditing Guidelines for Cloud Service Providers (CSP)

Focus: The Cloud Service Provider/AI Processing Infrastructure Provider has implemented effective sandboxing techniques to execute AI workloads in isolated environments, preventing unintended interactions with critical systems or data and limiting the possibility of lateral movement.

1. Inquiry with Control Owners

   1. Interview Infrastructure Security Leadership: Interview cloud infrastructure security architects, data center operations managers, and AI platform engineers responsible for implementing sandboxing in AI-optimized computing environments. Obtain and review the organization’s infrastructure isolation policies covering accelerator (GPU/TPU) resource allocation, tenant isolation, virtualization boundaries, storage access controls, and network segmentation for AI workloads. Verify documented security requirements exist for multi-tenant AI infrastructure, high-performance computing environments, specialized accelerator access, distributed training isolation, and shared storage protection.

   2. Review Sandboxing Technical Implementation: Examine documentation describing the technical implementation of hardware virtualization for AI accelerators, hypervisor isolation, container security for AI workloads, resource allocation enforcement, and network microsegmentation between tenants. Assess how storage isolation, memory protection, driver access controls, and hardware-level security features are implemented across different AI computing environments.

   3. Assess AI Resource Allocation Security: Review mechanisms implementing security for specialized AI hardware resources, including accelerator allocation and isolation, memory partitioning on GPUs/TPUs, hardware queuing systems, power and thermal management isolation, and multi-instance GPU (MIG) implementations. Evaluate how resource quotas, fair scheduling, and priority systems are secured across tenant boundaries.

   4. Evaluate Data Storage and Transfer Security: Review procedures for securing high-performance storage systems used for AI workloads, including parallel file system isolation, storage traffic separation, cache isolation between tenants, temporary storage cleanup, and data transfer security across infrastructure components. Assess protection mechanisms for training datasets, model weights, and checkpoints in shared infrastructure.

2. Obtaining and Verifying the Population of Records

   1. Define the Complete Population of Infrastructure Components: Obtain a comprehensive inventory of AI-optimized infrastructure components, including GPU/TPU clusters, high-performance computing resources, specialized AI accelerators, high-throughput storage systems, low-latency networking fabrics, resource schedulers, virtualization platforms, and container orchestration systems. Include hardware management interfaces, driver and firmware components, and infrastructure monitoring systems in this inventory.

   2. Verify Population Completeness: Cross-reference the inventory against hardware asset management systems, data center capacity documentation, virtualization management platforms, network configuration databases, and infrastructure deployment automation tools. Ensure the inventory aligns with procurement records, customer-facing service catalogs, and resource allocation databases to confirm completeness.

   3. Categorize Components by Risk Level: Segment the infrastructure component population based on resource sharing levels, hardware specialization, customer data exposure, access to specialized accelerators, network connectivity, resource costs, utilization patterns, and deployment environments. This risk-based categorization should guide the depth and frequency of security assessment for each infrastructure component.

3. Inspection of Evidence

   1. Sandbox Implementation Review: Select a representative sample of AI infrastructure components based on risk levels and verify the implementation of isolation mechanisms, resource access controls, and security boundaries. For isolation, examine hardware virtualization configurations, hypervisor security settings, container security policies, and network isolation implementations. For resource controls, review accelerator allocation mechanisms, memory partitioning approaches, quota enforcement, and time-sharing protections. For security boundaries, evaluate authentication systems, permission enforcement, escalation prevention, and tenant boundary enforcement.

   2. Multi-Tenant Isolation Testing: Review evidence of security testing including hypervisor boundary testing, container escape prevention evaluation, GPU/TPU memory isolation verification, network segmentation validation, and storage access control assessment. Evaluate penetration testing results for hardware resource isolation, virtualization boundaries, container security, and accelerator access controls in multi-tenant environments.

   3. Runtime Monitoring and Security Controls: Verify implementation of infrastructure monitoring systems, anomalous resource usage detection, hardware access pattern analysis, privileged operation logging, and tenant boundary enforcement monitoring. Assess the effectiveness of accelerator usage auditing, network traffic analysis between tenant boundaries, storage access monitoring, and hardware resource contention detection in identifying potential security issues.

   4. Data Protection within Infrastructure: Assess controls for data protection including storage isolation between tenants, prevention of data leakage through shared hardware resources, ephemeral storage sanitization, cached data isolation, and memory clearance between workloads. Evaluate how GPU/TPU memory is protected against side-channel attacks, how shared cache systems are secured, and how storage traffic is isolated across tenant boundaries.

   5. Hardware Resource Security: Examine the implementation of hardware resource allocation, accelerator virtualization, specialized instruction access controls, driver isolation, and firmware integrity protection. Assess secure boot implementations, hardware initialization procedures, privileged instruction limitations, and driver security boundaries between tenant workloads.

   6. Security Incident Response: Review documentation and evidence of infrastructure isolation breach procedures, hardware resource contention incident playbooks, and customer notification processes. Evaluate how affected infrastructure components are identified, potentially compromised workloads are isolated, and security incidents are investigated. Assess recovery procedures and post-incident security enhancement processes.

   7. Cloud Infrastructure Compliance: Verify the adequacy of infrastructure compliance controls, hardware security certifications, virtualization security standards alignment, and tenant isolation governance. Evaluate compliance with industry security standards for infrastructure providers, implementation of defense-in-depth for cloud environments, and regular security assessment procedures for AI infrastructure.

4. Evaluation and Reporting

   1. Sandbox Effectiveness Assessment: Evaluate how well infrastructure isolation implementations prevent unauthorized resource access, maintain tenant boundaries, control access to specialized hardware, limit infrastructure visibility, maintain appropriate resource quotas, and withstand multi-tenant attack scenarios. Assess the overall effectiveness in preventing unintended system interactions while delivering high-performance AI computing capabilities.

   2. Isolation Strategy Assessment: Assess the effectiveness of infrastructure isolation strategies based on hardware capabilities, virtualization techniques, network architecture, storage isolation methods, and tenant boundary enforcement. Evaluate whether isolation approaches appropriately balance performance requirements with security boundaries, particularly for specialized AI accelerator hardware.

   3. Documentation and Process Adequacy: Evaluate the quality of infrastructure security documentation, including clarity of isolation architecture, completeness of hardware access controls, definition of tenant boundaries, and security requirements for AI workloads. Assess whether documentation is maintained as infrastructure evolves and new accelerator technologies are introduced.

   4. Continuous Improvement Mechanisms: Evaluate processes for improving infrastructure isolation through regular boundary testing, incorporation of lessons learned, adaptation to new hardware technologies, security architecture reviews, and vulnerability management. Assess whether the organization demonstrates a commitment to continuously enhancing isolation controls as new AI accelerator technologies and attack vectors emerge.

AIS-14: AI Cache Protection

Control Specification

Implement security measures to protect caches in GenAI systems and services.

Auditing Guidelines for Cloud Service Providers (CSP)

Focus: The Cloud Service Provider/AI Processing Infrastructure Provider has implemented effective security measures to protect caches in their AI-optimized infrastructure, ensuring both performance optimization and protection of customer workloads, training data, and model artifacts.

1. Inquiry with Control Owners

   1. Interview Infrastructure and Security Leadership: Interview cloud architects, hardware engineers, and security specialists responsible for AI infrastructure deployment and cache implementation. Obtain and review the organization’s caching strategy and security policies covering GPU/TPU memory caches, distributed training caches, model weight storage systems, high-performance storage caches, and hardware-accelerated data pipelines, verify documented security requirements exist for multi-tenant cache isolation, hardware-level cache security, accelerator memory protection, shared storage cache isolation, and secure resource allocation for high-performance caches.

   2. Review Caching Implementation Details: Examine documentation describing the technical implementation of caching within the AI infrastructure, including GPU/TPU memory management, high-bandwidth memory (HBM) allocation, NVMe and persistent memory caches, distributed file system caches, accelerator on-chip caches, and network fabric cache systems, assess how customer workload isolation is maintained in shared accelerator environments, how training data caches are protected, and how specialized AI hardware caches are secured to prevent data leakage between tenants.

   3. Assess Hardware-Level Cache Security: Review mechanisms implementing security for hardware-level caches used in AI computing, including GPU/TPU memory isolation, accelerator cache partitioning, NVMe controller security features, CPU cache isolation for AI workloads, and hardware-assisted memory protection. Evaluate how shared accelerator memory is protected between customer workloads, how persistent cache systems maintain isolation, and how hardware-level cache coherence mechanisms preserve security boundaries.

   4. Evaluate Infrastructure Cache Management: Review procedures for AI infrastructure cache lifecycle management, including cache clearing between customer workloads, secure reallocation of accelerator memory, monitoring of cache utilization patterns, and isolation verification during hardware maintenance. Assess monitoring systems for detecting cache-based side-channels, memory residency attacks, accelerator resource contention, and cache poisoning attempts within shared AI infrastructure.

2. Obtaining and Verifying the Population of Records

   1. Define the Complete Population of Cache Components: Obtain a comprehensive inventory of caching mechanisms within the AI infrastructure, including GPU/TPU memory caches, distributed training communication caches, hardware accelerator on-chip caches, high-performance storage caches, interconnect and network fabric caches, compute node memory caches, and model weight distribution systems. Include specialized hardware caches, driver-level caching mechanisms, and firmware cache implementations used throughout the AI computing infrastructure.

   2. Verify Population Completeness: Cross-reference the cache inventory against infrastructure architecture documentation, hardware specifications, driver documentation, firmware configurations, and performance optimization strategies. Ensure the inventory aligns with available AI accelerator types, storage architectures, network fabrics, and compute resource specifications to confirm completeness of cache component identification across the cloud provider’s AI infrastructure.

   3. Categorize Cache Components by Risk Level: Segment the cache component population based on shared usage between customers, hardware proximity to customer workloads, persistence characteristics, memory technology used, performance criticality, data sensitivity exposure, and potential impact if compromised. This risk-based categorization should guide the depth and frequency of security assessment for each infrastructure caching component.

3. Inspection of Evidence

   1. Cache Implementation Security Review: Select a representative sample of AI infrastructure caching mechanisms based on risk levels and verify the implementation of security controls, tenant isolation measures, and access restrictions. Examine cache configurations in hardware accelerators, storage systems, and network fabrics. Verify memory isolation for GPU/TPU workloads, implementation of cache partitioning between tenants, and access control enforcement for persistent cache resources.

   2. Multi-Tenant Isolation Assessment: Review evidence of tenant isolation measures for infrastructure caches, including hardware virtualization boundaries, memory address translation controls, hypervisor-enforced isolation, physically separated cache resources where applicable, and cache flushing between tenant allocations. Evaluate how accelerator memory is protected from unauthorized access across tenant boundaries, how storage caches maintain isolation, and how hardware-level caches prevent information leakage in multi-tenant environments.

   3. Cache Clearing and Resource Reallocation: Verify implementation of cache clearing mechanisms triggered by resource reallocation, tenant transitions, hardware maintenance events, and security incidents. Assess memory scrubbing procedures for GPU/TPU resources, cache flushing protocols for persistent storage, and verification procedures to confirm complete removal of customer data from cache systems before reallocation to different tenants.

   4. Hardware Accelerator Cache Controls: Assess controls for hardware accelerator cache security including memory context isolation, secure virtualization of accelerator caches, resource partitioning techniques, driver-level security controls, and firmware-enforced boundaries. Evaluate hardware-specific security features such as Multi-Instance GPU (MIG) isolation, TPU slice protection, and dedicated hardware resources for sensitive workloads.

   5. Protection Against Infrastructure Cache Attacks: Examine the implementation of protections against cache timing side-channels, accelerator memory residency attacks, cache coherence exploits, and other hardware-level cache vulnerabilities. Assess hypervisor controls for cache isolation, memory page coloring techniques, cache flushing frequency calibration, and other mitigations for hardware cache vulnerabilities in shared AI infrastructure.

   6. Storage Cache Security: Review protections for high-performance storage cache systems, including secure cache allocation in distributed file systems, NVMe cache isolation, persistent memory protection, and secure block cache management. Assess how cached storage blocks are protected between customer workloads, how distributed cache coherence protocols maintain security boundaries, and how caching policies prevent unauthorized data access.

   7. Network Fabric and Interconnect Caches: Verify the security of network fabric caches and interconnect buffers, including isolation between tenant traffic flows, secure RDMA caching mechanisms, network buffer protection, and high-speed interconnect security features. Evaluate how network-level caches maintain separation between customer data paths while enabling high-throughput, low-latency communication for distributed AI workloads.

4. Evaluation and Reporting

   1. Cache Security Effectiveness Assessment: Evaluate how well cache security implementations protect customer workloads and data while maintaining infrastructure performance. Assess the balance between caching for compute efficiency and appropriate security controls based on hardware sharing models. Evaluate the effectiveness of defenses against unauthorized access, data leakage between tenants, and cache-targeted attacks across the AI computing infrastructure.

   2. Hardware Isolation Strategy Assessment: Assess the effectiveness of cache isolation strategies based on infrastructure architecture, hardware capabilities, virtualization technologies, and performance requirements for AI workloads. Evaluate whether security controls provide appropriate isolation given hardware constraints and whether defense-in-depth is implemented for the most sensitive shared cache resources.

   3. Documentation and Process Adequacy: Evaluate the quality of cache-related security documentation, including clarity of hardware caching architecture, completeness of security controls, cache clearing procedures, and incident response workflows. Assess whether documentation is maintained as new accelerator hardware is deployed and as caching strategies evolve to support emerging AI computing requirements.

   4. Continuous Improvement Mechanisms: Evaluate processes for improving cache security through regular security testing, incorporation of lessons learned from incidents, adaptation to new hardware technologies, security architecture reviews, and vulnerability management. Assess whether the organization demonstrates a commitment to continuously enhancing cache protection as new AI accelerator technologies are deployed and as understanding of hardware-level vulnerabilities evolves.

AIS-15: Prompt Differentation

Control Specification

Implement mechanisms enabling the model to clearly distinguish user-provided input instructions from data and system instructions (e.g., system prompts).

Auditing Guidelines for Cloud Service Providers (CSP)

Focus: The Cloud Service Provider/AI Processing Infrastructure Provider has implemented effective infrastructure, frameworks, and capabilities that enable their customers to clearly distinguish user-provided input instructions from data and system instructions when deploying AI models on their platforms.

1. Inquiry with Control Owners

   1. Interview Infrastructure and Platform Leadership: Interview AI platform architects, ML infrastructure engineers, and security specialists responsible for AI service development and model deployment frameworks. Obtain and review the organization’s approach to supporting instruction separation, including: model serving framework capabilities for instruction boundary management, infrastructure support for secure prompt handling, AI platform SDK security features, hardware acceleration for secure token processing, virtualization boundaries for multi-tenant instruction isolation, and reference architectures for secure model deployment. Verify documented capabilities exist for enabling deployed models to maintain separation between user inputs and system instructions through platform features such as secured parameter passing, hardware-accelerated token processing or infrastructure-level isolation mechanisms.

   2. Review AI Platform Implementation: Examine documentation describing the platform’s support for instruction separation, including: model serving container security features, managed AI service input handling capabilities, SDK implementations for boundary enforcement, infrastructure templates for secure model deployment, hardware acceleration features for token processing, virtualization controls for instruction isolation, reference implementations for secure prompt handling. Assess how the infrastructure provider’s AI platforms and services establish foundations for reliable instruction separation in customer-deployed models.

   3. Assess AI Service Design: Review mechanisms implementing instruction separation at the service level, including: managed model endpoint configuration options, input/output processing pipeline security, parameter handling in API gateway services, request validation in model serving infrastructure, token processing optimizations, hardware acceleration for boundary enforcement, memory isolation between processing stages. Evaluate how the cloud provider’s AI services support and enforce instruction boundaries for customer workloads and deployments.

   4. Evaluate Customer Guidance and Security Controls: Review how the provider supports secure AI deployments through: security best practice documentation for model serving, reference architectures for secure prompt handling, infrastructure templates with security controls, compliance frameworks for AI workloads, monitoring capabilities for instruction boundary violations, infrastructure scanning for vulnerable deployments, and service configuration validation.

2. Obtaining and Verifying the Population of Records

   1. Define the Complete Population of AI Infrastructure Offerings: Obtain a comprehensive inventory of AI infrastructure and platform services, including: general-purpose GPU/TPU compute services, AI-optimized virtual machine types, container services for model deployment, managed model serving platforms, AI development environments, model deployment frameworks and SDKs, hardware accelerators for AI workloads, and AI service integration components.

   2. Verify Population Completeness: Cross-reference the AI service inventory against: service catalogs and documentation, infrastructure deployment templates, pricing and capability documentation, technical specifications for AI instances, SDK and API documentation, reference architecture publications, service configuration options, and hardware accelerator specifications. Ensure the inventory covers all infrastructure, platforms, and services where secure model deployment and instruction handling are relevant.

   3. Categorize Infrastructure Components by Risk Level: Segment the AI infrastructure offerings based on: level of abstraction (IaaS, PaaS, SaaS), multi-tenancy characteristics, model deployment patterns, customer exposure and usage volume, integration with sensitive data systems, level of provider management, and hardware acceleration capabilities. This risk-based categorization should guide assessment depth for each infrastructure component.

3. Inspection of Evidence

   1. Infrastructure Support Implementation Review: Select a representative sample of AI infrastructure offerings based on risk levels and verify. For Platform-Level Separation Support, examine how the infrastructure platform supports instruction separation through features such as: memory isolation for different prompt components, hardware-accelerated token processing, secure enclaves for sensitive instructions, virtualization boundaries for inference isolation, request parameter validation mechanisms, and input sanitization capabilities in serving infrastructure. For AI Service Security Implementation, verify that managed AI services support secure deployment: service configuration options for input separation, managed API gateways with validation capabilities, token processing security features, parameter handling and validation, input format enforcement options, and logging capabilities for boundary violations. For SDK and Framework Support, confirm platform SDKs and frameworks encourage security: helper libraries for proper instruction formatting, template implementations with separation patterns, input validation components, security-focused reference code, configuration validation tools, and default secure configurations.

   2. Deployment Infrastructure Assessment: Review how the infrastructure supports secure model deployment. For Container and VM Security, verify security features in deployment environments: container isolation for model serving, memory protection mechanisms, process boundary enforcement, resource governance supporting security, configuration validation capabilities, and default security hardening. For Infrastructure Template Analysis, examine infrastructure-as-code templates to confirm: security best practices in reference architectures, implementation of isolation patterns, proper configuration of service boundaries, inclusion of monitoring and logging, integration of security services, and validation of deployment configurations.

   3. Security Testing for Infrastructure Support: Perform targeted testing of infrastructure security features. For Isolation Validation Testing, verify infrastructure isolation through: multi-tenant boundary testing, memory isolation verification, process separation validation, resource governance effectiveness, hardware acceleration security, and performance under security controls. For Platform Security Analysis, evaluate platform security features supporting: proper enforcement of configured boundaries, validation of input parameters, detection of potential boundary violations, performance impact of security controls, resource isolation between tenants, and maintaining security during scaling operations.

   4. Documentation and Customer Guidance: Review supporting materials for infrastructure users. For Deployment Documentation, verify existence and quality of: security best practices for model deployment, guidance on configuring secure model endpoints, examples of secure infrastructure configuration, warning about insecure deployment patterns, templates implementing security controls, and architecture diagrams showing security boundaries. For Security Technical Guides, assess infrastructure security documentation for inclusion of: model serving security considerations, input handling best practices, configuration validation guidance, monitoring recommendations, incident response guidance, and performance optimization with security.

   5. Hardware Acceleration Security: Evaluate security features of specialized AI hardware. For Accelerator Security Implementation, verify that hardware accelerators support security: memory protection features, isolation between workloads, secure parameter handling, token processing security features, resource governance capabilities, performance with security controls enabled.

Hardware-Software Integration: Review security of the hardware-software stack: driver security features, firmware security controls, API security for accelerator access, resource allocation security, memory management security, and monitoring and telemetry for security events.

1. Evaluation and Reporting

   1. Infrastructure Support Effectiveness Assessment: Evaluate how well the implementation: enables secure deployment of models with instruction boundaries, provides performance-optimized security controls, offers appropriate levels of isolation for different workloads, balances security with AI workload performance needs, and addresses various deployment patterns and architectures.

   2. Platform Strategy Assessment: Assess the effectiveness of the overall approach based on: integration of security throughout the AI infrastructure stack, support for various model deployment patterns, appropriate defaults encouraging security, compatibility with industry security practices, and evolution of security features with new AI capabilities.

   3. Documentation and Guidance Adequacy: Evaluate the quality of security documentation, including: clarity of secure deployment guidance, completeness of configuration recommendations, integration of security into reference architectures, support for customers implementing secure deployments, and ongoing communication about security considerations.

   4. Continuous Improvement Mechanisms: Evaluate processes for enhancing infrastructure security through: regular security testing of infrastructure components, analysis of customer deployment patterns and challenges, integration of lessons from security incidents, research into improved security architectures, and iterative enhancement of security features.

BCR: Business Continuity Management and Operational Resilience

BCR-01: Business Continuity Management Policy and Procedures

Control Specification

Establish, document, approve, communicate, apply, evaluate and maintain business continuity management and operational resilience policies and procedures. Review and update the policies and procedures at least annually, or upon significant changes.

Auditing Guidelines for Cloud Service Providers (CSP)

1. Establishment and Documentation: Verify that formal Business Continuity Management (BCM) and operational resilience policies and procedures explicitly address continuity requirements related to AI, application services, and delivered products. For Model Providers (MP) specifically, confirm that the policy covers upkeep, supportability, versioning, and retraining of AI models, particularly where their availability or behavior directly impacts downstream systems or customers. Ensure policies document detailed roles, responsibilities, objectives, and scope, including dependencies on model behavior, compute environments, and model-serving infrastructure. Confirm the identification of upstream and downstream interfaces and dependencies, such as AI pipelines, orchestration layers, or inference endpoints, and how continuity risks at each point are managed.

2. Approval and Communication: Confirm that policies and procedures are approved by senior management or governing bodies and that evidence of formal endorsement (e.g., signatures, meeting minutes) is maintained. Verify the presence of a robust document control process for managing revisions, release control, and versioning to ensure the latest policy is always accessible. Ensure effective communication of continuity policies to internal and external stakeholders, including third-party vendors, with supporting materials such as training logs, stakeholder memos, and BCM awareness sessions.

3. Application and Implementation: Evaluate whether the policy is implemented in practice, including operational execution of responsibilities. For MPs, verify that continuity planning includes model retraining schedules, rollback strategies, failure isolation plans, and incident handling for model outages or data drift. Confirm clear role definitions for continuity, and validate that they are being actively fulfilled in AI service teams and operational support.

4. Evaluation and Maintenance: Verify that the BCM policy is reviewed at least annually or upon significant changes (e.g., new model deployments, cloud migrations, architectural changes). Confirm that triggers for reassessment, such as introduction of high-dependency AI models, changes in inference service SLAs, or new customer impact scenarios, are documented and linked to update logs. Ensure KPIs are tracked to measure effectiveness of continuity planning, including model uptime, failure recovery times, and retraining impact windows. Verify that lessons learned from incidents, tests, and audits are used to refine the BCM policy. Confirm that policies align with external standards and regulatory expectations (e.g., ISO 22301, industry resilience benchmarks), and are validated through internal or third-party reviews.

5. Verify that all policies and procedures are formally reviewed at least annually or upon significant changes, with updates documented through version history and approvals, and communicated to relevant stakeholders.

From CCM v4.1:

1. Examine policy and procedures for adequacy, approval, communication, and effectiveness as applicable to business continuity and resilience.

2. Examine policy and procedures for evidence of review at least annually.

BCR-02: Risk Assessment and Impact Analysis

Control Specification

Determine the impact of business disruptions and risks to establish criteria for developing business continuity and operational resilience strategies and capabilities. Review and update the risk assessment and impact analysis at least annually, or upon significant changes.

Auditing Guidelines for Cloud Service Providers (CSP)

1. Business Impact Analysis and Risk Assessment: Confirm that the organization performs a Business Impact Analysis (BIA) to identify critical business processes and the potential effects of disruptions, explicitly considering the critical dependencies such as applications, IT systems, infrastructure, vendors, and human resources. These dependencies play a crucial role in understanding the impact of business disruptions. Verify that the BIA quantifies impacts in terms of financial loss, reputational damage, operational downtime, regulatory non-compliance, and other relevant metrics. Ensure that risk assessments identify both internal and external threats that could lead to business disruptions, explicitly including any risks related to AI systems, cloud infrastructure, and third-party vendors. Check that risks are analyzed in terms of likelihood, impact, and existing controls to gauge residual risk and the effectiveness of current mitigation strategies.

2. Establishing Impact Criteria for Strategies: Verify that clear criteria are established based on the BIA and risk assessment outcomes. Criteria may include Recovery Time Objectives (RTO) and Recovery Point Objectives (RPO), financial thresholds (e.g., cost implications of downtime), criticality of business functions and interdependencies, compliance and regulatory implications, stakeholder expectations and service level agreements (SLAs), and risk appetite. Ensure that the organization has defined its risk appetite, which will guide decisions on accepting certain and risks versus the cost of implementing risk treatment plans. Assess how the impact criteria are used to determine the prioritization of business continuity strategies and resilience capabilities, confirm that criteria help in deciding which functions require immediate restoration versus those that can be scheduled for later recovery, check that the criteria are embedded within a broader operational resilience framework, ensuring alignment with overall business strategy and risk management, review documented methodologies that connect risk levels with tailored resilience strategies (e.g., scaling up resources, alternative service delivery, backup systems).

3. Governance and Continuous Improvement: Ensure that senior management is involved in establishing and approving the impact criteria and associated resilience strategies. Verify that there are documented discussions or meeting minutes demonstrating management’s role in this process. Confirm that the impact criteria and related strategies are reviewed periodically or whenever significant changes (internal or external) occur, especially considering the changing technology landscape (e.g., AI systems, cloud architecture). Check for evidence of feedback loops from past incidents, tests, or drills that inform updates to the criteria and risk treatment strategies.

4. Evidence and Observations Checklist: Business Impact Analysis (BIA) reports and risk assessment records: policy documents outlining criteria for evaluating business disruption impacts, detailed methodologies linking disruption impacts to resilience strategies, management approval documents and review meeting minutes, change logs or update records reflecting periodic reviews and revisions, and risk appetite documentation specifying thresholds for acceptable risk.

From CCM v4.1:

1. Examine the policy to determine business impact and the criteria for developing business continuity.

2. Evaluate the process to review and approve the policy.

BCR-03: Business Continuity Strategy

Control Specification

Establish strategies to reduce the impact of business disruptions, and improve resiliency and recovery from business disruptions.

Auditing Guidelines for Cloud Service Providers (CSP)

1. Confirm the existence of a documented business continuity strategy covering compute, storage, and networking infrastructure that supports AI workloads.

2. Verify redundancy and failover strategies for core cloud services (e.g., IAM, DNS, VPC, container orchestration) critical to AI service delivery.

3. Ensure mechanisms are in place to isolate and recover from zonal and regional outages impacting AI workloads.

4. Check defined procedures to notify APs, OSPs, MPs, and AICs of disruptions that may impact AI model availability or inferencing pipelines.

5. Confirm regular resilience testing of infrastructure components supporting large-scale AI training and deployment.

6. Validate the existence of a strategy to ensure high availability of hardware accelerators (e.g., GPUs, TPUs) during disruption scenarios.

7. Verify cloud-native disaster recovery services are actively configured and available to tenants with AI dependencies.

From CCM v4.1:

1. Determine if the organization has established a risk appetite.

2. Determine if the organization has established strategies to reduce impact of business disruptions, within the organization’s risk appetite.

BCR-04: Business Continuity Planning

Control Specification

Establish, document, approve, communicate, apply, evaluate and maintain a business continuity plan based on the results of the operational resilience strategies and capabilities.

Auditing Guidelines for Cloud Service Providers (CSP)

1. Confirm a documented and approved BCP is in place for cloud services supporting AI workloads, including core IaaS, PaaS, and ML services.

2. Verify the plan includes defined roles and communication procedures for service recovery impacting tenant AI operations.

3. Check that the BCP addresses region/zone-level failures for GPU/TPU clusters or specialized hardware used in AI training.

4. Ensure detailed fallback and rerouting strategies exist for managed AI services (e.g., Vertex AI, SageMaker, Azure ML).

5. Validate CSP’s plans for restoring tenant data, models, and configurations hosted on the platform.

6. Confirm BCP testing results are periodically shared with affected enterprise customers consuming AI services.

7. Ensure CSP evaluates AI-specific operational risks during annual BCP reviews and updates accordingly.

From CCM v4.1:

1. Examine the policy for adequacy, approval, communication, and effectiveness as applicable to planning, delivery, and support of the organization’s application security capabilities.

2. Evaluate if the organization’s operational resilience strategies and capabilities are used as an input for the policy and implementation.

3. Examine policy and procedures for evidence of review.

BCR-05: Documentation

Control Specification

Develop, identify, and acquire documentation, both internally and from external parties, that is relevant to support the business continuity and operational resilience plans. Make the documentation available to authorized stakeholders and review at least annually, or upon significant changes.

Auditing Guidelines for Cloud Service Providers (CSP)

1. Verify that documentation supporting cloud service continuity (especially AI platform services) and operational resilience plan is maintained and regularly updated.

2. Confirm inclusion of infrastructure diagrams, zone/region failover strategies, and recovery timelines.

3. Check that CSP documentation covers service-level agreements, support models, and business continuity roles.

4. Ensure documentation is available to enterprise AI tenants upon request, subject to NDA or contractual agreement.

5. Validate that documentation incorporates input from infrastructure, service delivery, and customer support teams.

6. Confirm that key documentation artifacts (e.g., DR test results, audit logs, incident response procedures) are stored securely and access-controlled.

7. Ensure documentation is reviewed annually and updated based on changes to AI service architecture or regional availability.

From CCM v4.1:

1. Examine the process for determining the documentation required to support business continuity and operational resilience.

2. Examine the process for developing or acquiring such documentation and maintaining its currency.

3. Evaluate the process and implementation of identifying stakeholders and making documentation available.

4. Examine the policy and procedures for evidence of review.

BCR-06: Business Continuity Exercises

Control Specification

Exercise and test business continuity and operational resilience plans at least annually, or upon significant changes.

Auditing Guidelines for Cloud Service Providers (CSP)

1. Examine the plans for business continuity and operational resilience tests, regarding their intended outputs.

2. Examine the schedules of such tests and their periodicity.

3. Evaluate if the plans are tested upon significant changes or at least annually.

4. Verify that the exercise scenarios include various infrastructure failure modes, including power outages, hardware failures, network disruptions, and regional disasters that affect AI processing capabilities.

5. Review exercise results and documentation to confirm that critical AI infrastructure components (compute, networking, storage) are included in the scope and that recovery time objectives (RTOs) and recovery point objectives (RPOs) were measured against established targets.

6. Assess documentation of lessons learned from exercises and verify that identified deficiencies in infrastructure resilience were documented in a corrective action plan with clear ownership and timelines.

7. Examine evidence that infrastructure redundancy mechanisms (e.g., failover systems, load balancing, backup power) were tested explicitly during exercises.

8. Verify that the appropriate management responsible for infrastructure operations reviewed and approved the exercise planning, execution, and results.

From CCM v4.1:

1. Examine the plans for business continuity and operational resilience tests, with reference to their intended outputs.

2. Examine the schedules of such tests and their periodicity.

3. Evaluate if the plans are tested upon significant changes, or at least annually.

BCR-07: Communication

Control Specification

Establish and maintain communication channels with all relevant stakeholders in the course of business continuity and resilience procedures.

Auditing Guidelines for Cloud Service Providers (CSP)

1. Examine the policy for determining stakeholders and participants.

2. Determine if the organization has identified stakeholders and participants.

3. Examine the procedures for communication with identified stakeholders and participants.

4. Verify the establishment of automated notification systems for infrastructure status changes, reviewing the configuration of alerts, distribution lists, and escalation paths.

5. Review evidence of communication templates prepared for different infrastructure incident scenarios, ensuring they include appropriate technical detail and clarity for different stakeholder groups.

6. Assess the implementation of infrastructure status dashboards or notification systems, confirming their functionality, accessibility during disruptions, and inclusion of relevant infrastructure components.

7. Verify documentation of contact information for all dependent stakeholders is maintained, regularly updated, and accessible during outages.

8. Review records from past infrastructure incidents or exercises to confirm that communication procedures were followed, stakeholders were notified promptly, and regular updates were provided during extended incidents.

9. Confirm that alternative communication channels are established for scenarios where primary communication systems are unavailable.

From CCM v4.1:

1. Examine the policy for determining stakeholders and participants.

2. Determine if the organization has identified stakeholders and participants.

3. Examine the procedures for communication with identified stakeholders and participants.

BCR-08: Backup

Control Specification

Periodically perform backups. Ensure the confidentiality, integrity and availability of the backup, and verify restoration from backup for resiliency.

Auditing Guidelines for Cloud Service Providers (CSP)

1. Examine the policy for identifying data for which a backup is required.

2. Examine the requirements for the security of such backups.

3. Evaluate the effectiveness of the backup and restore.

4. Verify implementation of infrastructure-level backup mechanisms through configuration reviews and system logs, confirming automated execution according to defined schedules.

5. Assess encryption and access control mechanisms protecting backup confidentiality, including encryption of backup data at rest and in transit, key management procedures, and identity and access management controls.

6. Review backup storage redundancy and geographic distribution practices to confirm backups are protected from regional disasters or infrastructure failures affecting primary systems.

7. Examine documentation and test results verifying successful restoration procedures, including complete infrastructure recovery tests performed at least annually.

8. Verify monitoring and alerting systems for backup failures, reviewing incident logs and remediation procedures when backup processes encounter errors.

9. Assess backup performance metrics against recovery point objectives (RPOs) to confirm backup frequency aligns with data criticality and business requirements.

From CCM v4.1:

1. Examine the policy for identifying data for which a backup is required.

2. Examine the requirements for the security of such backups.

3. Evaluate the effectiveness of the backup and restore.

BCR-09: Disaster Response Plan

Control Specification

Establish, document, approve, communicate, apply, evaluate and maintain a disaster response plan to recover from natural and man-made disasters. Update the plan at least annually, or upon significant changes.

Auditing Guidelines for Cloud Service Providers (CSP)

1. Examine the policy and procedures for adequacy, approval, communication, and effectiveness as applicable to a disaster response plan.

2. Examine the policy and procedures for evidence of review, upon significant changes, or at least annually.

3. Examine the documented disaster response plan specific to AI processing infrastructure, verifying it addresses recovery of physical facilities, network systems, compute resources, and storage systems supporting AI workloads.

4. Verify that the plan has received formal approval from senior management responsible for infrastructure operations, with evidence of review and sign-off.

5. Assess the defined recovery time objectives (RTOs) and recovery point objectives (RPOs) for critical infrastructure components, confirming they align with service level commitments to dependent AI services.

6. Review documentation of geographic redundancy and failover mechanisms for infrastructure components, confirming implementation of technical controls that support rapid recovery.

7. Verify that critical infrastructure components’ off-site backup and recovery capabilities are established and regularly tested.

8. Examine evidence that the disaster response plan has been communicated to all relevant personnel, including training records and awareness programs.

9. Review records of disaster recovery tests or exercises conducted within the past 12 months, confirming they included realistic scenarios relevant to AI infrastructure.

10. Verify that the plan is reviewed and updated at least annually and after significant infrastructure changes, with documented change history and revision approval.

From CCM v4.1:

1. Examine the policy and procedures for adequacy, approval, communication, and effectiveness as applicable to a disaster response plan.

2. Examine the policy and procedures for evidence of review, upon significant changes, or at least annually.

BCR-10: Response Plan Exercise

Control Specification

Exercise the disaster response plan annually or upon significant changes, including, if possible, the participation of local emergency authorities.

Auditing Guidelines for Cloud Service Providers (CSP)

1. Examine the policy for planning and scheduling a disaster response exercise and involving local emergency authorities.

2. Evaluate if plans are tested upon significant changes or at least annually.

3. Verify that the exercises tested the recovery of all critical infrastructure components, including data centers, network connectivity, compute resources, and storage systems supporting AI operations.

4. Review exercise scenarios to confirm they included various disaster types relevant to infrastructure (e.g., power outages, network failures, facility damage, regional disasters) and assessed the organization’s response capabilities.

5. Assess whether infrastructure failover mechanisms and redundancy capabilities were actively tested during exercises rather than just theoretically reviewed.

6. Verify that recovery time achievements were measured against defined recovery time objectives (RTOs) during exercises and documented in after-action reports.

7. Confirm that exercises included coordination with relevant external parties such as utility providers, facility management, or local emergency authorities, where appropriate and feasible.

8. Review documentation of lessons learned from exercises and verify that identified weaknesses in infrastructure recovery capabilities resulted in documented improvement plans with clear ownership and timelines.

9. Verify that additional exercises were conducted following significant infrastructure changes that could impact disaster recovery capabilities.

From CCM v4.1:

1. Examine the policy for planning and scheduling disaster response exercises, and involving local emergency authorities, if possible.

2. Evaluate if plans are tested upon significant changes, or at least annually.

BCR-11: Equipment Redundancy

Control Specification

Supplement business-critical equipment with both locally redundant and geographically dispersed equipment located at a reasonable minimum distance in accordance with applicable industry standards.

Auditing Guidelines for Cloud Service Providers (CSP)

1. Examine the process to identify business-critical equipment and any redundant equipment.

2. Examine the process to identify the applicable industry standards.

3. Evaluate if the redundant business-critical equipment is independently located at a reasonable distance.

4. Verify that data centers housing redundant equipment are located at a minimum distance from each other according to relevant industry standards (e.g., Uptime Institute, ISO 22301, NIST), confirming that this distance is sufficient to isolate them from common threats.

5. Review the implementation of redundant power systems, including uninterruptible power supplies, backup generators, and redundant power distribution units, and confirm that they support critical AI processing equipment.

6. Assess the redundancy of the networking infrastructure, verifying redundant routers, switches, load balancers, and internet connections from different providers to avoid single points of failure.

7. Verify implementation of redundant compute resources for AI workloads, including server clusters, virtualization hosts, and container platforms, confirming automated failover capabilities.

8. Examine redundant system implementation, including RAID configurations, distributed storage systems, and data replication mechanisms across geographically separated locations.

9. Review monitoring systems that detect failures in redundant components and automated alerting mechanisms that notify appropriate personnel.

10. Verify documentation of regular testing procedures for redundant systems and examine records of recent failover tests confirming redundancy functions as designed.

From CCM v4.1:

1. Examine the process to identify business-critical equipment and any redundant equipment.

2. Examine the process to identify applicable industry standards.

3. Evaluate if the redundant business-critical equipment is independently located at a reasonable distance.

CCC: Change Control and Configuration Management

CCC-01: Change Management Policy and Procedures

Control Specification

Establish, document, approve, communicate, apply, evaluate and maintain policies and procedures for managing the risks associated with applying changes to assets owned, controlled or used by the organization. Review and update the policies and procedures at least annually, or upon significant changes.

Auditing Guidelines for Cloud Service Providers (CSP)

1. Conduct interviews with personnel responsible for documenting, maintaining, and communicating organizational change management policies, procedures, and standards (the Policies).

2. Inspecting Records and Documents: Obtain and review the change management Policies to ensure they are adequate for the organization to manage risks associated with applying changes to organizational assets. Verify that the Policies define the personnel or roles responsible for their dissemination, identify an official accountable for managing the Policies, specify the frequency of reviews and updates (annually), and outline events that necessitate policy updates.

3. Verify that the Policies are disseminated, are reviewed and updated at least annually or upon significant changes, are approved, and are communicated to relevant stakeholders.

(The above auditing guidelines from CCM v4.1 apply here as well.)

CCC-02: Quality Testing

Control Specification

Establish, maintain and implement a defined quality change control, approval and testing process incorporating baselines, testing, and release standards.

Auditing Guidelines for Cloud Service Providers (CSP)

1. Inquiring with Control Owners: Interview infrastructure engineering leads and examine operations documentation to understand: Hardware and Platform Management (AI-optimized hardware procurement and qualification processes, hardware platform versioning and baseline configurations, accelerator (GPU/TPU) driver and firmware management with update qualification procedures, compute cluster architecture and configuration baselines, high-performance storage system configuration management with allocation and tiering protocols, hardware-software compatibility validation procedures, hardware refresh and deprecation procedures); Software and Framework Governance (infrastructure-as-code template governance, AI framework optimization and library management, driver and firmware update qualification procedures, infrastructure component version control and tracking); Deployment and Change Management (staged deployment approaches and validation testing before infrastructure changes, compatibility verification across hardware and software stacks, performance regression testing after changes and infrastructure performance monitoring frameworks, customer impact assessment for infrastructure modifications, rollback procedures for problematic deployments); Resource Management and Operations (resource allocation and scheduling policies, compute quota management and GPU/TPU/accelerator provisioning with access control, network bandwidth reservation, quality of service, and networking fabric optimization, capacity management and scaling processes, multi-tenancy isolation controls and resource monitoring with utilization optimization, infrastructure redundancy and failover configurations, cost optimization and resource efficiency mechanisms).

2. Obtaining and Verifying the Population of Records: Collect a complete population of infrastructure change records from independent sources, including infrastructure-as-code repositories and deployment logs, hardware inventory management systems, driver and firmware update records, cluster management platform logs, configuration management databases (CMDBs), network configuration repositories, storage system setup and configuration records, and container image registries for infrastructure components. Select a sample of these deployments and trace them forward to the change management record system, confirming a corresponding record exists for each, thus ensuring all deployments are captured in the population.

3. Inspecting Records and Documents: 3.1 Select Representative Sample: Choose a balanced sample of infrastructure changes including: major hardware platform introductions, accelerator (GPU/TPU) updates and driver changes, storage system configuration modifications, network fabric and interconnect upgrades, resource scheduling algorithm changes, infrastructure scaling implementations, and performance optimization changes.

3.2. Infrastructure Change Validation, Deployment, and Performance Assurance: For each sampled infrastructure change, confirm comprehensive validation, deployment adherence, and performance documentation including: Validation and Testing (hardware-software compatibility testing and integration testing with AI frameworks and libraries, performance benchmark evaluation with AI workloads and scalability testing under various load conditions, reliability verification through stress testing and security assessment of configuration changes, resource isolation validation in multi-tenant environments); Deployment Procedures (pre-deployment environment validation and progressive rollout strategies across availability zones or regions, deployment window compliance and customer communication for service-impacting changes, concurrent monitoring during deployment and success criteria verification after implementation, rollback readiness and contingency planning); Performance Documentation and Metrics (compute throughput benchmarks for AI workloads and storage I/O performance metrics, network bandwidth and latency measurements, resource utilization efficiency metrics and scaling characteristics under load, performance consistency across identical resources, comparison with previous infrastructure generations).

1. Confirm Stakeholder Approvals for Changes: For each sampled infrastructure change, verify approvals from relevant stakeholders including: infrastructure engineering leadership, platform reliability engineers, security teams for infrastructure configuration changes, cost management teams for resource allocation changes, performance engineering teams for optimization changes, customer support teams for user-impacting changes, and procurement teams for hardware introductions.

2. Assess Configuration Reproducibility: For each sampled infrastructure change, verify documentation that enables infrastructure reproducibility: complete infrastructure-as-code templates, driver and firmware version specifications, hardware configuration parameters, networking topology and configuration details, storage system setup parameters, resource allocation and scheduling policies, and monitoring and alerting thresholds.

3. Evaluate Infrastructure Documentation: For each sampled infrastructure change, confirm the quality and completeness of documentation including: resource specifications and capabilities, compatible AI framework versions, known limitations and constraints, recommended configuration practices, performance optimization guidelines, resource utilization best practices, and maintenance window schedules and procedures.

From CCM v4.1:

1. Examine relevant documentation, observe relevant processes, and/or interview the control owner(s), relevant stakeholders, for change management and determine if the policy control requirements provided in the policy have been implemented.

2. Examine measures that evaluate(s) the organization’s compliance with the change and configuration management policy and determine if these measures are implemented according to policy control requirements.

CCC-03: Change Management Technology

Control Specification

Implement a change management procedure to manage the risks associated with applying changes to assets owned, controlled or used by the organization.

Auditing Guidelines for Cloud Service Providers (CSP)

1. Inquiring with Control Owners: Interview change management leadership to understand how changes to AI-specific infrastructure assets are managed. This includes GPU/TPU/accelerator updates, AI-optimized server and storage configurations, high-bandwidth network fabric modifications, and distributed compute environment updates. Discuss the workflows for hardware introductions, driver and firmware updates, resource allocation changes, and infrastructure optimizations. Examine how risks are assessed, particularly regarding multi-tenant isolation, AI workload performance impacts, hardware-software compatibility, and capacity planning.

2. Inspecting Records and Documents: 2.1 Confirm the use of enterprise change management systems such as ServiceNow, Jira, or BMC Remedy for tracking infrastructure changes. Validate that these systems are integrated into the broader governance and approval framework.

   1. Review configuration management databases (CMDBs) to ensure accurate inventories of infrastructure assets, well-documented baseline configurations for AI environments, relationship mapping between components, and comprehensive change histories.

   2. Assess the use of automated testing frameworks to validate infrastructure changes. Confirm that performance validation tests are consistently run, benchmark results are evaluated against thresholds, test coverage is documented, and testing is integrated into approval workflows.

   3. Evaluate cloud infrastructure management practices by verifying enforcement of infrastructure-as-code templates, proper versioning, detection and remediation of configuration drift, and controlled deployment procedures.

   4. Review API management practices related to infrastructure. Confirm that access to management APIs is controlled, versions are tracked, administrative activity is monitored, and authentication/authorization is enforced.

   5. Verify oversight of infrastructure components managed by external providers. Check that contracts specify change management obligations, vendor change notifications are integrated into internal workflows, impact assessments are conducted, testing protocols are in place, and post-change SLA monitoring is active.

   6. Inspect change management for AI-specific infrastructure. Confirm that driver and firmware updates are validated with ML frameworks, performance benchmarking is conducted with relevant AI workloads, capacity planning is aligned with distributed training needs, and hardware optimization configurations are properly tested.

   7. Review infrastructure-as-code (IaC) practices. Ensure code reviews are conducted, access controls are applied to repositories, templates are tested in staging before production deployment, and syntax and security validations are automated. Confirm version control and change history are documented.

From CCM v4.1:

1. Examine policy related to the change management of assets.

2. Examine the policy for the identification of risks arising from these changes being applied.

3. Determine if assets are classified based on their management responsibility, and if these have specific risk profiles.

CCC-04: Unauthorized Change Protection

Control Specification

Implement and enforce a procedure to authorize the addition, removal, update, and management of assets that are owned, controlled or used by the organization.

Auditing Guidelines for Cloud Service Providers (CSP)

Focus: The Cloud Service Provider/AI Processing Infrastructure Provider has implemented appropriate access restrictions for customers making changes to AI infrastructure components, including compute resources, accelerator configurations, storage systems, and networking capabilities.

Applicability: This control applies when the Cloud Service Provider/AI Processing Infrastructure Provider gives customers the ability to perform changes to AI infrastructure components, such as: AI accelerator (GPU/TPU) configuration adjustments, compute cluster scaling or optimization, storage tiering and caching configurations, networking fabric and interconnect settings, resource allocation and scheduling policies, infrastructure-as-code template modifications, and container orchestration settings for AI workloads. Access controls for CSP or AI Processing Infrastructure Provider personnel should be covered in a specific CSP attestation report, such as SOC 1 or SOC 2.

1. Inquiring with Control Owners: 1.1 Interview Platform Engineers and Infrastructure Administrators, and Review Access Control Documentation: Interview personnel responsible for managing customer access and examine formal documentation. For Infrastructure Access Management: Self-service AI infrastructure provisioning portals and GPU/TPU quota management systems; Hardware accelerator firmware and driver management with distributed computing orchestration platforms; High-performance storage configuration interfaces and infrastructure-as-code deployment pipelines; Kubernetes and container orchestration for AI workloads. For Access Control and Security Framework: Role-based access control (RBAC) implementation for infrastructure management; Customer isolation boundaries in multi-tenant AI environments; Quota enforcement mechanisms for high-value compute resources; API access control for infrastructure management interfaces. For Authentication and Governance: Authentication requirements for infrastructure configuration changes; Service account governance for automated infrastructure management; Resource tagging and permission boundaries; Escalation paths for quota and access modifications.

   1. Assess Change Management Policies: Review policies governing: customer self-service capabilities vs. provider-managed changes, approval workflows for infrastructure quota increases, risk assessment processes for customer-initiated infrastructure changes, guardrails and protective limitations on customer capabilities, monitoring of customer infrastructure modification activities, intervention thresholds for performance-impacting changes, automated validation of customer infrastructure templates, and resource utilization monitoring and anomaly detection.

2. Obtaining and Verifying the Population of Records: Obtain Complete Asset Population: Gather inventory of infrastructure components customers can modify: AI accelerator (GPU/TPU) pools and configuration interfaces, compute instance types available for AI workloads, storage system configuration options, network fabric settings accessible to customers, resource schedulers and orchestration tools, infrastructure-as-code templates and deployment pipelines, container orchestration platforms and configurations, and customer-configurable monitoring and alerting systems. Verify that the population is complete.

3. Inspecting Records and Documents: 3.1 Choose a diverse sample of infrastructure components that customers can modify, such as: high-demand GPU/TPU configurations, specialized AI accelerator hardware, high-performance storage tiers, low-latency network interconnects, auto-scaling compute clusters, custom container environments for AI workloads, infrastructure-as-code deployment pipelines, and resource allocation and scheduling systems.

   1. Obtain Access Control Lists: For each sampled infrastructure component, collect: user and account access permissions, role definitions and assignments, service principal and API key permissions, customer tenant isolation boundaries, resource quota configurations, permission boundary definitions, service control policies, and administrative access override capabilities.

   2. Validate Access List Completeness: Verify the completeness of access lists through: reviewing script logic for access report generation, cross-referencing with identity management systems, comparing against role definition repositories, validating against authentication logs, reconciling with customer subscription records, and examining API gateway access configurations.

   3. Verify Access Restrictions: For each sampled infrastructure component, validate that access is properly restricted. For Examining Access Control Mechanisms: review role-based access control implementations, verify tenant isolation in multi-tenant environments, confirm resource hierarchy permission inheritance, validate quota enforcement mechanisms, check API rate limiting and throttling configurations, assess permission boundary implementations, and review network-level access controls. For Reviewing Privileged Access Management: verify separation between provider administrative access and customer access, confirm just-in-time access for privileged operations, check approval workflows for elevated permissions, validate audit logging for privileged operations, assess emergency access procedures, and review service account governance. For Analyzing Deployment Pipeline Controls: examine infrastructure-as-code pipeline authorization checks, verify template validation before deployment, confirm policy-as-code enforcement, review deployment approval workflows, check pipeline execution permissions, and validate pre-deployment security and compliance scanning. For Testing Access Enforcement: verify unauthorized customer accounts cannot exceed quotas, confirm platform prevents cross-tenant resource access, test that permissions align with documented roles, validate that infrastructure policy guardrails cannot be bypassed, check that service limits are properly enforced, and verify logging and alerting for access control violations.

   4. Assess AI-Specific Access Controls: Evaluate specialized controls for AI infrastructure: quota management for scarce GPU/TPU resources, cost control mechanisms for expensive accelerators, performance protection for shared infrastructure, data locality and sovereignty enforcement, memory and storage allocation limits, specialized monitoring for AI workload anomalies, and fair use policies for distributed training.

From CCM v4.1:

1. Examine the policy relating to the authorisation of changes in assets.

2. Examine the implementation of such policy, technical controls, and their effectiveness.

CCC-05: Change Agreements

Control Specification

Include provisions limiting changes directly impacting service customers owned environments (tenants) to explicitly authorized requests within service level agreements.

Auditing Guidelines for Cloud Service Providers (CSP)

1. Inquiring with Control Owners: Conduct interviews with personnel responsible for managing cloud infrastructure changes and customer compute environment modifications to understand authorization processes for altering AI processing resources in customer tenants. Verify their understanding of controls that prevent unauthorized changes to compute configurations, storage access, or network settings that directly impact customer AI workloads and data processing capabilities.

2. Inspecting Records and Documents: 2.1 Review Cloud Infrastructure Deployment Change Policies: Evaluate policies governing updates to compute resources, storage configurations, network settings, and AI accelerator allocations that affect customer tenant environments.

   1. Inspect Customer Cloud Service Agreements: Look for restrictions on automatic infrastructure updates, changes to compute resource allocation, storage access modifications, or alterations to network configurations and AI processing capabilities.

   2. Assess Infrastructure Rollback or Configuration Control Mechanisms: Customers should be able to maintain specific infrastructure configurations or reject resource-impacting updates. Review infrastructure versioning, tenant isolation controls, or customer-managed resource settings.

   3. Verify Infrastructure Change Authorization Processes: Examine documented procedures requiring explicit customer authorization before implementing changes to compute resources, storage access, or network configurations that directly impact customer AI workload performance.

   4. Review Customer Infrastructure Change Documentation: Validate that customers receive proper notification and authorization requests before infrastructure changes that affect their AI processing capabilities or data access patterns.

   5. Examine SLA Compliance for Infrastructure Service Modifications: Confirm that cloud infrastructure changes maintain agreed resource allocation parameters and customer-authorized performance specifications.

From CCM v4.1:

1. Examine policy and/or procedures related to change management to determine whether provisions are included for limiting changes directly impacting CSCs owned environments/tenants to explicitly authorized requests within service level agreements between CSPs and CSCs.

2. Examine relevant documentation, observe relevant processes, and/or interview the control owner(s), and/or relevant stakeholders, as needed, for change agreements and determine if the policy control requirements stipulated in the policy have been implemented.

3. Examine measures that evaluate the organization’s change agreement policy and determine if these measures are implemented according to policy control requirements.

CCC-06: Change Management Baseline

Control Specification

Establish, document and implement change management and configuration baselines for all relevant authorized changes on organization assets. Review and update the baselines at least annually, or upon significant changes.

Auditing Guidelines for Cloud Service Providers (CSP)

1. Verify configuration baselines are defined, maintained for relevant assets, and reviewed/updated at least annually or upon significant changes, with evidence of updates.

From CCM v4.1:

1. Examine policy and/or standards related to change management to determine if changes are formally controlled, documented and enforced to minimize the corruption of information systems.

2. Determine if the introduction of new systems and major changes to existing systems are formally documented, specified, tested, quality controlled, and the implementation managed.

CCC-07: Detection of Baseline Deviation

Control Specification

Implement detection measures with proactive notification in case of changes deviating from the established baseline.

Auditing Guidelines for Cloud Service Providers (CSP)

1. Inquiry with Control Owners: 1.1 Interview monitoring and operations personnel responsible for detecting changes to AI infrastructure. Obtain and review the organization’s monitoring strategies, alert thresholds, and notification workflows for: AI accelerator (GPU/TPU) performance characteristics, distributed computing environment configurations, high-performance storage system metrics, specialized networking fabric performance, hardware driver and firmware versions, and resource allocation and scheduling policies. Verify the existence of documented detection mechanisms for: hardware performance degradation patterns, driver compatibility or stability issues, storage throughput and latency deviations, network fabric performance regression, resource contention and scheduling anomalies, and infrastructure capacity constraints. Identify monitoring tools used for: hardware telemetry collection and analysis, accelerator-specific performance profiling, storage I/O pattern monitoring, network packet flow analysis, resource utilization heat mapping, and distributed system synchronization monitoring.

   1. Review Notification and Response Procedures: Examine documentation describing notification pathways when infrastructure issues are detected. Understand escalation procedures based on customer impact and resource criticality. Verify integration between detection systems and infrastructure engineering teams. Assess emergency response capabilities for high-severity infrastructure incidents impacting multiple customers. Review response playbooks for different types of infrastructure-related issues: accelerator hardware performance degradation, storage system throughput or latency issues, network fabric congestion or packet loss, resource scheduler inefficiencies, driver or firmware compatibility problems, and distributed system synchronization failures.

2. Obtaining and Verifying the Population of Records: 2.1 Define the complete population of monitoring records by inventorying monitoring systems for AI infrastructure, including hardware telemetry collection platforms, accelerator (GPU/TPU) monitoring systems, storage performance tracking tools, network fabric monitoring infrastructure, resource manager logging and metrics, virtualization and container monitoring, driver and firmware version tracking, and capacity planning and forecasting systems.

   1. Verify completeness of the population by cross-referencing monitoring coverage against the inventory of AI infrastructure component. Verify monitoring covers all regions, availability zones, and deployment models.

3. Inspection of Evidence: 3.1 Monitoring System Verification: Verify that monitoring systems are configured to detect deviations in the following categories. For AI Accelerator Performance: computational throughput (FLOPS, operations/second), memory bandwidth and utilization, power consumption and thermal characteristics, training/inference benchmark performance, error rates and correction events, and utilization efficiency across workloads. For Storage System Characteristics: I/O operations per second (IOPS), throughput (GB/s) for sequential access, latency distributions for different operation types, queue depths and blocking operations, cache hit rates and effectiveness, and storage capacity utilization trends. For Network Fabric Performance: bandwidth utilization for collective operations, latency profiles for inter-node communication, packet loss rates and retransmissions, congestion events and back pressure signals, quality of service enforcement effectiveness, and network topology efficiency. For Resource Management Effectiveness: allocation efficiency and resource fragmentation, scheduling fairness across customers, queue wait times for resource types, preemption rates and impact, resource affinity and locality effectiveness, and quota enforcement accuracy.

   1. Alert Configuration Assessment: Examine alert configuration to verify: tiered thresholds based on resource type and cost, graduated alerting based on deviation persistence, different sensitivity for different customer tiers, correlation between related infrastructure metrics, seasonality and workload-aware baselines, forecasting-based proactive notifications, and hardware generation-specific threshold adjustments.

   2. Sample-Based Testing of Detection Capabilities: Select a representative sample of infrastructure components and perform controlled tests: induce synthetic accelerator load patterns, create storage I/O contention scenarios, simulate network congestion conditions, generate resource allocation imbalances, inject driver or firmware compatibility issues, and test distributed system synchronization edge cases. Verify that monitoring systems: accurately detect the simulated issues, generate appropriate alerts with correct severity, include sufficient diagnostic context, trigger within expected timeframes, follow defined notification workflows, and properly identify fault domains and impact scope.

   3. Alert Notification Workflow Verification: Trace the notification path for different types of infrastructure issues: initial detection and enrichment with telemetry, routing to appropriate infrastructure teams, escalation for customer-impacting issues, hardware vendor coordination workflows, customer notification processes, maintenance scheduling integration, and cross-region incident coordination.

   4. Response Effectiveness Evaluation: Review historical infrastructure incidents to evaluate: time to detect performance deviations, quality of diagnostic information, response time to critical infrastructure issues, effectiveness of remediation actions, customer impact minimization, vendor coordination effectiveness, and root cause analysis thoroughness.

   5. Automated Remediation Assessment: Verify implementation of automated remediation for common issues: accelerator thermal throttling management, storage path failover mechanisms, network route optimization and reconfiguration, resource rebalancing and workload migration, driver rollback capabilities, self-healing distributed system recovery, and preemptive resource capacity expansion.

   6. Integration with Capacity Planning: Assess how detection systems feed into capacity management: early warning indicators for capacity constraints, trend analysis for resource utilization, predictive analytics for hardware procurement, seasonal demand pattern recognition, capacity risk assessment automation, hardware lifecycle and refresh monitoring, and geographic expansion trigger indicators.

From CCM v4.1:

1. Examine measures that evaluate the organization’s compliance with the change management policy and determine if these measures are implemented according to policy control requirements.

CCC-08: Exception Management

Control Specification

Implement a procedure for the management of exceptions, including emergencies, in the change and configuration process. Align the procedure with the requirements of GRC-04: Policy Exception Process.

Auditing Guidelines for Cloud Service Providers (CSP)

1. Inquiry with Control Owners: 1.1 Understand Infrastructure Exception Handling Practices: Interview infrastructure operations leaders, hardware engineers, and data center managers responsible for exception handling. Review documented exception policies covering: emergency hardware/firmware updates and infrastructure maintenance, expedited capacity expansion and resource reallocations (e.g., GPU/TPU), disruption response (e.g., network, storage, power, environmental), and post-incident review and documentation requirements. Verify that exception criteria are clearly defined for: emergencies requiring immediate changes (e.g., failures, vulnerabilities), expedited patches or reallocations due to performance constraints, and authorization levels needed based on severity and customer impact.

   1. Review Exception Process Documentation: Examine procedures and artifacts that detail: exception request templates and approval workflows, risk assessment steps for infrastructure-related exceptions, temporary approval and escalation pathways, required documentation and post-change validation, and exception tracking and status monitoring.

   2. Assess Emergency Response Protocols: Evaluate documented procedures for handling critical infrastructure events: hardware failures and firmware vulnerabilities, storage/data integrity issues or cache corruption, network fabric disruptions or latency spikes, power, cooling, or physical plant failures, and emergency resource quota adjustments.

   3. Evaluate Governance and Oversight Structures: Confirm existence of: designated approval authorities and escalation paths, on-call emergency response teams per infrastructure domain, exception review boards and governance charters, executive oversight and GRC-04 alignment, and integration with enterprise risk and incident management.

2. Define and Verify Population of Exception Records: 2.1 Complete Exception Inventory: Obtain a full inventory of exception records, including: emergency hardware/firmware updates, capacity expansion approvals, resource reallocation (e.g., accelerator pooling), and unplanned maintenance and retroactive exceptions.

   1. Cross-Verify for Completeness: Ensure population accuracy by cross-referencing monitoring alerts and change tickets, incident and escalation records, service status reports and customer impact notifications, post-incident reviews, and risk registers.

3. Exception Sample Selection and Testing: 3.1 Select Representative Exceptions: Choose samples that vary by: type (e.g., hardware update, network fix, quota increase), affected infrastructure (compute, storage, network), customer impact (high, medium, low), approval level and timeframe, justification category (performance, failure, security).

   1. Evaluate Lifecycle of Each Exception: Review the following categories. Justification: clear rationale and urgency documented, evidence from monitoring or capacity thresholds, risk assessment and consideration of alternatives, and fit within defined exception criteria. Approval: approval by appropriate authority (or retroactively for emergencies), conditions/time limitations documented and followed. Implementation: verified through logs or infrastructure management tools, confined to approved scope and components, monitoring and mitigation applied during exception, stakeholder communication documented (e.g., customer alerts). Closure and Follow-up: timely closure and rollback (if applicable), validation tests conducted, lessons captured and documented, reintegration into standard processes completed.

4. Exception Tracking, Governance, and Continuous Improvement: 4.1 Assess Tracking and Oversight: Verify centralized tracking of infrastructure exceptions, expiration tracking for temporary approvals, governance reporting and executive visibility, trend analysis and identification of recurring issues, and integration with customer impact and risk reporting.

   1. Evaluate Improvement Mechanisms: Assess maturity of the CSP’s improvement processes: regular exception pattern reviews, incident-driven process refinements, reductions in emergency change frequency, improved emergency response calibration, updates to exception criteria as operations evolve, and infrastructure architecture adaptations to minimize exceptions.

From CCM v4.1:

1. Verify that the organization establishes and documents mandatory configuration settings for information technology products employed within the information system, as determined by adoption of the latest suitable security configuration baselines.

2. Confirm that the process identifies, documents, and approves exceptions from the mandatory established configuration settings for individual components based on explicit operational requirements.

3. Determine that the organization monitors and controls changes to the configuration settings in accordance with organizational policy and procedures.

CCC-09: Change Restoration

Control Specification

Define and implement a process to proactively roll back changes to a previous known good state in case of errors or security concerns.

Auditing Guidelines for Cloud Service Providers (CSP)

1. Inquiry with Control Owners: 1.1 Interview Infrastructure Operations Teams and Review Rollback Policies: Interview infrastructure operations leaders, hardware engineers, and data center managers responsible for AI infrastructure change management and rollback processes, and obtain organizational rollback policies and procedures including criteria for initiating infrastructure rollbacks, rollback decision authority matrix for different infrastructure components, emergency rollback procedures for critical hardware/firmware issues, planned rollback testing requirements for infrastructure changes, post-rollback validation protocols for AI workload performance, and rollback process documentation requirements for customer communication, while verifying documented criteria for hardware/firmware issues requiring immediate rollback, performance degradation thresholds warranting rollback, security vulnerabilities requiring immediate remediation, resource availability issues necessitating configuration rollback, and customer impact thresholds triggering intervention.

   1. Review Process Documentation and State Management: For Rollback Process Documentation, examine documentation describing rollback planning requirements for all infrastructure changes, technical rollback mechanisms for different infrastructure components including accelerator (GPU/TPU) driver and firmware rollback, compute cluster configuration restoration, storage system configuration rollback, network fabric and interconnect parameter rollback, resource scheduler configuration restoration, and virtualization platform version rollback, along with multi-tenant impact management during rollbacks, communication protocols for AI workload customers during rollbacks, service-level agreement considerations during infrastructure rollbacks, and verification requirements after infrastructure rollback. For Known Good State Management, review procedures for establishing and validating known good states including definition of “known good state” for AI infrastructure components, infrastructure performance benchmarking requirements, configuration snapshot and backup procedures, hardware-software compatibility validation procedures, performance characteristic documentation for stable configurations, version tagging for firmware, drivers, and configuration artifacts, and AI workload validation tests for baseline configurations.

   2. Evaluate Deployment Architecture: Assess how the deployment architecture supports rollback capabilities through infrastructure-as-code implementation and versioning, configuration management database (CMDB) capabilities, hardware firmware/driver rollback mechanisms, hypervisor and container platform version management, network configuration version control, resource management policy versioning, and automated infrastructure deployment pipeline rollback capabilities.

2. Inspection of Evidence: 2.1 Rollback Strategy Documentation Review: Verify comprehensive rollback strategy documentation, including: Component-Specific Rollback Approaches (accelerator hardware driver/firmware rollback, compute cluster configuration restoration, storage system parameter and firmware rollback, network fabric configuration rollback, resource scheduler policy restoration, virtualization/container platform version rollback, infrastructure monitoring system rollback); Rollback Decision Process (performance degradation thresholds triggering rollback, security vulnerability severity assessment methodology, customer workload impact evaluation process, decision authority and escalation protocols for different components, multi-tenant impact consideration in decision-making); Rollback Execution Process (step-by-step rollback procedures for each infrastructure component, required validation steps during rollback execution, customer workload handling during transitions, dependency management across infrastructure layers, order of operations for complex multi-component rollbacks, monitoring requirements during transition states); Post-Rollback Activities (infrastructure performance validation procedures, customer workload validation requirements, notification procedures for affected customers, root cause analysis requirements, documentation and knowledge capture, long-term remediation planning).

   1. Tools and Technical Implementation Assessment: Evaluate tools and technical implementations supporting rollback, including: infrastructure-as-code version control, configuration management database implementation, hardware management interfaces and rollback capabilities, firmware/driver repository management, infrastructure monitoring during transitions, automated configuration deployment and rollback, testing frameworks for infrastructure validation, and resource scheduling and workload migration tools.

   2. Sample-Based Testing of Rollback Capabilities: Select a representative sample of infrastructure components and verify: Rollback Planning (documentation of rollback plans for recent infrastructure changes, identification of known good configuration states, customer workload impact analysis for potential rollbacks, testing protocols for validating rolled back configurations, time and resource estimates for rollback execution); Rollback Testing (evidence of regular rollback capability testing, performance benchmarking following test rollbacks, simulation exercises for critical infrastructure components, customer workload validation during test rollbacks, measurement of infrastructure restoration times); Known Good State Verification (infrastructure performance validation procedures, configuration validation against baselines, hardware-software compatibility verification, documentation of acceptable performance parameters, preservation of configuration artifacts for known good states).

   3. Previous Rollback Execution Review: For a sample of previously executed rollbacks, verify: Rollback Trigger Assessment (clear documentation of infrastructure issues triggering rollback, alignment with defined performance or security criteria, customer impact assessment documentation, appropriate authority involvement in decision); Rollback Execution Documentation (component-specific rollback execution records, configuration management and version control evidence, issues encountered during transition, timing of infrastructure restoration, communication to affected customers); Post-Rollback Activities (infrastructure performance verification results, customer workload validation outcomes, impact assessment on AI workloads, root cause identification for original issue, preventative measures implementation).

   4. Automated Monitoring and Rollback Integration: Assess the integration between monitoring systems and rollback processes: automated detection of infrastructure performance degradation, hardware failure and anomaly detection capabilities, resource utilization monitoring and threshold alerting, automated rollback triggers for critical infrastructure issues, progressive configuration deployment with automatic reversion, and continuous performance monitoring during transition periods.

   5. Customer Communication Procedures: Evaluate procedures for customer communication during rollbacks: proactive notification protocols based on service tier, status update frequency during rollback operations, expected impact and timeline communications, customer-specific workload handling guidance, post-rollback verification communication, and root cause explanation and remediation planning.

3. Evaluation and Reporting: 3.1 Rollback Capability Effectiveness Assessment: Evaluate how well rollback processes: meet defined recovery time objectives for different service tiers, successfully restore infrastructure performance to baseline levels, maintain hardware-software compatibility, minimize customer workload disruption, cover all AI infrastructure components comprehensively, balance automated detection and human judgment, and scale across deployment environments and availability zones.

   1. Known Good State Management Assessment: Assess the effectiveness of known good state management: clarity of infrastructure performance baseline definition, comprehensive validation of configuration changes before promotion, preservation of configuration artifacts and snapshots, accessibility of configuration backups during incidents, and frequency of validation testing for known good configurations.

   2. Rollback Process Documentation Quality: Evaluate the quality of rollback process documentation: clarity of component-specific rollback procedures, technical details for different hardware and software combinations, customer impact considerations across service tiers, accessibility to operations and incident response teams, alignment with actual infrastructure architecture, and regular updates following infrastructure changes.

   3. Continuous Improvement Mechanisms: Evaluate processes for improving rollback capabilities: regular review of infrastructure recovery metrics, incorporation of lessons learned from performance incidents, technical capability enhancement for faster restoration, process refinement based on customer feedback, architectural improvements to simplify rollback procedures, and evolution of infrastructure validation methods.

From CCM 4.1:

1. Examine policy and/or procedures related to change management and determine if roll back procedures are defined and implemented, including procedures and responsibilities for aborting and recovering from unsuccessful changes and unforeseen events.

2. Examine relevant documentation, observe relevant processes, and/or interview the control owner(s) and/or relevant stakeholders, as needed to ensure that roll back procedures are defined and implemented and determine if the policy control requirements stipulated in the policy have been implemented. Select a sample of changes and examine the change management record to confirm that the change was assessed and included appropriate fallback procedures in the event of a failed change.

3. Examine measure(s) that evaluate(s) the organization’s compliance with the change management policy and determine if these measures are implemented according to policy control requirements.

4. Obtain and examine supporting documentation maintained as evidence of these metrics, measures, tests, or audits to determine if the office or individual responsible reviews the information and, if issues were identified, they were investigated and corrected.

CEK: Cryptography, Encryption & Key Management

CEK-01: Encryption and Key Management Policy and Procedures

Control Specification

Establish, document, approve, communicate, apply, evaluate and maintain policies and procedures for Cryptography, Encryption and Key Management. Review and update the policies and procedures at least annually, or upon significant changes.

Auditing Guidelines for Cloud Service Providers (CSP)

1. Policy Examination: Verify that the CSP has established and documented a comprehensive Cryptography, Encryption, and Key Management (CEK) policy that addresses cryptographic functions across the cloud infrastructure and service layers. Confirm that the policy covers key management systems (KMS), hardware security modules (HSMs), encryption of storage and networking layers, and tenant-specific key isolation where applicable.

2. Governance: Confirm that the CEK policy is formally approved by senior leadership and that approval records are maintained, such as entries in a policy registry, minutes from change control boards, or executive-level sign-off documents. Verify that a designated policy owner is assigned and that the CEK policy is reviewed and updated at least annually or after significant events such as the release of a new key management service, deprecation of encryption algorithms, or changes in regulatory or industry requirements.

3. Communication: Review evidence that the CEK policy has been communicated to internal operational teams such as security engineering, cloud platform operations, DevOps, and compliance. Acceptable evidence may include internal bulletins, training session records, policy acknowledgments, or documentation updates distributed across engineering teams.

4. Implementation Validation: Validate enforcement of the CEK policy by inspecting infrastructure configuration baselines, service-level encryption defaults, KMS or HSM configuration states, and CI/CD pipeline integrations. Confirm that these technical controls align with the policy’s stated objectives and reflect current implementation across services.

5. Role Assignment: Review the policy and related documentation to confirm that specific CEK responsibilities are assigned to appropriate cloud infrastructure teams, cryptographic service owners, platform security architects, and compliance leads. Ensure that each role has clearly defined accountability for key lifecycle operations and cryptographic oversight.

6. Training and Awareness: Inspect training records, knowledge base materials, and onboarding documentation to ensure that personnel responsible for CEK implementation and operations have received adequate training. Confirm that awareness programs include guidance on secure key generation, encryption management, and incident response.

7. Compliance Monitoring: Evaluate how the CSP monitors adherence to its CEK policy. Confirm the presence of automated key usage auditing, anomaly detection for unauthorized access, periodic control reviews, and policy enforcement verification through internal audits or security tooling.

8. Upstream and Downstream Dependencies: Confirm that the CSP’s CEK policy includes explicit support for downstream entities such as Application Providers (APs), Orchestrated Service Providers (OSPs), Model Providers (MPs), and AI Customers (AICs). Verify that the policy enables secure cryptographic operations by offering capabilities such as Bring Your Own Key (BYOK), Hold Your Own Key (HYOK), key separation for tenants, and support for contractual encryption guarantees when required.

From CCM v4.1:

1. Review cryptography, encryption, and key management policy and procedures and confirm that these have been approved by appropriate management.

2. Confirm that the policy and procedures are reviewed at least annually.

CEK-02: CEK Roles and Responsibilities

Control Specification

Define and implement cryptographic, encryption and key management roles and responsibilities.

Auditing Guidelines for Cloud Service Providers (CSP)

1. Verify that CSP roles and responsibilities are defined in formal policies and procedures for cryptographic, encryption, and key management operations (e.g., KMS operation, encryption enforcement, incident response).

2. Confirm that AI-specific responsibilities are defined in alignment with the CSP’s role (e.g., managing tenant-specific encryption for AI services, enabling secure LLM API integrations, enforcing cryptographic isolation in multi-tenant environments) and that role assignments are documented and maintained.

3. Review documentation to confirm that responsibilities are mapped to designated roles or teams (e.g., KMS administrators, cloud infrastructure engineering, platform security).

4. Validate that responsibilities related to AI workloads and encryption isolation (e.g., BYOK/HYOK setup, data segregation for GenAI tenants) are assigned to personnel responsible for customer-facing or shared services.

5. Verify that segregation of duties is enforced between teams responsible for key generation, encryption enforcement, and operational support of AI workloads.

6. Confirm that staff assigned to responsibilities have received training on cryptographic best practices, infrastructure-level controls, and AI-specific encryption challenges.

7. Verify that role assignments are reviewed at least annually or upon major changes to cryptographic infrastructure, platform capabilities, or AI service offerings.

8. Confirm that governance structures oversee role assignment and periodically assess alignment with cryptographic risk posture, regulatory expectations, and cloud service architecture.

9. Validate that continuity and succession plans are in place, with alternate personnel trained to perform functions in the event of absence or turnover.

10. Verify that responsibilities include coordination with upstream cryptographic services and downstream tenants (e.g., APs, OSPs, AICs), ensuring that encryption services support secure key provisioning, tenant isolation, and shared control models (e.g., BYOK).

From CCM 4.1:

1. Obtain cryptographic, encryption policy, and key management procedures.

2. Verify, by interviews or otherwise, that employees and stakeholders are aware of their roles and responsibilities, and obtain supporting documentation evidencing that the responsibilities are being managed in-line with policy and procedures.

CEK-03: Data Protection

Control Specification

Provide data protection at-rest, in-transit and, where applicable, in-use by using cryptographic libraries certified to approved standards.

Auditing Guidelines for Cloud Service Providers (CSP)

1. Verify that the CSP enforces encryption of data at-rest and in-transit across its cloud infrastructure, including storage services, networking layers, and compute environments, using cryptographic libraries certified to approved standards (e.g., FIPS 140-2/3).

2. Confirm that the encryption algorithms and protocols used (e.g., AES-256, TLS 1.3, RSA-2048) are appropriate for the classification of the protected data and are consistently applied across service layers.

3. Review platform-level configurations, default encryption settings, and service templates to validate the enforcement of encryption for customer workloads, control plane traffic, and metadata.

4. Validate that customer-facing services include capabilities to configure or enforce encryption, including tenant-level encryption policies, key selection (e.g., CSP-managed, BYOK), and automatic encryption toggles.

5. Confirm that AI-related services (e.g., model hosting, inference APIs, storage of prompt/completion data) are protected by the same cryptographic mechanisms, and that LLM-specific data flows are not exempt from encryption policies.

6. Review documentation and service descriptions to ensure that data encryption mechanisms are exposed and clearly explained to customers, including implementation standards, key storage locations, and responsibilities.

7. Verify that cryptographic modules (e.g., KMS, HSMs, TLS libraries) are implemented and maintained according to secure coding practices and approved validation schemes.

8. Confirm that the CSP maintains and updates an inventory of cryptographic libraries and protocols in use and that deprecated or weak algorithms are phased out systematically.

9. Review evidence that encryption enforcement is monitored through automated compliance checks, alerts, and internal audit reviews, with exceptions formally tracked and approved.

10. Verify that the CSP provides customers and downstream roles (e.g., APs, AICs) with tools or APIs to confirm encryption status, configure encryption policies, and receive audit logs related to data protection practices.

From CCM v4.1:

1. Identify data flows within the organization that are in-transit.

2. Identify data storages within the organization that are at-rest.

3. Confirm that the identified data flows and data storages have been protected by an appropriate cryptographic algorithm aligned to cryptography, encryption, and key management policy and procedures.

CEK-04: Encryption Algorithm

Control Specification

Utilize encryption algorithms following industry standards for protecting data, based on the data classification and associated risks.

Auditing Guidelines for Cloud Service Providers (CSP)

1. Verify that the CSP maintains a documented standard for approved encryption algorithms aligned with data classification levels (e.g., confidential, regulated, sensitive) and global cryptographic standards (e.g., NIST, ISO, ENISA).

2. Confirm that algorithms used for encryption at rest and in transit (e.g., AES-256, RSA-2048, TLS 1.3) are certified or validated, and confirm that they are mapped to specific service tiers, storage types, and transmission protocols.

3. Review whether algorithm effectiveness is periodically reassessed to address known vulnerabilities, cryptographic deprecation (e.g., SHA-1), or regulatory changes, and confirm that retirement or replacement procedures are documented.

4. Validate that algorithm selection accounts for operational considerations including latency, performance, and compatibility across CSP service offerings (e.g., storage, compute, network encryption layers).

5. Confirm that algorithm usage is consistently enforced across all service layers, including encryption of control plane communications, customer data, metadata, and backup services.

6. Verify that encryption algorithms are tightly integrated with the CSP’s key management infrastructure (e.g., KMS, HSM), and that usage policies enforce isolation, access boundaries, and proper key pairing.

7. Review whether encryption algorithm use is governed through approval processes involving cryptography or platform security teams, with documentation of review cycles and escalation paths.

8. Confirm that third-party components embedded in the CSP infrastructure (e.g., firmware, load balancers, backup appliances) use encryption algorithms that comply with CSP standards and undergo regular security vetting.

9. Validate that algorithm issues identified through internal audits, penetration tests, customer escalations, or regulatory assessments are tracked and addressed within the algorithm lifecycle governance process.

10. Verify that the CSP supports downstream encryption compatibility by publishing supported algorithm suites and offering configuration options (e.g., customer-defined cipher suites), while maintaining interoperability with upstream libraries or dependencies.

From CCM v4.1:

1. Identify the encryption algorithms in use.

2. Confirm that identified encryption algorithms have been reviewed and approved by appropriate management.

3. Confirm that the encryption algorithm approval process includes assessment of the appropriateness of the algorithm for the data it is protecting, any associated risks, and the algorithm’s usability.

CEK-05: Encryption Change Management

Control Specification

Establish a standard change management procedure, to accommodate changes from internal and external sources, for review, approval, implementation and communication of cryptographic, encryption and key management technology changes.

Auditing Guidelines for Cloud Service Providers (CSP)

1. Verify that the CSP maintains a documented change management procedure specifically for cryptographic, encryption, and key management technologies, covering infrastructure-layer services (e.g., KMS, HSM, TLS endpoints).

2. Confirm that the procedure accommodates changes from both internal sources (e.g., platform enhancements, algorithm updates) and external sources (e.g., industry deprecations, regulatory mandates, customer requirements).

3. Review whether CEK-related change requests are tracked in a centralized system and routed through formal change review and risk assessment processes (e.g., CAB, security design review).

4. Verify that roles and responsibilities are clearly defined for CEK change request review, approval, testing, and rollout, including participation from cryptographic engineers, infrastructure leads, and compliance officers.

5. Confirm that each approved CEK change includes a structured implementation plan, with defined testing procedures, contingency/rollback steps, and timeline for execution.

6. Review how changes are communicated to internal teams (e.g., operations, DevOps, customer engineering) and external stakeholders (e.g., tenants impacted by changes to cryptographic behavior).

7. Validate that version control is enforced for encryption configurations, key policy templates, and any code or automation artifacts related to the CEK change.

8. Verify that post-implementation testing is conducted to validate the effectiveness of the change, including automated checks for service availability, encryption correctness, and logging integrity.

9. Confirm that full CEK change documentation is maintained, including testing results, implementation notes, approval evidence, and communications, and confirm that it is available for audits and tenant assurance requests.

10. Review whether CEK change management includes analysis of upstream dependencies (e.g., third-party crypto libraries, hardware appliances) and downstream impact on tenants and shared service consumers.

From CCM v4.1:

1. Examine policy and procedures and obtain evidence that these include the change management process.

2. Obtain representative samples of recent changes relating to cryptographic, encryption, and key management technology.

3. Confirm that sample changes have followed the organization change management procedures, including approval by appropriate individuals, communication of changes to relevant stakeholders, and assessment of the success of implementing changes with any required remediation actions being tracked.

CEK-06: Encryption Change Cost Benefit Analysis

Control Specification

Manage and adopt changes to cryptography-, encryption-, and key management-related systems (including policies and procedures) that fully account for downstream effects of proposed changes, including residual risk, cost, and benefits analysis.

Auditing Guidelines for Cloud Service Providers (CSP)

1. Verify that the CSP maintains a documented process for managing changes to cryptographic, encryption, and key management systems, including updates to infrastructure services (e.g., KMS, HSM), platform APIs, and customer-facing controls.

2. Confirm that proposed changes are reviewed and approved through formal governance mechanisms (e.g., architecture review boards, compliance committees, service design review).

3. Review whether each CEK-related change includes a cost-benefit analysis that considers trade-offs between security improvements, operational cost, performance, compliance alignment, and customer impact.

4. Validate that residual risks introduced by CEK changes are documented, evaluated, and either mitigated or accepted with appropriate justification.

5. Confirm that the downstream impact of proposed changes is assessed, particularly for services used by tenants (e.g., changes to key generation algorithms, access controls, or BYOK capabilities).

6. Verify that relevant internal stakeholders, including platform security, service owners, operations, legal, and customer support, are engaged in planning, review, and approval of CEK-related changes.

7. Review whether version tracking, rollback procedures, and documentation are maintained for all cryptographic changes, including infrastructure upgrades and tenant-impacting service modifications.

8. Validate that CEK changes are monitored post-implementation to confirm that intended security or performance benefits are realized, and validate that negative side effects (e.g., degraded service, integration breakage) are promptly addressed.

9. Confirm that lessons learned from prior CEK changes (e.g., audit findings, incident postmortems, customer feedback) are documented and factored into future risk and cost-benefit evaluations.

10. Verify that changes affecting upstream dependencies (e.g., cryptographic libraries, cloud hardware providers) and downstream consumers (e.g., APs, OSPs, AICs) are reviewed for compatibility and communicated where relevant.

From CCM v4.1:

1. Obtain a copy of the change management policy and procedures. Confirm that these documents include assessment of impact on downstream effects, including residual risk, cost, and benefit analysis.

2. Examine recent changes made to cryptography-, encryption-, and key management-related systems (including policy and procedures), and confirm that these changes include an account of downstream effects of proposed changes, including residual risk, cost, and benefits analysis.

3. Confirm that the changes have been reviewed and approved by appropriate management.

CEK-07: Encryption Risk Management

Control Specification

Establish and maintain an encryption and key management risk program that includes provisions for risk assessment, risk treatment, risk context, monitoring, and feedback.

Auditing Guidelines for Cloud Service Providers (CSP)

1. Verify that the CSP has a documented CEK risk management program covering cryptographic services across cloud infrastructure, including KMS, HSMs, and tenant encryption support.

2. Confirm that CEK risks are contextualized based on infrastructure layers, service models (e.g., IaaS, PaaS, SaaS), tenant-specific encryption requirements, and jurisdictional or regulatory factors.

3. Review the risk assessment methodology used to evaluate CEK risks, including how key exposure, data classification, control maturity, and threat likelihood are quantified.

4. Verify that a CEK-specific risk register is maintained, documenting known vulnerabilities, associated risks, treatment plans, responsible teams, and risk disposition timelines.

5. Confirm that CEK treatment strategies include service reconfiguration (e.g., key isolation), upgrades (e.g., algorithm replacement), or compensating controls (e.g., data access throttling, increased logging).

6. Validate that residual CEK risks are reviewed by cloud risk governance forums and updated following significant architecture changes, security incidents, or compliance findings.

7. Review how CEK risks are monitored through ongoing controls such as encryption coverage scans, key usage monitoring, tenant isolation testing, and compliance dashboards.

8. Confirm that lessons learned from incidents, customer-reported issues, or audit findings feed into the CEK risk program and lead to updates in service design or policy.

9. Verify that CEK risks tied to multi-tenancy, shared cryptographic infrastructure, or tenant misconfiguration (e.g., improper key policy enforcement) are included in the risk register.

10. Validate that the CSP accounts for upstream component risks (e.g., hardware supply chain, crypto libraries) and downstream consumer expectations (e.g., AP, OSP, AIC encryption guarantees) in its CEK risk posture and documentation.

From CCM v4.1:

1. Identify and confirm the existence of the organization’s risk assessment process and obtain the risk register.

2. Confirm that the risk register includes as part of a regular process or control review encryption and key management.

3. Obtain evidence that demonstrates that a risk assessment is performed of the encryption and key management program and process.

CEK-08: Service Customer Key Management Capability

Control Specification

Service providers must provide the capability for service customers to manage their own data encryption keys.

Auditing Guidelines for Cloud Service Providers (CSP)

1. Verify that the CSP provides technical capabilities that allow AICs to manage their own cryptographic keys (e.g., BYOK, HYOK, customer-managed KMS) within the CSP’s infrastructure or services.

2. Confirm that keys provisioned by the AIC are logically isolated and that the CSP enforces tenant-level key usage boundaries to ensure cryptographic separation across customer environments.

3. Validate that CSP systems support key lifecycle operations under AIC control, including key generation, import, rotation, revocation, and deletion.

4. Verify that the CSP makes available audit logs or monitoring tools that allow AICs to track key usage events, such as access, encryption, decryption, and administrative changes.

5. Review whether service agreements, documentation, or customer policies clarify the scope of AIC key control, including enforceable rights and limitations on key visibility and usage.

6. Confirm that the CSP assigns clear responsibility to internal roles or teams (e.g., cloud security engineering, cryptographic services) for supporting and maintaining AIC key control capabilities.

7. Verify that exceptions to AIC-managed key usage are documented and accompanied by compensating controls, fallback options, or roadmaps for future support.

8. Validate that CSP customers can securely test their key configurations prior to deployment of sensitive or production data within the CSP environment.

9. Confirm that AIC key control features and supporting infrastructure are subject to periodic review and validation by CSP governance bodies or CEK oversight functions.

10. Verify that the CSP supports downstream AIC key control requirements across its cloud service offerings and evaluates upstream dependencies (e.g., HSMs, KMS APIs, third-party encryption services) to ensure ongoing support for secure, auditable, and isolated key management.

From CCM:

1. Identity CSP’s data key encryption policy and standards.

2. Review the implementation of the CSP key broker and key management services (KMS) and the cloud hardware security modules (HSMs).

3. Confirm that the configuration enables appropriate management of the key (e.g., customer-managed master key, CSP-managed master key, CSP-owned master key).

4. Confirm that HSM meets internal compliance standards (e.g., FIPS 140-2).

CEK-09: Encryption and Key Management Audit

Control Specification

Audit encryption and key management systems, policies, and processes with a frequency that is proportional to the risk exposure of the system with audit occurring preferably continuously but at least annually and after any security event(s).

Auditing Guidelines for Cloud Service Providers (CSP)

1. Verify that the CSP encryption and key management systems, policies, and processes are audited at a frequency that reflects the associated risk exposure preferably continuously but at least annually and after any security event.

2. Confirm that audits are also triggered by material changes to cryptographic infrastructure, key lifecycle operations, cloud service configurations, or security policy updates.

3. Review the scope of CEK audits to ensure coverage of core infrastructure components, including KMS, HSMs, encryption libraries, tenant isolation controls, and any CEK-as-a-service offerings.

4. Validate that audits assess compliance with internal CSP encryption policies and external frameworks (e.g., NIST 800-57, ISO/IEC 27001/27017/27701), including algorithm selection, access control, key handling, and lifecycle enforcement.

5. Verify that CEK audits are conducted independently of operational teams responsible for cryptographic system administration or cloud service delivery.

6. Confirm that audit results are formally documented, reviewed by security and compliance leadership, and followed by corrective actions for any gaps, control failures, or policy deviations.

7. Review whether audit findings and CEK risks are communicated to internal stakeholders, including platform engineering, product security, legal, and customer compliance support teams.

8. Verify that automated monitoring and logging tools (e.g., key usage dashboards, CEK audit agents) are implemented to support continuous or near-real-time audit coverage of CEK-related activities.

9. Confirm that CEK audit procedures cover customer-facing encryption controls, including BYOK/HYOK, tenant key isolation, and compliance with shared responsibility obligations.

10. Validate that CEK audit procedures are reviewed and updated periodically to reflect changes in cryptographic standards, CSP risk posture, emerging threats, and coordination requirements with upstream providers and downstream consumers.

From CCM v4.1:

1. Examine the master audit plan to confirm that audits of encryption and key management systems, policy and processes are included in the plan.

2. Review previously completed audits and confirm that audits of encryption and key management systems, policy and processes have been completed and that any issues raised have been included in issue logs and tracked appropriately.

CEK-10: Key Generation

Control Specification

Generate Cryptographic keys using industry accepted cryptographic libraries specifying the algorithm strength and the random number generator used.

Auditing Guidelines for Cloud Service Providers (CSP)

1. Verify that the CSP uses approved, standards-based cryptographic libraries (e.g., FIPS 140-2/3 certified) to generate encryption keys for cloud infrastructure services (e.g., storage, compute, networking) and tenant-facing key management systems.

2. Confirm that key generation processes specify algorithm type and strength (e.g., RSA-2048, AES-256), based on the classification of protected data and associated regulatory requirements.

3. Validate that cryptographic random number generators (RNGs) used for key generation comply with recognized standards (e.g., NIST SP 800-90A), and that entropy sources are appropriately managed across cloud regions.

4. Verify that key generation is automated and integrated into secure provisioning systems (e.g., KMS, HSM-backed infrastructure, service control planes), with strict identity and access controls.

5. Review permissions and audit configurations to ensure only authorized personnel, services, or tenants are allowed to initiate or request key generation.

6. Confirm that tenant-scope keys (e.g., BYOK, HYOK) and system-level keys (e.g., boot disk encryption, object store encryption) follow the same generation standards and are managed separately.

7. Verify that keys are not hardcoded, embedded in service templates, or stored in cloud automation scripts or manifests.

8. Review logging mechanisms that capture key generation events, including tenant identifier (if applicable), algorithm used, source system, timestamp, and outcome.

9. Confirm that keys used in development or test environments are generated separately using logically isolated and cryptographically distinct RNG instances from those in production.

10. Validate that CSP key generation procedures are reviewed periodically to reflect evolving cryptographic standards, multi-tenant service risks, and dependencies with upstream crypto modules and downstream customer-managed encryption features.

From CCM v4.1:

1. Confirm that the organization has an approved process for the generation of cryptographic keys.

2. Identify the keys being used.

3. Observe the generation of an encryption key in a production-like sandbox or as a test tenant in production and confirm the keys have been generated according to the appropriate procedure and technical specifications.

CEK-11: Key Purpose

Control Specification

Manage cryptographic secret and private keys that are provisioned for a unique purpose.

Auditing Guidelines for Cloud Service Providers (CSP)

1. Verify that the CSP assigns cryptographic keys and secrets (e.g., tenant keys, HSM-stored credentials, API tokens) to a unique purpose (e.g., encryption, signing, authentication) and that purpose separation is enforced across cloud services, secret management systems, and cryptographic APIs.

2. Confirm that each key and secret is mapped to its intended function (e.g., volume encryption, TLS, identity verification) and that this mapping is documented, reviewed periodically, and integrated into key management systems.

3. Verify that technical and procedural controls prevent the reuse of a single key or secret for multiple cryptographic purposes across different cloud services or layers.

4. Review cryptographic service configurations (e.g., KMS, HSM policies) to ensure that key and secret usage is restricted to their assigned purpose within compute, storage, or networking scopes.

5. Confirm that access to purpose-bound keys and secrets is limited to authorized personnel, services, or systems based on their designated function and aligned with the principle of least privilege.

6. Validate that secrets and keys used in AI-related services (e.g., encrypted inference logs, signed outputs, model container authentication) are provisioned for distinct functions and not shared across services or tenants.

7. Review whether key and secret metadata includes attributes (e.g., tags, labels, purpose descriptors) that specify intended use and that enforcement of these attributes is implemented across cloud key management and monitoring tools.

8. Confirm that infrastructure-as-code (IaC), orchestration templates, and cloud deployment scripts enforce key and secret purpose separation, rejecting configurations that apply multi-use materials.

9. Verify that logging and audit mechanisms capture purpose-related usage metadata and detect any misuse of keys or secrets outside their defined function, with alerting or remediation triggers in place.

10. Validate that keys or secrets exposed to upstream or downstream parties (e.g., APs, AICs) are purpose-scoped and contractually or technically restricted from being reused for unrelated tasks or services.

From CCM v4.1:

1. Obtain copies of the policy and procedures detailing the management of secret and private cryptographic keys.

2. Identify cryptographic secret and private keys that have been provisioned for a unique purpose.

3. Ascertain that these keys are being managed in accordance with policy and procedures.

CEK-12: Key Rotation

Control Specification

Rotate cryptographic keys in accordance with the calculated cryptoperiod, which includes provisions for considering the risk of information disclosure and legal and regulatory requirements.

Auditing Guidelines for Cloud Service Providers (CSP)

1. Verify that the CSP rotates cryptographic keys in accordance with defined cryptoperiods, considering the risk of information disclosure and legal or regulatory requirements across cloud infrastructure, storage, and key management services.

2. Confirm that cryptoperiods are formally defined for each key type based on key usage, data classification, risk exposure, and applicable compliance requirements.

3. Verify that automated key rotation is implemented in supported services (e.g., KMS, HSM, database encryption), and manual key rotation follows documented procedures.

4. Review configuration baselines and key management system settings to ensure rotation schedules are enforced consistently and override attempts are monitored and approved.

5. Confirm that access to initiate or configure key rotation is limited to authorized cloud operations or security teams, following role-based access control and approval workflows.

6. Validate that cryptographic keys used in CSP services supporting AI workloads (e.g., encrypted model storage, prompt logging, inference caching) follow rotation schedules aligned with defined cryptoperiods.

7. Review audit logs to confirm that key rotation events are logged with relevant metadata (e.g., key ID, time, rotation trigger, system ID, user ID) and retained for auditability.

8. Confirm that rotated keys are distributed securely across CSP infrastructure and dependent services, ensuring continuity and preventing exposure of key material.

9. Verify that superseded or expired keys are securely archived or destroyed based on CSP data classification and compliance retention policies.

10. Confirm that the CSP coordinates key rotation schedules with downstream entities (e.g., APs, AICs) and evaluates upstream cryptographic dependencies to ensure uninterrupted encryption and trust continuity.

From CCM v4.1: Consider the symmetric vs. asymmetric key rotation capabilities of CSPs and an appropriate rotation process adopted.

1. Confirm that policy and procedures include a requirement for regular key rotation.

2. Identify keys used within the organization. Confirm that these keys are part of the rotation process.

3. Review the key rotation process to confirm logging and monitoring of key rotation, tracking of date, time, encryption algorithm used, and authorization process used.

CEK-13: Key Revocation

Control Specification

Define, implement and evaluate processes, procedures and technical measures to revoke and remove cryptographic keys prior to the end of its established cryptoperiod, when a key is compromised, or an entity is no longer part of the organization, which include provisions for legal and regulatory requirements.

Auditing Guidelines for Cloud Service Providers (CSP)

1. Verify that the CSP defines, implements, and evaluates processes, procedures, and technical measures to revoke and remove cryptographic keys prior to the end of their cryptoperiod when they are no longer needed, compromised, or associated with entities no longer authorized, including keys stored in cloud-native KMS, customer-scoped HSMs, or infrastructure secrets stores.

2. Confirm that key revocation criteria are documented, including conditions such as key compromise, system decommissioning, cryptoperiod expiration, and personnel offboarding and that these criteria are reviewed periodically.

3. Verify that key revocation is supported by secure, automated tooling (e.g., cloud KMS policies, API-driven key invalidation, secrets rotation frameworks) and that manual processes follow approval-based workflows.

4. Review cloud infrastructure configurations to ensure revoked keys are promptly removed from caches, metadata services, memory, and other runtime environments where keys may have been provisioned.

5. Confirm that permissions to initiate key revocation are restricted to authorized roles (e.g., cloud security operations, cryptography service owners) and are governed by access control policies and change approval processes.

6. Validate that CSP keys associated with AI workloads (e.g., encrypted model storage, inference logging, or prompt data encryption) are revoked according to organizational policies and that dependencies in AI pipelines are updated accordingly.

7. Review logs for key revocation activities to confirm auditability, including key ID, reason for revocation, identity of the requestor, system components affected, and timestamp of revocation.

8. Confirm that downstream cloud services or tenants using the revoked key (e.g., APs, AICs) are automatically notified or updated to prevent reliance on invalid key material and that fallback behaviors are clearly defined.

9. Verify that revoked keys are archived or securely deleted according to the CSP’s cryptographic lifecycle policies, retention requirements, and legal or contractual obligations.

10. Confirm that the CSP coordinates with upstream service providers (e.g., hardware root key issuers, SaaS integrations) and downstream customers to manage shared key revocation events in a way that preserves service continuity and security.

From CCM v4.1:

1. Examine the organization procedures and confirm the existence of a key revocation process.

2. Identify a population of keys and confirm that they are captured within the key revocation process.

3. Confirm that a list of entities no longer part of the organization is maintained.

CEK-14: Key Destruction

Control Specification

Define, implement, and evaluate processes, procedures, and technical measures to securely destroy cryptographic keys when they are no longer needed, which include provisions for legal and regulatory requirements.

Auditing Guidelines for Cloud Service Providers (CSP)

1. Verify that the CSP defines, implements, and evaluates processes, procedures, and technical measures to destroy cryptographic keys stored outside a secure environment and to revoke keys stored in Hardware Security Modules (HSMs) when they are no longer needed, including those supporting tenant-specific encryption services, multi-tenant key storage, and cloud-native secrets management.

2. Verify that the CSP has a documented policy and process for the secure deletion of cryptographic keys and associated data once they are no longer needed, ensuring compliance with relevant legal, regulatory, and contractual requirements for data and key destruction.

3. Confirm that the CSP defines conditions for key destruction or revocation, including service termination, tenant offboarding, algorithm deprecation, cryptoperiod expiration, or customer request.

4. Verify that cryptographic keys stored outside secure environments (e.g., in configuration backups, unprotected volumes, ephemeral cache) are destroyed using industry-approved techniques (e.g., cryptographic erasure, zeroization), and that destruction is traceable and logged.

5. Review the CSP’s systems and platforms to confirm that ephemeral or deprecated keys are removed from memory, virtual instances, container layers, or local storage as part of shutdown or reallocation workflows.

6. Confirm that keys managed in HSMs or KMS are revoked using controlled interfaces that render the key permanently unusable and record revocation metadata (e.g., reason, timestamp, initiator).

7. Validate that CSP-managed keys used to support AI infrastructure (e.g., for encrypted prompt logs, inference cache, model backups) are destroyed or revoked when the services or storage components they protect are no longer in use.

8. Review destruction and revocation event logs to verify completeness and confirm that metadata includes the key ID, affected service, initiating entity, and destruction method.

9. Confirm that key destruction is a required step in CSP resource decommissioning procedures and is enforced through automation, infrastructure as code (IaC), or security orchestration.

10. Verify that CSP key destruction practices comply with relevant jurisdictional laws, industry standards (e.g., NIST, ISO), and contractual commitments to customers.

11. Confirm that the CSP notifies affected customers or partners (e.g., APs, AICs) when shared or customer-scoped keys are revoked or destroyed, ensuring continuity and avoiding unplanned disruption.

From CCM v4.1:

1. Confirm the existence of key destruction processes and procedures.

2. Review the access permissions for the destruction and restoration of keys and confirm that only appropriate individuals have access to these capabilities.

3. Review keys that have been destroyed and ascertain the appropriate process and procedure have been followed.

4. Establish documented criteria that determine when it is appropriate for a cryptographic key to be stored outside a secure environment.

CEK-15: Key Activation

Control Specification

Define, implement and evaluate processes, procedures and technical measures to create keys in a pre-activated state when they have been generated but not authorized for use, which include provisions for legal and regulatory requirements.

Auditing Guidelines for Cloud Service Providers (CSP)

1. Verify that the CSP defines processes, procedures, and technical measures to generate cryptographic keys in a pre-activated state, where keys are not authorized for use until explicitly approved.

2. Confirm that pre-activated keys are securely stored and logically separated from active key inventories until explicitly activated (e.g., across cloud services, infrastructure encryption platforms, or tenant-specific KMS configurations).

3. Review the CSP’s key activation approval workflow to validate that formal authorization is required before any pre-activated key is transitioned to active use.

4. Validate that key activation privileges are restricted to authorized personnel or services and that multi-party approvals or policy enforcement gates are in place where required.

5. Confirm that key activation controls are consistently enforced across all cloud infrastructure components, including KMS, HSMs, and encryption-as-a-service offerings.

6. Review logs of key activation events and ensure they capture the key ID, activation time, initiating identity, approval references, and affected systems or services.

7. Verify that legal and regulatory requirements (e.g., data protection laws, export controls, financial encryption rules) are considered and enforced in CSP key activation policies.

8. Confirm that pre-activated keys are subject to expiration, timeout, or revalidation policies if not activated within a defined period.

9. Validate that cryptographic keys supporting AI workloads (e.g., model storage encryption, inference protection, prompt handling) follow the same pre-activation controls and approval workflows as general-purpose keys.

10. Confirm that the CSP’s key activation procedures support coordination with upstream providers (e.g., hardware security module vendors) and downstream consumers (e.g., APs, AICs), especially where activation status impacts shared services or encryption chains.

From CCM v4.1:

1. Confirm the existence of processes and procedures to generate keys.

2. Confirm that the access and permissions around the key creation process is restricted to appropriate individuals.

3. Identify the key management server and the key storage database.

4. Review the key attributes and confirm that these are appropriate for the key, e.g., activation data, instance, deletion ability, rollover, etc.

5. Confirm the key activation process, e.g., manual, on creation, at a future time.

6. Review the pre-activated keys.

CEK-16: Key Suspension

Control Specification

Define, implement and evaluate processes, procedures and technical measures to monitor, review and approve key transitions from any state to/from suspension, which include provisions for legal and regulatory requirements.

Auditing Guidelines for Cloud Service Providers (CSP)

1. Verify that the CSP defines, implements, and evaluates processes, procedures, and technical measures to monitor, review, and approve cryptographic key transitions to and from suspension, including provisions for legal and regulatory requirements.

2. Confirm that the CSP defines acceptable conditions for suspending keys (e.g., incident response, access anomaly, integration failure, cryptographic violation) and includes these conditions in documented suspension procedures.

3. Review whether cryptographic key suspension and reactivation events follow a formal change control or approval workflow that ensures traceability and oversight.

4. Validate that suspended keys are logically disabled from cryptographic operations while remaining intact for potential reactivation, and are segregated from active key stores.

5. Verify that the ability to suspend or resume cryptographic keys is limited to authorized roles or systems, and that separation of duties is enforced.

6. Review whether CSP monitoring tools, logging infrastructure, or automated alerts are used to detect unauthorized or anomalous key suspension events.

7. Verify that key suspension and reactivation actions are logged and auditable, including details such as timestamp, initiating identity, affected key, reason for action, and downstream impact.

8. Confirm that CSP key suspension procedures incorporate applicable legal, contractual, and regulatory requirements (e.g., uptime guarantees, sectoral encryption mandates, or incident containment policies).

9. Validate that suspended keys related to AI workloads (e.g., inference caching, encrypted logging, model access tokens) are subject to the same suspension governance as other service-layer keys.

10. Review whether the CSP’s suspension procedures include coordination with upstream providers or downstream consumers (e.g., APs, AICs) where suspended keys may impact service continuity, encrypted data access, or shared key responsibilities.

From CCM 4.1:

1. Confirm the existence of processes and procedures to manage the transition state of keys.

2. Review the access and permissions regarding the transition state of keys and confirm that these are restricted to appropriate individuals.

3. Verify that it is possible to modify a key state and suspend/disable keys when required.

CEK-17: Key Deactivation

Control Specification

Define, implement and evaluate processes, procedures and technical measures to deactivate keys at the time of their expiration date, which include provisions for legal and regulatory requirements.

Auditing Guidelines for Cloud Service Providers (CSP)

1. Verify that the CSP defines, implements, and evaluates processes, procedures, and technical measures to deactivate cryptographic keys at the time of their expiration date, including provisions for legal and regulatory requirements (e.g., keys used in cloud infrastructure, managed storage encryption, KMS-based key provisioning).

2. Confirm that expiration metadata is defined for each cryptographic key managed by the CSP and tracked in centralized or service-specific key management systems.

3. Review whether automated expiration and deactivation mechanisms are implemented in the CSP’s key lifecycle tools (e.g., KMS, HSM, cloud-native encryption services).

4. Validate that keys approaching expiration are flagged and isolated from usage in active service pipelines or customer-facing operations.

5. Confirm that access to expired or deactivated keys is restricted through access control policies, logical isolation, or service-level enforcement mechanisms.

6. Review CSP audit trails and system logs to confirm that deactivation events are recorded with relevant metadata (e.g., key ID, expiration date, initiating system, affected services).

7. Verify that expired keys are transitioned to secure archival or destruction procedures, consistent with CSP’s data retention and cryptographic lifecycle policies.

8. Confirm that legal, regulatory, and contractual requirements (e.g., GDPR, financial recordkeeping, FIPS compliance) are incorporated into the CSP’s deactivation workflows and documentation.

9. Validate that CSP-managed keys supporting AI workloads (e.g., encrypted AI model storage, inference data, prompt logs) are subject to the same expiration and deactivation procedures.

10. Review whether the CSP coordinates deactivation timelines and notifications with upstream providers (e.g., hardware KMS vendors) and downstream entities (e.g., APs, AICs) to maintain continuity of encrypted services and avoid disruptions.

From CCM 4.1:

1. Confirm the existence of processes and procedures to deactivate keys.

2. Review the access and permissions around the key deactivation process and confirm this is restricted to appropriate individuals.

3. Review key deactivation process and configurations. Confirm that they are in line with internal and external requirements.

4. Confirm the key deactivation process e.g. manual, on expiration, at a defined future time.

CEK-18: Key Archival

Control Specification

Define, implement and evaluate processes, procedures and technical measures to manage archived keys in a secure repository requiring least privilege access, which include provisions for legal and regulatory requirements.

Auditing Guidelines for Cloud Service Providers (CSP)

1. Verify that the CSP defines processes, procedures, and technical measures to securely archive cryptographic keys that are no longer in active use but must be retained, including provisions for legal and regulatory requirements (e.g., customer BYOK, cloud-native encryption keys, and service-level key retention policies).

2. Confirm that archived keys are stored in secure key repositories (e.g., cloud KMS, HSM-backed vaults) that enforce encryption at rest and apply access control restrictions.

3. Review whether least privilege access controls are enforced for archived key repositories, with access granted only to roles with approved responsibilities related to compliance, legal, or service continuity.

4. Validate that access to archived keys is gated through approval workflows and that all access attempts are logged with metadata including requester, timestamp, and access rationale.

5. Confirm that archived keys are logically segregated from active key inventories and are not usable for encryption, decryption, or signing operations.

6. Review the CSP’s key retention policy to ensure that archived keys are stored for durations aligned with applicable legal, contractual, or industry obligations (e.g., PCI DSS, GDPR, HIPAA).

7. Verify that the CSP conducts periodic reviews of archived key inventories to assess continued retention requirements and identify candidates for destruction.

8. Confirm that technical safeguards are implemented to prevent unauthorized recovery, duplication, or reactivation of archived keys.

9. Validate that archived keys supporting AI-related functions (e.g., encrypted logs of prompts, AI model outputs, API tokens) are included in the CSP’s key archival scope and follow defined retention procedures.

10. Review whether the CSP coordinates with upstream providers (e.g., hardware KMS vendors) and downstream consumers (e.g., APs, AICs) to ensure archived key dependencies are documented, monitored, and incorporated into shared retention strategies.

From CCM v4.1:

1. Confirm the existence of a documented and valid process for key archival.

2. Verify that the key archival process implements least privilege throughout the key archival cycle.

3. Establish whether the storage medium is secure, as per internal and external requirements.

CEK-19: Key Compromise

Control Specification

Define, implement and evaluate processes, procedures and technical measures to use compromised keys to encrypt information only in controlled circumstance, and thereafter exclusively for decrypting data and never for encrypting data, which include provisions for legal and regulatory requirements.

Auditing Guidelines for Cloud Service Providers (CSP)

1. Verify that the CSP defines, implements, and evaluates processes, procedures, and technical measures for handling compromised cryptographic keys, including provisions for legal and regulatory requirements.

2. Verify that the CSP’s incident response plan includes documented steps for handling compromised keys, ensuring that the keys are restricted to decryption, securely revoked, and that they cannot be reused for encryption. Confirm that the CSP’s incident response procedures comply with relevant legal and regulatory requirements for key management in the event of a compromise.

3. Confirm that the CSP restricts use of compromised keys to decrypt-only operations under controlled circumstances (e.g., legacy storage layer decryption, cloud log retrieval), and explicitly prohibits further encryption with such keys unless formally approved.

4. Review how compromised keys are detected and flagged in cloud-native key management systems (e.g., KMS, HSM) or related infrastructure.

5. Validate that compromised keys are logically segregated from active key inventories and cannot be used in cloud service encryption workflows.

6. Confirm that access to compromised keys is restricted to authorized cloud security or incident response teams, with access governed by elevated approvals and role-based controls.

7. Review audit logs and monitoring tools to ensure all access and usage of compromised keys is tracked and includes metadata such as reason for access, user identity, and affected systems.

8. Verify that decrypt-only operations using compromised keys are documented and retained for audit purposes, including justification and linkage to security event records.

9. Confirm that CSP practices for managing compromised keys include applicable regulatory obligations (e.g., GDPR breach response, HIPAA encryption standards, FedRAMP handling procedures).

10. Validate that AI-specific keys (e.g., encrypting model logs, prompt storage, inference results) are included in compromised key handling protocols and subject to decrypt-only restrictions when compromised.

11. Review whether the CSP coordinates with upstream providers (e.g., hardware vendors, cryptographic library maintainers) and downstream consumers (e.g., APs, AICs) to contain key compromise risks and communicate key status changes or transitions.

From CCM v4.1:

1. Examine if the organization has defined processes, procedures and technical measures for secure handling of compromised keys.

2. Review if the process for secure usage of compromised keys fulfills the organization and external business / operational continuity requirements.

3. Evaluate the significance of technical and organizational measures defined and implemented for usage of compromised keys in a secure environment.

CEK-20: Key Recovery

Control Specification

Define, implement and evaluate processes, procedures and technical measures to assess the risk to operational continuity versus the risk of the keying material and the information it protects being exposed if control of the keying material is lost, which include provisions for legal and regulatory requirements.

Auditing Guidelines for Cloud Service Providers (CSP)

1. Verify that the CSP defines, implements, and evaluates processes, procedures, and technical measures to assess the tradeoff between operational continuity and the risk of key exposure in the event of keying material loss, including provisions for legal and regulatory requirements.

2. Confirm that the CSP conducts periodic risk assessments that evaluate key recovery scenarios across services (e.g., KMS, HSM, encrypted storage, model logs) and considers the impact of recovery failure or compromise on cloud-based encryption and AI workloads.

3. Review whether the CSP classifies keys by service function (e.g., storage encryption, database access, service tokens, model encryption) and includes all critical key types in recovery planning.

4. Validate that CSP recovery procedures include secure backups of keying material, protected with encryption, access controls, and mechanisms to prevent unauthorized access or misuse.

5. Confirm that key recovery processes are tested regularly in cloud environments (e.g., zonal failover, backup restore, automated KMS validation) to verify resilience without exposing sensitive data.

6. Review whether recovery actions require multi-party approvals, secure workflows, and documented justification (e.g., split knowledge, quorum-based authorization, break-glass access).

7. Verify that systems supporting key recovery operations are protected by strict access controls, least privilege enforcement, and tamper-evident logging.

8. Confirm that CSP key recovery considerations are integrated into enterprise risk management, service continuity planning, and compliance frameworks (e.g., ISO 27001, SOC 2, GDPR).

9. Validate that keys supporting AI-related functions (e.g., prompt encryption, inference data protection, model signing) are included in recovery strategies and are assessed for post-recovery data integrity risk.

10. Review whether the CSP coordinates with upstream technology providers (e.g., cryptographic library vendors, HSM manufacturers) and downstream consumers (e.g., APs, AICs) to define shared responsibilities, notify of key recovery events, and maintain cryptographic trust continuity.

From CCM v4.1:

1. Examine if the organization has defined processes and procedures for handling the operational risk of compromised keys.

2. Determine if the key recovery process fulfills the organization and external business / operational continuity requirements.

3. Evaluate the significance of technical and organizational measures as per the key management lifecycle.

CEK-21: Key Inventory Management

Control Specification

Define, implement and evaluate processes, procedures and technical measures in order for the key management system to track and report all cryptographic materials and changes in status, which include provisions for legal and regulatory requirements.

Auditing Guidelines for Cloud Service Providers (CSP)

1. Verify that the CSP defines, implements, and evaluates processes, procedures, and technical measures to ensure the key management system can track and report all cryptographic materials and changes in key status.

2. Confirm that the CSP’s key management system maintains a complete and up-to-date inventory of all cryptographic keys and materials in scope, including key attributes (e.g., type, status, owner, lifecycle stage, algorithm) and usage context.

3. Review whether the inventory includes all cryptographic materials used in CSP-managed services, including those supporting encryption of cloud storage, tenant environments, control planes, and AI-related infrastructure.

4. Validate that the system automatically logs changes in key status (e.g., creation, activation, revocation, suspension, compromise, destruction) with timestamps and source identifiers.

5. Confirm that access to the key inventory system is controlled through role-based access policies and that only authorized personnel can view or modify records.

6. Review archival and retention procedures for historical key metadata to ensure they meet CSP internal policy, contractual obligations, and legal or regulatory requirements.

7. Verify that keys associated with AI-enabling services (e.g., encrypted inference logs, prompt routing, or tenant-specific AI processing environments) are represented and tracked within the inventory system.

8. Confirm that the CSP employs monitoring, alerting, or anomaly detection mechanisms to identify unexpected key lifecycle events (e.g., unauthorized revocation, premature destruction).

9. Validate that periodic internal reviews or audits are performed to ensure completeness, accuracy, and consistency of the key inventory system across cloud service boundaries.

10. Review whether the CSP coordinates key inventory and lifecycle information with upstream providers (if applicable) and downstream entities (e.g., APs, AICs) where shared, inherited, or delegated key responsibilities exist.

From CCM v4.1:

1. Examine if the organization has defined the key management processes.

2. Review the processes for key lifecycle management (creation, rotation, storage, disposal) with respect to organization and external (regulatory) requirements.

3. Evaluate if the processes and procedures for change management of key management systems provide an overall traceability of lifecycle steps.

DCS: Datacenter Security

DCS-01: Physical and Environmental Security Policy and Procedures

Control Specification

Establish, document, approve, communicate, apply, evaluate and maintain policies and procedures for physical and environmental security. Review and update the policies and procedures at least annually, or upon significant changes.

Auditing Guidelines for Cloud Service Providers (CSP)

1. Verify that the CSP maintains comprehensive physical and environmental security policies covering all data centers supporting AI workloads.

2. Verify that evidence demonstrates management approval of these policies, consistent implementation across facilities, and regular policy review.

3. Verify that third‑party audit reports or internal assessments exist and validate the effectiveness of the CSP’s physical security controls, at least annually or upon significant changes.

From CCM 4.1: 1.Examine that physical and environmental security policies and procedures are formally established to address organizational risks, regulatory requirements, and operational needs. 2.Verify that all policies and procedures are clearly documented, and accessible to authorized personnel. 3.Verify that the policies and procedures are reviewed and approved by appropriate individuals. 4.Examine that the policies and procedures are effectively communicated to relevant stakeholders. 5.Evaluate that the policies and procedures are consistently applied across all relevant areas and operations. 6.Examine that the policies and procedures are reviewed and updated at least annually or upon significant changes, and that updates are communicated to all stakeholders.

DCS-02: Off-Site Equipment Disposal Policy and Procedures

Control Specification

Establish, document, approve, communicate, apply, evaluate and maintain policies and procedures for the secure disposal of equipment used outside the organization’s premises. If the equipment is not physically destroyed a data destruction procedure that renders recovery of information impossible must be applied. Review and update the policies and procedures at least annually, or upon significant changes.

Auditing Guidelines for Cloud Service Providers (CSP)

1. Examine the organization’s policy and procedures related to data destruction.

2. Determine if the policy has been approved, communicated, and reviewed.

3. Determine if a policy exists that addresses the secure destruction of data and for conditions when equipment is reused as opposed to when equipment is destroyed.

(The above auditing guidelines from CCM v4.1 apply here as well.).

DCS-03: Off-Site Transfer Authorization Policy and Procedures

Control Specification

Establish, document, approve, communicate, apply, evaluate and maintain policies and procedures for the relocation or transfer of hardware, software, or data/information to an offsite or alternate location. The relocation or transfer request requires the written or cryptographically verifiable authorization. Review and update the policies and procedures at least annually, or upon significant changes.

Auditing Guidelines for Cloud Service Providers (CSP)

1. Examine the organization’s policy and procedures related to relocation, transfer or retirement of assets.

2. Determine if policy has been approved, communicated, and reviewed.

3. Determine if the policy requires recorded authorisation of movements.

(The above auditing guidelines from CCM v4.1 apply here as well.).

DCS-04: Secure Area Policy and Procedures

Control Specification

Establish, document, approve, communicate, apply, evaluate and maintain policies and procedures for maintaining a safe and secure working environment in offices, rooms, and facilities. Review and update the policies and procedures at least annually, or upon significant changes.

Auditing Guidelines for Cloud Service Providers (CSP)

1. Examine the organization’s policy and procedures related to physical areas under the organization’s control.

2. Determine if policy has been approved, communicated, and reviewed.

(The above auditing guidelines from CCM v4.1 apply here as well.).

DCS-05: Secure Media Transportation Policy and Procedures

Control Specification

Establish, document, approve, communicate, apply, evaluate and maintain policies and procedures for the secure transportation of physical media. Review and update the policies and procedures at least annually, or upon significant changes.

Auditing Guidelines for Cloud Service Providers (CSP)

1. Examine the organization’s policy and procedures for secure transportation of physical media.

2. Determine if policy has been approved, communicated, and reviewed.

(The above auditing guidelines from CCM v4.1 apply here as well.).

DCS-06: Assets Classification

Control Specification

Classify and document the physical, and logical assets (e.g., applications) based on the organizational business risk. Review and update the assets’ classification at least annually, or upon significant changes.

Auditing Guidelines for Cloud Service Providers (CSP)

1. Examine the policy relating to defining the organization’s business risk.

2. Confirm that the physical and logical assets are being classified in accordance with defined policy and procedures.

3. Review the asset Inventory to determine if assets are cataloged and tagged according to the organization’s business risk classification criteria.

(The above auditing guidelines from CCM v4.1 apply here as well.).

DCS-07: Assets Cataloguing and Tracking

Control Specification

Catalogue and track all relevant physical and logical assets located at all of the service provider’s sites within a secured system. Review and update the catalogue at least annually, or upon significant changes.

Auditing Guidelines for Cloud Service Providers (CSP)

1. Examine the policy relating to defining asset location and disposition.

2. Examine the asset registers and determine if they are stored and accessed securely.

(The above auditing guidelines from CCM v4.1 apply here as well.).

DCS-08: Controlled Physical Access Points

Control Specification

Design and implement physical security perimeters to safeguard personnel, data, and information systems.

Auditing Guidelines for Cloud Service Providers (CSP)

1. Examine the policy relating to physical security perimeters.

2. Examine the lists of types of areas in the organization, and the classification of each.

3. Determine if there are appropriate physical security barriers and if monitoring exists between areas.

(The above auditing guidelines from CCM v4.1 apply here as well.).

DCS-09: Equipment Identification

Control Specification

Use equipment identification as a method for connection authentication.

Auditing Guidelines for Cloud Service Providers (CSP)

1. Examine the policy relating to equipment classification and identification.

2. Determine if appropriate methods are implemented.

3. Confirm the existence of a process or procedure to track and maintain a list of appropriate equipment permitted for authorized connections.

(The above auditing guidelines from CCM v4.1 apply here as well.).

DCS-10: Secure Area Authorization

Control Specification

Allow only authorized personnel access to secure areas, with all ingress and egress points restricted, documented, and monitored by physical access control mechanisms. Retain access control records on a periodic basis as deemed appropriate by the organization.

Auditing Guidelines for Cloud Service Providers (CSP)

1. Examine the policy and procedures relating to access to secure areas.

2. Determine if the policy includes ingress and egress points to service and delivery areas.

3. Determine if procedures include activities and actions against unauthorized personnel in the premises.

4. Confirm that existence, review, and retention of Access logs for secure areas are aligned with policy and procedures.

(The above auditing guidelines from CCM v4.1 apply here as well.).

DCS-11: Surveillance System

Control Specification

Implement, maintain, and operate datacenter surveillance systems at the external perimeter and at all the ingress and egress points to detect unauthorized ingress and egress attempts.

Auditing Guidelines for Cloud Service Providers (CSP)

1. Examine the policy relating to datacenter surveillance.

2. Determine if the policy includes ingress, egress and external perimeter to detect unauthorized access.

3. Determine if procedures include activities and actions against unauthorized personnel in the premises.

4. Review and determine if items identified in surveillance system logs for the premises have been actioned in accordance with policy and procedures.

5. Determine if logs are maintained and reviewed appropriately.

(The above auditing guidelines from CCM v4.1 apply here as well.).

DCS-12: Adverse Event Response Training

Control Specification

Train datacenter personnel to safely manage adverse events, including but not limited to unauthorized ingress and egress attempts.

Auditing Guidelines for Cloud Service Providers (CSP)

1. Examine the policy and procedures relating to activities and actions to perform in case of unauthorized access.

2. Examine the policy and procedures related to datacenter’s personnel training.

3. Determine if the training content is appropriate and approved by the organization.

4. Ascertain that appropriate datacenter personnel have completed all relevant training through review of training plans and records. Confirm that these have been completed in accordance with policy and procedures.

(The above auditing guidelines from CCM v4.1 apply here as well.).

DCS-13: Cabling Security

Control Specification

Define, implement and evaluate processes, procedures and technical measures that ensure a risk-based protection of power and telecommunication cables from a threat of interception, interference or damage at all facilities, offices and rooms.

Auditing Guidelines for Cloud Service Providers (CSP)

1. Examine the policy and procedures relating to cabling infrastructure.

2. Determine if risk registers are maintained for cabling (For plant and ancillary equipment).

(The above auditing guidelines from CCM v4.1 apply here as well.).

DCS-14: Environmental Systems

Control Specification

Implement and maintain data center environmental control systems that monitor, maintain and test for continual effectiveness the temperature and humidity conditions within accepted industry standards.

Auditing Guidelines for Cloud Service Providers (CSP)

1. Confirm the existence of policy and procedures relating to environmental control in the datacenter.

2. Verify that the environment control systems are documented and operational in accordance with policy and procedures.

3. Determine if testing for operational control effectiveness is conducted at regular intervals.

4. Determine if environment system logs (e.g., temperature and humidity) are generated and if related monitoring controls are maintained.

5. Confirm that the system logs are reviewed on a periodic basis and items are disposed of in accordance with policy and procedures.

(The above auditing guidelines from CCM v4.1 apply here as well.).

DCS-15: Secure Utilities

Control Specification

Secure, monitor, maintain, and test utilities services for continual effectiveness at planned intervals.

Auditing Guidelines for Cloud Service Providers (CSP)

1. Confirm the existence of the policy and procedures relating to utilities services.

2. Confirm that the control effectiveness of utilities services is conducted at periodic intervals.

3. Determine if utility services logs are maintained and reviewed periodically.

4. Determine if testing of the utilities services is included in the CSP contract with the customer.

(The above auditing guidelines from CCM v4.1 apply here as well.).

DCS-16: Equipment Location

Control Specification

Keep business-critical equipment away from locations subject to high probability for environmental risk events.

Auditing Guidelines for Cloud Service Providers (CSP)

1. Examine the policy relating to environmental risk.

2. Determine if locations are assessed and classified for probability of environmental risk.

3. Determine if business-critical equipment is identified.

(The above auditing guidelines from CCM v4.1 apply here as well.).

DCS-17: Datacenter Metrics

Control Specification

Establish, monitor and report data center security metrics to secure data center assets and services.

Auditing Guidelines for Cloud Service Providers (CSP)

1. Verify that the CSP monitors physical, environmental, and infrastructure metrics across facilities supporting AI workloads.

2. Confirm that access events, hardware failures, environmental conditions, and configuration integrity are centrally analyzed.

3. Verify that monitoring supports detection of security and availability risks.

4. Confirm that metrics are integrated into operational response and resilience programs.

From CCM v4.1:

1. Confirm that datacenter security metrics are defined.

2. Verify that metrics are continuously monitored and reviewed to detect anomalies, trends, or deviations from expected performance.

3. Verify that security metric reports are reported to stakeholders, and include actionable insights and recommendations.

DCS-18: Datacenter Operations Resilience

Control Specification

Define, implement and evaluate processes, procedures and technical measures to ensure continuous operations.

Auditing Guidelines for Cloud Service Providers (CSP)

1. Verify that the CSP implements redundancy across facilities, power, cooling, network, and compute layers supporting AI workloads.

2. Confirm that disaster recovery and failover mechanisms are implemented and tested.

3. Verify that recovery objectives are defined and monitored through operational testing.

4. Confirm that incident analysis and corrective actions are used to improve resilience controls.

From CCM v4.1:

1. Examine that business continuity and operational resilience requirements are clearly defined based on risk assessments and critical business functions.

2. Ensure that documented processes and procedures are implemented to support continuous operations.

3. Check that technical measures such as redundancy, high availability, and automated failover systems are implemented and tested regularly.

DSP: Data Security and Privacy Lifecycle Management

DSP-01: Security and Privacy Policy and Procedures

Control Specification

Establish, document, approve, communicate, apply, evaluate and maintain policies and procedures for the preparation, classification, protection and handling of data throughout its lifecycle, and according to all applicable laws and regulations, standards, and risk level. Review and update the policies and procedures at least annually, or upon significant changes.

Auditing Guidelines for Cloud Service Providers (CSP)

1. Examine the CSP’s policy and procedures related to data security and privacy.

2. Determine if a framework exists to ensure that the CSP monitors the regulatory and legislative environment for changes applicable to the CSP’s data security and privacy policy and procedures. Confirm whether the CSP has documented the roles and responsibilities that support its policy management.

3. Confirm whether the data security and privacy policy addresses the requirement that the CSP’s data is used only for authorized purposes and in compliance with legislation and regulation.

4. Examine if the security and privacy policy and procedures are reviewed and updated annually.

5. Examine documentation to determine if the function responsible for data security and privacy compliance reviews the information to determine whether the CSP complies with current legislation and regulations.

6. Determine if the CSP has a process for approving and communicating the classification, protection, preparation, and handling of data throughout its lifecycle.

7. Evaluate whether third-party security and privacy policies and procedures are considered in the CSP’s data security and privacy practices.

8. Verify that policies address the physical and logical protection of data storage systems hosting AI workloads. Verify that policies also describe how encryption, tenant isolation, and data residency controls are applied to physical and logical storage systems.

From CCM v4.1:

1. Examine the organization’s policy and procedures related to data privacy. Determine if a framework exists to ensure that the organization monitors the regulatory and legislative environment for changes applicable to the organization. Confirm whether the organization has documented the roles and responsibilities that support the management of its policy.

2. Determine whether policy and procedure content is sufficient to direct the compliant and lawful management of personal data and to address non-compliance.

3. Confirm whether policy addresses the requirement that the organization’s data is used only for authorized purposes and in compliance with legislation and regulation.

4. Examine if the policy and procedures are reviewed on an appropriate basis.

5. Examine the measure(s) that evaluate(s) compliance with the organization’s data privacy and security policy and determine if the measure(s) address(es) implementation of the policy/control requirement(s) as stipulated.

6. Examine documentation to determine if the function responsible for data privacy compliance reviews the information to determine whether the organization is compliant with current legislation and regulation.

7. Confirm that the procedure exists for follow-up on deviation to current legislation and regulations and is up to date.

DSP-02: Secure Disposal

Control Specification

Apply industry accepted methods for the secure disposal of data from storage media such that data is not recoverable by any forensic means.

Auditing Guidelines for Cloud Service Providers (CSP)

1. Examine the CSP’s procedures and technical requirements related to the secure disposal of data from storage media. Establish that this process and key controls comply with the CSP’s data privacy and security policy. Establish whether the CSP has documented the roles and responsibilities for this process.

2. Select a sample of disposal requests (if available) and assess whether they have followed the process through to completion. Confirm that all evidence was formally documented and recorded.

3. Examine measure(s) that evaluate(s) this process and determine if the measure(s) address(es) implementation of the process/control requirement(s) as stipulated.

4. Obtain and examine supporting documentation maintained as evidence of these metrics to determine if the office or individual responsible reviews the information and if identified issues were investigated and corrected. Examine related records to determine if the individual or office conducted any follow-ups on the deviations to verify they were corrected as intended.

5. Determine if the CSP has controls to evaluate third parties’ secure data disposal methods from storage media.

6. Verify that industry-accepted methods for secure data disposal are defined and implemented, ensuring data is not recoverable by any forensic means.

7. Verify that data disposal techniques include secure deletion, overwriting, and physical destruction of storage media.

8. Verify compliance with relevant data protection laws and organizational policies throughout the data disposal process.

9. Verify the effectiveness of technical measures such as certified data wiping tools and secure destruction methods.

10. Verify that disposal methods align with industry standards (e.g., NIST SP 800-88) and specify appropriate techniques for different media types, such as cryptographic erasure for solid-state drives, degaussing or physical destruction for magnetic media, and secure overwriting where applicable.

11. Review evidence of implementation, including logs, certificates of destruction, or other documentation that confirms proper disposal of decommissioned media.

12. Assess whether disposal procedures address special handling requirements for high-capacity storage systems commonly used in AI workloads.

13. Verify that contracts with any third-party disposal services include appropriate security requirements and that certificates of destruction are obtained.

14. Examine staff training records on secure disposal procedures and confirm that personnel responsible for media handling have appropriate knowledge.

From CCM v4.1:

1. Examine the organization’s procedures and technical requirements related to the secure disposal of data from storage media. Establish that this process and key controls comply with the organization’s data privacy and security policy. Establish whether the organization has documented the roles and responsibilities for this process.

2. Select a sample of disposal requests and assess whether they have followed the process through to completion. Confirm that all evidence was formally documented and recorded.

3. Examine measure(s) that evaluate(s) this process and determine if the measure(s) address(es) implementation of the process/control requirement(s) as stipulated. Reviews, tests, or audits should be completed periodically by the organization to measure the effectiveness of the implemented controls and to verify that non-compliance and opportunities for improvement are identified, evaluated for risk, reported, and corrected in a timely manner.

4. Obtain and examine supporting documentation maintained as evidence of these metrics to determine if the office or individual responsible reviews the information and if identified issues were investigated and corrected. Determine if the individual or office is able to correct issues without the need to routinely escalate the issues to the next level of management. Examine related records to determine if the individual or office conducted any follow-ups on the deviations to verify they were corrected as intended.

DSP-03: Data Inventory

Control Specification

Create and maintain a data inventory, at least for any sensitive, regulated and personal data. Review and update the inventory at least annually, or upon significant changes.

Auditing Guidelines for Cloud Service Providers (CSP)

1. Examine the CSP’s procedures and technical requirements for the population and management of its data inventory. Establish that this process and key controls comply with the CSP’s data privacy and security policy. Establish whether the CSP has documented the roles and responsibilities for this process.

2. Select a sample of entries to ensure they have been recorded correctly on the inventory. The sample must include a proportion of sensitive and personal data entries.

3. Assess whether data inventory management meets the CSP’s expectations from the defined procedures and technical requirements.

4. Examine measure(s) that evaluate(s) this process and determine if the measure(s) address(es) implementation of the process/control requirement(s) as stipulated.

5. Determine whether the CSP evaluates third-party data inventory practices and assigns each one an appropriate risk level.

6. Verify that a comprehensive data inventory is created, including all sensitive and personal data.

7. Verify that data sources, types, usage, and ownership are identified and documented.

8. Verify that the data inventory is maintained and updated regularly to reflect changes in data assets and processing activities.

9. Verify compliance with relevant data protection laws (e.g., GDPR, CCPA) and organizational policies throughout the data inventory process.

10. Review mechanisms provided to customers for identifying and locating their data within the infrastructure, such as metadata services, tagging capabilities, or data mapping tools.

11. Verify that the CSP provides customers with documentation about data storage locations, particularly for jurisdictional or compliance purposes.

From CCM v4.1:

1. Examine the organization’s procedures and technical requirements for the population and management of its data inventory. Establish that this process and key controls comply with the organization’s data privacy and security policy. Establish whether the organization has documented the roles and responsibilities for this process.

2. Select a sample of entries to ensure they have been recorded correctly on the inventory. The sample must include a proportion of sensitive and personal data entries.

3. Assess whether management of the data inventory meets the organization’s expectations.

4. Examine measure(s) that evaluate(s) this process and determine if the measure(s) address(es) implementation of the process/control requirement(s) as stipulated. Reviews, tests, or audits should be completed periodically by the organization to measure the effectiveness of the implemented controls and to verify that non-compliance and opportunities for improvement are identified, evaluated for risk, reported, and corrected in a timely manner.

5. Obtain and examine supporting documentation maintained as evidence of these metrics to determine if the office or individual responsible reviews the information and if identified issues were investigated and corrected. Determine if the individual or office is able to correct issues without the need to routinely escalate the issues to the next level of management. Examine related records to determine if the individual or office conducted any follow-ups on the deviations to verify they were corrected as intended.

DSP-04: Data Classification

Control Specification

Classify data according to its type, criticality and sensitivity level.

Auditing Guidelines for Cloud Service Providers (CSP)

1. Examine the CSP’s policy, procedures, and technical requirements for classifying data. Establish that this process and key controls comply with the CSP’s data privacy and security policy. Establish whether the CSP has documented the roles and responsibilities for this process.

2. Establish if the CSP’s data classification matrix is aligned with the CSP’s data classification requirements in terms of data type, criticality and sensitivity level.

3. Select a sample of data to confirm that each item has been classified appropriately.

4. Examine the measure(s) that evaluate this process and determine if they address the implementation of the process/control requirement(s) as stipulated. Verify that technical measures such as labeling, tagging, and access controls are used to enforce data classification.

5. Verify that data classification criteria are based on the organization’s specific needs and regulatory requirements.

6. Verify that data classification processes include regular reviews and updates to reflect data types, criticality and sensitivity levels changes.

7. Identify how the CSP evaluates third-party data classification practices and if appropriate risk levels are assigned to each.

8. Examine infrastructure mechanisms that support data classification, such as metadata services, tagging capabilities, or labeling frameworks implemented at the storage layer.

9. Verify that storage resources can be segregated based on data classification levels to enable appropriate isolation of data with different sensitivity requirements.

10. Review access control mechanisms at the infrastructure level that enforce permissions based on data classification, ensuring they’re adequately implemented and effective.

11. Assess capabilities for enforcing storage policies (e.g., encryption, retention, geographical restrictions) based on classification levels.

12. Verify that infrastructure logging and monitoring can track and report on activities related to differently classified data, particularly for highly sensitive categories.

From CCM v4.1:

1. Examine the organization’s procedures and technical requirements for classifying data. Establish that this process and key controls comply with the organization’s data privacy and security policy. Establish whether the organization has documented the roles and responsibilities for this process.

2. Establish if the organization’s data classification matrix is aligned with the organization’s data classification requirements.

3. Select a sample of data to confirm that each item has been classified appropriately.

4. Examine measure(s) that evaluate(s) this process and determine if the measure(s) address(es) implementation of the process/control requirement(s) as stipulated. Reviews, tests, or audits should be completed periodically by the organization to measure the effectiveness of the implemented controls and to verify that non-compliance and opportunities for improvement are identified, evaluated for risk, reported, and corrected in a timely manner.

5. Obtain and examine supporting documentation maintained as evidence of these metrics to determine if the office or individual responsible reviews the information and if identified issues were investigated and corrected. Determine if the individual or office is able to correct issues without the need to routinely escalate the issues to the next level of management. Examine related records to determine if the individual or office conducted any follow-ups on the deviations to verify they were corrected as intended.

DSP-05: Data Flow Documentation

Control Specification

Create data flow documentation to identify what data is processed, stored or transmitted where. Review data flow documentation at defined intervals, at least annually, and upon significant changes.

Auditing Guidelines for Cloud Service Providers (CSP)

1. Examine the CSP’s procedures and technical requirements for data flow documentation, and ensure that a review is carried out at least annually and after any change. Establish that this process and key controls comply with the CSP’s data privacy and security policy. Establish whether the CSP has documented the roles and responsibilities for this process.

2. Select a sample of documents to check that they have been completed to the correct specifications and reviewed.

3. Review whether data flow documentation includes an assessment of the accuracy, completeness, timeliness, and sustainability of the data (flow).

4. Identify if data flow documentation includes how data is processed, stored, and transmitted.

5. Verify that data flow documentation is reviewed at defined intervals, at least annually, and after any significant changes to the data processing environment.

6. Verify compliance with relevant data protection laws and organizational policies throughout the data flow documentation process.

7. Determine if the data flow documentation includes data processed, stored, or transmitted to or from third parties.

8. Verify that documentation identifies the data types that flow through different infrastructure components, including specific storage systems, network segments, and compute resources.

9. Review the documentation update process, confirming there are defined procedures for revising documentation when infrastructure changes occur, such as new components, architecture modifications, or decommissioning.

10. Assess evidence of regular documentation reviews, verifying that reviews occur at least annually and are comprehensive enough to validate accuracy and completeness.

11. Examine records of documentation updates following infrastructure changes, confirming that updates are timely and adequately reflect the modified environment.

12. Verify that infrastructure data flow documentation is accessible to relevant personnel and integrated with higher-level data flow mapping maintained by service consumers.

From CCM v4.1:

1. Examine the organization’s procedures and technical requirements for recording data flows and that a review is carried out at least annually. Establish that this process and key controls comply with the organization’s data privacy and security policy. Establish whether the organization has documented the roles and responsibilities for this process.

2. Select a sample of documents to check that they have been completed to the correct specifications and reviewed.

3. Review if data flow documentation includes assessment for accuracy, completeness, timeliness, and sustainability of data (flow).

4. Examine measure(s) that evaluate(s) this process and determine if the measure(s) address(es) implementation of the process/control requirement(s) as stipulated. Reviews, tests, or audits should be completed periodically by the organization to measure the effectiveness of the implemented controls and to verify that non-compliance and opportunities for improvement are identified, evaluated for risk, reported, and corrected in a timely manner.

5. Obtain and examine supporting documentation maintained as evidence of these metrics to determine if the office or individual responsible reviews the information and if identified issues were investigated and corrected. Determine if the individual or office is able to correct issues without the need to routinely escalate the issues to the next level of management. Examine related records to determine if the individual or office conducted any follow-ups on the deviations to verify they were corrected as intended.

DSP-06: Data Ownership and Stewardship

Control Specification

Document ownership and stewardship of all relevant documented personal and sensitive data. Perform review at least annually.

Auditing Guidelines for Cloud Service Providers (CSP)

1. Examine the CSP’s personal and sensitive data ownership and stewardship process. Determine if the documentation defines roles and responsibilities. Establish that this process and key controls comply with the organization’s data privacy and security policy. Establish whether the CSP has documented the roles and responsibilities for this process.

2. Establish that the CSP maintains a source(s) of record of data owners and stewards and the records for which they are responsible. This must include personal and sensitive data.

3. In the absence of a documented procedure, interview the control owner(s) responsible for key staff involved in the process and/or other relevant stakeholders impacted by the process/control requirement(s) and determine if the requirement(s) is/are understood. Evidence may be provided by observing individuals, systems, and/or processes associated with data management to determine if the process requirements are generally understood and implemented consistently.

4. Examine if the documentation is reviewed on an annual basis.

5. Verify that a data responsibility matrix detailing data types, associated obligations, and responsible persons or roles has been created.

6. Verify that the CSP maintains a source of record for data owners and the records for which they are responsible.

7. Determine whether third-party data ownership and stewardship are considered in the organization’s process.

8. Examine documentation distinguishing between data custody (CSP responsibility) and data ownership (customer responsibility) for storing personal and sensitive data infrastructure.

9. Verify that the CSP has defined and documented the roles and responsibilities of personnel with administrative access to infrastructure components hosting customer data.

10. Review documentation provided to customers regarding infrastructure management practices, confirming it articulates the boundaries of CSP responsibility versus customer responsibility.

11. Assess whether the CSP maintains appropriate attestations or certifications regarding infrastructure controls that support customer data stewardship obligations.

12. Verify that documentation related to infrastructure data custody is reviewed at least annually for accuracy and completeness.

From CCM v4.1:

1. Examine the organization’s data owner process and roles and responsibilities documentation. Establish that this process and key controls comply with the organization’s data privacy and security policy. Establish whether the organization has documented the roles and responsibilities for this process.

2. Establish that the organization maintains a source(s) of record of data owners and the records for which they are responsible. Establish that this must include personal data and sensitive data.

3. In the absence of a documented procedure, interview control owner(s) responsible for key staff involved in/with, and/or other relevant stakeholders impacted by the process/control requirement(s) and determine if the requirement(s) is/are understood. Evidence may be provided by observing individuals, systems and/or processes associated with data management to determine if the process requirements are generally understood and implemented consistently.

4. Select a range of entries to establish the information recorded is correct.

5. Assess whether oversight of the data ownership process meets the organization’s expectations.

6. Examine if the documentation is reviewed on an annual basis.

7. Examine measure(s) that evaluate(s) this process and determine if the measure(s) address(es) implementation of the process/control requirement(s) as stipulated. Reviews, tests, or audits should be completed periodically by the organization to measure the effectiveness of the implemented controls and to verify that non-compliance and opportunities for improvement are identified, evaluated for risk, reported, and corrected in a timely manner.

8. Obtain and examine supporting documentation maintained as evidence of these metrics to determine if the office or individual responsible reviews the information and if identified issues were investigated and corrected. Determine if the individual or office is able to correct issues without the need to routinely escalate the issues to the next level of management. Examine related records to determine if the individual or office conducted any follow-ups on the deviations to verify they were corrected as intended.

DSP-07: Data Protection by Design and Default

Control Specification

Develop systems, products, and business practices based upon a principle of security by design and industry best practices.

Auditing Guidelines for Cloud Service Providers (CSP)

1. Examine whether the CSP’s policy, standards, and procedures create a framework that fosters a culture and expectation of data protection by design and default.

2. Establish whether the CSP has documented the roles and responsibilities involved.

3. Review the CSP’s data breaches log, security incidents log, and project change failure records for examples of this requirement not being followed correctly. Further, confirm that action plans were identified and carried out.

4. Verify that security controls are embedded at every stage of the system development lifecycle.

5. Verify the effectiveness of technical measures such as secure coding practices, encryption, and access controls.

6. Verify that regular assessments and audits are conducted to evaluate the effectiveness of security measures and identify potential risks.

7. Verify that all processes, procedures, and technical measures related to security by design are thoroughly documented and regularly updated to reflect changes in industry best practices and regulations

8. Examine the CSP’s policy, standards, and procedures, and determine if third-party data protection practices are considered.

9. Examine system design documentation to verify that security requirements were incorporated during the infrastructure design phase rather than added later, with particular focus on AI-specific processing requirements.

10. Verify that the infrastructure implements a defense-in-depth strategy with multiple security layers, including network segmentation, access controls, encryption, monitoring, and physical security appropriate for AI workloads.

11. Review the secure configuration baseline for infrastructure components, confirming it aligns with industry standards (e.g., CIS benchmarks, NIST guidelines) and is implemented by default across the environment.

12. Assess the infrastructure design review process, verifying that security assessments are conducted during design phases and that findings are addressed before deployment.

13. Evaluate how security considerations for high-performance computing environments typical in AI workloads are balanced with protection requirements without compromising either.

14. Verify that infrastructure monitoring capabilities are designed to detect security events specific to AI operations, including unusual data access patterns or resource utilization.

From CCM v4.1:

1. Examine whether the organization’s policy, standards, and procedures create a framework which fosters a culture and expectation of “security through design.” Determine whether this content addresses the directive of the organization’s culture and whether practices reflect security through design.

2. Examine whether the organization’s governance framework, documents, controls, and metrics satisfy the organization and if its sub-processors comply with this requirement. Establish whether the organization has documented the roles and responsibilities involved.

3. Review the organization’s data breaches log, the security incidents log, and project change failure records for examples where this requirement was not followed correctly. Further, confirm that action plans were identified and carried out.

4. Examine the measures that evaluate this organizational requirement and determine if the measures address implementation of process and control requirements as stipulated.

5. Obtain and examine supporting documentation maintained as evidence of these metrics to determine if the office or individual responsible reviews the information and if identified issues were investigated and remediated appropriately.

DSP-08: Data Privacy by Design and Default

Control Specification

Develop systems, products, and business practices based upon a principle of privacy by design and industry best practices. Ensure that systems’ privacy settings are configured by default, according to all applicable laws and regulations.

Auditing Guidelines for Cloud Service Providers (CSP)

1. Examine whether the CSP’s policy, standards, and procedures create a framework that fosters a culture and expectation of privacy by design. Determine whether this content addresses the directive of the CSP’s culture and whether practices reflect privacy by design and industry best practices.

2. Examine whether the organization’s governance framework, documents, controls, and metrics satisfy the organization, and if its sub-processors comply with this requirement. Establish whether the CSP has documented the roles and responsibilities involved.

3. Obtain and examine supporting documentation maintained as evidence of these metrics to determine if the office or individual responsible reviews the information, and if identified issues were investigated and remediated appropriately.

4. Obtain evidence of the systems’ privacy settings and the laws and regulations that apply to the CSP. Determine if the configurations are implemented as defined by the applicable laws and regulations.

5. Verify that processes, systems, and applications used for the collection and processing (including use, disclosure, retention, transmission, and disposal) are limited to what is necessary for the identified purpose.

6. Verify that the CSP limits data collection to the minimum necessary for the identified purposes.

7. Verify that the CSP limits the data processing to what is accurate, adequate, relevant, and necessary for the identified purposes.

8. Verify that the CSP defines and documents data minimization objectives and uses mechanisms (such as de-identification) to meet those objectives.

9. Verify that the CSP either deletes or renders data in a form that does not permit identification when it no longer requires access to identifiable forms of data unless there is a legal requirement or business justification to retain it in identifiable form.

10. Verify that the CSP ensures that temporary files created during data processing are deleted (e.g., erased or destroyed) following documented procedures within a specified, documented time frame.

11. Verify that the CSP does not retain data for longer than necessary for the purposes for which it was processed.

12. Verify that the CSP follows documented policies, procedures, and/or mechanisms when disposing of data.

13. Verify that the CSP subjects data (e.g., sent to another organization) over a data-transmission network to appropriate controls to ensure data reaches its intended destination.

14. Examine the CSP’s policy, standards, and procedures and determine if a culture and expectation of privacy by design for third-party providers is defined. Determine whether this content addresses the directive of the CSP’s culture and whether practices reflect privacy by design and industry best practices.

15. Examine infrastructure design documentation to verify that privacy-enabling capabilities, such as data isolation, segregation mechanisms, and privacy-preserving storage options, are incorporated into the infrastructure architecture.

16. Verify that default configurations for infrastructure components include privacy-enhancing settings such as encryption at rest, secure access controls, and logging that minimizes capture of personal data.

17. Review mechanisms provided to support data residency requirements, confirming the infrastructure enables customers to control where their data is physically stored and processed.

18. Assess how the infrastructure supports privacy compliance through capabilities such as data discovery, classification, pseudonymization, or isolation of regulated information.

19. Verify that infrastructure management interfaces and monitoring tools are designed to minimize the exposure of personal data in logs, alerts, and administrative views by default.

20. Examine how the infrastructure enables secure deletion or isolation of personal data when requested by customers or required by regulations.

From CCM v4.1:

1. Examine whether the organization’s policy, standards, processes, and controls create a framework that fosters a culture and expectation of “data privacy through design.” Determine whether this content addresses the directive of the organization’s culture and if practices reflect data privacy through design.

2. Examine whether the organization’s governance framework, documents, controls, and metrics satisfy the organization and whether its sub-processors comply with this requirement. Establish whether the organization has documented the roles and responsibilities involved.

3. Review the organization’s data breaches log, the security incidents log, and project change failure records for examples where this requirement was not followed correctly. Further, confirm that action plans were identified and carried out appropriately.

DSP-09: Data Protection Impact Assessment

Control Specification

Conduct a Data Protection Impact Assessment (DPIA) to evaluate the origin, nature, particularity and severity of the risks upon the processing of personal data, according to any applicable laws, regulations and industry best practices.

Auditing Guidelines for Cloud Service Providers (CSP)

1. Examine procedures related to DPIA risk assessment and determine whether, once a requirement has been established, the CSP identifies and grades the associated risks, reports, and prioritizes the remediation of risks and non-compliance activities.

2. Examine whether the DPIA process and templates align with the CSP’s risk methodology and taxonomy.

3. Determine if the risks’ origin, nature, particularity, and severity are evaluated according to the applicable laws, regulations, and industry best practices for the CSP.

4. Establish whether the CSP has documented the roles and responsibilities for this process.

5. Select a sample of DPIAs and examine evidence to confirm that each assessment was performed to identify associated risks. Further, verify that any action plans were determined and carried out appropriately. Confirm that all relevant evidence was formally documented.

6. Verify that AI systems used in PII processing are included in the DPIA evaluation process.

7. Verify identification and assessment of risks specific to AI systems, such as bias, transparency, and accountability.

8. Verify that the DPIA includes evaluating profiling based on AI systems’ data.

9. Verify that records inform the DPIA process for AI systems and are kept up-to-date.

10. Determine if the DPIA includes third-party providers and how identified risks are remediated.

11. Verify that the CSP has procedures to provide information regarding data storage locations, cross-border data flows, and infrastructure security controls when requested by customers conducting DPIAs.

12. Assess if the CSP offers documentation on technical measures implemented at the infrastructure level to support customers’ DPIA requirements.

13. Review whether the CSP has a process to notify customers of significant infrastructure changes that might affect existing DPIAs.

From CCM v4.1:

1. Examine procedures related to DPIA risk assessment and determine if once a requirement has been established, the organization identifies and grades the associated risks and reports and prioritizes the remediation of risks and non-compliance activities. Examine whether the DPIA process and templates align to the organization’s risk methodology and taxonomy.

2. Establish whether the organization has documented the roles and responsibilities for this process.

3. Select a sample of DPIAs and examine evidence to confirm that each assessment was performed to identify associated risks. Further, confirm that any action plans were identified and carried out appropriately. Confirm that all relevant evidence was formally documented.

DSP-10: Sensitive Data Transfer

Control Specification

Define, implement and evaluate processes, procedures and technical measures that ensure any transfer of personal or sensitive data is protected from unauthorized access and only processed within scope as permitted by the respective laws and regulations.

Auditing Guidelines for Cloud Service Providers (CSP)

1. Examine the CSP’s procedures and technical requirements for securing and legally transferring personal and sensitive data. Establish that this process and key controls comply with the CSP’s data privacy and security policy.

2. Establish whether the CSP has documented the roles and responsibilities for this process.

3. Select a range of personal and sensitive data transfers to confirm that each transfer adhered to the CSP’s policy, procedures, and controls. Confirm that all relevant evidence was formally documented.

4. Verify that data transfers are protected from unauthorized access using encryption, secure communication channels, and access controls.

5. Verify compliance with relevant data protection laws (e.g., GDPR, CCPA) and organizational policies throughout the data transfer and processing activities.

6. Verify that regular assessments and audits are conducted to evaluate the effectiveness of data transfer and processing measures and identify potential risks.

7. Verify that all processes, procedures, and technical measures related to data transfer and processing are thoroughly documented and regularly updated to reflect changes in laws and regulations.

8. Obtain a sample of the technical measures implemented by the CSP to determine if those measures adhere to the CSP’s data privacy and security policy.

9. Determine how the CSP ensures that all third-party providers protect the transfer of personal or sensitive data.

10. Verify implementation of encryption protocols (e.g., TLS 1.2+) for all network paths that transfer sensitive data.

11. Assess technical measures enforcing geographical data residency requirements, including documentation of data storage locations.

12. Review access control mechanisms for infrastructure components that handle sensitive data transfers, verifying the principle of least privilege implementation.

13. Evaluate network monitoring capabilities for detecting unauthorized sensitive data transfers.

14. Verify implementation of secure API gateways and other transfer boundary protections.

15. Assess documentation and technical implementation of data transfer logging and monitoring for compliance verification.

From CCM v4.1:

1. Examine the organization’s procedures and technical requirements for the secure and lawful transfer of personal data and sensitive data. Establish that this process and key controls comply with the organization’s data privacy and security policy.

2. Establish whether the organization has documented the roles and responsibilities for this process.

3. Select a range of personal data transfers and a range of sensitive data transfers to confirm that each transfer adhered to the organization’s policy, procedures, and controls. Confirm that all relevant evidence was formally documented.

DSP-11: Personal Data Access, Reversal, Rectification and Deletion

Control Specification

Define and implement, processes, procedures and technical measures to enable data subjects to request access to, modification, or deletion of their personal data, according to any applicable laws and regulations.

Auditing Guidelines for Cloud Service Providers (CSP)

1. Examine whether the CSP’s policy and procedures related to data privacy address the requirement that authorized users must be able to access, modify, or delete personal data, and whether it is handled according to the applicable laws and regulations.

2. Establish whether the CSP has processes to manage and respond to data access requests from data subjects and whether it has documented the roles and responsibilities for this process.

3. Select a range of data changes to confirm that only authorized users can access, modify, and delete personal data successfully. Select a sample of data access requests to establish that these were completed correctly following the CSP’s processes. Confirm that all relevant evidence was formally documented.

4. Determine if third-party providers are evaluated according to the CSP’s policy and procedures related to data privacy, and whether those providers address the requirement that authorized users can access, modify, or delete personal data.

5. Verify that data subjects are informed about their rights and the procedures to exercise them.

6. Examine documentation of infrastructure capabilities that support identifying and isolating personal data for subject access requests.

7. Verify the implementation of secure mechanisms for selective data deletion at the infrastructure level.

8. Review audit logging systems that track data access, modification, and deletion actions at the infrastructure layer.

9. Assess infrastructure data mapping that documents where personal data is stored to support comprehensive request fulfillment.

10. Verify that infrastructure-level retention controls support deletion requirements.

From CCM v4.1:

1. Examine whether the organization’s policy and procedures related to data privacy addresses the requirement that authorized users must be able to access, modify, or delete personal data. Establish whether the organization has processes in place to manage and respond to data access requests from data subjects. Establish whether the organization has documented the roles and responsibilities for this process.

2. Select a range of data changes to confirm that only authorized users are able to successfully access, modify and delete personal data. Select a sample of data access requests to establish that these were completed correctly following the organization’s processes. Confirm that all relevant evidence was formally documented.

DSP-12: Limitation of Purpose in Personal Data Processing

Control Specification

Define, implement and evaluate processes, procedures and technical measures to ensure that personal data is processed according to any applicable laws and regulations and for the purposes declared to the data subject.

Auditing Guidelines for Cloud Service Providers (CSP)

1. Examine whether the CSP’s policy and procedures related to data privacy address the requirement that data the CSP is responsible for is processed lawfully and used only for the purposes stated to data subjects.

2. Establish whether the CSP has documented the roles and responsibilities for this process.

3. Review the CSP’s data breaches and confirm that action plans were identified and carried out appropriately. Confirm that all supporting evidence was formally documented.

4. Review the CSP’s processes that inform data subjects why it requests this data and what it will be used for. Confirm that any CSP documentation (including web page content) is subject to formal periodic review for relevance and compliance with legislation and regulation.

5. Review the technical measures implemented to ensure that personal data is processed according to applicable laws and regulations.

6. Verify that the purposes for processing personal data are declared and documented to the data subject.

7. Verify the effectiveness of technical measures such as encryption, access controls, and data anonymization used during data processing.

8. Verify that all processes, procedures, and technical measures related to data processing are thoroughly documented and regularly updated to reflect changes in laws and regulations.

9. Determine if the CSP evaluates third-party providers to ensure that personal data is processed according to applicable laws and regulations and for the purposes declared to the data subject.

10. Examine infrastructure capabilities that support data segregation and isolation based on processing purposes.

11. Verify implementation of data tagging or labeling mechanisms that can associate processing purpose limitations with stored data.

12. Review access control systems to assess whether they can restrict data access based on approved processing purposes.

13. Assess audit logging capabilities that track data processing activities at the infrastructure level, including purpose identification.

14. Verify that infrastructure design facilitates the enforcement of purpose limitation controls for higher-level components.

From CCM v4.1:

1. Examine whether the organization’s policy and procedures related to data privacy address the requirement that data the organization is responsible for is processed lawfully and used only for the purposes stated to data subjects.

2. Establish whether the organization has documented the roles and responsibilities for this process.

3. Review the organization’s data breaches and confirm that action plans were identified and carried out appropriately. Confirm that all supporting evidence was formally documented.

4. Review the organization’s processes that inform data subjects why the organization requests this data and what it will be used for. Confirm that any organization documentation (including web page content) is subject to formal periodic review for relevance and compliance to legislation and regulation.

DSP-13: Personal Data Sub-processing

Control Specification

Define, implement and evaluate processes, procedures and technical measures for the transfer and sub-processing of personal data within the service supply chain, according to any applicable laws and regulations.

Auditing Guidelines for Cloud Service Providers (CSP)

1. Examine the CSP’s contractual terms, procedures, roles, responsibilities, documents, and technical measures for transferring personal data and sensitive data to subprocessors and how subprocessors are to treat this data.

2. Identify areas where contractual controls are insufficient and ensure appropriate risk mitigation is in place.

3. Establish whether the CSP has documented the roles and responsibilities for this process.

4. Select a sample of data transfers to subprocessors to establish that the controls and reporting of the subprocessors comply with the CSP’s data privacy and security policy.

5. Verify that contracts with suppliers and sub-processors include clauses that comply with applicable laws and regulations regarding the transfer and sub-processing of personal data.

6. Verify the effectiveness of technical measures such as encryption, secure communication channels, and data masking used during data transfer and sub-processing.

7. Verify that regular assessments and audits are conducted to evaluate the effectiveness of data transfer and sub-processing measures and identify potential risks.

8. Verify that all processes, procedures, and technical measures related to data transfer and sub-processing are thoroughly documented and regularly updated to reflect changes in laws and regulations.

9. Examine the CSP’s contractual requirements for subprocessor compliance, reporting, and non-compliance sanctions and the CSP’s right to audit. Establish subprocessors’ processes, controls, and metrics to comply with the organization’s requirements.

10. Review documentation demonstrating how the infrastructure supports customers in maintaining regulatory compliance for sub-processing activities.

11. Assess whether the CSP provides visibility and logging capabilities for data transfers that would enable customers to track sub-processing activities.

12. Evaluate whether the CSP has documented which regulatory frameworks (e.g., GDPR, CCPA) their infrastructure is designed to support regarding data transfers.

From CCM v4.1:

1. Examine the organization’s contractual terms, procedures, roles and responsibility documents and technical requirements for the transfer of personal data and sensitive data to sub-processors and how sub-processors are to treat this data.

2. Establish whether the organization has documented the roles and responsibilities for this process.

3. Select a sample of data transfers to sub-processors to establish that the controls and reporting the sub-processor are in place and ensure that these comply with the organization’s data privacy and security policy.

4. Examine the organization’s contractual requirements for sub-processor compliance, reporting and non-compliance sanctions, and the organization’s right to audit. Establish sub-processors’ processes, controls and metrics to comply with those of the organization.

DSP-14: Disclosure of Data Sub-processors

Control Specification

Define, implement and evaluate processes, procedures and technical measures to disclose the details of any personal or sensitive data access by sub-processors to the data owner prior to initiation of that processing.

Auditing Guidelines for Cloud Service Providers (CSP)

1. Policies, Roles and Contracts: Examine the CSP’s documented policies, procedures, and contractual requirements requiring sub-processors to disclose access to PII before processing begins; identify and address any areas where contractual controls are insufficient, and ensure appropriate risk mitigation is in place; verify that roles and responsibilities for managing disclosures and approvals are defined and documented; review contracts with sub-processors and customers to ensure they mandate equivalent privacy and security standards; and include disclosure of subcontractors, and enforce data minimization (only necessary PII shared).

2. Sample-Based Validation: Select a sample of data transfers to sub-processors and validate that disclosures were made before processing and controls and reporting comply with CSP’s policies.

3. Disclosure Records and Record-Keeping: Verify that the CSP maintains complete records of all sub-processor disclosures, including: what was disclosed, when, to whom, the authority/legal basis, and confirm that these records are maintained and auditable throughout the service lifecycle.

4. Customer Notification and Legal Requests: Confirm the CSP has documented processes to notify customers of any legally binding disclosure requests, reject non-legally binding requests unless customers consent, ensure timely notification in compliance with contractual and legal obligations, and notify customers of any changes to sub-processors that may affect PII processing.

5. Sub-processor Management and Infrastructure Transparency: Review the CSP’s documentation and disclosures regarding their infrastructure sub-processors who may access PII through provided services, Verify that agreements and communications with customers make transparent how the CSP’s infrastructure and sub-processors handle PII.

6. Customer Transparency Mechanisms: Assess whether the CSP has implemented technical capabilities (e.g., logging, monitoring, dashboards) to enable customers to track data access and flows, meet their own sub-processor disclosure obligations, and review customer-facing documentation explaining how the CSP’s infrastructure supports transparency and disclosure requirements.

From CCM v4.1:

1. Examine the organization’s contractual requirements and procedures whereby sub-processors will disclose all occasions when personal or sensitive data was accessible by sub-processors prior to initiation of that processing.

2. Establish whether the organization has documented the roles and responsibilities for this process.

3. Select a sample of data transfers to sub-processors to establish that the controls and reporting the sub-processor are in place and ensure that these comply with the organization’s data privacy and security policy.

Note: A real-life case will be rare. Should it not be possible to follow a real-life case, a theoretical case should be tested to establish that systems, processes, and controls are operating as designed and as agreed with the sub-processor.

DSP-15: Limitation of Production Data Use

Control Specification

Obtain authorization from data owners, and manage associated risk before replicating or using production data in non-production environments.

Auditing Guidelines for Cloud Service Providers (CSP)

1. Verify that infrastructure-level policies and technical safeguards are in place to control the use of production tenant data in test, dev, or benchmarking environments.

2. Verify if infrastructure users (e.g., internal teams or client teams) obtain approval before replicating production workloads or datasets in non-production environments.

3. Verify if mechanisms (e.g., data masking, encryption) are in place to anonymize and secure data during infrastructure provisioning or testing.

4. Verify if any deviations from the infrastructure provider’s standard for handling production data are documented and approved.

5. Verify if infrastructure governance procedures are periodically updated to reflect regulatory, contractual, or service-level agreement changes.

6. Verify if internal teams are trained on policies and practices for securing client or production data when testing or provisioning infrastructure services.

From CCM v4.1:

1. Examine the organization’s procedures and technical requirements related to the use of production data in non-production environments or requests to replicate production data for use in non-production environments.

2. Establish whether the organization has documented the roles and responsibilities for this process.

3. Select a sample of requests and assess whether such requests have followed the approval and secure deployment processes through to completion. Confirm that all relevant evidence was formally documented and recorded.

4. Review the organization’s data breaches for examples in which this requirement was not followed correctly. Further, confirm that any appropriate action plans were identified and carried out.

DSP-16: Data Retention and Deletion

Control Specification

Data retention, archiving and deletion is managed in accordance with business requirements, applicable laws and regulations.

Auditing Guidelines for Cloud Service Providers (CSP)

1. Verify if infrastructure-level policies define roles and responsibilities for retention, archiving, and deletion of customer data and system telemetry.

2. Verify if data types (e.g., VM snapshots, training datasets, system logs), owners, and retention timeframes are documented and comply with SLAs and regulations.

3. Verify if infrastructure logs and tenant data are archived or deleted in line with the documented retention policy.

4. Verify if supplier and subprocessor agreements include data lifecycle terms aligned with customer and legal expectations.

5. Verify if customer or internal data is purged using secure, verifiable deletion practices at the infrastructure level.

6. Verify if deletion and archiving events are logged, monitored, and retained for audit purposes.

7. Verify if access to retained system and customer data is controlled and monitored to prevent leaks or breaches.

8. Verify if data retention policies are reviewed and updated in accordance with regulatory developments and technology lifecycle changes.

9. Verify if retention policies account for AI-specific data stored or processed through the infrastructure (e.g., model checkpoints).

10. Verify if AI platform services are configured to limit unnecessary retention of customer AI data.

11. Verify if de-identification tools are available or enforced for customer data used in AI processing pipelines.

12. Verify if AI-related customer data is protected by role-based access and encryption-at-rest/in-transit policies.

13. Verify if systems include automated workflows to delete expired AI data and workloads securely.

14. Verify if infrastructure monitoring systems provide visibility into compliance with AI-related data retention policies.

From CCM v4.1:

1. Examine the organization’s procedures, technical requirements and other documentation for the retention, archiving and deletion of data.

2. Establish whether the organization has documented the roles and responsibilities for this process.

3. Establish that the organization maintains a source(s) of record of data types, owners, and retention periods. Select a range of entries to establish that the information recorded is correct.

4. Establish how the organization determines that its retention records are accurate and complete. Establish that the organization has documented its understanding of the extent of its remit in terms of its role as a supplier and the extent of its own supplier’s obligations to this requirement.

5. Confirm that the data retention process meets the organization’s requirements as detailed in policy and procedures.

DSP-17: Sensitive Data Protection

Control Specification

Define and implement, processes, procedures and technical measures to protect sensitive data throughout its lifecycle.

Auditing Guidelines for Cloud Service Providers (CSP)

1. Verify whether infrastructure policies and procedures include data privacy guidelines for managing sensitive data processed by AI workloads hosted or supported by the infrastructure.

2. Verify whether roles and responsibilities are defined for maintaining privacy and security controls across infrastructure components supporting AI systems (e.g., data storage, pipeline management).

3. Verify that sensitive data classification is integrated into service offerings; confirm isolation, access control, and encryption standards; validate compliance with customer and regulatory privacy requirements; interview technical and compliance staff; and confirm documentation is up to date.

4. Verify that the infrastructure includes mechanisms to safeguard sensitive data across its lifecycle—from data ingestion to runtime processing in AI pipelines.

5. Verify whether any infrastructure-related data privacy incidents involving hosted AI workloads were investigated, with evidence of corrective actions and customer communication.

6. Verify that risk management strategies include technical safeguards (e.g., secure compute environments, encryption at rest/in transit) to protect customer data and prevent misuse.

7. Verify that incident response plans for AI infrastructure cover customer data privacy breaches, including clear escalation, notification, and remediation workflows.

From CCM v4.1:

1. Examine whether the organization’s policy and procedures related to data privacy address the requirement to manage and protect sensitive data throughout its lifecycle.

2. Establish whether the organization has documented the roles and responsibilities for this process.

3. Select a sample of sensitive data types to establish the systems, processes, and controls operating to manage sensitive data throughout its lifecycle. Select a sample to establish the examples following the organization’s processes.

4. Review the organization’s data breaches for examples for which this requirement was not followed correctly. Further, confirm that any relevant action plans were identified and carried out. Confirm that all relevant evidence was formally documented.

DSP-18: Disclosure Notification

Control Specification

The service providers must implement and describe to service customers the procedure to manage and respond to requests for disclosure of Personal Data by Law Enforcement Authorities according to applicable laws and regulations.

Auditing Guidelines for Cloud Service Providers (CSP)

1. Verify if infrastructure-level procedures describe how law enforcement requests for data (e.g., stored models, training sets) are processed and responded to.

2. Verify if the procedure complies with privacy and security frameworks relevant to infrastructure providers (e.g., ISO 27001, SOC 2).

3. Verify if responsibilities for legal request handling and escalation are clearly assigned among technical and legal teams.

4. Verify if a secure workflow exists for reviewing, approving, and transmitting data disclosures.

5. Verify that all legal requests and related communications are formally recorded and stored securely.

6. Verify if timeframes for disclosures are monitored and enforced in accordance with local laws.

7. Verify if legal request procedures are reviewed in conjunction with evolving cloud service obligations and international laws.

8. Verify if personnel are trained on how to handle subpoenas, warrants, and national security letters specific to infrastructure services.

9. Verify if law enforcement data requests and their outcomes are logged in an auditable tracking system.

10. Verify if a defined escalation path exists for reporting deviations or improper handling of disclosure requests.

11. Verify if AI-specific disclosure scenarios are addressed (e.g., model telemetry or training logs subject to subpoena).

12. Verify if controls exist to ensure that AI-generated data is protected from unauthorized access during disclosures.

13. Verify if audit mechanisms are in place to detect policy violations or abuse during the disclosure process for AI workloads.

From CCM v4.1:

1. Examine the organization’s procedures and technical requirements related to personal data requests from law enforcement authorities.

2. Establish that processes and controls comply with the organization’s data privacy and security policy.

3. Establish whether the organization has documented the roles and responsibilities for this process.

4. Select a sample of requests and assess whether such requests have followed the approvals and secure communication processes through to completion. Confirm that all evidence was formally documented.

5. Review the organization’s data breaches for examples for which this requirement was not followed correctly. Further, confirm that relevant action plans were identified and carried out.

DSP-19: Data Location

Control Specification

Define and implement, processes, procedures and technical measures to specify and document the physical locations of data, including any locations in which data is processed or backed up.

Auditing Guidelines for Cloud Service Providers (CSP)

1. Verify that infrastructure policies and documentation cover the physical storage locations of AI workloads and associated data, and enforce ethical use standards for AI data processing and storage.

2. Verify documented roles and responsibilities related to managing AI system infrastructure, including physical storage governance.

3. Verify that policies cover jurisdictional restrictions and guidelines for data storage and processing on the infrastructure layer.

4. Verify that the organization maintains source(s) of record for all physical storage locations supporting AI workloads, with clear data lineage.

5. Verify accuracy and completeness of physical storage records as maintained and reported by infrastructure systems.

6. Verify that obligations of both the infrastructure provider and its suppliers regarding AI system storage and processing are documented.

7. Verify that AI infrastructure components used in data storage and processing meet organizational policy and ethical standards.

8. Verify procedures for continuous monitoring and auditing of AI storage systems to ensure compliance with ethical standards and regulations.

9. Verify that infrastructure risk management strategies include measures to mitigate bias and ensure transparency in AI system storage and processing.

10. Verify documented incident handling procedures for AI infrastructure-related data storage events, including reporting and remediation.

From CCM v4.1:

1. Examine the organization’s procedures, technical requirements, and other documentation to direct, manage and review the records of the organization’s data physical storage locations.

2. Establish whether the organization has documented the roles and responsibilities for this process.

3. Confirm that the organization’s policy and procedures include details of guidelines for the storage and processing of data within the designated countries/regions/zones/jurisdictions.

4. Establish that the organization maintains a source(s) of record of its physical data storage locations and is able to trace data lineage. Select a range of entries to establish that the information is recorded appropriately.

5. Confirm that the data storage records are accurate and complete as detailed in policy and procedures.

6. Establish that the organization has documented its understanding of the extent of its remit in terms of its role as a supplier and the extent of its own supplier’s obligations to this requirement.

7. Confirm that the data storage process meets the organization’s requirements as detailed in policy and procedures.

DSP-20: Data Provenance and Transparency

Control Specification

Define, implement and evaluate processes, procedures and technical measures to: 1) Document and trace data sources, and 2) Make the data source available according to legal and regulatory requirements

Auditing Guidelines for Cloud Service Providers (CSP)

1. Verify that all infrastructure-level data sources (e.g., logs, metrics, model checkpoints) are documented with source, type, and format.

2. Verify that lineage information is maintained for operational data, showing data flow from ingestion to storage or processing.

3. Verify that dictionaries or schemas exist for metadata and logs captured during AI processing.

4. Verify that provenance tracking includes infrastructure actions such as resource provisioning, access history, and pipeline changes.

5. Verify that automated systems monitor changes to infrastructure datasets and logs (e.g., audit logs, object storage access).

6. Verify that system-level controls ensure the integrity of data and metadata in transit and at rest.

7. Verify that operational processes handle data volume growth, privacy-sensitive logs, and infrastructure-specific complexities.

8. Verify that infrastructure-level data practices comply with laws and cloud service obligations (e.g., data residency, retention).

9. Verify that encryption and granular access controls are in place for all customer and operational data.

10. Verify that data cleanup and deletion are performed according to retention schedules.

11. Verify that infrastructure personnel are trained in secure data lifecycle handling and monitoring practices.

12. Verify that metadata about AI data processing and resource usage can be produced for audit or forensic purposes.

13. Verify that versioning is applied to deployment templates, pipelines, and logs associated with infrastructure-level AI workloads.

14. Verify that disclosure protocols are defined for infrastructure data and comply with legal and contractual frameworks.

DSP-21: Data Poisoning Prevention & Detection

Control Specification

Define, implement and evaluate processes, procedures and technical measures to prevent data poisoning in AI models and continuously detect such.

Auditing Guidelines for Cloud Service Providers (CSP)

1. Verify that infrastructure providers validate data sources ingested into AI training and processing pipelines to prevent malicious or poisoned data introduction.

2. Verify data quality checks are embedded in infrastructure services to detect and filter corrupted or suspicious data during AI workload execution.

3. Verify automated anomaly detection systems monitor data flows and storage for unusual patterns indicating data poisoning.

4. Verify infrastructure supports adversarial training and other resilience techniques by providing appropriate compute and tooling capabilities.

5. Verify infrastructure enforces strict access controls to prevent unauthorized dataset modifications at storage or processing layers.

6. Verify that data encryption protects AI workloads’ data at rest and in transit against unauthorized access or tampering.

7. Verify monitoring and alerting systems detect tampering or poisoning signs at the infrastructure level.

8. Verify documented incident response processes exist for infrastructure-related data poisoning threats, with clear escalation and remediation paths.

9. Verify that infrastructure personnel receive training on recognizing and responding to data poisoning risks in AI workloads.

10. Verify that infrastructure providers deploy automated tools to continuously monitor data integrity and detect anomalies across the AI data pipeline.

DSP-22: Privacy Enhancing Technologies

Control Specification

Use Privacy Enhancing Technologies for training data, informed by risk and privacy impact analysis and business use cases.

Auditing Guidelines for Cloud Service Providers (CSP)

1. Verify that infrastructure-level PETs (e.g., encrypted computation environments, secure aggregation) are implemented based on clearly defined business use cases.

2. Verify that PET infrastructure components are continuously monitored and evaluated to detect degradation or new risks.

3. Verify that PETs offered as services (e.g., secure multiparty computation platforms) meet privacy compliance standards.

4. Verify that metrics and audit reports for infrastructure-level PETs are defined and monitored for effectiveness.

5. Verify that DevOps and infrastructure teams are trained on PET deployment, updates, and security maintenance.

6. Verify that PET systems hosted in the infrastructure are kept up to date with relevant security patches.

7. Verify that PET usage logs (e.g., access to secure enclaves, computation results) are reviewed and analyzed.

8. Verify that periodic third-party penetration tests and vulnerability assessments are conducted on PET-enabled infrastructure offerings.

DSP-23: Data Integrity Check

Control Specification

Regularly validate the consistency and conformity of training, fine-tuning or augmentation data. Implement dataset versioning to ensure traceability and enforce restrictions to prevent unauthorized changes.

Auditing Guidelines for Cloud Service Providers (CSP)

1. Verify that all data sources handled by the infrastructure services are identified and traceable.

2. Verify that logging systems track all changes or updates to data processed or stored on infrastructure platforms.

3. Verify that automated integrity monitoring tools are implemented at the infrastructure layer to detect anomalies.

4. Verify that infrastructure access controls prevent unauthorized data modifications.

5. Verify that encryption is enforced for sensitive data at rest and in transit within infrastructure systems.

6. Verify that version control tracks changes to datasets and AI models managed by the infrastructure.

7. Verify that infrastructure staff are trained on data integrity best practices and system controls.

8. Verify that documented procedures address data integrity incidents occurring within infrastructure services.

DSP-24: Data Differentiation and Relevance

Control Specification

Ensure training-data differentiation and relevance to the intended use of the AI Model.

Auditing Guidelines for Cloud Service Providers (CSP)

1. Verify if the infrastructure provider complies with applicable privacy regulations and updates policies to reflect evolving AI governance and compliance standards.

2. Verify that data governance policies are adhered to within infrastructure services, including compliance with privacy regulations.

3. Verify that mechanisms exist to protect sensitive information and maintain data integrity at the infrastructure level.

4. Verify if continuous monitoring tools track the performance and integrity of AI-related data and systems hosted on the infrastructure.

GRC: Governance, Risk and Compliance

GRC-01: Governance Program Policy and Procedures

Control Specification

Establish, document, approve, communicate, apply, evaluate and maintain policies and procedures for an information governance program, which is sponsored by the leadership of the organization and related to AI systems as well. Review and update the policies and procedures at least annually, or upon significant changes.

Auditing Guidelines for Cloud Service Providers (CSP)

1. Policy Examination

   • a. Verify that the organization has a documented and approved information governance policy that applies to its AI-optimized infrastructure and services.

   • b. Confirm that the policy is aligned with organization’s responsibilities for managing customer data, model hosting, training artifacts, and related AI workloads across tenants.

   • c. Ensure the policy reflects leadership sponsorship and applies to internal organization’s operations as well as support for tenant-level AI data governance requirements.

2. Policy Assessment

   • a. Review the policy to confirm that roles and responsibilities are clearly defined for AI-related data isolation, secure provisioning, and lifecycle management in multi-tenant environments.

   • b. Assess whether the policy includes provisions for handling AI-specific data assets (e.g., training datasets, model outputs, telemetry, service metadata. and supports transparency and accountability for customer-facing services.

   • c. Verify that governance policies provide enabling features to support customer compliance needs, such as consent logging, clone detection, and transparency options, while maintaining clarity that ultimate compliance responsibility rests with the customer.

3. Evaluation and Review

   • a. Determine whether the policy and procedures are reviewed and updated at least annually, or when significant changes occur that affect AI data governance processes, infrastructure, or platform services. Confirm that these reviews explicitly cover multi-tenant identity risks (e.g., clone activity, cross-customer exposure, memory sharing, and auditability of service-to-service data flows), with results documented in governance records.

   • b. Confirm the review process includes participation from relevant stakeholders, such as platform engineering, cloud operations, compliance, and AI service teams.

From CCM v4.1:

1. Examine the policy and/or procedures related to information governance programs to determine whether the organization has developed a comprehensive strategy for information governance.

2. Examine policies and procedures for evidence of review at least annually.

GRC-02: Risk Management Program

Control Specification

Establish and maintain a formal, documented, and leadership-sponsored AI Risk Management (AIRM) program that includes policies and procedures for identification, evaluation, ownership, treatment, and acceptance of risks.

Auditing Guidelines for Cloud Service Providers (CSP)

1. Program Examination

   • a. Verify that the organization has established a formal, documented AI Risk Management (AIRM) program that is approved and sponsored by senior leadership.

   • b. Confirm the AIRM program includes documented policies and procedures for identifying, evaluating, owning, treating, and accepting risks specific to CSP-operated AI infrastructure and services.

2. Program Assessment

   • a. Review documentation to assess whether the AIRM program addresses risks related to CSP-specific responsibilities such as model training environments, data leakage prevention, shared resource security, and customer-facing AI services.

   • b. Verify that risk ownership is defined and that responsibilities are assigned to accountable roles or functions within the CSP organization.

3. Program Evaluation

   • a. Assess whether risk treatment strategies (e.g., mitigation, transfer, acceptance) are documented and reviewed regularly in response to platform changes or emerging AI risks.

   • b. Confirm that the AIRM program includes processes for updating risk registers and communicating accepted risks to stakeholders.

4. Program Implementation Validation

   • a. Examine records of AIRM program reviews (e.g., risk register updates, leadership reviews) conducted at least annually or after significant changes to AI services.

   • b. Verify that identified issues or gaps in the risk management process are tracked, remediated, and closed in a timely manner.

From CCM v4.1:

1. Examine the policy and/or procedures related to the Enterprise Risk Management (ERM) program to determine whether the organization has developed a comprehensive strategy to manage risk to organizational operations and assets, and individuals.

2. Review ERM documentation, processes, and supporting evidence to confirm if the ERM program includes provisions for cloud security and privacy risk.

3. Examine measure(s) that evaluate(s) the organization’s compliance with the risk management policy and determine if the measure(s) address(es) implementation of the policy/control requirement(s) as stipulated in the policy level.

4. Obtain and examine supporting evidence to determine if the office or individual responsible reviews the information and, if issues were identified, if they were investigated and remediated appropriately.

GRC-03: Organizational Policy Reviews

Control Specification

Review all relevant organizational policies and associated procedures at least annually or when a substantial change occurs within the organization.

Auditing Guidelines for Cloud Service Providers (CSP)

1. Policy Examination

   • a. Verify that the organization maintains a documented inventory of internal policies and associated procedures relevant to the operation, security, and governance of AI-enabled cloud services and infrastructure.

   • b. Confirm that the organization has defined which policies are considered “relevant” for AI infrastructure, model hosting, training pipelines, customer-facing AI services, and shared responsibility environments.

2. Policy Assessment

   • a. Verify that policies and procedures are reviewed at least annually, with documented version control, timestamps, and evidence of formal review and approval.

   • b. Confirm that designated policy owners (e.g., platform governance leads, compliance officers) are accountable for conducting reviews and that governance bodies (e.g., risk committees or AI oversight boards) are involved in approvals where applicable.

3. Review Process Evaluation

   • a. Determine whether the organization has established criteria for identifying substantial changes (e.g., platform upgrades, introduction of new AI services, or revised SLAs that affect customers) that may require out-of-cycle policy reviews.

   • b. Verify that the organization has a documented process to initiate policy reviews in response to such changes, and that it includes notification and escalation procedures where customer-facing impacts are expected.

4. Implementation Validation

   • a. Inspect records of the organization’s policy reviews to confirm that the annual review cycle is in place and that policies tied to AI operations (e.g., tenant isolation data handling, model serving) reflect current practices.

   • b. Examine a sample of recent substantial changes (e.g., changes to model deployment processes, updates to infrastructure automation) and validate that associated policies and procedures were reviewed and updated as a result.

From CCM:

1. Examine the policy and/or procedures related to the Enterprise Risk Management (ERM) program to determine if the organization reviews these documents at least annually or when a substantial change occurs within the organization.

2. Confirm that Policy reviews have taken place in compliance with the organization’s review requirements and that any exceptions identified are investigated and remediated.

GRC-04: Policy Exception Process

Control Specification

Establish and follow an approved exception process as mandated by the governance program whenever a deviation from an established policy occurs.

Auditing Guidelines for Cloud Service Providers (CSP)

1. Policy Examination

   • a. Verify that a formal, documented exception process exists for deviations from organization’s policies related to AI infrastructure, platform configurations, or customer-facing AI services (e.g., model hosting, API rate limits, data handling constraints).

   • b. Confirm that the exception process is incorporated into or referenced by the organization’s broader governance framework, including internal compliance programs or risk management procedures applicable to AI services.

2. Policy Assessment

   • a. Verify that the exception process includes documented approval workflows, justification requirements, expiration timelines, and conditions under which exceptions must be renewed or reviewed.

   • b. Confirm that the exception process covers deviations from organization’s internal operational policies, including scenarios such as bypassing encryption enforcement, extending AI model access beyond standard SLAs, or overriding resource usage limits.

   • c. Assess whether approved exceptions are communicated to relevant internal teams (e.g., service owners, platform compliance) and documented in a central tracking system for auditability.

3. Review Process Evaluation

   • a. Determine whether the organization has implemented controls to prevent unauthorized policy deviations (e.g., configuration checks, exception flags in orchestration systems).

   • b. Confirm that an appropriate governance body (e.g., platform risk team, service compliance board) periodically reviews approved exceptions and monitors adherence to the exception process.

4. Implementation Validation

   • a. Review a sample of approved exceptions related to CSP-operated AI infrastructure or services to validate that they meet approval, justification, and expiration requirements.

   • b. Examine recent changes to CSP-managed AI systems (e.g., infrastructure scaling for specific clients, API access changes, or emergency patches) and confirm that appropriate exceptions were documented and approved when deviations from policy occurred.

From CCM:

1. Examine the policy and/or procedures to determine if the policy exception process has been established.

2. Identify and confirm that exceptions to policies are tracked, authorized, and evidenced.

3. Confirm a review of policy exceptions takes place on a periodic basis by appropriate management.

GRC-05: Information Security Program

Control Specification

Develop and implement an Information Security Program, which includes programs for all the relevant domains of the AICM.

Auditing Guidelines for Cloud Service Providers (CSP)

1. Program Documentation and Scope: Verify that the organization maintains a formal, documented Information Security Program covering the full scope of its cloud infrastructure, platforms, and services. Where the CSP supports AI workloads (e.g., model hosting, data pipelines, inference infrastructure), confirm that the program includes or references controls aligned to relevant AICM domains (e.g., Infrastructure, Data Protection, Third-Party Risk).

2. Security Policy and Governance Assessment: Assess whether the program defines and governs key control areas relevant to secure multi-tenant cloud operations and AI workload support, such as data isolation, identity and access management, infrastructure hardening, logging and monitoring, and shared responsibility models. Confirm that clear ownership is assigned (e.g., CISO, cloud platform leads), that oversight mechanisms (e.g., security committees, governance boards) are in place, and that the program aligns with relevant security frameworks (e.g., ISO/IEC 27001, SOC 2, CSA STAR, NIST).

3. AICM Domain Coverage and Organizational Integration: Determine whether the CSP has evaluated its responsibilities under applicable AICM domains and mapped them to its policies, procedures, and controls. Confirm that implementation spans relevant business and technical units such as platform engineering, operations, compliance, support, and product security, not limited to a single function or silo.

4. Implementation and Effectiveness Validation: Review supporting documentation (e.g., internal audit reports, risk assessments, compliance reviews, or security control monitoring evidence) to validate that the Information Security Program is effectively implemented across domains relevant to AI workload hosting. Select a sample of relevant AICM domains (e.g., Infrastructure, Access Management, Service Continuity) and verify that associated program elements are in place and functioning.

From CCM:

1. Examine the policy and/or procedures related to the Information Security Program to determine whether the organization has developed and implemented a comprehensive strategy to manage Information Security across the organization.

2. Review the details of the information security program and establish if this covers the CCMv4 relevant domains.

3. Confirm that identified gaps/issues are being tracked, monitored, and remediated with appropriate escalation where required.

GRC-06: Governance Responsibility Model

Control Specification

Define and document roles and responsibilities for planning, implementing, operating, assessing, and improving governance programs.

Auditing Guidelines for Cloud Service Providers (CSP)

1. Policy Examination

   • a. Verify that the organization has documented roles and responsibilities for governing the secure provisioning and operation of AI services provided to customers, including infrastructure, platform, and support layers.

   • b. Confirm that responsibilities span the governance lifecycle—planning, implementation, operation, assessment, and continuous improvement—as they relate to delivering secure and compliant AI services.

2. Policy Assessment

   • a. Assess whether governance roles clearly define accountability for service security, incident response, customer support, and shared responsibility boundaries.

   • b. Confirm that governance responsibilities account for multi-tenant risks, service-level obligations, and contractual responsibilities to customers using hosted AI solutions.

3. Program Evaluation

   • a. Determine whether governance responsibilities are embedded in service delivery processes such as security reviews, change control, and customer onboarding.

   • b. Verify that governance roles are tied to oversight forums (e.g., security councils, compliance teams) that monitor service-level performance, audit readiness, and continuous improvement.

   • c. Confirm that governance responsibilities explicitly address multi-tenant identity protections, with roles accountable for preventing cross-customer exposure of identity data or model outputs.

4. Implementation Validation

   • a. Review documentation such as governance charters, audit logs, operational dashboards, or internal/external assurance reports to confirm governance responsibilities are fulfilled.

   • b. Select a governance function (e.g., customer data isolation, AI model deployment support, shared responsibility guidance) and confirm the responsible role is fulfilling duties as defined in policy.

From CCM:

1. Confirm the organization has established a governance framework which details roles, responsibilities, and accountability.

2. Evidence that governance meetings are reported and documented appropriately.

3. Confirm that individuals/groups responsible for governance are tracking and monitoring progress against the governance program.

GRC-07: Information System Regulatory Mapping

Control Specification

Identify and document all relevant standards, regulations, legal/contractual, and statutory requirements, which are applicable to your organization. Review at least annually, or upon significant changes.

Auditing Guidelines for Cloud Service Providers (CSP)

1. Policy Examination

   • a. Verify that the organization maintains a documented inventory of applicable standards, regulations, legal obligations, and contractual commitments relevant to the provision of cloud-based AI services.

   • b. Confirm that the organization considers various sources when compiling its inventory (e.g., global privacy laws, data residency requirements, cloud service agreements, customer-specific contractual terms, and industry frameworks).

2. Policy Assessment

   • a. Assess whether the inventory is reviewed and updated at least annually or when significant business or regulatory changes occur, and that ownership for maintaining the inventory is clearly assigned (e.g., compliance, legal, or regulatory affairs).

   • b. Confirm that the documented requirements reflect the organization’s AI service offerings, regions of operation, and customer base, including sector-specific mandates (e.g., financial services, healthcare).

3. Program Evaluation

   • a. Determine whether regulatory and contractual requirements are integrated into organization’s service design, operational controls, and customer-facing policies (e.g., data transfer safeguards, audit support provisions, breach notification protocols).

   • b. Confirm that relevant governance stakeholders (e.g., compliance, engineering, customer success) reference the requirements inventory in risk assessments, contract negotiations, or platform configuration decisions.

4. Implementation Validation

   • a. Review records such as compliance mapping matrices, internal control assessments, and policy update logs to confirm that documented requirements are reflected in operational processes.

   • b. Select a sample of obligations (e.g., GDPR data processing, cross-border transfer clauses) and verify that documentation or audit trails show these were incorporated into the organization’s service delivery and oversight.

From CCM v4.1:

1. Confirm that policy and procedures include provisions to identify and document all relevant standards, regulations, legal/contractual, and statutory requirements.

2. Establish that the organization maintains an inventory of CCM controls and relevant regulatory information is mapped across to the CCM inventory.

3. Identify and examine any metrics and supporting evidence to provide assurance that the information system regulatory mapping is reviewed on a periodic basis, and that any gaps in the mapping are appropriately actioned.

GRC-08: Special Interest Groups

Control Specification

Establish and maintain contact with related special interest groups and other relevant entities in line with business context.

Auditing Guidelines for Cloud Service Providers (CSP)

1. Policy Examination: Verify that the organization has a documented strategy, policy, or guideline encouraging participation in external special interest groups related to cloud infrastructure, AI platform governance, multi-tenant security, compliance frameworks, or responsible AI deployment at scale. Confirm that the organization has articulated the purpose of external engagement (e.g., tracking regulatory developments, contributing to cloud/AI standards, addressing emerging risks, promoting transparency in shared responsibility models).

2. Policy Assessment: Assess whether the identified external groups are relevant to the organization’s operations, including cloud compliance forums, international standards bodies, infrastructure-focused AI alliances, and regulatory cloud working groups. Verify that roles responsible for external engagement (e.g., cloud governance, compliance, public policy, platform risk) are formally documented and aligned to the organization’s governance structure.

3. Program Evaluation: Determine whether the organization has a structured process to identify, evaluate, and prioritize participation in external groups based on relevance to regulatory, security, and AI infrastructure concerns. Confirm that information gained from external engagement is shared internally with appropriate stakeholders (e.g., engineering, compliance, legal, client-facing teams) and influences the organization’s policies, platform development, or assurance practices.

4. Implementation Validation: Review documentation such as working group memberships, standards committee participation, public comment submissions, industry consortium involvement, or internal briefings summarizing external discussions. Select a sample of external groups (e.g., ISO/IEC JTC 1/SC 42, EUCS, Open Compute Project, CSA AI/Cloud working groups) and verify that engagement supports the organization’s AI/cloud governance objectives and shared responsibility obligations.

From CCM:

1. Examine the organization’s policy and procedures related to contact with cloud-related special interest groups to determine if membership is required and actively maintained.

2. Identify relevant individuals responsible for contacting cloud-related special interest groups and determine if the policy requirements stipulated in the policy level have been implemented.

GRC-09: Acceptable Use of the AI Service

Control Specification

Define, document and enforce policies and procedures on the acceptable use of AI services offered by the organization. Ensure effectiveness by continuous risk assessments, reviews and human oversight.

Auditing Guidelines for Cloud Service Providers (CSP)

1. Examine the AI Acceptable Use Policy for adequacy, currency, and communication to relevant interested parties and users.

2. Verify that the AI Acceptable Use Policy identifies the applicable CSP-operated AI infrastructure and services users subject to these guidelines.

3. Verify that the AI Acceptable Use Policy clearly defines the acceptable and prohibited use of the CSP services, with respect to AI-enabling services, specifying what constitutes acceptable and prohibited use cases as applicable.

4. Verify, through interviews or otherwise, that the policy is communicated to CSP users, and acknowledged as applicable.

5. Examine policy for evidence of review by policy owner or committee at least annually.

GRC-10: AI Impact Assessment

Control Specification

Establish, document, and communicate to all relevant stakeholders an AI Impact Assessment process and its criteria to regularly evaluate the ethical, societal, operational, legal, and security impacts of the AI system throughout its lifecycle.

Auditing Guidelines for Cloud Service Providers (CSP)

1. Verify that an approved AI Impact assessment process exists. The process should include how the methodology/criteria evaluates AI systems on a regular basis as per company’s policy.

2. Verify that the evaluation process in integrated with the AI system lifecycle (e.g., design, development, deployment and monitoring phases).

3. Verify the evaluation criteria and scoring mechanism exists across all the dimensions such as ethical, societal, legal, operational, and security.

4. Assess how the impact assessment methodology evaluates differential impacts across various customer segments or usage patterns within the multi-tenant service environment.

5. Verify the process to identify various stakeholders (both internal and external) and how they communicate and engage stakeholders to communicate impact assessment process, evaluation procedures, impact/risk scores ,and most importantly how they collect and incorporate their feedback.

GRC-11: Bias and Fairness Assessment

Control Specification

Regularly evaluate AI systems, models, datasets & algorithms for bias and fairness to ensure compliance with ethical standards.

Auditing Guidelines for Cloud Service Providers (CSP)

1. Bias and Fairness Policy: Confirm a documented policy exists for assessing and mitigating bias in end-user applications, aligned with Responsible AI principles and relevant regulations.

2. Representative User Contexts: Ensure training and fine-tuning consider diverse user demographics, languages, and contexts relevant to the application’s global reach.

3. Fairness in Output Behavior: Verify that models are evaluated and adjusted to reduce biased or harmful outputs across different use cases and user interactions.

4. Real-Time Monitoring and Safeguards: Confirm mechanisms exist to detect, log, and respond to bias-related issues in real-time usage.

5. Transparency to Users: Ensure that limitations, fairness considerations, and usage guidelines are clearly communicated to users (e.g., through system cards, help docs).

GRC-12: Ethics Committee

Control Specification

Establish an ethics committee to review AI applications, ensuring alignment with ethical standards and organizational values.

Auditing Guidelines for Cloud Service Providers (CSP)

1. Verify that CSP has a ethics committee consists of a diverse set of stakeholders needs to be involved AI application lifecycle.

2. Verify the CSP roles and responsibilities are clearly defined and documented.

3. Verify that CSP has clear understanding of their role and have knowledge to contribute/guide towards Ethical AI Applications.

4. Verify that there established standards for decision making and approving AI applications.

GRC-13: Explainability Requirement

Control Specification

Establish, document, and communicate the degree of explainability needed for the AI Services.

Auditing Guidelines for Cloud Service Providers (CSP)

1. Verify that the CSP has clearly defined explainability requirements that align with applicable compliance, regulatory, or ethical obligations.

2. Verify that the CSP prioritizes explainability based on risk levels and use cases, ensuring alignment with customer requirements and potential consequences of decision errors.

3. Verify that the CSP maintains consistent and transparent communication with all stakeholders, including customers, integrated service providers, and internal teams, regarding explainability standards and responsibilities.

4. Verify that the CSP has a documented framework for selecting, integrating, or substituting AI components based on explainability factors outlined in its requirements.

5. Verify that the CSP ensures transparency, enabling customers to understand explainability expectations and how decisions are made across the full AI pipeline.

GRC-14: Explainability Evaluation

Control Specification

Evaluate, document, and communicate the degree of explainability of the AI Services, including possible limitations and exceptions.

Auditing Guidelines for Cloud Service Providers (CSP)

1. Verify that CSPs define explainability requirements for AI services hosted on their platforms, in alignment with regulatory and compliance expectations of customers.

2. Verify that CSPs provide tools or APIs to evaluate the explainability of AI models deployed in their environment.

3. Verify that any limitations (e.g., restrictions due to proprietary models) and exceptions (e.g., limited observability) are documented and communicated to customers.

4. Ensure that CSP service documentation includes guidance on how to assess and document the explainability level of hosted AI services.

5. Verify that any native explainability outputs are accessible and interpretable to non-technical users.

GRC-15: Human supervision

Control Specification

Establish, execute, and assess processes, procedures, and technical measures to ensure human oversight and control of the AI system in compliance with regulatory requirements and organizational risk management.

Auditing Guidelines for Cloud Service Providers (CSP)

1. Verify that the Cloud Service Provider (CSP) has defined processes, procedures, and technical measures to ensure that AI systems are designed and developed in such a way that human operators can oversee their functioning and intended performance throughout their entire lifecycle. Ensure that the processes are documented in detail, covering scope, objectives, roles and responsibilities.

2. Examine the above-mentioned processes, procedures, and technical measures to confirm their compliance with relevant regulatory requirements and industry best practices.

3. Examine whether the above-mentioned processes, procedures, and technical measures adopt a risk-based approach.

4. Confirm that the above-mentioned processes, procedures, and technical measures are concretely and appropriately implemented by responsible parties over the entire AI systems’ lifecycle (from the design and market placement to the maintenance/upgrade and decommission phases).

5. Inspect whether the above-mentioned processes, procedures, and technical measures are monitored against sets of efficacy and efficiency metrics / indicators.

6. Inspect whether the above-mentioned processes, procedures, and technical measures are periodically reviewed and updated by responsible parties.

HRS: Human Resources

HRS-01: Background Screening Policy and Procedures

Control Specification

Establish, document, approve, communicate, apply, evaluate and maintain policies and procedures for background verification of all new employees (including but not limited to remote employees, contractors, and third parties) according to local laws, regulations, ethics, and contractual constraints and proportional to the data classification to be accessed, the business requirements, and acceptable risk. Review and update the policies and procedures at least annually, or upon significant changes.

Auditing Guidelines for Cloud Service Providers (CSP)

1. Policy Documentation and Approval: Verify that the CSP has a documented, approved background verification policy covering employees, contractors, and third parties who have physical or logical access to cloud infrastructure and data centers.

2. Defined Criteria: Verify that the policy defines consistent screening criteria: criminal history, employment history, education, professional licenses, and (if relevant) credit checks.

3. Transparency and Consent: Verify the policy is clearly communicated to applicants and written consent is obtained, respecting fairness and applicable laws.

4. Use of Providers: Verify that the CSP uses reputable, legally compliant background check providers.

5. Handling Adverse Findings: Verify that the CSP defines fair processes for addressing adverse findings, allowing candidates to respond or appeal.

6. Data Privacy and Security: Verify that personal data collected through background checks is securely handled in compliance with privacy regulations.

7. Review and Update: Verify that the policy is reviewed and updated at least annually or after significant changes to legal/regulatory or operational context.

8. Evidence of Compliance: Review a representative sample of hiring records to ensure background checks were completed before granting access to infrastructure or sensitive data.

9. Customer Assurance: Review third‑party audit reports (e.g., SOC 2, ISO 27001) that include background verification controls, and confirm they are up to date and communicated to customers as evidence of compliance.

10. KPI Monitoring: Verify whether the CSP tracks metrics (e.g., turnaround time, discrepancies, compliance incidents) to improve the program.

From CCM v4.1:

1. Examine policy for adequacy, currency, communication, and effectiveness.

2. Examine the process for selection of local laws, regulations, ethics, and contractual constraints, and for review of its output.

3. Verify that the background verification required is mapped to the risks and data classification.

4. Examine the policy and procedures for evidence of review at least annually.

5. Examine Human Resources tickets upon hire which trigger background review and final confirmation from third party conducting background reviews showing it has been completed and how exceptions or failed checks have been addressed.

HRS-02: Acceptable Use of Technology Policy and Procedures

Control Specification

Establish, document, approve, communicate, apply, evaluate and maintain policies and procedures for defining allowances and conditions for the acceptable use of organizationally-owned or managed assets. Review and update the policies and procedures at least annually, or upon significant changes.

Auditing Guidelines for Cloud Service Providers (CSP)

1. Policy Establishment and Documentation: Verify that the CSP has established and documented two distinct AUPs, an internal AUP for employees and contractors, addressing acceptable and prohibited use of customer environments and data, and a published AUP for customers, defining acceptable and prohibited use of CSP services and infrastructure by tenants.

2. Policy Communication and Acknowledgement: Confirm that the internal AUP is communicated to all CSP employees and contractors, with signed acknowledgements retained. Verify that the customer‑facing AUP is published and easily accessible to all customers (e.g., through terms of service, portal links).

3. Content of the Internal AUP: Verify that the internal AUP explicitly prohibits unauthorized access to or use of customer environments, data, or resources; unauthorized changes to customer configurations or services; and disclosure of sensitive customer information. Confirm the AUP defines consequences for violations and outlines escalation and reporting procedures.

4. Content of the Customer‑Facing AUP: Verify that the customer‑facing AUP explicitly prohibits use of CSP services for illegal or prohibited activities, abuse of resources (e.g., unauthorized crypto‑mining, spamming, denial‑of‑service attacks), and launching attacks or unauthorized access attempts originating from the customer’s tenancy. Confirm the AUP clearly defines enforcement actions (e.g., suspension or termination of services for violations).

5. Monitoring and Enforcement: Verify that monitoring mechanisms are in place to detect violations of both the internal and customer‑facing AUPs. Ensure that documented procedures exist to investigate violations, notify relevant parties, and apply corrective actions.

6. Periodic Review and Maintenance: Confirm that both the internal and customer‑facing AUPs are reviewed and updated at least annually, or after significant changes to services, laws, or customer expectations. Verify that evidence of review and approval is maintained.

From CCM v4.1:

1. Examine policy for adequacy, currency, communication, and effectiveness.

2. Verify that a definition of organizationally-owned or managed assets exists, and is implemented.

3. Verify, via Interviews or otherwise, that the policy is communicated to users.

4. Examine policy and procedures for evidence of review at least annually.

HRS-03: Clean Desk Policy and Procedures

Control Specification

Establish, document, approve, communicate, apply, evaluate and maintain policies and procedures that require unattended workspaces to not have openly visible confidential data. Review and update the policies and procedures at least annually, or upon significant changes.

Auditing Guidelines for Cloud Service Providers (CSP)

1. Ensure Cloud Service Provider (CSP) has a documented policy prohibiting display of confidential cloud-related data (e.g., customer configurations, access credentials, logs, billing info) in unattended workspaces.

2. Confirm the policy is approved by cloud security, compliance, and service delivery teams, and is version-controlled.

3. Verify the policy is communicated to all relevant personnel (e.g., cloud engineers, support staff, DevOps, SREs).

4. Check enforcement through screen lock policies, session timeouts, and workspace monitoring across cloud consoles and admin tools.

5. Review incident logs for any breaches involving unattended exposure of sensitive cloud data.

6. Ensure the policy is reviewed and updated annually to reflect changes in cloud architecture, customer SLAs, or regulatory requirements (e.g., ISO 27001, SOC 2, GDPR).

From CCM v4.1:

1. Examine policy for adequacy, currency, communication, and effectiveness.

2. Verify that secure and unsecure work areas are defined and demarcated.

3. Verify that confidential data is classified appropriately, and that the classification is available at point-of-use.

4. Verify, via Interviews or otherwise, that the policy is communicated to users.

5. Examine policy and procedures for evidence of review at least annually.

HRS-04: Remote and Home Working Policy and Procedures

Control Specification

Establish, document, approve, communicate, apply, evaluate and maintain policies and procedures to protect information accessed, processed or stored at remote sites and locations. Review and update the policies and procedures at least annually, or upon significant changes.

Auditing Guidelines for Cloud Service Providers (CSP)

1. Verify the CSP’s remote work policy for its own employees requires the use of hardened, company-managed devices and secure, authenticated connections for any access to the cloud infrastructure.

2. Review the CSP’s security attestations for controls related to remote administrative access.

3. Verify if the Remote and Home Working Policy and associated procedures are reviewed and updated at least annually or upon significant changes in legal or regulatory requirements, information security or operational risk, business or workforce model, technology controls, or assurance and audit expectations.

From CCM v4.1:

1. Examine policy for adequacy, currency, communication, and effectiveness.

2. Verify, via Interviews or otherwise, that remote sites and locations, especially those not under the control of the organization, are defined and demarcated.

3. Verify, via Interviews or otherwise, that the policy and procedures are communicated to users.

4. Examine policy and procedures for evidence of review or at least annually.

HRS-05: Asset returns

Control Specification

Establish and document procedures for the return of organization-owned assets by terminated employees, contractors and third parties.

Auditing Guidelines for Cloud Service Providers (CSP)

1. Verify the CSP’s employee/contractors/third parties’ offboarding process ensures the return of all corporate assets and the immediate revocation of all physical and logical access to data centers and cloud infrastructure.

2. Review audit logs to confirm that access is removed in a timely manner.

From CCM v4.1:

1. Examine policy for adequacy, currency, communication, and effectiveness.

2. Verify that a definition of organizationally-owned assets exists, and is implemented.

3. Verify that a definition of terminated employees exists, and is implemented.

4. Examine policy and procedures for evidence of review at least annually.

HRS-06: Employment Termination

Control Specification

Establish, document, and communicate to all relevant personnel the procedures outlining the roles and responsibilities concerning changes in employment.

Auditing Guidelines for Cloud Service Providers (CSP)

1. Verify the CSP’s policies for employment changes ensure that all access to the cloud provider’s physical and logical infrastructure is immediately and permanently revoked upon termination.

2. Check for integration between the HR system and IAM systems to automate access removal.

From CCM v4.1:

1. Examine policy for adequacy, currency, communication, and effectiveness.

2. Verify that organization charts are maintained and available as appropriate.

3. Verify that a definition of terminated employees exists, and is implemented.

4. Examine policy and procedures for notification of stakeholders upon changes in employment, or of roles, and the appropriate activities are triggered, i.e. access changes, asset return, etc.

HRS-07: Employment Agreement Process

Control Specification

Employees sign the employee agreement prior to being granted access to organizational information systems, resources and assets.

Auditing Guidelines for Cloud Service Providers (CSP)

1. Verify the CSP requires all employees to sign employment agreements with strict confidentiality and security obligations before being granted any level of access to the cloud provider’s systems or data centers.

2. Confirm this is a standard and audited part of their hiring process.

From CCM v4.1:

1. Verify that the organization has defined formats and templates of employment agreements.

2. Verify, if more than one Agreement is used, that they are mapped to appropriate roles and job descriptions.

3. Examine the policy and procedures that mandate the signing of such Agreement before access is granted.

HRS-08: Employment Agreement Content

Control Specification

The organization includes within the employment agreements provisions and/or terms for adherence to established information governance and security policies.

Auditing Guidelines for Cloud Service Providers (CSP)

1. Review the CSP’s employment agreement to ensure it includes stringent terms requiring adherence to the company’s security policies, customer data confidentiality obligations (including zero-trust principles), and privacy regulations.

2. Confirm these terms are a condition of employment.

From CCM v4.1:

1. Verify that the organization has defined formats and templates of Employment Agreements.

2. Verify that the Agreements include references to the organization’s Information Security Management System (ISMS), and that they mandate compliance.

HRS-09: Personnel Roles and Responsibilities

Control Specification

Establish, document and communicate roles and responsibilities of employees, as they relate to information assets’ security and privacy.

Auditing Guidelines for Cloud Service Providers (CSP)

1. Verify the CSP’s operational and security policies document the roles and responsibilities for all personnel involved in managing the cloud infrastructure.

2. Review the CSP’s public-facing Shared Responsibility Model documentation to see how they communicate their roles to customers.

From CCM v4.1:

1. Verify that organization charts are maintained and available as appropriate.

2. Verify that the Role or Job Descriptions refer to the appropriate ISMS requirements.

3. Verify, by Interviews or otherwise, that employees and stakeholders are aware of the roles or job descriptions, and that these are reviewed.

HRS-10: Non-Disclosure Agreements

Control Specification

Identify, document, and review, at planned intervals, requirements for non-disclosure/confidentiality agreements reflecting the organization’s needs for the protection of data and operational details.

Auditing Guidelines for Cloud Service Providers (CSP)

1. Evaluate whether the Cloud Service Provider has clearly defined and documented its non-disclosure and confidentiality requirements, with specific focus on protecting hosted data, virtual infrastructure, and customer workloads; ensuring confidentiality of customer information, metadata, and service usage patterns; and controlling third-party access, including subcontractors, integrations, and managed services, through contractual and technical safeguards.

2. Confirm that these non-disclosure and confidentiality agreements are reviewed at scheduled intervals, ensuring they comply with internal policies and applicable legal/regulatory standards; adapt to evolving technologies, threat landscapes, and service offerings; and undergo timely updates and formal re-approval as needed.

From CCM v4.1:

1. Examine if the organization has identified its requirements for non-disclosure and confidentiality.

2. Determine the planned interval for review.

3. Verify that the requirements are reviewed at such planned intervals.

HRS-11: Security Awareness Training

Control Specification

Establish, document, approve, communicate, apply, evaluate and maintain a security awareness training program for all employees of the organization and provide regular training updates.

Auditing Guidelines for Cloud Service Providers (CSP)

1. Verify the CSP provides comprehensive and role-based security awareness training to all employees, covering topics from physical datacenter security to cloud infrastructure security and customer data privacy obligations.

2. Review the CSP’s training curriculum and completion metrics.

From CCM v4.1:

1. Examine the security awareness training program for adequacy, currency, communication, and effectiveness.

2. Verify, by Interviews or otherwise, that the training program has been implemented.

3. Verify that the scope of the training program extends to all employees.

4. Examine policy and procedures for evidence of review.

HRS-12: Personal and Sensitive Data Awareness and Training

Control Specification

Provide employees with access to sensitive organizational and personal data with appropriate security awareness training and regular updates in organizational procedures, processes, and policies relating to their professional function relative to the organization.

Auditing Guidelines for Cloud Service Providers (CSP)

1. Confirm that personnel with access to sensitive cloud infrastructure or AI workloads (e.g., model hosting environments, customer data, orchestration logs) receive security training, for example, cloud engineers managing AI model deployment must complete secure access and infrastructure hardening training.

2. Check for documented training policies and access-role mappings. For example, requiring platform administrators and DevOps engineers to complete annual cloud security certifications before accessing production systems.

3. Verify that training is completed and regularly updated to reflect evolving cloud and AI risks. For example, it may include topics like multi-tenant isolation, prompt leakage in hosted models, and secure API gateway configurations.

4. Ensure training is tailored to specific roles (e.g., cloud engineers, site reliability engineers, AI platform operators). For example, SREs receiving incident response training, while AI platform teams focus on secure model lifecycle management.

5. Interview staff to confirm awareness of responsibilities and recent updates. For example, ask a cloud operator how they manage access to model logs and whether they are aware of the latest infrastructure patching policy.

6. Review how updates are communicated, such as through internal security bulletins, DevOps briefings, or monthly cloud governance newsletters that highlight changes in cloud security practices and AI hosting protocols.

From CCM v4.1:

1. Examine the security awareness training program for adequacy, currency, communication, and effectiveness.

2. Verify that a definition of sensitive organizational and personal data exists, and is implemented.

3. Verify, by Interviews or otherwise, that the training program has been implemented.

4. Verify that the scope of the training program extends to all employees with access to such data.

5. Examine policy and procedures for evidence of review.

HRS-13: Compliance User Responsibility

Control Specification

Make employees aware of their roles and responsibilities for maintaining awareness and compliance with established policies and procedures and applicable legal, statutory, or regulatory compliance obligations.

Auditing Guidelines for Cloud Service Providers (CSP)

1. Review how the Cloud Service Provider (CSP) identifies and updates applicable AI-related legal, statutory, and regulatory obligations (e.g., ISO 42001, EU AI Act, GDPR, U.S. state-level AI laws).

2. Collect evidence of documented processes, legal/compliance reviews, and involvement of relevant stakeholders (e.g., cloud governance, legal, risk teams).

3. Interview staff (e.g., cloud engineers, AI platform managers) to confirm awareness of their responsibilities under these obligations.

4. Check for role-specific training, signed acknowledgments, and ongoing compliance communications.

From CCM v4.1:

1. Examine the process for selection of applicable legal, statutory, or regulatory compliance obligations, and for review of its output.

2. Verify, by Interviews or otherwise, that employees are aware of their roles and responsibilities with respect to such obligations.

HRS-14: AI Competency Training

Control Specification

Establish, document, approve, communicate, apply, evaluate and maintain policies and procedures defining the AI training program for all relevant personnel of the organization based on their roles and provide regular training updates.

Auditing Guidelines for Cloud Service Providers (CSP)

1. Verify the cloud service provider has an approved AI training policy aligned with its infrastructure, platform services, and AI offerings (e.g., covering responsible use of hosted models and compute resources).

2. Verify that the training program defines role-specific paths (e.g., cloud engineers on secure AI deployment, support teams on identifying misuse, sales teams on responsible customer onboarding).

3. Ensure training is accessible and delivered through onboarding, internal portals, or team-based sessions across technical and customer-facing roles.

4. Review participation records to confirm staff receive training relevant to their responsibilities in managing and supporting AI services.

5. Evaluate effectiveness through assessments or feedback, and confirm updates are made following incidents, customer misuse, or audits.

6. Confirm training content is regularly updated to reflect new AI services, regulatory changes, or evolving customer use cases.

HRS-15: AI Acceptable Use

Control Specification

Establish, document, and communicate to all personnel the policies and procedures on the acceptable use of AI technologies within the organization.

Auditing Guidelines for Cloud Service Providers (CSP)

1. Confirm the cloud service provider has a documented AI Acceptable Use Policy (AI AUP) for AI services, approved by governance (e.g., prohibiting use of hosted models for mass surveillance or unauthorized facial recognition).

2. Ensure the AI AUP is accessible and clearly defines acceptable use of AI tools, APIs, and compute resources (e.g., restricting use of GPU instances for training models that violate laws or content policies).

3.Verify the policy is communicated through onboarding, documentation, and training (e.g., cloud ops teams trained to detect misuse, customer success teams trained to guide compliant deployments).

1. Assess enforcement mechanisms like usage monitoring and abuse detection (e.g., flagging excessive API calls or attempts to bypass safety filters, with consistent enforcement).

2. Check that the policy is regularly reviewed and updated (e.g., when launching new AI services or enabling access to more powerful foundation models).

IAM: Identity & Access Management

IAM-01: Identity and Access Management Policy and Procedures

Control Specification

Establish, document, approve, communicate, implement, apply, evaluate and maintain policies and procedures for identity and access management. Review and update the policies and procedures at least annually, or upon significant changes.

Auditing Guidelines for Cloud Service Providers (CSP)

1. Verify that IAM policies cover cloud infrastructure hosting AI components, including compute, storage, and networking.

2. Confirm the CSP enforces IAM policies for internal operators managing AI workloads or model containers.

3. Ensure policies include fine-grained access controls using IAM roles, service accounts, and conditions.

4. Validate that CSP IAM policies are reviewed periodically, with evidence of updates tied to service-level risk assessments.

5. Check compliance with regulatory IAM requirements (e.g., GDPR, FedRAMP) and alignment with cloud-native security frameworks (e.g., AWS IAM, GCP IAM).

From CCM v4.1:

1. Examine policy and/or procedures related to identity and access management to determine if policy and/or procedure content:

   • a. addresses the provisioning, modification and deprovisioning of logical access.

   • b. establishes password complexity and management requirements.

   • c. addresses authorization concept following separation of duties and least privilege.

   • d. addresses privileged access management and access reviews.

   • e. includes roles and responsibilities for provisioning, modifying and deprovisioning of logical access.

   • f. understands the delineation of identity and access management control responsibility in relation to the shared responsibility model.

2. Determine if the policy is clearly communicated and available to stakeholders.

3. Examine if policy and procedures are reviewed and updated at least annually.

IAM-02: Credentials Management Policy and Procedures

Control Specification

Establish, document, approve, communicate, implement, apply, evaluate and maintain policies and procedures for the management of authentication credentials, including passwords. Review and update the policies and procedures at least annually, or upon significant changes.

Auditing Guidelines for Cloud Service Providers (CSP)

1. Verify the Cloud Service Provider (CSP) has established, documented, approved, and communicated policies governing authentication credentials across IAM services, including passwords, tokens, certificates, and federated identities, and confirm annual or event-driven review.

2. Confirm enterprise-grade credential policies define complexity, strength, secure storage, and transmission requirements.

3. Verify MFA and conditional access mechanisms are supported and enforced for privileged administrative access to cloud infrastructure.

4. Confirm credential lifecycle management processes exist for both human and non-human identities, including key rotation, revocation, and expiration controls.

5. Verify secure handling of non-password authentication methods (e.g., API keys, certificates, CLI tokens), and clarify Shared Responsibility Model boundaries for credential management between the CSP and customers.

6. Confirm continuous monitoring, logging, and periodic evaluation of credential management controls to detect policy non-compliance or anomalous authentication behavior.

From CCM v4.1:

1. Examine policy and/or procedures related to passwords to determine if minimum password complexity requirements are defined.

2. Determine if the organization enforces minimum password complexity requirements as defined in policy.

3. Examine policy and procedures for evidence of review at least annually.

IAM-03: Identity Inventory

Control Specification

Manage, store, and regularly review the inventory of identities, and monitor their level of access.

Auditing Guidelines for Cloud Service Providers (CSP)

1. Confirm comprehensive inventory of all IAM principals including users, roles, and service accounts.

2. Validate identity tagging mechanisms (e.g., department, purpose, lifecycle) to enable filtering and analysis.

3. Ensure continuous identity discovery through automated tools or CSP-native inventory services.

4. Assess whether inventory is reconciled with billing or audit logs for accuracy validation.

5. Check controls to prevent stale or shadow identities from persisting in the cloud environment.

6. Verify that customers can export or query their identity inventories on demand.

7. Confirm CSP maintains separate inventories for infrastructure, control plane, and tenant-facing identities.

From CCM:

1. Determine if the organization has defined acceptable storage methods and locations of system identities.

2. Evaluate if the organization is consistently utilizing approved methods and locations to store system identities.

3. Evaluate if access to stored identities is managed following established processes.

IAM-04: Separation of Duties

Control Specification

Employ the separation of duties principle when implementing information system access.

Auditing Guidelines for Cloud Service Providers (CSP)

1. Verify CSP maintains strict SoD across operational, support, and privileged user functions.

2. Assess SoD controls in provisioning platforms, including admin console access restrictions.

3. Check audit trails for SoD enforcement across cloud orchestration activities.

4. Confirm CSP provides documentation and attestation of SoD controls to customers.

From CCM:

1. Determine if divisions of responsibility and separation of duties are defined and documented.

2. Determine if information system access authorizations are established to support separation of duties.

IAM-05: Least Privilege

Control Specification

Employ the least privilege principle when implementing information system access.

Auditing Guidelines for Cloud Service Providers (CSP)

1. Verify CSP’s IAM policies restrict access based on least privilege principles.

2. Assess whether shared responsibilities (e.g., managed services) still enforce minimal access for tenants.

3. Check for continuous access reviews and revocations by CSP across platform layers.

4. Confirm that elevated privileges are temporary and tightly monitored.

From CCM:

1. Examine the policy to determine the least privilege required for each role or user.

2. Evaluate the effectiveness of the implementation and review of policy.

IAM-06: Access Provisioning

Control Specification

Define and implement an identity access provisioning process which authorizes, records, and communicates access changes to data and assets.

Auditing Guidelines for Cloud Service Providers (CSP)

1. Verify CSP’s IAM systems enforce consistent provisioning across cloud tenants.

2. Assess whether provisioning controls support customer segregation and compliance needs.

3. Check that delegated access granted by CSP adheres to role definitions.

4. Confirm auditability of provisioning actions by CSP support personnel.

From CCM:

1. Examine the policy to determine the least privilege required for each role or user.

2. Evaluate the effectiveness of the implementation and review of policy.

IAM-07: Access Changes and Revocation

Control Specification

De-provision or modify identity access in a timely manner.

Auditing Guidelines for Cloud Service Providers (CSP)

1. Review CSP’s automated de-provisioning mechanisms.

2. Confirm revocation includes access to cloud APIs, consoles, and back-end storage.

3. Verify that emergency revocation (e.g., threat detection) is supported and logged.

From CCM:

1. Determine if a process is established for removing logical access when users leave the organization or when access is no longer appropriate.

2. Determine if a timeframe for access removal and access modification is defined.

3. Verify that a process is established for removing existing system access and assigning appropriate access or for modifying existing access after internal transfer or change of job functions.

4. Determine if established processes for access removal and modification, within the defined time frame, are followed in practice.

IAM-08: Access Review

Control Specification

Review and revalidate identity access for least privilege and separation of duties with a frequency that is commensurated with organizational risk tolerance and at least annually, or upon significant changes.

Auditing Guidelines for Cloud Service Providers (CSP)

1. Confirm the CSP conducts role-based access reviews for cloud infrastructure components.

2. Check reviews include both manual roles and programmatic access (e.g., service accounts).

3. Ensure mechanisms are in place to detect unused or excessive permissions.

4. Validate the CSP’s audit logs for evidence of review-driven changes.

5. Confirm periodic access reviews are included in SOC 2 or similar compliance audits.

From CCM v4.1:

1. Determine if the required frequency for review of accounts is established.

2. Determine if accounts are reviewed for compliance, including the level of access and conflicting access, following the principle of least privilege and consideration of separation of duties.

3. Determine if accounts are reviewed at the organization-defined frequency.

IAM-09: Segregation of Privileged Access Roles

Control Specification

Define, implement and evaluate processes, procedures and technical measures for the segregation of privileged access roles.

Auditing Guidelines for Cloud Service Providers (CSP)

1. Confirm role segregation exists between CSP engineers, support staff, and customers.

2. Validate that root-level access is strictly limited and logged.

3. Check for separation between infrastructure provisioning and billing operations.

4. Review CSP’s IAM policies for conflict-of-interest prevention.

5. Confirm use of break-glass procedures for emergency access with auditing.

From CCM:

1. Determine if processes, procedures, and technical measures for the separation of privileged access are defined and include requirements for separation of administrative access to data, encryption, key management and logging capabilities.

2. Evaluate if established processes, procedures, and technical measures for the separation of privileged access are implemented and followed in practice.

IAM-10: Management of Privileged Access Roles

Control Specification

Define and implement an access process to ensure privileged access roles and rights are granted for a time limited period, and implement procedures to prevent the accumulation of segregated privileged access.

Auditing Guidelines for Cloud Service Providers (CSP)

1. Confirm privileged roles (e.g., cloud admins, network architects) require multi-step approval.

2. Review credential management for privileged identities.

3. Check for controls that prevent role escalation without visibility.

4. Validate periodic audits of privilege usage and associated actions.

5. Ensure evidence exists of privilege role reviews post-incident.

From CCM:

1. Determine if an access process, that includes requirements for limiting the time period of privileged access roles and rights, is defined.

2. Determine if procedures address the prevention of culmination of segregated privileged access.

3. Evaluate if an access process, that includes requirements for limiting the time period of privileged access roles and rights, is implemented and consistently followed in practice.

4. Evaluate if procedures that address the prevention of culmination of segregated privileged access is implemented and consistently followed in practice.

IAM-11: Service Customers’ Approval for Agreed Privileged Access Roles

Control Specification

Define, implement and evaluate processes and procedures for service customers to participate, where applicable, in the granting of access for agreed, high risk (as defined by the organizational risk assessment) privileged access roles.

Auditing Guidelines for Cloud Service Providers (CSP)

1. Ensure that customer-defined roles are honored and not overridden by platform-wide roles.

2. Verify policies requiring approval workflows for infrastructure-level privileged roles.

3. Confirm logs exist for all privileged role assignment actions.

4. Validate escalation paths and emergency access controls are appropriately authorized.

5. Check role lifecycle governance is in place across cloud tenants.

From CCM v4.1:

1. Determine if processes and procedures for customers to participate, where applicable, in the granting of access for agreed, high risk (as defined by the organizational risk assessment) privileged access roles are defined, implemented and consistently followed in practice.

IAM-12: Unique Identities

Control Specification

Define, implement and evaluate processes, procedures and technical measures, that ensure identities’ activities are identifiable through uniquely associated IDs.

Auditing Guidelines for Cloud Service Providers (CSP)

1. Confirm cloud tenants and users are assigned unique identifiers across all services.

2. Ensure traceability from IAM policies to cloud resource actions.

3. Check for mechanisms that detect shared credentials or account reuse.

4. Validate logging systems associate user IDs with resource operations.

5. Confirm periodic reviews of identity lifecycle management for cloud accounts.

From CCM v4.1:

1. Determine if processes, procedures and technical measures are defined and require that users are identifiable through unique IDs or by association of individuals to the usage of user IDs.

2. Determine if the established processes, procedures and technical measures are implemented and consistently followed in practice.

IAM-13: Strong Authentication

Control Specification

Define, implement and evaluate processes, procedures and technical measures for authenticating access to systems, application and data assets, including multifactor authentication for at least privileged user and sensitive data access. Adopt digital certificates or alternatives which achieve an equivalent level of security for system identities.

Auditing Guidelines for Cloud Service Providers (CSP)

1. Verify cloud console and management APIs enforce MFA and hardware-backed credentials.

2. Confirm authentication enforcement across all IAM roles with model/data access privileges.

3. Ensure that service-to-service authentication (e.g., between AI pipeline components) uses workload identity federation or OIDC tokens.

4. Validate logging of all authentication events and support for anomaly-based detection.

5. Confirm alignment of authentication mechanisms with regulatory compliance standards (e.g., NIST SP 800-63B).

From CCM:

1. Determine if processes, procedures, and technical measures for authenticating access to systems, applications and sensitive data are defined and maintained.

2. Determine if processes, procedures, and technical measures for authenticating access to systems, applications and sensitive data include organization-defined requirements for specific use cases of multifactor authentication, digital certificates and/or alternative security measures.

3. Determine if processes, procedures, and technical measures for authenticating access to systems, applications and sensitive data are implemented and consistently followed in practice.

IAM-14: Credentials Management

Control Specification

Define, implement and evaluate processes, procedures and technical measures for the secure management of authentication credentials, including passwords.

Auditing Guidelines for Cloud Service Providers (CSP)

1. Confirm all infrastructure secrets (SSH keys, service tokens) are managed using a centralized vault.

2. Verify policy mandates encryption and strict access control for all stored passwords.

3. Validate the cloud IAM system enforces key-based access rather than passwords for APIs.

4. Ensure logs are collected for secret creation, access, and deletion events.

5. Confirm alerts are triggered on secret misuse or exposure.

From CCM v4.1:

1. Determine if processes, procedures and technical measures for the secure management of passwords are defined.

2. Determine if processes, procedures and technical measures for the secure management of passwords are implemented and consistently followed in practice.

IAM-15: Authorization Mechanisms

Control Specification

Define, implement and evaluate processes, procedures and technical measures to verify access to data and system functions is authorized.

Auditing Guidelines for Cloud Service Providers (CSP)

1. Verify IAM policies enforce least-privilege access to AI workloads and resources.

2. Confirm that access to sensitive cloud-native AI services is governed by conditional IAM policies.

3. Validate cloud authorization logs capture all access grant and denial events.

4. Ensure regular reviews of authorization rules to prevent privilege creep.

5. Confirm that misconfigured policies are automatically flagged by cloud-native analyzers.

From CCM v4.1:

1. Determine if processes, procedures and technical measures, for verification of access authorization to data and system functions, are defined.

2. Determine if processes, procedures and technical measures, for verification of access authorization to data and system functions, are implemented and consistently followed in practice.

IAM-16: Knowledge Access Control - Need to Know

Control Specification

Define policy and procedure for “need to know” access to knowledge, information and data within the organization and in the context of the AI system to be applied when regulating access to resources.

Auditing Guidelines for Cloud Service Providers (CSP)

1. Verify platform-level RBAC or ABAC policies are configured to enforce knowledge access limitations.

2. Check tenant-level isolation controls on data lake, object storage, and model registry.

3. Confirm logging and monitoring of access attempts to AI knowledge resources like datasets and features.

4. Validate cloud-native services (e.g., Vertex AI, SageMaker) restrict access to metadata and pipeline artifacts.

5. Ensure policies align with CSP customer’s “least privilege” configuration templates for AI workloads.

IAM-17: Output Modification and Special Authorization

Control Specification

When allowing model output modification of AI generated output, establish a role for this access and allow changes only by authorized identities.

Auditing Guidelines for Cloud Service Providers (CSP)

1. Ensure CSP-managed AI platforms restrict post-inference output modifications to administrative roles.

2. Verify role-specific logging of any changes to AI inference result storage or redirection.

3. Confirm support for output hashing or versioning mechanisms as part of audit requirements.

4. Validate CSP’s change control procedures cover model endpoint outputs used in production pipelines.

5. Check if customers are provided with mechanisms to lock output fields or enforce immutability where necessary.

IAM-18: Agent Access Restriction

Control Specification

Restrict agents’ access to the tools and plugins necessary for the activity or use case at hand, ensuring adherence to the principles of need-to-know and least privilege.

Auditing Guidelines for Cloud Service Providers (CSP)

1. Verify that consent and identity mapping services offered by CSPs are compliant with privacy frameworks.

2. Confirm support for federated identity systems enabling cross-platform consent synchronization.

3. Validate revocation propagation across CSP-hosted microservices or serverless architectures.

4. Ensure CSP logging infrastructure retains mappings only as long as necessary.

5. Confirm service-level agreements support customer demands for identity mapping transparency.

IPY: Interoperability & Portability

IPY-01: Interoperability and Portability Policy and Procedures

Control Specification

Establish, document, approve, communicate, apply, evaluate and maintain policies and procedures for interoperability and portability including requirements for: a. Communications between application interfaces b. Information processing interoperability c. Application development portability d. Information/Data exchange, usage, portability, integrity, and persistence Review and update the policies and procedures at least annually or upon significant changes.

Auditing Guidelines for Cloud Service Providers (CSP)

1. Verify the existence of documented policies and procedures addressing interoperability and portability ensuring it contains communications between application interfaces, information processing interoperability, application development portability.

2. Confirm that the policies and procedures have received appropriate approval from relevant authority within the CSP’s organization.

3. Examine evidence of a regular review and update cycle, ensuring the policies and procedures are evaluated and updated.

4. Verify the Application Provider’s due diligence process for ensuring that upstream providers implement controls related to interoperability and portability.

5. Verify that the policies are effectively communicated to relevant stakeholders, including internal personnel and any external partners or service customers impacted by these controls.

6. Verify that the review and update of the interoperability and portability policies and procedures occur at least annually, and that evidence of review (e.g., change logs, approvals) is retained.

From CCM v4.1:

1. Examine policy for adequacy, currency, communication, and effectiveness.

2. Examine the inventory of documentation that establishes the requirements and communication of this control.

3. Examine policy and procedures for evidence of review at least annually.

IPY-02: Application Interface Availability

Control Specification

Provide application interface(s) to service customers so that they programmatically retrieve their data to enable interoperability and portability.

Auditing Guidelines for Cloud Service Providers (CSP)

1. Verify that the CSP provides complete, up-to-date API documentation covering integration, data handling, and usage. Confirm that the CSP ensures reliable API operation through uptime monitoring, incident response procedures, and service customer notifications during disruptions.

2. Ensure that the APIs cover all necessary functionalities required by AI service customers to retrieve their data fully.

3. Verify that there are adequate security controls in place for accessing and using the APIs, including but not limited to authentication, authorization, and encryption.

4. Verify that the policy governing API availability and usage is reviewed and updated on a periodic basis by the respective owner.

From CCM v4.1:

1. Examine the list of Application Programming Interfaces (API) available to Cloud Service Consumers.

2. Determine if such list and usable documentation is made available to Cloud Service Consumers.

IPY-03: Secure Interoperability and Portability Management

Control Specification

Implement cryptographically secure network protocols for the management, import and export of data, according to industry standards.

Auditing Guidelines for Cloud Service Providers (CSP)

1. Examine the adequacy of the policy to ensure to if they contain comprehensive details regarding the implementation of cryptographically secure network protocols within the CSP environment.

2. Review that the Interoperability and Portability Policy has been updated regularly to adapt to evolving industry standards and emerging threats.

3. Review that the communication channels are adequate to communicate about the policy to all relevant parties involved.

4. Examine the mechanisms used for the monitoring and enforcement of the policy. Ensure that there are clear procedures for detecting and addressing non-compliance.

From CCM v4.1:

1. Examine the policy for the secure transmission of requests and data.

2. Inspect the requirements, with respect to any security domains defined.

3. Examine the policy that specifies protocols for transmission, with respect to standardization.

IPY-04: Data Portability Contractual Obligations

Control Specification

Agreements must include provisions specifying service customers’ access to data upon contract termination and will include: a. Data format b. Length of time the data will be stored c. Scope of the data retained and made available to the service customers d. Data deletion policy

Auditing Guidelines for Cloud Service Providers (CSP)

1. Review the contractual agreements to ensure service customers know their rights and obligations maintaining data security and availability during transitions.

2. Verify if data format specifications are specified in the contracts which ensure service customers can transfer and seamless use data with portability.

3. Examine data deletion period which ensures service customers can plan for data migration or deletion in line with regulations.

4. Verify there is an annual review in place to review data portability provisions.

From CCM v4.1:

1. Examine the standard form of contract for offboarding the Cloud Service Consumers.

2. Determine if non-standard clauses allow the Cloud Service Consumers to waive such rights.

3. Determine if there are requests for data in unsupported formats.

4. Examine the policy regarding deletion of resources no longer in the control of a client, and determine if such policy corresponds to the contractual data retention.

I&S: Infrastructure Security

I&S-01: Infrastructure and Virtualization Security Policy and Procedures

Control Specification

Establish, document, approve, communicate, apply, evaluate and maintain policies and procedures for infrastructure and virtualization security. Review and update the policies and procedures at least annually, or upon significant changes.

Auditing Guidelines for Cloud Service Providers (CSP)

1. Examine Cloud Service Providers (CSPs) policies and procedures that defines the scope, objectives, roles, and responsibilities for Cloud (e.g., storage, processing, networking, services).

2. Verify that policies and procedures are documented and approved by senior management or governing authority and update versioning.

3. Verify policies and procedure are effectively applied to the infrastructure and virtualization security operations s and evaluated continuously for operational effectiveness and compliance.

4. Verify if policies and procedures are regularly reviewed and updated to address emerging threats, vulnerabilities, and evolving business needs, ensuring clear documentation of changes and approvals exists.

From CCM v4.1:

1. Interview the team to determine if policy and procedures have been documented.

2. Evaluate the documented policy to determine if it has been approved and communicated to the relevant internal and external teams.

3. Determine if the policy has been applied to the infrastructure and virtualization security operations and if relevant procedures have been drafted.

4. Determine if the procedures are periodically evaluated and if they are maintained, up to date, and relevant.

5. Determine if policy and procedures are reviewed and updated on an annual basis. Policy may contain segregation of environments and roles, change management requirements and continuous exercising.

I&S-02: Capacity and Resource Planning

Control Specification

Plan and monitor the availability, quality, and adequate capacity of resources in order to deliver the required system performance as determined by the business.

Auditing Guidelines for Cloud Service Providers (CSP)

1. Examine the Cloud Service Provider’s business requirements for system performance are available.

2. Verify capacity plans, performance forecasts, and scaling procedures are review and approve by senior management or governance authorities.

3. Verify performance metrics regularly, proactively identify potential capacity constraints, and verify compliance with agreed-upon service levels.

4. Verify performance planning procedures regularly review, at least annually and align with changing business demands, system performance metrics, emerging technologies, and evolving threats.

From CCM v4.1:

1. Determine if the business requirements for system performance are available.

2. Determine if evidence exists that points to planning and monitoring of the availability, quality and capacity of resources.

3. Determine if evidence exists that establishes that the plan is appropriate and adequate to meet the expectations of the business requirements established in the first guideline.

I&S-03: Network Security

Control Specification

Monitor, encrypt and restrict communications between environments, services, and applications to only authenticated and authorized connections, as justified by the business. Review these configurations at least annually, and support them by a documented justification of all allowed services, protocols, ports, and compensating controls.

Auditing Guidelines for Cloud Service Providers (CSP)

1. Examine network policies and procedures for communication between environments in cloud.

2. Verify network segmentation to ensure proper isolation between security zones and environments.

3. Determine access controls, protocols, and encryption to secure communication between environments, services, and applications, ensuring only authenticated, authorized connections are permitted.

4. Verify continuous monitoring of network communications and logging to detect and address unauthorized or unusual activities promptly.

5. Verify regular reviews, at least annually with policies update to align with business needs and evolving threats, ensuring structured record-keeping of changes and approvals.

From CCM v4.1:

1. Examine the policy for communication between environments.

2. Examine the criteria for business justification of communication, and reviews.

3. Determine if the inventory of allowed communication has been reviewed, at least annually.

4. Evaluate the effectiveness of the monitoring and encryption of such communication.

5. Evaluate the details of business justification, and its review.

I&S-04: OS Hardening and Base Controls

Control Specification

Harden host and guest OS, hypervisor or infrastructure control plane, according to their respective best practices, and supported by technical controls, as part of a security baseline.

Auditing Guidelines for Cloud Service Providers (CSP)

1. Examine documented policies and hardening security baselines alignment with business needs and industry best practices.

2. Determine if appropriate technical controls are in place to enforce and verify system hardening (e.g., CIS Cloud Benchmarks, AWS and Azure Security Baselines).

3. Verify regular assessments conducted against established security baselines, ensuring promptly addressing any identified deviations or vulnerabilities.

4. Verify an annual review of hardening configurations for hosts, guest OS, and hypervisors, ensuring documented results are reviewed and approved by authorities.

5. Determine if emerging threats are monitored and hardening procedures are updated accordingly, ensuring all changes are systematically documented and approved.

From CCM v4.1:

1. Determine if the host and the guest OS has been hardened as per best practices.

2. Determine if the hypervisor or infrastructure control planes are hardened as per best practices.

3. Determine if appropriate technical controls exist that ensure that the hardening is done.

4. Determine if a security baseline has been set up.

5. Determine if the security baseline contains information about the hardening done.

I&S-05: Production and Non-Production Environments

Control Specification

Separate production and non-production environments to reduce the risk of sensitive production data being used in non-production environments. Production data is sanitized or protected before any authorized non-production use.

Auditing Guidelines for Cloud Service Providers (CSP)

1. Examine Cloud Service Provider (CSP) policies and procedures ensuring separation of production and non-production environments to reduce the risk of sensitive production data exposure.

2. Verify clear delineation of responsibilities under the Shared Responsibility Model between the CSP and cloud consumers regarding production and non-production environment segregation and production data handling.

3. Verify role-based and least-privilege access controls enforce separation between production and non-production environments, restricting production access to authorized personnel only.

4. Verify procedures ensuring production data is not used in non-production environments unless sanitized or otherwise protected before any authorized use.

5. Verify formal change promotion processes between non-production and production environments preserve environment separation and prevent unauthorized data transfer, including documented approvals and integrity validation.

6. Verify monitoring and logging across environments to detect unauthorized access, data movement, or configuration changes, and confirm logs are securely maintained and reviewed.

7. Confirm segregation and production data protection controls are periodically reviewed and updated to address evolving threats, regulatory requirements, and tenant isolation requirements.

From CCM v4.1:

1. Verify if production and non-production environments are appropriately segregated.

2. Verify if the segregation is reviewed and managed during change management.

3. Verify the classification of data contained in each environment.

I&S-06: Segmentation and Segregation

Control Specification

Design, develop, deploy and configure applications and infrastructures such that service customer (tenant) access is appropriately segmented and segregated, monitored and restricted.

Auditing Guidelines for Cloud Service Providers (CSP)

1. Verify documented policies and procedures clearly define segmentation and segregation practices used to enforce service customer (tenant) isolation within shared cloud infrastructure.

2. Verify network and logical segmentation mechanisms are implemented to prevent unauthorized cross-tenant access to systems and data.

3. Verify access controls align with segmentation and segregation policies and restrict access to resources within the appropriate tenant context.

4. Review evidence of regular testing and validation of segmentation controls to confirm continued effectiveness of tenant isolation.

5. Review incident response procedures to confirm they address detection, containment, and remediation of cross-tenant access or isolation failures.

6. Verify monitoring and logging mechanisms are capable of detecting unauthorized cross-tenant activity or boundary violations.

7. Determine whether relevant personnel receive periodic training on tenant isolation and segmentation responsibilities, where applicable to their role.

From CCM v4.1:

1. Review evidence to verify that the design and development of applications and infrastructure ensure appropriate best practices such as hardening, segmentation, and segregation is incorporated and the shared responsibility model between the CSP and CSC is maintained.

2. Review evidence to verify that the deployment and configuration of applications and infrastructure follow appropriate hardening, segmentation, and segregation is incorporated and the shared responsibility model between the CSP and CSC is maintained.

3. Review evidence to determine that segmentation and segregation is monitored.

4. Review evidence to determine that the tenants are isolated from each other.

I&S-07: Migration to Hosted Environments

Control Specification

Use secure and encrypted communication channels when migrating servers, services, applications, or data to hosted environments. Such channels must include only up-to-date and approved protocols.

Auditing Guidelines for Cloud Service Providers (CSP)

1. Verify the Cloud Service Provider has comprehensive documentation identifying and detailing high-risk environments based on data sensitivity, threat exposure, and business impact.

2. Confirm encryption mechanisms adhere to current security standards.(e.g., supporting processing, storage, and network services).

3. Check records documenting secure migration processes.

4. Ensure risk assessments conducted before migrating sensitive data to cloud environments.

5. Validate compliance checks post-migration to confirm the security and integrity of data.

6. Confirm clearly defined roles and responsibilities for migration activities.

7. Verify documented incident response plans for issues arising during cloud migration.

From CCM v4.1:

1. Examine the list of environments that will be the target of migrations.

2. Examine the criteria for maintaining a list of approved protocols.

3. Examine the records of migrations.

I&S-08: Network Architecture Documentation

Control Specification

Identify and document high-risk environments based on data sensitivity, threat exposure, and business impact.

Auditing Guidelines for Cloud Service Providers (CSP)

1. Verify the Cloud Service Provider has comprehensive documentation identifying and detailing high-risk environments.

2. Confirm regular updates and reviews of network architecture documentation (e.g., cloud security baselines, CSA Star certification, MITRE Cloud Matrix).

3. Check availability and accessibility of architecture documentation to authorized personnel.

4. Ensure documentation aligns with current network configurations and practices.

5. Validate documented processes for identifying and managing changes to network architecture.

6. Confirm training provided to responsible personnel for maintaining accurate documentation.

From CCM v4.1:

1. Examine the criteria for identifying high-risk environments.

2. Examine the inventory of high-risk environments, and periodicity of review.

I&S-09: Network Defense

Control Specification

Define, implement and evaluate processes, procedures and defense-in-depth techniques for protection, detection, and timely response to network-based attacks.

Auditing Guidelines for Cloud Service Providers (CSP)

1. Verify the Cloud Service Provider (CSP) documented procedures clearly define network defense mechanisms.

2. Confirm regular implementation and evaluation of defense strategies (e.g., Zero Trust, honey pots, Microsoft Sentinel, AWS GuardDuty).

3. Check routine testing of defense mechanisms for effectiveness against current threats.

4. Ensure monitoring and logging effectively capture events relevant to network defense.

5. Validate timely response and mitigation processes for detected threats.

6. Confirm clear accountability and documented roles for network defense management.

7. Verify regular training sessions on network defense practices provided to security teams.

From CCM v4.1:

1. Interview the team to evaluate if they have defined processes and procedures for protection, detection and timely response to address network based attacks.

2. Review evidence to establish that the defined processes and procedures have been implemented.

3. Review evidence to establish that the processes and procedures are evaluated and validated periodically.

4. Review evidence to establish that the processes and procedures are based upon a defense-in-depth.

5. Review evidence to support the effective activation of incident response plans when necessary including the associated communication protocols.

LOG: Logging and Monitoring

LOG-01: Logging and Monitoring Policy and Procedures

Control Specification

Establish, document, approve, communicate, apply, evaluate and maintain policies and procedures for logging and monitoring. Review and update the policies and procedures at least annually, or upon significant changes.

Auditing Guidelines for Cloud Service Providers (CSP)

1. Conduct interviews with personnel responsible for documenting, maintaining, and communicating organizational logging and monitoring policies, procedures, and standards (the Policies).

2. Inspecting Records and Documents: Obtain and review the Policies to ensure they are adequate for the organization to manage risks associated with logging and monitoring. Verify that the Policies define the personnel or roles responsible for their dissemination, identify an official accountable for managing the Policies, specify the frequency of reviews and updates (annually), and outline events that necessitate policy updates. Review the Policies by performing the following verification steps:

   1. Verify that logging and monitoring infrastructure services (e.g., Cloud Logging, CloudWatch) comply with CSP’s internal logging policies.

   2. Confirm that the CSP enforces logging for IAM events, data access, and service configuration changes.

   3. Ensure logs are protected using encryption at rest and in transit, with strict access controls.

   4. Check for evidence of monitoring policies applied to CSP-managed services used by tenants.

   5. Validate that CSP provides customers with access to their relevant logs or offers secure export functionality.

   6. Confirm that CSP logs are subject to regular audits and support legal or compliance inquiries.

   7. Ensure that logs support investigation of cross-tenant issues and supply chain-related anomalies.

   8. Verify controls are in place to prevent and detect disabling or tampering with log pipelines.

   9. Examine policy and procedures for adequacy, approval, communication, and effectiveness as applicable to planning, delivery and support of the organization’s logging and monitoring requirements.

   10. Examine policy and procedures for evidence of review at least annually.

3. Verify that the Policies are communicated, reviewed and updated at least annually or upon significant changes, are approved, and communicated to relevant stakeholders.

From CCM v4.1:

1. Examine policy and procedures for adequacy, approval, communication, and effectiveness as applicable to planning, delivery and support of the organization’s logging and monitoring requirements.

2. Examine policy and procedures for evidence of review at least annually.

LOG-02: Audit Logs Protection

Control Specification

Define, implement and evaluate processes, procedures and technical measures to ensure the security and retention of audit logs.

Auditing Guidelines for Cloud Service Providers (CSP)

1. Inquiring with Control Owners: Conduct interviews with personnel responsible for defining, implementing, and evaluating audit log security and retention processes for cloud infrastructure and AI processing services to understand their roles in protecting infrastructure logs and customer compute data. Verify their understanding of technical measures implemented to ensure audit logs from GPU/TPU resources, distributed computing environments, and customer workloads remain secure and are retained according to organizational requirements.

2. Inspecting Records and Documents: 2.1 Verify that infrastructure logs, hypervisor logs, and customer compute session logs are stored in write-once or append-only formats where feasible.

   1. Confirm that logs containing customer workload data, resource utilization metrics, and infrastructure access patterns are protected using encryption at rest and in transit.

   2. Ensure access to infrastructure logs is restricted to authorized cloud operations personnel only, with RBAC or IAM controls maintaining customer data isolation.

   3. Validate mechanisms to detect and alert on unauthorized access attempts or changes to logs containing customer infrastructure usage and performance data.

   4. Check that cloud infrastructure log protection is periodically tested through internal audits, including validation of multi-tenancy security controls.

   5. Confirm that log retention for cloud services aligns with customer contracts, regulatory requirements, and business policy requirements.

   6. Verify that controls are in place to prevent unauthorized access to customer compute logs and maintain infrastructure security boundaries.

   7. Review documented processes and procedures for cloud infrastructure audit log security, including breach notification and regulatory reporting procedures.

   8. Validate that backup and recovery procedures exist for infrastructure audit logs to ensure operational continuity and customer service availability.

   9. Confirm that log disposal procedures are secure and documented for infrastructure logs when retention periods expire, including customer data destruction verification.

   10. Validate that logging services (e.g., CloudTrail, Audit Logs) enforce strict access policies and logging integrity.

   11. Confirm logs cannot be disabled or modified without elevated administrative approval.

   12. Ensure that encryption and integrity checks are applied to all logs in transit and at rest.

   13. Verify segregation of duties to prevent unauthorized access or deletion of customer logs.

   14. Confirm mechanisms exist to detect tampering or anomalies in the logging pipeline.

   15. Check that CSP logs are regularly backed up and retained per compliance standards.

   16. Ensure CSP logs support forensic investigations and comply with third-party audit requirements.

   17. Validate that security incidents involving logging protection violations are promptly recorded and remediated.

From CCM v4.1:

1. Examine the organization’s log retention requirements.

2. Evaluate the policy and technical measures with respect to effectiveness.

LOG-03: Security Monitoring and Alerting

Control Specification

Identify and monitor security-related events within applications, the underlying infrastructure. Define and implement a system to generate alerts to responsible stakeholders based on such events and corresponding metrics.

Auditing Guidelines for Cloud Service Providers (CSP)

1. Inquiring with Control Owners: Conduct interviews with personnel responsible for identifying, monitoring, and alerting on security-related events within cloud infrastructure and multi-tenant compute environments. Determine how infrastructure security events are defined and classified, how alert thresholds or metrics are established, and how notifications are routed to responsible stakeholders for incidents involving unauthorized access, infrastructure compromise, or tenant isolation failures.

2. Inspecting Records and Documents: 2.1 Verify documented procedures define security-related events to be monitored across cloud infrastructure components (e.g., hypervisors, compute nodes, storage systems, network infrastructure, and tenant isolation mechanisms).

   1. Verify monitoring mechanisms are implemented to detect defined security events across infrastructure and tenant environments (e.g., unauthorized access attempts, privilege escalation, hypervisor or container escape attempts, hardware tampering, or cross-tenant boundary violations).

   2. Review logs or monitoring outputs to determine whether defined security events are captured and retained in accordance with monitoring procedures.

   3. Verify alerting mechanisms are configured and generate notifications when defined security event thresholds or metrics are met.

   4. Verify that alert notifications are directed to appropriate responsible stakeholders.

   5. Review evidence that monitoring configurations and alert thresholds are periodically reassessed and updated as infrastructure architecture or threat conditions change.

From CCM v4.1:

1. Examine policy related to the security monitoring and alerting, and determine if security-related events within applications and the underlying infrastructure are identified.

2. Examine processes related to identifying responsible stakeholders for the purpose of alerting.

3. Evaluate the implementation with respect to effectiveness, and conduct a review of metrics.

LOG-04: Audit Logs Access and Accountability

Control Specification

Restrict audit log access to authorized identities and maintain records of that access.

Auditing Guidelines for Cloud Service Providers (CSP)

1. Inquiring with Control Owners: Conduct interviews with personnel responsible for managing cloud infrastructure audit log access controls and maintaining access records to understand their authorization processes for accessing infrastructure logs, customer workload logs, and system security events. Verify their understanding of access restriction mechanisms and record-keeping requirements for all cloud infrastructure audit log access activities.

2. Inspecting Records and Documents: 2.1 Verify access to cloud infrastructure-generated audit logs (including compute resource usage, customer workload events, infrastructure security incidents, and system operations) is restricted to authorized personnel.

   1. Ensure cloud infrastructure logging access is role-based and mapped to least privilege principles, maintaining customer workload isolation and data protection.

   2. Confirm all cloud infrastructure log access events are themselves logged with timestamps, actor IDs, and specific customer environment data accessed.

   3. Check for formal review processes of cloud infrastructure log access permissions, including customer data isolation requirements.

   4. Validate cloud operations and infrastructure teams are not granted persistent access to customer-specific logs without approval and operational necessity.

   5. Review incident records for unauthorized access to cloud infrastructure audit logs and follow-up actions taken.

   6. Confirm procedures are in place to revoke cloud infrastructure log access upon role changes or terminations.

   7. Examine documented access control policies and procedures for cloud infrastructure audit log systems, including customer tenant protections.

   8. Validate that cloud infrastructure access records are retained according to customer SLAs and compliance requirements.

   9. Review monitoring and alerting mechanisms for unauthorized or suspicious cloud infrastructure audit log access attempts.

   10. Verify access to orchestration platform logs is strictly controlled and subject to periodic access reviews.

   11. Confirm administrative access to audit logs is gated through MFA and approval workflows.

   12. Validate log access events are included in centralized security monitoring dashboards.

   13. Review segregation of duties policies to prevent unauthorized modification, deletion, or tampering of audit logs.

   14. Verify CSP performs and documents periodic access reviews of logging infrastructure.

From CCM v4.1:

1. Examine policy related to the protection of log information.

2. Determine if the control requirements stipulated in the policy have been implemented.

3. Examine policy related to the maintenance of access records.

LOG-05: Audit Logs Monitoring and Response

Control Specification

Implement and maintain capabilities to correlate and monitor security audit logs for the detection of suspicious or anomalous activity that deviates from typical or expected patterns. Establish and follow a defined process to review and take appropriate and timely actions on detected anomalies.

Auditing Guidelines for Cloud Service Providers (CSP)

1. Inquiring with Control Owners: Conduct interviews with personnel responsible for monitoring cloud infrastructure security audit logs to understand how anomalous resource usage and suspicious infrastructure activity are identified, how baseline infrastructure behavior is defined, and how detected anomalies are reviewed and acted upon in a timely manner.

2. Inspecting Records and Documents

   1. Verify security audit logs are generated and monitored for cloud infrastructure components, including compute resources, storage systems, network activity, hypervisor operations, and tenant-related events.

   2. Verify correlation rules or detection mechanisms are implemented to identify suspicious or anomalous activity that deviates from defined baseline infrastructure behavior.

   3. Review documentation defining baseline infrastructure usage patterns and criteria used to classify activity as anomalous.

   4. Review monitoring outputs or dashboards to determine whether detected anomalies are logged and tracked.

   5. Verify a documented process exists for reviewing detected anomalies and taking appropriate and timely action.

   6. Inspect evidence that detected anomalies are reviewed and that appropriate and timely actions are taken and documented in accordance with the defined process.

   7. Review evidence that anomaly detection thresholds or correlation rules are periodically reassessed and updated as infrastructure architecture, customer usage patterns, or threat conditions change.

   8. Verify alerts are generated for high-risk infrastructure activities such as privilege escalation, unauthorized API access, tenant boundary violations, or abnormal resource consumption.

From CCM v4.1:

1. Examine policy for the monitoring of audit logs.

2. Determine if policy and patterns have been established for anomalous activities.

3. Examine policy for the review of, and timely action on anomalies.

LOG-06: Clock Synchronization

Control Specification

Use a reliable time source across all relevant information processing systems.

Auditing Guidelines for Cloud Service Providers (CSP)

1. Inquiring with Control Owners: Conduct interviews with personnel responsible for managing time synchronization across cloud infrastructure and AI processing resources to understand their implementation of reliable time sources for compute resource management, customer workload tracking, and infrastructure monitoring. Verify their understanding of time synchronization requirements for multi-tenant environments, GPU/TPU clusters, and procedures for maintaining accurate timestamps across distributed cloud infrastructure.

2. Inspecting Records and Documents: 2.1 Confirm cloud infrastructure systems handling compute resources and customer workloads use a centralized time source.

   1. Verify implementation of Network Time Protocol (NTP) or equivalent time synchronization protocols across cloud infrastructure, hypervisors, and AI processing clusters.

   2. Check synchronization logs to validate accurate timestamping across compute resource allocation, customer workload execution, and infrastructure monitoring activities.

   3. Assess whether unsynchronized cloud infrastructure systems trigger alerts or errors that could affect customer workload scheduling or resource billing accuracy.

   4. Verify clock drift thresholds are defined and monitored for cloud infrastructure components, GPU/TPU clusters, and customer tenant environments.

   5. Confirm the accuracy of timestamps in cloud infrastructure logs critical for customer billing, resource utilization tracking, and security investigations.

   6. Validate incident response records for infrastructure issues reference consistent timestamps across customer environments and infrastructure components.

   7. Examine documentation of reliable time source configuration for cloud infrastructure and backup time synchronization mechanisms across data centers.

   8. Review time synchronization policies covering cloud infrastructure, customer tenant isolation, and AI processing resource management systems.

   9. Validate that time source reliability is monitored for cloud infrastructure and backup time sources are available to maintain service availability across multiple regions.

   10. Confirm use of centralized, authenticated NTP servers across the cloud infrastructure.

   11. Verify tenant isolation does not interfere with consistent time sync in multi-tenant setups.

   12. Ensure that logs generated from different services share a common time reference.

   13. Validate redundancy and fault-tolerance in time source configurations.

   14. Check monitoring systems for alerting when time synchronization fails.

   15. Review logs of past sync failures and documented remediation steps.

   16. Confirm compliance with regulatory standards requiring timestamp precision.

From CCM v4.1:

1. Examine policy that establishes the time scale and epoch, or traceability, of time across systems.

2. Evaluate the process that ensures synchronization of time on relevant systems.

LOG-07: Logging Scope

Control Specification

Establish, document and implement which information meta/data system events should be logged. Review and update the scope at least annually or whenever there is a change in the threat environment, and as per relevant regulatory requirements.

Auditing Guidelines for Cloud Service Providers (CSP)

1. Inquiring with Control Owners: Conduct interviews with personnel responsible for establishing, documenting, and implementing logging scope for cloud infrastructure events and compute resource metadata to understand their process for defining which AI processing and customer workload events should be logged and their procedures for annual reviews. Verify their understanding of infrastructure security threat environment changes that trigger scope updates and their implementation of documented logging requirements across compute clusters, storage systems, and customer tenant environments.

2. Inspecting Records and Documents: 2.1 Confirm documentation specifies which cloud infrastructure events must be logged (e.g., compute resource allocation, customer workload execution, storage access, network traffic, hypervisor activities).

   1. Validate inclusion of both success and failure events in the cloud infrastructure logging scope, including successful resource provisioning and failed authentication attempts.

   2. Ensure regular reviews of cloud infrastructure logging scope to capture evolving infrastructure security threats such as hypervisor attacks, side-channel exploits, and customer isolation breaches.

   3. Check scope alignment with customer SLA requirements, regulatory compliance standards, and cloud service contractual obligations.

   4. Assess procedures for adjusting logging scope when deploying new infrastructure services, AI accelerators, or customer environments.

   5. Confirm stakeholder approval for the defined cloud infrastructure logging scope, including input from cloud operations teams, security architects, and compliance officers.

   6. Verify logs reflect real-world cloud infrastructure events as specified in scope documents, including resource utilization, customer activities, and system operations.

   7. Examine evidence of annual cloud infrastructure logging scope reviews and documentation of any scope updates driven by new infrastructure threats or regulatory changes.

   8. Review procedures for monitoring and responding to infrastructure threat environment changes that may require logging scope adjustments for emerging attack vectors.

   9. Validate that implementation of cloud infrastructure logging scope requirements is consistently applied across all compute resources, storage systems, network infrastructure, and customer tenant isolation mechanisms.

   10. Confirm that the scope includes all infrastructure-level logs (compute, storage, network).

   11. Validate services automatically log user actions, configuration changes, and API calls.

   12. Assess whether default logging scope can be customized per tenant.

   13. Ensure regular scope reviews as services or customer requirements evolve.

   14. Verify logging of control plane and data plane events.

   15. Review service documentation to ensure it defines and enforces consistent logging scope.

   16. Confirm that changes to the defined logging scope are documented with version history, formal approvals, and traceability to relevant regulatory requirements or compliance obligations.

CCM v4.1:

1. Examine policy for the identification of loggable events, applications, or systems.

2. Examine the outputs of such identification, with respect to review and approval.

3. Examine scope for evidence of review at least annually.

LOG-08: Audit Logs Sanitization

Control Specification

Define, implement and evaluate technical measures for service customers to detect and scrub or tokenize sensitive data from logs to prevent unauthorized exposure, as per applicable laws and regulations.

Auditing Guidelines for Cloud Service Providers (CSP)

1. Inquiring with Control Owners: Conduct interviews with personnel responsible for defining, implementing, and evaluating the technical measures that allow service customers to detect, and scrub, or tokenize sensitive data from applicable, and scoped, AI logs, which helps customers prevent unauthorized exposure, as per applicable laws and regulations. Verify their understanding of this customer responsibility, and its applicability for the scoped product or service within the workflow the Cloud Service Provider supports.

2. Review product or service baseline, or agreement to verify that customer can opt-in for this responsibility, within the workflow the Cloud Service Provider supports, and based on the regulations that are applicable.

3. Verify that automated safeguards are in place according to the technical measures defined for the product or service within the workflow the Cloud Service Provider supports, and based on the regulations that are applicable.

   1. Review the product or service description.

   2. Review the product or service customer agreement.

   3. Review the product or service customer baseline.

4. For those customers that opt-in, examine logs of the scoped product or services to verify only allowed information exists within logs. Due to the fact that company policy may not allow a review of this nature, especially logs that are customer or partially-customer controlled, policy should be cited, and this step skipped. Additionally, it is possible to review the logs of a test environment if one is available.

From CCM v4.1:

1. Examine documentation describing the technical measures available to service customers for detecting and removing sensitive data from audit logs. Confirm these measures are defined in accordance with applicable laws and regulatory requirements (e.g., GDPR, HIPAA, or regional requirements).

2. Determine whether the service provider offers mechanisms to assist service customers with log sanitization, such as configurable logging policies, pattern-matching tools (e.g., regular expressions), predefined sanitization rules, or API support for log filtering.

3. Evaluate whether guidance and controls are provided to service customers for identifying and sanitizing sensitive data fields in logs prior to retention, export, or external sharing (e.g., documented best practice templates, or tooling for log pre-preprocessing).

4. Assess whether customer-accessible audit log sanitization features (e.g., masking, field exclusion, redaction capabilities) are tested periodically and whether changes to these features are reviewed and documented after significant system updates.

5. Review evidence that service customers are made aware of their responsibilities and available options for audit log sanitization, such as through service-level documentation, customer onboarding materials, or support channels.

LOG-09: Log Records

Control Specification

Generate audit records containing relevant security information.

Auditing Guidelines for Cloud Service Providers (CSP)

1. Inquiring with Control Owners: Conduct interviews with personnel responsible for generating audit records containing relevant cloud infrastructure security information to understand their processes for capturing, formatting, and maintaining security-related audit data across AI processing resources and customer workload environments. Verify their understanding of what constitutes relevant infrastructure security information and their procedures for ensuring audit records contain sufficient detail for infrastructure security investigations, customer isolation validation, and service availability requirements.

2. Inspecting Records and Documents: 2.1 Verify cloud infrastructure logs capture event type, timestamp, actor, and source for all compute resource operations, customer workload activities, and infrastructure management events.

   1. Confirm logs include identifiers for correlating infrastructure actions across compute clusters, storage systems, and customer tenant environments.

   2. Ensure structured formats (e.g., JSON, syslog) are used for consistency across cloud infrastructure logging systems.

   3. Check completeness of cloud infrastructure log records by sampling resource allocation trails, customer workload execution patterns, and infrastructure operation flows.

   4. Validate that custom infrastructure events are logged where relevant (e.g., hypervisor escape attempts, customer isolation violations, resource exhaustion attacks).

   5. Review cloud infrastructure audit logs for evidence of tampering or missing entries related to customer workloads and infrastructure operations.

   6. Examine cloud infrastructure audit records to ensure they contain relevant security information such as resource access controls, customer workload isolation events, infrastructure configuration changes, and security boundary violations.

   7. Validate that cloud infrastructure audit records include sufficient contextual information to support infrastructure security investigations, customer isolation verification, and service availability analysis.

   8. Confirm that cloud infrastructure audit record generation covers all security-relevant events across compute resources, storage systems, network infrastructure, and customer tenant isolation mechanisms.

   9. Review cloud infrastructure audit record retention and storage mechanisms to ensure infrastructure security information remains available for customer SLA compliance and regulatory requirement timeframes.

   10. Verify cloud-native services generate logs with required fields (e.g., resource, action, user).

   11. Confirm records support compliance with regional and industry regulations.

   12. Validate timestamps, source IPs, and user identifiers are present in each log record.

   13. Review consistency across services (e.g., IAM, VMs, storage).

   14. Check integrity of audit trails by comparing against service-level events.

   15. Confirm that all log-generating services follow centralized schema.

From CCM v4.1:

1. Examine policy related to audit logging and determine if it includes requirements to generate audit records containing relevant security information.

2. Examine audit records and determine if they adequately reflect the policy.

LOG-10: Audit Records Protection

Control Specification

Protect audit records from unauthorized access, modification, and deletion.

Auditing Guidelines for Cloud Service Providers (CSP)

1. Inquiring with Control Owners: Conduct interviews with personnel responsible for protecting cloud infrastructure audit records from unauthorized access, modification, and deletion. Verify their understanding of security controls, access restrictions, monitoring procedures, and incident response processes related to audit records.

2. Inspecting Records and Documents: 2.1 Verify access controls enforce least-privilege and role-based restrictions for cloud infrastructure audit records.

   1. Verify audit records are protected against unauthorized modification or deletion through tamper-resistant or immutable storage mechanisms.

   2. Review documentation demonstrating encryption of audit records at rest and during transmission.

   3. Verify audit records are segregated from operational data and protected independently.

   4. Review audit trails documenting access to audit record storage locations.

   5. Verify monitoring and alerting mechanisms detect unauthorized access, modification, or deletion attempts involving audit records.

   6. Examine backup and recovery procedures ensuring protection extends to archived audit records.

   7. Verify periodic testing and review of audit record protection controls.

   8. Review incident response procedures addressing compromise or suspected compromise of audit records.

   9. Verify responsibilities for audit record protection are clearly defined under the Shared Responsibility Model between the CSP and cloud consumers.

From CCM v4.1:

1. Examine policy for the protection of audit records.

2. Evaluate the use of technical measures in the protection of audit records.

LOG-11: Encryption Monitoring and Reporting

Control Specification

Establish and maintain a monitoring and internal reporting capability over the operations of cryptographic, encryption and key management policies, processes, procedures, and controls.

Auditing Guidelines for Cloud Service Providers (CSP)

1. Inquiring with Control Owners: Conduct interviews with personnel responsible for establishing and maintaining monitoring and internal reporting capabilities over cryptographic, encryption, and key management operations for cloud infrastructure and AI processing resources to understand their oversight processes for customer data protection and infrastructure security. Verify their understanding of monitoring controls for encryption of customer workloads, internal reporting mechanisms for infrastructure cryptographic operations, and procedures for maintaining ongoing oversight of key management for customer isolation and service security.

2. Inspecting Records and Documents: 2.1 Confirm monitoring mechanisms are in place to detect encryption failures or unauthorized decryption attempts for cloud infrastructure data, customer workloads, and inter-service communications.

   1. Verify reports are generated on the use of encryption in cloud infrastructure data transmission, customer data storage, and compute resource protection.

   2. Review documentation on how cryptographic keys are handled, rotated, and monitored for cloud infrastructure security, customer data protection, and tenant isolation.

   3. Validate that cloud infrastructure teams receive alerts for deviations in encryption policy adherence affecting customer security and infrastructure integrity.

   4. Check integration with central SIEM tools for real-time visibility into cloud infrastructure cryptographic operations and customer protection events.

   5. Ensure audit logs capture cloud infrastructure encryption-related events like certificate expiration, invalid key use, or customer data encryption failures.

   6. Confirm documentation of encryption algorithms and configurations in use for cloud infrastructure operations, customer data protection, and hardware security.

   7. Examine internal reporting processes for communicating cloud infrastructure cryptographic and key management findings to infrastructure operations and customer security teams.

   8. Review periodic assessment and reporting schedules for cloud infrastructure cryptographic policy compliance and customer protection effectiveness.

   9. Validate that monitoring and reporting capabilities cover all aspects of cloud infrastructure cryptographic operations including customer isolation, infrastructure security, and regulatory compliance.

   10. Confirm centralized monitoring of encryption operations across all cloud services.

   11. Validate reporting systems track usage of KMS, HSMs, and customer-managed keys.

   12. Review incident handling procedures for failed or suspicious cryptographic operations.

   13. Verify customer access to audit logs involving key lifecycle events.

   14. Ensure tools are in place to alert on anomalies in key access patterns.

   15. Confirm monitoring of compliance with configured encryption policies across multi-tenant platforms.

   16. Check evidence of periodic reporting to external auditors or customers.

From CCM v4.1:

1. Examine policy related to the monitoring and reporting of operations of cryptographic policy.

2. Examine the process to identify such a policy.

3. Evaluate the effectiveness of such reporting capability.

LOG-12: Transaction/Activity Logging

Control Specification

Log and monitor key lifecycle management events to enable auditing and reporting on usage of cryptographic keys.

Auditing Guidelines for Cloud Service Providers (CSP)

1. Inquiring with Control Owners: Conduct interviews with personnel responsible for logging and monitoring key lifecycle management events for cloud infrastructure to understand their processes for capturing, analyzing, and reporting on cryptographic key usage for customer data protection and infrastructure security. Verify their understanding of key lifecycle event logging requirements for cloud operations, monitoring procedures for encryption keys protecting customer workloads, and reporting capabilities that enable auditing and compliance oversight of cryptographic key management activities in AI processing infrastructure.

2. Inspecting Records and Documents: 2.1 Verify that cryptographic key usage for cloud infrastructure data encryption, customer workload protection, and compute resource security is logged by the infrastructure management systems.

   1. Confirm logs include timestamped records of key creation, use, rotation, and destruction for cloud infrastructure operations, customer data protection, and tenant isolation security.

   2. Ensure visibility into key usage by different cloud infrastructure components, compute cluster services, and customer tenant systems.

   3. Validate alerts are generated on suspicious or unauthorized key operations affecting cloud infrastructure security or customer data protection.

   4. Check alignment with internal policy for lifecycle monitoring of keys used within cloud infrastructure for customer isolation and service availability protection.

   5. Review SIEM or monitoring tool integrations that centralize and analyze cloud infrastructure key-related activities and customer protection events.

   6. Confirm audit trails exist for every critical key management operation supporting cloud infrastructure functionality and customer data security.

   7. Examine reporting capabilities and procedures for generating cloud infrastructure key lifecycle management reports to support customer compliance and infrastructure security auditing requirements.

   8. Review log retention policies and practices to ensure cloud infrastructure key lifecycle event records are maintained for customer protection and regulatory compliance timeframes.

   9. Validate that key lifecycle monitoring covers all cloud infrastructure cryptographic operations including customer data encryption, compute security, and infrastructure backup protection activities.

   10. Verify cloud KMS and HSM services generate logs for all key operations (create, use, rotate, delete).

   11. Confirm customer access to logs through secure APIs or dashboards.

   12. Review policies ensuring that all key usage is auditable and traceable to specific identities.

   13. Check real-time alerting is in place for abnormal or failed key transactions.

   14. Ensure audit logs support chain-of-custody for regulatory compliance.

   15. Confirm backup and retention policies preserve transaction logs for cryptographic events.

   16. Validate internal reviews of key usage logs are conducted regularly.

From CCM v4.1:

1. Examine policy for logging and monitoring usage of cryptographic key usage lifecycle events.

2. Examine the process to identify such events.

3. Evaluate the review of these logs.

LOG-13: Access Control Logs

Control Specification

Monitor and log physical access using an auditable access control system.

Auditing Guidelines for Cloud Service Providers (CSP)

1. Inquiring with Control Owners: Conduct interviews with personnel responsible for monitoring and logging physical access using auditable access control systems for cloud infrastructure and AI processing facilities to understand their processes for tracking, recording, and reviewing physical access to data centers, compute clusters, and customer workload environments. Verify their understanding of access control system monitoring capabilities for cloud infrastructure, logging procedures for physical access to customer tenant facilities and AI processing resources, and audit trail requirements that ensure all physical access activities affecting infrastructure security and customer data protection are properly documented and reviewable.

2. Inspecting Records and Documents: 2.1 Verify physical access control systems are in place for all cloud infrastructure environments, including data centers, AI processing clusters, customer tenant facilities, and compute resource centers.

   1. Check logging mechanisms capture physical access timestamps, user identity, and location for cloud infrastructure facilities and customer workload environments.

   2. Confirm physical access logs are retained in accordance with customer protection and regulatory compliance requirements for cloud infrastructure operations.

   3. Validate alerts are generated for unauthorized or after-hours physical access to cloud infrastructure facilities and customer data centers.

   4. Review role-based access controls to ensure only authorized infrastructure personnel can retrieve physical access logs for cloud environments.

   5. Confirm periodic audits assess physical access adherence across all cloud infrastructure facilities and customer data protection areas.

   6. Examine whether physical access logs are integrated into centralized SIEM systems for correlation with cloud infrastructure security and customer protection events.

   7. Verify encryption is applied to stored physical access logs for cloud infrastructure facilities.

   8. Review monitoring procedures and capabilities of the physical access control system to ensure real-time visibility into physical access events affecting cloud infrastructure and customer environments.

   9. Validate that the access control system provides comprehensive audit trails with tamper-evident logging for all physical access activities in cloud infrastructure and customer facilities.

   10. Examine backup and recovery procedures for cloud infrastructure physical access control system logs to ensure continuity of audit capabilities for customer protection and regulatory compliance.

   11. Verify CSP data center physical access logs meet ISO/IEC 27001 and SOC 2 standards.

   12. Ensure detailed audit trails exist for infrastructure used by regulated or high-risk tenants.

   13. Check physical access logs are securely stored and cryptographically protected.

   14. Confirm that access to physical access log systems themselves is restricted and monitored.

   15. Validate that all physical access events are automatically reconciled with badge activity.

   16. Review retention and redaction protocols for tenant-specific physical access logs.

   17. Confirm customer audit rights for physical access under contractual obligations.

   18. Ensure physical access logs are regularly shared with tenants under shared responsibility models.

   19. Verify physical access controls and logging meet SOX compliance requirements for financial reporting systems and customer data protection.

   20. Validate physical access monitoring supports SOC audit requirements and control effectiveness testing.

From CCM v4.1:

1. Examine policy for logging and monitoring physical access.

2. Examine the process to identify such events.

3. Evaluate the review of these logs.

LOG-14: Failures and Anomalies Reporting

Control Specification

Define, implement and evaluate processes, procedures and technical measures for the reporting of anomalies and failures of the monitoring system and provide immediate notification to the accountable party.

Auditing Guidelines for Cloud Service Providers (CSP)

1. Inquiring with Control Owners: Conduct interviews with personnel responsible for defining, implementing, and evaluating processes for reporting cloud infrastructure monitoring system anomalies and failures to understand their procedures for detecting, classifying, and immediately notifying accountable parties of infrastructure issues affecting customer workloads and data protection. Verify their understanding of technical measures for cloud infrastructure anomaly detection, notification workflows for different infrastructure failure types, and evaluation processes that ensure cloud monitoring system reliability and timely escalation to responsible stakeholders including cloud operations teams and customer security contacts.

2. Inspecting Records and Documents: 2.1 Verify cloud infrastructure systems are configured to detect logging anomalies such as dropped compute events, storage access failures, or customer workload data format corruption affecting service availability and customer isolation.

   1. Check processes are in place for classifying cloud infrastructure failure severity and identifying responsible owners including cloud operations teams, customer success managers, and security incident response staff.

   2. Validate cloud infrastructure failures trigger alert workflows in ticketing or incident response platforms with appropriate escalation to cloud operations and customer security teams.

   3. Ensure fallback mechanisms exist when primary cloud infrastructure logging systems fail, including backup resource monitoring and customer workload tracking capabilities.

   4. Confirm logs of cloud infrastructure failure events are themselves collected and analyzed to understand impact on customer services and infrastructure reliability.

   5. Check that post-incident reviews incorporate root cause analysis for cloud infrastructure failures with focus on customer impact and service level agreement compliance.

   6. Verify metrics are defined to track detection and resolution of cloud infrastructure anomalies including customer service impact and infrastructure availability measures.

   7. Examine immediate notification procedures for cloud infrastructure monitoring failures to ensure accountable parties including cloud operations teams and customer security contacts receive timely alerts.

   8. Review evaluation processes for assessing the effectiveness of cloud infrastructure anomaly reporting and failure notification procedures in maintaining customer trust and service reliability.

   9. Validate that technical measures include automated escalation mechanisms for cloud infrastructure monitoring failures when initial notifications are not acknowledged by responsible cloud operations teams.

   10. Confirm logging infrastructure includes built-in anomaly detection for write failures, latency, or integrity.

   11. Verify system health metrics feed into anomaly classification engines.

   12. Check for anomalies in cross-tenant logs, such as unauthorized metadata modifications.

   13. Validate regulatory reporting mechanisms for significant failure events.

   14. Ensure anomaly dashboards support both internal use and tenant visibility.

   15. Confirm documented workflows route failures to engineering and trust teams for triage.

From CCM v4.1:

1. Examine the policy for reporting of anomalies and failures of the monitoring system.

2. Examine the process for identifying accountable parties.

LOG-15: Input Monitoring

Control Specification

Log and monitor all input events (content and metadata) to enable auditing and reporting on the usage of AI models.

Auditing Guidelines for Cloud Service Providers (CSP)

1. Inquiring with Control Owners: Conduct interviews with personnel responsible for logging and monitoring all input events (content and metadata) to cloud AI processing infrastructure to understand their processes for capturing, storing, and analyzing workload input data for auditing infrastructure usage and reporting on compute resource utilization across customers. Verify their understanding of input event logging requirements for cloud infrastructure, monitoring procedures for customer workload patterns and resource performance, and reporting capabilities that enable comprehensive auditing of AI infrastructure interactions and capacity analytics.

2. Inspecting Records and Documents: 2.1 Confirm input logging covers all cloud infrastructure endpoints including compute APIs, storage interfaces, customer portals, and third-party cloud service integrations.

   1. Verify logs capture customer identity, workload source, timestamp, resource allocation, and input payload structure for AI infrastructure requests.

   2. Check that logging does not capture sensitive customer workload data unless explicitly required for infrastructure functionality and properly protected under customer agreements.

   3. Validate logging covers both direct customer inputs to infrastructure services and indirect inputs processed through automated scaling and resource management systems.

   4. Confirm that cloud infrastructure logs are used to detect resource abuse, security violations, or malformed requests affecting infrastructure security and customer isolation.

   5. Review retention settings to ensure cloud infrastructure input logs are stored in alignment with customer agreements and regulatory compliance requirements.

   6. Ensure cloud infrastructure input logs feed into usage analytics dashboards for capacity planning and customer experience monitoring.

   7. Verify access to cloud infrastructure input logs is role-restricted to authorized infrastructure personnel and fully auditable for customer data protection.

   8. Examine monitoring capabilities to ensure real-time visibility into cloud infrastructure usage patterns, resource performance metrics, and customer utilization trends.

   9. Validate that metadata logging includes comprehensive infrastructure context such as resource parameters, service configurations, customer details, and performance metrics.

   10. Review reporting mechanisms to confirm they provide adequate audit trails for cloud infrastructure governance, customer compliance, and capacity analytics.

   11. Confirm logging APIs and input collection services provide tenants access to their logs.

   12. Validate input logging mechanisms are embedded in AI services (e.g., model endpoints).

   13. Ensure logs capture tenant ID, region, service version, and API path.

   14. Confirm guardrails prevent inadvertent access to other tenants’ input logs.

   15. Check for logs covering service-to-service input invocations.

   16. Validate SLAs are met for input log availability and retention.

   17. Verify CSP personnel access to logs is logged and reviewed.

LOG-16: Output Monitoring

Control Specification

Log and monitor all output events (content and metadata) to enable auditing and reporting on usage of AI models.

Auditing Guidelines for Cloud Service Providers (CSP)

1. Inquiring with Control Owners: Conduct interviews with personnel responsible for managing time synchronization across AI model development and distribution systems to understand their implementation of reliable time sources for model training logs, research activities, and model versioning. Verify their understanding of time synchronization requirements for training infrastructure, model distribution platforms, and procedures for maintaining accurate timestamps across model lifecycle activities.

2. Inspecting Records and Documents: 2.1 Confirm AI model development systems handling training processes and model distribution use a centralized time source.

   1. Verify implementation of Network Time Protocol (NTP) or equivalent time synchronization protocols across model training clusters and research infrastructure.

   2. Check synchronization logs to validate accurate timestamping across model training processes, evaluation metrics, and distribution activities.

   3. Assess whether unsynchronized model development systems trigger alerts or errors that could affect training reproducibility or research integrity.

   4. Verify clock drift thresholds are defined and monitored for model training infrastructure and model serving systems.

   5. Confirm the accuracy of timestamps in model development logs critical for research reproducibility and intellectual property protection.

   6. Validate incident response records for model-related issues reference consistent timestamps across training sessions and model deployment events.

   7. Examine documentation of reliable time source configuration for model development environments and backup time synchronization mechanisms.

   8. Review time synchronization policies covering model training systems, research platforms, and model distribution infrastructure.

   9. Validate that time source reliability is monitored for model development activities and backup time sources are available to ensure research continuity.

   10. Ensure all model-serving environments and pipelines synchronize with a reliable time source.

   11. Verify timestamp alignment across model logs, inference requests, and security logs.

   12. Check whether clock sync mechanisms are included in deployment templates.

   13. Review system logs for anomalies due to clock mismatches during model training or serving.

   14. Confirm configuration compliance for time synchronization policies.

   15. Assess whether timing discrepancies impact forensic reconstruction.

MDS: Model Security

MDS-01: Training Pipeline Security

Control Specification

Define, implement, and evaluate policies, procedures, and technical measures that ensure the security of the Training Pipeline. Regularly review and update policies, procedures and technical measures to address new security threats and best practices.

Auditing Guidelines for Cloud Service Providers (CSP)

1. Review security measures implemented to protect the CSP infrastructure used for AI model training pipelines.

2. Verify controls around data storage, access, and transit used in training. Assess the configuration of network security, including firewalls and intrusion detection/prevention systems protecting training environments.

3. Evaluate the physical security and environmental controls for the facilities where training infrastructure is housed. Verify the incident response procedures related to the training pipeline infrastructure. Evaluate how access control is maintained in the training environment.

4. Confirm regular reviews and updates of security measures and procedures.

MDS-02: Model Artifact Scanning

Control Specification

Define, implement, and evaluate policies, procedures, and technical measures for the scanning of model artifacts for vulnerabilities and attacks, at each step of the service lifecycle and at each hand over point. Regularly review and update policies, procedures and technical measures to address model artifact scanning.

Auditing Guidelines for Cloud Service Providers (CSP)

1. Examine security measures in place for storing model artifacts, including access controls and encryption.

2. Verify logging and monitoring of access to model artifacts.

3. Evaluate measures to prevent unauthorized modification or deletion of model artifacts.

4. Assess compliance with relevant data security standards and regulations.

5. Check procedures for secure transfer of model artifacts.

6. Verify backup and recovery procedures for model artifacts.

MDS-03: Model Documentation

Control Specification

Define, implement, enforce, approve, document, communicate, maintain and evaluate processes and procedures for model documentation. Regularly review and update the model documentation.

Auditing Guidelines for Cloud Service Providers (CSP)

1. Assess the CSP’s controls for storing and managing model documentation provided by customers or third parties.

2. Verify that documentation is accessible only to authorized personnel.

3. Review procedures for maintaining the integrity and confidentiality of model documentation.

4. Evaluate data retention policies related to model documentation.

5. Confirm that documentation is properly backed up and protected from loss or damage.

MDS-04: Model Documentation Requirements

Control Specification

Establish and implement baseline requirements for Model documentation.

Auditing Guidelines for Cloud Service Providers (CSP)

1. Verify that the CSP provides tools and capabilities to support customer’s model documentation requirements.

2. Assess the CSP’s documentation for how to securely manage and store model documentation.

3. Confirm that service agreements outline clear responsibilities for model documentation security.

MDS-05: Model Documentation Validation

Control Specification

Define, implement, and evaluate processes, procedures, and technical measures for the validation of the Model documentation aligned with the current model.

Auditing Guidelines for Cloud Service Providers (CSP)

1. Assess the CSP’s processes for ensuring integrity and validation of the models’ documentation.

2. Examine validation mechanisms in place and whether they align with the security protocols implemented by the organization.

3. Ensure all documentation is consistently updated to address any data changes.

MDS-06: Adversarial Attack Analysis

Control Specification

Define, implement, and evaluate processes and technical measures to assess adversarial threats specific to each AI model.

Auditing Guidelines for Cloud Service Providers (CSP)

1. Review network security controls in place to protect hosted AI models from adversarial attacks.

2. Assess intrusion detection and prevention systems specific to detecting AI-related attacks.

3. Verify logging and monitoring of network traffic for suspicious activity related to model interaction.

4. Evaluate security measures to protect APIs used for accessing hosted models.

5. Assess procedures for incident response to detected adversarial attacks.

6. Review procedures for patching vulnerabilities related to adversarial attacks.

MDS-07: Robustness against Adversarial Attack / Model Hardening

Control Specification

Define, implement, and evaluate processes, procedures, and technical measures for Model Hardening to mitigate relevant adversarial attacks as identified in the Threat Analysis and Adversarial Threat Analysis.

Auditing Guidelines for Cloud Service Providers (CSP)

1. Examine the CSP’s service-level protections that complement model hardening, such as input validation, rate limiting, and anomaly detection at the infrastructure level.

2. Assess monitoring mechanisms detect potential adversarial attacks on hosted models.

3. Verify documentation of how CSP infrastructure supports customer’s model hardening strategies.

4. Review the process for testing and validating the effectiveness of infrastructure-level defenses.

MDS-08: Model Integrity Checks

Control Specification

Regularly calculate and compare checksums using cryptographic hashes of model checkpoints to detect unauthorized modifications. Apply at least annually based on the level of risk, or after any change of hands.

Auditing Guidelines for Cloud Service Providers (CSP)

1. Verify implementation of data integrity monitoring for stored models, using checksums or other methods.

2. Assess procedures for detecting unauthorized modifications to stored model files.

3. Confirm procedures for alerting and responding to integrity check failures.

4. Verify the frequency of integrity checks aligns with the level of risk.

5. Examine mechanisms to ensure data is protected against tampering and potential security vulnerabilities.

MDS-09: Model Signing/Ownership Verification

Control Specification

Sign models cryptographically and verify signatures to ensure model provenance and ownership, any time the model changes hands or is loaded from storage.

Auditing Guidelines for Cloud Service Providers (CSP)

1. Review the mechanisms the CSP provides to support customer’s model signing and ownership verification. If the CSP offers key management services, assess the security controls for managing cryptographic keys.

2. Evaluate how the CSP verifies the validity of digital signatures on models being hosted.

3. Confirm that the CSP’s documentation details how customers can verify the provenance and ownership of their models.

MDS-10: Model Continuous Monitoring

Control Specification

Define, implement, and evaluate processes, procedures, and technical measures for continuous monitoring of model performance metrics over time to identify sudden shifts or unexpected changes in predictions that could degrade model performance.

Auditing Guidelines for Cloud Service Providers (CSP)

1. Examine the CSP’s infrastructure monitoring systems and how they track resource utilization related to hosted AI models.

2. Verify the alerting mechanisms for detecting anomalies in resource consumption or performance that could indicate issues.

3. Assess integration of monitoring data with incident response processes.

4. Examine if the infrastructure ensures the model has high-quality data that does not cause data poisoning.

MDS-11: Model Failure

Control Specification

Perform a risk-based evaluation of the model and model serving infrastructure for model failure. Define and implement measures to mitigate model and model serving infrastructure failures, and regularly evaluate throughout the AI system’s lifecycle.

Auditing Guidelines for Cloud Service Providers (CSP)

1. Review CSP’s infrastructure resilience and high-availability measures for hosting AI models.

2. Assess failover mechanisms that ensure model availability during infrastructure failures.

3. Verify documentation of redundancy architecture and recovery procedures.

4. Confirm that redundancy implementation aligns with service level agreements and business continuity requirements. Verify that redundant implementations don’t contribute to data poisoning or model theft.

MDS-12: Open Model Risk Assessment

Control Specification

Establish a process to evaluate risk associated with open models. Periodically review these risk factors, and implement a process to monitor and mitigate any determined vulnerabilities.

Auditing Guidelines for Cloud Service Providers (CSP)

1. Verify that the CSP offers infrastructure security measures to protect open weight models from unauthorized access.

2. Review processes conducted when integrating open weight models into service offerings, regarding the potential security flaws.

3. Assess the monitoring of potential vulnerabilities as part of the CSP integration security testing.

4. Confirm CSP security requirements comply with any security rules and guidance from the government or industry regulation.

MDS-13: Secure Model Format

Control Specification

Adopt secure model formats and processes for AI model serialization where applicable.

Auditing Guidelines for Cloud Service Providers (CSP)

1. Verify the CSP’s processes ensure that the models’ security during transfer, storage, and deployment, for customer’s use.

2. Assess security measures applied to secure formats during deployment and transit from the source of the models.

3. Examine encryption protocols, access controls, and data integrity checks and if they’re adequately secured.

SEF: Security Incident Management, E-Discovery, & Cloud Forensics

SEF-01: Security Incident Management Policy and Procedures

Control Specification

Establish, document, approve, communicate, apply, evaluate and maintain policies and procedures for Security Incident Management, E-Discovery, and Forensics. Review and update the policies and procedures at least annually, or upon significant changes.

Auditing Guidelines for Cloud Service Providers (CSP)

1. Verify the Cloud Service Provider (CSP) has a documented and approved security incident management policy, aligned with recognized industry standards such as NIST SP 800-61, NIST 800-201 or ISO/IEC 27035.

2. Ensure the Cloud Service Provider (CSP) has procedures for E-Discovery and Forensics. Including deployment, operations and cloud consumers.

3. Confirm that roles and responsibilities for incident detection, reporting, escalation, and resolution are clearly defined and documented.

4. Check that procedures cover the full incident lifecycle, including initial reporting, triage, escalation criteria, containment, eradication, recovery, and post-incident review.

5. Ensure that the policy and procedures are communicated effectively to all internal and external stakeholders, including third-party service providers, where applicable.

6. Verify that the incident management policy and related procedures are reviewed and updated periodically, or following major incidents, organizational changes, or regulatory updates.

7. Confirm that regular training is provided to incident response teams, with materials updated based on emerging threats and lessons learned.

8. Validate that incident response drills or tabletop exercises are conducted regularly, with documentation of scenarios, participants, outcomes, and improvement actions.

From CCM v4.1:

1. Examine policy for adequacy, approval, communication, and effectiveness as applicable to planning, delivery and support of the organization’s Security Incident Management, E-Discovery and Cloud Forensics.

2. Examine policy and procedures for evidence of review at least annually.

SEF-02: Service Management Policy and Procedures

Control Specification

Establish, document, approve, communicate, apply, evaluate and maintain policies and procedures for the timely management of security incidents. Review and update the policies and procedures at least annually, or upon significant changes.

Auditing Guidelines for Cloud Service Providers (CSP)

1. Confirm the AP has documented policies and procedures to ensure timely response of incidents.

2. Verify timely management expectations have been established and are based on business needs (e.g., regulations, contracts, incident severity level, ability to retrieve cloud data).

3. Review dependencies and partners which could impact the ability of the CSP to respond to the planned timelines

4. Confirm regular audits of service management effectiveness and timely response to incidents.

5. Validate audit findings and lessons learned are addressed.

6. Verify documented training provided for service management procedures.

From CCM v4.1:

1. Examine the policy for adequacy, approval, communication, and effectiveness as applicable to planning, delivery and support of the organization’s Security Incident Management, with respect to timely management.

2. Examine the policy and procedures for evidence of review at least annually.

SEF-03: Incident Response Plans

Control Specification

Establish, document, approve, communicate, apply, evaluate and maintain a security incident response plan, which includes but is not limited to: a communication strategy for notifying relevant internal departments, impacted service customers, and other business critical relationships (such as supply-chain) that may be impacted.

Auditing Guidelines for Cloud Service Providers (CSP)

1. Verify the CSP has incident response plans clearly documented and approved.

2. Confirm incident response plans cover critical scenarios for executing cloud services comprehensively.

3. Check plans define specific roles and escalation procedures.

4. Verify the incident response plan includes a documented communication strategy for notifying internal teams, affected service customers, and critical third-party partners (e.g., infrastructure providers, managed services) during security incidents.

5. Ensure regular reviews and updates of incident response documentation.

6. Confirm testing and drills of incident response plans performed periodically.

7. Verify documented corrective actions following response plan testing.

From CCM v4.1:

1. Examine the policy for adequacy, approval, communication, and effectiveness as applicable to planning, delivery and support of the organization’s Security Incident Management, with respect to timely management.

2. Examine the processes to identify impacted stakeholders.

3. Determine if this plan meets stakeholder requirements.

SEF-04: Incident Response Testing

Control Specification

Exercise the incident response plans at planned intervals or upon significant changes.

Auditing Guidelines for Cloud Service Providers (CSP)

1. Confirm the CSP conducts scheduled incident response exercises or triggers them upon significant changes to infrastructure, service architecture, or threat conditions.

2. Validate that exercises are logged with full detail (e.g., simulated threat, scope, stakeholder roles, timelines).

3. Confirm exercises evaluate ability to coordinate response across globally distributed infrastructure and customer segments.

4. Ensure corrective actions from exercises are tracked and reviewed for timely resolution.

5. Verify that participants from operations, engineering, security, and customer support are engaged.

6. Validate scenarios include cloud-native incidents (e.g., IAM misconfiguration, control-plane compromise).

7. Confirm findings are fed back into policy and documentation updates, with governance signoff where required.

From CCM v4.1:

1. Verify if there is a calendar of exercises available, if exercises are performed at planned intervals and when there are significant changes within the organization or the context in which it operates.

2. Verify if the organization has reviewed and acted upon the results of its exercising and testing to implement changes and improvements.

SEF-05: Incident Response Metrics

Control Specification

Establish, monitor and report information security incident metrics.

Auditing Guidelines for Cloud Service Providers (CSP)

1. Verify CSP has documented metrics for evaluating incident response effectiveness.

2. Confirm metrics align with cloud service level agreements, organizational goals and industry best practices (e.g., Cloud Mean Time to Detect (CMTTD), Cloud Alert Fidelity (true positives from AWS GuardDuty, Auzre Defender), Anomalous Behavior Detection Rate).

3. Check regular collection, analysis, and reporting of response metrics.

4. Ensure documentation of actions taken based on metrics analysis.

5. Confirm clear accountability for monitoring incident response metrics.

From CCM v4.1:

1. Verify that metrics have been established to measure information security incidents.

2. Verify that metrics together demonstrate the efficacy, effectiveness and success of the information security incident response plan to address incidents as they happen.

3. Verify that the metrics are measured and reported to stakeholders.

SEF-06: Event Triage Processes

Control Specification

Define, implement and evaluate processes, procedures and technical measures supporting business processes to triage security-related events.

Auditing Guidelines for Cloud Service Providers (CSP)

1. Verify CSP has documented triage procedures clearly define event categorization and prioritization.

2. Confirm triage processes efficiently differentiate between critical and non-critical events for the cloud solution.

3. Confirm design supports information collection to support triage (e.g., AWS Cloud Trails, AWS Cloud Watch, Microsoft Cloud Defender).

4. Understand triage models from suppliers and partners (e.g., OSP, AP, MP, AIC).

5. Check regular training provided on event triage methods.

6. Ensure continuous improvement through periodic review and update of triage processes.

7. Confirm clear accountability assigned for triaging security events.

From CCM v4.1:

1. Verify if operational processes that help the organization to prepare for, identify, detect, protect, respond to and recover from information security incidents in a step-by-step manner exist.

2. Verify if tools that support these organizational procedures to triage security related events complement the ability of the teams to detect, review, monitor and quickly decide upon the context and the possible impact of the incident as it happens and over time.

SEF-07: Incident Management and Response

Control Specification

Define, implement and evaluate processes, procedures and technical measures for timely and effective response to security incidents in accordance with incident categories and severity levels. Review, update, and test processes and procedures at least annually.

Auditing Guidelines for Cloud Service Providers (CSP)

1. Verify incident response categories and severity levels clearly documented (e.g, consider impacts to instance, region, single or multi-tenant).

2. Verify approaches for automatic detection and response, including technical measures such as data recovery, backups, containment actions, employee notification in case of data leakage, and regulatory reporting requirements.

3. Confirm well-defined roles and escalation pathways during incident response.

4. Check documented incident response timelines and service level agreements (SLAs).

5. Ensure regular reviews of incident response activities and outcomes.

6. Verify clear accountability documented for incident handling.

7. Confirm training provided to relevant stakeholders on incident response processes.

From CCM v4.1:

1. Confirm critical roles, responsibilities, communication protocols, and escalation paths specific to incident response are clearly assigned, and that documentation is accessible to relevant personnel even during a network outage or other incident-induced disruptions.

2. Validate the documentation incorporates necessary technical measures that support specific incident types and response phases.

3. Assess the actual incident handling consistently adheres to documented procedures, including consistent application of incident specificity and classification criteria.

4. Confirm that incidents are effectively contained, threats eradicated, and services restored without recurrence, and that root causes are addressed to prevent similar incidents.

5. Assess whether internal and external communications during incidents are timely, accurate, and aligned with the documented communication plan.

6. Determine if a formal system exists for tracking, assigning responsibility, and ensuring the timely completion of corrective and preventative actions identified in PIRs and exercises, and that these actions drive strategic improvements to security controls or IR capabilities.

7. Verify mechanisms exist for incident responders to provide feedback on the practicality and effectiveness of procedures and tools, and that this feedback is systematically reviewed and incorporated into updates.

8. Confirm the incident response program undergoes a holistic annual review and testing (e.g., via tabletop exercises or simulations) against current threats, organizational changes, regulatory updates, and past incident/test results, leading to substantive updates to the IRP and procedures that are communicated to the IR team, involving all relevant stakeholders.

SEF-08: Security Breach Notification

Control Specification

Define and implement processes, procedures and technical measures for security breach notifications. Report material security breaches including any relevant supply chain breaches, as per applicable SLAs, laws and regulations.

Auditing Guidelines for Cloud Service Providers (CSP)

1. Verify CSP documented policies clearly specify requirements for breach notification.

2. Ensure impacted parties are engaged.

3. Confirm procedures comply with applicable legal and regulatory requirements.

4. Confirm the notification procedure provides essential information (e.g., services impacted, instances impacted, regions impacted).

5. Ensure regular testing of breach notification procedures.

6. Ensure impacted parties are informed of breaches within defined SLA and appropriate actions are taken to reduce the impact of the breach.

From CCM v4.1:

1. Examine policy for adequacy, approval, communication, and effectiveness as applicable to planning, delivery and support of the organization’s Security Breach Notification management.

2. Verify if there is a formal program that documents the breach notification requirements for all regulatory or contractual domains that the organization asserts adherence to.

3. Verify if there is a periodic awareness program to ensure all those associated with information security incident response are aware of the procedures involved for their roles, responsibilities and authorities.

4. Determine if the organization has established breach notification Time Objectives for information security breaches that meet the minimum expectation of the applicable regulation and verify if those time objectives are reflected in all internal and external service level expectations.

SEF-09: Incident Records Management

Control Specification

Establish and maintain a secure repository of security incident records. Regularly review the incident records to identify patterns, root causes, and systemic vulnerabilities, and implement relevant corrective measures.

Auditing Guidelines for Cloud Service Providers (CSP)

1. Verify the Cloud Service Provider (CSP) has documented policies that clearly specify requirements for collecting, classifying, storing, protecting and retaining incident records related to cloud infrastructure and platform services supporting AI workloads.

2. Verify the policies define clear trigger conditions for when security incidents must be recorded, including incidents arising from unauthorized access, misconfigured cloud resources, data exposure, service outages or platform level security events.

3. Confirm the CSP maintains a secure incident record repository with appropriate access controls, encryption (in transit and at rest) and audit logging to prevent unauthorized access, modification or deletion.

4. Determine whether the CSP conducts periodic reviews of incident records to identify recurring patterns, root causes and systemic vulnerabilities (e.g. misconfigured identity or network controls, insecure default configurations, logging gaps, shared tenancy risks or availability failures) and whether the review cadence and review process are formally documented.

5. Confirm corrective actions identified through incident record analysis are documented, tracked, implemented and verified for effectiveness in addressing the identified issues.

6. Ensure records of reviews and corrective actions are retained and available for audit.

From CCM v4.1:

1. Examine the organization’s policy and procedures for maintaining security incident records to determine whether requirements for record collection, storage, protection, and retention are clearly defined.

2. Determine whether a secure incident record repository exists and whether appropriate access controls, encryption, and audit trails are implemented to prevent unauthorized access or tampering.

3. Determine whether the organization performs periodic reviews of incident records to identify recurring patterns, root causes, and systemic vulnerabilities, and whether the review schedule is documented.

4. Review evidence of corrective measures taken in response to insights from incident record reviews, and confirm that these actions are tracked and aligned with the issues identified during the analysis.

SEF-10: Points of Contact Maintenance

Control Specification

Maintain points of contact for applicable regulation authorities, national and local law enforcement, and other legal jurisdictional authorities. Review and update the points of contact at least annually.

Auditing Guidelines for Cloud Service Providers (CSP)

1. Verify documented procedures for Cloud Service Provider (CSP) to meet regulatory responsibilities and maintain points of contact.

2. Verify procedures for review of dependencies with OSP, MP, AIC and AP that would impact the Application Provider’s ability to meet its regulatory contact obligations (e.g., GDPR, CIRCIA, NIS2, nation CSIRTs).

3. Confirm regular updates and validation of points of contact.

4. Check records clearly document responsibility for points of contact maintenance.

5. Ensure immediate updates to contact information upon role changes.

6. Confirm periodic audits validating the accuracy and availability of contacts.

From CCM v4.1:

1. Examine the process used to determine applicable points of contact, and the procedure for reviewing the list/documentation that contains them.

2. Verify if the organization has updated the list of points of contact for applicable regulation authorities, national and local law enforcement, and other legal jurisdictional authorities.

3. Examine when the last updates were done and if there is a schedule for reviewing and updating these contacts.

STA: Supply Chain Management, Transparency, and Accountability

STA-01: Supply Chain Risk Management Policies and Procedures

Control Specification

Establish, document, approve, communicate, apply, evaluate, and maintain policies and procedures for supply chain risk management. Review and update the policies and procedures at least annually, or upon significant changes.

Auditing Guidelines for Cloud Service Providers (CSP)

1. Ensure GPU sourcing, model deployment layers, and marketplace vendors are covered.

2. Validate sign-offs by risk/compliance leads.

3. Inspect internal SOPs and published transparency reports, to verify communication to internal and external stakeholders.

4. Review onboarding and vetting workflows for open-source, ML libraries, hardware vendors, to specify the implementation depth.

5. Request sample SBOMs, risk scorecards, or breach history logs, to check the supplier risk evaluation.

6. Verify the most recent update and trigger events for policy review (e.g., breach, new partner).

7. Check that the policy aligns with recognized cloud security and supply chain risk management standards and applicable regulations.

8. Verify that monitoring metrics or internal/external audits are performed periodically to evaluate policy effectiveness.

From CCM v4.1:

1. Confirm that supply chain risk management policies and procedures are formally established to address supply chain related risks.

2. Ensure that these policies are clearly documented, and accessible to relevant personnel.

3. Check that the policies are reviewed and approved.

4. Verify that the policies are communicated to relevant stakeholders.

5. Assess whether the policies are consistently applied across supply chain processes.

6. Evaluate the effectiveness of supply chain risk management policies and procedures. 7.Ensure that the policies are reviewed and updated at least annually or after significant changes, with updates communicated to all stakeholders.

STA-02: SSRM Policy and Procedures

Control Specification

Establish, document, approve, communicate, apply, evaluate and maintain policies and procedures for the application of the Shared Security Responsibility Model (SSRM) within the organization. Review and update the policies and procedures at least annually, or upon significant changes.

Auditing Guidelines for Cloud Service Providers (CSP)

1. Verify that the CSP has established and documented policies and procedures in the domain of Supply Chain Management that define organizational and technical measures to protect infrastructure and services against third‑party risks, threats, and vulnerabilities (e.g., hardware vendors, hypervisors, datacenter operators).

2. Ensure that these policies explicitly define and apply the SSRM, clearly demarcating responsibilities between CSP‑managed and customer‑managed security controls.

3. Confirm that the SSRM explicitly addresses infrastructure layers, virtualization security, multi-tenancy isolation, and controls relevant to AI workloads.

4. Inspect whether SSRM policies and procedures are compliant with relevant cloud security standards (e.g., ISO/IEC 27017, CSA CCM) and applicable regulations.

5. Verify that SSRM policies are formally approved by authorized leadership and communicated clearly to customers (e.g., through trust center, contracts, SLA) and internal stakeholders.

6. Confirm consistent SSRM enforcement across all services, with defined and auditable controls for customer onboarding, offboarding, and third‑party integrations.

From CCM v4.1:

1. Examine policy for adequacy, approval, communication, currency, and effectiveness.

2. Examine policy and procedures for evidence of review at least annually.

STA-03: SSRM Supply Chain

Control Specification

Apply, document, implement and manage the SSRM throughout the supply chain.

Auditing Guidelines for Cloud Service Providers (CSP)

1. Confirm that the CSP publishes its SSRM in customer-facing materials, contracts, and service documentation, clearly outlining shared responsibilities for infrastructure, platform services, and security boundaries.

2. Assess how the CSP implements and governs inherited responsibilities from hardware vendors, third-party service integrations, or regional data center operators, and how these are incorporated into its own operational and security frameworks.

3. Review the CSP’s responsibility matrix, ensuring it clearly defines roles and obligations across the supply chain including hardware providers, orchestration layers, model developers, application providers, and customers to support transparency, accountability, and compliance.

From CCM v4.1:

1. Examine the policy for provisions related to service delivery.

2. Evaluate the process for communication of requirements and service levels to vendors and other third-parties.

3. Determine if a review of effectiveness is in place, especially with respect to contractual requirements.

STA-04: SSRM Guidance

Control Specification

Provide SSRM Guidance to the service customers detailing information about the SSRM applicability throughout the supply chain.

Auditing Guidelines for Cloud Service Providers (CSP)

1. Confirm the cloud service provider (CSP) publishes clear and accessible SSRM guidance for service customers, outlining shared responsibilities across infrastructure, platform services, and integrated AI workloads.

2. Review the CSP’s public documentation, trust center, or support resources for detailed descriptions of service customer responsibilities such as configuring identity and access management (IAM), securing data at rest and in transit, managing virtual networks, and monitoring cloud resource usage.

3. Evaluate whether the SSRM guidance covers critical infrastructure-layer risks, including but not limited to: data residency and encryption; availability zones and failover strategies; tenant isolation and shared resource segmentation; logging, telemetry, and service customer monitoring interfaces. Confirm that these responsibilities are clearly delineated between CSP and AIC in documentation and contractual materials.

From CCM v4.1:

1. Examine whether SSRM guidance documentation has been approved by management and communicated to CSCs.

2. Examine the process for review of SSRM Guidance if required. (Note: This control applies to an Organization that is in the role of a CSP).

STA-05: SSRM Control Ownership

Control Specification

Delineate the shared ownership and applicability of all CSA AICM controls according to the SSRM.

Auditing Guidelines for Cloud Service Providers (CSP)

1. Confirm the Cloud Service Provider (CSP) has mapped all CSA AICM controls to its internal framework, identifying which are CSP-owned, inherited (e.g., from hardware vendors or MP), or customer-owned (AIC), with clear documentation.

2. Review the mapping using SSRM guidance to ensure accuracy. Validate ownership assumptions, resolve gaps (e.g., unclear responsibility for data retention), and update regularly.

From CCM v4.1:

1. Examine the policy for assessing, demarcating, and documenting the interfaces at the edges of the organization’s responsibility.

2. Determine if the delineation has been done, and is current.

3. Examine the process for communicating the security responsibility boundaries to third-parties.

STA-06: SSRM Documentation Review

Control Specification

Review and validate the SSRM documentation.

Auditing Guidelines for Cloud Service Providers (CSP)

1. Confirm the Cloud Service Provider (CSP) has a process to regularly review its own SSRM documentation and that of key suppliers (e.g., hardware vendors, colocation providers), ensuring shared responsibilities are clearly defined and current by updating its matrix to reflect infrastructure-layer responsibilities such as physical security, virtualization, and network segmentation.

2. Verify these reviews are conducted at least annually or when major service changes occur (e.g., new data center deployments, platform upgrades), ensuring the SSRM reflects changes in control ownership, data handling, and operational responsibilities.

From CCM v4.1:

1. Examine the policy for assessing, demarcating, and documenting the interfaces at the edges of the Organization’s responsibility.

2. Examine the process for validating the boundaries for cloud services used.

3. Examine the process for validating the seamlessness of controls for cloud services used.

(Note: This control applies to an Organization that is in the role of a CSC).

STA-07: SSRM Control Implementation

Control Specification

Implement, operate, and audit or assess the portions of the SSRM which the organization is responsible for.

Auditing Guidelines for Cloud Service Providers (CSP)

1. Verify through third-party audit reports (e.g., SOC 2, ISO 27001) that the CSP implements, operates, and assesses its assigned SSRM controls such as physical security, hypervisor security, and infrastructure patch management ensuring these are tested and validated by independent assessors.

2. Review the CSP’s shared responsibility matrix and supporting evidence (e.g., compliance mappings, control test results) to confirm that the CSP is actively managing its responsibilities and that these align with the AP’s SSRM expectations.

From CCM v4.1:

1. Examine the policy related to addressing security in third-party agreements and determine if organizations employ formal contracts.

2. Determine if written procedures exist for addressing security in third-party agreements and whether or not the procedure(s) address(es) each element of the policy/control requirement(s) stipulated in the policy level.

3. Examine relevant documentation, observe relevant processes, and/or interview the control owner(s), and/or relevant stakeholders, as needed, for addressing security in third-party agreements and determine if the policy/control requirements stipulated in the policy level have been implemented.

4. Examine measure(s) that evaluate(s) the organization’s compliance with the third-party management policy and determine if the measure(s) address(es) implementation of the policy/control requirement(s) as stipulated in the policy level.

STA-08: Supply Chain Inventory

Control Specification

Develop and maintain an inventory of all supply chain relationships.

Auditing Guidelines for Cloud Service Providers (CSP)

1. Confirm that the cloud service provider maintains a centralized and up-to-date inventory of all third-party service and infrastructure relationships that support its cloud offerings.

2. Verify that the CSP documents all integrated service relationships across compute, storage, networking, platform services, and external dependencies.

3. Determine whether the inventory is subject to regular review and validation to ensure its completeness, accuracy, and alignment with current operational, security, and compliance requirements.

From CCM v4.1:

1. Determine if there is an inventory maintained of all supply chain relationships.

2. Establish ownership for maintaining this inventory.

3. Examine the inventory’s records to establish whether CSP/CSC relationships are maintained in this inventory.

4. Determine whether this inventory is subject to review.

STA-09: Service Bill of Material (BOM)

Control Specification

Define, implement, and enforce a process for establishing a Bill of Material for the service supply chain. Review and update the Bill of Material at least annually, or upon significant changes.

Auditing Guidelines for Cloud Service Providers (CSP)

1. Verify the cloud service provider (CSP) has a documented SBoM process, with regular reviews triggered by infrastructure or security changes.

2. Check that the SBoM defines all key components, including APIs, versions, scaling, dependencies, security controls, and risk classifications with relevant metadata.

3. Ensure the SBoM includes both cloud and AI-specific elements, such as compute, networking, model endpoints, and monitoring.

4. Confirm the SBoM is securely stored with role-based access for authorized stakeholders, including cloud security teams.

5. Verify timely SBoM updates after changes, with documented impact assessments reviewed by cloud security providers.

6. Check that SBoM details are clearly communicated, including service capabilities, SLAs, limitations, and integration protocols, with validated security disclosures.

From CCM v4.1:

1. Confirm that a process is defined for creating and maintaining a Bill of Material (BoM) for the service supply chain.

2. Ensure the BoM is clearly documented, and accessible to relevant stakeholders.

3. Check that the BoM process is approved by appropriate management and integrated into supply chain and service management workflows.

4. Evaluate if the BoM is consistently applied and enforced across relevant processes.

5. Ensure the BoM is reviewed and updated at least annually or upon significant changes, with updates communicated to all stakeholders.

STA-10: Supply Chain Risk Management

Control Specification

Periodically review risk factors associated with supply chain relationships.

Auditing Guidelines for Cloud Service Providers (CSP)

1. Verify the CSP conducts regular reviews of supply chain risks at least annually or after significant changes addressing operational, security, compliance, and reputational risks, such as onboarding a new infrastructure vendor or changes in data residency laws.

2. Confirm risk assessments are documented, kept up to date, and informed by indicators like SLA violations, security incidents, or audit findings (e.g., repeated downtime from a storage provider or failure to meet encryption standards while involving relevant internal teams).

3. Ensure that identified risks lead to mitigation actions such as revising third-party agreements, enhancing monitoring controls, or replacing non-compliant vendors and that these actions are tracked and supported by audit-ready documentation, especially when risks impact service availability or regulatory compliance.

From CCM v4.1:

1. Examine the policy related to identification of risks related to external parties and determine if the organization conducts due diligence of the external party.

2. Determine if the policy/control requirements stipulated in the policy level have been implemented.

3. Determine the periodicity of review of risk factors.

STA-11: Primary Service and Contractual Agreement

Control Specification

Service agreements must incorporate at least the following mutually-agreed upon provisions and/or terms: • Scope, characteristics and location of business relationship and services offered • Information security requirements (including SSRM) • Change management process • Logging and monitoring capability • Incident management and communication procedures • Right to audit and third party assessment • Service termination • Interoperability and portability requirements • Data privacy • Operational Resilience

Auditing Guidelines for Cloud Service Providers (CSP)

1. Verify that the CSP’s third-party contracts include key provisions covering service scope, SSRM-aligned security, change management, monitoring, incident response, audit rights, termination, interoperability, and data privacy and operational resilience.

2. Assess whether the cloud service provider (CSP) regularly reviews and updates third-party agreements to reflect evolving security standards, regulatory requirements, and operational changes, and ensures that third parties remain compliant through audits or performance evaluations.

From CCM v4.1:

1. Examine the policy for inclusion of the Control in third party agreements.

2. Examine the policy related to the review of third-party services to determine if the organization incorporates compliance by third parties.

STA-12: Supply Chain Agreement Review

Control Specification

Review supply chain agreements at least annually, or upon significant changes.

Auditing Guidelines for Cloud Service Providers (CSP)

1. Verify whether the cloud service provider (CSP) reviews key supply chain partners such as model providers, application providers, orchestrated service providers, data and hardware vendors, infrastructure operators, and integrators at least annually or following major changes in services, risk, or regulations.

2. Verify that review outcomes are documented, and that identified risks or gaps are addressed through updated contracts, mitigation actions, or vendor reassessments, with oversight from governance or risk teams.

From CCM v4.1:

1. Determine if a documented review schedule of CSP-CSC supply chain agreements exists on an annual basis and is operating.

2. Examine the organization’s implementation of its third-party management policy.

STA-13: Supply Chain Compliance Assessment

Control Specification

Define and implement a process for conducting internal assessments to confirm conformance and effectiveness of standards, policies, procedures, and service level agreement activities at least annually.

Auditing Guidelines for Cloud Service Providers (CSP)

1. Verify whether the Cloud Service Provider has a recurring, structured audit process to evaluate governance across cloud infrastructure, data storage, compute services, virtualization, and AI workload support (e.g., container orchestration, GPU provisioning, serverless functions).

2. Review audit documentation for issues such as misconfigured access controls, data residency violations, service availability risks, or insecure APIs. Confirm that corrective actions are tracked, resolved promptly, and aligned with cloud security standards, regulatory requirements, and internal policies.

3. Determine whether audit results are shared with relevant teams, such as cloud operations, compliance, and security, and that a feedback mechanism is in place to continuously improve audit effectiveness and ensure responsible cloud service delivery.

From CCM v4.1:

1. Examine the process for determining the standards and policy that service level agreements must conform to.

2. Examine the process to determine contractual, legal, and technical requirements applicable to service level agreements.

3. Determine if internal assessments are defined, planned, and executed, at least annually.

STA-14: Supply Chain Service Agreement Compliance

Control Specification

Implement policies requiring all service providers throughout the supply chain to comply with information security, confidentiality, access control, privacy, audit, personnel policy and service level requirements and standards.

Auditing Guidelines for Cloud Service Providers (CSP)

1. Assess whether the CSP has established a formal policy or framework for integrating security, compliance, and governance requirements into contractual agreements across its supply chain, including subcontractors and technology partners.

2. Verify that these requirements are consistently reflected in executed contracts with third parties. This includes provisions related to data protection, regulatory compliance, service availability, and incident response.

3. Evaluate whether the CSP retains the contractual right to audit or assess its supply chain partners where necessary. This should include the ability to verify compliance with agreed-upon controls and to address risks related to data security, service continuity, and regulatory obligations.

From CCM v4.1:

1. Examine the policy for incorporation of requirements into contractual documents throughout the CSP’s supply chain.

2. Determine if requirements have been incorporated in contracts.

3. Evaluate if the right to audit is protected, where required.

STA-15: Supply Chain Governance Review

Control Specification

Review the organization’s service providers’ IT governance policies and procedures at least annually, or upon significant changes.

Auditing Guidelines for Cloud Service Providers (CSP)

1. Examine whether the cloud service provider has defined and implement a process for reviewing the governance practices of its supply chain partners, including third-party infrastructure providers, software vendors, and managed service providers.

2. Evaluate whether the CSP actively conducts these reviews at least annually, or upon significant changes, and maintains documented evidence that the review process is being followed in accordance with the established policy.

From CCM v4.1:

1. Examine the policy for review of supply chain partners governance of IT.

2. Determine if the right to review is incorporated contractually.

3. Evaluate whether such a review cycle is operating within the organization.

STA-16: Supply Chain Data Security Assessment

Control Specification

Define and implement a process for conducting risk-based security assessments of the supply chain.

Auditing Guidelines for Cloud Service Providers (CSP)

1. Verify the CSP has a formal process to assess supply chain data security, covering cloud infrastructure (e.g., IAM, virtualization) and AI components (e.g., GPU clusters, object storage, orchestration tools).

2. Investigate how the CSP addresses risks from third parties like hardware vendors (e.g., chipsets), software suppliers (e.g., container runtimes), and platforms supporting AI workloads (e.g., MLaaS).

3. Review procedures for managing risks from entities handling customer data (e.g., backup services) or supporting infrastructure (e.g., CDN, DNS).

4. Confirm regular security assessments are performed per policy, covering data confidentiality (e.g., encryption), infrastructure integrity (e.g., patching), and compliance (e.g., ISO 27001).

From CCM v4.1:

1. Examine the policy related to the security assessments of the supply chain.

2. Examine the policy related to identification of risks related to external parties.

3. Determine if procedures exist for identification of risks related to external parties

4. Evaluate evidence of the conduct of assessments of organizations within the supply chain, periodically as required by the policy.

TVM: Threat & Vulnerability Management

TVM-01: Threat and Vulnerability Management Policy and Procedures

Control Specification

Establish, document, approve, communicate, apply, evaluate and maintain policies and procedures to identify, report and prioritize the remediation of vulnerabilities and threats, in order to protect systems against vulnerability exploitation. Review and update the policies and procedures at least annually, or upon significant changes.

Auditing Guidelines for Cloud Service Providers (CSP)

1. Verify that the CSP has established and documented TVM policies and procedures defining scope, objectives, roles, and responsibilities.

2. Inspect whether the policies are compliant with regulatory requirements, industry best practices, and relevant threat scenarios.

3. Verify formal approval of the policies by authorized management.

4. Verify communication of the policies to all relevant stakeholders and their understanding.

5. Confirm that the policies are effectively applied in daily operations.

6. Verify that metrics are established and monitored to evaluate effectiveness and identify areas for improvement.

7. Inspect evidence that the policies are reviewed and updated at least annually or upon significant changes.

8. Verify that the TVM policy explicitly covers all layers of the cloud infrastructure — physical, hypervisor, network, and managed services.

9. Review the CSP’s public‑facing documentation (e.g., cloud security white papers, SOC 2 reports) describing vulnerability scanning, patching, and remediation practices.

10. Confirm that the CSP provides customers with tools, guidance, or best practices to help them manage vulnerabilities in their own cloud environments as part of the shared responsibility model.

11. Verify that policies and procedures include formalized mechanisms and dedicated communication channels for Vulnerability Disclosure activities.

From CCM v4.1:

1. Examine policy for adequacy, currency, communication, and effectiveness.

2. Examine policy and procedures for evidence of review at least annually.

TVM-02: Malware and Malicious Instructions Protection Policy and Procedures

Control Specification

Establish, document, approve, communicate, apply, evaluate and maintain policies and procedures to protect against malware and malicious instructions. Review and update the policies and procedures at least annually, or upon significant changes.

Auditing Guidelines for Cloud Service Providers (CSP)

1. Verify that the Cloud Service Provider (CSP) has established and documented policies and procedures in the domain of Malware Protection that—by defining organizational and technical measures to prevent, detect, examine and remove malicious codes from systems—aim at leading efforts to protect the latter against malware attacks. Ensure that the policies are documented in detail, covering scope, objectives, roles and responsibilities.

2. Inspect whether the above-mentioned policies and procedures are compliant with relevant regulatory requirements, industry best practices and the specific threat scenarios to which the organization is potentially exposed.

3. Verify that the above-mentioned policies and procedures have been formally approved by authorized parties (e.g., management sign-off).

4. Verify that the above-mentioned policies and procedures (in both their original and subsequent versions) have been adequately communicated by authorized parties to all relevant stakeholders and that their content has been thoroughly comprehended by them.

5. Confirm that the policy is concretely and appropriately applied by involved parties in their day-to-day operations.

6. Verify that metrics and Key Performance Indicators (KPIs) have been established and are continuously monitored to evaluate the effectiveness of the above-mentioned policies and procedures and identify possible improvement areas.

7. Inspect whether the above-mentioned policies and procedures are periodically reviewed and updated (at least annually) by responsible parties.

8. Verify the CSP has a multi-layered malware protection strategy for its infrastructure, including scanning of internal systems, network intrusion detection, and protection for managed services.

9. Review the CSP’s documentation on the security measures they take to protect the cloud environment from malware.

From CCM v4.1:

1. Examine policy for adequacy, currency, communication, and effectiveness.

2. Examine policy and procedures for evidence of review at least annually.

TVM-03: Vulnerability Identification

Control Specification

Define, implement and evaluate processes, procedures and technical measures for the detection of vulnerabilities on organizationally managed assets at least monthly.

Auditing Guidelines for Cloud Service Providers (CSP)

1. Verify that vulnerability detection measures (e.g., scanning, agent-based monitoring) are implemented across all organizationally managed assets, and that scans or detection activities occur at least monthly.

2. Inspect whether the above-mentioned policies, procedures and technical measures are compliant with relevant regulatory requirements and industry best practices.

3. Confirm that the above-mentioned policies, procedures and technical measures are concretely and appropriately applied by involved parties in their day-to-day operations.

4. Inspect whether the above-mentioned policies, procedures and technical measures are monitored against sets of efficacy and efficiency metrics / indicators.

5. Inspect whether the above-mentioned policies, procedures and technical measures are periodically reviewed and updated by responsible parties.

6. Review the CSP’s public documentation on their patching and vulnerability remediation timelines for their infrastructure and services.

7. Confirm the CSP has a well-defined process for emergency security updates across their global infrastructure.

From CCM v4.1:

1. Examine policy for adequacy, currency, and effectiveness.

2. Determine if technical measures are evaluated for effectiveness.

TVM-04: Threat Analysis and Modelling

Control Specification

Define, implement and evaluate threat analysis processes and procedures to identify, assess and review the threat landscape for Cloud and AI systems. Build threat models according to industry best practices to inform the risk mitigation strategy.

Auditing Guidelines for Cloud Service Providers (CSP)

1. Verify that the Cloud Service Provider (CSP) has defined processes, procedures, and technical measures to systematically identify threats to which AI systems and models are potentially exposed. Ensure that the processes are documented in detail, covering scope, objectives, roles and responsibilities.

2. Verify that processes, procedures, and technical measures are in place to systematically assess threats to AI systems and models previously identified.

3. Inspect whether the above-mentioned processes, procedures, and technical measures of threat analysis are compliant with relevant regulatory requirements and industry best practices.

4. Verify that countermeasures against identified threats are timely defined, prioritized, accordingly applied, monitored, reviewed and updated by relevant parties.

5. Inspect whether the above-mentioned processes, procedures, and technical measures of threat analysis are monitored against sets of efficacy and efficiency metrics / indicators.

6. Inspect whether the above-mentioned processes, procedures, and technical measures of threat analysis are periodically reviewed and updated by responsible parties.

From CCM v4.1:

1. Examine the documentation available for the threat analysis program to determine whether key process artifacts of the threat analysis activity, including inputs and outputs, have been documented and tracked to provide for clarity and traceability.

2. Determine whether processes for threat analysis and modelling are performed according to a defined, documented methodology that is structured, systematic, consistent, repeatable, and aligns with industry best practices.

3. Determine whether the implemented threat management methodology addresses threat analysis and modelling, including:

   • identification and characterization of the system

   • identification, analysis, and assessment of potential threats threat response, including:

   • prioritization of threat responses

   • determination and implementation of responses and countermeasures

   • review, validation, and monitoring of remediations

4. Review the documented scope of the threat analysis and modelling program as well as documentation of completed threat modelling activities to determine whether the systems, processes, and services included in the scopes cover all key, critical elements of the organization’s operations, products, and services.

5. Review records of an appropriate sample of systems or services for which threat analysis and modelling has been performed to confirm whether:

   • The scopes of systems and services covered in the threat analysis and modelling activities performed are clearly and precisely defined and documented.

   • all applicable objectives and requirements, including business objectives, security objectives, privacy objectives, safety objectives, and compliance objectives, are documented and reflected in the analyses.

   • The detail of in-scope systems and process elements includes sufficient decomposition and deconstruction of the scoped systems and processes to adequately support analysis. Examples of constituent components and elements that may be appropriate for system characterization include systems, connections, data stores, dataflows, transformation functions, trust boundaries, external services, controls, entities/actors, technologies, protocols, locations, and other pertinent elements to adequately inform the analysis.

6. Review the analytical framework(s) used for identifying and evaluating threats, and examine how threats and their potential threat vectors are enumerated, conceptualized, examined, and evaluated as part of the threat modelling process. Ensure that the topical and technology focuses are appropriate to the organization, services, and products covered and that any catalogues or taxonomies of threats used are similarly organizationally-relevant.

7. Review records and process documentation of the performance of threat analysis and modeling for systems and services analyzed to determine whether the threat analysis and modelling processes performed:

   • are commensurate in rigor to the criticality of the cloud service offering, organization size, industry, and regulatory or compliance requirements,

   • are sufficiently integrated into the development and operational lifecycles of the target system(s) or service(s) to ensure security-by-design and privacy-by-design,

   • identify relevant threat scenarios and perform scenario analysis against the system design to determine possible threat outcomes,

   • result in an informed assessment of risk for the identified unmitigated threats, including an evaluation of their likelihoods and impacts,

   • provide useful, actionable information for threat response.

8. Identify whether documentation and other operational evidence exists that demonstrates the threat model continues to be refined and improved as knowledge, needs, and capabilities grow and change and as the system evolves, in particular updated to remain current as the threat environment and technology environment changes.

TVM-05: Detection Updates

Control Specification

Define, implement and evaluate processes, procedures and technical measures to update detection tools, threat signatures, and indicators of compromise on a weekly, or more frequent basis.

Auditing Guidelines for Cloud Service Providers (CSP)

1. Verify that the Cloud Service Provider (CSP) has defined processes, procedures, and technical measures to update tools implemented to detect vulnerabilities, threat signatures and indicators of compromise within the security perimeter at least weekly. Ensure that the processes are documented in detail, covering scope, objectives, roles and responsibilities.

2. Verify that the above-mentioned processes, procedures, and technical measures are compliant with relevant regulatory requirements and industry best practices.

3. Confirm that the above-mentioned processes, procedures, and technical measures are concretely and appropriately applied by involved parties in their day-to-day operations.

4. Inspect whether the above-mentioned processes, procedures, and technical measures are monitored against sets of industry-standard efficacy and efficiency metrics / indicators.

5. Inspect whether the above-mentioned policies, procedures, and technical measures are periodically reviewed and updated by responsible parties.

6. Verify the CSP has a mature, automated process for continuously updating the threat signatures and detection rules across its vast infrastructure, using a combination of commercial, open-source, and proprietary threat intelligence.

From CCM v4.1:

1. Examine policy for adequacy, currency, and effectiveness.

2. Determine if technical measures are evaluated for effectiveness.

3. Determine if updates and reviews of indicators are conducted at least weekly.

TVM-06: External Library Vulnerabilities

Control Specification

Define, implement and evaluate processes, procedures and technical measures to identify updates for applications which use third party or open source libraries according to the organization’s vulnerability management policy.

Auditing Guidelines for Cloud Service Providers (CSP)

1. Verify that the Cloud Services Provider (CSP) has defined processes, procedures, and technical measures to identify and implement updates for applications that use third party or open source libraries, in order to mitigate risks of compromise associated with the exploitation of vulnerabilities within such libraries. Ensure that the processes are documented in detail, covering scope, objectives, roles and responsibilities.

2. Examine the above-mentioned processes, procedures, and technical measures to confirm their compliance with the organization’s vulnerability management policy, as well as with relevant regulatory requirements and industry best practices.

3. Confirm that the above-mentioned processes, procedures, and technical measures are concretely and appropriately applied by involved parties in their day-to-day operations.

4. Inspect whether the above-mentioned processes, procedures, and technical measures are monitored against sets of efficacy and efficiency metrics / indicators.

5. Inspect whether the above-mentioned processes, procedures, and technical measures are periodically reviewed and updated by responsible parties.

6. Verify the CSP is responsible for managing vulnerabilities in the external libraries used by their own managed cloud services.

7. Confirm the CSP provides tools (e.g., native SCA scanners) to help customers identify and manage vulnerabilities in the open-source libraries they use in their own applications deployed on the cloud.

From CCM v4.1:

1. Examine policy for adequacy, currency, and effectiveness.

2. Determine if a process exists to identify third-party libraries, and to evaluate their impact on the organization’s vulnerability management.

TVM-07: Penetration Testing

Control Specification

Define, implement and evaluate processes, procedures and technical measures for the periodic performance of penetration testing by independent third parties.

Auditing Guidelines for Cloud Service Providers (CSP)

1. Verify that the CSP has defined and documented processes, procedures, and technical measures for periodic penetration testing by independent third parties. Documentation must include scope, objectives, roles, and responsibilities.

2. Examine whether these processes comply with regulatory requirements and industry best practices.

3. Inspect alignment of the processes with the relevant threat scenarios specific to the CSP’s infrastructure.

4. Confirm that these processes are implemented and adhered to.

5. Verify that findings from penetration tests are reviewed and translated into concrete remediation actions.

6. Inspect whether metrics and indicators are monitored to evaluate the efficacy and efficiency of the penetration testing program.

7. Inspect evidence that the processes are reviewed and updated at least annually or upon significant changes.

8. Verify that the CSP has a formal, documented policy permitting customers to conduct penetration testing of their own workloads on the CSP platform, with clear processes for authorization and scoping.

9. Review the CSP’s own independent penetration testing reports and third‑party attestations (e.g., SOC 2 Type II, ISO 27001) covering its infrastructure and confirm they are kept current and made available to customers

From CCM v4.1:

1. Examine policy for adequacy, currency, and effectiveness.

2. Determine if the process for defining frequency of penetration testing is defined.

3. Determine if the process for selection of independent third parties is defined, and evaluated.

TVM-08: Vulnerability Remediation Schedule

Control Specification

Define, implement and evaluate processes, procedures and technical measures based on identified risks to support scheduled and emergency responses to vulnerability identification.

Auditing Guidelines for Cloud Service Providers (CSP)

1. Verify that the Cloud Service Provider (CSP) has defined processes, procedures, and technical measures to periodically (at least monthly) detect vulnerabilities on assets managed by the organization. Ensure that the processes are documented in detail, covering scope, objectives, roles and responsibilities.

2. Examine the above-mentioned processes, procedures, and technical measures to confirm their compliance with relevant regulatory requirements and industry best practices.

3. Confirm that the above-mentioned processes, procedures, and technical measures are concretely and appropriately implemented.

4. Inspect whether the above-mentioned processes, procedures, and technical measures are monitored against sets of efficacy and efficiency metrics / indicators.

5. Inspect whether the above-mentioned processes, procedures, and technical measures are periodically reviewed and updated by responsible parties.

From CCM v4.1:

1. Examine policy for adequacy, currency, and effectiveness.

2. Determine if vulnerability detection is undertaken as required, and at least monthly.

TVM-09: Vulnerability Prioritization

Control Specification

Use a risk-based method for effective prioritization of vulnerability remediation using an industry recognized framework.

Auditing Guidelines for Cloud Service Providers (CSP)

1. Verify that the Cloud Service Provider (CSP) systematically adopts a method to support efforts in effectively and efficiently prioritizing remediations to vulnerabilities identified within the security perimeter.

2. Examine the above-mentioned method to verify that it adopts of a risk-based approach.

3. Examine the above-mentioned method to verify its compliance with industry recognized standards and frameworks.

From CCM v4.1:

1. Examine policy and procedures related to prioritization of vulnerabilities detected.

2. Determine if an industry recognized or widely used framework is implemented.

3. Examine how the output of risk assessment of the vulnerabilities is used to inform prioritization of remediation.

4. Determine if the process is evaluated for effectiveness.

TVM-10: Threat Response

Control Specification

Use a risk-based method for the prioritization and mitigation of threats, leveraging an industry-recognized framework to guide threat decision-making and protection measures.

Auditing Guidelines for Cloud Service Providers (CSP)

1. Review threat modeling for infrastructure supporting AI workloads.

2. Validate CSP’s shared responsibility documentation for AI threat handling.

3. Evaluate services offered for AI threat detection (e.g., GuardDuty ML, Sentinel AI rules).

4. Check scoring and categorization logic for threats affecting AI deployments.

5. Assess incident response SLAs for AI-specific threats (e.g., data exfiltration from AI APIs).

6. Confirm existence of collaborative threat response mechanisms with AI customers.

From CCM v4.1:

1. Examine the documentation available for the threat response processes to verify whether key artifacts of the threat response activity, including inputs and outputs, have been documented and tracked to provide for clarity, traceability, and risk tracking.

2. Review the documented guidance and procedures for threat response processes to determine whether they:

   • include a risk-driven prioritization of threats that takes into account threat severities, organizational obligations and requirements, and realities of technical aspects (e.g., interdependencies, complexities).

   • provide for identification and selection of appropriate risk response strategies for each identified threat, and associated investigation and planning, including for technical mitigation strategies.

   • provide for validated implementation of risk responses for each threat and that the respective response results in a residual risk that is appropriate and acceptable for the organization’s risk appetite, risk tolerance, and organizational obligations and requirements.

3. Review artifacts of the performed threat response processes to determine whether the relevant identified threats associated with the organization’s cloud services are appropriately prioritized and addressed, and that associated mitigations are tested and validated for sufficiency and effectiveness.

4. Check for evidence that the organization’s risk models are revised and maintained throughout the development lifecycle to reflect the evolution of the system and its controls and are regularly updated throughout the operational lifecycle to remain current as the threat environment and technology environment changes.

TVM-11: Vulnerability Management Reporting

Control Specification

Define and implement a process for tracking and reporting vulnerability identification and remediation activities that includes stakeholder notification.

Auditing Guidelines for Cloud Service Providers (CSP)

1. Verify that the Cloud Service Provider (CSP) has defined a process to systematically document both the vulnerabilities identified within the security perimeter and the activities implemented to remediate them. Ensure that the process is documented in detail, covering scope, objectives, roles and responsibilities.

2. Examine the above-mentioned process to verify that it includes a notification phase to relevant stakeholders.

3. Confirm that the above-mentioned process is communicated and thoroughly comprehended by relevant parties.

4. Confirm that the above-mentioned process is concretely and appropriately implemented by responsible parties.

5. Inspect whether the above-mentioned process is monitored against sets of efficacy and efficiency metrics / indicators.

6. Inspect whether the above-mentioned process is periodically reviewed and updated by responsible parties.

From CCM v4.1:

1. Examine policy and procedures related to tracking and reporting of vulnerabilities.

2. Examine the process to identify stakeholders.

3. Determine if the process is implemented.

TVM-12: Vulnerability Management Metrics

Control Specification

Establish, monitor and report metrics for vulnerability identification and remediation at defined intervals.

Auditing Guidelines for Cloud Service Providers (CSP)

1. Verify that the Cloud Service Provider (CSP) has defined metrics and indicators for vulnerability identification and remediation at defined intervals.

2. Inspect whether the above-mentioned metrics and indicators are concretely and continuously monitored.

3. Inspect whether the above-mentioned metrics and indicators are periodically reviewed and updated by responsible parties.

4. Inspect whether the evidence emerged during the monitoring of the above-mentioned metrics and indicators is documented in appropriate executive and technical reports.

5. Inspect whether the above-mentioned reports are timely shared and actively discussed with all relevant parties to support decision making.

From CCM v4.1:

1. Verify that metrics have been established to measure vulnerabilities.

2. Examine the process for reporting metrics, including identification of recipients.

3. Determine if reports are sent at the defined intervals.

TVM-13: Guardrails

Control Specification

Define and implement processes, procedures and technical measures to apply guardrails to the AI system. Continuously evaluate guardrails for changes in regulatory requirements and risk scenarios.

Auditing Guidelines for Cloud Service Providers (CSP)

1. Verify that the Cloud Services Provider (CSP) has defined processes, procedures, and technical measures to apply guardrails to the AI system. Ensure that the processes are documented in detail, covering scope, objectives, roles and responsibilities.

2. Examine whether the above-mentioned processes, procedures, and technical measures are compliant with relevant regulatory requirements and industry best practices.

3. Confirm that the above-mentioned processes, procedures, and technical measures are concretely and appropriately implemented.

4. Inspect whether the above-mentioned processes, procedures, and technical measures are monitored against sets of efficacy and efficiency metrics / indicators.

5. Inspect whether the above-mentioned processes, procedures, and technical measures are periodically reviewed and updated by responsible parties.

UEM: Universal Endpoint Management

UEM-01: Endpoint Devices Policy and Procedures

Control Specification

Establish, document, approve, communicate, apply, evaluate and maintain policies and procedures for all endpoints. Review and update the policies and procedures at least annually, or upon significant changes.

Auditing Guidelines for Cloud Service Providers (CSP)

1. Verify documented, approved, communicated, and applied endpoint management policies covering internal corporate and production environments, BYOD, and third‑party devices. Ensure policies define scope, objectives, roles, responsibilities, approval workflows, and evidence of senior management oversight. Inspect for compliance with relevant standards and regulations (e.g., ISO/IEC 27001, CSA CCM).

2. Technical and Operational Provisions: Review policies for clear definitions of: endpoint inventory and ownership assignment; OS requirements and configuration management; approved services, applications, and compatibility matrices; encryption, anti‑malware, firewalls, DLP, remote wipe, and locate; privacy considerations for personal devices; and granular access controls and contractual SLA obligations for third‑party endpoints.

3. Application and Monitoring: Verify implementation evidence (inventories, logs, training, monitoring dashboards). Review certifications (e.g., ISO 27001, SOC 2) and reports for evidence of effectiveness. Confirm policy review cadence (at least annually or post‑change) and documented updates.

From CCM v4.1:

1. Examine policy for adequacy, currency, communication, and effectiveness.

2. Examine policy and procedures for evidence of review, at least annually.

UEM-02: Application and Service Approval

Control Specification

Define, document, apply and evaluate a list of approved services, applications and sources of applications (stores) acceptable for use by endpoints when accessing or storing organization-managed data.

Auditing Guidelines for Cloud Service Providers (CSP)

Irrespective of cloud service delivery model, the CSP is responsible for defining, documenting, applying, and evaluating a list of approved services, applications, and sources of applications (stores) acceptable for use by endpoints when accessing or storing organization-managed data.

Implementation best practices include (but not limited to):

1. Centralized Configuration: For managed endpoints, universally enforce policies through one or more centralized configuration management tools.

2. Unmanaged Endpoints Risk Management: Risk assessment should be conducted to determine what (if any) information or systems may be accessed or stored using unmanaged endpoints.

3. Approved Stores Usage: Approved sources (stores) for obtaining applications of only trusted vendor applications should be maintained, such as official app stores or internal repositories (e.g., Linux, Windows, macOS, Android, and iOS).

4. Unauthorized Stores Usage Exception: The installation of applications from unauthorized sources should be prohibited, unless a business need exists after following the organizational exceptions approval process/cycle.

From CCM 4.1:

1. Determine if a list of approved services, applications and sources of applications (stores) acceptable for use by endpoints when accessing or storing organization-managed data have been identified and documented.

2. Determine if the identified and documented list of approved services, applications and sources of applications (stores) acceptable for use by endpoints when accessing or storing organization-managed data have been enforced.

3. Examine how endpoints are monitored for unauthorized services and the process to remove or terminate use of non-sanctioned resources.

UEM-03: Compatibility

Control Specification

Define and implement a process for the validation of the endpoint device’s compatibility with operating systems and applications.

Auditing Guidelines for Cloud Service Providers (CSP)

1. Verify the CSP has documented and approved compatibility and configuration management policies, covering all endpoint types (internal, customer, third-party), including definitions of supported OS platforms and enforcement of consistent software baselines.

2. Confirm that compatibility validation is implemented through automated diagnostic tools, capable of identifying noncompliant endpoint configurations and triggering remedial actions (e.g., OS upgrade, patching) before granting network access.

3. Inspect whether the policy defines change control requirements for all configuration updates, including tracking of why, what, and how changes are made, and formal approval procedures.

4. Review implementation artifacts, such as compatibility test reports, tool outputs, OS standardization procedures, configuration baselines, and remediation logs.

5. Ensure misconfigured or outdated endpoints are detected and remediated proactively, with audit trails, automated enforcement mechanisms, and periodic policy review aligned to cloud security and operational requirements.

From CCM v4.1:

1. Examine the process for endpoint compatibility validation.

2. Determine if the process produces a published compatibility matrix.

UEM-04: Endpoint Inventory

Control Specification

Maintain an inventory of all endpoints used to store, access and process company data.

Auditing Guidelines for Cloud Service Providers (CSP)

1. Verify that the CSP has a documented and approved centralized endpoint inventory policy, covering all devices accessing or storing organizational data.

2. Confirm the use of automated discovery tools to detect and inventory all connected endpoints, including mobile and BYOD devices.

3. Inspect whether the inventory captures critical data such as network addresses, hardware identifiers, device names, asset owners, departments, and device authorization status.

4. Review implementation evidence including inventory reports, discovery tool logs, device approval processes, and decommissioning records for unauthorized devices.

5. Ensure the CSP regularly updates the inventory to reflect device changes, ownership, configuration updates, and software versions, with active enforcement of removal or quarantine for unauthorized endpoints.

From CCM v4.1:

1. Examine the asset register, with reference to endpoints.

2. Determine if endpoints that store and access company data are tagged and included in the asset inventory.

UEM-05: Endpoint Management

Control Specification

Define, implement and evaluate processes, procedures and technical measures to enforce policies and controls for all endpoints permitted to access systems and/or store, transmit, or process organizational data.

Auditing Guidelines for Cloud Service Providers (CSP)

1. Verify that the CSP has implemented technical measures to enforce endpoint management controls, including inventory, configuration, and access policies for devices accessing organizational systems.

2. Confirm that risk assessments are conducted to define acceptable endpoint types for system access or data storage, with compensating controls where needed.

3. Verify centralized configuration enforcement using standardized configuration management tools for managed endpoints.

4. Inspect whether the CSP enforces prevention of security control circumvention (e.g., jailbreaking, rooting) using technical detective and preventive controls integrated with centralized management systems.

5. Review hardening measures for unmanaged endpoints, including secure default configurations, encryption, disabling unnecessary services, and network segmentation to mitigate risks.

From CCM v4.1:

1. Examine procedures for adequacy, currency, communication, and effectiveness.

2. Determine the extent and applicability of the processes, procedures, and technical measures over applicable endpoints, as identified.

3. Examine policy and procedures for evidence of review, with respect to effectiveness.

UEM-06: Automatic Lock Screen

Control Specification

Configure all relevant interactive-use endpoints to require an automatic lock screen.

Auditing Guidelines for Cloud Service Providers (CSP)

1. Verify that the CSP enforces automatic lock screen settings to activate after a specified inactivity period, requiring reauthentication.

2. Confirm that inactivity timeout settings are consistently applied to all managed endpoints and aligned with security risk assessments.

3. Inspect whether authentication methods include strong passwords, biometrics, or passwordless mechanisms such as PINs or fingerprint recognition for unlocking endpoints.

4. Review implementation evidence such as endpoint configuration baselines, centralized policy enforcement logs, and compliance reports.

5. Ensure the lock screen settings are incorporated into broader endpoint management policies and cannot be bypassed by users.

From CCM v4.1:

1. Determine the organization’s definition of interactive-use endpoints.

2. Examine the processes and technical measures in place to enforce automatic lock screens.

UEM-07: Operating Systems

Control Specification

Manage changes to endpoint operating systems, patch levels, and/or applications through the company’s change management processes.

Auditing Guidelines for Cloud Service Providers (CSP)

1. Verify that the CSP has a documented Change and Patch Management Policy for customer‑facing and corporate endpoints, defining supported OS versions, patch cadence, and enforcement mechanisms.

2. Inspect the policy for formal governance, roles/responsibilities, approval processes, and scheduled policy reviews.

3. Confirm the policy mandates automated compatibility checks and remediation tooling (e.g., patch agents, OS upgrade scripts) before endpoint network access.

4. Verify that the policy requires testing patches/OS upgrades in isolated environments and integrates vulnerability scans into the change workflow.

5. Review system outputs (inventory data, automated diagnostic logs, patch/uninstall records, change‑approval tickets, and audit trails) to ensure endpoints comply with CSP’s OS management policy.

From CCM v4.1:

1. Examine the organization’s change management policy for controls related to changes on endpoints.

2. Determine if such controls are in place for making changes to production and infrastructure systems and if the controls are evaluated as effective.

UEM-08: Storage Encryption

Control Specification

Protect information from unauthorized disclosure on managed endpoint devices with storage encryption.

Auditing Guidelines for Cloud Service Providers (CSP)

1. Verify that the CSP has a documented Encryption Policy for endpoints, approved by governance, defining sensitivity tiers, supported encryption levels (file, full‑disk), and roles/responsibilities.

2. Inspect the policy to confirm use of industry‑standard algorithms and strong cryptography for all sensitive data, with key management procedures and allowable exceptions clearly defined.

3. Confirm the policy mandates automated enforcement, such as diagnostic tools that validate encryption status and trigger remediation (patching, upgrades) before network access.

4. Verify that the policy requires testing of encryption workflows in isolated environments and integrates encryption checks into change‑management and orchestration processes.

5. Review system outputs (encryption compliance dashboards, remediation logs, change‑approval tickets, and audit trails) to ensure all endpoint devices adhere to the CSP’s storage encryption requirements.

From CCM 4.1:

1. Examine the organization’s asset disposal policy for end-of-life security requirements.

2. Examine the organization’s policy on encryption or otherwise protection of data at rest on endpoints.

3. Determine if such controls are in place and evaluated as effective.

UEM-09: Anti-Malware Detection and Prevention

Control Specification

Configure managed endpoints with anti-malware detection and prevention technology and services.

Auditing Guidelines for Cloud Service Providers (CSP)

1. Verify that the CSP has a documented Anti‑Malware Policy for all endpoint types, approved by governance, defining scope, roles, responsibilities, and review cadence.

2. Inspect the policy to confirm it mandates automated installation and regular updates of anti‑malware software, signatures, and virus definitions.

3. Confirm the policy enforces application whitelisting on endpoints and restricts unauthorized software installation, including on BYOD devices.

4. Verify the policy requires periodic scans of installed software and data for unauthorized code, plus defined procedures for response and removal.

5. Review system outputs (scan reports, remediation logs, exception records, change‑approval tickets, and audit trails) to ensure endpoints comply with the CSP’s anti‑malware requirements.

From CCM 4.1:

1. Examine the organization’s anti-malware policy.

2. Determine if such controls are in place and evaluated as effective.

UEM-10: Software Firewall

Control Specification

Configure managed endpoints with properly configured software firewalls.

Auditing Guidelines for Cloud Service Providers (CSP)

1. Verify that the CSP has a documented Software Firewall Policy for all endpoint types, approved by governance, with defined roles and review intervals.

2. Inspect the policy to confirm it mandates installation of host‑based firewalls with default‑deny configurations and approved baseline rule‑sets.

3. Confirm the policy requires automated deployment of rule‑sets, logging of firewall events, and central collection for analysis.

4. Verify that the policy enforces patching and updating of firewall software on endpoints and defines formal change control for rule modifications.

5. Review system outputs (baseline configuration inventories, automated compliance reports, firewall log‑aggregation dashboards, patch records, and audit logs) to ensure endpoints comply with the CSP’s firewall requirements.

From CCM 4.1:

1. Examine the organization’s software firewall and other endpoint network protection policy.

2. Examine the policy on configuration of such controls.

3. Determine if such controls are in place and evaluated as effective.

UEM-11: Data Loss Prevention

Control Specification

Configure managed endpoints with Data Loss Prevention (DLP) technologies and rules in accordance with a risk assessment.

Auditing Guidelines for Cloud Service Providers (CSP)

1. Verify that the CSP has a documented DLP Policy for both endpoint and cloud workloads, approved by governance, defining sensitivity tiers, roles, and review intervals.

2. Inspect the policy to confirm it mandates centralized data classification, structured inventories, and use of CSP‑native or integrated DLP services on all managed endpoints.

3. Confirm the policy requires automated scanning of data in motion and at rest including API transfers, container volumes, file uploads, against classification‑based rules and application whitelisting.

4. Verify that the policy specifies real‑time responses (blocking, encryption, alerting), integration with security event management, and defined SOPs for handling DLP violations.

5. Review system outputs (classification inventories, DLP configuration snapshots, violation logs, remediation tickets, compliance dashboards, and audit trails) to ensure compliance across endpoints and workloads.

From CCM 4.1:

1. Examine the organization’s data loss policy.

2. Examine the policies on configuration of such controls.

3. Determine if such controls are driven by risk assessments.

4. Determine if such controls are in place and evaluated as effective.

UEM-12: Remote Locate

Control Specification

Enable remote geo-location capabilities for all managed mobile endpoints, according to all applicable laws and regulations.

Auditing Guidelines for Cloud Service Providers (CSP)

1. Verify that the CSP has a documented process for remote tracking of endpoint devices, including BYOD and corporate devices, under all service delivery models.

2. Confirm that the policy mandates inventory of all endpoints, use of GPS or network-based tracking, and immediate alerts for devices going offline or untraceable.

3. Review whether remote tracking processes are integrated with incident response workflows and include well-defined escalation paths for lost or stolen devices.

4. Inspect implementation evidence such as tracking logs, inventory records, alert configurations, and periodic testing documentation of remote wipe functionality.

5. Verify that the CSP routinely tests the effectiveness of remote locate and wipe procedures across different endpoint types and maintains records of these tests.

From CCM 4.1:

1. Examine the organization’s remote geo-location for managed mobile endpoints policy.

2. Determine if such controls are in place.

UEM-13: Remote Wipe

Control Specification

Define, implement and evaluate processes, procedures and technical measures to enable the deletion of company data remotely on managed endpoint devices.

Auditing Guidelines for Cloud Service Providers (CSP)

1. Verify that the CSP has a documented process for remote wipe of corporate and BYOD endpoints, covering inventory, geolocation tracking, alerting for untraceable devices, and remote wipe capability.

2. Confirm that remote wipe features are enforced at the device level and cannot be disabled by users.

3. Inspect whether wipe operations are limited to authorized personnel and include secure data removal techniques to prevent incomplete wipes or data leakage.

4. Review implementation evidence such as endpoint inventories, tracking logs, remote wipe execution reports, and periodic test documentation.

5. Verify that the CSP routinely tests remote wipe procedures across all supported endpoint types and maintains testing evidence for audit and compliance purposes.

From CCM 4.1:

1. Examine procedures for adequacy, currency, communication, and effectiveness.

2. Determine the extent and applicability of the processes, procedures, and technical measures over managed endpoints, as identified.

3. Examine policy and procedures for evidence of review, with respect to effectiveness.

UEM-14: Third-Party Endpoint Security Posture

Control Specification

Define, implement and evaluate processes, procedures and technical and/or contractual measures to maintain proper security of third-party endpoints with access to organizational assets.

Auditing Guidelines for Cloud Service Providers (CSP)

1. Verify that the CSP maintains documented agreements with third parties covering endpoint access controls, including provisions for identity management, endpoint isolation, security tool installation, secure communications, and defined contractual security responsibilities.

2. Confirm that contracts include detailed requirements for endpoint security, such as device types allowed, data confidentiality, compliance with legal requirements, patching, service levels, and reporting duties.

3. Inspect whether agreements mandate third-party security assessments, assign vendor-side security contacts, and define penalties for non-compliance.

4. Review implementation evidence such as endpoint access logs, vendor risk assessments, contract terms, monitoring reports, and meeting records between CSP and vendors.

5. Verify that third-party access and security are continuously monitored through automated tools, with prompt action on suspicious activities or policy violations.

From CCM v4.1:

1. Examine procedures for adequacy, currency, communication, and effectiveness.

2. Determine the organization’s definition of third-party endpoints.

3. Determine the extent and applicability of the processes, procedures, and technical measures over third-party endpoints.

4. Examine policy and procedures for evidence of review, with respect to effectiveness.