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.

Shared Implementation Guidelines

[Applicable to all providers]

1. Define Policy Scope: Establish provider’s specific policy scopes as highlighted in the provider specific section of implementation guidelines.

2. Policy Governance Structure: Establish clear roles and responsibilities for policy maintenance, including cross-functional team involvement and oversight committees. Define approval chains involving senior management, legal teams, and compliance officers.

3. Policy Documentation Requirements: Define structured documentation for audit policies, including detailed procedures, standards, and guidelines specific to each provider’s scope. Consider establishing templates and formats for maintaining consistent policy documentation.

4. Policy Management Framework: Implement structured policy review processes. Review and update AI audit and assurance policies at least annually to incorporate changes in technology, regulatory updates, and organizational priorities. Align with applicable laws, regulations, and standards like GDPR, CCPA, ISO 27001/42001, HIPAA, etc. Incorporate guidance from AI-specific frameworks like NIST AI Risk Management Framework and OWASP LLM Top 10.

5. Communication and Training Standards: Define requirements for policy communication, including formal documentation, training programs, and stakeholder awareness initiatives. Establish standards for maintaining policy documentation and ensuring accessibility to relevant parties.

6. Quality Control Standards: Define policies for quality assurance within each provider’s scope, including requirements for testing, validation, and performance monitoring of AI systems and features.

Implementation Guidelines for Cloud Service Providers (CSP)

The CSP should establish formal policies and procedures based on industry best practices and relevant standards to educate its personnel of the required baseline for information security standards and guidelines. It should establish and document an approved and organized approach to its regulatory and contractual requirements, or security requirements in standards such as ISO/IEC 27001, AICPA TSC (SOC 2), and CSA AICM in order to prepare and plan its audit and assurance activities.

Policies should include (but not limited to) provisions on the following:

• a. Scope and Objectives:

  • i. The scope of audit and assurance activities should be defined, including the cloud services, environments, and data to be audited

  • ii. A risk-based audit plan should be developed that prioritizes areas of highest risk and aligns with the defined business objectives

  • iii. Authority and accountability for audit completion should be defined, and requirements to comply and/or assist with audits.

• b. Independent Assessments: Requirements to conduct independent assessments by qualified and independent third-party auditors to evaluate compliance with relevant standards, security policies, legal and contractual requirements.

  • i. auditors should have least privilege access to only relevant and necessary information and resources allowing to conduct the audit

  • ii. a conflict of interest policy should be in place to maintain auditors objectivity and independence

• c. Risk-Based Planning Assessment: Requirements on evaluating the effectiveness of the CSP’s risk-based plans and internal policies in identifying, assessing, and mitigating security risks and potential security vulnerabilities within the cloud environment.

• d. Requirements Compliance: Requirements for the CSP to verify compliance for its cloud security practices with all applicable standards, regulations, legal/contractual, and statutory requirements, including data privacy laws, industry-specific regulations, and customer contractual obligations that are applicable to the audit

• e. Audit Management Process: An audit management process to govern audit planning, execution, and reporting on cloud security audits. This includes defining the scope, frequency, and methodologies for audits, as well as the roles and responsibilities of audit personnel.

• f. Remediation: A risk-based corrective action plan to address audit findings in a timely and effective manner. The plan should:

  • i. Structure audit finding reviews, and track any findings

  • ii. Prioritize findings based on their potential impact and likelihood of occurring,

  • iii. Assign clear ownership and timelines for remediation and track progress towards resolving identified issues. Additionally, the CSP should regularly review and report remediation status to relevant stakeholders.

• g. Approval: Approval requirements and senior management involvement to ensure alignment with the organization’s strategic goals and risk appetite.

  • i. An approval process should be established for any changes or modifications to the policy and procedures

  • ii. A documented record of approvals (including dates, names of approvers, and any relevant comments or discussions should be maintained.

• h. Communication: Effective communication of the policy and procedures should be facilitated to all relevant cloud stakeholders. Communication channels should be established with relevant stakeholders that require record of activities and provide them with reports of audit findings, audit-related issues and remediation strategies.

• i. Maintenance and Reviews: Audit and assurance policies and procedures should be documented, reviewed and updated at least annually to ensure alignment with evolving cloud security landscape and to reflect changes in cloud technology, regulations, and risks.

A&A-02: Independent Assessments

Control Specification

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

Shared Implementation Guidelines

Independent assessments are essential to ensure AI systems are credible, reliable, and compliant. Annual assessments identify vulnerabilities and risks, allowing for proactive mitigation and continuous improvement.

[All Providers: MP, AP, OSP]

1. Assessment Planning and Execution: Engage qualified independent assessors with AI expertise, establish clear assessment objectives and scope, and develop comprehensive testing methodologies including adversarial testing where applicable. Ensure assessors maintain independence from the teams responsible for system development and operations.

2. Assessment Standards Alignment: Incorporate relevant standards and frameworks including CSA AI Security Framework, ISO/IEC 42001 for AI Management Systems, ISO/IEC 27001 for information security, and industry-specific requirements. Ensure alignment with organizational policies and regulatory requirements.

3. Documentation and Reporting: Maintain detailed assessment records, document methodology and findings, create clear actionable reports, and establish evidence preservation procedures. Share findings with relevant stakeholders including senior management and compliance teams.

4. Assessment Frequency and Updates: Conduct assessments at least annually and after significant changes. Update assessment criteria based on evolving threats, technologies, and standards. Maintain a schedule of planned assessments.

5. Quality Assurance: Verify assessor qualifications and independence, validate assessment methodologies, ensure comprehensive coverage of critical areas, and review assessment quality and effectiveness.

6. Relevant Assessment Scope: Ensure independent assessments appropriately cover controls relevant to their role in the AI supply chain, focusing on the specific components, processes, and data under their responsibility as defined in their scope of services and products.

Implementation Guidelines for Cloud Service Providers (CSP)

1. Define the Scope of Independent Assessments and ensure assessments cover multi-tenancy controls, data isolation, supply chain dependencies, and platform-level AI governance measures.

2. CSPs should maintain mechanisms to produce and distribute attestations or reports that demonstrate the effectiveness of their controls upon request from cloud consumers of AI services (AICs). The attestations must be based on applicable controls and requests must be fulfilled within defined service-level timelines.

From CCM v4.1: Control Ownership Rationale. The CSP and the CSC are both responsible for the implementation of this control, however each party needs to implement it independently in accordance with their own regulatory and contractual obligations. The CSP’s independent audit and assurance assessments may be utilized to gauge the security posture of its own cloud services’ infrastructure.

Implementation Guidelines. Applicable to all service models: The CSP should regularly conduct independent assurance and audit activities as established by A&A-01. The CSP should also conform and provide a platform to prove that compliance controls are applied and in accordance with relevant standards. The audit activities may vary in scope to cover more or less specific areas in a rotational time frame to make sure the whole of the organization and its service provisions include at least some audit activities throughout the year.

Audits and assurance in terms of this control could mean:

• a. Independent verification of self-assessments

• b. Physical control reviews and evidence-based claim assessments

• c. Performance or testing control effectiveness such as penetration testing, vulnerability scanning, and red team exercises

Audit activities should be conducted by a competent independent internal or external party.

The CSP may choose to implement a Governance, Risk and Compliance (GRC) tool, either its own or a third-party solution, to enhance audit and assurance activities.

The CSP should not rely only on self assessments, internal gap analysis, or any other metrics that are produced by internal auditing, internal scans, etc., since internal self-alerting biases may exist.

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.

Shared Implementation Guidelines

Risk-based planning assessments focus on identifying and prioritizing areas of greatest potential risk within AI systems and operations.

[All Providers: MP, AP, OSP]

1. Risk-Based Assessment Framework: Conduct independent assessments according to documented risk-based plans. Create a comprehensive AI risk inventory including data breaches, model bias, adversarial attacks, and non-compliance with regulations. Use frameworks like ISO 31000 or NIST RMF to classify risks by likelihood and impact. Establish risk evaluation metrics (financial, reputational, operational) to prioritize assessment areas. Align risk-based plans with enterprise risk management and AI governance policies. Incorporate regulatory requirements such as GDPR, HIPAA, or the EU AI Act into planning.

2. Prioritization and Frequency: Prioritize assessments for high-risk AI applications involving sensitive data, autonomous decision-making, or public-facing interfaces. Determine assessment frequency based on risk levels of each AI system. Include provisions for on-demand assessments triggered by significant changes such as new model deployments, regulatory updates, or security incidents. Update risk-based plans regularly to reflect changes in technology, threats, and organizational priorities.

3. Documentation and Integration: Document assessment methodologies, findings, and corrective actions for audit and compliance purposes. Classify findings by risk exposure level with actionable mitigation recommendations. Integrate risk-based assessments with organizational compliance frameworks such as ISO 27001/42001 or NIST AI RMF, etc.. Implement monitoring systems to track risk levels and trigger reassessments as needed.

Implementation Guidelines for Cloud Service Providers (CSP)

Implementation best practices for this actor include (but are not limited to):

The CSP should implement a regime of independent assurance and audit activities using a risk-based approach. The CSP is recommended to adhere to operational activities and procedures in auditing and risk management standards.

Because the CSC will generally need to rely on the independent audits, assessments, and attestations engaged by and for the CSP, the CSP should ensure that the objectives and scopes of the independent assurance activities are clearly defined and that the objectives and scopes are documented and communicated with adequate clarity and specificity to the AIC.

In particular, the CSP’s documentation of objectives and scope should be clear, unambiguous, and have specific delineation as to which cloud services, which resources (including data), and which service features and options were assessed. This permits the CSC to adequately and appropriately rely on the assurance activities and reports provided by the CSP.

From the CCM v4.1: Control Ownership Rationale. The CSP and the CSC are both responsible for the implementation of this control, however each party needs to implement it independently in accordance with their own risk-based plans and policies, regulatory and contractual obligations. The CSP’s independent audit and assurance assessments may be utilized to gauge the security posture of its own cloud services’ infrastructure. However, the CSC should also perform independent assessments of the CSP to demonstrate compliance with its own (CSC’s) requirements. Both CSP and CSC are responsible for reviewing the impact of changing risks on audit and assurance assessments.

Implementation Guidelines. Applicable to all service models: The CSP should implement a regime of independent assurance and audit activities using a risk-based approach. The CSP is recommended to adhere to operational activities and procedures in auditing and risk management standards.

Because the CSC will generally need to rely on the independent audits, assessments, and attestations engaged by and for the CSP, the CSP should ensure that the objectives and scopes of the independent assurance activities are clearly defined and that the objectives and scopes are documented and communicated with adequate clarity and specificity to the CSC.

In particular, the CSP’s documentation of objectives and scope should be clear, unambiguous, and have specific delineation as to which cloud services, which resources (including data), and which service features and options were assessed. This permits the CSC to adequately and appropriately rely on the assurance activities and reports provided by the CSP.

A&A-04: Requirements Compliance

Control Specification

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

Shared Implementation Guidelines

Compliance with relevant standards, regulations, legal, contractual, and statutory requirements is critical for ensuring that AI systems operate within the boundaries of the law and adhere to organizational and industry-specific obligations.

[All Providers: MP, OSP, AP]

1. Compliance Identification: Identify all applicable regulations governing AI systems ( e.g. GDPR, HIPAA, CCPA, ISO 27001, NIST AI RMF, EU AI Act, etc.) across relevant jurisdictions where AI components are developed, deployed, or used.

2. Governance Integration: Integrate compliance checks into AI governance frameworks to ensure consistent implementation across model development, training data management, deployment infrastructure, and monitoring systems.

3. Assessment and Verification: Conduct periodic gap analyses and compliance audits to identify discrepancies between current practices and requirements, with focus on data protection, model transparency, fairness, and security controls.

4. Monitoring and Documentation: Establish systems to track regulatory changes relevant to AI systems, maintain comprehensive audit trails, and document evidence including policies, logs, training records, and system configurations.

Implementation Guidelines for Cloud Service Providers (CSP)

The CSP should conduct audits and assessments against industry standards, regulations and statutory requirements depending on the services and the jurisdictions in which they operate. The CSP should implement a process to identify and document legal and regulatory requirements that impact its cloud service offering, both within itself and with third-party suppliers that operate on its behalf. The process should:

• a. Cover the jurisdictions, i.e., regions, countries, states, where the organization conducts business

• b. Incorporate the following: Security-specific legislations or regulations and Legislations or regulations which has security control implications.

• c. Identify the regulatory, statutory, contractual, or other compliance requirements to which the cloud service, its associated systems, and its data are subject

• d. Identify the respective specific technical and administrative compliance requirements that are required for the data, technology, and processes comprising and supporting the cloud service. In general, this should include:

  • i. objects and data elements, system settings and capabilities, metadata, events, activities, and processes subject to any special regulatory requirements

  • ii. what specific requirements apply to objects, system settings, metadata, activity, and processes.

(The above CSP implementation 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.

Shared Implementation Guidelines

AI service providers should implement an audit plan which covers the frequency and schedule of the audit. It should have both internal and external audit plans. Each provider must audit their systems according to their specific scope of responsibility

[AI Providers: MP, OSP, AP]

1. Audit Planning: Define objectives and scope of audits to include AI-specific components such as model development processes, training data quality, inference systems, and governance frameworks. Create a comprehensive audit calendar that specifies frequency based on risk assessment, responsible teams with AI expertise, and key milestones for each audit cycle.

2. Evidence Collection: Document evidence including model documentation, training datasets, inference logs, security configurations, and output validation tests. Ensure all evidence is securely stored with proper access controls and maintains traceability between model versions, training data, and deployed systems.

3. Reporting: Generate comprehensive reports summarizing findings, risk levels specific to AICM domains and compliance gaps with actionable recommendations. Use standardized templates that address unique AI concerns including bias, safety, and model robustness.

4. Remediation: Develop prioritized remediation schedules with clear deadlines and responsibilities assigned to relevant teams. Establish specific criteria for remediation of AI risks and findings across all AICM domains.

5. Stakeholder Communication: Share results with relevant stakeholders including senior management, AI governance boards, and compliance teams. Incorporate domain expert feedback to refine both technical and governance aspects of AI systems.

6. Continuous Improvement: Analyze past reports to identify recurring issues, emerging AI-specific risks, and performance patterns across multiple audit cycles. Use insights to drive improvements in model development processes, security controls, and governance frameworks.

Implementation Guidelines for Cloud Service Providers (CSP)

The CSP should implement an audit plan which covers the frequency and schedule of the audit. It should have both internal and external audit plans. A security control assessment plan should be part of internal auditing activities to determine the extent to which the controls are implemented correctly, operating as intended (are effective), and producing the desired outcome. The purposes of an audit are:

• a. Ensure that the policies, standards and procedures relevant to the area are effectively implemented

• b. Ensure the effectiveness of risk management implementation

• c. Ensure the effectiveness of the controls included in the organizational security program / Information security management system

• d. Where appropriate, provide improvement recommendations to overcome deficiencies in implementation,

• e. Ensure compliance of control implementation with laws and regulations The CSP should adhere to the following best practices:

• f. Ensure the availability of adequate competent personnel

• g. Emphasize the importance and benefits of audits

• h. Design and implement workflows and timelines

• i. Stress the importance of adequate review of audit and other artifacts

• j. Utilize the outputs of the review process to assess the effectiveness of the Audit Management process.

From the CCM: Control Ownership Rationale. This control is shared, meaning that the CSP and CSC should independently implement the control requirements. Nevertheless, the CSC should be aware that it should not rely solely on the CSP’s independent audits and need to conduct its own audit activities.

Implementation Guidelines. The implementation guidelines provided for the CSP apply.

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.

Shared Implementation Guidelines

AI providers should maintain a Risk Management program to identify, mitigate, and manage risks specific to their systems. Management should establish processes to identify risks within their area of responsibility and implement appropriate measures to address them. Audit findings should receive appropriate attention at all organizational levels. When control deficiencies are identified, they should be evaluated for prioritization based on potential impact. Once prioritized, appropriate risk treatment options should be selected and implemented.

[AI Providers (MP, OSP, AP)] 1.Remediation Framework: Establish a documented framework outlining the process for creating, implementing, and monitoring corrective action plans specific to AI systems. Base the framework on a risk-based approach. Ensure the framework aligns with organizational policies, regulatory requirements, and industry standards

1. Communication and Coordination: Communicate remediation plans, including priorities and deadlines, to all responsible teams across AI development, operations, and security. Use collaborative platforms to coordinate remediation activities that may span across model development, orchestration, and application layers.

2. Roles and Responsibilities: Designate specific individuals or teams responsible for addressing each audit finding related to AI systems. Ensure clear ownership for remediating issues spanning the entire AI lifecycle handled by the provider.

3. Risk-Based Prioritization: Prioritize findings based on risk assessment that considers both traditional security factors and AI-specific concerns such as model robustness, output safety, and potential for misuse. Implement a tiered approach that addresses critical AI safety and security issues first. Establish escalation protocols for high-risk findings or delays in remediation of critical AI safety issues to ensure timely resolution.

4. Verification and Validation: Conduct follow-up assessments to confirm that remediation measures effectively address identified risks. For AI systems, this may include model testing, red-teaming exercises, or adversarial testing to validate that vulnerabilities have been properly mitigated.

5. Documentation and Reporting: Document remediation outcomes, including evidence of risk mitigation such as before/after security testing results, model performance metrics, and compliance improvements. Maintain comprehensive records linking audit findings to specific remediation actions and verification results. Provide regular status updates to relevant stakeholders.

6. Continuous Improvement: Regularly review and update corrective action processes to incorporate lessons learned from previous remediations and emerging AI risks. Adjust and implement policy and controls based on incident data, evolving threats, changing regulatory landscape for AI, and advances in AI safety research.

7. Metrics and Measurement: Include metrics and KPIs specific to AI systems that demonstrate risk reduction and compliance improvement. Track metrics such as successful model security test rates, reduction in false positives/negatives, or improvements in model robustness against adversarial inputs.

Implementation Guidelines for Cloud Service Providers (CSP)

The CSP should maintain a Risk Management program to mitigate and manage risk. Management should have a process that requires it to identify risks within its area of responsibility and to implement appropriate measures to address those risks. Findings of audit and assurance activities should be given due care and attention at the appropriate levels. If a control deficiency (finding) is identified, the deficiency should be evaluated for prioritization. Once prioritized, the appropriate risk treatment should be selected.

Options to treat risks should be clearly defined and evaluated, which could include:

• a. mitigating risk by increasing the effectiveness of controls

• b. mitigating the risk by implementing compensating controls

• c. avoiding all or part of the risk (i.e., deciding not to pursue a particular business initiative)

• d. accepting all or part of the risk

Risk treatment actions should be:

• a. documented in an approved risk treatment plan

• b. assigned to ensure accountability

• c. monitored against agreed upon target dates

• d. reported as required by the Organization’s Policy It is important to establish a set of success metrics and routinely monitor for closure.

From the CCM v4.1: Control Ownership Rationale. The CSP and the CSC are both responsible for the implementation of a risk-based corrective action plan to remediate audit findings, however each party needs to implement it independently in accordance with their own unique legislative, regulatory and contractual obligations.

Implementation Guidelines. Applicable to all service models: The CSP should maintain a Risk Management program to mitigate and manage risk. Management should have a process that requires it to identify risks within its area of responsibility and to implement appropriate measures to address those risks.

Findings of audit and assurance activities should be given due care and attention at the appropriate levels. If a control deficiency (finding) is identified, the deficiency should be evaluated for prioritization. Once prioritized, the appropriate risk treatment should be selected.

Options to treat risks should be clearly defined and evaluated, which could include:

• a. Mitigating risk by increasing the effectiveness of controls

• b. Mitigating the risk by implementing compensating controls

• c. Avoiding all or part of the risk (i.e., deciding not to pursue a particular business initiative)

• d. Accepting all or part of the risk

Risk treatment actions should be:

• a. documented in an approved risk treatment plan

• b. assigned to ensure accountability

• c. monitored against agreed upon target dates

• d. reported as required by the Organization’s Policy

It is important to establish a set of success metrics and routinely monitor for closure.

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.

Shared Implementation Guidelines

[Applicable to all providers (CSP, MP, OSP, AP) excluding AIC unless otherwise specified] 1.Define Policy Scope: Establish provider-specific policy scopes as outlined in the provider-specific sections below. Ensure policies address the security of applications and interfaces throughout their lifecycle, including design, development, deployment, and maintenance.

1. Policy Governance Structure: Establish clear roles and responsibilities for maintaining application security policies, including involvement of cross-functional teams (e.g., security, development, operations) and oversight by governance bodies. Define approval workflows involving senior management, security leads, and legal/compliance teams to ensure alignment with organizational objectives.

2. Policy Documentation Requirements: Define structured documentation standards for application and interface security policies, including detailed procedures, technical standards, and implementation guidelines specific to each provider’s scope. Use consistent templates to document security controls, risk assessments, and mitigation strategies.

3. Policy Management Framework: Implement a structured review process for application security policies. Conduct reviews and updates at least annually or following significant system changes (e.g., new features, architecture updates, or identified vulnerabilities) that could alter risk exposure. Ensure alignment with relevant laws, regulations, and standards (e.g., GDPR, CCPA, ISO 27001, OWASP Top 10). Incorporate guidance from AI-specific frameworks such as NIST AI Risk Management Framework and OWASP LLM Top 10 where applicable.

4. Communication and Training Standards: Define requirements for communicating application security policies, including formal documentation distribution, mandatory training programs for developers and operators, and awareness campaigns for stakeholders. Establish standards for ensuring policy accessibility (e.g., internal portals) and comprehension across relevant teams.

5. Quality Control Standards: Define policies for quality assurance of application and interface security, including requirements for secure coding practices, vulnerability testing (e.g., static/dynamic analysis), penetration testing, and performance monitoring to ensure robust security controls are in place.

Implementation Guidelines for Cloud Service Providers (CSP)

Policy Scope: Application and interface security policies covering the underlying infrastructure supporting AI systems, including virtual machines, containers, networking, and storage. Policies should address secure configuration of cloud resources, access controls for APIs, and protection of interfaces exposed to MPs, OSPs, or APs.

[Applicable to all providers (CSP, MP, OSP, AP) excluding AIC unless otherwise specified] 1.Define Policy Scope: Establish provider-specific policy scopes as outlined in the provider-specific sections below. Ensure policies address the security of applications and interfaces throughout their lifecycle, including design, development, deployment, and maintenance.

1. Policy Governance Structure: Establish clear roles and responsibilities for maintaining application security policies, including involvement of cross-functional teams (e.g., security, development, operations) and oversight by governance bodies. Define approval workflows involving senior management, security leads, and legal/compliance teams to ensure alignment with organizational objectives.

2. Policy Documentation Requirements: Define structured documentation standards for application and interface security policies, including detailed procedures, technical standards, and implementation guidelines specific to each provider’s scope. Use consistent templates to document security controls, risk assessments, and mitigation strategies.

3. Policy Management Framework: Implement a structured review process for application security policies. Conduct reviews and updates at least annually or following significant system changes (e.g., new features, architecture updates, or identified vulnerabilities) that could alter risk exposure. Ensure alignment with relevant laws, regulations, and standards (e.g., GDPR, CCPA, ISO 27001, OWASP Top 10). Incorporate guidance from AI-specific frameworks such as NIST AI Risk Management Framework and OWASP LLM Top 10 where applicable.

4. Communication and Training Standards: Define requirements for communicating application security policies, including formal documentation distribution, mandatory training programs for developers and operators, and awareness campaigns for stakeholders. Establish standards for ensuring policy accessibility (e.g., internal portals) and comprehension across relevant teams.

5. Quality Control Standards: Define policies for quality assurance of application and interface security, including requirements for secure coding practices, vulnerability testing (e.g., static/dynamic analysis), penetration testing, and performance monitoring to ensure robust security controls are in place.

From CCM: Control Ownership Rationale. This control’s implementation responsibility is not impacted by the type of cloud service offerings (IaaS, PaaS, SaaS). Both the CSP and CSC should independently establish their own policies and procedures for guiding the development and implementation of application security capabilities based on the cloud service model in effect within the organizations.

Implementation Guidelines. Applicable to all service models: The CSP should establish policies and procedures for guiding the secure development and implementation of cloud applications and application interfaces. The policies should align with the CSP’s purpose and strategy with top management’s commitment to continuous improvement. Policies should include (but not limited to) provisions on the following:

• a. Scope and Objectives: The cloud organization should define the scope and objectives of the AIS policies and procedures

  • i. The scope of the policy and procedures, including::

    • The cloud environments and within those the applications and Interfaces (APIs) that should be covered

    • The applicability of the policies and procedures to third-party vendors involved in the development and deployment of cloud-based applications

    • Address cross-functional aspects, incorporating requirements from various teams, such as development, security, operations, and legal

  • ii. The objectives of the policy and procedures, including:

    • The protection of sensitive and personal data, preventing unauthorized access, and maintaining applications’ availability

    • The alignment of the policies and procedures with the organization’s overall security strategy and compliance requirements

    • The expected outcomes of implementing and adhering to the policies and procedures (e.g., reduced vulnerability risk, improved security posture)

• b. Application Security Baseline Requirements: Requirements for establishing, documenting, implementing and assessing a centralized security baseline that outlines the minimum security requirements for all cloud-based applications and APIs. This baseline should be based on industry standards (e.g., OWASP), best practices, and the organization’s specific risk tolerance

• c. Application Security Metrics: Metrics to track the effectiveness of application security controls and processes that should be regularly reviewed and reported onto to identify trends and areas for improvement

• d. Secure Application Development: Requirements to define and establish a SSDLC governance framework that incorporates security practices throughout the entire development process (i.e., threat modeling, secure design and coding guidelines, security testing and code reviews, remediation, and secure coding training)

• e. Automated Application Security Testing: Requirements for the application security testing tools (automated if possible) integration into the SSDLC to identify vulnerabilities early in the development process

• f. Automated Secure Application Deployment: Requirements for deployment pipelines (automated if possible) to ensure that applications are deployed securely and consistently (e.g., code review, vulnerability scanning, and security configuration management)

• g. In-house or 3rd Party Supplier Application Development: Security requirements for third-party vendors that develop or deploy cloud-based applications for the organization that should be aligned with the organization’s security baseline and should cover all phases of the SSDLC

  • i. A risk assessment of each third-party vendor before engaging them to evaluate the vendor’s security practices, experience, and reputation

  • ii. A contractual obligation for the third-party vendor should be established to comply with the organization’s security requirements

• h. Application Vulnerability Remediation: Vulnerability management requirements to identify, prioritize, and remediate vulnerabilities in cloud-based applications (with automated tools if possible). Requirements should include clear timelines for remediation and escalation procedures for high-risk vulnerabilities

• i. Approval: Approval requirements and senior management involvement to ensure alignment with the organization’s strategic goals and risk appetite

  • i. An approval process should be established for any changes or modifications to the AIS policy and procedures

  • ii. A documented record of approvals (including dates, names of approvers, and any relevant comments or discussions) should be maintained

• j. Communication: Effective communication of the policy and procedures should be facilitated to all relevant cloud stakeholders, including developers, operations teams, and CSCs

• k. Maintenance and Reviews: Application security policies and procedures should be documented, reviewed and updated at least annually to ensure alignment with evolving cloud security landscape and to reflect changes in cloud technology, regulations, and risks

AIS-02: Application Security Baseline Requirements

Control Specification

Establish, document and maintain baseline requirements for securing applications.

Shared Implementation Guidelines

[All Actors] All actors in the AI supply chain must establish and adhere to security baselines that address the unique risks and vulnerabilities of AI systems.

1. Define AI-Specific Security Baselines: Establish baseline security requirements that address the unique challenges and risks associated with AI systems.

2. Document and Maintain Baselines: Document security baselines in a centralized repository with version control to ensure consistency, clarity, and ease of updating.

3. Align with Best Practices and Standards: Ensure that security baselines align with recognized industry best practices and relevant security standards, including those specific to AI.

4. Regularly Review and Update: Establish a process for regularly reviewing and updating security baselines to adapt to the evolving threat landscape and emerging technologies.

5. Communicate Baselines: Effectively communicate security baselines to relevant stakeholders to ensure alignment and understanding.

Implementation Guidelines for Cloud Service Providers (CSP)

CSPs must establish and maintain robust AI-specific security baselines to protect their infrastructure, services, and customer data, especially in the face of evolving AI security threats. These baselines serve as the foundation for their security posture and are critical for ensuring the confidentiality, integrity, and availability of cloud resources used for AI. Here are the corresponding AI-specific guidelines for CSPs:

1. Establish AI-Specific Baseline Security Requirements: CSPs must define comprehensive security requirements for all components of their infrastructure and services that support AI workloads. This includes the physical infrastructure, data centers, networks, hardware, software, and platforms. These requirements should address a wide range of security controls, with a focus on the unique needs of AI.

2. Document AI Security Baselines in a Centralized Repository with Version Control: CSPs must document their AI-specific security baselines in a centralized and easily accessible repository. This documentation should be well-organized, clearly written, and maintained with version control.

3. Align AI Security Baselines with Industry Best Practices and Standards: CSPs should ensure their AI-specific security baselines align with recognized industry best practices and relevant security frameworks and standards, including those specific to AI (e.g., NIST AI Risk Management Framework).

4. Regularly Review and Update AI Security Baselines: CSPs must establish a process for regularly reviewing and updating their AI-specific security baselines.

5. Communicate AI Security Baselines to Customers: CSPs should clearly communicate their AI-specific security baselines to their customers.

6. Define comprehensive security requirements for infrastructure and services that support AI workloads, focusing on the unique needs of AI.

[All Actors] All actors in the AI supply chain must establish and adhere to security baselines that address the unique risks and vulnerabilities of AI systems.

1. Define AI-Specific Security Baselines: Establish baseline security requirements that address the unique challenges and risks associated with AI systems.

2. Document and Maintain Baselines: Document security baselines in a centralized repository with version control to ensure consistency, clarity, and ease of updating.

3. Align with Best Practices and Standards: Ensure that security baselines align with recognized industry best practices and relevant security standards, including those specific to AI.

4. Regularly Review and Update: Establish a process for regularly reviewing and updating security baselines to adapt to the evolving threat landscape and emerging technologies.

5. Communicate Baselines: Effectively communicate security baselines to relevant stakeholders to ensure alignment and understanding.

From CCM: Control Ownership Rationale. This control’s implementation responsibility is not impacted by the type of cloud service offerings (IaaS, PaaS, SaaS). Both the CSP and CSC are independently responsible for establishing, documenting, and maintaining baseline requirements to secure the various cloud applications that are either produced or consumed.

Implementation Guidelines. Applicable to all service models: The baseline requirements should include, but not be limited to:

• a. Applications Categorization:

  • i. A risk-based approach should be used to identify, classify and categorize all relevant cloud applications and APIs based on the sensitivity, criticality, and the type of data they handle, and regulatory requirements

  • ii. Specific security requirements should be established for each application type (e.g., configuration, access control, encryption, vulnerability management, and incident response)

• b. Baseline Requirements Documentation:

  • i. A security baseline document should be created for each application type in a security requirements specification (SRS)

  • ii. Include details on each security requirement with respect to specific security controls, configurations, and procedures that should be implemented

• c. Baseline Requirements Implementation:

  • i. Cloud infrastructure features and third-party security tools should be used to implement the documented security requirements by their corresponding security controls

  • ii. Security control implementations and configuration should be implemented using infrastructure as code (IaC) tools

  • iii. Security controls should be integrated into the SSDLC to ensure security is embedded across all lifecycle phases in adherence to the established baseline requirements

• d. Baseline Review and Updates:

  • i. The security baseline requirements should be regularly reviewed and updated to reflect changes in applications technology, evolving threats, industry standards, possible findings from the continuous monitoring and assessment process, and the organization’s risk profile

  • ii. Lessons learned from security incidents and audits should be incorporated into the security baseline

  • iii. Baseline requirements should be reviewed and approved by management on a periodic basis and/or upon significant changes

• e. Compliance to Baseline Requirements:

  • i. Risk assessments should be conducted to evaluate cloud applications security and configurations alignment with the baseline

  • ii. Baseline requirements should be extended to third-party applications via thorough security assessments ensuring they meet the established baseline requirements before integration into the cloud environment

  • iii. Automated tools should be used to detect and remediate security violations

• f. Continuous Monitoring and Evaluation: Automated tools, manual reviews, and regular penetration testing for continuous security monitoring, vulnerability assessments, and compliance checks should be employed to ensure ongoing adherence to baseline requirements

AIS-03: Application Security Metrics

Control Specification

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

Shared Implementation Guidelines

[All Actors] All actors in the AI supply chain must share responsibility and collaborate to establish and maintain robust security metrics, monitoring, and reporting practices.

1. Define and Utilize AI-Specific Security Metrics: Establish and utilize security metrics tailored to the unique risks and vulnerabilities of AI systems.

2. Implement Automated Monitoring and Logging: Implement automated systems to continuously monitor and log AI-related security events and metrics.

3. Establish Baselines, Thresholds, and SLAs: Define acceptable levels of security performance and establish mechanisms for detecting deviations.

4. Generate and Share Regular Reports: Produce and disseminate regular reports on AI security metrics to relevant AI Actors.

5. Continuously review and update their respective security metrics, monitoring, and reporting processes.

Implementation Guidelines for Cloud Service Providers (CSP)

CSPs must establish robust mechanisms for security metrics, monitoring, and reporting to ensure the security and reliability of their AI-specific services and infrastructure. These guidelines align with the downstream responsibilities of MP, OSP, and AP, ensuring a consistent approach to security across the AI supply chain.

1. Define AI-Specific Security Metrics: CSPs must define a comprehensive set of AI-specific security metrics that encompass infrastructure, platform, and service-level security. These metrics should provide visibility into the CSP’s security posture and the effectiveness of its controls in protecting AI workloads.

2. Implement Automated Monitoring and Logging for AI Security: CSPs must implement robust, automated monitoring and logging systems to collect, aggregate, and analyze AI-specific security data in real-time. This enables proactive identification of security incidents, anomalies, and trends.

3. Establish Baselines, Thresholds, and SLAs for AI Security: CSPs must define baselines for normal operating conditions, establish thresholds for acceptable performance and security levels, and define Service Level Agreements (SLAs) where applicable, with a focus on AI workloads.

4. Generate Regular AI Security Reports: CSPs must generate regular reports on AI-specific security metrics and share them with relevant stakeholders, including downstream providers (MP, OSP), customers, and internal teams.

5. Continuously Review and Update AI Security Metrics: CSPs must continuously review and update their AI-specific security metrics, monitoring systems, and reporting processes to adapt to the evolving AI threat landscape, new AI technologies, and changing business needs.

6. Define comprehensive AI-specific security metrics across infrastructure, platform, and services.

[All Actors] All actors in the AI supply chain must share responsibility and collaborate to establish and maintain robust security metrics, monitoring, and reporting practices.

1. Define and Utilize AI-Specific Security Metrics: Establish and utilize security metrics tailored to the unique risks and vulnerabilities of AI systems.

2. Implement Automated Monitoring and Logging: Implement automated systems to continuously monitor and log AI-related security events and metrics.

3. Establish Baselines, Thresholds, and SLAs: Define acceptable levels of security performance and establish mechanisms for detecting deviations.

4. Generate and Share Regular Reports: Produce and disseminate regular reports on AI security metrics to relevant AI Actors.

5. Continuously review and update their respective security metrics, monitoring, and reporting processes.

From CCM: Control Ownership Rationale. This control’s implementation is a shared and independent responsibility for the CSP and the CSC since both need to define and implement metrics for the cloud applications they manage and according to their own unique business objectives, security requirements, and compliance obligations.

Implementation Guidelines. Applicable to all service models: By implementing technical and operational metrics for cloud applications, CSPs can optimize performance, enhance cost efficiency, maintain security, and elevate customer trust.

To effectively define and develop cloud application security metrics, the CSP should follow a structured approach that aligns with business objectives, security requirements, and compliance obligations.

The metrics should be documented to include descriptions and efficient and effective ways of gathering underlying data.

• a. Purpose and Scope Determination:

  • i. The purpose of the metrics should be determined (e.g., to measure security posture, compliance adherence, or risk mitigation effectiveness)

  • ii. The specific cloud applications or environments to be covered by the metrics should be identified

• b. Key Security Domains:

  • i. Security metrics should be categorized into relevant domains (e.g., vulnerability management, access control, data protection, and incident response)

  • ii. Metrics should be prioritized based on their importance to the organization’s security posture and business goals

• c. Measurable Parameters:

  • i. For each security domain, specific measurable parameters should be identified that accurately reflect the security posture

  • ii. Should ensure the selected parameters are quantifiable, consistent, and aligned with industry standards

• d. Thresholds and Benchmarks:

  • i. Acceptable thresholds for each metric should be defined, representing acceptable levels of security performance

  • ii. Metric performance should be compared against industry benchmarks or internal targets to assess security posture

• e. Data Collection and Aggregation:

  • i. A mechanism for collecting raw data from relevant sources should be established, such as security tools, logs, and cloud provider APIs

  • ii. Collected data should be aggregated into meaningful metrics for analysis and reporting

• f. Data Analysis and Visualization:

  • i. Data visualization tools should be utilized to present metrics in clear and understandable dashboards and reports

  • ii. Trends and patterns in metric data should be analyzed to identify potential security issues or areas for improvement

• g. Integration with Existing Processes:

  • i. Consider integrating security metrics into existing security reporting and risk management processes

  • ii. Metrics should be used to inform decision-making and prioritize security investments

• h. Continuous Monitoring and Evaluation:

  • i. Metrics performance should be regularly monitored and their effectiveness evaluated in measuring the cloud applications security posture

  • ii. Metrics should be refined and adapted as security requirements and business objectives evolve

  • iii. Various reports targeted toward different audiences should be generated from the metrics (e.g., KPIs, and KRIs) to track, quantify, and provide visibility into the effectiveness of the application security posture.
    i. SMART framework for metrics: A SMART framework can be adopted. SMART stands for Specific, Measurable, Achievable, Relevant, and Time-bound. i. Specific: The metric should have a clear and well-defined definition that leaves no room for ambiguity. It should be specific enough to focus on a particular aspect of performance or effectiveness ii. Measurable: The metric should be quantifiable and expressed in a unit of measurement that allows for tracking and comparison. It should be possible to collect and analyze data to assess the metric’s value iii. Achievable: The metric should be realistic and attainable within the organization’s capabilities and resources. Setting overly ambitious targets can lead to discouragement and frustration

  • iv. Relevant: The metric should align with the organization’s goals and objectives. It should provide meaningful information that directly contributes to achieving strategic goals

• i. Time-bound: The metric should have a defined timeframe for measurement and evaluation. This allows for tracking progress and identifying trends over time

Tools and toolchains should be employed for automating the measurements collection, generating the reports, and decision-making processes for error reduction and efficiency.

Trends and comparison analysis should be incorporated for continuous improvement and service maturity. The CSP should use the measurement results to improve its SSDLC processes. The entire process should be reviewed on a predetermined schedule or as required by the organization.

Use Case Example: The metric of ““Percentage of vulnerabilities remediated within a specified timeframe”” is taken as an example to see how it applies to the technical measures provided in this control. This metric falls under the Vulnerability Management domain and measures the effectiveness of vulnerability remediation efforts.

• a. Purpose and Scope Determination:

  • i. Objective: To measure the organization’s ability to timely remediate vulnerabilities and reduce the window of exposure to potential attacks

  • ii. Scope: All cloud applications and infrastructure components

• b. Key Security Domains: Unpatched vulnerabilities can be exploited by attackers to gain unauthorized access or compromise systems

• c. Measurable Parameters: The metric ““Percentage of vulnerabilities remediated within a specified timeframe”” directly quantifies the organization’s vulnerability remediation performance

• d. Thresholds and Benchmarks:

  • i. Set a target threshold for vulnerability remediation, such as remediating 90% of critical vulnerabilities within 7 days and 70% of high-severity vulnerabilities within 14 days

  • ii. Compare metric performance against industry benchmarks or internal targets to assess vulnerability remediation effectiveness

• e. Data Collection and Aggregation:

  • i. Utilize vulnerability scanning tools to identify vulnerabilities across cloud applications and infrastructure components

  • ii. Integrate vulnerability scan results with a central vulnerability management platform to track remediation progress

• f. Data Analysis and Visualization:

  • i. Generate reports and dashboards that track the percentage of vulnerabilities remediated within the specified timeframe

  • ii. Visualize trends in vulnerability remediation performance over time to identify areas for improvement

• g. Integration with Existing Processes:

  • i. Incorporate vulnerability remediation metric into the organization’s security risk management framework

  • ii. Use metric data to inform resource allocation and prioritization for vulnerability remediation efforts

• h. Continuous Monitoring and Improvement:

  • i. Regularly monitor vulnerability remediation performance against established thresholds and benchmarks

  • ii. Evaluate the effectiveness of vulnerability management processes and make adjustments as needed

Example Summary: A CSP has set a target of remediating 95% of critical vulnerabilities within 7 days. Over the past month, the average percentage of critical vulnerabilities remediated within 7 days has been 88%. This indicates that the organization is not meeting its target and may need to improve its vulnerability remediation processes.

Other examples of technical metrics include:

• a. Vulnerability Management:

  • i. count or percentage of vulnerabilities by weakness

  • ii. count of critical and high-severity vulnerabilities

  • iii. count or percentage of vulnerabilities by detection source (e.g., design review, code review, SAST, DAST, penetration test, VDP, bug bounty)

  • iv. Percentage of vulnerabilities remediated within a specified timeframe

• b. count or percentage of vulnerabilities by environment detected (pre-production vs. production) vi. count exceeding remediation service level objectives (SLOs) vii. count or percentage of applications using automated security testing by test type (SAST, DAST, SCA) viii. count or percentage of applications with completed penetration testing in the last “n” months ix. count or percentage of development teams or individuals who have completed application security training in the last “n” months

• c. Access Control:

  • i. Percentage of users with least privilege access

  • ii. Number of unauthorized access attempts

• d. Data Protection:

  • i. Percentage of data encrypted at rest and in transit

  • ii. Number of data loss incidents

• e. Incident Response:

  • i. Mean time to detect (MTTD) and mean time to respond (MTTR) to security incidents

  • ii. Number of incidents successfully contained and remediated

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.

Shared Implementation Guidelines

[Applicable to MP, OSP, and AP] The following best practices should be followed when implementing a secure SDLC:

1. Secure SDLC Governance: A security governance framework should be implemented that is tailored to the secure SDLC and that defines roles, responsibilities, and accountability for security throughout the secure SDLC.

   • i. The AI Service Providers (e.g., CSP, MP, OSP, or AP) secure SDLC processes, at a minimum, should meet the regulatory and AIC’s business requirements.

   • ii. The AISP should provide information to AISCs about the secure SDLC processes to the extent compatible with their disclosure policies.

2. Threat Modeling: AI-specific threat modeling should be incorporated into the early stages of the secure SDLC to identify potential security risks (e.g., poisoning, model inversion, data leakage). Mitigation strategies should be designed to help developers anticipate and proactively address AI-specific security issues, reducing the likelihood of AI-specific vulnerabilities being introduced later in the development cycle.

3. Secure Coding Practices:

   • i. Comprehensive security design requirements should be defined that specify AI-specific security measures and controls to be implemented throughout the application’s architecture

   • ii. Industry standard (e.g., OWASP, etc) secure coding practices should be incorporated in the secure SDLC

   • iii. Secure coding guidelines should be followed and implemented respectively (e.g., proper implementation and configuration of security headers, input validation, information output handling, error handling, and proper use of cryptographic libraries)

   • iv. Conduct regular training to ensure awareness and adherence to secure coding practices

4. Open-Source Components Secure Use: Secure practices for managing open-source components should be employed, including thorough vulnerability scanning, dependency management, and continuous monitoring for known vulnerabilities. Use trusted open-source repositories and ensure proper attribution and licensing compliance.

5. Vulnerability Management: Continuously scan for and remediate vulnerabilities in code, infrastructure, and third-party components (refer to TVM domain)

6. Security Testing: Regular security audits, static and dynamic application security testing, and penetration testing should be conducted to identify and address potential security weaknesses (refer to AIS-05 and TVM-06).

7. Secure Deployment and Configuration Management: (i) Secure deployment and configuration management practices should be implemented to ensure that AI applications are deployed and configured in a secure manner (ii)Automated tools should be used to enforce consistent configurations and monitor for deviations from security policies.

8. AI Impact Assessment: AI Impact Assessments should be conducted following the standards in GRC-10. Assessments should be updated at key SDLC stages and after major changes.

Implementation Guidelines for Cloud Service Providers (CSP)

CSPs play a vital role in providing the platform and services that underpin the AI development lifecycle. To align with the MP and OSP guidelines, CSPs must ensure their offerings facilitate and enforce security best practices throughout this lifecycle.

Implementation best practices for this actor include (but are not limited to):

1. Support a Secure AI SDLC: CSPs should provide services and tools that enable and support a secure AI-specific SDLC, encompassing all stages from data acquisition to model deployment and monitoring.

2. Offer Security Tools and Services: CSPs should provide a comprehensive suite of security tools and services that can be integrated into the AI development workflow.

3. Enable Automation and Integration: CSPs must ensure that security tools and services can be easily automated and integrated into CI/CD and MLOps pipelines.

4. Provide Security Monitoring and Logging: CSPs should offer comprehensive security monitoring and logging capabilities to provide visibility into the security posture of AI systems throughout their lifecycle.

5. Ensure Infrastructure Security: CSPs must provide a secure underlying infrastructure that supports the secure AI development lifecycle.

From CCM v4.1: Control Ownership Rationale. This control’s implementation responsibility is not impacted by the type of cloud service offerings (IaaS, PaaS, SaaS). Both the CSP and CSC are responsible for independently defining and implementing a Secure Software Development Lifecycle (SSDLC) process for secure application design, development, deployment, and operation in accordance with system security requirements defined by each cloud party. For deployments within the SaaS model, this control resides with the CSP, since SaaS CSPs typically offer ready-to-use applications and services, while the SaaS CSC consumes the service and is not responsible for implementing a SSDLC for application development.

Implementation Guidelines. Applicable to all service models: CSPs should leverage an SSDLC process to ensure that applications and APIs are securely designed, developed, deployed, and operated in their cloud environments. Integration of security best practices throughout the entire development lifecycle, can help CSPs to effectively protect their applications from vulnerabilities and cyberattacks.

Defining security requirements should be the first step in the SSDLC process to ensure that security is integrated throughout all phases of development. Security requirements should derive from security objectives and/or organizational goals and regulatory requirements. Industry standards should be applied at project inception and every stage of the SSDLC process. To successfully promote SSDLC security, roles and expectations should be clearly defined, published and communicated to relevant stakeholders.

The following best practices should be followed when implementing an SSDLC:

• a. SSDLC Governance: A security governance framework should be implemented that is tailored to the SSDLC and that defines roles, responsibilities, and accountability for security throughout the SSDLC

  • i. The CSP’s SSDLC processes, at a minimum, should meet the regulatory and CSC’s business requirements

  • ii. The CSP should provide information to CSCs about the SSDLC to the extent compatible with their disclosure policies

• b. DevSecOps: A DevSecOps approach should be defined and implemented that integrates security practices into all stages of the SSDLC, from planning and design to development, testing, deployment, and operation, rather than being an afterthought

• c. Threat Modeling: Threat modeling should be incorporated into the early stages of the SSDLC to identify potential security risks and design mitigation strategies to help developers anticipate and proactively address security issues, reducing the likelihood of vulnerabilities being introduced later in the development cycle

• d. Secure Coding Practices:

  • i. Comprehensive security design requirements should be defined that specify the security measures and controls to be implemented throughout the application’s architecture

  • ii. Industry standard (OWASP, etc) secure coding guidelines should be incorporated in the SSDLC

  • iii. Secure coding guidelines should be followed and implemented respectively (e.g., proper implementation and configuration of security headers, input validation, information output handling, error handling, and proper use of cryptographic libraries)

• e. Open Source Components Secure Use: Secure practices for managing open-source components should be employed, including thorough vulnerability scanning, dependency management, and continuous monitoring for known vulnerabilities. Use trusted open-source repositories and ensure proper attribution and licensing compliance

• f. Vulnerability Management: Continuously scan for and remediate vulnerabilities in code, infrastructure, and third-party components (refer to TVM domain)

• g. Security Testing: Regular security audits, static, dynamic application security testing, and penetration testing should be conducted to identify and address potential security weaknesses (refer to AIS-05 and TVM-06)

• h. Secure Deployment and Configuration Management:

  • i. Secure deployment and configuration management practices should be implemented to ensure that cloud-based applications are deployed and configured in a secure manner

  • ii. Automated tools should be used to enforce consistent configurations and monitor for deviations from security policies i. EoL Process: When an application reaches its end-of-life, a CSP should at minimum: i. Notify CSCs of the EoL date and provide clear instructions on how to migrate to alternative services ii. Discontinue providing technical support and updates for the application and archive the application’s source code and documentation

  • iii. Ensure that all application associated data is properly deleted or transferred to the CSC’s designated location

  • iv. Review and assess potential security vulnerabilities during the decommissioning process

The CSPs should be transparent about their security practices and provide CSCs with the necessary tools and support to meet their security requirements. The CSCs should actively engage with CSPs to ensure that their security requirements are implemented and maintained throughout the SSDLC.

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.

Shared Implementation Guidelines

[All Actors]

1. Implement comprehensive automated security testing throughout the AI lifecycle.

2. Use secured, controlled environments and infrastructure for developing, testing and releasing AI components, for example ‘just in time’ (JIT), zero standing privileges (ZSP), etc.

3. Continuously monitor running AI workloads and supporting services; trigger additional tests when anomalies or new threats are detected.

4. Share test results, threat intelligence and incident information promptly so all stakeholders can coordinate remediation and improve best practices. (a) Communicate security requirements, testing results, and incident information in a timely and effective manner. (b) Collaborate to develop and implement best practices for AI security. (c) Share threat intelligence and lessons learned. (d) Work together to address emerging AI security challenges. (e) Update the Testing suite as new AI paradigms emerge.

Implementation Guidelines for Cloud Service Providers (CSP)

Implementation best practices for this actor include (but are not limited to):

1. Provide Scalable and Secure Infrastructure for AI-Specific Automated Testing: CSPs must offer scalable and secure infrastructure optimized for the unique demands of AI security testing, including large datasets, complex models, and specialized hardware such as GPUs, TPUs, and FPGAs, optimized for AI model testing and adversarial attack simulation.

2. Offer Automated AI Security Testing Tools and Services: CSPs should provide a comprehensive suite of automated AI security testing tools and services that address the specific vulnerabilities of AI systems.

3. Enable Integration with AI-Specific CI/CD Pipelines: CSPs must facilitate the seamless integration of automated AI security testing tools and services into AI-specific CI/CD pipelines for model development, deployment, and monitoring.

4. Provide AI-Specific Security Monitoring and Logging: CSPs should provide enhanced security monitoring and logging capabilities tailored to the unique security challenges of AI systems such as adversarial attack detection, model drift monitoring, explainability Monitoring, and AI-specific logging (e.g., model updates, retraining, and changes in security configurations).

5. Facilitate Secure Collaboration for AI Security: CSPs should provide secure and collaborative environments for AI security testing, enabling MP, OSP, and other stakeholders to work together effectively. This may includes secure model sharing, collaborative testing platforms, threat intelligence sharing.

From CCM v4.1: Control Ownership Rationale. The implementation responsibility of this control is a shared responsibility between the CSP and CSC, however doing so independently from one another. Both parties and each independently are responsible for implementing a robust testing strategy which includes acceptance criteria of new information systems, upgrades and new versions.

Implementation Guidelines. Applicable to all service models: As early as the development phase of the SSDLC, the CSP should incorporate security testing to facilitate the identification of security flaws by developers, enabling timely remediation and minimizing the risk of vulnerabilities being introduced into production.

The following best practices should be followed for implementing an applications security testing strategy:

• a. SSDLC and Testing Management: The development team should follow the SSDLC with security best practices to create code that is secure by design, as well as use static and dynamic analysis tools to identify security loopholes present in the code

• b. Continuous CI/CD Testing: Continuous testing should be built into CI/CD pipelines:

  • i. Understand that CI/CD is just not delivering the code, rather also an opportunity to adopt a “shift-left” approach with continuous testing

  • ii. Pre-commit and post-commit hooks should be implemented and used

  • iii. A vulnerability scanner should be used to identify any third-party library issues

  • iv. An automated scanner should be used to identify hardcoded / default secrets, including access keys, secret key, credentials, private keys, etc.

• c. Static Application Security Testing (SAST): SAST should be used to analyze the application’s source code, bytecode, or binary code to detect issues early in the development lifecycle and identify security vulnerabilities, coding errors, and potential weaknesses that could be exploited by attackers (e.g., data/control flow, taint analysis)

• d. Dynamic Application Security Testing (DAST): DAST should be used to test the application in its running state to identify security vulnerabilities by sending requests and analyzing the responses (e.g., fuzz testing, session hijacking, injection testing)

• e. Interactive Application Security Testing (IAST): IAST should be used to combine elements of both SAST and DAST, identify security issues without the need for source code access, and provide real-time feedback on security vulnerabilities during the application’s runtime

• f. Penetration Testing: Penetration tests should be performed to simulate real-world cyberattacks to identify potential vulnerabilities and assess the effectiveness of the security measures in place

• g. Input Validation: Input validation test cases should be used to identify injection attacks (e.g., SQL injection, Command Injection, Cross-site scripting (XSS), Cross-Site Request Forgery (CSRF). This includes checking the type, format, length, and range of input data to ensure that it adheres to predefined criteria and does not contain any malicious or unauthorized content

• h. Information Output Handling: Information output filtering test cases should be used to identify information exfiltration attacks (e.g., cleartext output of passwords)

• i. Industry Best Practices: Security test cases should be employed according to OWASP Top 10. Consider also aligning test cases with various compliance standards (e.g., ISO/IEC 27001, AICPA TSC) depending on organizational strategy and requirements

• j. Continuous Monitoring: Continuous monitoring should be required once an application is deployed to test for a crash, DoS, DDoS, unauthenticated scans, etc.

• k. Applications Testing Automation:

  • i. The test team should leverage automation to expedite the testing completion process and for efficacy in reducing errors and surfacing security gaps

  • ii. Automated tools should test applications for both known and unknown vulnerabilities

  • iii. Criteria should be developed for assessing the automation required by an application, as not all systems will benefit equally

At minimum, the above multiple test types and integration points are needed to provide the appropriate level of assurance throughout a SSDLC.

[All Actors]

1. Implement comprehensive automated security testing throughout the AI lifecycle.

2. Use secured, controlled environments and infrastructure for developing, testing and releasing AI components, for example ‘just in time’ (JIT), zero standing privileges (ZSP), etc.

3. Continuously monitor running AI workloads and supporting services; trigger additional tests when anomalies or new threats are detected.

4. Share test results, threat intelligence and incident information promptly so all stakeholders can coordinate remediation and improve best practices. (a) Communicate security requirements, testing results, and incident information in a timely and effective manner. (b) Collaborate to develop and implement best practices for AI security. (c) Share threat intelligence and lessons learned. (d) Work together to address emerging AI security challenges.

AIS-06: Secure Application Deployment

Control Specification

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

Shared Implementation Guidelines

[Applicable to all providers (CSP, MP, OSP, AP) except AIC]

1. Define Deployment Strategy Scope: Establish provider-specific strategies for secure, standardized, and compliant application deployment as outlined in the provider-specific sections below. Ensure strategies cover the entire deployment lifecycle, including build, testing, staging, and production phases, with a focus on automation to reduce human error and ensure consistency.

2. Deployment Governance Structure: Establish clear roles and responsibilities for overseeing secure deployment processes, involving cross-functional teams (e.g., DevOps, security, compliance) and governance bodies. Define approval workflows that include senior management, security architects, and compliance officers to ensure deployments align with organizational security and regulatory requirements.

3. Deployment Documentation Standards: Define structured documentation standards for deployment processes, including configuration management, automation scripts, and compliance checklists. Use consistent templates to document deployment workflows, security controls, and rollback procedures to ensure traceability and auditability.

4. Deployment Management Framework: Implement a structured review and update process for deployment strategies. Conduct reviews at least annually or following significant changes (e.g., new deployment tools, infrastructure updates, or regulatory changes). Ensure alignment with relevant standards (e.g., NIST 800-53, ISO 27001, CIS Controls) and AI-specific frameworks like NIST AI Risk Management Framework. Automate policy enforcement where possible using CI/CD pipelines and configuration management tools.

5. Communication and Training Standards: Define requirements for communicating deployment strategies, including formal distribution of process documentation, mandatory training for DevOps and security teams, and awareness programs for stakeholders. Ensure deployment policies and automation tools are accessible via internal portals and that teams are trained on secure deployment practices and compliance requirements.

6. Quality Control and Automation Standards: Define policies for quality assurance of deployment processes, including automated security scanning, infrastructure-as-code (IaC) validation, and compliance checks within CI/CD pipelines. Implement automated testing (e.g., unit, integration, security tests) and monitoring to ensure deployments meet security and performance standards. Establish rollback mechanisms to address deployment failures securely.

Implementation Guidelines for Cloud Service Providers (CSP)

Policy Scope: Secure deployment strategies for cloud infrastructure supporting AI systems, including virtual machines, containers, serverless functions, and networking components. Policies should address automated provisioning, secure configuration of deployment pipelines, and compliance with cloud-specific standards (e.g., AWS Well-Architected Framework, Azure Security Benchmark). Ensure protection of deployment interfaces and secrets management (e.g., API keys, credentials).

[Applicable to all providers (CSP, MP, OSP, AP) except AIC]

1. Define Deployment Strategy Scope: Establish provider-specific strategies for secure, standardized, and compliant application deployment as outlined in the provider-specific sections below. Ensure strategies cover the entire deployment lifecycle, including build, testing, staging, and production phases, with a focus on automation to reduce human error and ensure consistency.

2. Deployment Governance Structure: Establish clear roles and responsibilities for overseeing secure deployment processes, involving cross-functional teams (e.g., DevOps, security, compliance) and governance bodies. Define approval workflows that include senior management, security architects, and compliance officers to ensure deployments align with organizational security and regulatory requirements.

3. Deployment Documentation Standards: Define structured documentation standards for deployment processes, including configuration management, automation scripts, and compliance checklists. Use consistent templates to document deployment workflows, security controls, and rollback procedures to ensure traceability and auditability.

4. Deployment Management Framework: Implement a structured review and update process for deployment strategies. Conduct reviews at least annually or following significant changes (e.g., new deployment tools, infrastructure updates, or regulatory changes). Ensure alignment with relevant standards (e.g., NIST 800-53, ISO 27001, CIS Controls) and AI-specific frameworks like NIST AI Risk Management Framework. Automate policy enforcement where possible using CI/CD pipelines and configuration management tools.

5. Communication and Training Standards: Define requirements for communicating deployment strategies, including formal distribution of process documentation, mandatory training for DevOps and security teams, and awareness programs for stakeholders. Ensure deployment policies and automation tools are accessible via internal portals and that teams are trained on secure deployment practices and compliance requirements.

6. Quality Control and Automation Standards: Define policies for quality assurance of deployment processes, including automated security scanning, infrastructure-as-code (IaC) validation, and compliance checks within CI/CD pipelines. Implement automated testing (e.g., unit, integration, security tests) and monitoring to ensure deployments meet security and performance standards. Establish rollback mechanisms to address deployment failures securely.

From CCM v4.1: Control Ownership Rationale. The implementation responsibility of this control is a shared responsibility between the CSP and CSC, however doing so independently from one another. The CSP should independently establish and implement strategies for secure application deployment.

Implementation Guidelines. Applicable to all service models: The following best practices should be followed for implementing an applications secure deployment strategy:

• a. Standardized Deployment Process: Standardized deployment processes should be implemented to ensure consistent and secure application deployments. This includes:

  • i. Security requirements definition based on application deployment needs and industry standards to ensure applications are protected from unauthorized access, data breaches, and other cybersecurity threats

  • ii. Automated deployment pipelines CI/CD should be established to automate the deployment process, minimizing manual intervention and errors

  • iii. Standardized deployment templates should be developed that encapsulate best practices and configurations for common application scenarios

  • iv. Automated or manual rollback procedures should be implemented in case of deployment failures or security issues. Regularly test rollback procedures to ensure their effectiveness

• b. Automation Requirements: Automation should be prioritized wherever possible to streamline deployment processes, enhance security, and improve overall efficiency. This includes:

  • i. Infrastructure as code (IaC) tools should be used to automate the provisioning and configuration of the cloud infrastructure

  • ii. Automated testing should be implemented to validate that applications are deployed correctly and securely in the cloud environment (e.g., testing for functional correctness, security configuration)

  • iii. Automated patch management systems implementation to ensure that cloud resources and applications are up-to-date with the latest security patches

  • iv. Automated Security Orchestration and Response (SOAR) platforms utilization to automate security response tasks (e.g., threat detection, investigation, and remediation)

• c. Deployment and Automation Technologies:

  • i. A curated list of approved deployment and automation technologies should be maintained that have been rigorously vetted for security and compatibility with the organization’s infrastructure and applications

  • ii. Regularly review and update this list to ensure it reflects the latest advancements in secure deployment technologies and best practices

• d. Integration with Existing Processes:

  • i. Secure application deployment practices should be identified and seamlessly integrated with existing application deployment processes to minimize disruption and ensure a cohesive deployment workflow

  • ii. Secure application deployment procedures should be adapted and aligned with the specific deployment tools, methodologies, and automation frameworks already in use

• e. Secure Application Deployment Customization:

  • i. Secure application deployment strategies should be customized to address the unique requirements of various deployment environments (e.g., different operating systems, network configurations, and cloud platforms)

  • ii. Security measures should be tailored to the specific vulnerabilities and risks associated with each deployment environment

• f. Application Deployment Monitoring:

  • i. Logging and monitoring mechanisms should be established to track secure application deployment activities, identify anomalies, and detect potential security breaches

  • ii. Real-time monitoring should be implemented to promptly alert security personnel of any suspicious or unauthorized activities during the deployment process

• g. Deployment Performance Metrics:

  • i. Quantitative metrics should be developed and utilized to assess the success of secure application deployments, including deployment time, error rates, and security compliance levels

  • ii. Metrics should be continuously monitored and evaluated to identify areas for improvement to optimize the secure application deployment process

AIS-07: Application Vulnerability Remediation

Control Specification

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

Shared Implementation Guidelines

[Applicable to all providers (CSP, MP, OSP, AP) excluding AIC unless otherwise specified]

1. Define Remediation Process Scope: Establish provider-specific processes for identifying, prioritizing, and remediating application security vulnerabilities as outlined in the provider-specific sections below. Ensure processes cover the entire vulnerability lifecycle, including detection, assessment, mitigation, and validation, across applications and interfaces.

2. Remediation Governance Structure: Establish clear roles and responsibilities for managing the remediation process, involving cross-functional teams (e.g., security, development, operations) and oversight by governance bodies. Define escalation workflows involving security leads, senior management, and compliance teams to prioritize and address critical vulnerabilities effectively.

3. Remediation Documentation Standards: Define structured documentation standards for the remediation process, including vulnerability reports, risk assessments, remediation plans, and validation records. Use consistent templates to document vulnerability details, impact analysis, mitigation steps, and post-remediation verification to ensure traceability and auditability.

4. Remediation Management Framework: Implement a structured process for managing remediation activities. Conduct regular vulnerability assessments and prioritize remediation based on risk severity (e.g., CVSS scores, exploitability). Review and update remediation processes at least annually or following significant changes (e.g., new vulnerabilities, system updates, or regulatory requirements). Ensure alignment with relevant standards (e.g., OWASP Top 10, NIST 800-53, ISO 27001) and AI-specific frameworks like NIST AI Risk Management Framework and OWASP LLM Top 10. Automate vulnerability tracking and reporting where possible using security tools.

5. Communication and Training Standards: Define requirements for communicating remediation processes, including formal distribution of vulnerability reports, mandatory training for developers and security teams on secure coding and remediation techniques, and awareness programs for stakeholders. Ensure remediation policies and tools are accessible via internal portals and that teams are trained on vulnerability management and compliance requirements.

6. Quality Control and Validation Standards: Define policies for quality assurance of remediation efforts, including requirements for re-testing mitigated vulnerabilities, conducting root cause analysis, and validating fixes through static/dynamic analysis or penetration testing. Establish automated monitoring and alerting to detect reintroduced vulnerabilities and ensure ongoing compliance with security standards.

Implementation Guidelines for Cloud Service Providers (CSP)

Policy Scope: Remediation processes for vulnerabilities in cloud infrastructure supporting AI systems, including virtual machines, containers, networking components, and APIs. Policies should address automated vulnerability scanning, patch management for cloud resources, and validation of fixes to ensure secure configurations. Ensure alignment with cloud-specific security benchmarks (e.g., CIS Benchmarks, AWS Foundational Security Best Practices).

[Applicable to all providers (CSP, MP, OSP, AP) excluding AIC unless otherwise specified]

1. Define Remediation Process Scope: Establish provider-specific processes for identifying, prioritizing, and remediating application security vulnerabilities as outlined in the provider-specific sections below. Ensure processes cover the entire vulnerability lifecycle, including detection, assessment, mitigation, and validation, across applications and interfaces.

2. Remediation Governance Structure: Establish clear roles and responsibilities for managing the remediation process, involving cross-functional teams (e.g., security, development, operations) and oversight by governance bodies. Define escalation workflows involving security leads, senior management, and compliance teams to prioritize and address critical vulnerabilities effectively.

3. Remediation Documentation Standards: Define structured documentation standards for the remediation process, including vulnerability reports, risk assessments, remediation plans, and validation records. Use consistent templates to document vulnerability details, impact analysis, mitigation steps, and post-remediation verification to ensure traceability and auditability.

4. Remediation Management Framework: Implement a structured process for managing remediation activities. Conduct regular vulnerability assessments and prioritize remediation based on risk severity (e.g., CVSS scores, exploitability). Review and update remediation processes at least annually or following significant changes (e.g., new vulnerabilities, system updates, or regulatory requirements). Ensure alignment with relevant standards (e.g., OWASP Top 10, NIST 800-53, ISO 27001) and AI-specific frameworks like NIST AI Risk Management Framework and OWASP LLM Top 10. Automate vulnerability tracking and reporting where possible using security tools.

5. Communication and Training Standards: Define requirements for communicating remediation processes, including formal distribution of vulnerability reports, mandatory training for developers and security teams on secure coding and remediation techniques, and awareness programs for stakeholders. Ensure remediation policies and tools are accessible via internal portals and that teams are trained on vulnerability management and compliance requirements.

6. Quality Control and Validation Standards: Define policies for quality assurance of remediation efforts, including requirements for re-testing mitigated vulnerabilities, conducting root cause analysis, and validating fixes through static/dynamic analysis or penetration testing. Establish automated monitoring and alerting to detect reintroduced vulnerabilities and ensure ongoing compliance with security standards.

From CCM: Implementation Guidelines. Applicable to all service models: Application security vulnerabilities are a serious threat to cloud-based applications. These vulnerabilities can be exploited by attackers to gain unauthorized access to applications, steal sensitive data, and disrupt operations. CSPs play a critical role in helping CSCs remediate application security vulnerabilities.

The following best practices should be followed for implementing a vulnerability remediation process:

• a. Vulnerability Remediation Scope: A process for defining the scope of a vulnerability remediation should be established (e.g., IaaS CSPs may only be responsible for remediating vulnerabilities in the underlying infrastructure, while PaaS CSPs may also be responsible for remediating vulnerabilities in the platform software)

• b. Remediation Plan: A remediation plan for each vulnerability should be developed and include the steps that need to be taken to remediate the vulnerability, the estimated time to remediate the vulnerability, and the resources that will be required

  • i. The plan should include processes and procedures for vulnerabilities remediation in coordination with development teams, the CSC, and for implementing security patches in a timely manner

• c. Remediation Prioritization and Risk Assessment:

  • i. The severity and potential impact of identified vulnerabilities should be assessed based on factors such as exploitability, target scope, and potential consequences

  • ii. Vulnerability assessment tools should be utilized to provide risk scores

  • iii. Vulnerabilities remediation should be prioritized based on their risk scores, considering factors such as business criticality, asset value, regulatory compliance requirements, and industry standard vulnerability scoring systems such as CVSS if applicable

  • iv. Threat intelligence feeds should be incorporated into the prioritization process to identify vulnerabilities actively exploited by attackers

• d. Track and Measure Progress: Progress on remediation efforts should be tracked and the effectiveness of the vulnerability remediation process measured

• e. Patch Management Automation: Application of patches should be automated to reduce the time and effort required to remediate vulnerabilities and improve the overall security posture of cloud-based applications (refer to TVM domain)

• f. Remediation Automation:

  • i. Configuration management tools should be utilized to automatically correct misconfigured security settings and enforce secure configurations across different environments using secure by default principles

  • ii. Automated code refactoring tools should be employed to address insecure coding practices and enforce secure coding guidelines within applications

  • iii. Automated dependency management tools should be utilized to update and replace vulnerable open-source components with patched or updated versions

  • iv. Automated remediation hooks should be implemented within the CI/CD pipeline to automatically remediate identified vulnerabilities before and after deployment

• g. Remediation Logging: Comprehensive logging of remediation activities should be established to track the remediation process and identify potential issues

• h. Post-Remediation Verification: Post-remediation verification steps should be implemented to ensure that vulnerabilities have been effectively addressed and that no new vulnerabilities have been introduced

• i. Continuous Remediation Monitoring: The effectiveness of the vulnerability remediation process should be continuously monitored and improvements made as needed

• j. Notification and Reporting: Notification and reporting mechanisms should be established to inform relevant stakeholders of any vulnerabilities detected and remediation actions taken

  • i. Communicate with CSCs any identified vulnerabilities and the plan to remediate them. Communication should be timely and transparent in accordance with agreed SLAs

Vulnerabilities should be identified and remediated as early as possible in the SSDLC and automated processes are ideal for such a task.

Vulnerability Scanning and Remediation Examples: To ensure that only secure and hardened container images are used in the application development process, integrate a vulnerability scanner into the CI/CD pipeline specifically for “image” scanning. This will guarantee that only secure “images” (also known as golden images) are incorporated into the application software builds.

Automated scanning tools are an effective solution for identifying and remediating such issues. For instance, cloud agent-based tools can be deployed on each active VM instance to continuously scan for third-party security vulnerabilities, with the frequency of scans determined by the organization’s security strategy (daily, weekly, etc.).

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.

Shared Implementation Guidelines

[Applicable to all providers (CSP, MP, OSP, AP) excluding AIC unless otherwise specified]

1. Establish provider-specific policy scopes for securing APIs, covering authorization, key management, testing, and threat mitigation across the API lifecycle (design, implementation, deployment, monitoring). Ensure policies address unique API risks like injection, abuse, or exposure.

2. Define roles for API security oversight, involving cross-functional teams (e.g., security engineers, API developers, compliance). Set approval workflows with senior management and security leads to align measures with organizational risk goals.

3. Create structured documentation standards for API security measures, including procedures for key management, authorization protocols, testing schedules, and threat mitigation. Use templates to document controls, risk assessments, and remediation steps consistently.

4. Implement a review process for API security measures. Conduct reviews and updates at least annually or after significant changes (e.g., new API endpoints, vulnerabilities, dependency updates). Align with standards like OWASP API Security Top 10, NIST SP 800-53, and applicable laws (e.g., GDPR, CCPA).

5. Define requirements for communicating API security policies: distribute formal documentation, mandate training for API developers and operators, and run awareness campaigns. Ensure accessibility via internal portals and comprehension across teams.

6. Set policies for API security quality assurance, including requirements for secure API design (e.g., rate limiting, input validation), regular testing (e.g., penetration testing, fuzzing), and monitoring (e.g., anomaly detection). Require audit logs for API access and usage.

Implementation Guidelines for Cloud Service Providers (CSP)

Policy Scope: API security policies cover infrastructure supporting AI systems (e.g., VMs, containers, networking). Address secure API configurations, key management for cloud APIs, and protection of interfaces exposed to MPs, OSPs, or APs. Include logging and monitoring for unauthorized access attempts.

[Applicable to all providers (CSP, MP, OSP, AP) excluding AIC unless otherwise specified]

1. Establish provider-specific policy scopes for securing APIs, covering authorization, key management, testing, and threat mitigation across the API lifecycle (design, implementation, deployment, monitoring). Ensure policies address unique API risks like injection, abuse, or exposure.

2. Define roles for API security oversight, involving cross-functional teams (e.g., security engineers, API developers, compliance). Set approval workflows with senior management and security leads to align measures with organizational risk goals.

3. Create structured documentation standards for API security measures, including procedures for key management, authorization protocols, testing schedules, and threat mitigation. Use templates to document controls, risk assessments, and remediation steps consistently.

4. Implement a review process for API security measures. Conduct reviews and updates at least annually or after significant changes (e.g., new API endpoints, vulnerabilities, dependency updates). Align with standards like OWASP API Security Top 10, NIST SP 800-53, and applicable laws (e.g., GDPR, CCPA).

5. Define requirements for communicating API security policies: distribute formal documentation, mandate training for API developers and operators, and run awareness campaigns. Ensure accessibility via internal portals and comprehension across teams.

6. Set policies for API security quality assurance, including requirements for secure API design (e.g., rate limiting, input validation), regular testing (e.g., penetration testing, fuzzing), and monitoring (e.g., anomaly detection). Require audit logs for API access and usage.

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.

Shared Implementation Guidelines

[Applicable to all providers (CSP, MP, OSP, AP) excluding AIC unless otherwise specified]

1. Define Input Validation Scope: Establish provider-specific processes for validating, filtering, modifying, or blocking inputs to protect against adversarial patterns, failure patterns, and unwanted behavior, as outlined in the provider-specific sections below. Ensure processes cover all input sources (e.g., user inputs, APIs, data feeds) throughout the application lifecycle, including development, deployment, and operation.

2. Input Validation Governance Structure: Establish clear roles and responsibilities for managing input validation processes, involving cross-functional teams (e.g., security, data science, development) and oversight by governance bodies. Define approval workflows involving senior management, security leads, and compliance teams to ensure alignment with organizational policies and regulatory requirements.

3. Input Validation Documentation Standards: Define structured documentation standards for input validation processes, including detailed procedures, adversarial pattern libraries, and mitigation strategies specific to each provider’s scope. Use consistent templates to document input validation rules, risk assessments, and response actions for detected threats to ensure traceability and auditability.

4. Input Validation Management Framework: Implement a structured review process for input validation policies and mechanisms. Conduct reviews and updates at least annually or following significant system changes (e.g., new input sources, updated threat models, or regulatory changes). Ensure alignment with relevant laws, regulations, and standards (e.g., GDPR, CCPA, ISO 27001, OWASP Top 10) and AI-specific frameworks such as NIST AI Risk Management Framework and OWASP LLM Top 10. Incorporate automated tools for real-time input validation and threat detection where possible.

5. Communication and Training Standards: Define requirements for communicating input validation policies, including formal distribution of documentation, mandatory training programs for developers and operators on adversarial pattern recognition and mitigation, and awareness campaigns for stakeholders. Establish standards for ensuring policy accessibility (e.g., internal portals) and comprehension across relevant teams.

6. Quality Control Standards: Define policies for quality assurance of input validation processes, including requirements for testing validation mechanisms (e.g., fuzz testing, adversarial simulation), monitoring input-related incidents, and validating mitigation effectiveness. Incorporate automated validation tools and anomaly detection systems to ensure robust protection against adversarial inputs and compliance with organizational policies.

Implementation Guidelines for Cloud Service Providers (CSP)

Policy Scope: Input validation policies covering the infrastructure supporting AI systems, including virtual machines, containers, networking, and APIs. Policies should address validation of configuration inputs, API requests, and data flows to prevent adversarial exploitation of cloud resources. Ensure protection against failure patterns (e.g., misconfigurations) and compliance with cloud-specific security standards (e.g., AWS Well-Architected Framework, Azure Security Benchmark).

[Applicable to all providers (CSP, MP, OSP, AP) excluding AIC unless otherwise specified]

1. Define Input Validation Scope: Establish provider-specific processes for validating, filtering, modifying, or blocking inputs to protect against adversarial patterns, failure patterns, and unwanted behavior, as outlined in the provider-specific sections below. Ensure processes cover all input sources (e.g., user inputs, APIs, data feeds) throughout the application lifecycle, including development, deployment, and operation.

2. Input Validation Governance Structure: Establish clear roles and responsibilities for managing input validation processes, involving cross-functional teams (e.g., security, data science, development) and oversight by governance bodies. Define approval workflows involving senior management, security leads, and compliance teams to ensure alignment with organizational policies and regulatory requirements.

3. Input Validation Documentation Standards: Define structured documentation standards for input validation processes, including detailed procedures, adversarial pattern libraries, and mitigation strategies specific to each provider’s scope. Use consistent templates to document input validation rules, risk assessments, and response actions for detected threats to ensure traceability and auditability.

4. Input Validation Management Framework: Implement a structured review process for input validation policies and mechanisms. Conduct reviews and updates at least annually or following significant system changes (e.g., new input sources, updated threat models, or regulatory changes). Ensure alignment with relevant laws, regulations, and standards (e.g., GDPR, CCPA, ISO 27001, OWASP Top 10) and AI-specific frameworks such as NIST AI Risk Management Framework and OWASP LLM Top 10. Incorporate automated tools for real-time input validation and threat detection where possible.

5. Communication and Training Standards: Define requirements for communicating input validation policies, including formal distribution of documentation, mandatory training programs for developers and operators on adversarial pattern recognition and mitigation, and awareness campaigns for stakeholders. Establish standards for ensuring policy accessibility (e.g., internal portals) and comprehension across relevant teams.

6. Quality Control Standards: Define policies for quality assurance of input validation processes, including requirements for testing validation mechanisms (e.g., fuzz testing, adversarial simulation), monitoring input-related incidents, and validating mitigation effectiveness. Incorporate automated validation tools and anomaly detection systems to ensure robust protection against adversarial inputs and compliance with organizational policies.

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.

Shared Implementation Guidelines

[Applicable to all providers (CSP, MP, OSP, AP) excluding AIC unless otherwise specified]

1. Define Output Validation Scope: Establish provider-specific processes for validating, filtering, modifying, or blocking outputs to protect against adversarial patterns, failure patterns, and unwanted behavior, as outlined in the provider-specific sections below. Ensure processes cover all output types (e.g., API responses, model predictions, user-facing data) throughout the application lifecycle, including development, deployment, and operation.

2. Output Validation Governance Structure: Establish clear roles and responsibilities for managing output validation processes, involving cross-functional teams (e.g., security, data science, development) and oversight by governance bodies. Define approval workflows involving senior management, security leads, and compliance teams to ensure alignment with organizational policies and regulatory requirements.

3. Output Validation Documentation Standards: Define structured documentation standards for output validation processes, including detailed procedures, adversarial pattern libraries, and mitigation strategies specific to each provider’s scope. Use consistent templates to document output validation rules, risk assessments, and response actions for detected threats to ensure traceability and auditability.

4. Output Validation Management Framework: Implement a structured review process for output validation policies and mechanisms. Conduct reviews and updates at least annually or following significant system changes (e.g., new output types, updated threat models, or regulatory changes). Ensure alignment with relevant laws, regulations, and standards (e.g., GDPR, CCPA, ISO 27001, OWASP Top 10) and AI-specific frameworks such as NIST AI Risk Management Framework and OWASP LLM Top 10. Incorporate automated tools for real-time output validation and threat detection where possible.

5. Communication and Training Standards: Define requirements for communicating output validation policies, including formal distribution of documentation, mandatory training programs for developers and operators on adversarial pattern recognition and mitigation, and awareness campaigns for stakeholders. Establish standards for ensuring policy accessibility (e.g., internal portals) and comprehension across relevant teams.

6. Quality Control Standards: Define policies for quality assurance of output validation processes, including requirements for testing validation mechanisms (e.g., adversarial testing, output monitoring), monitoring output-related incidents, and validating mitigation effectiveness. Incorporate automated validation tools and anomaly detection systems to ensure robust protection against adversarial outputs and compliance with organizational policies.

Implementation Guidelines for Cloud Service Providers (CSP)

Policy Scope: Output validation policies covering the infrastructure supporting AI systems, including API responses, configuration data, and logs generated by virtual machines, containers, and networking components. Policies should address validation of outputs to prevent adversarial exploitation (e.g., data leakage via misconfigured APIs), failure patterns (e.g., erroneous configurations), and unwanted behavior (e.g., excessive resource usage). Ensure compliance with cloud-specific security standards (e.g., AWS Well-Architected Framework, Azure Security Benchmark).

[Applicable to all providers (CSP, MP, OSP, AP) excluding AIC unless otherwise specified]

1. Define Output Validation Scope: Establish provider-specific processes for validating, filtering, modifying, or blocking outputs to protect against adversarial patterns, failure patterns, and unwanted behavior, as outlined in the provider-specific sections below. Ensure processes cover all output types (e.g., API responses, model predictions, user-facing data) throughout the application lifecycle, including development, deployment, and operation.

2. Output Validation Governance Structure: Establish clear roles and responsibilities for managing output validation processes, involving cross-functional teams (e.g., security, data science, development) and oversight by governance bodies. Define approval workflows involving senior management, security leads, and compliance teams to ensure alignment with organizational policies and regulatory requirements.

3. Output Validation Documentation Standards: Define structured documentation standards for output validation processes, including detailed procedures, adversarial pattern libraries, and mitigation strategies specific to each provider’s scope. Use consistent templates to document output validation rules, risk assessments, and response actions for detected threats to ensure traceability and auditability.

4. Output Validation Management Framework: Implement a structured review process for output validation policies and mechanisms. Conduct reviews and updates at least annually or following significant system changes (e.g., new output types, updated threat models, or regulatory changes). Ensure alignment with relevant laws, regulations, and standards (e.g., GDPR, CCPA, ISO 27001, OWASP Top 10) and AI-specific frameworks such as NIST AI Risk Management Framework and OWASP LLM Top 10. Incorporate automated tools for real-time output validation and threat detection where possible.

5. Communication and Training Standards: Define requirements for communicating output validation policies, including formal distribution of documentation, mandatory training programs for developers and operators on adversarial pattern recognition and mitigation, and awareness campaigns for stakeholders. Establish standards for ensuring policy accessibility (e.g., internal portals) and comprehension across relevant teams.

6. Quality Control Standards: Define policies for quality assurance of output validation processes, including requirements for testing validation mechanisms (e.g., adversarial testing, output monitoring), monitoring output-related incidents, and validating mitigation effectiveness. Incorporate automated validation tools and anomaly detection systems to ensure robust protection against adversarial outputs and compliance with organizational policies.

AIS-11: Agents Security Boundaries

Control Specification

Establish security boundaries for agents.

Shared Implementation Guidelines

[All Actors]

1. Define security boundaries for each agent, based on role-based access, data-sensitivity levels and environment (dev / test / staging / prod); apply need-to-know at every stage.

2. Implement key attack-surface controls (input/output validation, access controls, encryption, execution isolation) at user interfaces, data pipelines and model-runtime layers.

3. Maintain boundary consistency across all environments by carrying the same rules, secrets segregation and hardening settings from test through production.

4. Deploy environment-specific protections (network segmentation, IAM policies, logging, monitoring) that equal or exceed production standards.

5. Document boundaries, risk assessments, and control ownership and keep records aligned with policy, standards, and regulation.

6. Test boundary effectiveness via penetration tests, access-control validation, and control assessments; cover all threat categories and lifecycle stages.

7. Review and update boundaries and controls regularly to reflect new threats, regulatory changes, and operational shifts, using monitoring insights for improvement.

8. Operate AI honeypots or decoy assets where appropriate to detect early attempts at crossing security boundaries.

Implementation Guidelines for Cloud Service Providers (CSP)

Role Specific:

1. Continuously improve SSRM practices across AI model development, orchestration services, applications, and cloud environments to address new vulnerabilities and risks.

2. Regularly assess SSRM processes for AI models, applications, and cloud services to ensure they remain effective in the face of evolving threats and supply chain complexities.

3. Work with third-party vendors to improve their SSRM practices, ensuring they remain aligned with the organization’s evolving risk management framework.

4. Use performance metrics and audit results to drive improvements in SSRM practices and ensure that supply chain security remains a priority.

[All Actors]

1. Define security boundaries for each agent, based on role-based access, data-sensitivity levels and environment (dev / test / staging / prod); apply need-to-know at every stage.

2. Implement key attack-surface controls (input/output validation, access controls, encryption, execution isolation) at user interfaces, data pipelines and model-runtime layers.

3. Maintain boundary consistency across all environments by carrying the same rules, secrets segregation and hardening settings from test through production.

4. Deploy environment-specific protections (network segmentation, IAM policies, logging, monitoring) that equal or exceed production standards.

5. Document boundaries, risk assessments, and control ownership and keep records aligned with policy, standards, and regulation.

6. Test boundary effectiveness via penetration tests, access-control validation, and control assessments; cover all threat categories and lifecycle stages.

7. Review and update boundaries and controls regularly to reflect new threats, regulatory changes, and operational shifts, using monitoring insights for improvement.

8. Operate AI honeypots or decoy assets where appropriate to detect early attempts at crossing security boundaries.

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.

Shared Implementation Guidelines

[Applicable to all providers (CSP, MP, OSP, AP) excluding AIC unless otherwise specified]

1. Establish provider-specific policy scopes for implementing model development practices within the SDLC. Ensure policies address version control, code review, static code analysis, dynamic analysis, and other secure development practices across all SDLC phases (planning, design, development, testing, deployment, maintenance).

2. Define roles for overseeing model development practices, involving cross-functional teams (e.g., AI engineers, security, DevOps). Set approval workflows with senior management and technical leads to ensure alignment with organizational SDLC standards and security objectives.

3. Create structured documentation standards for model development policies, including procedures for version control, code review processes, and static code analysis requirements. Use templates to document workflows, tool usage (e.g., Git, Snyk), and compliance with SDLC stages.

4. Implement a review process for model development policies. Conduct reviews at least annually or after significant changes (e.g., new tools, updated SDLC processes, emerging vulnerabilities). Align with standards like OWASP Secure Coding Practices, NIST SSDF, and AI-specific frameworks like NIST AI RMF, where applicable.

5. Define requirements for communicating model development policies: distribute formal documentation, mandate training for AI developers and engineers on SDLC practices, and run awareness campaigns on secure coding. Ensure accessibility through internal portals and comprehension across teams.

6. Set policies for quality assurance in model development, including requirements for automated version control (e.g., Git commits, branching), mandatory peer code reviews, and static code analysis (e.g., SonarQube, Checkmarx) before deployment. Require audit trails for development changes and compliance with SDLC checkpoints.

Implementation Guidelines for Cloud Service Providers (CSP)

Policy Scope:

Model development policies cover infrastructure supporting AI model development (e.g., compute, storage, CI/CD pipelines). Ensure version control for infrastructure-as-code (IaC), code reviews for deployment scripts, and static analysis of configuration files within the SDLC. Ensure secure integration with MPs or OSPs during model deployment, following standard API integrations, with appropriate authentication/authorization, encryption, auditing, and logging.

[Applicable to all providers (CSP, MP, OSP, AP) excluding AIC unless otherwise specified]

1. Establish provider-specific policy scopes for implementing model development practices within the SDLC. Ensure policies address version control, code review, static code analysis, dynamic analysis, and other secure development practices across all SDLC phases (planning, design, development, testing, deployment, maintenance).

2. Define roles for overseeing model development practices, involving cross-functional teams (e.g., AI engineers, security, DevOps). Set approval workflows with senior management and technical leads to ensure alignment with organizational SDLC standards and security objectives.

3. Create structured documentation standards for model development policies, including procedures for version control, code review processes, and static code analysis requirements. Use templates to document workflows, tool usage (e.g., Git, Snyk), and compliance with SDLC stages.

4. Implement a review process for model development policies. Conduct reviews at least annually or after significant changes (e.g., new tools, updated SDLC processes, emerging vulnerabilities). Align with standards like OWASP Secure Coding Practices, NIST SSDF, and AI-specific frameworks like NIST AI RMF, where applicable.

5. Define requirements for communicating model development policies: distribute formal documentation, mandate training for AI developers and engineers on SDLC practices, and run awareness campaigns on secure coding. Ensure accessibility through internal portals and comprehension across teams.

6. Set policies for quality assurance in model development, including requirements for automated version control (e.g., Git commits, branching), mandatory peer code reviews, and static code analysis (e.g., SonarQube, Checkmarx) before deployment. Require audit trails for development changes and compliance with SDLC checkpoints.

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.

Shared Implementation Guidelines

[Applicable to all providers (CSP, MP, OSP, AP) excluding AIC unless otherwise specified]

1. Establish provider-specific policy scopes for implementing sandboxing techniques in tools and plugins used by agents. Ensure policies address isolation of execution environments (e.g., containers, VMs), prevention of unintended interactions with critical systems/data, and restriction of lateral movement across all deployment and runtime scenarios.

2. Define roles for overseeing sandboxing implementation, involving cross-functional teams (e.g., security architects, DevOps, compliance). Set approval workflows with senior management and security leads to ensure alignment with organizational isolation standards and risk management goals.

3. Create structured documentation standards for sandboxing policies, including procedures for setting up isolated environments (e.g., Docker, Firejail), defining access boundaries, and monitoring for breaches. Use templates to document sandbox configurations, isolation tests, and mitigation strategies for breakout risks.

4. Implement a review process for sandboxing policies. Conduct reviews at least annually or after significant changes (e.g., new tools/plugins, updated sandbox tech, identified vulnerabilities). Align with standards like NIST 800-53 (SC-7 Boundary Protection), OWASP Secure Isolation Guidelines, and AI-specific frameworks like NIST AI RMF where applicable.

5. Define requirements for communicating sandboxing policies: distribute formal documentation, mandate training for teams managing sandboxed environments (e.g., developers, operators), and run awareness campaigns on isolation best practices. Ensure accessibility via internal portals and comprehension across teams.

6. Set policies for quality assurance in sandboxing, including requirements for automated isolation testing (e.g., container escape tests), monitoring for unintended interactions (e.g., system call auditing), and restricting lateral movement (e.g., network segmentation). Require audit logs for sandbox activities and breach attempts.

Implementation Guidelines for Cloud Service Providers (CSP)

Policy Scope:

Sandboxing policies cover tools and plugins executed on CSP infrastructure (e.g., monitoring tools, deployment plugins). Implement isolated environments (e.g., VMs, containers) to prevent interactions with critical CSP systems (e.g., hypervisors, tenant data) and limit lateral movement to MPs, OSPs, or APs.

[Applicable to all providers (CSP, MP, OSP, AP) excluding AIC unless otherwise specified]

1. Establish provider-specific policy scopes for implementing sandboxing techniques in tools and plugins used by agents. Ensure policies address isolation of execution environments (e.g., containers, VMs), prevention of unintended interactions with critical systems/data, and restriction of lateral movement across all deployment and runtime scenarios.

2. Define roles for overseeing sandboxing implementation, involving cross-functional teams (e.g., security architects, DevOps, compliance). Set approval workflows with senior management and security leads to ensure alignment with organizational isolation standards and risk management goals.

3. Create structured documentation standards for sandboxing policies, including procedures for setting up isolated environments (e.g., Docker, Firejail), defining access boundaries, and monitoring for breaches. Use templates to document sandbox configurations, isolation tests, and mitigation strategies for breakout risks.

4. Implement a review process for sandboxing policies. Conduct reviews at least annually or after significant changes (e.g., new tools/plugins, updated sandbox tech, identified vulnerabilities). Align with standards like NIST 800-53 (SC-7 Boundary Protection), OWASP Secure Isolation Guidelines, and AI-specific frameworks like NIST AI RMF where applicable.

5. Define requirements for communicating sandboxing policies: distribute formal documentation, mandate training for teams managing sandboxed environments (e.g., developers, operators), and run awareness campaigns on isolation best practices. Ensure accessibility via internal portals and comprehension across teams.

6. Set policies for quality assurance in sandboxing, including requirements for automated isolation testing (e.g., container escape tests), monitoring for unintended interactions (e.g., system call auditing), and restricting lateral movement (e.g., network segmentation). Require audit logs for sandbox activities and breach attempts.

AIS-14: AI Cache Protection

Control Specification

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

Shared Implementation Guidelines

[Applicable to all providers (CSP, MP, OSP, AP) excluding AIC unless otherwise specified]

1. Establish provider-specific policy scopes for securing cache systems in LLMs. Ensure policies address encryption of cached data follow CEK controls, enforcement of strict access controls, and mechanisms to prevent retention of sensitive information in fast memory (e.g., clearing caches after use) across all LLM-related operations.

2. Define roles for overseeing cache security measures, involving cross-functional teams (e.g., security engineers, AI developers, compliance). Set approval workflows with senior management and security leads to ensure alignment with organizational data protection standards and risk management goals.

3. Create structured documentation standards for cache security policies, including procedures for encryption (e.g., AES-256), access control implementation (e.g., RBAC), and data retention mitigation (e.g., automatic cache expiry). Use templates to document configurations, access logs, and compliance checks.

4. Implement a review process for cache security policies. Conduct reviews at least annually or after significant changes (e.g., new caching mechanisms, updated LLM workloads, identified vulnerabilities). Align with standards like NIST 800-53 (SC-28 Data at Rest), OWASP Data Protection Guidelines, and AI-specific frameworks like NIST AI RMF, where applicable.

5. Define requirements for communicating cache security policies: distribute formal documentation, mandate training for teams managing LLMs (e.g., developers, operators), and run awareness campaigns on data protection risks. Ensure accessibility via internal portals and comprehension across teams.

6. Set policies for quality assurance in cache security, including requirements for encryption validation (e.g., key management audits), access control testing (e.g., penetration tests), and retention mitigation checks (e.g., memory forensics). Require audit logs for cache access and clearing events to detect unauthorized access or poisoning attempts.

Implementation Guidelines for Cloud Service Providers (CSP)

Policy Scope:

Cache security policies cover cache systems supporting LLMs on CSP infrastructure (e.g., in-memory databases, GPU memory). Implement encryption for cached data, strict access controls for CSP-managed caches, and mechanisms to clear sensitive LLM data from fast memory, mitigating risks of unauthorized access or poisoning across MPs, OSPs, or APs.

[Applicable to all providers (CSP, MP, OSP, AP) excluding AIC unless otherwise specified]

1. Establish provider-specific policy scopes for securing cache systems in LLMs. Ensure policies address encryption of cached data follow CEK controls, enforcement of strict access controls, and mechanisms to prevent retention of sensitive information in fast memory (e.g., clearing caches after use) across all LLM-related operations.

2. Define roles for overseeing cache security measures, involving cross-functional teams (e.g., security engineers, AI developers, compliance). Set approval workflows with senior management and security leads to ensure alignment with organizational data protection standards and risk management goals.

3. Create structured documentation standards for cache security policies, including procedures for encryption (e.g., AES-256), access control implementation (e.g., RBAC), and data retention mitigation (e.g., automatic cache expiry). Use templates to document configurations, access logs, and compliance checks.

4. Implement a review process for cache security policies. Conduct reviews at least annually or after significant changes (e.g., new caching mechanisms, updated LLM workloads, identified vulnerabilities). Align with standards like NIST 800-53 (SC-28 Data at Rest), OWASP Data Protection Guidelines, and AI-specific frameworks like NIST AI RMF where applicable.

5. Define requirements for communicating cache security policies: distribute formal documentation, mandate training for teams managing LLMs (e.g., developers, operators), and run awareness campaigns on data protection risks. Ensure accessibility via internal portals and comprehension across teams.

6. Set policies for quality assurance in cache security, including requirements for encryption validation (e.g., key management audits), access control testing (e.g., penetration tests), and retention mitigation checks (e.g., memory forensics). Require audit logs for cache access and clearing events to detect unauthorized access or poisoning attempts.

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

Shared Implementation Guidelines

[Applicable to all providers (CSP, MP, OSP, AP) excluding AIC unless otherwise specified]

1. Establish provider-specific policy scopes for implementing mechanisms to distinguish user-provided input instructions from data and system instructions. Ensure policies address input formatting techniques (e.g., border strings, data marking) and standard templates to reduce ambiguity and prevent incorrect prioritization across model interactions.

2. Define roles for overseeing input distinction mechanisms, involving cross-functional teams (e.g., AI developers, security engineers, compliance). Set approval workflows with senior management and technical leads to ensure alignment with organizational security and operational standards.

3. Create structured documentation standards for input distinction policies, including procedures for implementing border strings (e.g., ###USER###), data marking (e.g., metadata tags), and standard templates for user/system/data inputs. Use templates to document formatting rules, template designs, and validation checks.

4. Implement a review process for input distinction policies. Conduct reviews at least annually or after significant changes (e.g., new model architectures, updated input handling, identified exploits). Align with standards like OWASP Secure Input Handling, NIST 800-53 (SI-10), and AI-specific frameworks like NIST AI RMF, where applicable.

5. Define requirements for communicating input distinction policies: distribute formal documentation, mandate training for teams developing or managing models (e.g., developers, operators), and run awareness campaigns on secure input handling. Ensure accessibility via internal portals and comprehension across teams.

6. Set policies for quality assurance in input distinction, including requirements for automated validation of input formatting (e.g., regex checks for border strings), testing for ambiguity or misprioritization (e.g., adversarial input tests), and monitoring for incorrect instruction handling (e.g., logging misinterpretations). Require audit logs for input processing events.

Implementation Guidelines for Cloud Service Providers (CSP)

Policy Scope:

Input distinction policies cover infrastructure supporting AI models (e.g., APIs, data pipelines). Implement mechanisms to tag and format inputs (e.g., user vs. system) at the infrastructure level, ensuring clear handoff to MPs or OSPs. Use standard templates for API payloads to limit ambiguity in downstream model interactions.

[Applicable to all providers (CSP, MP, OSP, AP) excluding AIC unless otherwise specified]

1. Establish provider-specific policy scopes for implementing mechanisms to distinguish user-provided input instructions from data and system instructions. Ensure policies address input formatting techniques (e.g., border strings, data marking) and standard templates to reduce ambiguity and prevent incorrect prioritization across model interactions.

2. Define roles for overseeing input distinction mechanisms, involving cross-functional teams (e.g., AI developers, security engineers, compliance). Set approval workflows with senior management and technical leads to ensure alignment with organizational security and operational standards.

3. Create structured documentation standards for input distinction policies, including procedures for implementing border strings (e.g., ###USER###), data marking (e.g., metadata tags), and standard templates for user/system/data inputs. Use templates to document formatting rules, template designs, and validation checks.

4. Implement a review process for input distinction policies. Conduct reviews at least annually or after significant changes (e.g., new model architectures, updated input handling, identified exploits). Align with standards like OWASP Secure Input Handling, NIST 800-53 (SI-10), and AI-specific frameworks like NIST AI RMF, where applicable.

5. Define requirements for communicating input distinction policies: distribute formal documentation, mandate training for teams developing or managing models (e.g., developers, operators), and run awareness campaigns on secure input handling. Ensure accessibility via internal portals and comprehension across teams.

6. Set policies for quality assurance in input distinction, including requirements for automated validation of input formatting (e.g., regex checks for border strings), testing for ambiguity or misprioritization (e.g., adversarial input tests), and monitoring for incorrect instruction handling (e.g., logging misinterpretations). Require audit logs for input processing events.

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.

Shared Implementation Guidelines

[ AI providers MP, OSP, and AP] and AIC unless exempted.

1. Preparedness Planning: Establish comprehensive strategies to maintain essential functions during disruptions, with documented procedures for system restoration and function resumption with defined RTO and RPO.

2. Redundancy Implementation: Deploy backup systems, duplicated resources, and alternative processing pathways to prevent single-point vulnerabilities across the entire solution stack.

3. Collaborative Incident Response: Maintain clear communication channels and coordinated protocols for rapid joint action when unexpected challenges arise.

4. Regular Simulation Exercises: Conduct scheduled scenario-based readiness assessments to validate recovery procedures and identify improvement opportunities.

5. Continuous Enhancement: Implement feedback mechanisms to evolve resilience capabilities based on lessons from actual events and preparation activities.

6. Transparent Documentation: Maintain accessible records of architecture diagrams, dependency maps, and recovery instructions for all system components.

7. Shared Responsibility Matrix: Clearly define each party’s accountability for maintaining operational stability throughout normal conditions and during exceptional circumstances.

8. Compliance Verification: Ensure all safeguards meet or exceed applicable industry standards and regulatory requirements for critical system protection.

9. Approval Process: Conduct initial technical assessment by subject matter experts(SMEs) for accuracy and completeness which should be then reviewed by cross-functional stakeholders for interdependency validation. Present final documentation to all stakeholders for formal endorsement

10. Communication: Distribute approved policies through multiple channels and briefing sessions with stakeholders and personnel with key roles. Create a shared terminology reference to ensure consistent understanding of terms and method for communication protocols for coordinated response.

11. Update: Schedule comprehensive review at minimum annually, while performing immediate assessment when there is architectural, system or dependency change. Updates should be associated with trigger events or review cycles and also need to be done when regulatory or compliance requirements dictate.

12. Change Management: Change control processes ensure that changes to the environment are carefully planned, reviewed, approved by Change Control Board, and implemented in a controlled manner. This helps prevent unauthorized or unintended changes that could disrupt service delivery or compromise security. Documentation of rollback procedures and post change validation.

Implementation Guidelines for Cloud Service Providers (CSP)

Policies and procedures should: a) Clearly define the scope of business continuity management (BCM) and operational resilience (OR) governance across CSP-managed cloud infrastructure and services, including environments supporting AI workloads. b) Assign defined roles, responsibilities, and authority for BCM and OR oversight, decision-making, and policy ownership within the organization. c) Be formally approved by appropriate senior management, with documented evidence of approval and version control. d) Reference and govern supporting BCM and OR artifacts (e.g., impact analyses, continuity strategies, recovery plans, and resilience testing), as defined under related controls. e) Establish requirements for communicating BCM and OR policies to relevant internal stakeholders and, where applicable, customers under shared responsibility arrangements. f) Require periodic evaluation of BCM and OR effectiveness, including consideration of resilience performance for AI-related infrastructure and services. g) Require BCM and OR policies and procedures to be reviewed and updated at least annually and upon significant changes to infrastructure architecture, AI service models, workload characteristics, risk profile, or regulatory obligations.

From CCM v4.1: Control Ownership Rationale. The implementation responsibility for this control is shared between both the CSC and the CSP, however it is expected that the control is implemented independently by each party. Each party is expected to have different business continuity management and operational resilience requirements that they should achieve respectively to their geographical location, contractual, and regulatory ecosystem.

Implementation Guidelines. Establishing policies and procedures for business continuity management (BCM) and operational resilience is imperative for CSPs to maintain uninterrupted cloud services delivery, promptly recover from disruptions, and effectively manage crises. For CSCs, the implementation of these policies provides continuous access to critical services, even in the face of unforeseen events or cyber threats. CSCs can rely on the CSP’s commitment to operational resilience, knowing that robust measures are in place to safeguard against disruptions and swiftly respond to incidents.

Collaboration between the CSP and the CSC is essential to ensure a robust business continuity strategy. The policy should also establish a clear understanding of how the CSP and CSC will work together during disruptive incidents, including coordinated incident response and recovery efforts.

The CSP should define the roles and responsibilities that are needed for business continuity and operational resilience implementation. Additionally, the specific responsibilities may vary depending on the type of cloud service and the service level agreements in place.

The CSP is responsible for the appropriateness of the policy, framework for objectives, risk appetite and risk tolerance.

IaaS Provider: The CSP is responsible for establishing and implementing documented business continuity management and operational resilience policies, procedures, processes and standards for the underlying specific infrastructure, consisting of servers, storage, networking and virtualization. The CSP is responsible for providing resilient infrastructure that should secure CSC’s business continuity and disaster recovery.

PaaS Provider: The CSP is responsible for establishing and implementing business continuity management and operational resilience policies, procedures, processes and standards for the underlying development platform that enables CSC to build their own applications. The CSP is responsible for providing a resilient development platform that should enable CSC to continue its development activities.

SaaS Provider: The CSP is responsible for establishing and implementing business continuity management and operational resilience policies, procedures, processes and standards for the applications and delivered software that enables CSC to build their own business processes and upload their data. The CSP is responsible for providing resilient applications and software that should enable the CSC to continue their business processes in case of a disaster.

Policies should include (but not limited to) provisions on the following:

• a. Scope and Objectives:

  • i. An outline of the cloud-based systems, applications, data, and processes that fall under the purview of the policy

  • ii. The goals and intended outcomes of the policy, such as ensuring business continuity, minimizing data loss and downtime, and maintaining compliance with regulatory requirements

  • iii. The policy’s objectives with the organization’s overall strategic goals and risk management framework

• b. Business Impact Disruptions and Risks: A comprehensive BIA and risk assessment to identify potential threats, vulnerabilities, and hazards that could disrupt critical business operations

• c. Business Continuity Strategy (BCS): Business continuity objectives that align with the organization’s overall risk tolerance and BC strategic goals

  • i. A tailored BCS should be developed for each critical business process, asset, and resource, considering the potential disruptions and risks identified in the BIA and risk assessment

  • ii. BCSs should be designed to support the timely and effective recovery of critical business operations, minimizing downtime and maximizing the organization’s ability to deliver products and services to customers

  • iii. BCSs should be documented including detailed recovery procedures, roles and responsibilities, and communication plans

• d. Business Continuity Plan (BCP): BCPs that address specific types of cloud disruptions and scenarios.

  • i. Documented BCSs should be translated into actionable BCPs that provide step-by-step instructions for responding to and recovering from disruptions

  • ii. Responsibilities and timelines should be assigned for each task outlined in the BCPs so that all relevant personnel are aware of their roles and responsibilities

  • iii. BCPs should be integrated into the organization’s overall incident response and disaster recovery plans, to support a coordinated and effective response to disruptions

• e. BCM and OR Documentation: A documentation of BCM and OR policies, procedures, and plans in a centralized and accessible location

• f. Business Continuity Exercises: Requirements to conduct regular BCM and OR exercises to test the effectiveness of plans and procedures

• g. Relevant Cloud Stakeholders Communication: Communication plans for BCM and OR activities involving key stakeholders

• h. Cloud Data Backup: A cloud data backup strategy that protects against data loss, corruption, and unauthorized access

• i. Disaster Response Plan: Requirements for the establishment of a detailed disaster response plan that outlines actions to be taken in the event of a major disruption

• j. DR Plan Exercise: Regular disaster response plan exercises should be conducted to test the effectiveness of the plan

• k. Equipment Redundancy: Requirements for utilizing geographically dispersed cloud data centers and implementing redundant cloud-based infrastructure components to ensure high availability and operational resilience l Approval: Approval requirements and senior management involvement to ensure alignment with the organization’s strategic goals and risk appetite

  • i. An approval process should be established for any changes or modifications to the BCM and OR policy and procedures

  • ii. A documented record of approvals (including dates, names of approvers, and any relevant comments or discussions) should be maintained

• l. Communication: Effective communication of the policy and procedures should be facilitated to all relevant cloud stakeholders

• m. Maintenance and Reviews: Business continuity management and operational resilience policies and procedures should be documented, reviewed and updated at least annually to ensure alignment with evolving cloud security landscape and to reflect changes in cloud technology, regulations, and risks.

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.

Shared Implementation Guidelines

[All Actors]

1. Context Establishment: Systematically identify vulnerabilities and critical dependencies within AI systems and establish realistic recovery objectives aligned with business impact assessments.Document interdependencies to prevent cascade failures and maintain clear communication across organizational boundaries.

2. Threat Landscape Analysis:Evaluate likelihood based on historical data and emerging trends. Consider both general technology risks and AI-specific challenges. Conduct evaluations to identify vulnerabilities across the AI solution ecosystem and business impact assessments to determine critical functions and acceptable interruption thresholds.

3. Vulnerability Identification: Catalog potential weaknesses in current continuity provisions.Examine cascade scenarios where initial disruptions may trigger subsequent failures, also consider resilience limitations in specialized hardware or computational resources.

4. Impact Determination: Quantify financial implications including both direct costs and opportunity losses along with unquantifiable costs such as reputational effects from service unavailability or degraded performance or due to different disruption scenarios.

5. Risk Evaluation and Treatment: Prioritize identified risks and determine appropriate risk responses (accept, mitigate, transfer, or avoid). Develop control measures for risks requiring treatment and monitor for changing risk profiles.

Implementation Guidelines for Cloud Service Providers (CSP)

[Policy Scope:]

1. Evaluate infrastructure resilience against physical and virtual disruptions

2. Assess resource allocation mechanisms during constrained operations

3. Analyze isolation effectiveness between different customer environments

4. Examine recovery capabilities for specialized AI computing resources

[All Actors]

1. Context Establishment: Systematically identify vulnerabilities and critical dependencies within AI systems and establish realistic recovery objectives aligned with business impact assessments.Document interdependencies to prevent cascade failures and maintain clear communication across organizational boundaries.

2. Threat Landscape Analysis:Evaluate likelihood based on historical data and emerging trends. Consider both general technology risks and AI-specific challenges. Conduct evaluations to identify vulnerabilities across the AI solution ecosystem and business impact assessments to determine critical functions and acceptable interruption thresholds.

3. Vulnerability Identification: Catalog potential weaknesses in current continuity provisions.Examine cascade scenarios where initial disruptions may trigger subsequent failures, also consider resilience limitations in specialized hardware or computational resources.

4. Impact Determination: Quantify financial implications including both direct costs and opportunity losses along with unquantifiable costs such as reputational effects from service unavailability or degraded performance or due to different disruption scenarios.

5. Risk Evaluation and Treatment: Prioritize identified risks and determine appropriate risk responses (accept, mitigate, transfer, or avoid). Develop control measures for risks requiring treatment and monitor for changing risk profiles.

[From CCM] Control Ownership Rationale. The CSP and CSC are both responsible for the implementation of this control, however each party needs to independently assess the impact of disruptions in their infrastructure and services. More specifically, each party should conduct their own Business Impact Analysis (BIA), define parameters such as Recovery Time Objective (RTO) and Recovery Point Objective (RPO), and perform an independent risk assessment.

Implementation Guidelines. Applicable to all service models: The CSP is responsible for ensuring a business continuity and operational resilience strategy for the CSP’s services. By implementing a business impact analysis (BIA) and risk assessment process, the CSP can effectively identify, assess, and mitigate potential disruptions and risks, enabling the CSC to maintain business operations in the face of adverse events.

The CSP should implement the following best practices in its own business impact analysis (BIA) and risk assessment process:

• a. Information Governance Incorporation: BIAs and risk assessment activities should be integrated into the Information Governance Program (refer to GRC-01) ensuring alignment with organizational goals and risk tolerance

• b. BIA and Risk Assessment Team: A cross-functional team should be formed with representatives from IT, operations, business units, and risk management to ensure a comprehensive perspective

• c. BIA and Risk Assessment: A systematic risk assessment process or risk-based approach should be implemented and maintained from the Enterprise Risk Management Program (ERM) (GRC-02) in order to document a standardized methodology for conducting BIA and risk assessment exercises, ensuring consistency and repeatability.

  • i. The potential impact of disruptions on critical business processes, data, and systems should be analyzed

  • ii. Risks should be prioritized based on their likelihood and potential impact and establish risk tolerance levels for cloud-based services

The BIA risk assessment should include (but not be limited to):

1. Risks of Disruption to Prioritized Activities: The potential risks of disruption to prioritized critical activities should be systematically identified and documented. These risks can be internal or external factors that could hinder the organization’s ability to deliver its products or services

2. Risks of Disruption to Supporting Resources: The potential risks of disruption to the cloud physical and human resources that support prioritized critical activities should be also identified and documented

3. Risks of Disruption Analysis: A systematic analysis of the identified risks of disruption should be conducted by evaluating the likelihood and impact of each risk to determine its overall severity

4. Risks of Disruption Requiring Treatment: The identified risks of disruption that require treatment or mitigation strategies should be prioritized and evaluated. It involves assessing the potential benefits and costs of implementing countermeasures

5. Automation Processes: Automation tools should be leveraged to streamline data collection, analysis, and reporting, improving efficiency and effectiveness

6. BIA and Risk Assessment Reviews: Regular reviews of BIA and risk assessment findings should be scheduled to ensure ongoing relevance and effectiveness.

BCR-03: Business Continuity Strategy

Control Specification

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

Shared Implementation Guidelines

[All Actors]

1. Maintain consistent inference capabilities despite infrastructure challenges.

2. Preserve intellectual property embedded in model architecture and parameters.

3. Enable quick restoration of stable model versions when issues emerge, via storing versions of training dataset and implementing adequate data retention strategies per organizational policies.

4. Ensure training capability persistence for critical model families.

5. Knowledge Preservation Strategy: Create immutable snapshots of trained models with complete parameter sets, while maintaining secured repositories of training methodologies and dataset.

6. Recovery Acceleration Framework: Create rapid redeployment pathways for critical models and establish verification protocols to validate restored model performance. Develop partial operation capabilities during reduced infrastructure availability.

Implementation Guidelines for Cloud Service Providers (CSP)

[Policy Scope] -Provide multi-zone and multi-region deployment options for AI workloads. -Offer AI-specific DR capabilities (e.g., persistent volumes for model storage). -Monitor infrastructure supporting AI services with predictive alerting and implement automated failover capabilities with regular validation. -Automate failover for AI containers, databases, and streaming data platforms. -Enable customers to test DR plans using sandbox failover simulations.

[All actors]

1. Maintain consistent inference capabilities despite infrastructure challenges.

2. Preserve intellectual property embedded in model architecture and parameters.

3. Enable quick restoration of stable model versions when issues emerge, via storing versions of training dataset and implementing adequate data retention strategies per organizational policies.

4. Ensure training capability persistence for critical model families.

5. Knowledge Preservation Strategy: Create immutable snapshots of trained models with complete parameter sets, while maintaining secured repositories of training methodologies and dataset.

6. Recovery Acceleration Framework: Create rapid redeployment pathways for critical models and establish verification protocols to validate restored model performance. Develop partial operation capabilities during reduced infrastructure availability.[From CCM] Control Ownership Rationale. The CSP should identify and select business continuity strategies based on the outputs from the BIA and risk assessment. The business continuity strategies should consist of one or more solutions.

The CSP is responsible for providing resilient cloud infrastructure and services to the CSC according to its service agreement (including SLOs), and the CSC may depend on certain services and resilience capabilities offered by the CSP for parts of the CSC’s strategy, including information provided by the CSP. The CSP, however, is not responsible for developing, planning, documenting, adopting, or otherwise establishing the CSC’s BC strategies.

Implementation Guidelines. Applicable to all service models: The CSP should identify and select strategies and solutions considering business continuity objectives and the amount and type of risk that CSP may or may not take.

Business continuity and operational resilience strategies should include (but not limited to):

• a. Risk-based Business Continuity and Resilience Strategy

  • i. Thorough risk assessments should be conducted to identify potential disruptions, assess their impact, and determine acceptable risk tolerance levels

  • ii. Detailed business continuity plans (BCPs) should be developed that outline specific actions to prevent, mitigate, respond to, and recover from disruptions (refer to BCR-04)

• b. Disruption Anticipation

  • i. Potential unavailability of all relevant components, including infrastructure, applications, data, and personnel should be anticipated and addressed

  • ii. Redundancy and failover mechanisms should be implemented to minimize downtime and ensure continued service delivery

  • iii. Multi-cloud strategies should be leveraged to distribute workloads across multiple cloud providers, reducing dependence on a single infrastructure

  • iv. Data replication and disaster recovery (DR) solutions should be employed to safeguard critical data and enable rapid recovery from outages

• c. Recovery Timeframes

  • i. Critical business activities that must be maintained during disruptions should be identified and prioritized

  • ii. Recovery time objectives (RTOs) and recovery point objectives (RPOs) for each prioritized activity should be defined

  • iii. Detailed recovery procedures for each prioritized activity, including timelines, resource allocation, and communication protocols should be developed

  • iv. RTOs and RPOs to reflect changes in business priorities and risk assessments should be regularly reviewed and updated

• d. Capacity Planning and Monitoring

  • i. Capacity planning so that cloud resources are able to meet demand (refer to IVS-02)

  • ii. Sufficient resources, including personnel, infrastructure, and financial support should be allocated, to implement and maintain business continuity and operational resilience strategies

  • iii. Cloud-based solutions that offer high availability, scalability, and resilience to disruptions should be preferred and employed

  • iv. Proactive monitoring and alerting systems should be implemented to identify and respond to potential cloud-related disruptions promptly

• e. Solutions and Measures Documentation

  • i. Each business continuity and operational resilience strategy should be documented in detail, including specific solutions, measures, and responsibilities

  • ii. All relevant stakeholders (e.g., personnel, partners, and CSCs) should be aware of and understand the documented strategies

  • iii. Documentation should be regularly reviewed and updated to reflect changes in strategies, technologies, and business requirements

• f. CSP-CSC Collaborative Strategy Development

  • i. Business continuity and operational resilience strategies should be developed by both the CSP and CSC with consideration of acceptable limits regarding risk appetite and tolerance

  • ii. Roles and responsibilities should be defined for both parties, ensuring alignment and accountability

  • iii. Review and update strategies to reflect changes in business operations, risk assessments, and cloud infrastructure

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.

Shared Implementation Guidelines

[All Actors]

1. Identify and Prioritize: Document essential functions and their acceptable interruption timeframes.

2. Establish Alternatives: Develop simplified operational modes for critical functions and alternative data sources when primary inputs are unavailable.

3. Define Clear Roles: Assign specific continuity responsibilities across organizational boundaries Establish decision authority for activating emergency procedures.

4. Test Regularly: Conduct realistic exercises involving all necessary participants. Validate assumptions about resource availability during challenges.

5. Maintain Relevance: Review plans when significant system changes occur. Update procedures based on insights from exercises and real events.

Implementation Guidelines for Cloud Service Providers (CSP)

[Policy Scope]

• Implement resource allocation guarantees for recovery operations.

• Create isolation boundaries between tenants sharing infrastructure.

• Develop rapid provisioning capabilities for alternate processing environments.

• Establish data replication across geographic boundaries.

• Design progressive capacity restoration plans for large-scale events.

• Create verification procedures validating recovered environment performance.

• Conduct infrastructure component failure simulations.

• Validate resource prioritization during constrained scenarios.

• Test recovery time achievements against established objectives.

[All Actors] Identify and Prioritize: Document essential functions and their acceptable interruption timeframes.

Establish Alternatives: Develop simplified operational modes for critical functions and alternative data sources when primary inputs are unavailable.

Define Clear Roles: Assign specific continuity responsibilities across organizational boundaries Establish decision authority for activating emergency procedures.

Test Regularly: Conduct realistic exercises involving all necessary participants Validate assumptions about resource availability during challenges

Maintain Relevance: Review plans when significant system changes occur Update procedures based on insights from exercises and real events

[From CCM] Control Ownership Rationale. This control’s implementation responsibility is Shared for all cloud service models and both CSP and CSC. The CSP and CSC should both independently develop and implement their own business continuity plans in order to meet their own business needs, contractual and regulatory requirements.

Implementation Guidelines.

IaaS Provider: The CSP is responsible for establishing, documenting, implementing, enforcing, reviewing, and maintaining the BCP for the physical infrastructure (including database, hosts and network).

PaaS Provider: The CSP is responsible for establishing, documenting, implementing, enforcing, reviewing, and maintaining the BCP including the platform underlying resources, middleware, and APIs.

SaaS Provider: The CSP is responsible for establishing, documenting, implementing, enforcing, reviewing and maintaining the BCP to the underlying platform resources, virtual machines, network resources, and associated management plane or administrative interface of the cloud services.

Applicable to all service models: The Business Continuity Plan (BCP) is a critical component of operational resilience strategies and capabilities for CSPs. CSPs should implement a BCP so that their cloud services are resilient and can withstand disruptions. The BCP should provide guidance and information that will assist teams to respond to a disruption and assist with response and recovery.

Implementation best practices towards the creation of a BCP include (but not limited to):

• a. BCM Team Establishment: A BCM team should be established to oversee the development and implementation of the BCP. The BCM team should be responsible for identifying critical business processes,conducting risk assessments, developing mitigation plans, and testing and maintaining the BCP

• b. BCP Scope: The purpose, scope, and boundaries of the BCP should be determined and documented (including limitations and exclusions of systems, technology, services, processes, locations, as well as scenarios/types of contingencies and scales of incidents it addresses)

  • i. Critical business processes and resources that are essential for the delivery of their cloud services should be identified (including the dependencies between different cloud processes and resources)

  • ii. Acceptable downtime for each critical process (RTO) and the maximum allowable data loss (RPO) should be defined

  • iii. Detailed recovery strategies that outline the steps to restore normal operations within the RTOs should be defined for each critical process

  • iv. Robust data backup and recovery solutions to protect against data loss and enable timely restoration should be planned

• c. Cloud infrastructure’s inherent redundancy, such as multiple data centers and failover capabilities,to ensure service availability should be leveraged vi. The CSP should document and communicate the scope of the BCP to the CSC

• d. BCP Development: The BCP should be developed and documented in a clear and concise manner. The documentation should include the following information:

  • i. A description of critical business processes

  • ii. A risk assessment and mitigation plan

  • iii. BCP integration into existing processes and procedures to ensure seamless implementation and adherence

  • iv. Roles and responsibilities for BCM team members

• e. Procedures and processes for responding to disruptions vi. Details of the actions that the teams will take for recovery procedures within predetermined timeframes, and to monitor the effects of the disruption and respond vii. A reference to the predefined threshold and process for activating the response viii. Details to manage the immediate consequences of a disruption giving due regard to:

  • prevention of further loss or unavailability of prioritized activities

  • protection of the environment

  • a process for standing down once the incident is over ix. Testing and maintenance plans

• f. BCP Documentation: The BC plan should be documented and maintained at centralized and secure repository with all BC relevant documentation

• g. BCP Approval: Formal approval from senior management should be obtained to ensure the plan has the necessary authority and resources for implementation

• h. BCP Communication:

  • i. A BC plan should be communicated to all relevant key stakeholders, including CSCs, personnel, and regulators (if required), to be informed about disruptions and recovery progress

  • ii. Communication channels and protocols, messaging formats, and escalation procedures should be established with the CSC to ensure timely and accurate information sharing during a disruption

• i. BCP Implementation and Testing:

  • i. Regular simulations and drills should be conducted to test the effectiveness of the BC plan and identify areas for improvement

  • ii. Testing should include simulations, tabletop exercises, and full-scale tests

  • iii. Learn from past incidents and incorporate lessons learned into the plan

• j. Post-Incident BCP Effectiveness Evaluation:

  • i. A thorough post-incident review should be conducted after each disruption incident and based on continuous monitoring of incident response metrics to evaluate the effectiveness of the plan, identify areas for improvement, and update procedures accordingly

  • ii. Lessons learned from each disruption incident should be documented and those insights incorporated into the business continuity plan to enhance future preparedness i. BCP Reviews: Reviews and updates should be conducted at least annually to verify that the BC plan aligns with current threats, risks, industry best practices and complies with business objectives and changes in cloud technology, infrastructure, and business operations

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.

Shared Implementation Guidelines

[All Actors]

1. Ensure critical information remains available during system disruptions.

2. Record architectural designs showing component relationships and dependencies with recovery procedures and actionable steps.

3. Maintain contact information for essential personnel and external partners

4. Review operational documents at minimum annually and update immediately following significant system changes.

5. Preserve training methodologies,dataset characteristics and preprocessing workflows where required to reconstitute models or restore critical AI services during continuity or recovery events.

6. Record API specifications,evaluation criteria, model parameters and hyperparameters, and performance characteristics necessary to restore, validate, or safely resume AI services in accordance with approved business continuity and operational resilience plans.

Implementation Guidelines for Cloud Service Providers (CSP)

1. Document infrastructure maps with AI-specific resource allocations.

2. Record configuration parameters with version histories and dependencies.

3. Document and maintain specialized hardware requirements for AI workloads.

4. Document recovery time capabilities for different component failures.

5. Maintain documented resource prioritization frameworks for constrained operations.

6. Preserve documented configuration specifications enabling environment reconstruction.

7. Document the design of environment reconstruction workflows, including verification steps.

8. Document failover sequences with automated and manual components.

9. Maintain testing procedures used to validate infrastructure resilience.

[All actors]

1. Ensure critical information remains available during system disruptions.

2. Record architectural designs showing component relationships and dependencies with recovery procedures and actionable steps.

3. Maintain contact information for essential personnel and external partners

4. Review operational documents at minimum annually and update immediately following significant system changes.

5. Preserve training methodologies,dataset characteristics and preprocessing workflows where required to reconstitute models or restore critical AI services during continuity or recovery events.

6. Record API specifications,evaluation criteria, model parameters and hyperparameters, and performance characteristics necessary to restore, validate, or safely resume AI services in accordance with approved business continuity and operational resilience plans.

[From CCM v4.1] Control Ownership Rationale. This control’s ownership and implementation responsibility is “Shared (Independent)” for the CSP and the CSC. The CSP is responsible for providing resilient cloud infrastructure and services to the CSC according to its service agreement, and the CSC may depend on the services and resilience capabilities offered by the CSP; for documentation, the CSP is responsible only for developing, identifying, and acquiring documentation related to the business continuity and resilience of its own systems and services, not those of the CSC. The CSP should share relevant documentation and information with the CSC.

Implementation Guidelines. Applicable to all service models: Documenting business continuity and operational resilience programs enables CSPs to effectively prepare, respond, and recover from disruptions. It enhances preparedness, streamlines incident management, improves decision-making, supports regulatory compliance, preserves knowledge, facilitates continuous improvement, and instills customer confidence.

The CSP should be exclusively responsible for delivering BC and OR relevant documentation to the CSC.

Additional guidelines for developing documentation in support of business continuity and operational resilience programs should include (but not be limited to):

• a. Documentation Governance:

  • i. Roles and responsibilities for documentation creation, review, and approval should be defined

  • ii. A structured process for identifying, developing, and maintaining documentation should be implemented

• b. Documentation Scope and Development:

  • i. A cloud-based registry should be created to store and manage all business continuity (BC) and operational resilience (OR) documentation, that offers easy access and searchability for authorized stakeholders, including links to their respective locations

  • ii. Records of BCM and OR training and exercises should be maintained

  • iii. Standardized templates and style guides for the documentation of BC and OR processes, procedures, and plans should be developed to maintain consistency and improve usability

  • iv. A version control system should be implemented to track changes, maintain historical records, and facilitate rollbacks if necessary

• c. Automation tools should be leveraged to streamline the creation and maintenance of BC and OR documentation to reduce manual effort, improve consistency, and automate repetitive tasks

• d. Documentation Identification and Acquisition:

  • i. A thorough review of existing documentation should be performed to identify relevant materials that can support the BC and OR programs, including internal documents, external resources, and industry best practices

  • ii. Relevant documentation should be collected from third-party providers, such as cloud service providers, data center operators, and network service providers

  • iii. External documentation should be identified and acquired, such as industry standards, regulatory requirements

• e. Documentation Secure Access: Access controls on a “need-to-know” basis should be implemented to ensure that only authorized stakeholders can access the registry and its sensitive documentation

• f. Cloud-based Collaboration Tools: Cloud-based collaboration tools should be used to facilitate the sharing and review of BC and OR documentation

• g. Documentation Sharing with CSC:

  • i. Access to the CSP’s BC and OR documentation enables the CSC to better prepare for and respond to disruptions. By understanding the CSP’s plans and procedures, the CSC can ensure that its own BC and OR plans are aligned and that there are no gaps in coverage

  • ii. Reduces the risk of downtime by ensuring that both the CSP and the CSC are working from the same playbook thus avoid confusion and loss of valuable time in the event of a disruption

  • iii. Regulators may require the CSP to share BC and OR documentation and requirements included with the CSCs. Sharing this documentation can help to ensure that both the CSP and the CSC are compliant with these requirements

• h. Documentation Review and Update:

  • i. A regular review process for BC and OR documentation should be implemented. This process should ensure that the documentation is accurate, up-to-date, and aligned with changes in cloud environments, current business requirements and risks

  • ii. Documentation updates should be part of the change management process to ensure that documentation remains consistent with business practices

  • iii. Documentation changes, review activities, and authorization decisions should be tracked to maintain an audit trail for compliance purposes

BCR-06: Business Continuity Exercises

Control Specification

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

Shared Implementation Guidelines

[All actors]

1. Preparation Steps:

   • a. Define clear learning objectives for each activity and involve representatives from all interconnected services.

   • b. Create realistic scenarios based on genuine vulnerabilities.

   • c. Establish safe environments that won’t impact production systems

   • d. Conduct exercises at least annually or following significant changes (e.g., material architectural, dependency, or process changes)

2. Exercise Activities:

   • a. Tabletop Discussions: Team conversations walking through potential scenarios.

   • b. Functional Drills: Testing specific capabilities like model rollbacks or alternative workflows.

   • c. Simulated Incidents: Comprehensive scenarios involving multiple teams and systems.

   • d. Surprise Challenges: Unannounced tests of readiness with realistic constraints.

3. Post-Exercise:

   • a. Conduct immediate debrief sessions while experiences are fresh.

   • b. Document specific improvement opportunities and assign action items with clear ownership.

   • c. Share relevant insights across organizational boundaries and update continuity plans based on lessons learned.

4. Combined Scenarios

   • a. Annual end-to-end simulation involving all ecosystem participants.

   • b. Regular validation of shared alert and escalation mechanisms.

   • c. Create common evaluation framework for cross-entity exercises.

Implementation Guidelines for Cloud Service Providers (CSP)

[Policy Scope]

1. Resource Reallocation Drill: Simulate resource contention with artificial demand spikes and practice prioritization during constrained capacity

2. Environment Reconstruction: Test provisioning of alternative processing capacity and record the time to rebuilding of computational environments from templates.

3. Data Accessibility Challenge: Validate retrieval from backup storage systems

4. Multi-Region Failover: Exercise geographic redundancy mechanisms by deliberately or forced restricted access to primary facilities during scheduled tests.

[All actors]

1. Preparation Steps:

   • a. Define clear learning objectives for each activity and involve representatives from all interconnected services.

   • b. Create realistic scenarios based on genuine vulnerabilities.

   • c. Establish safe environments that won’t impact production systems

   • d. Conduct exercises at least annually or following significant changes (e.g., material architectural, dependency, or process changes)

2. Exercise Activities:

   • a. Tabletop Discussions: Team conversations walking through potential scenarios.

   • b. Functional Drills: Testing specific capabilities like model rollbacks or alternative workflows.

   • c. Simulated Incidents: Comprehensive scenarios involving multiple teams and systems.

   • d. Surprise Challenges: Unannounced tests of readiness with realistic constraints.

3. Post-Exercise:

   • a. Conduct immediate debrief sessions while experiences are fresh.

   • b. Document specific improvement opportunities and assign action items with clear ownership.

   • c. Share relevant insights across organizational boundaries and update continuity plans based on lessons learned.

4. Combined Scenarios

   • a. Annual end-to-end simulation involving all ecosystem participants.

   • b. Regular validation of shared alert and escalation mechanisms.

   • c. Create common evaluation framework for cross-entity exercises.

[From CCM v4.1] Control Ownership Rationale. This control’s implementation responsibility is Shared (Independent) between the CSP and CSC. The CSP’s ownership of this control relates to exercise and testing BCPs for CSP-controlled resources offered to CSCs.

A full scale exercise or testing is recommended if both parties are involved in any end-to-end Business continuity and operational resilience plans testing. If not then CSP should provide test evidence to their CSC.

The CSC’s ownership of this control relates to exercise and testing business continuity plans for CSC-controlled resources within the CSC’s cloud organizational units, infrastructure, and assets relevant to the cloud services offered by CSP.

The CSP is responsible for:

• Establishing, documenting, implementing, and reviewing the exercise and testing of the BCP for the physical infrastructure (including  database, hosts and network) and doing so on a periodical basis

• Identifying and prioritizing critical systems and equipment during the exercise and testing • Communicating and requesting CSCs’ participation in the table top exercises

Implementation Guidelines. Applicable to all service models: Exercises and tests help ensure that business continuity procedures support the business continuity objectives. An exercise is a task or activity involving people and processes that is designed to validate one or more aspects of the BCP or related procedures. There are many different types of exercises, depending on the intended goals and objectives. Exercises may include scenario-driven simulations of BCP elements. For example, exercises may include performing duties in a simulated environment (i.e., functional) or be discussion based (i.e., tabletop).

To exercise and test business continuity and operational resilience plans the CSP should establish:

• a. Exercise and Testing Framework:

  • i. The goals of the exercise and testing program should be defined to align with the overall business continuity and operational resilience strategies and plans

  • ii. The essential processes that must be maintained during disruptions should be determined, considering dependencies and potential impact on customer service

  • iii. A regular testing cadence should be established on an annual basis or upon significant changes, to support ongoing preparedness

  • iv. Realistic and challenging scenarios should be designed that encompass a wide range of potential disruptions, such as cloud outages, data loss, and cyberattacks

• b. Documentation should be developed outlining the exercise and testing procedures, including roles, responsibilities, and communication protocols

• c. Communication and Collaboration:

  • i. Well-defined communication channels should be established to facilitate timely and accurate information sharing during exercises and tests

  • ii. Roles and responsibilities should be defined for all stakeholders involved in exercise and testing activities, ensuring accountability and coordination

  • iii. Open and transparent communication should be encouraged throughout the exercise and testing process to identify and address issues promptly

  • iv. Collaborative tools and platforms should be used to facilitate real-time communication, information sharing, and decision-making during exercises and tests

• d. Simulation and Emulation Technologies:

  • i. Simulation and emulation technologies should be leveraged to create realistic and immersive scenarios that replicate real-world disruptions

  • ii. Simulation and emulation tools should be used to test the resilience of cloud infrastructure, applications, and data under various disruptive scenarios

  • iii. Backup and recovery procedures should be tested to ensure the ability to restore critical data and systems following a disruption

  • iv. The performance of systems and processes during simulations and emulations should be analyzed to identify areas for improvement and strengthen resilience

• e. A variety of exercises can be employed to assess the effectiveness of the business continuity and operational resilience plans (e.g., tabletops, walk-through, simulation, parallel, and full-scale exercises)

• f. Continuous Improvement:

  • i. The outcomes of each exercise and test should be documented including identified issues, lessons learned, and corrective actions taken

  • ii. Trends and patterns identified across multiple exercises and tests to gain insights into recurring vulnerabilities and areas for improvement should be analyzed

  • iii. Lessons learned from exercises and tests should be shared with relevant stakeholders to enhance organizational-wide resilience

• g. Review and Updates: Business continuity and operational resilience plans should be regularly reviewed and updated based on the findings of exercises and tests as well as the organization’s business processes, assets, and risks evolution

The CSP should ensure recovery testing is conducted at least annually, or more frequently, depending on the operating environment and criticality of the applications and business functions.

BCR-07: Communication

Control Specification

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

Shared Implementation Guidelines

[All Actors]

1. Stakeholder Mapping: Create comprehensive matrices identifying all parties affected by various disruption types. Define specific information needs for technical teams, business units, and external partners. Establish clear ownership for different communication streams.

2. Communication Infrastructure: Implement security protocols for sensitive updates during vulnerability-related events. Test all notification systems at least quarterly with cross-organizational verification.

3. Preparatory Materials: Develop concise message templates focused on critical decision-making information. Prepare explanatory resources that translate technical situations into business impact terms. Establish standard formats for exchanging structured incident data between teams.

4. Structured Updates: Maintain consistent update format enabling quick identification of new developments. Activate alerts through multiple channels simultaneously to ensure reach. Include precise impact descriptions with affected and unaffected functions clearly differentiated.

5. Cross-Functional Coordination: Form joint assessment teams with representatives from each entity in the service chain. Maintain dedicated liaisons responsible for translating technical details to business implications.

6. Continuous Refinement: Gather structured feedback on communication effectiveness after each significant event. Conduct periodic simulations focused specifically on information exchange. Measure and track key metrics including time-to-notify and message comprehension. Evolve communication strategies based on technological changes and organizational learning.

Implementation Guidelines for Cloud Service Providers (CSP)

[Policy Scope]

1. Key Stakeholder Matrix

   • Internal Teams: Infrastructure operations, security personnel, and executive leadership.

   • Direct Customers: Platform users and dedicated environment clients.

   • Special Relationships: High-priority workloads requiring exceptional handling.

   • Hardware Partners: Equipment vendors and data center operators.

2. Communication Framework:

   • Develop incident classification framework with communication triggers.

   • Create impact zone mapping showing affected services and customers.

   • Establish progressive notification procedures based on incident development.

   • Configure service health dashboard with appropriate transparency levels.

   • Establish dedicated communication channels for high-priority customers.

   • Create technical support briefing mechanisms ensuring consistent information.

   • Design templates focused on resource availability and recovery projections.

   • Develop technical detail tiers appropriate for different audiences.

   • Create visual status indicators for complex infrastructure states.

3. Testing & Maintenance :

   • Conduct large-scale incident simulation testing notification systems.

   • Review messaging effectiveness through customer comprehension assessment.

   • Validate automated alert systems through scenario injection testing.

[All actors]

1. Stakeholder Mapping: Create comprehensive matrices identifying all parties affected by various disruption types. Define specific information needs for technical teams, business units, and external partners. Establish clear ownership for different communication streams.

2. Communication Infrastructure: Implement security protocols for sensitive updates during vulnerability-related events. Test all notification systems at least quarterly with cross-organizational verification.

3. Preparatory Materials: Develop concise message templates focused on critical decision-making information. Prepare explanatory resources that translate technical situations into business impact terms. Establish standard formats for exchanging structured incident data between teams.

4. Structured Updates: Maintain consistent update format enabling quick identification of new developments. Activate alerts through multiple channels simultaneously to ensure reach. Include precise impact descriptions with affected and unaffected functions clearly differentiated.

5. Cross-Functional Coordination: Form joint assessment teams with representatives from each entity in the service chain. Maintain dedicated liaisons responsible for translating technical details to business implications.

6. Continuous Refinement: Gather structured feedback on communication effectiveness after each significant event. Conduct periodic simulations focused specifically on information exchange. Measure and track key metrics including time-to-notify and message comprehension. Evolve communication strategies based on technological changes and organizational learning.[From CCM] Control Ownership Rationale. This control’s implementation responsibility is shared between the CSP and the CSC, in an independent manner. It is fully and independently the responsibility of the CSP to establish communication with its own stakeholders and participants in the course of its business continuity and resilience procedures and in all elements of the CSP’s own BC plan and program. The CSP’s ownership of this control relates to developing and establishing communication plans for the CSP’s organizational units and those for its other stakeholders, including its customer stakeholders, the CSCs. The CSP does not have responsibility to communicate directly to the CSC’s stakeholders and participants.

Implementation Guidelines. Applicable to all service models: The CSP is responsible for establishing, documenting, implementing, enforcing, reviewing, and maintaining communication plans internally as well as with CSC and other stakeholders.

The CSP is responsible for establishing communication channels internally for all service delivery models. The CSP should exchange their communication plan and strategy with the CSC so during disruption or BCP/DR exercise notification should go through the right channels and the right people in a timely manner.

Implementation best practices include (but not limited to):

• a. Communication Plan:

  • i. A communication plan and matrix should be developed and maintained that includes a list of all relevant stakeholders (e.g., CSCs, partners, personnel, and regulatory bodies), their contact details, and the preferred communication channels

  • ii. Roles and responsibilities of teams responsible for communication during business continuity events should be defined

  • iii. Pre-prepared communication templates and playbooks should be created for various disruption scenarios (e.g., regarding the activation, operation, coordination, and communication of a business continuity response).

  • iv. Includes the criteria, thresholds, and indicators to demonstrate when and how business continuity-related communications should be sent, who should send them, and to whom they should be sent

• b. Includes the technology and processes required for business continuity communications vi. Should include a response structure established that will enable timely warnings and communication to relevant stakeholders vii. The plan should communicate to relevant stakeholders:

  • the importance of effective business continuity and the consequences of disruptions

  • the business continuity and resilience policy, objectives, and this plan

  • the roles, responsibilities, authorities, and expected competencies to all relevant stakeholders

• c. Communication Goals: Specific communication goals should be defined for each stakeholder group, such as informing CSCs about outages, providing updates to partners on new features, or addressing personnel concerns about resilience measures

• d. Communication Messages: Tailor communication messages to the specific needs and interests of each stakeholder group. Use plain language, avoid jargon, and provide actionable information

• e. Regular Communication: Regular communication cadence should be established, including daily or weekly status updates, and proactive communication during potential disruptions or outages

• f. Multi-Channel Communication:

  • i. Multiple communication channels should be utilized to ensure redundancy. This can include email, SMS, voice calls, instant messaging, and cloud collaboration platforms

  • ii. Cloud-based communication tools should be leveraged that can be accessed from anywhere to ensure availability during disruptions

• g. Communication Systems Redundancy:

  • i. Critical communication systems should be distributed across multiple regions to mitigate the impact of regional disruptions

  • ii. Redundant internet connectivity should be implemented through multiple ISPs to ensure continuous communication even if one provider experiences issues

• h. Communication Exercises: Regularly conduct communication drills to test the effectiveness of communication plans and procedures in a simulated crisis or disruption scenario

• i. Communication Integration with BCPs: Integrate communication plans and procedures into overall business continuity and resilience plans to ensure seamless coordination and response during disruptions

• j. Feedback Collection:

  • i. Continuously gather feedback from stakeholders to assess the effectiveness of communication efforts and identify areas for improvement

  • ii. Use lessons learned to update and enhance communication plans and systems

• k. Regulatory Compliance: Should be ensured that communication practices comply with relevant regulatory requirements and standards applicable to the cloud service industry

• l. Review and Update: Communication plans and procedures should be regularly reviewed and updated to reflect changes in stakeholder needs, technology, and business strategies

BCR-08: Backup

Control Specification

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

Shared Implementation Guidelines

[All Actors]

1. Core Backup Principles:

   • a. Implement comprehensive version control for all critical configurations and code.

   • b. Maintain immutable snapshots with point-in-time recovery capabilities.

   • c. Create geographically distributed copies with at least one offline storage location.

   • d. Establish clear boundaries defining backup responsibilities between entities.

   • e. Document dependencies that affect restoration sequences and procedures.

2. Implementation Methodology:

   • a. Deploy automated daily snapshots for frequently changing components.

   • b. Implement weekly full backups capturing complete system states.

   • c. Create monthly archives stored in physically separate locations.

   • d. Structure backups to support rapid retrieval of specific components.

   • e. Maintain metadata linking related assets for coordinated recovery.

3. Data Security:

   • a. Encrypt all backup data both in transit and at rest.

   • b. Implement least-privilege access controls for backup management.

   • c. Establish separation between production and backup infrastructure.

   • d. Apply appropriate classification and handling standards to backup media.

4. Verification & Validation:

   • a. Conduct automated integrity checks immediately after backup creation.

   • b. Conduct quarterly(at least) recovery exercises in isolated environments.

   • c. Validate cross-entity restoration through coordinated testing.

5. Recovery Documentation:

   • a. Document step-by-step restoration procedures for various scenarios.

   • b. Establish clear prioritization frameworks for sequential recovery.

Implementation Guidelines for Cloud Service Providers (CSP)

[Policy Scope]

1. Critical Assets Protection Strategy:

   • Implement comprehensive preservation of infrastructure configurations and resource allocations.

   • Establish secure repositories for specialized environment definitions and templates.

   • Create versioned archives of network topologies and security group definitions.

   • Maintain secure backups of customer environment states and deployment parameters.

2. Infrastructure Configuration Preservation:

   • Deploy automated daily snapshots of platform configurations and deployment states.

   • Implement immutable infrastructure definitions with version control.

   • Create secure storage for environment parameters with appropriate isolation.

3. Resource State Safeguards:

   • Establish continuous backup for virtualization states with minimal recovery points.

   • Create geographically distributed replicas with appropriate encryption.

   • Implement integrity verification ensuring complete environment reconstruction capability.

4. Recovery Readiness:

   • Develop environment restoration procedures with performance validation.

   • Create isolated testing regions for backup effectiveness verification.

   • Establish automated recovery orchestration with dependency awareness.

[All actors]

1. Core Backup Principles:

   • a. Implement comprehensive version control for all critical configurations and code.

   • b. Maintain immutable snapshots with point-in-time recovery capabilities.

   • c. Create geographically distributed copies with at least one offline storage location.

   • d. Establish clear boundaries defining backup responsibilities between entities.

   • e. Document dependencies that affect restoration sequences and procedures.

2. Implementation Methodology:

   • a. Deploy automated daily snapshots for frequently changing components.

   • b. Implement weekly full backups capturing complete system states.

   • c. Create monthly archives stored in physically separate locations.

   • d. Structure backups to support rapid retrieval of specific components.

   • e. Maintain metadata linking related assets for coordinated recovery.

3. Data Security:

   • a. Encrypt all backup data both in transit and at rest.

   • b. Implement least-privilege access controls for backup management.

   • c. Establish separation between production and backup infrastructure.

   • d. Apply appropriate classification and handling standards to backup media.

4. Verification & Validation:

   • a. Conduct automated integrity checks immediately after backup creation.

   • b. Conduct quarterly(at least) recovery exercises in isolated environments.

   • c. Validate cross-entity restoration through coordinated testing.

5. Recovery Documentation:

   • a. Document step-by-step restoration procedures for various scenarios.

   • b. Establish clear prioritization frameworks for sequential recovery.

[From CCM] Control Ownership Rationale. This control’s implementation is a shared responsibility between the CSP and the CSC, and it pertains to a “Dependent” relationship since the CSP is responsible for providing the backup capabilities to the CSC for the latter to properly configure them according to its own security policy and business requirements. More specifically, the CSP offers backup and restore services, and is responsible for the infrastructure that supports these services. The CSC, on the other hand, is responsible for correctly leveraging these services to secure their data (e.g., select data to backup, enable encryption and verify data restoration functionality).

Implementation Guidelines. Applicable to all service models: To ensure the confidentiality, integrity, and availability of data stored in the cloud, the CSPs should implement a comprehensive set of technical measures that encompass data security, backup, and restoration procedures.

Implementation best practices for the CSP to periodically backup data stored in the cloud include (but not limited):

• a. Backup Strategy: A backup strategy should be established that includes regular backup schedules, incremental backups, and full backups, including the physical location of backup files, which should comply with the privacy and data protection laws and regulations applicable to the data collected

  • i. Multiple backup methods, including cloud-based backup services, on-premises storage, and offline backups should be utilized

  • ii. The 3-2-1 backup rule can be used: three copies of data on two different media, with one copy stored offsite

• b. Separate Location Backup: Backups should be stored in a separate location physically or logically isolated from the primary cloud data storage

• c. Backup Encryption: Backup data should be encrypted with strong encryption algorithms and secure key management practices to prevent unauthorized access

• d. Backup Integrity Verification: The integrity of backups should be regularly verified with the use of data integrity verification mechanisms like cryptographic hashes, checksums or message authentication codes (MACs) to ensure they are not corrupted or tampered with

• e. Backup Repository Access Control: Access control for backup repositories should be implemented to prevent unauthorized access and access permissions should be regularly reviewed and updated

• f. Backup Retention and Archiving:

  • i. Data retention policies should be established to determine the scope, frequency, and duration of cloud data backups and in compliance with applicable laws/regulations, contractual agreements (SLAs), and CSP’s business requirements

  • ii. Data archiving strategies should be implemented to ensure long-term data preservation and compliance with regulatory requirements

  • iii. Automatically purge outdated backups in accordance with the retention policy

• g. Backup Monitoring and Auditing: Backup processes should be continuously monitored to ensure backups are running successfully and data integrity is maintained

• h. Data Restoration and Resiliency:

  • i. RPOs and RTOs should be defined and used as metrics to guide backup frequency and recovery strategies

  • ii. A comprehensive data restoration plan should be established that outlines the steps to restore data from backups in case of data loss or corruption. Regularly test the plan to ensure its effectiveness

  • iii. Backup restorations should be carried out only after they have been approved by authorized personnel (according to contractual agreements with CSCs or the internal policies of the CSP)

  • iv. Backup and data restoration processes should be automated to minimize manual intervention, downtime and expedite recovery

• i. Use automation tools to schedule backups, monitor backup health, trigger restorations and manage the restoration workflow vi. Replicate data to multiple data centers or geographic regions to ensure data availability in case of regional outages or disasters. Use replication technologies like synchronous or asynchronous replication vii. Backup restores should be regularly tested to ensure the ability to recover from data loss or corruption

  • i. Backup Monitoring and Logging: Continuous monitoring and logging of data backup and restoration processes should be implemented to detect and address any potential issues promptly. Use monitoring tools to track backup status, data integrity, restoration performance, and set up alerts for any anomalies or failures in the backup system

• j. Third-Party Assessments: Engage in third-party security assessments and to validate the effectiveness of backup and security measures

• k. Communication with the CSC: The CSP, when appropriate, should be able to disclose the backup and restoration test results to the CSC as part of the assurance of business continuity and resilience

• l. Backup Review and Update: Backup and recovery plans should be regularly reviewed and updated to reflect changes in data volumes, infrastructure, and regulatory requirements to ensure that plans are aligned with current business needs and security standards

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.

Shared Implementation Guidelines

[All Actors]

1. Building Response Foundation:

   • a. Establish cross-functional teams with clearly defined roles and responsibilities.

   • b. Designate specific decision authorities empowered to act during time-sensitive situations.

   • c. Create explicit escalation pathways with activation criteria for different scenario types.

   • d. Develop detailed responsibility assignments covering all recovery functions.

2. During Incidents:

   • a. Deploy rapid diagnostic procedures identifying affected components and dependencies.

   • b. Conduct immediate impact assessment determining operational consequences.

   • c. Activate containment measures preventing problem escalation.

   • d. Execute stability verification before initiating recovery procedures.

3. During Recovery Operations Phase:

   • a. Implement pre-planned alternatives for critical functions.

   • b. Deploy progressive restoration based on established priorities.

   • c. Activate reconciliation procedures ensuring data and state consistency.

   • d. Execute verification protocols confirming successful function restoration.

4. Post Incident Response (PIR) and Activities:

   • a. Conduct comprehensive analysis of response effectiveness includes scheduling of PIR meetings.

   • b. Implement identified resilience improvements while memories remain fresh.

   • c. Update response procedures based on practical experience.

   • d. Document lessons learned for organizational knowledge preservation.

5. Cross-Entity Coordination:

   • a. Establish clear communication channels spanning organizational boundaries.

   • b. Create shared terminology ensuring consistent understanding during joint responses.

   • c. Develop notification procedures alerting dependent entities about potential impacts.

   • d. Implement synchronized status reporting during complex incidents.

Implementation Guidelines for Cloud Service Providers (CSP)

[Policy Scope]

1. Response Structure:

   • Establish multi-disciplinary team including infrastructure specialists and capacity managers.

   • Designate technical leads authorized to implement resource prioritization.

   • Create clear escalation paths for infrastructure-wide incidents.

   • Develop responsibility assignments covering different facility scenarios.

2. Incident Classification :

   • Implement tiered incident levels based on infrastructure impact scope.

   • Define clear thresholds for activating different recovery strategies.

   • Create assessment rubrics for resource availability evaluation.

   • Establish criteria for geographic failover activation.

3. Response Phase:

   • Deploy automated diagnostics identifying affected infrastructure components.

   • Implement resource availability analysis determining capacity impacts.

   • Activate isolation procedures containing fault propagation.

   • Execute infrastructure stability verification before recovery initiation.

   • Deploy resource prioritization protocols focusing on critical workloads.

   • Implement geographical redistribution when regional impacts occur.

   • Activate predefined capacity reservation for essential services.

   • Execute progressive restoration based on workload classification.

4. Post-Incident Activities:

   • Conduct infrastructure resilience analysis identifying improvement opportunities.

   • Implement enhanced monitoring for early warning indicators.

   • Update capacity planning based on performance during constraints.

   • Document effective resource allocation approaches during limitations.

[All Actors]

1. Building Response Foundation:

   • a. Establish cross-functional teams with clearly defined roles and responsibilities.

   • b. Designate specific decision authorities empowered to act during time-sensitive situations.

   • c. Create explicit escalation pathways with activation criteria for different scenario types.

   • d. Develop detailed responsibility assignments covering all recovery functions.

2. During Incidents:

   • a. Deploy rapid diagnostic procedures identifying affected components and dependencies.

   • b. Conduct immediate impact assessment determining operational consequences.

   • c. Activate containment measures preventing problem escalation.

   • d. Execute stability verification before initiating recovery procedures.

3. During Recovery Operations Phase:

   • a. Implement pre-planned alternatives for critical functions.

   • b. Deploy progressive restoration based on established priorities.

   • c. Activate reconciliation procedures ensuring data and state consistency.

   • d. Execute verification protocols confirming successful function restoration.

4. Post Incident Response (PIR) and Activities:

   • a. Conduct comprehensive analysis of response effectiveness includes scheduling of PIR meetings.

   • b. Implement identified resilience improvements while memories remain fresh.

   • c. Update response procedures based on practical experience.

   • d. Document lessons learned for organizational knowledge preservation.

5. Cross-Entity Coordination:

   • a. Establish clear communication channels spanning organizational boundaries.

   • b. Create shared terminology ensuring consistent understanding during joint responses.

   • c. Develop notification procedures alerting dependent entities about potential impacts.

   • d. Implement synchronized status reporting during complex incidents.

[From CCM] Control Ownership Rationale. The responsibility of this control is “Shared (Dependent)” between the CSP and the CSC, because the CSP should develop and implement Disaster Recovery Plans (DRP) for themselves, and plans relevant to their customers as well.

The CSP’s ownership of this control relates to the DRP for developing and managing disaster recovery to CSP-controlled resources.

Implementation Guidelines.

IaaS Provider: The CSP is responsible for establishing, documenting, implementing, enforcing, reviewing and maintaining a DRP for the cloud physical infrastructure.

PaaS Provider: The CSP is responsible for establishing, documenting, implementing, enforcing, reviewing, and maintaining a DRP that includes the underlying platform resources, middleware, and APIs for delivering cloud services.

SaaS Provider: The CSP is responsible for establishing, documenting, implementing, enforcing, reviewing, and maintaining a DRP to the underlying platform resources, virtual machines, network resources, and associated management plan or administrative interface of the cloud services.

The following guidelines apply towards the establishment, documentation, approval, communication, implementation, review and maintenance of a DR plan (including but not limited to):

• a. DR Team Establishment:

  • i. A cross-functional team should be formed with experts in cloud infrastructure, data recovery, security, customer support, and communications

  • ii. Roles and responsibilities for each emergency response team member should be defined, ensuring accountability and efficient coordination

• b. Disasters Risk Identification:

  • i. A thorough risk assessment should be conducted to identify potential natural disasters (floods, earthquakes, hurricanes, etc.) and man-made threats (cyberattacks, power outages, human errors)

  • ii. The severity and probability of each disaster should be evaluated and risks prioritized based on their potential impact on business operations

• c. DRP Development:

  • i. A DR plan should be developed and documented that outlines the organization’s overall approach to disaster preparedness and recovery

  • ii. The plan should include the risk assessment, recovery objectives, recovery procedures, communication plans, and contact information.

  • iii. Recovery procedures should be outlined for each critical service or application. These procedures should specify the steps to be taken, the responsible personnel, and the resources required for data recovery, systems restoration, application redeployment and business continuity

  • iv. The plan should be outlined according to the following steps to be taken before, during, and after a disaster, including:

    • Prevention: Implement proactive measures to mitigate disaster risks, such as data backups, infrastructure hardening, and security protocols

    • Detection: Establish early warning systems and monitoring tools to detect potential threats and initiate response protocols promptly

    • Response: Define clear procedures for isolating affected systems, restoring services, and communicating with customers

    • Recovery: Outline steps to restore full functionality, including data recovery, infrastructure repair, and validation testing

• d. DRP Documentation: The DR plan should be documented and maintained at centralized and secure repository with all DR relevant documentation

• e. DRP Approval: Formal approval from senior management should be obtained to ensure the plan has the necessary authority and resources for implementation

• f. DRP Communication:

  • i. The plan should be communicated to all relevant stakeholders, including personnel, CSCs, and partners

  • ii. Communication channels and protocols, messaging formats, and escalation procedures should be established with the CSC to ensure timely and accurate information sharing during a disaster

  • iii. CSCs should be informed about the CSP’s disaster preparedness and recovery capabilities, including RPOs and RTOs, to manage expectations

  • iv. Provide regular updates on the status of the situation and recovery efforts

• g. DRP Implementation and Testing:

  • i. Regular simulations and drills should be conducted to test the effectiveness of the DR plan and identify areas for improvement

  • ii. Testing should include simulations, tabletop exercises, and full-scale tests

  • iii. Learn from past incidents and incorporate lessons learned into the plan

• h. Post-Incident DRP Effectiveness Evaluation:

  • i. A thorough post-incident review should be conducted after each disaster event to evaluate the effectiveness of the plan, identify areas for improvement, and update procedures accordingly

  • ii. Lessons learned from each disaster event should be documented and those insights incorporated into the disaster response plan to enhance future preparedness i. DRP Reviews: Reviews and updates should be conducted at least annually to verify that the DR plan aligns with current threats, risks, industry best practices and complies with business objectives and changes in cloud technology, infrastructure, and business operations.

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.

Shared Implementation Guidelines

[All Actors]

1. Designing Effective Scenarios:

   • a. Develop progressive difficulty levels building team capabilities over time, include both technical complications and communication challenges.

   • b. Design scenarios that test decision-making under uncertainty and time pressure.

2. Building a Comprehensive Program:

   • a. Begin with tabletop sessions exploring response strategies without system impact.

   • b. Introduce unexpected complications challenging assumptions and standard approaches.

3. Hands-On Validation:

   • a. Conduct controlled technical testing in isolated environments which validate processes and with actual tools and systems.

   • b. Execute partial recovery activities focused on critical functions.

4. Full-Scale Exercises:

   • a. Organize comprehensive simulations involving all response team members, and incorporate surprise elements to test readiness and adaptability.

   • b. Conduct immediate debriefs while experiences remain fresh.

   • c. Focus evaluation on specific improvement opportunities rather than general observations.

   • d. Translate lessons into concrete procedure updates before the next incident.

   • e. Share non-sensitive insights that could benefit other ecosystem participants.

5. Cross-Entity Readiness

   • a. Participate in joint exercises exploring scenarios that cross organizational boundaries, may include local authorities to facilitate and test such exercise response.

Implementation Guidelines for Cloud Service Providers (CSP)

[Policy Scope]

1. Create scenarios targeting infrastructure disruption and resource constraint challenges.

2. Develop simulation approaches for facility incidents and capacity limitations.

3. Establish exercise progression exploring increasingly complex availability issues.

4. Design specialized drills testing resource prioritization and failover procedures.

5. Implement hands-on verification of resource prioritization procedures.

6. Execute partial recovery drills focusing on critical service restoration.

7. Execute verification drills confirming service levels during progressive restoration.

[All actors]

1. Designing Effective Scenarios:

   • a. Develop progressive difficulty levels building team capabilities over time, include both technical complications and communication challenges.

   • b. Design scenarios that test decision-making under uncertainty and time pressure.

2. Building a Comprehensive Program:

   • a. Begin with tabletop sessions exploring response strategies without system impact.

   • b. Introduce unexpected complications challenging assumptions and standard approaches.

3. Hands-On Validation:

   • a. Conduct controlled technical testing in isolated environments which validate processes and with actual tools and systems.

   • b. Execute partial recovery activities focused on critical functions.

4. Full-Scale Exercises:

   • a. Organize comprehensive simulations involving all response team members, and incorporate surprise elements to test readiness and adaptability.

   • b. Conduct immediate debriefs while experiences remain fresh.

   • c. Focus evaluation on specific improvement opportunities rather than general observations.

   • d. Translate lessons into concrete procedure updates before the next incident.

   • e. Share non-sensitive insights that could benefit other ecosystem participants.

5. Cross-Entity Readiness

   • a. Participate in joint exercises exploring scenarios that cross organizational boundaries, may include local authorities to facilitate and test such exercise response.

[From CCM] Control Ownership Rationale. The ownership is “Shared (Dependent)” because, although aspects of many activities, such as creating plans, can be done independently, disaster recovery and its associated testing implicates the restoration of CSP services and the testing of such recovery and therefore the exercise of the response plan can and often does require the CSC’s dependence on the CSP, especially when testing certain CSP-provided resilience capabilities (e.g., intra-region or inter-region failovers, etc.). The CSP is responsible for their own tests of DR on their infrastructure and services. Exercises and tests help management validate continuity and resilience of technology components, including systems, networks, applications, and data, that support critical business functions. The type or combination of methods should be determined by the entity’s size, complexity, and nature of its business. Comprehensive testing of all critical functions and applications allows the CSP to identify potential problems; therefore, the CSP should use one of the more thorough testing methods discussed in this section to verify the BCP’s viability. Exercises may include performing duties in a simulated environment (i.e., functional), be discussion-based (i.e., tabletop), or be full-scale or limited-scale.

Implementation Guidelines. Applicable to all service models: Implementation best practices for the exercise of the disaster recovery plan include (but not limited):

• a. DRP Exercise Scope and Objectives:

  • i. The scope of the exercise should be identified, including the systems, personnel, and processes to be tested

  • ii. The scope of the DRP exercise should be tailored to the CSP’s specific needs and risks

  • iii. Exercise objectives of the DRP should be defined

• b. Cross-Functional Team Establishment: A dedicated cross-functional team responsible for planning, executing, and evaluating the exercise should be formed (e.g., representatives from IT, security, operations, communications, and any relevant departments should be included)

• c. DRP Exercise Plan Establishment: The DRP exercise plan should outline the scope, goals, objectives, participants, scenarios, and evaluation criteria for the exercise

  • i. Realistic disaster scenarios that challenge different aspects of the response plan should be simulated, including various types of disasters considered such as natural disasters, cyber attacks, and human errors

  • ii. The DRP exercise should be conducted in a separate environment from the production environment to avoid any disruption to production services

  • iii. Communication channels with external stakeholders, including CSCs, partners, and emergency services should be simulated

  • iv. All participants should be familiar with the DRP exercise plan and their roles and responsibilities communicated during the exercise

• d. Support should be provided to the CSC during DRP exercise and testing vi. DR plan exercise execution should take place annually or when significant changes to the DRP plan occur

• e. Local Emergency Authorities: Local emergency authorities should be involved in the planning and exercise process in order to ensure that the CSP’s DR plan is coordinated with local emergency response efforts. Emergency authorities can provide expertise in disaster response, coordination with other organizations, and access to resources such as public safety personnel and equipment

• f. Tabletop Exercises: Tabletop exercises should be regularly conducted to walk through the disaster scenarios and response procedures in order to identify areas for improvement and refine the plan based on the outcomes

• g. Exercise Results Documentation and Communication:

  • i. The DR exercise plan results including successes, challenges, and action items should be documented and communicated to all relevant stakeholders

  • ii. Regular communication during a disaster will help to keep CSCs informed of the situation and to minimize disruption to their businesses

• h. Continuous Improvement: Feedback and lessons learned from exercises and real-world incidents should be documented and incorporated into the DR plan to improve its effectiveness

• i. Review and Updates: DR exercise plans should be regularly reviewed and updated based on the findings of exercises and tests as well as the organization’s business processes, assets, and risks evolution so that they remain relevant and effective

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.

Shared Implementation Guidelines

[All Actors]

1. Strategic Assessment:

   • Inventory all physical and virtual components supporting critical functions.

   • Classify infrastructure elements based on maximum tolerable downtime.

   • Identify specialized hardware with unique replacement challenges.

   • Map dependencies between components to understand failure implications.

   • Document resource requirements for minimum acceptable operations.

2. Design Principles for Resilient Systems:

   • Create true redundancy rather than mere backup capabilities.

   • Implement geographic distribution for critical system components.

   • Build capacity ensuring secondary systems handle full production loads.

   • Develop isolation boundaries preventing cascade failures across components.

3. Core Processing Safeguards:

   • Deploy parallel computing environments using N+1 redundancy principles.

   • Establish automated health checking with failover triggers.

   • Create load balancing across redundant processing instances.

   • Design resource isolation preventing “noisy neighbor” problems.

4. Network Resilience Measures:

   • Implement diverse routing paths between essential components.

   • Establish multiple external connectivity providers with dynamic balancing.

   • Create redundant internal communication channels with automatic switching.

   • Design independent management networks for emergency administration.

5. Environmental Protection:

   • Deploy redundant power systems with seamless transition capabilities.

   • Implement alternative cooling approaches with independent controls.

   • Create multiple physical security layers with overlapping coverage.

   • Establish diverse monitoring systems with independent alerting mechanisms.

6. Validation and Maintenance:

   • Conduct regular failover testing under realistic load conditions.

   • Perform scheduled operation from secondary systems to verify readiness.

   • Implement automated verification ensuring configuration synchronization.

   • Create capacity validation confirming redundant systems remain adequate.

7. Cross-Entity Considerations:

   • Establish clear documentation of redundancy capabilities and limitations.

   • Create shared understanding of expected transition times during failures.

   • Develop notification protocols when activating redundant systems.

   • Design complementary approaches where systems interconnect.

Implementation Guidelines for Cloud Service Providers (CSP)

[Policy Scope]

1. Identify physical resources requiring complete redundancy.

2. Evaluate specialized hardware needing protected capacity reserves.

3. Assess environmental systems requiring alternative implementations.

4. Deploy N+1 redundancy for all critical processing resources.

5. Implement geographical distribution across multiple facilities.

6. Determine network pathways needing diverse routing options.

7. Implement diverse routing strategies preventing regional disruptions.

[All actors]

1. Strategic Assessment:

   • Inventory all physical and virtual components supporting critical functions.

   • Classify infrastructure elements based on maximum tolerable downtime.

   • Identify specialized hardware with unique replacement challenges.

   • Map dependencies between components to understand failure implications.

   • Document resource requirements for minimum acceptable operations.

2. Design Principles for Resilient Systems:

   • Create true redundancy rather than mere backup capabilities.

   • Implement geographic distribution for critical system components.

   • Build capacity ensuring secondary systems handle full production loads.

   • Develop isolation boundaries preventing cascade failures across components.

3. Core Processing Safeguards:

   • Deploy parallel computing environments using N+1 redundancy principles.

   • Establish automated health checking with failover triggers.

   • Create load balancing across redundant processing instances.

   • Design resource isolation preventing “noisy neighbor” problems.

4. Network Resilience Measures:

   • Implement diverse routing paths between essential components.

   • Establish multiple external connectivity providers with dynamic balancing.

   • Create redundant internal communication channels with automatic switching.

   • Design independent management networks for emergency administration.

Environmental Protection:

• Deploy redundant power systems with seamless transition capabilities.

• Implement alternative cooling approaches with independent controls.

• Create multiple physical security layers with overlapping coverage.

• Establish diverse monitoring systems with independent alerting mechanisms.

1. Validation and Maintenance:

   • Conduct regular failover testing under realistic load conditions.

   • Perform scheduled operation from secondary systems to verify readiness.

   • Implement automated verification ensuring configuration synchronization.

   • Create capacity validation confirming redundant systems remain adequate.

2. Cross-Entity Considerations:

   • Establish clear documentation of redundancy capabilities and limitations.

   • Create shared understanding of expected transition times during failures.

   • Develop notification protocols when activating redundant systems.

   • Design complementary approaches where systems interconnect.

From CCM: Control Ownership Rationale. The implementation responsibility for this control is exclusively owned by the CSP, because the CSP is the owner of the business-critical equipment, and responsible for supplementing it with redundancy measures and placing it at an appropriate location of acceptable risk. The CSP is responsible for providing the CSC with redundant equipment and information about the control implementation.

Implementation Guidelines. Applicable to all service models: The strategic placement and construction of data centers are of paramount importance to CSPs. The location of a data center should be carefully considered to minimize disruptions caused by natural phenomena. Factors such as ease of cooling, seismic stability, flood risk, and geopolitical stability must be meticulously evaluated.

Prior to data center implementation, CSPs should conduct a comprehensive site assessment to proactively mitigate potential risks associated with the cloud infrastructure. Engaging with relevant industry groups and standards organizations, can provide valuable insights and guidance during the decision-making process.

The CSP’s redundancy strategy should be compliant with the requirements declared in contracts and SLA with the CSC.

Implementation best practices for equipment redundancy include (but not limited):

• a. Business-Critical Equipment Identification: The equipment that is essential for maintaining core business operations should be identified (e.g., servers, storage systems, network devices, and any other infrastructure components that are critical for data processing, communication, and application availability)

• b. Equipment Redundancy Strategy:

  • i. Redundancy strategies should be aligned with business requirements, business impact analysis, and risk assessments to ensure optimal resource allocation and protection against critical failures

  • ii. The level of redundancy required should be assessed for each business-critical component. This may vary depending on the criticality of the equipment, the potential impact of downtime, and the organization’s risk tolerance

  • iii. Proactively assess, mitigate, and remediate potential risks associated with regional or location-specific failures to maintain service continuity

  • iv. Management plans, including tools and interfaces, should be developed and implemented to effectively manage redundancy and maintain service operations uninterrupted.

• c. Cloud infrastructure services from reputable CSPs that offer redundant data centers across multiple geographical locations should be utilized vi. Systems Redundancy Examples:

  • Equip all critical systems with redundant power supplies to mitigate the risk of power failures. Use separate power grids or sources to ensure diversity

  • Implement diverse network paths to avoid a single point of failure. Use multiple internet service providers (ISPs) and establish redundant connections between data centers

  • Deploy redundant hardware components, such as servers, storage, and networking equipment

  • Utilize technologies like load balancing and failover clustering to distribute the workload across redundant systems • Implement data replication, backups, across geographically dispersed data centers to ensure data availability in case of a site failure

• d. Redundancy Architecture Documentation: A detailed documentation of the redundancy strategy and devised architecture and configurations should be created and maintained

• e. Geographical Dispersion: Mirrored or redundant equipment should be implemented at separate data centers located at a reasonable minimum distance from each other to minimize the risk of simultaneous outages caused by localized events, such as natural disasters or power disruptions

  • i. A multi-location (i.e., redundant systems are deployed across multiple locations within a region) and multi-region redundancy strategy (redundant systems are deployed across multiple regions, each consisting of multiple locations) should be adopted and implemented where possible

  • ii. Data replication strategies should be implemented to ensure data consistency and availability across redundant data centers

• f. Automated Failover Mechanisms: Automated failover mechanisms should be configured to seamlessly switch traffic to the redundant equipment in the event of a primary equipment failure to ensure that operations continue uninterrupted without manual intervention

• g. Testing and Maintenance: Regular testing of redundant equipment should be conducted to ensure its readiness and functionality. Establish a comprehensive maintenance plan for both primary and redundant equipment to maintain system performance and reliability

• h. Continuous Improvement: Redundancy strategies should be regularly reviewed and updated based on evolving business needs, technological advancements and according with industry standards and any relevant regulatory requirements.

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.

Shared Implementation Guidelines

[All Actors]

1. Establish well-documented policies outlining responsibilities, procedures, and reporting mechanisms for ensuring adherence to change control policies.

2. Implement a schedule for regular internal audits and external assessments to evaluate adherence to change control policies and identify improvement areas.

3. Define measurable metrics to track the effectiveness and consistency of change control implementation.

4. Leverage automation tools to support the implementation of change control processes, including change tracking, logging, and reporting.

5. Define clear escalation paths for instances of non-adherence or ineffective change control implementation to ensure timely remediation and accountability.

[Shared between the MP and AP]

1. Focus on managing changes in application logic, APIs, ML models, and data schemas.

2. Use GitOps, CI/CD pipelines, and change tracking in model registries.

Implementation Guidelines for Cloud Service Providers (CSP)

[All Actors]

1. Establish well-documented policies outlining responsibilities, procedures, and reporting mechanisms for ensuring adherence to change control policies.

2. Implement a schedule for regular internal audits and external assessments to evaluate adherence to change control policies and identify improvement areas.

3. Define measurable metrics to track the effectiveness and consistency of change control implementation.

4. Leverage automation tools to support the implementation of change control processes, including change tracking, logging, and reporting.

5. Define clear escalation paths for instances of non-adherence or ineffective change control implementation to ensure timely remediation and accountability.

[Shared between the MP and AP]

1. Focus on managing changes in application logic, APIs, ML models, and data schemas.

2. Use GitOps, CI/CD pipelines, and change tracking in model registries.

From CCM v4.1: Control Ownership Rationale. This control’s implementation responsibility is shared for both CSP and CSC, however, each should implement this control independently from one another. The change management policy and procedures should be managed and baselined independently by each party, the CSP and CSC within their respective corporate business needs, requirements and in alignment with industry standards.

Implementation Guidelines. Applicable to all service models: Establishing robust change control and configuration management processes is essential for CSPs to ensure the stability, security, and reliability of their cloud services. Change control processes ensure that changes to the cloud environment are carefully planned, reviewed, approved, and implemented in a controlled manner. This helps prevent unauthorized or unintended changes that could disrupt service delivery or compromise security. Configuration management processes, on the other hand, focus on maintaining consistent and accurate configurations across the cloud environment, ensuring that systems are properly configured and compliant with security standards and business requirements. The CSP has responsibility for the design, implementation, and management of all supporting infrastructure, virtual elastic compute, server operating systems, storage, and networking, and also middleware, development tools, business intelligence services, and database management systems. A change management process should be in operation to ensure all proposed changes to the services consumed by the CSC are governed and subjected to formal procedures. Applications should be configured as contractually agreed upon.

Policies should include (but not limited to) provisions on the following:

• a. Scope and Objectives: The scope, objectives, roles and responsibilities for the change management process and should be aligned with the organization’s strategic goals, business requirements, and security policies, and comply with the relevant laws, regulations, and standards

  • i. Create a Change Control Board (CCB) that is responsible for reviewing and approving all change requests

  • ii. Form a dedicated change management team responsible for overseeing and executing the change management process

  • iii. Assign clear roles and responsibilities for each phase of the change management process, such as change initiation, review, approval, implementation, testing, and post-implementation review

  • iv. Define what constitutes a change, including configuration changes, software updates, hardware modifications,and data alterations

• b. Change Management Process: Requirements to establish a formal process outlining the change management workflow for managing changes to cloud computing assets should be defined

• c. Change Management Baseline: Requirements for the establishment and maintenance of a change management baseline which includes a standard and approved state of the organization assets that serves as a reference point for the changes. The change management baseline should be reviewed periodically to verify it is accurate and up-to-date

• d. Detection of Baseline Deviation: Requirements for the establishment of a detection baseline deviations process to monitor and audit the configuration of the organization assets regularly, and compare it with the change management baseline in order to detect and report any deviations or anomalies

• e. Exception Management: A process for managing exceptions to the change management policy and procedures. The procedures should include a process for requesting exceptions, reviewing exceptions, approving exceptions, and documenting them

• f. Change Risk Assessment: A risk assessment for all changes to cloud computing assets and ensuring that changes are made with a full understanding of the risks involved and that appropriate measures are taken to minimize those risks

• g. Quality Testing: A defined quality change control, approval and testing process with established baselines, testing, and release standards. The process should include a testing plan, test cases, and acceptance criteria

• h. Change Authorization: An authorization process for all changes to cloud computing assets are authorized and that legitimate changes are approved before they are implemented in production

• i. CSP and CSC Change Agreements: Requirements for change agreements that define the terms and conditions for the changes that directly impact the CSCs owned environments/tenants, such as the scope, frequency, timing, duration, notification, approval, and compensation of the changes

• j. Change Restoration: Change restoration requirements to revert the changes that cause or contribute to the incidents, errors, or deviations, and restore the cloud assets and their baseline configurations to their previous or desired state

• k. Approval: Approval requirements and senior management involvement to ensure alignment with the organization’s strategic goals and risk appetite

  • i. An approval process should be established for any changes or modifications to the policy and procedures

  • ii. A documented record of approvals (including dates, names of approvers, and any relevant comments or discussions) should be maintained

• l. Communication: Effective communication of the policy and procedures should be facilitated to all relevant cloud stakeholders

• m. Maintenance and Reviews: The change control and configuration management policies and procedures should be documented, reviewed and updated at least annually to ensure alignment with evolving cloud security landscape and to reflect changes in cloud technology, regulations, and risks.

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.

Shared Implementation Guidelines

[All Actors]

1. Define quality assurance standards for changes, including minimum thresholds for code quality, test coverage, and acceptable vulnerability levels.

2. Document standardized testing strategies for unit, integration, regression, and user acceptance testing before promoting changes.

3. Mandate security testing (e.g., static code analysis, vulnerability scanning) as part of the change control lifecycle.

4. Leverage automated testing frameworks and continuous integration pipelines to validate changes efficiently and consistently.

5. Ensure all testing activities and results are logged and traceable as part of change documentation.

Implementation Guidelines for Cloud Service Providers (CSP)

[All Actors]

1. Define quality assurance standards for changes, including minimum thresholds for code quality, test coverage, and acceptable vulnerability levels.

2. Document standardized testing strategies for unit, integration, regression, and user acceptance testing before promoting changes.

3. Mandate security testing (e.g., static code analysis, vulnerability scanning) as part of the change control lifecycle.

4. Leverage automated testing frameworks and continuous integration pipelines to validate changes efficiently and consistently.

5. Ensure all testing activities and results are logged and traceable as part of change documentation.

From CCM v4.1: Control Ownership Rationale. This control’s implementation responsibility is shared for both CSP and CSC, however, both should implement this control independently from one another. All quality change control processes and applied changes to systems should be independently baselined, tested, and approved according to their corporate policies and in line with industry standards.

Implementation Guidelines. Applicable to all service models: The CSP should plan to test and review during the change management process. This plan should include test inputs and conditional outcomes. For internal development, the team that oversees change initially can perform such tests. Independent acceptance testing can then be performed to determine whether the system functions as intended.

Testing records should be documented before implementing planned changes to organization assets. The record should comprise a test plan, configuration baseline before the change, test result, and new configuration baseline.

Implementation best practices for this control include (but not limited to):

• a. Quality Change Control Baseline:

  • i. Baselines with key performance indicators (KPIs) and security metrics should be established to assess the impact of changes and ensure that service quality and security are maintained

  • ii. A quality change control process should be implemented to ensure that the changes are consistent, reliable, and compatible with the existing cloud environment configuration

• b. Testing Strategies: Comprehensive testing strategies should be developed that encompass unit testing, integration testing, performance testing, security testing, and user acceptance testing. Automated testing tools should be utilized whenever possible to streamline testing procedures and improve efficiency

• c. Release Standards: Release standards should be defined prior to releasing new features, updates, or patches to cloud services. These standards should address aspects such as code quality, compatibility, security vulnerabilities, and bug fixes

• d. Testing and Deployment Automation: Testing should verify that the changes meet the expected outcomes, performance, and functionality, and do not introduce any errors, defects, or vulnerabilities

  • i. All changes to cloud computing assets should be tested in a non-production environment before implementing them in production

  • ii. Testing processes should be automated where possible to reduce manual effort and expedite the testing cycle

  • iii. Continuous integration (CI) and continuous delivery (CD) pipelines should be utilized to automate the deployment of changes to production environments

• e. User Acceptance Testing (UAT): UAT procedures should be implemented to involve end-users in testing changes. Feedback should be collected from end-users to ensure changes meet functional and usability 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.

Shared Implementation Guidelines

[All Actors]

1. Identify and document potential risks associated with each proposed change, including operational, security, performance, and compliance-related risks.

2. Define the likelihood and impact of each risk, and specify mitigation steps or fallback procedures (e.g., rollback plans, alternative configurations).

3. Include risk evaluation as part of the formal change review and approval workflow.

4. Implement monitoring and logging mechanisms to track the real-time impact of deployed changes and detect early signs of risk materialization.

5. Assign clear ownership and escalation paths for each identified risk, ensuring that designated stakeholders are prepared to intervene if risk thresholds are crossed.

6. Regularly review and update the risk registry to capture lessons learned from previous changes and incorporate them into future change planning.

Implementation Guidelines for Cloud Service Providers (CSP)

1. Identify infrastructure or multi-tenant risks when making backend changes affecting hosted AI services.

2. Track risk metrics such as service stability, resource utilization, or deployment failure rates.

3. Clearly define tenant notification and escalation procedures for changes that carry shared operational risks.

[All Actors]

1. Identify and document potential risks associated with each proposed change, including operational, security, performance, and compliance-related risks.

2. Define the likelihood and impact of each risk, and specify mitigation steps or fallback procedures (e.g., rollback plans, alternative configurations).

3. Include risk evaluation as part of the formal change review and approval workflow.

4. Implement monitoring and logging mechanisms to track the real-time impact of deployed changes and detect early signs of risk materialization.

5. Assign clear ownership and escalation paths for each identified risk, ensuring that designated stakeholders are prepared to intervene if risk thresholds are crossed.

6. Regularly review and update the risk registry to capture lessons learned from previous changes and incorporate them into future change planning.

From CCM: Control Ownership Rationale. This control’s implementation responsibility is shared for both CSP and CSC, however, both should implement this control independently from one another. All configuration changes to systems should be independently baselined, tested, and approved according to their corporate policies and in line with industry standards.

Implementation Guidelines. Applicable to all service models: Risk management plays a critical role in ensuring that changes to cloud assets are implemented in a secure and controlled manner. CSPs should leverage risk management practices to identify, assess, and mitigate potential risks associated with changes, minimizing the potential for errors, security breaches, or disruptions to cloud services.

Implementation best practices for this control include (but are not limited to):

• a. Change Management Process: The process should include a change request form, review and approval process, testing, implementation changes procedures and outcomes documentation. Should be ensured that changes status is continuously tracked and that are made in a controlled and consistent manner, minimizing the risk of errors and disruptions. Change request forms should include:

  • i. Description of the change

  • ii. Justification for the change

  • iii. Potential risks of the change

  • iv. Impact of the change on business operation

• b. Steps to revert the change in case issues arise vi. Approval signatures from relevant stakeholders

• c. Change Risk Management: The impact and type of change should be assessed to determine the risk of the change before it is applies

  • i. Before implementing a change, CSPs should conduct a thorough impact assessment to identify potential consequences on cloud assets, performance, security, and compliance requirements

  • ii. Changes are categorized based on their impact, urgency, and risk profile. High-risk changes receive prioritized attention and undergo rigorous review and testing

  • iii. Evolving risks associated with cloud assets and change management practices should be regularly identified and risk management strategies reviewed and updated accordingly

• d. Change Management Tools:

  • i. A change management workflow should be defined to ensure that changes are submitted, reviewed, and approved by relevant stakeholders, including security, operations, and development teams to prevent unauthorized or poorly managed changes

  • ii. Change management tools should be adopted to effectively record the change management workflow process

• e. Stakeholders Collaboration:

  • i. Collaborate with relevant internal and external interested parties involved in the change and risk management processes

  • ii. An appropriate level of subject matter expertise and the roles of reviewers and approvers of changes should be derived by a combination of change type and risk level

• f. Continuous Monitoring and Logging Tools: Should be implemented to provide real-time reporting/monitoring capabilities of the change progress so that timely informed decisions can be made to assist with managing emerging risks resulting from the change

• g. Configuration Management Tools: These tools track and manage cloud infrastructure configurations, ensuring consistency and adherence to change management policies and procedures

• h. Change Review Committee: Security, Privacy, Risk and Compliance personnel should be made part of change review committees

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.

Shared Implementation Guidelines

[All Actors]

1. Define baseline configurations for every critical asset (e.g., systems, containers), AI platforms, model environments, orchestration pipelines and application services.

2. Embed security, compliance and operational requirements (least-privilege, hardened services, logging defaults, resource limits) in each baseline.

3. Route every proposed addition, update or removal through a formal approval workflow with multi-stakeholder sign-off (e.g., engineering, security, compliance, operations).

4. Store approved baselines and change packages in tamper-evident, version-controlled repositories; capture who/what/when metadata for audit.

5. Block or flag unauthorised changes; require rollback or emergency-exception handling per CCC-08 when deviations are detected.

6. Review and revise baselines on a regular basis or whenever major architectural change, new regulation or material threat intelligence changes occur.

Implementation Guidelines for Cloud Service Providers (CSP)

1. Offer customers secure, validated baseline configurations for common workloads (e.g., hardened VM images, secure container templates, baseline IAM roles).

2. Provide tools to enforce the use of approved baselines and prevent drift during provisioning.

3. Publish updates to baselines following CVE disclosures or platform changes, along with changelogs and security justifications.

[All Actors]

1. Define baseline configurations for every critical asset e.g., systems, containers, AI platforms, model environments, orchestration pipelines and application services.

2. Embed security, compliance and operational requirements (least-privilege, hardened services, logging defaults, resource limits) in each baseline.

3. Route every proposed addition, update or removal through a formal approval workflow with multi-stakeholder sign-off (e.g., engineering, security, compliance, operations).

4. Store approved baselines and change packages in tamper-evident, version-controlled repositories; capture who/what/when metadata for audit.

5. Block or flag unauthorised changes; require rollback or emergency-exception handling per CCC-08 when deviations are detected.

6. Review and revise baselines on a regular basis or whenever major architectural change, new regulation or material threat intelligence changes occur.

From CCM: Control Ownership Rationale. This control’s implementation responsibility is shared for both CSP and CSC, however, both should implement this control independently from one another. All configuration changes to systems should be independently baselined, tested, and approved according to their corporate policies and in line with industry standards.

Implementation Guidelines. Applicable to all service models: The CSP should establish procedures and implement technical measures to prevent and/or detect any unwanted/unauthorized changes (e.g., additions, removals, and updates) to organizational assets in production, including applications, systems, infrastructure, configurations.

Organizations should permit only qualified and authorized individuals to access systems for purposes of initiating changes. Access restrictions include physical and logical access controls such as cryptographic controls or MFA.

Implementation best practices for this control include (but not limited to):

• a. Centralized Asset Management System: An accurate and up-to-date inventory of all organization assets should be leveraged and used as a single source for tracking the addition, removal, updates of assets (refer to DCS-06)

• b. Change Identity and Access Management: A robust IAM system should be implemented to control user access and changes to assets based on their identities, roles, and entitlements. Strong authentication mechanisms should be used, such as multi-factor authentication (MFA), to prevent unauthorized changes to assets

• c. Change by Least Privilege Principle: The principle of least privilege should be implemented to minimize the risk of unauthorized or accidental changes by restricting access to sensitive assets and configurations

• d. Change by SoD: Ensure sufficient separation of duties exists, such that that same team cannot both develop and authorize changes

• e. Change Monitoring and Logging:

  • i. Cloud assets configurations, access logs, and user activities should be continuously monitored to detect unauthorized changes or anomalous behavior

  • ii. Unauthorized or unintended changes that could compromise security or disrupt cloud services should be detected, investigated and reported on

  • iii. Automated monitoring tools should be used to identify potential security threats and prevent unauthorized changes

• f. Segregate Environments: Segregation of production systems from development and testing environments should be leveraged to minimize the risk of unauthorized changes or security vulnerabilities affecting production systems.

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.

Shared Implementation Guidelines

[All Actors]

1. Operate a formal change-control workflow for every configuration, code, model or infrastructure change that could affect a customer environment.

2. Require each change request to contain version information, test evidence, risk assessment and an explicit rollback plan.

3. Record every approved baseline and subsequent change in version-controlled tooling (Git / IaC repository / model registry) with immutable metadata (who, what, when, why).

4. Enforce least-privilege access so only authorised personnel or automations can execute approved changes.

5. Use controlled deployment mechanisms (CI/CD, change-windows, blue–green) that honour customer SLAs and enable safe roll-forward or rollback.

6. Validate that the running state matches the approved baseline; block or auto-revert unauthorised deviations.

7. Perform post-change verification and retrospective analysis to capture regressions, misconfigurations or customer impact.

[All Actors except AIC]

1. Obtain explicit customer authorisation (per SLA or written approval) before applying changes that materially affect a customer-owned tenant or environment.

Implementation Guidelines for Cloud Service Providers (CSP)

1. Provide structured change request interfaces (e.g., change sets, update plans) for modifying configurations on managed services.

2. Ensure configuration changes made via APIs, consoles, or IaC are logged, versioned, and reversible.

3. Support customer-defined guardrails (e.g., policy-as-code) to prevent unsafe configuration changes.

[All Actors]

1. Define baseline configurations for every critical asset (e.g., systems, containers), AI platforms, model environments, orchestration pipelines and application services.

2. Embed security, compliance and operational requirements (least-privilege, hardened services, logging defaults, resource limits) in each baseline.

3. Route every proposed addition, update or removal through a formal approval workflow with multi-stakeholder sign-off (e.g., engineering, security, compliance, operations).

4. Store approved baselines and change packages in tamper-evident, version-controlled repositories; capture who/what/when metadata for audit.

5. Block or flag unauthorised changes; require rollback or emergency-exception handling per CCC-08 when deviations are detected.

6. Review and revise baselines on a regular basis or whenever major architectural change, new regulation or material threat intelligence changes occur.

[All Actors except AIC]

1. Obtain explicit customer authorisation (per SLA or written approval) before applying changes that materially affect a customer-owned tenant or environment.

From CCM: Control Ownership Rationale. This control’s implementation responsibility is shared for both CSP and CSC, however, both should implement this control independently from one another. All configuration changes to systems utilized should be managed appropriately within the agreement between the CSP and CSC. For the CSP to implement this control and include its provisions in SLAs (i.e., limiting changes impacting the CSCs’ systems), there is a role for the CSC to play, namely to discuss, refine, and approve such provisions.

Implementation Guidelines. Processes and procedures established by both the CSP and CSC should reflect change management responsibilities. Each party should acknowledge the other’s responsibility, which should be part of a written change management agreement. The acknowledgment should include a reference to limitations related to changes impacting CSC-owned environments. The CSC should be able to configure, control or communicate exclusion windows to the CSP when changes cannot occur.

IaaS Provider: The CSP is responsible for establishing their change management and testing processes, only for the compute, storage, and networking resources offered as part of the IaaS service. No changes should be undertaken to these systems without prior notice to the CSC as the dependent applications could be negatively affected by any CSP-managed asset being changed. The CSP Forward Schedule of Changes (FSC) program should be agreed with the CSC as part of a service level agreement.

PaaS Provider: The CSP has responsibility for the design, implementation, and management of all supporting infrastructure—virtual elastic compute, server operating systems, storage, and networking—but also middleware, development tools, business intelligence services and database management systems, so any change should be agreed in advance by the CSC prior to implementation.

SaaS Provider: The CSP has responsibility for the design, implementation, and asset management of:

• all supporting infrastructure—virtual elastic compute, server operating systems, storage, and networking

• middleware, development tools, business intelligence services and database management systems

• applications configured as contractually with the CSC

Applicable to all service models: Additional recommendations that apply for the CSP include (but not limited to):

• a. SLA Authorized Changes and Definition:

  • i. The change management process should be integrated with SLAs to ensure that both CSCs and CSPs are accountable for adhering to this process

  • ii. What constitutes an authorized change should be defined in the SLA such as specifying the types of changes, the scope of changes, and the approval process for each type of change

• b. Change Management Notification and Approval: CSPs should notify the CSCs of and have the opportunity to review and approve any configuration changes that may impact their cloud environment

  • i. A formal change management process should be established with clear notification procedures for CSCs (e.g., a change request (CR) process that includes detailed information about the proposed change, its purpose, impact, potential risks, and rollback procedures)

  • ii. Provide CSCs with detailed information about proposed changes, including the potential impact on their environment

  • iii. Provide CSCs with timely notifications about proposed changes, including the CR, the expected impact, and the timeline for implementation

  • iv. Obtain CSC approval for proposed changes impacting the CSC environment before implementation

• c. Schedule changes that directly impact CSC-owned environments/tenants during agreed-upon maintenance windows (whenever possible)

• d. Change Rollback and Remediation: Remediation procedures should be established within SLAs in case of unauthorized or disruptive changes, including rollback strategies and compensation mechanisms

• e. Post-change reports: Provide CSCs with post-change reports summarizing the implementation of the change, any issues encountered, and the final state of the environment

• f. Continuous Monitoring and Evaluation: CSPs should continuously monitor and improve their change management processes to minimize disruption to CSCs’ environments

  • i. Include change management performance metrics in SLAs to measure the effectiveness of the process in preventing unauthorized or disruptive changes

  • ii. Solicit feedback from CSCs on their change management processes

  • iii. Review and update the SLA provisions related to change management regularly to reflect changes in cloud infrastructure, applications, and CSCs’ requirements

NOTE: In an emergency, the CSP may need to apply changes that impact the CSC-owned environments without the explicit authorization of the CSC, in case those emergency changes would be required for the overall security of the CSP’s system. If those types of changes are applied, the CSC should be consulted as soon as possible (Refer to exception change management procedures in CCC-08).

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.

Shared Implementation Guidelines

[All Actors]

1. Identify and define critical baseline elements that must be monitored for deviation, including system configurations, AI model artifacts and versions, training datasets, hyperparameters, infrastructure specifications, orchestration configurations, and access control settings.

2. Maintain version-controlled records of all approved baselines, ensuring traceability and auditability of original configuration states.

3. Implement automated tools to detect configuration drift or unauthorized deviations from the approved baselines in real-time or near real-time.

4. Establish materiality threshold criteria for what constitutes a material deviation that warrants investigation, rollback or emergency change.

5. Document procedures for responding to baseline deviations, including root cause analysis, corrective actions, and optional incident escalation.

6. Ensure deviation detection mechanisms are tested periodically and integrated with the organization’s broader change control and security operations workflows.

7. Review and approve configuration baselines at least annually or upon major changes to organization assets.

Implementation Guidelines for Cloud Service Providers (CSP)

Role Specific:

1. Provide customers with capabilities to establish, maintain, and monitor configuration baselines for cloud-hosted resources supporting AI systems (e.g., identity and access management policies, compute configurations, storage settings, networking controls, and AI pipeline infrastructure).

2. Establish mechanisms for detecting and reporting configuration deviations from approved baselines, including integrations with infrastructure-as-code, policy-as-code, or compliance monitoring frameworks.

3. Support remediation workflows that enable restoration of approved configurations, including automated or operator-initiated rollback to last known good state when deviations are detected.

4. Maintain version-controlled baseline and configuration management for provider-managed cloud services and ensure changes to underlying service configurations are documented, approved, and traceable through change management processes.

[All Actors]

1. Identify and define critical baseline elements that must be monitored for deviation, including system configurations, AI model versions, training datasets, hyperparameters, infrastructure specifications, and access control settings.

2. Maintain version-controlled records of all approved baselines, ensuring traceability and auditability of original configuration states.

3. Implement automated tools to detect configuration drift or unauthorized deviations from the approved baselines in real-time or near real-time.

4. Establish materiality threshold criteria for what constitutes a material deviation that warrants investigation, rollback or emergency change.

5. Document procedures for responding to baseline deviations, including root cause analysis, corrective actions, and optional incident escalation.

6. Ensure deviation detection mechanisms are tested periodically and integrated with the organization’s broader change control and security operations workflows.

7. Review and approve configuration baselines at least annually or upon major changes to organization assets.

From CCM v4.1: Control Ownership Rationale. This control’s implementation responsibility is shared for both CSP and CSC, however, both should implement this control independently from one another. All configuration changes to systems should be independently baselined, tested, and approved according to their corporate policies and in line with industry standards.

Implementation Guidelines. Applicable to all service models: A change management baseline is a snapshot of the current state of all cloud assets at a specific point in time. This baseline serves as a reference point against which all subsequent changes to cloud assets are evaluated and measured.

The purpose of establishing a change management baseline is to ensure that changes are controlled, authorized, and implemented in a consistent and orderly manner to minimize the risk of unintended consequences and maintain the security and integrity of the cloud environment.

The CSP should develop, document, and maintain under version control current baseline configurations and should review and update the baseline configurations when required due to updates or newly installed components.

Implementation best practices for this control include (but are not limited to):

• a. Change Management Baseline: A change management baseline should be implemented that includes a standard and approved state of the organization’s cloud assets that serves as a reference point for the changes. The baseline should include:

  • i. A list of all cloud assets (e.g., CMDB), including hardware, software components, their relevant data, their attributes and relationships, enabling effective change management

  • ii. The configuration/security settings, version numbers, patch status that are subject to change management should be captured for each cloud asset (e.g., virtualization, network settings, security settings, and VMs, applications/APIs configuration)

  • iii. Key performance indicators (KPIs) that measure the health, performance, and utilization of cloud assets

  • iv. The current security posture of the cloud environment, including vulnerability assessments, risk assessments, and compliance audits

• b. Documentation: An accurate documentation for each cloud asset baseline should be maintained, including its creation date, author, and associated assets

• c. Changes Tracking and Implementation:

  • i. All changes made to cloud assets should be monitored and tracked against the baseline and be well documented (e.g., who made the change, when it was made, what was changed, and any issues or incidents that arise reported on)

  • ii. Version control systems (e.g., Git) should be utilized to track baseline changes and maintain historical records

  • iii. Proposed changes should be evaluated against the baseline and associated policies before approval

  • iv. The baseline should be updated and documented whenever a new change is implemented, and be stored and backed up in a secure and accessible location

• d. Deployed changes should be post-verified that match the approved version and adhere to the established baseline

CCC-07: Detection of Baseline Deviation

Control Specification

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

Shared Implementation Guidelines

[All Actors]

1. Define baseline states and metrics for every relevant layer: configurations, infrastructure, service behaviour, model-performance KPIs and security settings.

2. Continuously monitor telemetry and logs against those baselines by using rules-based or ML-driven detectors (e.g., SIEM, APM, drift-detection services).

3. Generate automated alerts (severity, owner, escalation path) as soon as deviations exceed predefined thresholds.

4. Record every deviation event with root cause, corrective action and outcome; store results in a change / incident repository for audit and learning.

5. Review and tune baselines, thresholds and detection logic on a regular basis or whenever major incidents, architectural change or new threat intelligence.

Implementation Guidelines for Cloud Service Providers (CSP)

1. Provide customers with performance monitoring tools that help track model outputs and evaluate compliance with performance standards.

2. Ensure that infrastructure used by models is optimized for performance, offering necessary computational resources to maintain model efficiency.

3. Implement automated performance evaluation systems that allow customers to monitor the ongoing effectiveness of models.

4. Offer transparency into model performance data, helping customers assess how their AI models are functioning within the cloud environment.

[All Actors]

1. Define baseline states and metrics for every relevant layer: configurations, infrastructure, service behaviour, model-performance KPIs and security settings.

2. Continuously monitor telemetry and logs against those baselines by using rules-based or ML-driven detectors (e.g., SIEM, APM, drift-detection services).

3. Generate automated alerts (severity, owner, escalation path) as soon as deviations exceed predefined thresholds.

4. Record every deviation event with root cause, corrective action and outcome; store results in a change / incident repository for audit and learning.

5. Review and tune baselines, thresholds and detection logic on a regular basis or whenever major incidents, architectural change or new threat intelligence.

From CCM v4.1: Control Ownership Rationale. This control’s implementation responsibility is shared for both CSP and CSC, however, both should implement this control independently from one another. All configuration changes to systems should be independently baselined, tested, and approved according to their corporate policies and in line with industry standards.

Implementation Guidelines. Applicable to all service models: By proactively detecting and addressing anomalous changes, CSPs can minimize the risk of security breaches, data loss, and compliance violations. When an issue is detected, automated alerts should strongly be considered to notify stakeholders for further investigation. When a deviation is detected, the organization should follow the incident management process (refer to SEF-01).

Implementation best practices for this control include (but are not limited to):

• a. Change Management Baseline Deviations: Changes deviation should be evaluated against the configuration baseline that serves as a reference point for identifying such deviations (refer to CCC-06)

• b. Anomaly Detection Thresholds: Thresholds for determining which changes deviate from the established baseline should be defined and based on historical data, risk assessments, and industry best practices

• c. Change Monitoring Tools: Automated and manual tools and techniques such as configuration scanners, change detectors, and configuration audits, should be utilized to collect and analyze the configuration data and identify any differences or discrepancies to the baseline

• d. Real-time Alerting Mechanisms: Real-time alerting mechanisms should be configured to notify security teams and relevant stakeholders when anomalies are detected. These alerts should provide detailed information about the anomaly, its potential impact, and recommended actions

• e. Risk-based Alerts Prioritization: Alerts should be prioritized based on the potential severity and impact of the detected anomaly to enable security teams focus their attention on the most critical issues and respond promptly

• f. Anomalies Assessment Automation: Initial investigation steps for detected anomalies should be employed whenever possible to reduce the time required to identify the root cause of anomalies. This could involve automated correlation of events, data analysis, and threat intelligence lookup

• g. Escalation Process: An escalation process should be defined for handling anomalies that require further investigation or remediation. This process should specify who is responsible for each step, the timeline for response, and the communication protocols

• h. Anomalies and Remediation Actions Documentation: All detected anomalies, the investigation process, and the actions taken to remediate the issue should be documented (i.e., to understand the root cause of anomalies, prevent recurrences, and demonstrate compliance with security regulations)

• i. Detection Rules and Thresholds Review: Detection rules and thresholds should be regularly reviewed and refined based on new threat intelligence, emerging vulnerabilities, and changes in cloud infrastructure or applications

• j. Stakeholders Notification: Relevant stakeholders, such as the change management team, the CSP and CSC should be notified and alerted of any deviations or anomalies, and provided with the necessary information and evidence for further investigation and resolution

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.

Shared Implementation Guidelines

[All Actors]

1. Define a formal exception workflow that specifies: eligibility (regular vs. emergency), required risk assessment, approvers, maximum duration and/or compensating controls.

2. Embed the workflow in change-/config-management tooling (e.g., CI/CD gates, IaC pull-requests) so unauthorised changes are blocked or tagged until the exception is approved.

3. Log every exception with full metadata (requester, reason, scope, approvals, expiry date); store in the same repository used for normal change records.

4. Implement an emergency fast-track that allows rapid change when service impact or security risk is imminent; require retrospective approval and review within organization defined SLA.

5. Review the open-exception register on a regular, risk-based cadence and either close, renew with justification, or convert to standard policy updates.

6. Align all steps with GRC-04 (policy-exception requirements) to ensure single governance across policies, risk assessments, and stakeholder notifications.

Implementation Guidelines for Cloud Service Providers (CSP)

1. Provide risk management frameworks that allow customers to assess and mitigate risks associated with AI models running in the cloud.

2. Implement continuous monitoring of the cloud infrastructure to detect risks that could impact model performance or security.

3. Offer tools to help customers manage the risks associated with deploying AI models on cloud infrastructure, such as disaster recovery options.

4. Ensure that customers have access to the necessary resources to conduct risk assessments of both AI models and cloud infrastructure.

[All Actors]

1. Define a formal exception workflow that specifies: eligibility (regular vs. emergency), required risk assessment, approvers, maximum duration and/or compensating controls.

2. Embed the workflow in change-/config-management tooling (e.g., CI/CD gates, IaC pull-requests) so unauthorized changes are blocked or tagged until the exception is approved.

3. Log every exception with full metadata (requester, reason, scope, approvals, expiry date); store in the same repository used for normal change records.

4. Implement an emergency fast-track that allows rapid change when service impact or security risk is imminent; require retrospective approval and review within organization defined SLA.

5. Review the open-exception register on a regular, risk-based cadence and either close, renew with justification, or convert to standard policy updates.

6. Align all steps with GRC-04 (policy-exception requirements) to ensure single governance across policies, risk assessments, and stakeholder notifications.

From CCM v4.1: Control Ownership Rationale. This control’s implementation responsibility is shared for both CSP and CSC, however, both should implement this control independently from one another. All configuration changes to systems should be independently baselined, tested, and approved according to their corporate policies and in line with industry standards.

Implementation Guidelines. Applicable to all service models: CSPs should implement a robust procedure for managing exceptions, including emergencies, in the change and configuration process to ensure the availability, security, and reliability of their cloud services. Effective exception management ensures that changes are implemented in a controlled manner, even in the face of unexpected events or urgent situations.

Implementation best practices for this control include (but are not limited to):

• a. Exception Categories: Different categories of exceptions should be defined, including routine exceptions, urgent exceptions, and emergencies in order to prioritize responses based on the severity and urgency of the situation

• b. Categories Approval Process: Approval processes for each exception category should be defined by specifying who has the authority to approve exceptions and the required documentation. Ensure that emergency exceptions have a streamlined approval process to minimize delays

• c. Exception Requests Documentation: Documentation of all exception requests should be mandated, including the nature of the exception, justification for the exception, potential risks, and mitigation measures to provide transparency and accountability for exception management

• d. Exceptions Communication: Exceptions should be communicated to relevant stakeholders promptly, including the change management team, security team, and affected CSCs

• e. Exceptions Rollback Procedures: Rollback procedures should be established for all exceptions, especially those involving critical systems or data

• f. Post-Exception Reviews: Thorough post-exception reviews should be conducted to analyze the root cause of the exception, identify lessons learned, and implement preventive measures to minimize the likelihood of similar incidents in the future

• g. Exception management and Incident Response Integration: Exception management should be integrated with the incident response process to ensure a coordinated response to security incidents or other disruptions that require immediate action

• h. Exception Management Reviews: Exception management procedures should be regularly reviewed and refined based on feedback from post-exception reviews, changes in cloud infrastructure or applications, and evolving security threats

• i. Exception Records Documentation and Maintenance: A centralized repository of exception records should be maintained for the collection and preservation of evidence and chain of custody documentation for incident management analysis purposes, including the nature of the exception, approval details, rollback procedures, and post-exception review findings

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.

Shared Implementation Guidelines

[All Actors]

1. Define rollback procedures for critical systems, configurations, models, and services, ensuring that fallback mechanisms are in place in case of failed or unauthorized changes.

2. Establish rollback baselines by capturing pre-change states (e.g., system configurations, model weights, orchestration templates, and environment variables) as part of every approved change request.

3. Store rollback baselines in version-controlled repositories or configuration management tools with traceable metadata (who, what, when).

4. Implement automated or semi-automated rollback mechanisms that allow rapid restoration to the last known good state in the event of an error, misconfiguration, or breach.

5. Define a formal rollback process, including initiation criteria, required approvals, execution steps, and post-rollback validation (e.g., functional and security checks).

6. Document rollback events, including cause, execution steps, impact, and lessons learned, to improve future change resilience and readiness.

Implementation Guidelines for Cloud Service Providers (CSP)

1. Provide infrastructure-level rollback capabilities (e.g., snapshot restoration, config reversion, version rollbacks for hosted services).

2. Enable rollback logs and metadata visibility for tenants to verify root cause and impact.

3. Support customer-defined rollback policies, thresholds, and automation logic in cloud-native tooling.

[All Actors]

1. Define rollback procedures for critical systems, configurations, models, and services, ensuring that fallback mechanisms are in place in case of failed or unauthorized changes.

2. Establish rollback baselines by capturing pre-change states (e.g., system configurations, model weights, orchestration templates, and environment variables) as part of every approved change request.

3. Store rollback baselines in version-controlled repositories or configuration management tools with traceable metadata (who, what, when).

4. Implement automated or semi-automated rollback mechanisms that allow rapid restoration to the last known good state in the event of an error, misconfiguration, or breach.

5. Define a formal rollback process, including initiation criteria, required approvals, execution steps, and post-rollback validation (e.g., functional and security checks).

6. Document rollback events, including cause, execution steps, impact, and lessons learned, to improve future change resilience and readiness.

From CCM v4.1: Control Ownership Rationale. This control’s implementation responsibility is shared for both CSP and CSC, however, both should implement this control independently from one another. All configuration changes to systems should be independently baselined, tested, and approved according to their corporate policies and in line with industry standards.

Implementation Guidelines. Applicable to all service models: Implementing a robust process for proactively rolling back changes to a previously known good state in case of errors or security concerns is essential for CSPs to maintain the stability, security, and reliability of their cloud services. A well-defined rollback process ensures that changes can be reversed quickly and effectively, minimizing the potential impact of errors or security incidents. The CSC should be notified if deployment of changes fail and if the roll back occurred.

Implementation best practices for this control include (but are not limited to):

• a. Rollback Baseline:

  • i. A rollback baseline that includes snapshots, backups and restore points of all critical cloud assets at a known stable state should serve as a reference point for recovery and restoring the environment

  • ii. Detailed change logs and backups of configurations should be maintained to facilitate rollback procedures

• b. Rollback Process:

  • i. Rollback process and supporting procedures should be established that can be implemented quickly and effectively in case of issues

  • ii. Rollback procedures should include identifying rollback points, triggering rollbacks, and verifying the success of rollbacks

  • iii. Rollback procedures should be automated whenever possible to minimize the time and effort required to revert changes (automated tools can be used to restore configurations, data, and applications from the rollback baseline)

• c. Rollback Triggers: The triggers for initiating a rollback should be defined, including specific error codes, security alerts, or performance degradation beyond acceptable thresholds and should be configurable to align with the CSP’s risk tolerance and security policies

• d. Rollback Testing Strategy: Rollback procedures should be regularly tested to ensure they are effective and functioning as intended. Use staging environments or isolated test environments to conduct rollback simulations without impacting production systems

• e. Rollback Procedures Documentation: Rollback procedures should be documented, including the steps involved, the tools used, and the expected outcomes

• f. Rollback and Change Management Integration: Rollback procedures should be integrated with the change management process to ensure that rollback plans are considered during change implementation and that rollback triggers are aligned with change approval processes

• g. Rollback History: A history of rollback events should be maintained, including the date, time, reason for rollback, and the specific changes reverted. This historical data provides valuable insights for identifying patterns, improving rollback procedures, and demonstrating compliance with security regulations

• h. Rollback Procedures Reviews: Rollback procedures should be regularly reviewed and refined based on testing results, feedback from rollback events, and evolving security threats or cloud infrastructure changes

• i. Rollback Simulation Exercises:

  • i. Periodic rollback simulation exercises should be conducted to test the effectiveness of rollback procedures and identify areas for improvement

  • ii. Have a dedicated team responsible for handling change rollbacks and remediation efforts

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.

Shared Implementation Guidelines

[All actors] Roles/Controls/Guidelines (Baseline) before application of role context:

1. Establish and document policies and procedures for Cryptography, Encryption, and Key Management.

2. Approve the policies and procedures through formal governance processes (e.g., security committee, CISO).

3. Communicate the policies and procedures to all relevant stakeholders.

4. Apply the approved policies and procedures to all systems, services, and processes under the role’s control.

5. Evaluate the effectiveness of policy implementation using internal audits, technical reviews, and encryption control validations.

6. Review and update the policies and procedures at least annually, or when significant system, model, or regulatory changes occur.

Implementation Guidelines for Cloud Service Providers (CSP)

Role Specific

1. Collaborate with orchestrated service providers and application providers to ensure model-serving endpoints and encrypted model payloads are integrated according to the Model Provider’s approved cryptographic policies and do not introduce inconsistencies in downstream encryption coverage.

2. Maintain isolated development, testing, and production environments for model components, each bound by distinct encryption policy enforcement rules, to prevent cross-contamination of key material or unauthorized model data access.

3. Define and manage policy exceptions for controlled model-sharing scenarios (e.g., open-source releases or customer-delivered models), ensuring that any deviation from baseline encryption requirements is formally documented, reviewed, and scoped to approved distribution channels.

[All Actors] Roles/Controls/Guidelines (Baseline) before application of role context:

1. Establish and document policies and procedures for Cryptography, Encryption, and Key Management.

2. Approve the policies and procedures through formal governance processes (e.g., security committee, CISO).

3. Communicate the policies and procedures to all relevant stakeholders.

4. Apply the approved policies and procedures to all systems, services, and processes under the role’s control.

5. Evaluate the effectiveness of policy implementation using internal audits, technical reviews, and encryption control validations.

6. Review and update the policies and procedures at least annually, or when significant system, model, or regulatory changes occur.

From CCM v4.1: Control Ownership Rationale. This is a “Shared (Independent)” responsibility between the CSP and the CSC as the creation of a Cryptography, Encryption and Key Management policy by each party is essential for effective security. The CSP should offer cryptography services, and in such a case it is responsible for the infrastructure that supports these services. The CSC, on the other hand, is responsible for correctly using these services to secure their data, for instance, choosing when and what data to encrypt, and managing access to encryption keys.

Implementation Guidelines. The CSP should have a robust system for cryptographic management with clear policies and procedures for encryption and key management, including key generation, distribution, rotation, revocation, destruction, activation, suspension, deactivation, archival, compromise, recovery, inventory management, purposes, and access. These policies should be reviewed and updated at least annually.

IaaS Provider: Policies and procedures should be in place that dictate how and when these encryption methods are to be used, who has access to the keys, how the lifecycle of these keys is managed, roles and responsibilities, data protection, change management, risk management, monitoring, reporting, incident handling, and audit. An IaaS provider should offer mechanisms for encryption both in transit and at rest for all data, along with a key management service. The CSP should ensure that these services comply with the latest security standards and best practices.

PaaS Provider: Policies and procedures should be in place to guide the usage and management of these encryption methods and keys, including change management and risk management practices. A PaaS provider should offer platform-level encryption for data at rest and in transit, including a secure key management system. The CSP should adhere to security best practices and standards, including data protection protocols like data encryption and algorithm selection.

SaaS Provider: Policies and procedures should be in place that dictate how encryption is handled at the application level, including key management, again featuring the full spectrum of key management activities. The provider should ensure all data at rest and in transit is encrypted using approved cryptographic protection methods. The CSP should offer the CSC the ability to manage their own keys where feasible and monitor the technology closely to keep up with emergence of threats and vulnerabilities. The CSP should ensure incident handling procedures, audit mechanisms, and activity logging for encryption and key management processes.

Policies should include (but not limited to) provisions on the following:

• a. Scope and Objectives:

  • i. Scope definition and governance of the organization’s use of cryptography, encryption, and key management practices to protect sensitive data

  • ii. Objectives for the secure implementation of cryptographic controls for data security and the establishment of key management practices to safeguard encryption keys from unauthorized access, modification, or disclosure

• b. Roles and Responsibilities: Responsibilities of all entities involved in managing cryptographic controls and the encryption key lifecycle. This includes responsibilities for generating, distributing, storing, rotating, and disposing of keys

• c. Encryption Standards: Cryptographic data security and protection requirements, for both data in transit and at rest and covering the necessary encryption standards, algorithms and best practices

• d. Cryptography Change Management: Procedures for making changes to cryptographic controls and encryption key management, including who can authorize changes, how changes should be documented, and processes for testing and auditing changes

• e. Risk Management: Procedures for identification, assessment, and mitigation of risks associated with cryptographic controls and key management that should be integrated into the CSP’s broader risk management framework

• f. Key Management Activities: Requirements regarding key management activities, including key generation, distribution, rotation, revocation, destruction, activation, suspension, deactivation, archival, compromise, recovery, inventory management, purposes, and access

• g. Monitoring and Reporting: Monitoring of cryptographic controls and key management practices, along with regular reporting of their status, including any anomalies or potential breaches to the CSC

• h. Approval: Approval requirements and senior management involvement to ensure alignment with the organization’s strategic goals and risk appetite

  • i. An approval process should be established for any changes or modifications to the policy and procedures

  • ii. A documented record of approvals (including dates, names of approvers, and any relevant comments or discussions) should be maintained i. Communication: Effective communication of the policy and procedures should be facilitated to all relevant cloud stakeholders

• i. Maintenance and Reviews: Cryptography, Encryption, and Key Management policies and procedures should be documented, reviewed and updated at least annually to ensure alignment with evolving cloud security landscape and to reflect changes in cloud technology, regulations, and risks

CEK-02: CEK Roles and Responsibilities

Control Specification

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

Shared Implementation Guidelines

[All Actors] Applies to all Roles (Baseline) before application of role context:

1. Establish and document policies and procedures for Cryptography, Encryption, and Key Management.

2. Approve the policies and procedures through formal governance processes (e.g., security committee, CISO).

3. Communicate the policies and procedures to all relevant stakeholders.

4. Apply the approved policies and procedures to all systems, services, and processes under the role’s control.

5. Evaluate the effectiveness of policy and procedure implementation using internal audits, technical reviews, and encryption control validations.

6. Review and update the policies and procedures at least annually, or when significant system, model, or regulatory changes occur.

Implementation Guidelines for Cloud Service Providers (CSP)

Role Specific

1. Map encryption and key management responsibilities across infrastructure teams (e.g., compute, storage, network security) and document role-specific accountability for cloud-native key lifecycle services.

2. Implement identity and access controls to restrict key management operations (e.g., creation, rotation, destruction) to authorized personnel based on least privilege and role-based access policies.

3. Provide audit trails and evidence of control execution by correlating IAM activity, key usage logs, and role-based enforcement across encryption-related services.

[All Actors] Applies to all Roles (Baseline) before application of role context:

1. Establish and document policies and procedures for Cryptography, Encryption, and Key Management.

2. Approve the policies and procedures through formal governance processes (e.g., security committee, CISO).

3. Communicate the policies and procedures to all relevant stakeholders.

4. Apply the approved policies and procedures to all systems, services, and processes under the role’s control.

5. Evaluate the effectiveness of policy and procedure implementation using internal audits, technical reviews, and encryption control validations.

6. Review and update the policies and procedures at least annually, or when significant system, model, or regulatory changes occur.

From CCM v4.1: Control Ownership Rationale. This is a “Shared (Independent)” responsibility between the CSP and CSC, because the CSP is responsible for defining and implementing roles and responsibilities for cryptographic operations and key management inside their organization. In order to correspond with the CSC’s individual security demands, the CSP is expected to provide configurable options related to these duties. However, the CSP has no control over how the CSC manages the options presented, making the role ‘independent’. Depending on the tools and features provided, the CSP might influence the CSC’s roles and responsibilities, in particular with service models such as SaaS.

Implementation Guidelines. IaaS Provider:

• a. define and enforce roles and responsibilities around key managers, ensuring they cannot access protected data or the cryptographic engine. Also, provide the CSC with robust access controls and role definition capabilities within their platform. This includes enabling the CSC to implement the principles of SoD and split knowledge

• b. incorporate practices like SoD, splitting knowledge, and least privilege access to cryptographic resources and processes

• c. establish clear policies for the management of both operational and backed-up key information storage and recovery. Assist customers in defining cryptoperiods, overseeing key and digital certificate inventories, and verifying the integrity of stored key information prior to use. Manage the process of revoking compromised keys and creating replacement keys or digital certificates. Maintain transparency throughout these processes

• d. offer secure solutions for key storage and management, including secure distribution of private and secret keys and the metadata, and provide customers with the ability to securely generate, revoke, and destroy their cryptographic keys

PaaS Provider:

• a. define roles and responsibilities for the key management system, including a policy authority responsible for all operational CKMS roles, and reports to IT executives

• b. manage the encryption and key management at the platform level, securing the runtime environment to prevent unauthorized access to cryptographic keys and protecting keys in use

• c. ensure that policies are in place for storage and recovery of archived key information and integrity checks of stored key information.

• d. offer encryption solutions at the data, application, and transaction layers, and support the CSC in implementing their own encryption solutions if required

SaaS Provider:

• a. define roles and responsibilities across the full stack, including who can set and change encryption configurations for the software or application

• b. implement robust encryption and key management practices for the CSC data at rest, in transit, and in use, providing it with transparency about these practices

• c. offer options for the CSC to manage its own encryption keys where possible (e.g., bring-your-own-key-scenarios, aka BYOK), and support the CSC in the secure implementation of these options

• d. establish the rules for the management of the storage and recovery of operational and backed-up key information.

Applicable to all service models:

• a. define and follow key lifecycle responsibilities, including key generation, distribution, cryptoperiod establishment, key revocation, storage and recovery, integrity checks, and destruction of keys when they are no longer required

• b. conduct regular audits and reviews to ensure compliance and check the effectiveness of segregation of duties, roles, and responsibilities

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.

Shared Implementation Guidelines

[All Actors] Applies to all Roles (Baseline) before application of role context.

1. Establish and document policies and procedures for Cryptography, Encryption, and Key Management.

2. Approve the policies and procedures through formal governance processes (e.g., security committee, CISO).

3. Communicate the policies and procedures to all relevant stakeholders.

4. Apply the approved policies and procedures to all systems, services, and processes under the role’s control.

5. Evaluate the effectiveness of policy and procedure implementation using internal audits, technical reviews, and encryption control validations.

6. Review and update the policies and procedures at least annually, or when significant system, model, or regulatory changes occur.

Implementation Guidelines for Cloud Service Providers (CSP)

Role Specific

1. Automate enforcement of encryption defaults across infrastructure services by implementing policy-as-code frameworks that prevent deployment of non-compliant configurations.

2. Maintain centralized visibility of cryptographic usage across regions and services, using telemetry and inventory tools to detect deviations from approved algorithm baselines.

3. Provide evidence of encryption control effectiveness through regular audit reports, customer-facing security documentation, and cryptographic compliance attestations for infrastructure services.

[All Actors] Applies to all Roles (Baseline) before application of role context.

1. Establish and document policies and procedures for Cryptography, Encryption, and Key Management.

2. Approve the policies and procedures through formal governance processes (e.g., security committee, CISO).

3. Communicate the policies and procedures to all relevant stakeholders.

4. Apply the approved policies and procedures to all systems, services, and processes under the role’s control.

5. Evaluate the effectiveness of policy and procedure implementation using internal audits, technical reviews, and encryption control validations.

6. Review and update the policies and procedures at least annually, or when significant system, model, or regulatory changes occur.

From CCM v4.1: Control Ownership Rationale. In the context of the service delivery models, IaaS, PaaS, and SaaS, the CSP has the primary responsibility of managing and providing cryptographic protection for data at rest and in transit, using certified cryptographic libraries, but the control’s implementation is also dependent on the CSC, making it a shared but dependent responsibility.

Implementation Guidelines. This measure enhances the security posture by safeguarding sensitive information from unauthorized access during storage and transmission. Using cryptographic libraries certified to approved standards adds an extra layer of assurance, meeting industry benchmarks for encryption, and instilling confidence in both the CSP and CSCs regarding the confidentiality and integrity of their data.

IaaS Provider:

• a. CSP should maintain a secure CKMS that meets or exceeds FIPS validation or approval by other relevant international standardization bodies

• b. offer mechanisms for full disk encryption options for at-rest databases and file servers and encryption for in-transit (network) data, providing the CSC the ability to implement as needed

• c. provide secure network communication protocols, such as TLS, to protect in-transit data between virtual machines, CSP services and users

• d. maintain security of the underlying infrastructure supporting these cryptographic services

• e. offer mechanisms for keeping data encryption keys in a protected environment, safe from exfiltration and tampering, including tampering by the CSP

• f. define, implement and evaluate mechanisms to protect data and systems’ integrity through cryptographic methods

PaaS Provider:

• a. In addition to the responsibilities listed for IaaS, the CSP should offer platform-level encryption options for at-rest, in use and in-transit data. This should include options to encrypt various data structures/types (e.g., files, records, or fields)

• b. offer the CSC the ability to manage its encryption settings, including the selection of encryption algorithms where appropriate

• c. define, implement and evaluate mechanisms to protect data and systems’ integrity through cryptographic methods

SaaS Provider:

• a. beyond the responsibilities listed for IaaS and PaaS, ensure that customer data is encrypted both at rest and in transit

• b. ensure that end user workstations and interfaces are secured using encryption for at-rest and in-transit data

• c. offer options for end-to-end encryption, where data remains encrypted from the point of origin to the point of use

• d. offer options for end-to-end encryption, like trusted execution environments, where the data remains encrypted while in-use

• e. manage encryption keys securely, ensuring they are regularly rotated and not exposed to unauthorized parties. Also, the CSP should provide secure methods for the CSC to manage encryption keys within the software service, including generation, rotation, and revocation of keys

• f. define, implement and evaluate mechanisms to protect data and systems’ integrity through cryptographic methods

CEK-04: Encryption Algorithm

Control Specification

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

Shared Implementation Guidelines

[All Actors] Applies to all Roles (Baseline) before application of role context

1. Establish and document policies and procedures for Cryptography, Encryption, and Key Management.

2. Approve the policies and procedures through formal governance processes (e.g., security committee, CISO).

3. Communicate the policies and procedures to all relevant stakeholders.

4. Apply the approved policies and procedures to all systems, services, and processes under the role’s control.

5. Evaluate the effectiveness of policy and procedure implementation using internal audits, technical reviews, and encryption control validations.

6. Review and update the policies and procedures at least annually, or when significant system, model, or regulatory changes occur.

Implementation Guidelines for Cloud Service Providers (CSP)

Role Specific

1. Integrate algorithm enforcement into infrastructure automation scripts and provisioning templates to ensure all deployed services use only approved encryption standards by default.

2. Continuously monitor cloud service configurations using policy-as-code and security scanning tools to detect and alert on use of deprecated or unauthorized cryptographic algorithms.

3. Generate periodic compliance reports for internal and external stakeholders that summarize encryption algorithm usage across services and validate conformance with approved standards and certifications.

[All Actors] Applies to all Roles (Baseline) before application of role context

1. Establish and document policies and procedures for Cryptography, Encryption, and Key Management.

2. Approve the policies and procedures through formal governance processes (e.g., security committee, CISO).

3. Communicate the policies and procedures to all relevant stakeholders.

4. Apply the approved policies and procedures to all systems, services, and processes under the role’s control.

5. Evaluate the effectiveness of policy and procedure implementation using internal audits, technical reviews, and encryption control validations.

6. Review and update the policies and procedures at least annually, or when significant system, model, or regulatory changes occur.

From CCM: Control Ownership Rationale. The control ownership for the encryption algorithm is “Shared (Independent”). The CSP is primarily responsible for determining and implementing the appropriate encryption algorithms in their infrastructure to ensure robust data protection. The CSP has the expertise and access to infrastructure to carry out this task, but it is the CSC’s responsibility to opt for the CSP’s encryption service and implement it as per business requirement, best practices and acceptable industry standard.

Implementation Guidelines. The CSP is responsible for implementing encryption algorithms that are most suitable for data protection, considering the data classification, associated risks, and usability of the encryption technology.

The CSP should:

• a. Offer encryption services that use algorithms appropriate for various types of data protection. These algorithms should be consistent with up-to-date industry best practices and standards

• b. Ensure that the cryptographic libraries it uses are certified to approved standards, such as FIPS 140-2

• c. Communicate clearly and transparently to CSCs about the encryption algorithms used, their strengths and weaknesses, and the types of data and risks they are suitable for

• d. Continually monitor developments in encryption technology and threats to encryption security. This includes upgrading encryption services in response to new vulnerabilities and adopting new, more secure algorithms as they become available

• e. Adopt a risk-based approach when deciding on the appropriate key size and algorithm types, considering factors such as the level of risk to data and cost-benefit analysis

• f. Offer the flexibility to developers to choose the encryption algorithm as per their application’s requirement while ensuring minimum security standards

• g. Ensure the CKMS security policies protect the confidentiality, integrity, availability, and source authentication of all keys, algorithms, and metadata.

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.

Shared Implementation Guidelines

[All Actors] Applies to all Roles (Baseline) before application of role context.

1. Establish and document policies and procedures for Cryptography, Encryption, and Key Management.

2. Approve the policies and procedures through formal governance processes (e.g., security committee, CISO).

3. Communicate the policies and procedures to all relevant stakeholders.

4. Apply the approved policies and procedures to all systems, services, and processes under the role’s control.

5. Evaluate the effectiveness of policy and procedure implementation using internal audits, technical reviews, and encryption control validations.

6. Review and update the policies and procedures at least annually, or when significant system, model, or regulatory changes occur.

Implementation Guidelines for Cloud Service Providers (CSP)

Role Specific

1. Integrate encryption change controls into infrastructure-as-code templates and service deployment automation to ensure approved cryptographic updates are consistently applied across environments.

2. Maintain an internal registry of cryptographic modules and versions deployed across cloud services, tracking changes and validating alignment with approved standards and compliance mandates.

3. Coordinate cross-functional encryption change reviews with infrastructure, compliance, and customer enablement teams to assess downstream impacts and ensure changes are transparently communicated to affected customers.

[All Actors] Applies to all Roles (Baseline) before application of role context.

1. Establish and document policies and procedures for Cryptography, Encryption, and Key Management.

2. Approve the policies and procedures through formal governance processes (e.g., security committee, CISO).

3. Communicate the policies and procedures to all relevant stakeholders.

4. Apply the approved policies and procedures to all systems, services, and processes under the role’s control.

5. Evaluate the effectiveness of policy and procedure implementation using internal audits, technical reviews, and encryption control validations.

6. Review and update the policies and procedures at least annually, or when significant system, model, or regulatory changes occur.

From CCM: Control Ownership Rationale. In an IaaS model, the CSP facilitates the platform for encryption and key management. The CSP oversees and independently manages changes to the cloud infrastructure, including the underlying hardware and network infrastructure. This independent handling of change management results in “Shared (Independent)” control ownership.

In the PaaS model, the CSP provides the platform where the cryptographic processes occur and where cryptographic material is exposed. While it handles changes related to the platform, the change management process involves an interaction with the CSC’s application layer, creating a level of dependency. As a result, the control ownership falls under the “Shared Dependent”) category.

In the SaaS model, the CSP takes on the most responsibility. It provides a full software solution, including encryption and key management. Hence, it is entirely responsible for managing changes to the software services, including the handling of cryptographic processes, making the control ownership ‘CSP-Owned.’

Implementation Guidelines. Applicable to all service models: Implementation guidelines should include (but not be limited to):

• a. establish a standard change management procedure for handling changes to cryptographic, encryption, and key management technologies. This includes changes resulting from internal reviews, as well as external factors such as changes to regulatory requirements or industry standards

• b. thoroughly review and approve changes before implementation, taking into account potential impact on security and compliance

• c. include provisions in change management procedures for documenting all changes, including the reasons for the changes and the expected benefits. This documentation should also include a rollback plan in case the changes need to be reversed if any risk or vulnerability is found in newly implemented changes in cryptography

• d. implement mechanisms to prevent unauthorized changes to software and systems, and to recover the system to a secure state in case unauthorized changes are detected

• e. conduct security audits to verify that the changes have been implemented correctly and have not introduced any new security risks

• f. report all audit results to the system authority, and promptly address any identified issues

• g. communicate with the CSC about any kind of change its their cryptography and key management lifecycle.

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.

Shared Implementation Guidelines

[All Actors] Applies to all Roles (Baseline) before application of role context.

1. Establish and document policies and procedures for Cryptography, Encryption, and Key Management.

2. Approve the policies and procedures through formal governance processes (e.g., security committee, CISO).

3. Communicate the policies and procedures to all relevant stakeholders.

4. Apply the approved policies and procedures to all systems, services, and processes under the role’s control.

5. Evaluate the effectiveness of policy and procedure implementation using internal audits, technical reviews, and encryption control validations.

6. Review and update the policies and procedures at least annually, or when significant system, model, or regulatory changes occur.

Implementation Guidelines for Cloud Service Providers (CSP)

Role Specific

1. Require all proposed encryption changes to include quantitative and qualitative cost-benefit assessments, including potential impact on tenant data isolation, service uptime, and compliance metrics.

2. Engage infrastructure, legal, and customer success teams during encryption change evaluations to assess operational feasibility and downstream customer implications.

3. Maintain a cryptographic change portfolio with documented rationales, benefit realization summaries, and risk outcomes to support governance transparency and regulatory inquiries.

[All Actors] Applies to all Roles (Baseline) before application of role context.

1. Establish and document policies and procedures for Cryptography, Encryption, and Key Management.

2. Approve the policies and procedures through formal governance processes (e.g., security committee, CISO).

3. Communicate the policies and procedures to all relevant stakeholders.

4. Apply the approved policies and procedures to all systems, services, and processes under the role’s control.

5. Evaluate the effectiveness of policy and procedure implementation using internal audits, technical reviews, and encryption control validations.

6. Review and update the policies and procedures at least annually, or when significant system, model, or regulatory changes occur.

From CCM: Control Ownership Rationale. Both the CSP and CSC have an independent shared responsibility for this control, because both are responsible for managing and adopting changes to cryptography and key management-related systems. The CSP owns this control for Platform Managed Keys.

Implementation Guidelines. Applicable to all service models: Control implementation is not service delivery model specific (IaaS, PaaS, SaaS) because the CSP should ensure that all changes to cryptography and key management-related systems be based on applicable security requirements.

Implementation guidelines should include (but not be limited to):

• a. key change management cost-benefit analysis/return on investment (ROI) should be calculated for all key management-related changes

• b. every analysis should fully account for downstream effects of proposed changes, including residual risks

• c. every analysis should be reviewed and approved

• d. periodically or after a change, compare the anticipated ROI to the actual ROI

• e. significant deviation from the planned ROI should be audited

• f. report all audit results to the system authority.

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.

Shared Implementation Guidelines

[All Actors] Applies to all Roles (Baseline) before application of role context

1. Establish and document policies and procedures for Cryptography, Encryption, and Key Management.

2. Approve the policies and procedures through formal governance processes (e.g., security committee, CISO).

3. Communicate the policies and procedures to all relevant stakeholders.

4. Apply the approved policies and procedures to all systems, services, and processes under the role’s control.

5. Evaluate the effectiveness of policy and procedure implementation using internal audits, technical reviews, and encryption control validations.

6. Review and update the policies and procedures at least annually, or when significant system, model, or regulatory changes occur.

Implementation Guidelines for Cloud Service Providers (CSP)

Role Specific

1. Develop and maintain a cloud encryption risk dashboard that aggregates risk metrics from storage, compute, and network layers to support near real-time visibility and decision-making.

2. Align encryption risk treatment plans with customer data protection expectations by integrating service-specific risks into shared responsibility models and support documentation.

3. Conduct scenario-based tabletop exercises simulating cryptographic failure or misconfiguration events to test CSP response readiness and validate existing treatment strategies.

[All Actors] Applies to all Roles (Baseline) before application of role context

1. Establish and document policies and procedures for Cryptography, Encryption, and Key Management.

2. Approve the policies and procedures through formal governance processes (e.g., security committee, CISO).

3. Communicate the policies and procedures to all relevant stakeholders.

4. Apply the approved policies and procedures to all systems, services, and processes under the role’s control.

5. Evaluate the effectiveness of policy and procedure implementation using internal audits, technical reviews, and encryption control validations.

6. Review and update the policies and procedures at least annually, or when significant system, model, or regulatory changes occur.

From CCM: Control Ownership Rationale. Both CSP and CSC have an independent shared responsibility for this control, in which the encryption and key management are maintained through the enterprise risk program. The CSP owns this control for Platform Managed Keys.

Implementation Guidelines. Applicable to all service models: Control implementation is not service delivery model specific (IaaS, PaaS, SaaS) because the CSP should ensure that encryption and key management are maintained through the enterprise risk program.

Key risk management is the process of managing the risks to key management governance, organization, infrastructure, and activities.

• a. assess the risks of unauthorized disclosure, modification, destruction, or information loss

• b. consider the risk and consequences of information exposure for the selections of cryptoperiod

• c. evaluate the tradeoffs of manual versus automated key distribution

• d. reduce compromised key risks by:

  • i. not using such keys for new encryption activities

  • ii. only using keys to decrypt material previously decrypted under this key

• e. adjust the audit scope and frequency to align with the risk assessment

• f. apply algorithm strength in proportion to the risk of information exposure

• g. assess risks to operational continuity versus the risks of key material data exposure when considering key recovery.

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.

Shared Implementation Guidelines

[All Actors] Applies to all Roles (Baseline) before application of role context.

1. Establish and document policies and procedures for Cryptography, Encryption, and Key Management.

2. Approve the policies and procedures through formal governance processes (e.g., security committee, CISO).

3. Communicate the policies and procedures to all relevant stakeholders.

4. Apply the approved policies and procedures to all systems, services, and processes under the role’s control.

5. Evaluate the effectiveness of policy and procedure implementation using internal audits, technical reviews, and encryption control validations.

6. Review and update the policies and procedures at least annually, or when significant system, model, or regulatory changes occur.

Implementation Guidelines for Cloud Service Providers (CSP)

Role Specific

1. Enable and document customer-managed key (CMK) functionality in CSP offerings by provisioning self-service interfaces for key creation, policy enforcement, and lifecycle automation.

2. Conduct periodic service validation to confirm that AIC key management features, such as bring-your-own-key (BYOK), key rotation scheduling, and access logging. Operate as intended across supported products.

3. Coordinate with compliance and customer experience teams to verify that AIC encryption key capabilities meet evolving regulatory and contractual expectations for data sovereignty and tenant isolation.

[All Actors] Applies to all Roles (Baseline) before application of role context.

1. Establish and document policies and procedures for Cryptography, Encryption, and Key Management.

2. Approve the policies and procedures through formal governance processes (e.g., security committee, CISO).

3. Communicate the policies and procedures to all relevant stakeholders.

4. Apply the approved policies and procedures to all systems, services, and processes under the role’s control.

5. Evaluate the effectiveness of policy and procedure implementation using internal audits, technical reviews, and encryption control validations.

6. Review and update the policies and procedures at least annually, or when significant system, model, or regulatory changes occur.

From CCM 4.1: Control Ownership Rationale. Both CSP and CSC have a dependent shared responsibility for this control, in which the CSP provides the capability for the CSC to manage their own data encryption keys.

Implementation Guidelines. Applicable to all service models: Control implementation is not service delivery model specific (IaaS, PaaS, SaaS) because the CSP provides the capability for the CSC to manage its own data encryption keys across the service delivery models.

Key management capability is the process in which the CSP provides the CSC the means to manage CSC-owned or -generated encryption keys.

• a. the CSC and CSP should agree on the definition and scope of CSC-managed keys and document it (shared responsibility) in the SLA, applicable contracts, policies, and procedures

• b. the CSP should allow the CSC’s to manage policies, procedures, and processes

• c. the CSP should provide means for the CSC to manage keys and data encryption keys

• d. the CSP should enable the CSC to manage key encryption keys or master keys used to encrypt data keys

• e. the CSP should allow the CSC to use the key management system (e.g., transactions, reporting)

• f. optionally, the CSC should provide a capability for CSC-generated master encryption keys using BYOK mechanisms

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

Shared Implementation Guidelines

[All Actors] Applies to all Roles (Baseline) before application of role context.

1. Establish and document policies and procedures for Cryptography, Encryption, and Key Management.

2. Approve the policies and procedures through formal governance processes (e.g., security committee, CISO).

3. Communicate the policies and procedures to all relevant stakeholders.

4. Apply the approved policies and procedures to all systems, services, and processes under the role’s control.

5. Evaluate the effectiveness of policy and procedure implementation using internal audits, technical reviews, and encryption control validations.

6. Review and update the policies and procedures at least annually, or when significant system, model, or regulatory changes occur.

Implementation Guidelines for Cloud Service Providers (CSP)

Role Specific

1. Integrate continuous audit logging into key management services to track customer key usage, administrative access, and cryptographic operations across multitenant environments.

2. Automate audit report generation for customer-managed key workflows, ensuring that logs and evidence align with compliance frameworks and SLA commitments.

3. Perform risk-aligned audits of key vault operations, focusing on key lifecycle coverage, access patterns, and enforcement of geographic or regulatory restrictions.

[All Actors] Applies to all Roles (Baseline) before application of role context.

1. Establish and document policies and procedures for Cryptography, Encryption, and Key Management.

2. Approve the policies and procedures through formal governance processes (e.g., security committee, CISO).

3. Communicate the policies and procedures to all relevant stakeholders.

4. Apply the approved policies and procedures to all systems, services, and processes under the role’s control.

5. Evaluate the effectiveness of policy and procedure implementation using internal audits, technical reviews, and encryption control validations.

6. Review and update the policies and procedures at least annually, or when significant system, model, or regulatory changes occur.

From CCM v4.1: Control Ownership Rationale. Both the CSP and CSC have an independent shared responsibility for this control, because CSP and CSC should ensure that they perform audits of encryption and key management systems, policies, and processes.

Implementation Guidelines. Applicable to all service models: Control implementation is not service delivery model specific (IaaS, PaaS, SaaS Provider) because the audit of encryption and key management systems, policies, and processes apply to all.

Key audit is the process of assessing the organization, governance, infrastructure, policies, procedures, and activities with regards to the use and protection of cryptographic keys.

• a. audits should be used to assess compliance with key management policies and procedures

• b. audits should be used to assess the design and effectiveness of key management controls and the control environment

• c. audits should be used to assess compliance with industry and regulatory standards (e.g., HIPAA, PCI)

• d. audits results should be reported to the key management system authority

• e. audits should be performed according to key management and risk management policies

• f. The CSP should request third-party audit/certification reports and review issues with third party vendors/CSPs.

• g. at a minimum, sensitive audit information and sensitive audit tools should be handled adhering to the same security requirements as the audited information

CEK-10: Key Generation

Control Specification

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

Shared Implementation Guidelines

[All Actors] Applies to all Roles (Baseline) before application of role context.

1. Establish and document policies and procedures for Cryptography, Encryption, and Key Management.

2. Approve the policies and procedures through formal governance processes (e.g., security committee, CISO).

3. Communicate the policies and procedures to all relevant stakeholders.

4. Apply the approved policies and procedures to all systems, services, and processes under the role’s control.

5. Evaluate the effectiveness of policy and procedure implementation using internal audits, technical reviews, and encryption control validations.

6. Review and update the policies and procedures at least annually, or when significant system, model, or regulatory changes occur.

Implementation Guidelines for Cloud Service Providers (CSP)

Role Specific

1. Embed certified key generation modules into CSP-managed services such as KMS and HSM, enforcing algorithm strength and secure RNG settings across all customer and internal keys.

2. Automate validation workflows that continuously verify entropy quality, algorithm compliance, and configuration consistency across distributed key generation services.

3. Maintain key generation audit logs and compliance documentation for all CSP cryptographic services, supporting customer assurance, internal oversight, and regulatory reviews.

[All Actors] Applies to all Roles (Baseline) before application of role context.

1. Establish and document policies and procedures for Cryptography, Encryption, and Key Management.

2. Approve the policies and procedures through formal governance processes (e.g., security committee, CISO).

3. Communicate the policies and procedures to all relevant stakeholders.

4. Apply the approved policies and procedures to all systems, services, and processes under the role’s control.

5. Evaluate the effectiveness of policy and procedure implementation using internal audits, technical reviews, and encryption control validations.

6. Review and update the policies and procedures at least annually, or when significant system, model, or regulatory changes occur.

From CCM v4.1: Control Ownership Rationale. Both the CSP and CSC have an independent shared responsibility for this control, because both the CSP and CSC should generate cryptographic keys using industry accepted cryptographic libraries.

Implementation Guidelines. Applicable to all service models: Control implementation is not service delivery model specific (IaaS, PaaS, SaaS) because both CSP and CSC should generate cryptographic keys using industry accepted cryptographic libraries.

The key generation process should be cryptographically secure.

• a. keys should be generated using secure random bit generators (RBGs) and possibly other parameters, or generated based on keys that are created in this fashion

• b. key management technology and processes should be IST FIPS validated

• c. all relevant transitions/activity should be recorded (logged) in the CKMS

CEK-11: Key Purpose

Control Specification

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

Shared Implementation Guidelines

[All Actors] Applies to all Roles (Baseline) before application of role context.

1. Establish and document policies and procedures for Cryptography, Encryption, and Key Management.

2. Approve the policies and procedures through formal governance processes (e.g., security committee, CISO).

3. Communicate the policies and procedures to all relevant stakeholders.

4. Apply the approved policies and procedures to all systems, services, and processes under the role’s control.

5. Evaluate the effectiveness of policy and procedure implementation using internal audits, technical reviews, and encryption control validations.

6. Review and update the policies and procedures at least annually, or when significant system, model, or regulatory changes occur.

Implementation Guidelines for Cloud Service Providers (CSP)

Role Specific

1. Configure CSP-managed services to enforce cryptographic key tagging and purpose-specific usage constraints at the infrastructure level, including in KMS, HSMs, and API-accessible key interfaces.

2. Implement automated policy enforcement mechanisms to prevent the assignment or reuse of keys across unrelated cryptographic operations such as encryption-at-rest, token signing, and key wrapping.

3. Review audit logs and telemetry from key management systems to detect violations of key purpose boundaries and initiate alerts or corrective actions as required.

[All Actors] Applies to all Roles (Baseline) before application of role context.

1. Establish and document policies and procedures for Cryptography, Encryption, and Key Management.

2. Approve the policies and procedures through formal governance processes (e.g., security committee, CISO).

3. Communicate the policies and procedures to all relevant stakeholders.

4. Apply the approved policies and procedures to all systems, services, and processes under the role’s control.

5. Evaluate the effectiveness of policy and procedure implementation using internal audits, technical reviews, and encryption control validations.

6. Review and update the policies and procedures at least annually, or when significant system, model, or regulatory changes occur.

From CCM v4.1: Control Ownership Rationale. Both CSP and CSC have an independent shared responsibility for this control, depending on the scope of the resource and key ownership model available or selected by the client. The CSP owns this control for Platform Managed Keys.

Implementation Guidelines. Applicable to all service models: Key distribution is the process of logically or physically transferring keys.

• a. asymmetric key pairs should be generated using a secure key generation process, ideally in a secure environment, such as an HSM

• b. the private key should be protected using strong encryption and access controls to ensure that only authorized users can access it

• c. the public key should be protected against tampering or substitution

• d. symmetric keys should also be generated using a secure key generation process and protected with strong encryption

• e. symmetric keys should be distributed using a secure channel, and access controls should be in place to restrict usage to authorized users

• f. symmetric keys should be changed regularly to minimize the risk of compromise

• g. keys should be protected at all stages of their lifecycle, including during storage, transit, and usage

• h. key distribution controls should ensure that keys are only distributed to authorized parties with a legitimate need to access the key

• i. key distribution controls should also protect against tampering, substitution, or interception during transit

• j. key distribution should also ensure that keys are available to authorized users whenever they are needed

• k. all key distribution activities should be logged and recorded in a CKMS or inventory management system

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.

Shared Implementation Guidelines

[All Actors] Applies to all Roles (Baseline) before application of role context.

1. Establish and document policies and procedures for Cryptography, Encryption, and Key Management.

2. Approve the policies and procedures through formal governance processes (e.g., security committee, CISO).

3. Communicate the policies and procedures to all relevant stakeholders.

4. Apply the approved policies and procedures to all systems, services, and processes under the role’s control.

5. Evaluate the effectiveness of policy and procedure implementation using internal audits, technical reviews, and encryption control validations.

6. Review and update the policies and procedures at least annually, or when significant system, model, or regulatory changes occur.

Implementation Guidelines for Cloud Service Providers (CSP)

Role Specific

1. Enforce cryptoperiod-based key rotation within KMS and HSM services, applying differentiated intervals for system, service, and tenant-facing keys based on usage class and exposure level.

2. Provide APIs and customer interfaces that support both automated and manual key rotation, along with documentation for aligning tenant rotation schedules with compliance needs.

3. Review key lifecycle telemetry and rotation logs across CSP services to confirm rotation accuracy, detect anomalies, and validate that expired keys are revoked or archived per policy.

[All Actors] Applies to all Roles (Baseline) before application of role context.

1. Establish and document policies and procedures for Cryptography, Encryption, and Key Management.

2. Approve the policies and procedures through formal governance processes (e.g., security committee, CISO).

3. Communicate the policies and procedures to all relevant stakeholders.

4. Apply the approved policies and procedures to all systems, services, and processes under the role’s control.

5. Evaluate the effectiveness of policy and procedure implementation using internal audits, technical reviews, and encryption control validations.

6. Review and update the policies and procedures at least annually, or when significant system, model, or regulatory changes occur.

From CCM: Control Ownership Rationale. Both CSP and CSC have an independent shared responsibility for this control, depending on the scope of the resource and key ownership model available or selected by the client. The CSP owns this control for Platform Managed Keys.

Implementation Guidelines. Applicable to all service models: Before rotating a key, ensure that all data previously encrypted with the old key version can be decrypted. Depending on organizational policies and the technology capacity of the system, old data may be automatically or manually re-encrypted with the new key version after key rotation. When rotating keys, consider the following principles:

• a. Data Decryption: Non-primary (old) keys should be used to decrypt data previously encrypted before re-encrypting the data with new keys

• b. Data Re-encryption: Old data may be re-encrypted using new keys based on organizational policy and technology capacity

• c. Algorithm Strength: This includes the strength of the encryption algorithm, the length of the key, and the mode of operation used

• d. Transactions Volume: the volume of information flow or the number of transactions that may impact the processing time required for key rotation and how frequently key rotation is necessary

• e. Data Sensitivity and Lifetime Protection: This includes how long the data needs to be protected, the sensitivity of the data, and the potential risks associated with data compromise

• f. Crypto-Security Functions: Functions such as data encryption, digital signature, and key protection may be impacted by key rotation and should be considered

• g. Key Copies Number: the number of key copies and the distribution of those copies and ensuring that all relevant key copies are updated during the rotation process

• h. Keys Rotation Logging: All key rotation activities should be logged and recorded in the CKMS or inventory management system.

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.

Shared Implementation Guidelines

[All Actors] Applies to all Roles (Baseline) before application of role context.

1. Establish and document policies and procedures for Cryptography, Encryption, and Key Management.

2. Approve the policies and procedures through formal governance processes (e.g., security committee, CISO).

3. Communicate the policies and procedures to all relevant stakeholders.

4. Apply the approved policies and procedures to all systems, services, and processes under the role’s control.

5. Evaluate the effectiveness of policy and procedure implementation using internal audits, technical reviews, and encryption control validations.

6. Review and update the policies and procedures at least annually, or when significant system, model, or regulatory changes occur.

Implementation Guidelines for Cloud Service Providers (CSP)

Role Specific

1. Configure revocation APIs and admin interfaces to support immediate invalidation of CSP-managed and customer-managed keys across all supported regions and services.

2. Integrate key revocation status into KMS and HSM telemetry to trigger dependent service alerts and enforce system-wide propagation of key invalidation events.

3. Perform regular tests of key revocation procedures using simulated compromise and offboarding scenarios to validate effectiveness, completeness, and compliance with jurisdictional mandates.

[All Actors] Applies to all Roles (Baseline) before application of role context.

1. Establish and document policies and procedures for Cryptography, Encryption, and Key Management.

2. Approve the policies and procedures through formal governance processes (e.g., security committee, CISO).

3. Communicate the policies and procedures to all relevant stakeholders.

4. Apply the approved policies and procedures to all systems, services, and processes under the role’s control.

5. Evaluate the effectiveness of policy and procedure implementation using internal audits, technical reviews, and encryption control validations.

6. Review and update the policies and procedures at least annually, or when significant system, model, or regulatory changes occur.

From CCM: Control Ownership Rationale. Both CSP and CSC have an independent shared responsibility for this control, depending on the scope of the resource and key ownership model available or selected by the client. The CSP owns this control for Platform Managed Keys.

Implementation Guidelines. Applicable to all service models: Key revocation removes keys from operational use before their expiration dates.

• a. key revocation of a symmetric key restricts the use of the key material

• b. key revocation of an asymmetric key specifically refers to the private key

• c. emergency revocation refers to when keys are lost or compromised

• d. revocation statuses should be available to all who have relied on the key

• e. Digital certificate revocation lists (CRLs) or other relevant mechanisms should be used to inform stakeholders

• f. ROI: The cost to decrypt then re-encrypt large distributed databases with a significant number of key holders. Where applicable, a two-key system should be used, one to encrypt data and another to encrypt the key that encrypts the data, in order to significantly minimize the impact of revoking keys

• g. ROI: Risk of long-term cryptoperiods versus short, and the amount of data encrypted with one key

• h. all relevant transitions/activity should be recorded (logged) in the CMKS or inventory management system.

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.

Shared Implementation Guidelines

[All Actors] Applies to all Roles (Baseline) before application of role context.

1. Establish and document policies and procedures for Cryptography, Encryption, and Key Management.

2. Approve the policies and procedures through formal governance processes (e.g., security committee, CISO).

3. Communicate the policies and procedures to all relevant stakeholders.

4. Apply the approved policies and procedures to all systems, services, and processes under the role’s control.

5. Evaluate the effectiveness of policy and procedure implementation using internal audits, technical reviews, and encryption control validations.

6. Review and update the policies and procedures at least annually, or when significant system, model, or regulatory changes occur.

Implementation Guidelines for Cloud Service Providers (CSP)

Role Specific

1. Implement automated key destruction workflows across file-based stores, internal key management services, and multitenant platforms, ensuring keys are securely erased and unrecoverable.

2. Configure HSM revocation mechanisms to support tenant-initiated and CSP-triggered key invalidation, with visibility into lifecycle completion and audit trail generation.

3. Conduct periodic validation exercises simulating key destruction and revocation events, confirming compliance with regulatory destruction timelines, logging completeness, and zero key residue across services.

[All Actors] Applies to all Roles (Baseline) before application of role context.

1. Establish and document policies and procedures for Cryptography, Encryption, and Key Management.

2. Approve the policies and procedures through formal governance processes (e.g., security committee, CISO).

3. Communicate the policies and procedures to all relevant stakeholders.

4. Apply the approved policies and procedures to all systems, services, and processes under the role’s control.

5. Evaluate the effectiveness of policy and procedure implementation using internal audits, technical reviews, and encryption control validations.

6. Review and update the policies and procedures at least annually, or when significant system, model, or regulatory changes occur.

From CCM:

Control Ownership Rationale. Both the CSP and CSC have an independent shared responsibility for this control, depending on the scope of the resource and key ownership model available or selected by the client. The CSP owns this control for Platform Managed Keys.

Implementation Guidelines. Applicable to all service models: Key destruction removes all traces to prevent recovery by physical or electronic means.

• a. when a key is to be destroyed, all key copies should be destroyed

• b. keys should be destroyed when they are not needed to minimize risk of compromise

• c. secret and private keys should be destroyed so they cannot be recovered by any means

• d. public keys may be kept or destroyed

• e. notify stakeholders in advance of key destruction

• f. consider laws, regulations, and their retention requirements for keys and/or metadata

• g. key recovery information (KRI) should be protected against unauthorized disclosure or destruction

• h. all relevant transitions/activity should be recorded (logged) in the CMKS or inventory management system.

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.

Shared Implementation Guidelines

[All Actors] Applies to all Roles (Baseline) before application of role context.

1. Establish and document policies and procedures for Cryptography, Encryption, and Key Management.

2. Approve the policies and procedures through formal governance processes (e.g., security committee, CISO).

3. Communicate the policies and procedures to all relevant stakeholders.

4. Apply the approved policies and procedures to all systems, services, and processes under the role’s control.

5. Evaluate the effectiveness of policy and procedure implementation using internal audits, technical reviews, and encryption control validations.

6. Review and update the policies and procedures at least annually, or when significant system, model, or regulatory changes occur.

Implementation Guidelines for Cloud Service Providers (CSP)

Role Specific

1. Configure all CSP-managed key generation services (e.g., KMS, HSMs) to default new keys to a pre-activated state, ensuring no cryptographic function is permitted prior to formal activation.

2. Require and enforce approval workflows for key activation that include compliance validation, separation-of-duties verification, and tenant acknowledgment (where applicable).

3. Audit all activation events to verify no pre-activated key has been exposed prematurely, and that CSP systems maintain strict enforcement of key lifecycle transition states.

[All Actors] Applies to all Roles (Baseline) before application of role context.

1. Establish and document policies and procedures for Cryptography, Encryption, and Key Management.

2. Approve the policies and procedures through formal governance processes (e.g., security committee, CISO).

3. Communicate the policies and procedures to all relevant stakeholders.

4. Apply the approved policies and procedures to all systems, services, and processes under the role’s control.

5. Evaluate the effectiveness of policy and procedure implementation using internal audits, technical reviews, and encryption control validations.

6. Review and update the policies and procedures at least annually, or when significant system, model, or regulatory changes occur.

From CCM:

Control Ownership Rationale. Both CSP and CSC have an independent shared responsibility for this control, depending on the scope of the resource and key ownership model available or selected by the client. The CSP owns this control for Platform Managed Keys.

Implementation Guidelines. Applicable to all service models: Activated keys are used to protect information cryptographically.

• a. pre-activated keys are activated by entering the start date of the validity/cryptoperiod

• b. keys which are not activated for use are not ready to encrypt data

• c. non-activated keys should only be used to perform proof-of-possession or key confirmation

• d. if pre-activated keys are no longer needed, they should be destroyed

• e. if there are suspicions about the integrity of a given key, it should be moved to the compromised state

• f. all relevant transitions/activity should be recorded (logged) in the CKMS or inventory management system.

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.

Shared Implementation Guidelines

[All Actors] Applies to all Roles (Baseline) before application of role context.

1. Establish and document policies and procedures for Cryptography, Encryption, and Key Management.

2. Approve the policies and procedures through formal governance processes (e.g., security committee, CISO).

3. Communicate the policies and procedures to all relevant stakeholders.

4. Apply the approved policies and procedures to all systems, services, and processes under the role’s control.

5. Evaluate the effectiveness of policy and procedure implementation using internal audits, technical reviews, and encryption control validations.

6. Review and update the policies and procedures at least annually, or when significant system, model, or regulatory changes occur.

Implementation Guidelines for Cloud Service Providers (CSP)

Role Specific

1. Configure key management platforms to automatically enforce suspension protocols for CSP-managed and customer-accessible keys upon detection of policy violations or unauthorized access.

2. Enable audit trails for all key suspension and reactivation events, ensuring visibility into the decision-making process, including the roles responsible for approval and validation.

3. Integrate reactivation workflows into CSP services with strict compliance checks, ensuring suspended keys are not reinstated until proper security reviews and risk assessments are completed.

[All Actors] Applies to all Roles (Baseline) before application of role context.

1. Establish and document policies and procedures for Cryptography, Encryption, and Key Management.

2. Approve the policies and procedures through formal governance processes (e.g., security committee, CISO).

3. Communicate the policies and procedures to all relevant stakeholders.

4. Apply the approved policies and procedures to all systems, services, and processes under the role’s control.

5. Evaluate the effectiveness of policy and procedure implementation using internal audits, technical reviews, and encryption control validations.

6. Review and update the policies and procedures at least annually, or when significant system, model, or regulatory changes occur.

From CCM:

Control Ownership Rationale. Both CSP and CSC have an independent shared responsibility for this control, depending on the scope of the resource and key ownership model available or selected by the client. The CSP owns this control for Platform Managed Keys.

Implementation Guidelines. Applicable to all service models: Suspended keys are not used for a period.

• a. keys may be suspended for leaves of absence or suspicion of compromise

• b. suspensions should be investigated before transitioning to activation, revocation, or replacement

• c. suspended keys should not be used to encrypt data, but they can decrypt data

• d. do not process encryption applied after the beginning of a suspension period

• e. all relevant transitions/activity should be recorded (logged) in the inventory management system (CKMS).

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.

Shared Implementation Guidelines

[All Actors] Applies to all Roles (Baseline) before application of role context.

1. Establish and document policies and procedures for Cryptography, Encryption, and Key Management.

2. Approve the policies and procedures through formal governance processes (e.g., security committee, CISO).

3. Communicate the policies and procedures to all relevant stakeholders.

4. Apply the approved policies and procedures to all systems, services, and processes under the role’s control.

5. Evaluate the effectiveness of policy and procedure implementation using internal audits, technical reviews, and encryption control validations.

6. Review and update the policies and procedures at least annually, or when significant system, model, or regulatory changes occur.

Implementation Guidelines for Cloud Service Providers (CSP)

Role Specific

1. Configure key management systems (e.g., KMS, HSM) to enforce automatic deactivation of CSP-managed and customer-provisioned keys upon expiration, ensuring they are removed from all active encryption workflows.

2. Validate expiration-based deactivation through automated policy checks, ensuring that expired keys cannot be used for encryption, decryption, or key wrapping operations in multi-tenant environments.

3. Maintain detailed logs of key deactivation events, capturing the key identifier, expiration timestamp, deactivation action, and any affected customer services, for audit and compliance reporting.

[All Actors] Applies to all Roles (Baseline) before application of role context.

1. Establish and document policies and procedures for Cryptography, Encryption, and Key Management.

2. Approve the policies and procedures through formal governance processes (e.g., security committee, CISO).

3. Communicate the policies and procedures to all relevant stakeholders.

4. Apply the approved policies and procedures to all systems, services, and processes under the role’s control.

5. Evaluate the effectiveness of policy and procedure implementation using internal audits, technical reviews, and encryption control validations.

6. Review and update the policies and procedures at least annually, or when significant system, model, or regulatory changes occur.

From CCM: Control Ownership Rationale. Both CSP and CSC have an independent shared responsibility for this control, depending on the scope of the resource and key ownership model available or selected by the client. The CSP owns this control for Platform Managed Keys.

Implementation Guidelines. Applicable to all service models: Deactivated keys should not be used to encrypt but can be used to decrypt.

• a. upon the expiration date, keys should not be able to encrypt data

• b. the deactivated state should transition to the destroyed state when keys are no longer needed

• c. metadata should be retained for audit purposes

• d. all relevant transitions/activity should be recorded (logged) in the CKMS or inventory management system.

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.

Shared Implementation Guidelines

[All Actors] Applies to all Roles (Baseline) before application of role context

1. Establish and document policies and procedures for Cryptography, Encryption, and Key Management.

2. Approve the policies and procedures through formal governance processes (e.g., security committee, CISO).

3. Communicate the policies and procedures to all relevant stakeholders.

4. Apply the approved policies and procedures to all systems, services, and processes under the role’s control.

5. Evaluate the effectiveness of policy and procedure implementation using internal audits, technical reviews, and encryption control validations.

6. Review and update the policies and procedures at least annually, or when significant system, model, or regulatory changes occur.

Implementation Guidelines for Cloud Service Providers (CSP)

Role Specific

1. Maintain separate archival zones for CSP-managed encryption keys and customer-delegated keys, applying tamper-evident storage and encryption-at-rest controls aligned with regional compliance standards and customer SLAs.

2. Enforce role-based access to archived keys using federated identity systems, ensuring only authorized cryptographic custodians and compliance reviewers can access key artifacts, with all actions logged in immutable audit trails.

3. Perform quarterly reviews of archived key access logs, verifying that access attempts are justified, traceable, and compliant with customer-specific archival duration and legal hold requirements.

[All Actors] Applies to all Roles (Baseline) before application of role context

1. Establish and document policies and procedures for Cryptography, Encryption, and Key Management.

2. Approve the policies and procedures through formal governance processes (e.g., security committee, CISO).

3. Communicate the policies and procedures to all relevant stakeholders.

4. Apply the approved policies and procedures to all systems, services, and processes under the role’s control.

5. Evaluate the effectiveness of policy and procedure implementation using internal audits, technical reviews, and encryption control validations.

6. Review and update the policies and procedures at least annually, or when significant system, model, or regulatory changes occur.

From CCM: Control Ownership Rationale. Both CSP and CSC have an independent shared responsibility for this control, depending on the scope of the resource and key ownership model available or selected by the client. The CSP owns this control for Platform Managed Keys.

Implementation Guidelines. Applicable to all service models: Key archiving places keys in long-term storage.

• a. archived key material can support the later recovery of information

• b. while archived key material may be needed in the future, the key material should be destroyed when no longer required

• c. the key recovery process should include the generation, storage, and access of the long-term storage keys used to protect backed-up and archived key information

• d. archives should be used for long-term key access

• e. the inventory system should record the storage and recovery of archived key information

• f. all relevant transitions/activity should be recorded (logged) in the CKMS or inventory management system

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.

Shared Implementation Guidelines

[All Actors] Applies to all Roles (Baseline) before application of role context

1. Establish and document policies and procedures for Cryptography, Encryption, and Key Management.

2. Approve the policies and procedures through formal governance processes (e.g., security committee, CISO).

3. Communicate the policies and procedures to all relevant stakeholders.

4. Apply the approved policies and procedures to all systems, services, and processes under the role’s control.

5. Evaluate the effectiveness of policy and procedure implementation using internal audits, technical reviews, and encryption control validations.

6. Review and update the policies and procedures at least annually, or when significant system, model, or regulatory changes occur.

Implementation Guidelines for Cloud Service Providers (CSP)

Role Specific

1. Control compromised key usage by limiting its use exclusively to decryption of previously encrypted data, ensuring it is not reused for any encryption activities. Ensure that this decryption-only policy is enforced under strict regulatory compliance and legal guidelines.

2. Ensure approval and documentation of any decryption activities with compromised keys, requiring formal approval before use, detailed documentation, and adherence to regulatory reporting obligations and tenant isolation requirements.

3. Educate and communicate key compromise handling procedures to all relevant stakeholders, including security teams and tenant support personnel, ensuring they understand the constraints around the use of compromised keys and the prohibition of their reuse for encryption purposes.

[All Actors] Applies to all Roles (Baseline) before application of role context

1. Establish and document policies and procedures for Cryptography, Encryption, and Key Management.

2. Approve the policies and procedures through formal governance processes (e.g., security committee, CISO).

3. Communicate the policies and procedures to all relevant stakeholders.

4. Apply the approved policies and procedures to all systems, services, and processes under the role’s control.

5. Evaluate the effectiveness of policy and procedure implementation using internal audits, technical reviews, and encryption control validations.

6. Review and update the policies and procedures at least annually, or when significant system, model, or regulatory changes occur.

From CCM: Control Ownership Rationale. This is a shared responsibility between the CSP and the CSC. This control falls under the “Dependent” category as the execution by both parties is essential for effective security. The CSP offers encryption and key management services, and is responsible for the infrastructure that supports these services. The CSC, on the other hand, is responsible for correctly using these services to secure their data, for instance, choosing when and what data to encrypt, and managing access to encryption keys.

Implementation Guidelines. When appropriate, the CSP should notify the CSC that keys previously used to encrypt its data have been compromised and that those keys are no longer used for encryption. IaaS Provider: The IaaS provider should offer mechanisms for encryption both in transit and at rest for all data, along with a key management service. The CSP should ensure that these services comply with the latest security standards and best practices. The CSP should provide tools and resources for secure key management and encryption, following best practices. PaaS Provider: The PaaS provider should offer platform-level encryption for data at rest and in transit, including a secure key management system. The PaaS provider should also provide the option for application-level encryption managed by the CSC. The CSP should adhere to security best practices and standards. The CSP should offer the CSC the ability to manage its own keys where feasible SaaS Provider: The SaaS provider should handle encryption at the application level, including key management. The provider should ensure all data at rest and in transit is encrypted. The CSP should offer CSCs the ability to manage their own keys where feasible. Applicable to all service models: The CSP’s policies, procedures, and processes should ensure that compromised keys await an investigation to determine disposition.

• a. perform emergency revocation when keys are lost or compromised

• b. a compromised status should be available to all who have relied on the key

• c. use Compromised Key Lists (CKL) to inform stakeholders

• d. also reflect compromised status is in the inventory management system

• e. use audits to uncover undetected compromised keys

• f. analyze events to support recovery from compromises

• g. detail the method for revoking and re-keying compromised keys

• h. use cryptoperiods to limit compromised key damage

• i. a compromised key should only be used to process data it has protected for the sole purpose of decrypting the data

• j. all transitions/activity should be recorded (logged) and the key state updated in the CKMS or inventory management system.

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.

Shared Implementation Guidelines

[All Actors] Applies to all Roles (Baseline) before application of role context

1. Establish and document policies and procedures for Cryptography, Encryption, and Key Management.

2. Approve the policies and procedures through formal governance processes (e.g., security committee, CISO).

3. Communicate the policies and procedures to all relevant stakeholders.

4. Apply the approved policies and procedures to all systems, services, and processes under the role’s control.

5. Evaluate the effectiveness of policy and procedure implementation using internal audits, technical reviews, and encryption control validations.

6. Review and update the policies and procedures at least annually, or when significant system, model, or regulatory changes occur.

Implementation Guidelines for Cloud Service Providers (CSP)

Role Specific

1. Assess recovery impact by evaluating the trade-off between service continuity and the risk of exposing tenant or infrastructure keying material, ensuring recovery actions adhere to regulatory and contractual requirements.

2. Approve recovery processes through formal governance, ensuring recovery scenarios like key vault restoration or hardware reactivation are justified and authorized based on risk frameworks and compliance needs.

3. Implement recovery procedures by securing recovery processes across cloud systems, ensuring they are auditable, access-controlled, and compliant with customer and regulatory expectations, including the use of KMS platforms, HSMs, and tenant key interfaces.

[All Actors] Applies to all Roles (Baseline) before application of role context

1. Establish and document policies and procedures for Cryptography, Encryption, and Key Management.

2. Approve the policies and procedures through formal governance processes (e.g., security committee, CISO).

3. Communicate the policies and procedures to all relevant stakeholders.

4. Apply the approved policies and procedures to all systems, services, and processes under the role’s control.

5. Evaluate the effectiveness of policy and procedure implementation using internal audits, technical reviews, and encryption control validations.

6. Review and update the policies and procedures at least annually, or when significant system, model, or regulatory changes occur.

From CCM: Control Ownership Rationale. This is a shared responsibility between the CSP and the CSC. This control falls under the “Dependent” category as the execution by both parties is essential for effective security. The CSP offers encryption and key management services, and is responsible for the infrastructure that supports these services. The CSC, on the other hand, is responsible for correctly using these services to secure their data, for instance, choosing when and what data to encrypt, and for managing access to encryption keys.

Implementation Guidelines. IaaS Provider: The IaaS Provider should offer mechanisms for encryption both in transit and at rest for all data, along with a key management service. The CSP should ensure that these services comply with the latest security standards and best practices. The CSP should provide tools and resources for secure key management and encryption, following best practices. PaaS Provider: The PaaS provider should offer platform-level encryption for data at rest and in transit, including a secure key management system. The PaaS provider should also provide the option for application-level encryption managed by the CSC. The CSP should adhere to security best practices and standards. SaaS Provider: The SaaS provider should handle encryption at the application level, including key management. The provider should ensure all data at rest and in transit is encrypted. The CSP should offer the CSC the ability to manage its own keys where feasible. Applicable to all service models: Key recovery retrieves or reconstructs keys from backups or archives. The CSP’s policies, procedures, and processes should ensure:

• a. the type of key (e.g., private signature keys or symmetric data encryption keys)

• b. the application in which the key will be used (e.g., interactive communication or file storage)

• c. whether the key is owned by the local entity, another entity, or is shared

• d. the role of the entity in communication (i.e., sender or receiver)

• e. the algorithm or computation in which the key will be used

• f. all relevant transitions/activity should be recorded (logged) in the CKMS or inventory management system

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.

Shared Implementation Guidelines

[All Actors] Applies to all Roles (Baseline) before application of role context

1. Establish and document policies and procedures for Cryptography, Encryption, and Key Management.

2. Approve the policies and procedures through formal governance processes (e.g., security committee, CISO).

3. Communicate the policies and procedures to all relevant stakeholders.

4. Apply the approved policies and procedures to all systems, services, and processes under the role’s control.

5. Evaluate the effectiveness of policy and procedure implementation using internal audits, technical reviews, and encryption control validations.

6. Review and update the policies and procedures at least annually, or when significant system, model, or regulatory changes occur.

Implementation Guidelines for Cloud Service Providers (CSP)

Role specific

1. Implement key inventory tracking across all cryptographic materials, ensuring that all states of key lifecycle events such as creation, activation, suspension, revocation, and destruction are logged and tracked according to service-level agreements and compliance requirements.

2. Establish key inventory synchronization systems to ensure that all cryptographic key transitions, including rotations and access changes, are recorded and available for audit purposes, meeting regulatory and customer compliance needs.

3. Monitor and audit key inventory accuracy through internal audits, technical reviews, and encryption control validations, ensuring that inventory records are up-to-date and discrepancies are resolved in a timely and transparent manner.

[All Actors] Applies to all Roles (Baseline) before application of role context

1. Establish and document policies and procedures for Cryptography, Encryption, and Key Management.

2. Approve the policies and procedures through formal governance processes (e.g., security committee, CISO).

3. Communicate the policies and procedures to all relevant stakeholders.

4. Apply the approved policies and procedures to all systems, services, and processes under the role’s control.

5. Evaluate the effectiveness of policy and procedure implementation using internal audits, technical reviews, and encryption control validations.

6. Review and update the policies and procedures at least annually, or when significant system, model, or regulatory changes occur.

From CCM: Control Ownership Rationale. This is a shared responsibility between the CSP and the CSC. This control falls under the “Dependent” category as the execution by both parties is essential for effective security. The CSP offers encryption and key management services, and is responsible for the infrastructure that supports these services. The CSC, on the other hand, is responsible for correctly using these services to secure their data, for instance, choosing when and what data to encrypt, and managing access to encryption keys.

Implementation Guidelines. IaaS Provider: The IaaS Provider should offer mechanisms for encryption both in transit and at rest for all data, along with a key management service. The CSP should ensure that these services comply with the latest security standards and best practices. The CSP should provide tools and resources for secure key management and encryption that follow best practices.

PaaS Provider: The PaaS provider should offer platform-level encryption for data at rest and in transit, including a secure key management system. The PaaS provider should also provide the option for application-level encryption managed by the CSC. The CSP should adhere to security best practices and standards.

SaaS Provider: The SaaS provider should handle encryption at the application level, including key management. It should ensure all data at rest and in transit is encrypted. The CSP should offer the CSC the ability to manage its own keys where feasible.

Applicable to all service models: The CKMS, whether manual or automated, exists to process, control, store and report key management activity. The CSP’s policies, procedures, and processes should ensure that the CKMS:

• a. captures, tracks and labels all changes in status

• b. continuously monitors for unknown cryptographic assets.

• c. generates and distributes key information

• d. acquires or generates public-key certificates

• e. backups archives and inventory key information

• f. maintains a database that maps entities to the CSP’s digital certificate or key structure

• g. provides maintenance and distribution of revoked key or digital certificate reports

• h. generates audit requests and processes audit responses

• i. crypto materials include keys, digital certificates, and HSMs

• j. verifies that key management technology and processes are FIPS validated

• k. protects the confidentiality, integrity, availability, and source authentication of all keys, digital certificates, algorithms, and metadata

• l. records (logs) all relevant transitions/activity in the inventory CKMS.

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.

Shared Implementation Guidelines

[All Actors, except AIC]

1. Organizations should establish, document, approve, communicate, apply, evaluate, and maintain physical and environmental security policies and procedures applicable to facilities and environments supporting AI systems.

2. Policies should define responsibilities, access control requirements, environmental protections, monitoring expectations, and incident response integration.

3. Policies and procedures must be reviewed at least annually and updated following significant organizational, infrastructure, or threat changes.

Implementation Guidelines for Cloud Service Providers (CSP)

1. Cloud Service Providers should maintain comprehensive physical and environmental security programs for all facilities supporting AI workloads, including data centers, hardware lifecycle operations, and network infrastructure.

2. Policies should cover physical access controls, surveillance, environmental monitoring, redundancy, and incident response coordination.

3. CSPs should provide transparency into physical security practices through independent third-party audits and customer assurance documentation.

From CCM v4.1: Control Ownership Rationale. The CSP is typically responsible for the implementation of this control. Policies and procedures related to the physical and environmental security fall under the responsibility of the CSP since they own and operate the datacenter and supporting infrastructure. These policies ensure secure handling, relocation, and decommissioning of IT assets to support operational resilience including disaster recovery, business continuity, and scalability. With direct oversight of these components, the CSP is best positioned to define, implement, and enforce effective security measures.

Implementation Guidelines. Applicable to all service models: The CSP should establish and document a comprehensive framework within its policies and procedures to ensure the physical protection of all organizational assets throughout their lifecycle. This includes not only information assets such as servers, storage devices, networking equipment, backup media, and printed documents, but also physical infrastructure like buildings, data centers, and office spaces, as well as personnel who access or manage these environments. The framework should define clear requirements to prevent tampering, damage, theft, or unauthorized physical access to these assets. It should also include specific provisions for securing data centers and other critical facilities managed by the CSP. The policy should emphasize compliance with applicable regulations, regular physical security audits, and continuous monitoring to ensure the safety and integrity of all physical and human assets.

Policies should include (but not limited to) provisions on the following: The objective of this policy is to establish a structured and consistent approach to ensure the confidentiality, integrity, and availability of information systems, physical infrastructure, and personnel who manage these environments by implementing robust physical security and environmental controls, complying with relevant legal and regulatory requirements, and maintaining a secure environment for personnel and infrastructure.

• a. Risk-Based Approach: Physical and environmental security controls should be designed and implemented based on a thorough assessment of risks to personnel, infrastructure, and information assets. Based on this assessment, a specific, measurable, achievable, relevant, and time-bound (SMART) policies and procedures should be defined.

• b. Defense in Depth: A multi-layered security strategy should be established and implemented, combining physical barriers, access controls, surveillance, and monitoring to deter, detect, and respond to threats.

  • Access Control measures, such as keycards or smart badges, biometric scanners and authentications, security personnel at entry points, anti-tailgating and anti-pass-back systems, and role-based access levels and audit trails to restrict entry to authorized personnel and areas.

  • Perimeter Security measures, such as high-security fencing, reinforced gates, vehicle barriers, controlled entry points with access controls, 24/7 surveillance cameras, motion-activated lighting, intrusion detection sensors, clear warning signage, security patrols and perimeter inspections.

  • Surveillance & Monitoring measures, such as alarm systems, high-resolution, night-vision security cameras, motion detectors, intrusion alarms, and centralized monitoring dashboards—to ensure continuous, real-time visibility and rapid response to physical security threats.

  • Visitor Management measures, such as system for tracking and managing visitors, verifying identification and purpose of visit, escort visitors in sensitive areas, and maintain logs for auditing and review.

  • Facility Design and Location avoiding proximity to high-risk areas.

  • Secure shipping and receiving areas measures, such as controlled access, surveillance, and physical barriers, verify and log all deliveries, inspect packages, and escort unauthorized personnel. Ensure proper lighting, alarm systems, and staff training to detect and respond to threats.

• c. Least Privilege Access: Physical access to facilities and equipment should be granted only to authorized individuals based on job responsibilities and business needs.

• d. Environmental Resilience and Sustainability

  • i. Environmental Resilience: Facilities should be designed, operated, and maintained to withstand environmental threats such as fire, flooding, extreme temperatures, seismic activity, and power outages. Comprehensive response plans should be in place to address these risks, incorporating:

    • Evacuation procedures

    • Emergency communication protocols

    • Backup power systems

    • Fire suppression readiness

    • Staff training

    • Coordination with local emergency services

  • ii. Sustainability and Environmental Responsibility: Develop and implement environmental policies that prioritize sustainability. These policies should focus on:

    • Reducing waste

    • Conserving natural resources

    • Minimizing emissions

  • iii. Environmental controls should be energy-efficient and aligned with sustainability goals to reduce environmental impact while maintaining operational security. Continuous monitoring and management of environmental factors are essential. Key parameters include:

    • Temperature

    • Water presence

    • Power continuity

    • Humidity

    • Cleanliness

  • iv. Implement appropriate systems such as:

    • Heating, ventilation, and air conditioning (HVAC)

    • Drainage systems

    • Fire suppression systems

    • Emergency lighting

    • Uninterruptible power supplies (UPS)

    • Humidity regulation

• e. Redundancy and Failover: Critical environmental systems-such as power, cooling, and fire suppression - should include redundant components and failover mechanisms to ensure uninterrupted operations during systems failures or emergencies.

• f. Regular Maintenance : Implement a schedule for the routine maintenance and testing of physical security systems and equipment.

• g. Regulatory Compliance: All physical and environmental security practices should comply with applicable laws, regulations, industry standards (e.g., ISO/IEC 27001, NIST, ISO 14000, ISO 22301), and contractual obligations.

  • i. Device Inspections: Require regular inspection and verification of physical devices (e.g., servers, storage, networking equipment, Hardware Security Modules) to detect signs of tampering, unauthorized modifications, or physical compromise, ensuring trust in the execution environment provided by the cloud service provider.

  • ii. Chain-of-Custody: Enforce documented chain-of-custody procedures for hardware assets and HSMs from acquisition through decommissioning, ensuring accountability, traceability, and the ability to validate that devices in use remain untampered and aligned with trusted execution environment requirements.

• h. Approval: Approval requirements and senior management involvement to ensure alignment with the organization’s strategic goals and risk appetite

  • i. An approval process should be established for any changes or modifications to the policy and procedures

  • ii. A documented record of approvals (including dates, names of approvers, and any relevant comments or discussions) should be maintained

• i. Communication: Effective communication of the policy and procedures should be facilitated to all relevant cloud stakeholders

• j. Maintenance and Reviews: Data center and equipment disposal security policies and procedures should be documented, reviewed and updated at least annually to ensure alignment with evolving cloud security landscape and to reflect changes in cloud technology, regulations, and risks

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.

Shared Implementation Guidelines

[All Actors except AIC]

1. Providers should ensure that they have robust and clearly documented processes for the secure disposal of equipment that is used outside their physical premises, including devices that handle model development, data processing, or inference tasks. These include but not limited to the procedures listed for the CSP. If using third party datacenter vendors, ensure they have these procedures in place.

Implementation Guidelines for Cloud Service Providers (CSP)

Role Specific The Cloud Service Provider has a broader operational reach given the scale of data center environments and off-site equipment usage.

[All Actors except AIC]

1. Providers should ensure that they have robust and clearly documented processes for the secure disposal of equipment that is used outside their physical premises, including devices that handle model development, data processing, or inference tasks. These include but not limited to the procedures listed for the CSP. If using third party datacenter vendors, ensure they have these procedures in place.

From CCM v4.1: Control Ownership Rationale. The CSP owns the control of ensuring that client data is effectively removed from the provider environment when clients delete, leave, or egress from a cloud platform, due to their direct access to the infrastructure and data, contractual obligations, expertise, and resources.

Implementation Guidelines. Applicable to all service models: The CSP should have a policy outlining the requirements and procedures for the disposal of physical equipment within their data centers.

Policies should include (but not limited to) provisions on the following:

• a. Disposal Authorization: Authorization procedures for equipment disposal requests. Only authorized personnel should be able to initiate and approve such requests

• b. Equipment Disposal: Τhe procedures for the disposal of physical equipment, including servers, storage devices, and networking hardware, when they reach the end of their lifecycle

• c. Asset Inventory and Decommissioning Procedures: Procedures for maintaining an accurate asset inventory (refer to DCS-06) and define the steps to be taken when decommissioning equipment, including the initiation of data destruction processes

• d. Secure Transportation and Disposal: Security measures to be taken during the physical disposal process, including secure transportation to disposal facilities and protection against theft or unauthorized access

• e. Data Destruction: Procedures to completely destroy all data stored on the equipment prior to physical equipment disposal, using industry-approved methods (refer to DSP-02). Secure data erasure procedures should be established to render data irretrievable from storage devices. This may include physical destruction of media (e.g., hard drives demagnetization, paper shredding, etc.), data cryptographic erasure, or software-based erasure methods

• f. Verification of Equipment Destruction: Requirement of a systematic process for verifying the successful and complete destruction of data on decommissioned equipment through a documented and auditable verification mechanism

• g. Disposal Record-Keeping and Auditing: Detailed records of all equipment and data disposal events into a tracking system with a digital certificate of media disposition that clearly indicates whether they have been cleared, purged, or destroyed. Records should include the date, type of equipment/data, equipment serial numbers, disposal methods, dates of disposal, authorized personnel involved and verification results for audit and compliance purposes

• h. Certification of Equipment Disposal Vendors: Requirements to use certified data disposal vendors who adhere to recognized industry standards and provide documentation certifying the proper disposal of data and equipment

• i. Chain of Custody Procedures: Chain of custody procedures to track the movement and handling of equipment slated for disposal, ensuring accountability and preventing unauthorized access

• j. Approval: Approval requirements and senior management involvement to ensure alignment with the organization’s strategic goals and risk appetite

• k. An approval process should be established for any changes or modifications to the policy and procedures

• l. A documented record of approvals (including dates, names of approvers, and any relevant comments or discussions) should be maintained

• m. Communication: Effective communication of the policy and procedures should be facilitated to all relevant cloud stakeholders

• n. Maintenance and Reviews: Data center and equipment disposal security policies and procedures should be documented, reviewed and updated at least annually to ensure alignment with evolving cloud security landscape and to reflect changes in cloud technology, regulations, and risks

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.

Shared Implementation Guidelines

[All Actors except AIC]

1. Providers should ensure that they have robust and clearly documented processes and procedures for the relocation or transfer of hardware, software, or data/information to an offsite or alternate location, including devices that handle model development, data processing, or inference tasks. These include but not limited to the procedures listed for the CSP. If using third-party datacenter vendors, ensure they have these procedures in place.

Implementation Guidelines for Cloud Service Providers (CSP)

Role Specific The CSP owns this control as it operates the datacenters and infrastructure that host customer cloud services and data.

CSPs should implement robust security measures to protect hardware, software, and data/information during relocation or transfer.Policies should include (but not limited to) provisions on the following :

• a. Requirement for the written or cryptographically verifiable authorization from the CSC before initiating the relocation or transfer of any hardware, software, or data/information. This authorization should clearly specify the scope of the relocation or transfer, including the assets involved, the destination location, and the timeframe

• b. Procedures to promptly notify the AIC of the initiation of the relocation or transfer process and provide regular updates on the progress and completion of the relocation or transfer

• c. Chain of custody procedures to track the movement and handling of hardware and software components throughout the entire relocation process, maintaining a secure and auditable record

• d. Procedures that establish an inventory of hardware/software components slated for relocation, including servers, networking equipment, and storage devices. Document their current configuration, and update it post-relocation for audit purposes

• e. A process for access control to restrict access to data/information during the relocation or transfer process supported by logging of all access attempts, modifications, and transfers.

• f. Secure transportation methods for physical relocation of hardware or data storage devices. Tamper-proof packaging, secure tracking mechanisms, and physical security measures should be employed during transit

• g. Requirements for establishing data classification and tagging practices for the sensitivity data/information involved in the relocation or transfer and implementing additional security measures for highly sensitive data (e.g., encryption, DLP measures)

• h. Obfuscation or de-identification techniques should be employed to obscure sensitive data like personal data during transmission

• i. Encryption requirements for data during the transfer process from the cloud environment to the offsite location.

• j. Use strong encryption algorithms (e.g., AES-256) and manage encryption keys securely (refer to CEK-03)

• k. Protect data storage at the offsite location, emphasizing the use of encryption and access controls to protect data once it reaches the destination.

• l. Cryptographic keys, passwords, or other credentials that should be used for encryption or data obfuscation during transfer are properly managed and restricted to authorized personnel

• m. Requirements to assess adherence to relevant regulatory standards and data protection laws during the hardware, software and data/information relocation or transfer, obtain and verify necessary app

• n. Approval requirements and senior management involvement to ensure alignment with the organization’s strategic goals and risk appetite

• o. An approval process should be established for any changes or modifications to the policy and procedures

• p. A documented record of approvals (including dates, names of approvers, and any relevant comments or discussions) should be maintained

• q. Effective communication of the policy and procedures should be facilitated to all relevant cloud stakeholders

• r. Data center and hardware, software relocation and data transfer security policies and procedures should be documented, reviewed and updated at least annually to ensure alignment with evolving cloud security landscape and to reflect changes in cloud technology, regulations, and risks

[All Actors except AIC]

1. Providers should ensure that they have robust and clearly documented processes and procedures for the relocation or transfer of hardware, software, or data/information to an offsite or alternate location, including devices that handle model development, data processing, or inference tasks. These include but not limited to the procedures listed for the CSP. If using third-party datacenter vendors, ensure they have these procedures in place.

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.

Shared Implementation Guidelines

[All Actors except AIC]

1. Providers should ensure that they have documented, approved, communicated, applied, evaluated and maintained policies and procedures for maintaining a safe and secure working environment in offices, rooms, and facilities that processes data for models or inference tasks. These include but not limited to the procedures listed for the CSP.

Implementation Guidelines for Cloud Service Providers (CSP)

Role Specific The CSP should incorporate comprehensive security measures into its policies and procedures to maintain a secure and safe working environment in offices for employees

To meet these responsibilities, the CSP should maintain the following policies and procedures. Policies should include (but not limited to) provisions on the following:

• a. Access Control: Requirements for establishing and implementing physical access controls specifically for office spaces, rooms and facilities to ensure that only authorized personnel can enter. Secure methods should be considered such as secure key cards or biometrics for access

• b. Access Request and Approval Process: Requirements for establishing a defined access request and approval process for all data center facilities, ensuring that access is granted only to authorized personnel and based on the principle of least privilege

• c. Secure Storage: Requirements for maintaining secure storage areas within offices, for sensitive equipment, data storage devices, and confidential documents and personal belongings. Employ access controls and monitoring systems for these storage areas to prevent unauthorized handling or removal.

• d. Workstations Security: Requirements for securing employees workstations:

  • i. Strong password policies and secure login practices

  • ii. Locking workstations when unattended to prevent unauthorized access

  • iii. Avoid leaving sensitive information or access credentials in plain view

• e. Security Surveillance and Personnel: Requirements for the deployment of security personnel to maintain a visible security presence and to enhance safety and deter unauthorized access. Surveillance systems, including CCTV cameras, should be installed to monitor and enhance security

• f. Environmental Safety Measures: Requirements for the implementation of environmental controls to maintain stable temperature, humidity, and power conditions for the safety of employees. Establish procedures to conduct regular fire drills to ensure that employees are familiar with evacuation procedures in case of a fire

• g. Equipment Management: Controls over the secure management of devices, electronic and physical equipment in the working environment. Implement policies for the secure handling, removal, and disposal of equipment and data used in day-to-day work (refer to DSP-01 and DSP-02)

• h. Security Assessments: Requirements to conduct regular inspections in all working environments. Findings should be documented and corrective actions taken to address any issues identified

[All Actors except AIC]

1. Providers should ensure that they have documented, approved, communicated, applied, evaluated and maintained policies and procedures for maintaining a safe and secure working environment in offices, rooms, and facilities that processes data for models or inference tasks. These include but not limited to the procedures listed for the CSP.

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.

Shared Implementation Guidelines

[All Actors Except AIC]

1. Providers should ensure that they have document, approve, communicate, apply, evaluate and maintain policies and procedures for secure transportation of media that processes data for models or inference tasks.

2. Implement Physical protection standards for transfer of media.

3. Design/Implement procedural safeguards/steps in place to authorize and verify such transfers, with separation of duties of personnel involved.

Implementation Guidelines for Cloud Service Providers (CSP)

Role Specific To ensure the secure transportation of physical media, the CSPs should implement comprehensive security measures in their policies and procedures. These measures should include secure packaging, tracking and monitoring, chain-of-custody procedures, secure storage, physical protection, authorization, escort procedures, access restrictions, data encryption and erasure, incident reporting, investigation and response, and post-incident analysis.

Regular training, drills, and documentation procedures at both departure and destination points ensure the integrity and confidentiality of the transported physical media. Incorporating these measures enhances the overall security posture of the CSP during the transportation process.

To meet these responsibilities, the CSP should maintain the following policies and procedures.

Policies should include (but not limited to) provisions on the following:

• a. Media Transport Authorization: A written or cryptographically verifiable authorization for the transportation of physical media. This authorization should specify the type of media, destination, and authorized personnel involved

• b. Media Data Encryption and Erasure:

  • i. Sensitive data stored on physical media should be encrypted using strong encryption algorithms

  • ii. Secure data erasure procedures for physical media should be established according to industry-approved methods such as physical destruction, demagnetization, or cryptographic erasure

• c. Secure Packaging: Requirements for secure packaging standards to protect physical media from damage and tampering during transportation. Packaging should conceal the nature of the media to prevent unauthorized identification

• d. Secure Storage: Requirements for the secure storage of physical media in designated secure areas with restricted access control, such as vaults, secure cabinets, or access-controlled storage facilities. Physical security measures should be included to protect physical media storage areas (e.g., alarms, surveillance systems, and security personnel)

• e. Chain-of-Custody: Chain-of-custody procedures to maintain a record of all individuals who handle the physical media during transit

• f. Tracking and Monitoring: Requirements for implementing real-time tracking and monitoring systems to track the location and status of physical media in transit (e.g., via GPS tracking, secure shipping services, or courier services with tracking capabilities)

• g. Route Planning: Plans for transportation routes that minimize risks, considering factors such as high-crime areas or other potential security threats

• h. Escort Procedures: Escort procedures for the transportation of highly sensitive physical media that require authorized personnel to accompany the media throughout the transit process

• i. Secure Delivery of Physical Media: Procedures for the documentation, secure unloading and handling of physical media upon arrival at the destination confirming the safe and secure delivery of physical media, including verification steps to ensure the integrity of the transported media

• j. Access Restrictions: A process to restrict access to physical media during transit to authorized personnel only to prevent unauthorized individuals from handling or accessing the media

• k. Approval: Approval requirements and senior management involvement to ensure alignment with the organization’s strategic goals and risk appetite

  • i. An approval process should be established for any changes or modifications to the policy and procedures

  • ii. A documented record of approvals (including dates, names of approvers, and any relevant comments or discussions) should be maintained

• l. Communication: Effective communication of the policy and procedures should be facilitated to all relevant cloud stakeholders

• m. Maintenance and Reviews: Physical media transportation security policies and procedures should be documented, reviewed and updated at least annually to ensure alignment with evolving cloud security landscape and to reflect changes in cloud technology, regulations, and risks

[All Actors Except AIC]

1. Providers should ensure that they have document, approve, communicate, apply, evaluate and maintain policies and procedures for secure transportation of media that processes data for models or inference tasks.

2. Implement Physical protection standards for transfer of media.

3. Design/Implement procedural safeguards/steps in place to authorize and verify such transfers, with separation of duties of personnel involved.

To meet these responsibilities, the CSP should maintain the following policies and procedures.

Policies should include (but not limited to) provisions on the following:

• a. Media Transport Authorization: A written or cryptographically verifiable authorization for the transportation of physical media. This authorization should specify the type of media, destination, and authorized personnel involved

• b. Media Data Encryption and Erasure:

  • i. Sensitive data stored on physical media should be encrypted using strong encryption algorithms

  • ii. Secure data erasure procedures for physical media should be established according to industry-approved methods such as physical destruction, demagnetization, or cryptographic erasure

• c. Secure Packaging: Requirements for secure packaging standards to protect physical media from damage and tampering during transportation. Packaging should conceal the nature of the media to prevent unauthorized identification

• d. Secure Storage: Requirements for the secure storage of physical media in designated secure areas with restricted access control, such as vaults, secure cabinets, or access-controlled storage facilities. Physical security measures should be included to protect physical media storage areas (e.g., alarms, surveillance systems, and security personnel)

• e. Chain-of-Custody: Chain-of-custody procedures to maintain a record of all individuals who handle the physical media during transit

• f. Tracking and Monitoring: Requirements for implementing real-time tracking and monitoring systems to track the location and status of physical media in transit (e.g., via GPS tracking, secure shipping services, or courier services with tracking capabilities)

• g. Route Planning: Plans for transportation routes that minimize risks, considering factors such as high-crime areas or other potential security threats

• h. Escort Procedures: Escort procedures for the transportation of highly sensitive physical media that require authorized personnel to accompany the media throughout the transit process

• i. Secure Delivery of Physical Media: Procedures for the documentation, secure unloading and handling of physical media upon arrival at the destination confirming the safe and secure delivery of physical media, including verification steps to ensure the integrity of the transported media

• j. Access Restrictions: A process to restrict access to physical media during transit to authorized personnel only to prevent unauthorized individuals from handling or accessing the media

• k. Approval: Approval requirements and senior management involvement to ensure alignment with the organization’s strategic goals and risk appetite

  • i. An approval process should be established for any changes or modifications to the policy and procedures

  • ii. A documented record of approvals (including dates, names of approvers, and any relevant comments or discussions) should be maintained

• l. Communication: Effective communication of the policy and procedures should be facilitated to all relevant cloud stakeholders

• m. Maintenance and Reviews: Physical media transportation security policies and procedures should be documented, reviewed and updated at least annually to ensure alignment with evolving cloud security landscape and to reflect changes in cloud technology, regulations, and risks

Shared

1. Providers should ensure that they have document, approve, communicate, apply, evaluate and maintain policies and procedures for secure transportation of media that processes data for models or inference tasks.

2. Implement Physical protection standards for transfer of media.

3. Design/Implement procedural safeguards/steps in place to authorize and verify such transfers, with separation of duties of personnel involved.

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.

Shared Implementation Guidelines

[All Actors]

1. Providers should classify the different types of assets that perform tasks such as data processing , inference based on the risk of data that might affect the organization, if exposed.

2. Core principles for Asset classification which applies to all AI ecosystem participants (MP, OSP, AP, AIC, CSP) should implement consistent asset classification.

3. Core areas where each needs to be expanded are: Comprehensive Inventory Management, Risk-Based Classification, Access Control Framework, Monitoring & Incident Response, Documentation Requirements.

Implementation Guidelines for Cloud Service Providers (CSP)

Role Specific CSPs should adhere to a comprehensive approach that aligns with the data sensitivity levels defined by the CSC. This involves understanding the CSC’s data classification policy, identifying and assessing the sensitivity of data stored on each asset, implementing appropriate security controls, and continuously monitoring and auditing asset security.

Additionally, CSPs should document asset classification and security controls, train employees, and leverage automated tools to streamline the process and enhance data protection measures. By adopting these best practices, CSPs can effectively safeguard sensitive data and fulfill their contractual responsibilities as trusted partners in the cloud ecosystem.

Implementation best practices for the CSP to classify and document the physical, and logical assets include (but not limited to):

• a. Asset Inventory and Tracking: The CSP should leverage an inventory of all physical and logical assets that are used to store, process, or transmit CSC data (refer to DCS-06), including physical equipment, such as servers and storage devices, as well as software components, such as network assets and configurations, virtual machines, operating systems and applications

• b. Asset Classification: The CSP should assess the sensitivity of data stored on each asset based on the CSC’s data classification policy. This assessment should take into account the type of CSC data, the potential harm that could be caused if the data were breached, and the legal and regulatory requirements for protecting the data

• c. Automated Tools for Assets Classification: The CSP can use automated tools to help with asset classification and security. These tools can scan assets for vulnerabilities and identify assets that are not in compliance with the asset classification policies

• d. Assets Classification Documentation: The CSP should document the classification of each asset and the security controls that are applied to the asset. This documentation should be made available to the CSC upon request

• e. Assets Tagging: The CSPs should assign unique tags or labels to physical and logical assets to facilitate identification, tracking, and management (refer to DCS-06).

• f. Apply Security Controls: Appropriate classification levels should be applied to physical and logical assets and appropriate security protection and controls in accordance to the sensitivity of the data stored on, processed or transmitted by the cloud asset

• g. Continuous Monitoring and Evaluation: The CSP should monitor and audit assets security on a regular basis or upon changes to assets to ensure that the security controls applied are effective and appropriate based on the sensitivity levels of CSC data

• h. Prioritize documenting usage patterns, data sharing agreements, and security requirements for AI vendors.

[All Actors]

1. Providers should classify the different types of assets that perform tasks such as data processing , inference based on the risk of data that might affect the organization, if exposed.

2. Core principles for Asset classification which applies to all AI ecosystem participants (MP, OSP, AP, AIC, CSP) should implement consistent asset classification.

3. Core areas where each needs to be expanded are: Comprehensive Inventory Management, Risk-Based Classification, Access Control Framework, Monitoring & Incident Response, Documentation Requirements.

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.

Shared Implementation Guidelines

[All Actors]

1. Maintaining detailed catalogs of physical and digital assets relevant to each entity’s role.

2. Documenting dependencies, connections, and data flows between components.

3. Monitoring assets from creation through deployment to retirement.

4. Implementing appropriate protection mechanisms based on asset classification.

5. Ensuring asset management practices support industry frameworks.

Implementation Guidelines for Cloud Service Providers (CSP)

Role Specific

1. The AIC should reach out to its CSP to understand what tools it provides (e.g., access to the cloud management plane via catalog managers and APIs) that enable the CSC to retrieve the list of cloud assets that are used to handle the AIC’s data.

2. The AIC should define a tagging strategy for their environment that involves creating a list of tags to categorize assets and asset owners in a catalog. A standardized naming convention is the starting point for organizing the cloud-hosted resources. The same naming conventions on tags should be consistently used across multiple CSPs (e.g., multi-cloud environment), and where possible, cloud assets should be tracked by an automated means, allowing for prompt decisions to be made according to them (e.g., access control decisions, monitoring and alerting, accounting).

3. Templates for defining a naming and tagging convention for tagging assets are defined by all major CSPs. The AIC may choose to adopt the CSP’s naming standards or define their own that they wish to apply to each asset type they plan to deploy as part of their cloud adoption effort.

Examples of tagging conventions and respective cloud assets types that should be cataloged and tracked are below, where applicable by cloud service model (but not limited to):

• a. Asset Tags Types:

  • i. Environment Tag: Identifying resources belonging to different environments such as production, development, or testing

  • ii. Function/Application Tag: Associating resources with specific applications or services within the cloud environment

  • iii. Department Tag: Associating resources with specific departments in the organization

  • iv. Location Tag: Tagging resources based on their geographic location or data center region

• b. Owner Tag: Specifying the individual or team responsible for a particular resource vi. Release Version Tag: Version number of the software or application they are associated with vii. Security Classification Tag: Identifying the security classification or sensitivity level of resources viii. Compliance/Regulatory Tag: Indicate compliance with specific regulations or standards ix. Automation Tag: Indicate whether the asset should be selected for action by scripts, scanners or other form of automation

• c. Active Tag: Designates resources currently in use for production, development, or other relevant purposes xi. Deprecated Tag: Designates resources scheduled for retirement or no longer actively used

• d. Cloud Asset Types:

  • i. Virtual machines (e.g., VM instances/images, OS name/version),

  • ii. Virtual networking (e.g., VPC networks and subnets, DNS records, IP addresses),

  • iii. Databases (e.g., database/SQL servers),

  • iv. Storage (e.g., block, file, object storage types),

• e. Applications (e.g., custom applications, container images, software licenses) vi. Maintaining detailed catalogs of physical and digital assets relevant to each entity’s role. vii. Documenting dependencies, connections, and data flows between components viii. Monitoring assets from creation through deployment to retirement ix. Implementing appropriate protection mechanisms based on asset classification

• f. Ensuring asset management practices support industry frameworks.

1. The catalog should include all device status changes (e.g., patch levels, lost/decommissioned status, and to whom the asset type is assigned, or approved for BYOD).

2. Cloud asset cataloging and tracking should be prioritized to include the most security-relevant or critical ones followed by the inclusion of remaining asset types that pertain to minimal or no risk.

3. If supported by the CSP, automated scans should be made to identify assets that are not tagged or have tagged values not aligned to AIC’s tagging rules (e.g., assets tagged or not tagged with a ‘classification level’ value).

4. When tagging tools are not made available from the CSP, the AIC should proceed with manually tagging and cataloging assets. Easy-to-parse formats (JSON, YAML, XML) should be preferred for more efficient management and maintenance of the catalog.

5. The AIC should map security tools to the assets included in the catalog in order to prevent, detect, recover, and respond to security risks that are applicable to them (e.g., use vulnerabilities patching and antivirus tools with VM/OS assets as preventive and detective security controls).

6. Assets that have been tagged with a ‘Security Classification Level’ key type should inherit the highest data classification level (high-water mark) value among the different classification levels of data that the particular asset type is destined to use for performing computational, network or storage operations on such data.

7. Ensure that contractual agreements with CSPs cover data handling and physical access restrictions” or “periodically review third-party audit reports.

[All Actors]

1. Maintaining detailed catalogs of physical and digital assets relevant to each entity’s role.

2. Documenting dependencies, connections, and data flows between components.

3. Monitoring assets from creation through deployment to retirement.

4. Implementing appropriate protection mechanisms based on asset classification.

5. Ensuring asset management practices support industry frameworks.

DCS-08: Controlled Physical Access Points

Control Specification

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

Shared Implementation Guidelines

[All Actors Except AIC]

1. Providers should implement physical security measures to safeguard personnel, data and information systems that are involved in tasks, such as data processing, inference, training.

Implementation Guidelines for Cloud Service Providers (CSP)

Role specific CSPs handle sensitive data and information systems for the AICs , making them a prime target for physical security breaches. Establishing robust physical security perimeters enables CSPs to safeguard personnel, data, and information systems within CSP facilities. These guidelines outline best practices for implementing effective physical security perimeters to protect CSP assets.

1. Implementation best practices for the physical perimeter security include (but not limited to):

   • a. Perimeter Security:

     • i. High-security fencing with controlled access points should be installed to demarcate the CSP’s physical boundaries

     • ii. Multi-factor authentication (MFA) should be implemented for all entry points, including gates, doors, and loading docks. Employees and visitors should present valid credentials and undergo identity verification before entering

     • iii. A comprehensive network of high-resolution, motion-activated surveillance cameras should be installed throughout the perimeter and within restricted areas

     • iv. Adequate and well-maintained lighting around the perimeter should be installed to deter unauthorized access and improve visibility for security personnel and surveillance systems

   • b. Administrative and Business Areas:

     • i. A physical separation between administrative and business areas and data storage and processing facilities areas should be created

     • ii. Stricter access controls for data storage and processing facilities areas should be implemented, restricting entry to authorized personnel only

     • iii. A formal visitor management process should be established that requires visitors to be accompanied by authorized personnel at all times. Maintain visitor logs and restrict access to sensitive areas

     • iv. Vendor access should be segregated to designated areas and access to sensitive areas restricted to monitor vendor activities and ensure proper documentation of their presence and actions

   • c. Data Storage and Processing Facilities Areas:

     • i. Sensitive data and critical IT assets should be stored within dedicated, secure rooms with reinforced walls, doors, and access control systems. Mantraps or other physical barriers should be implemented to control entry and prevent unauthorized access

     • ii. A designated area for deliveries and inspection should be established. Tamper-evident seals, tracking mechanisms should be implemented for deliveries and equipment. Access to delivery areas should be restricted and documentation maintained of all deliveries

     • iii. Reliable power backup systems and surge protection should be implemented to ensure uninterrupted operation and protection of IT infrastructure in case of power outages or power surges

   • d. Continuous Monitoring and Evaluation:

     • i. Physical security assessments should be regularly conducted to identify and address potential vulnerabilities

     • ii. Share threat intelligence with relevant personnel, and stay informed about emerging physical security threats and adapt security measures accordingly

[All Actors Except AIC]

1. Providers should implement physical security measures to safeguard personnel, data and information systems that are involved in tasks, such as data processing, inference, training.

DCS-09: Equipment Identification

Control Specification

Use equipment identification as a method for connection authentication.

Shared Implementation Guidelines

[All Actors Except AIC]

1. Providers should implement equipment identification as a means for authenticating to connection for systems that perform data processing, inference tasks.

2. Providers should have hardware identity foundations with trusted platform modules and unique fingerprinting across infrastructure, which combined with authentication mechanism, such as mutual TLS, certificate-based validation, and hardware-bound access controls.

3. Providers should establish continuous attestation services and anomaly detection while protecting infrastructure through secure boot capabilities and hardware roots of trust.

Implementation Guidelines for Cloud Service Providers (CSP)

Role Specific Implementing physical equipment identification as a method for connection authentication enhances cloud security by verifying the authenticity of devices connecting to cloud resources. This approach adds an extra layer of protection beyond traditional username and password authentication, mitigating risks associated with unauthorized access and credential theft.

Implementation best practices for equipment authentication include (but not limited to):

• a. Equipment Registration and Identification:

  • i. A comprehensive inventory of all authorized equipment should be maintained (refer to DCS-06)

  • ii. Automated mechanisms to discover and register equipment connecting to the cloud environment should be employed

  • iii. Equipment identification should be integrated with cloud access control mechanisms to enforce granular access policies

• b. Identifiers Assignment and Protection:

  • i. Unique identifiers (e.g., MAC addresses, serial numbers) should be assigned to all physical equipment connected to the cloud infrastructure (e.g., servers, network devices, storage devices, and any other connected hardware)

  • ii. A consistent and standardized naming convention for equipment identifiers should be used

  • iii. Tamper-proof mechanisms to prevent unauthorized modification of equipment identifiers should be employed (e.g., hardware-based identifiers, cryptographic techniques, or secure tamper-evident labels)

• c. Equipment Trustworthiness Assessment:

  • i. Equipment attestation protocols should be implemented to validate the integrity and trustworthiness of connecting equipment

  • ii. Secure boot mechanisms should be utilized to ensure that equipment is running genuine and unmodified firmware

  • iii. Vulnerability scanning and patching techniques should be employed to maintain equipment security posture

• d. Connection Authentication Mechanisms:

  • i. Granular access control policies based on equipment identity, risk assessment, and user authorization levels should be employed

  • ii. Access to sensitive resources and privileged functionalities should be restricted based on equipment trustworthiness and user privileges

  • iii. A secure communication channel should be established between the cloud infrastructure and the equipment to be authenticated (e.g., using TLS, SSH encryption or a dedicated authentication protocol)

  • iv. An equipment mechanism should be implemented to present its unique identifier to the cloud infrastructure during the authentication process (e.g., a cryptographic handshake, a challenge-response mechanism, or a secure configuration protocol)

• e. The authenticity of the equipment identifier should be validated using a trusted source of equipment information (e.g., a centralized equipment registry, a distributed ledger technology, or a trusted hardware security module (HSM))

• f. Continuous Monitoring and Evaluation:

  • i. The effectiveness of equipment authentication controls should be continuously monitored and assessed (e.g., by using SIEM tools, cloud-based security monitoring services)

  • ii. Audit logs should be maintained (e.g., the equipment identifier, authentication method, timestamp, and connection status) and regularly reviewed to identify potential security breaches, unauthorized access attempts, or misconfigurations related to equipment identification and authentication

[All Actors Except AIC]

1. Providers should implement equipment identification as a means for authenticating to connection for systems that perform data processing, inference tasks.

2. Providers should have hardware identity foundations with trusted platform modules and unique fingerprinting across infrastructure, which combined with authentication mechanism, such as mutual TLS, certificate-based validation, and hardware-bound access controls.

3. Providers should establish continuous attestation services and anomaly detection while protecting infrastructure through secure boot capabilities and hardware roots of trust.

4. Providers should have hardware identity foundations with trusted platform modules and unique fingerprinting across infrastructure, which combined with authentication mechanism, such as mutual TLS, certificate-based validation, and hardware-bound access controls.

5. Providers should establish continuous attestation services and anomaly detection while protecting infrastructure through secure boot capabilities and hardware roots of trust.

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.

Shared Implementation Guidelines

[All Actors except AIC]

1. Providers should allow only authorized personnel access to secure areas that contain equipment that perform tasks, data processing, inference. The access should be restricted by physical security controls and reviewed on a periodic basis.

Implementation Guidelines for Cloud Service Providers (CSP)

Role Specific The CSP should establish a comprehensive framework for restricting access to secure areas within cloud environments, ensuring that only authorized personnel can gain entry and that all ingress and egress activities are documented, monitored, and retained for a specified period.

Implementation best practices for secure areas access include (but not limited to):

• a. Physical Access Control:

  • i. A layered approach to physical access control should be implemented using a combination of physical barriers, electronic access control systems, and security personnel

  • ii. Designated entry and exit points for secure areas should be established

  • iii. Physical barriers should be installed to prevent unauthorized entry into secure areas (e.g., fences, walls, doors, mantraps)

  • iv. Electronic access control systems should be implemented (e.g., key cards, proximity cards, or biometric scanners)

• b. Security personnel should be employed to monitor and patrol secure areas, both physically and electronically vi. Visitor management procedures should be implemented to track and control the entry and exit of non-authorized personnel.

• c. Access Control Records Documentation:

  • i. Access control records system should be implemented to document and capture all ingress and egress activities within secure areas

  • ii. Identity of all personnel entering and exiting secure areas should be recorded along with the date and time of access

  • iii. The type of access granted should be documented, such as physical access, logical access, or remote access

  • iv. Access control records should be maintained for a period of time deemed appropriate by the organization and in accordance with regulatory requirements and organizational policies

• d. Monitoring of Ingress and Egress Points:

  • i. Ingress and egress points should be continuously monitored to secure areas using surveillance cameras and other monitoring systems

  • ii. Monitoring systems should be integrated with access control systems to correlate access events with video footage.

  • iii. Procedures should be established for promptly reviewing and investigating any suspicious access events

• e. Continuous Monitoring and Evaluation: The effectiveness of physical access controls should be continuously monitored and regular physical security assessments conducted to identify and address potential vulnerabilities.

[All Actors except AIC]

1. Providers should allow only authorized personnel access to secure areas that contain equipment that perform tasks, data processing, inference. The access should be restricted by physical security controls and reviewed on a periodic basis.

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.

Shared Implementation Guidelines

[All Actors except AIC,AP,OSP]

1. Providers should implement and maintain surveillance around data centres that perform tasks related to data processing, inference, etc.

2. Full coverage of DC with no blind spots. Establish formal chain of custody procedures for access recordings.

3. Maintain comprehensive access logs for all entry and exit events including maintenance activities performed on surveillance systems for regulatory compliance reviews.

Implementation Guidelines for Cloud Service Providers (CSP)

Role Specific For the CSPs to effectively implement, maintain, and operate datacenter surveillance systems for unauthorized ingress and egress detection, implementation best practices should include (but not limited to):

• a. Physical Access Control Systems (PACS): PACS should be implemented to control access to the datacenter perimeter (e.g., entry points, server rooms, and restricted areas). PACS can utilize various authentication methods, such as multi-factor authentication (MFA) and using key cards, biometrics, etc.

• b. Video Surveillance: High-resolution cameras with night vision capabilities, motion detection, and analytics to capture clear images and identify suspicious activities should be deployed around the data center perimeter (e.g., entry points, fencing, and parking areas). Technologies include (but not limited to):

  • i. Thermal imaging cameras to detect heat signatures, providing surveillance even in low-light or obscured conditions

  • ii. License Plate Recognition implemented at vehicle entry points to capture and identify license plates, enabling monitoring of authorized and unauthorized vehicles

  • iii. AI-powered surveillance systems to enhance threat detection and analysis, enabling real-time identification of potential threats

• c. Perimeter Intrusion Detection Systems (PIDS): PIDS sensors should be deployed to detect unauthorized intrusions into the data center perimeter (e.g., motion sensors, infrared beams, and fiber optic sensors, ground penetrating radar)

• d. Perimeter Intrusion Prevention Systems (PIPS): PIPS should be deployed along the perimeter to actively prevent unauthorized intrusions (e.g., electrified fencing, retractable bollards, and sonic deterrents)

• e. Video Analytics: Video analytics software should be utilized to analyze surveillance footage and automatically detect suspicious activities (e.g., loitering, unauthorized access, and unusual behavior)

• f. Continuous Monitoring and Evaluation: The effectiveness of datacenter surveillance systems should be continuously monitored and security measures adapted to ensure they are properly configured, maintained, and up-to-date based on evolving threats and vulnerabilities.

[All Actors except AIC,AP,OSP]

1. Providers should implement and maintain surveillance around data centres that perform tasks related to data processing, inference, etc.

2. Full coverage of DC with no blind spots. Establish formal chain of custody procedures for access recordings.

3. Maintain comprehensive access logs for all entry and exit events including maintenance activities performed on surveillance systems for regulatory compliance reviews.

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.

Shared Implementation Guidelines

[All Actors except AIC]

1. Providers should have trained personnel to handle unauthorized access into areas of data center that perform sensitive tasks, such as data processing.

Implementation Guidelines for Cloud Service Providers (CSP)

Role Specific

Data center personnel should be properly trained to respond effectively to unauthorized physical access attempts for maintaining the security of a CSP’s environment.

Implementation best practices in training personnel to respond to unauthorized ingress or egress incidents include (but not limited to):

• a. Training Programs: Training programs that cover various aspects of physical security (e.g., recognizing unauthorized access, responding to incidents, and following established procedures should be designed and implemented)

  • i. Data center personnel should be well-versed in the incident response plan related to unauthorized physical access attempts

  • ii. Personnel should be trained on the specific steps to take in the event of an unauthorized ingress or egress incident

  • iii. Personnel should be trained on the importance of accurate and timely documentation of ingress/egress access incidents and need for detailed reports that can be used for analysis, investigations, and compliance purposes

• b. Emergency Procedures: Detailed training on emergency procedures should be provided (e.g., evacuations, lockdowns, or any other response measures that may be required during a security incident)

• c. Simulation Exercises: Regular simulated exercises should be conducted to allow personnel to practice responding to unauthorized physical access attempts

• d. Communication Protocols: Personnel should be trained on how to quickly and accurately report incidents to the appropriate authorities, including security teams, management, and, if necessary, law enforcement

• e. Use of Security Technology: Personnel should be trained on the use of security technology (e.g., surveillance cameras, access control systems, and intrusion detection systems), how to interpret alerts and respond appropriately

• f. Security Teams Coordination:

  • i. Collaboration and coordination should be fostered between datacenter personnel and dedicated security teams

  • ii. Roles and responsibilities should be understood by relevant teams during a security incident

• g. Escorting Procedures:

  • i. Personnel should be trained on proper escorting procedures for visitors or contractors within secure areas

  • ii. Challenge procedures should be implemented to verify the identity of individuals without proper credentials

• h. Legal and Ethical Considerations: Education should be provided on the legal and ethical aspects of responding to unauthorized physical access attempts and understanding of the limits of personnel’s authority and the appropriate actions to take within the confines of the law

• i. Post-Incident Review: After each simulated exercise or real incident, a post-incident review should be conducted to identify areas for improvement identified, and incorporate lessons learned into future training sessions

[All Actors except AIC]

1. Providers should have trained personnel to handle unauthorized access into areas of data center that perform sensitive tasks, such as data processing.

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.

Shared Implementation Guidelines

[All Actors except AIC]

1. Providers should implement measures that ensure risk based approach to protection of equipment such as cables, server racks, that perform sensitive tasks, such as data processing, inference, training, etc.

2. Provider should establish redundant connections for critical systems, deploy real-time monitoring with tamper detection, and restrict physical access through role-based controls.

3. Regular inspections, maintenance schedules during minimal usage windows, and comprehensive disaster recovery plans ensure ongoing protection.

Implementation Guidelines for Cloud Service Providers (CSP)

Role Specific

Power and telecommunication cables are critical infrastructure components that support the operation of data centers, offices, and rooms. These cables are vulnerable to a variety of threats, including interception, interference, and damage.

• Interception can allow unauthorized individuals to gain access to sensitive data

• Interference can disrupt or disable critical systems

• Damage can cause power outages and data loss

To protect power and telecommunication cables from these threats, CSPs should implement a risk-based approach that includes (but not limited to) the following measures:

• a. Cable Security Risk Assessment: Risk assessment should be conducted to identify potential threats to power and telecommunication cables, including physical access, electromagnetic interference (EMI), and intentional sabotage

• b. Cables Physical Access Barriers: Physical barriers should be implemented to restrict unauthorized access to power and telecommunication cables (e.g., fences, security gates, and access control systems)

• c. Secure Cable Routing: Cables should be routed through secure pathways (e.g., conduits or dedicated cable trays)

• d. Cable Shielding: Shielded cables or protective enclosures should be utilized to minimize electromagnetic interference (EMI) and prevent unauthorized signal tapping

• e. Power and Telecommunication Cables Segregation: Segregating power and telecommunication cables can help to prevent EMI from interfering with telecommunication signals

• f. Grounding and Bonding: Proper grounding and bonding practices should be implemented to protect cables from electrical surges and lightning strikes

• g. Monitoring and Surveillance: Surveillance systems to monitor cable infrastructure for signs of tampering or damage should be installed and maintained

• h. Continuous Monitoring and Evaluation:

  • i. The effectiveness of implemented cable security controls should be evaluated through regular testing and monitoring to identify any gaps or weaknesses

  • ii. Trends in cable damage, interference, or interception incidents should be analyzed to identify patterns and potential areas for improvement, incorporating lessons learned and emerging threats i. Implement automated documentation of cable infrastructure changes.

• i. Establish security review processes for new connectivity requirements.

• j. Install diverse entry points for ISPs and telecommunications connections

[All Actors except AIC]

1. Providers should implement measures that ensure risk based approach to protection of equipment such as cables, server racks, that perform sensitive tasks, such as data processing, inference, training, etc.

2. Provider should establish redundant connections for critical systems, deploy real-time monitoring with tamper detection, and restrict physical access through role-based controls.

3. Regular inspections, maintenance schedules during minimal usage windows, and comprehensive disaster recovery plans ensure ongoing protection.

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.

Shared Implementation Guidelines

[All Providers except AIC]

1. Providers should implement environmental control systems around data centres that perform sensitive tasks such as training, data processing, inference to ensure continual effectiveness and humidity conditions is within accepted standards.

2. Providers should establish comprehensive environmental control systems that address the specific environmental conditional such as temperature and humidity requirements of AI computing hardware.

3. Implement multi-tiered monitoring systems with real-time dashboards and automated alerts for deviations that might impact system performance.

4. Develop documented emergency protocols for environmental failures, including graceful degradation and workload shifting capabilities.

5. Create redundant cooling and power systems with N+1 redundancy for critical AI workloads.

6. Conduct regular effectiveness testing and maintenance of all environmental controls, with quarterly performance analysis to optimize for both reliability and energy efficiency.

Implementation Guidelines for Cloud Service Providers (CSP)

Role Specific CSPs should implement and maintain effective datacenter environmental control systems to ensure optimal performance and reliability of the data center.

1. Implementation best practices for a CSP to secure datacenter environmental control systems include (but not limited to):

   • a. Environmental Monitoring Systems:

     • i. Advanced environmental monitoring systems to track temperature and humidity levels in real-time

     • ii. Distributed sensors strategically placed throughout the datacenter to capture accurate readings from different zones

   • b. Automated Environmental Controls: Automated control systems to adjust temperature and humidity based on predefined thresholds that are integrated with Building Management Systems (BMS) for centralized control and automation

   • c. Redundancy and Failover:

     • i. Redundant HVAC (Heating, Ventilation, and Air Conditioning) systems implemented to ensure continuous operation even if one system fails

     • ii. Failover mechanisms implemented to switch between different environmental control systems seamlessly

   • d. Energy Efficiency:

     • i. Cooling system efficiency should be optimized through techniques such as hot/cold aisle containment, airflow management, and variable speed fans

     • ii. Free cooling methods should be utilized when external conditions permit, such as outside air economization

   • e. Remote Monitoring and Management:

     • i. Remote monitoring and management capabilities should be enabled to allow administrators to oversee and control environmental conditions from anywhere

     • ii. Alerts and notifications should be implemented for out-of-range conditions to facilitate rapid response

   • f. Regular Maintenance:

     • i. A routine maintenance schedule for HVAC equipment, including cleaning, filter replacement, and calibration of sensors should established

     • ii. Periodic inspections should be conducted to identify potential issues before they lead to failures

   • g. Regular Performance Testing:

     • i. Regular performance testing of environmental control systems should be conducted to ensure they meet industry standards

     • ii. Simulate extreme conditions to validate the system’s ability to handle peak loads

   • h. Thermal Imaging and Analysis:

     • i. Thermal imaging cameras to identify hotspots and optimize the placement of cooling equipment

     • ii. Thermal analysis to ensure uniform temperature distribution across the datacenter i. Alignment to Standards: A process for environmental security control systems alignment and adherence to industry standards (e.g., ISA/IEC 62443)

   • i. Documentation and Reporting:

     • i. Documentation of environmental control configurations, testing procedures, and results should be maintained

     • ii. Regular reports should be generated on system performance and environmental conditions for review and analysis

   • j. Environmental Systems Access Control: Physical access controls to environmental control systems should be implemented to prevent unauthorized tampering and remote access restricted to authorized personnel using secure protocols

   • k. Audit Trails: Detailed audit trails should be enabled to track changes to environmental control configurations and regularly reviewed to identify and investigate any unusual activities

   • l. Systems/Software Patching: Environmental control systems and associated software should be kept up to date with the latest security patches.

   • m. Cloud-based Monitoring and Management:

     • i. Cloud-based monitoring and management platforms should be utilized to centrally oversee environmental conditions across multiple datacenters

     • ii. Cloud-based solutions should provide real-time visibility into environmental data, facilitate data analysis, and enable remote management of control systems

     • iii. Cloud-based predictive analytics tools should be utilized to analyze sensor data and identify potential environmental hazards before they impact critical IT infrastructure

[All Providers except AIC]

1. Providers should implement environmental control systems around data centres that perform sensitive tasks such as training, data processing, inference to ensure continual effectiveness and humidity conditions is within accepted standards.

2. Providers should establish comprehensive environmental control systems that address the specific environmental conditional such as temperature and humidity requirements of AI computing hardware.

3. Implement multi-tiered monitoring systems with real-time dashboards and automated alerts for deviations that might impact system performance.

4. Develop documented emergency protocols for environmental failures, including graceful degradation and workload shifting capabilities.

5. Create redundant cooling and power systems with N+1 redundancy for critical AI workloads.

6. Conduct regular effectiveness testing and maintenance of all environmental controls, with quarterly performance analysis to optimize for both reliability and energy efficiency.

DCS-15: Secure Utilities

Control Specification

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

Shared Implementation Guidelines

[All Actors except AIC]

1. Providers should test utility services that power data centres that perform sensitive tasks such as training, data processing, inference to ensure continual effectiveness on a periodic basis.

2. Providers should establish comprehensive environmental control systems that address the specific environmental conditional such as temperature and humidity requirements of AI computing hardware.

3. Implement multi-tiered monitoring systems with real-time dashboards and automated alerts for deviations that might impact system performance.

4. Develop documented emergency protocols for environmental failures, including graceful degradation and workload shifting capabilities.

5. Create redundant cooling and power systems with N+1 redundancy for critical AI workloads.

6. Conduct regular effectiveness testing and maintenance of all environmental controls, with quarterly performance analysis to optimize for both reliability and energy efficiency.

Implementation Guidelines for Cloud Service Providers (CSP)

Role Specific Data center utility services refer to the essential infrastructure components that support the functioning of a data center. These services are critical for maintaining the operational integrity, performance, and reliability of the data center environment.

Key data center utility services include: Power supply and backup, Cooling/HVAC, Fire Suppression, Rack and Cabinet, Water and Leak detection systems.

1. Implementation best practices to secure utilities services include (but not limited to):

   • a. Power Supply and Backup Systems:

     • i. A continuous and reliable source of electricity to power servers, networking equipment, and other hardware within the data center

     • ii. Physical and logical security measures to protect power distribution systems (PDUs), transformers, and generators from unauthorized access, sabotage, and cyberattacks

     • iii. Power consumption should be continuously monitored to identify anomalies, potential overloads, impending failures and generate alerts

     • iv. Regular maintenance for power equipment including cleaning, inspections, and testing, to minimize downtime and extend equipment lifespan

   • b. Power systems and backup power systems (e.g., backup generators, UPS systems) should be regularly tested and maintained to ensure they can handle peak demand without disruptions or outages vi. Redundant power sources should be implemented to ensure continuous operation and backup generators and UPS systems regularly inspected and tested vii. Backup power systems should have their own security measures to prevent tampering viii. Log events related to backup power systems should be monitored for security analysis

   • c. Cooling Systems and HVAC (Heating, Ventilation, Air Conditioning):

     • i. Cooling systems to regulate the temperature and humidity levels in the data center to prevent equipment overheating and ensure optimal operating conditions

     • ii. Physical and logical security measures to protect HVAC systems, including air conditioning units, chillers, and cooling towers, from unauthorized access, sabotage, and cyberattacks

     • iii. Cooling system performance, including temperature, humidity, and airflow, should be continuously monitored to identify potential issues and maintain optimal cooling conditions

     • iv. Maintenance for cooling equipment should be scheduled on a regular basis to ensure efficient operation and prevent breakdowns

   • d. Backup cooling systems (e.g., generators and emergency cooling units) should be regularly tested to ensure they can maintain proper cooling in the event of a primary system failure vi. HVAC systems should be used with remote monitoring and control capabilities

   • e. Fire Suppression Systems:

     • i. Automated fire detection and suppression mechanisms to protect against the risk of fire and minimize potential damage to equipment

     • ii. Physical and logical access to fire suppression control systems should be restricted and reviewed on a regular basis

     • iii. Continuous monitoring for fire detection sensors should be enabled and regular tests and inspections conducted of fire suppression systems

     • iv. Routine inspections and maintenance for fire protection equipment should be scheduled

   • f. Fire suppression systems and software should be updated based on industry best practices

   • g. Rack and Cabinet Systems:

     • i. Server racks should be secured with physical locks and access controls

     • ii. Cable management practices should be implemented to avoid security risks associated with disorganized cabling

     • iii. Tamper-evident seals should be used to detect unauthorized access

   • h. Water and Leak Detection:

     • i. Water detection systems should be implemented with real-time alerts

     • ii. Physical barriers and waterproofing measures should be installed to prevent water ingress

     • iii. Infrastructure should be regularly inspected and maintained to identify potential water-related risks

     • iv. Periodic drills should be conducted for responding to water-related emergencies

   • i. Telecommunications and Internet Connectivity

     • i. Physical access to telecommunications and internet infrastructure should be restricted to authorized personnel only

     • ii. Tamper-evident seals and alarms should be used to detect unauthorized access to telecommunications/internet equipment

     • iii. Internet and networking equipment should be regularly updated and patched to address security vulnerabilities

     • iv. Reputable telecommunications service providers should be vetted and selected with a focus on security

   • j. Redundant telecommunications and internet failover mechanisms should be implemented to switch between different communication paths in case of a failure

   • k. Continuous Monitoring and Evaluation: The effectiveness of utilities services security controls should be continuously monitored, evaluated and updated to adapt to evolving security threats and technological advancements

[All Actors except AIC]

1. Providers should test utility services that power data centres that perform sensitive tasks such as training, data processing, inference to ensure continual effectiveness on a periodic basis.

2. Providers should establish comprehensive environmental control systems that address the specific environmental conditional such as temperature and humidity requirements of AI computing hardware.

3. Implement multi-tiered monitoring systems with real-time dashboards and automated alerts for deviations that might impact system performance.

4. Develop documented emergency protocols for environmental failures, including graceful degradation and workload shifting capabilities.

5. Create redundant cooling and power systems with N+1 redundancy for critical AI workloads.

6. Conduct regular effectiveness testing and maintenance of all environmental controls, with quarterly performance analysis to optimize for both reliability and energy efficiency.

DCS-16: Equipment Location

Control Specification

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

Shared Implementation Guidelines

[All Actors except AIC]

1. Providers should isolate critical equipment that contains data centres that perform business sensitive tasks, such as training, data processing away from environment related risks such as flooding, tornadoes, etc.

2. Providers should implement a strategic approach to select equipment location that minimizes environmental failure risks to critical systems.

3. Conduct comprehensive environmental and geological risk assessments before selecting datacenter locations, ensuring facilities avoid flood zones, seismic risk areas, and regions prone to extreme weather events. Implement geographic diversity with distributed infrastructure across multiple regions, preventing any single environmental event from disrupting essential AI services.

4. Establish continuous environmental monitoring with predictive capabilities to anticipate potential hazards.

5. Develop formal business continuity plans with specific protocols for equipment protection during environmental emergencies. Regularly review and update risk profiles considering evolving climate patterns.

Implementation Guidelines for Cloud Service Providers (CSP)

Role Specific CSPs face various challenges in protecting their infrastructure from environmental and man-made risks, such as natural disasters, cyberattacks, and power outages. These risks can cause significant downtime, data loss, and financial damage to businesses.

To mitigate these risks, CSPs should implement a comprehensive strategy that includes (but is not limited) the following best practices:

• a. Environmental Risk Assessment:

  • i. A risk assessment should be conducted to identify potential natural environment risks in different geographical locations (e.g., fires and flooding (waterlogging, water pipe exposure), dust, wind (exposure to open doors/windows), atmospheric electrical discharge, solar induced geomagnetic storm, and natural disasters (earthquake, tsunami, volcanic activity, mudslide, tectonic activity))

  • ii. Man-made risks and factors should be considered, such as industrial activities, geopolitical stability, and proximity to critical infrastructure (e.g., deliberate attacks include fire, flood, nuclear accident, biological hazard, civil unrest)

• b. Site Selection Distance from High-Risk Areas:

  • i. Datacenter locations should be selected in regions with a lower probability of natural disasters (coastal zones susceptible to storm surges or flood-prone regions)

  • ii. Areas prone to man-made risks, including those with a history of industrial accidents, political instability, or civil unrest should be avoided

  • iii. A safe distance from critical infrastructure like power plants, chemical facilities, and transportation hubs should also be maintained

• c. Geographic Diversity:

  • i. Data centers should be established in geographically diverse locations to mitigate the impact of region-specific risks

  • ii. No two data centers should be placed in close proximity to minimize the likelihood of simultaneous disruptions

• d. Zoning and Land Use Planning:

  • i. Collaboration with local authorities should be established for adherence to zoning regulations and land use planning to avoid areas with known environmental or safety risks

  • ii. Future developments and urban expansion should be considered when selecting a site

• e. Topography: Locations with favorable topography should be assessed and selected (e.g., elevated ground to reduce the risk of flooding or water-related disasters, local terrain factors like drainage and susceptibility to seismic activity)

• f. Regulatory Compliance: Compliance with local and international regulations governing the construction and operation of data centers should be established and maintained

• g. Emergency Preparedness and Response: Emergency preparedness and response plans tailored to the specific risks of each location should be developed and regularly updated

• h. Insurance Coverage: Insurance coverage for potential risks associated with the chosen locations, including environmental disasters and business interruption should be obtained

• i. Supplier and Vendor Evaluation: The resilience of critical suppliers and vendors, such as power providers and network carriers should be evaluated to ensure they are also located in low-risk areas

• j. Continuous Monitoring and Evaluation: A continuous monitoring program to assess the ongoing suitability of chosen locations should be implemented and risk assessments and mitigation strategies regularly reviewed and updated according to changes in regulations that may impact the chosen location

[All Actors except AIC]

1. Providers should isolate critical equipment that contains data centres that perform business sensitive tasks, such as training, data processing away from environment related risks such as flooding, tornadoes, etc.

2. Providers should implement a strategic approach to select equipment location that minimizes environmental failure risks to critical systems.

3. Conduct comprehensive environmental and geological risk assessments before selecting datacenter locations, ensuring facilities avoid flood zones, seismic risk areas, and regions prone to extreme weather events. Implement geographic diversity with distributed infrastructure across multiple regions, preventing any single environmental event from disrupting essential AI services.

4. Establish continuous environmental monitoring with predictive capabilities to anticipate potential hazards.

5. Develop formal business continuity plans with specific protocols for equipment protection during environmental emergencies. Regularly review and update risk profiles considering evolving climate patterns.

DCS-17: Datacenter Metrics

Control Specification

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

Shared Implementation Guidelines

[All actors]

1. Organizations should define, monitor, and report security-relevant metrics to evaluate the protection and reliability of infrastructure supporting AI systems.

2. Metrics should include indicators of physical and environmental conditions, infrastructure availability, access control events, hardware and platform health, and configuration integrity.

3. Organizations should monitor for deviations from approved configurations, patch levels, and security baselines that could impact the confidentiality, integrity, or availability of data center assets and services.

4. Metric thresholds, alerting mechanisms, and reporting processes should be defined, reviewed periodically, and integrated into operational response and risk management workflows.

Implementation Guidelines for Cloud Service Providers (CSP)

1.Cloud Service Providers should monitor comprehensive physical, environmental, and infrastructure security metrics across all facilities and platforms supporting AI workloads.

1. Metrics should include physical access events, power and cooling stability, hardware failures, network performance, and configuration integrity across compute, storage, and network services.

2. Providers should monitor for deviations from approved security baselines and platform configurations, and use automated analytics to identify emerging risks.

3. Metrics should be centrally analyzed and integrated into operational response, resilience planning, and customer assurance reporting.

From CCM v4.1: Control Ownership Rationale. The CSP is typically responsible for the implementation of this control. The CSP has the authority, insight, tools, and operational control on datacenter security metrics. These metrics enable the CSP to monitor performance, continuously improve reliability and resilience, plan for capacity and scalability, ensure security and compliance, enhance customer satisfaction, optimize resources, and support data-driven decision-making. The CSC lacks visibility, has limited accountability and control over the data center, making this primarily the responsibility of the CSP.

Implementation Guidelines. Applicable to all service models:

• a. Define security objectives and scope of the data center security metrics program by identifying critical assets (i,e., servers, network devices, storage, power systems).

• b. Determine threat vectors such as physical intrusion, unauthorized access, cyber threats, environmental risks to the critical assets.

• c. Determine the essential security metrics that are crucial for safeguarding datacenter assets and services, such as

  • i. Operational Security Metrics

    • Number of unauthorized access attempts.

    • Number of successful vs. failed access logins.

    • Number of security patches applied vs. pending.

  • ii. Infrastructure Security Metrics

    • Percentage of assets with up-to-date firmware/security patches.

    • Redundancy compliance (e.g., dual power/network paths).

    • Physical access control compliance (e.g., biometric, RFID).

• d. Set security goals by aligning each metric with SMART criteria:

  • i. Specific: Define exact goals (reduce intrusions by X%)

  • ii. Measurable: Use quantifiable indicators

  • iii. Achievable: Set realistic targets

  • iv. Relevant: Align with security strategy

• e. Time-bound: Include deadlines (e.g., within Y months)

• f. Set Thresholds and Benchmarks by

  • i. using historical data and industry standards.

  • ii. defining alert levels (green/yellow/red).

  • iii. adjusting thresholds dynamically based on workload patterns.

• g. Classify the metrics as Key risk Indicators (KRI), Key control indicators (KCI) and Key Performance Indicators (KPI) to help ensure datacenter’s metrics are effective, actionable and aligned with overall security goals.

  • i. Key risk indicators are metrics indicating potential risks (e.g., “Number of intrusions detected per month”).

  • ii. Key Control Indicator (KCI): Metrics indicating the effectiveness of controls (e.g., “Number of unauthorized access attempts blocked”).

  • iii. Key Performance Indicator (KPI): Metrics indicating overall performance (e.g., “Percentage of unauthorized access attempts blocked”).

• h. Establish a monitoring framework by selecting monitoring tools such as SIEM systems for centralized monitoring, IDS/IPS for real-time threat detection, and Network monitoring tools for traffic analysis. These tools could be cloud native, third party solutions or in-house built solutions.

• i. Automate data collection, monitoring and alerts.

  • i. Configure alerts for when metrics exceed pre-defined thresholds.

  • ii. Develop automated responses for common incidents such as blocking IP addresses after multiple failed login attempts. i. Assign Ownership: Define responsibilities for monitoring, reporting, and response.

• j. Provide periodic training on security metrics and their importance to relevant staff to promote data-driven decision making.

• k. Create reporting templates for consistent reporting of metrics.

• l. Schedule reports by establishing reporting schedules at agreed frequency.

• m. Build dashboards to visualize historical trends, real time performance and deviations to thresholds.

• n. Communicate results with stakeholders to use in operational reviews.

DCS-18: Datacenter Operations Resilience

Control Specification

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

Shared Implementation Guidelines

[All actors]

1. Organizations should define, implement, and evaluate processes, procedures, and technical measures to ensure the continuous operation of infrastructure supporting AI systems.

2. Resilience planning should address redundancy, fault tolerance, backup and recovery, and disaster recovery capabilities appropriate to the organization’s risk profile and service criticality.

3. Operational resilience measures should be tested periodically, validated through exercises or failover events, and updated based on changes to infrastructure, workloads, and threat conditions.

4. Dependencies on external service providers should be identified, defined and incorporated into continuity planning.

Implementation Guidelines for Cloud Service Providers (CSP)

1. Cloud Service Providers should design infrastructure with redundancy in aspects such, as, but not limited to, power, cooling, network, and compute layers, to support continuous operations of AI workloads.

2. CSPs should implement geographically distributed facilities, automated failover mechanisms, and disaster recovery capabilities appropriate to service criticality.

3. Operational resilience programs should include regular testing of recovery procedures, validation of redundancy controls, and continuous improvement based on incident analysis.

4. CSPs should provide customers with transparency into resilience capabilities and service continuity commitments.

From CCM v4.1: Control Ownership Rationale. The Cloud Service Provider (CSP) holds primary responsibility for establishing and managing the operational processes, procedures, and technical controls necessary to maintain uninterrupted data center services. The CSP has the authority and control over the infrastructure, while the Cloud Service Customer (CSC) has limited visibility and responsibility, making this a core responsibility of the CSP.

Implementation Guidelines. Applicable to all service models: To ensure continuous operations of data centers, organizations should follow a layered approach that combines technical, procedural, and security-focused actions.

• a. Define requirements and scope by:

  • i. Identify systems, services, and data that need high availability.

  • ii. Identify critical assets and prioritize based on business impact and compliance.

  • iii. Identify weak points. Map single points of failure and system dependencies.

• b. Strengthening Data Resiliency

  • i. Replicate Data: Use synchronous and asynchronous replication across regions.

  • ii. Automate Backups: Follow the 3-2-1 rule—3 copies, 2 media types, 1 offsite.

  • iii. Protect Data Integrity: Use checksums, versioning, and immutability.

• c. Building Redundancy

  • i. Compute: Use clusters or auto-scaling groups to avoid single-node failures.

  • ii. Storage: Implement RAID and distributed file systems.

  • iii. Network: Add redundant NICs, switches, and multi-path routing.

  • iv. Power & Cooling:

    • Use dual power supplies, UPS, and backup generators.

    • Install redundant cooling systems and monitor environmental conditions.

• d. Communication:

  • Use multiple ISPs or SD-WAN.

  • Set up failover for internal messaging and alerts. vi. Geographic Redundancy:

  • Deploy systems across multiple regions or availability zones.

  • Use geo-redundant storage and multi-region failover. vii. Application-Level Redundancy:

  • Use active-active or active-passive setups.

  • Add load balancers to manage traffic and detect failures. viii. Use Advanced Redundancy Techniques

  • JVM-Level: Distribute logic and data across N+1 JVMs.

  • Machine-Level: Spread workloads across N+1 virtual or physical machines.

  • Zone-Level: Add redundancy across server racks, power sources, and subnets.

  • Geographical: Operate in multiple regions to handle regional outages.

  • In-RAM Sync: Enable hot in-memory failover.

  • SSD Persistence: Combine RAM speed with SSD durability.

  • Asynchronous Replication: Use mirror services for external backups and replicate across clusters to protect against regional failures.

• e. Plan Fault Tolerance and Disaster Recovery

  • i. Use Fault Tolerance: Add error detection, failover, managed service degradation, and isolation.

  • ii. Plan for Recovery: Maintain physical or cloud-based disaster recovery sites. Test and update plans regularly.

• f. Integrate Cybersecurity

  • i. Encrypt Data: Protect data in transit, at rest, and in use.

  • ii. Control Access: Use strong authentication and role-based access.

  • iii. Prepare for Incidents: Develop and test response plans.

  • iv. Ensure Immutability: Protect backups and logs from tampering.

• g. Use air-gapped backups by keeping critical data offline vi. Audit Regularly: Run security audits and penetration tests.

• h. Monitoring, Automation, and Continuous Improvement

  • i. Monitor Continuously: Track system health, replication lag, and failover events. Use synthetic monitoring to simulate user experience.

  • ii. Automate Responses: Automate scaling, failover, and recovery.

  • iii. Analyze Incidents: Perform root cause analysis and update systems based on lessons learned.

  • iv. Improve Continuously: Reassess needs and benchmark against best practices.

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.

Shared Implementation Guidelines

[All Actors]

1. To include establishing below policies and procedures (in line with all relevant legal requirements and standards):

   • a. Data Governance Framework: Establish roles, responsibilities, and processes for managing data across AI lifecycle.

   • b. Data Stewardship Policy: Designate data stewards to oversee the quality, integrity, and compliance of data.

   • c. Data Minimization: AI systems should access only the minimal amount of data necessary to perform their functions, avoiding the storage or use of customer prompts and completions for model retraining.

   • d. Data Cataloging: Maintain an updated catalog of all data used by AI systems, including storage locations and access details.

   • e. Data Residency: Offer data residency options to comply with regional data privacy regulations, allowing customers to store their data within specific geographic locations.

   • f. Data Access Controls: Implement strict access controls to ensure that only authorized users can access sensitive data used in AI systems.

   • g. Data Lifecycle Management: Define policies to address the AI data lifecycle, including generation, collection, storage and management, processing (data cleaning, transformation, annotation and labeling, integration, and validation), and disposal after a governance-defined period of inactivity.

   • h. Data Quality Policy: Ensure data integrity, accuracy, and completeness. Regularly audit and clean data to maintain high standards, for example in line with ISO/IEC 5259, ISO 25012 and ISO 8000

   • i. Transparency and Accountability Policy: Promote transparency in data practices and ensure accountability through regular reporting and audits.

Implementation Guidelines for Cloud Service Providers (CSP)

1. Policy Development & Documentation

   • Develop comprehensive data lifecycle policies that reflect: o Cloud-native storage and compute characteristics o Multitenancy and virtualized data handling risks

   • Map policy requirements to global standards (e.g., ISO/IEC 27018, GDPR, CCPA, HIPAA).

   • Define lifecycle stages clearly: creation, use, transfer, retention, archival, and deletion.

2. Data Classification Enablement

   • Provide built-in or integrated services that allow customers to: o Classify data by sensitivity (public, confidential, restricted) o Tag data assets automatically (e.g., AWS Macie, Google DLP)

   • Enforce tagging policies via infrastructure as code and governance templates.

3. Protection & Access Controls

   • Offer default and customizable encryption-at-rest and in-transit for all storage services.

   • Provide granular access control mechanisms (IAM roles, attribute-based access control).

   • Support BYOK or HSM integrations for customer-managed key encryption.

4. Data Handling & Residency

   • Allow configuration of regional storage and data residency controls.

   • Offer options to restrict data movement across regions or services, in compliance with local laws.

5. Lifecycle Management Automation

   • Deliver features to automate: o Retention enforcement (e.g., S3 lifecycle rules, Azure Blob retention policies) o Archiving to cold storage o Secure deletion mechanisms (including cryptographic erasure)

6. Compliance & Auditing Tools

   • Offer tools and dashboards for: o Monitoring data lifecycle states o Audit logging (e.g., CloudTrail, Azure Monitor) o Compliance assessments (e.g., AWS Audit Manager, GCP Assured Workloads)

7. Policy Review Support:

   • Provide customer alerts or service recommendations to: o Review and update data management policies annually, or upon significant system changes, o Address new regulatory or industry compliance requirements

   • Enable versioning of policy templates or configuration artifacts to track updates and history.

8. Security & Risk Monitoring

   • Implement continuous monitoring services to detect: o Anomalies in data access patterns o Policy misconfigurations o Data exfiltration attempts Provide customers with automated remediation suggestions or guardrails.

[All Actors]

1. To include establishing below policies and procedures (in line with all relevant legal requirements and standards):

   • a. Data Governance Framework: Establish roles, responsibilities, and processes for managing data across AI lifecycle.

   • b. Data Stewardship Policy: Designate data stewards to oversee the quality, integrity, and compliance of data.

   • c. Data Minimization: AI systems should access only the minimal amount of data necessary to perform their functions, avoiding the storage or use of customer prompts and completions for model retraining.

   • d. Data Cataloging: Maintain an updated catalog of all data used by AI systems, including storage locations and access details.

   • e. Data Residency: Offer data residency options to comply with regional data privacy regulations, allowing customers to store their data within specific geographic locations.

   • f. Data Access Controls: Implement strict access controls to ensure that only authorized users can access sensitive data used in AI systems.

   • g. Data Lifecycle Management: Define policies to address the AI data lifecycle, including generation, collection, storage and management, processing (data cleaning, transformation, annotation and labeling, integration, and validation), and disposal after a governance-defined period of inactivity.

   • h. Data Quality Policy: Ensure data integrity, accuracy, and completeness. Regularly audit and clean data to maintain high standards, for example in line with ISO/IEC 5259, ISO 25012 and ISO 8000

   • i. Transparency and Accountability Policy: Promote transparency in data practices and ensure accountability through regular reporting and audits.

From CCM v4.1: Control Ownership Rationale. The implementation responsibility for this control is shared and independent for the CSP and CSC, since both CSP and CSC need to independently establish policies and procedures for data lifecycle management as part of their organization’s overarching data governance framework.

Implementation Guidelines. Applicable to all service models: The CSP should include in its policies and procedures a comprehensive framework for the classification, privacy, protection, and handling of data throughout its lifecycle. This includes clearly defined data storage criteria and secure data disposal practices. The policy should emphasize compliance with relevant regulations, periodic security audits, and continuous monitoring to ensure the security of customer data.

Policies should include (but not limited to) provisions on the following:

• a. Scope and Objectives:

  • i. The scope and objectives of the policy and what it should achieve

  • ii. Formal approval by Executive Management, Leadership Committee (EXCO) and/or Board level members

  • iii. All the phases of the data/information lifecycle including but not limited to Collection, Creation, Transmission, Storage, Usage, Sharing/Disclosure, Retention/Archival and Destruction

  • iv. The relevant entities and jurisdictions and/or geographical regions that the organization operates in

• b. The relevant regulations or applicable industry standards that are applicable to the entity vi. Stakeholders who will be either the owners or custodians/stewards of data (e.g. stakeholders include customers, business partners, third parties, employees) vii. Requirements for communicating the policy to all relevant stakeholders. Communication of policies and procedures can be handled via methods such as electronic digital mailers (EDMs) sent to all staff or via e-learning platforms viii. Alignment to company code, objectives and values (i.e., trust management)

• c. Data Classification: Data classification policies and procedures should include the following:

  • i. Data classification and labeling of data with clear definitions and examples (e.g., Public, Internal, Restricted, Confidential)

  • ii. Asset valuation of the asset that could potentially store or process the data (e.g., Asset Valuation Ratings such as High, Medium, and Low mapped against Confidentiality, Integrity; availability and impacts such as Financial, Reputational, Customer Service, Operational, and Regulatory. The ratings should be decided based on the label applicable to the data/dataset and the overall risk it represents) (refer to DCS-05)

  • iii. Acceptable Use Agreements (AUAs) should be communicated and signed by all relevant stakeholders, especially before employee/personal onboarding. The AUA should be a declaration that confirms awareness and willingness to protect data

  • iv. Technologies that either label data/information automatically at various layers of the infrastructure (e.g., email gateway, end Point) or allow an end user to specifically choose classification should be considered for implementation

• d. Data and asset classification should occur before a technology asset or service is being designed and is eventually placed into production. An asset value rating should be assigned to every asset in the inventory vi. All data and its associated assets should be accounted for (i.e., a Data and asset inventory should exist) vii. A Responsible, Accountable, Consulted, and Informed (RACI) matrix that specifies the task of each role or individual that will act as either data owner, steward/custodian or processor viii. Data flow diagrams should be available to understand how specific data elements flow through the ecosystem and where they are stored and/or processed

Note: From a control implementation perspective, the CSP should offer Cloud Access Security Broker (CASB) solutions that are able to classify and label data based on known regulations (e.g., HIPAA, PCI-DSS) or custom rules (e.g., financial or proprietary data), and DLP.

• a. Data Privacy: Data Privacy policies and procedures should include the following:

  • i. Data minimization, specifically during the collection of data for the purposes of ensuring alignment to privacy regulations

  • ii. Privacy notices covering what data will be collected, how it will be used, who will have access to the data, with whom it will be shared or disclosed (including third parties), how long it will be retained, and how it will be protected. From an implementation perspective, privacy notices can take the form of pop-ups, banners, layered notices, or similar

  • iii. Additional concepts such as Consent, Choice, Collection Limitations, Data Quality, Reliable Sources, Primary & Secondary Uses, and Internal and External Disclosure

  • iv. Data subject access and under what conditions it will be provided (i.e., how data subjects can access and/or export their data and how they can contact the organization with questions or concerns around privacy)

• b. Data Handling & Protection: Data handling & protection policies and procedures should include the following:

  • i. Data protection controls should be commensurate with the classification of data, its associated label, and the overall value of the asset that stores or processes the data (where required approvals are taken), including and not limited to all types of data (e.g., personal data, sensitive data)

  • ii. Logical controls including but not limited to encryption of data in storage & in transit, use of Trusted Execution Environments (TEEs) for data in use, authentication, authorization (access control and permissions), audit trails, digital rights management (DRM), data leak prevention (DLP), outbound proxy, SSL/TLS bypass, database access management (DAM), anonymization, tokenization, and pseudonymization.

Note: types of encryption, algorithms, key sizes, and key management should be referenced in the Cryptography, Encryption & Key Management domain of the CCM.

iii. Physical controls including but not limited to the physical access controls such as locks and keys, biometrics, smart cards, and mandatory dual control for opening fireproof safes iv. Environmental controls including but not limited to protection against extreme temperatures, humidity, fire, and other acts of nature

• a. Additional controls including but not limited to protection against acts of war (e.g., terrorism, biological or chemical warfare) vi. Data handling controls for all types of data, hard copies and/or digital vii. Protection of data on different types of devices including but not limited to end points, servers, mobile devices, removable (e.g., USB drives, SD cards) and backup media (e.g., encryption of backup tapes) viii. Business Continuity and disaster recovery measures that will ensure confidentiality, integrity and availability of data (e.g., the use of special air-gapped vaults to recover from ransomware attacks, tapes off site, recovery from hot, warm, or cold sites, and regular recovery testing) ix. Approach to external security testing, vulnerability assessment and certifications

• b. Approach to risk management and shared responsibilities xi. Approach to manage security incidents and data breach notifications.

• c. Data Storage & Retention: Data Storage & Retention policies and procedures should include the following:

  • i. The length/period of time the data will be retained as per laws, regulations and business requirements

  • ii. Type of data including but not limited to customer data, backups, audit logs, and any data that can assist with forensic investigations

  • iii. Requirements to collect and retain evidence, hardcopy records, monitoring, and recording mechanisms

  • iv. Handling chain of custody which includes prevention of manipulation of records

• d. Be aligned with the organization’s topic-specific policy on records management and other records requirements vi. Be chosen such that required records can be retrieved in an acceptable time frame and format, depending on the requirements to be fulfilled vii. Storage and handling procedures are implemented in accordance with recommendations provided by manufacturers of storage media. Consideration should be given to the possibility of deterioration of media used for storage of records viii. Handling of metadata describing the context, content and structure of records, as well as their management over time

• e. Data Destruction: Data Destruction policies and procedures should include the following:

  • i. The conditions under which data will be destroyed including but not limited to termination of service by the CSC, automatic deletion after a specific period (e.g., 30 days) where applicable or when requested by the CSC or storage device has reached end of life

  • ii. The specific methods that will be used to destroy data (e.g., cryptographic erasure, writing zeros, degaussing, physical destruction or as per media sanitization guidelines)

• f. Approval: Approval requirements and senior management involvement to ensure alignment with the organization’s strategic goals and risk appetite

  • i. An approval process should be established for any changes or modifications to the policy and procedures

  • ii. A documented record of approvals (including dates, names of approvers, and any relevant comments or discussions) should be maintained

• g. Communication: Effective communication of the policy and procedures should be facilitated to all relevant cloud stakeholders

• h. Maintenance and Reviews: Policies and procedures for the classification, protection and handling of data should be documented, reviewed and updated at least annually to ensure alignment with evolving cloud security landscape and to reflect changes in cloud technology, regulations, and risks.

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.

Shared Implementation Guidelines

[All Actors]

1. Dispose of cached inference results and log files the actor retains using approved secure-deletion methods.

2. Purge any user sessions, logs and outputs once the defined retention period expires for data the actor stores or processes.

3. Ensure business- or user-data deletion aligns with compliance obligations for the systems the actor controls.

4. Enable and execute secure-wipe / cryptographic-erasure lifecycle policies.

[Shared among: MP, CSP, OSP]

1. Delete training/validation data and embeddings post-use or repurpose for models the actor trains or fine-tunes.

Implementation Guidelines for Cloud Service Providers (CSP)

1. Establish a Secure Data Disposal Policy: Define and publish a formal policy for secure data disposal, aligned with:

   • Guidelines for Media Sanitization (e.g. NIST SP 800-88 Rev. 1)

   • Storage Security (e.g. ISO/IEC 27040)

   • Classify data types (e.g., temporary, long-term, sensitive) and map to disposal procedures.

2. Automated Secure Deletion Mechanisms: Implement built-in storage lifecycle management tools that automate data expiration and deletion (e.g., AWS S3 Lifecycle Policies, Azure Blob Soft Delete and Retention). Ensure the disposal method includes: Cryptographic erasure (deletion of encryption keys rendering data unreadable). Zeroing out of blocks on SSDs or HDDs (for sensitive workloads)

3. Cryptographic Erasure as a Default Disposal Practice:

   • Encrypt all stored data by default.

   • On deletion, destroy encryption keys associated with data rather than the data itself—this is fast, secure, and irreversible.

   • Maintain logs of key destruction operations for audit purposes.

4. Physical Media Sanitization & Destruction: When retiring physical hardware:

   • Perform secure wipe using DoD 5220.22-M or similar tools.

   • Degauss, shred, or incinerate storage media. Maintain chain-of-custody documentation for physical destruction. Use third-party certified e-waste recyclers where applicable, ensuring compliance with R2 or e-Stewards standards.

5. Independent Auditing and Certification: Undergo third-party audits of data destruction processes and physical security. Obtain certifications such as: For example ISO/IEC 27001, SOC 2 Type II (with focus on data destruction controls), PCI DSS (requires secure media destruction for payment data environments).

6. Customer Visibility & SLAs: Provide customers with:

   • Assurance documentation about how their data is disposed of

   • Data lifecycle control APIs (e.g., setting object expiry, manual delete commands) Include secure disposal commitments in Service Level Agreements (SLAs).

7. Incident Logging & Forensic Assurance:

   • Log every data deletion event and make logs available for customer audit on request.

   • Perform internal validation or red-teaming exercises to test recoverability of deleted data. Document forensic analysis results to prove irrecoverability.

[All Actors]

1. Dispose of cached inference results and log files the actor retains using approved secure-deletion methods.

2. Purge any user sessions, logs and outputs once the defined retention period expires for data the actor stores or processes.

3. Ensure business- or user-data deletion aligns with compliance obligations for the systems the actor controls.

4. Enable and execute secure-wipe / cryptographic-erasure lifecycle policies.

[Shared among: MP, CSP, OSP]

1. Delete training/validation data and embeddings post-use or repurpose for models the actor trains or fine-tunes.

From CCM v4.1: Control Ownership Rationale. The implementation responsibility for DSP-02 is Shared and both CSP and CSC need to implement it. This is due to the fact that either CSP or CSC may, depending on their unique requirements (e.g., regulation, end of life of storage media) may be required to securely dispose of data from storage media.

This control is also Dependent since the CSP is expected to have the technological capability that supports industry accepted methods of deleting data in a way that is not retrievable when requested by the CSC, or when a storage device is at the end of its lifetime and needs to be decommissioned.

Implementation Guidelines. Applicable to all service models:

• a. Data Disposal Authorization: Establish authorization procedures for data disposal requests. Only authorized personnel should be able to initiate and approve such requests

• b. Restrict Access after Disposal Request: the CSP should disallow any new attempts to access data once the request for data deletion has been submitted and approved

• c. Data Disposal Options: Explore various data disposal options and select the most appropriate method based on data sensitivity, media type and regulatory requirements

• d. Off-Premise Transport Restriction: Data media storage should not be permitted to leave the organization’s premises nor be transported out of the CSP’s datacenters without being sanitized or destroyed

• e. Data Destruction: Prior to physical media disposal, all data stored on such media must be completely destroyed using industry-approved methods. Implement secure data erasure procedures to render data irretrievable from storage devices. This may include physical destruction of media (e.g., hard drives demagnetization, paper shredding, etc.), data cryptographic erasure, or software-based erasure methods

• f. Cryptographic Erasure:

  • i. utilize encryption to render data irretrievable, by encrypting the data and then destroying the encryption key.

  • ii. the CSP should make sure that key material (including but not limited to keys, seeds, initialization vectors) is deleted in a forensically sound manner

• g. Data Sanitization: as part of the decommissioning process or based on requests by the CSC for data deletion, a secure logical or physical data deletion method on media should be used (including but not limited to zeroization, cross-cut shredding, degaussing, incineration, or pulverizing) based on industry accepted practices such as those specified in NIST SP 800-88 Guidelines for Media Sanitization, or methods such as DOD 5220.22-M

• h. Verification of Data Destruction: Require a systematic process for verifying the successful and complete destruction of data on decommissioned media through a documented and auditable verification mechanism

• i. Certification of Equipment Disposal Vendors: Use certified data disposal vendors who adhere to recognized industry standards and provide documentation certifying the proper disposal of data

• j. Disposal Record-Keeping and Auditing: Maintain detailed records of all data disposal events into a tracking system with a digital certificate of media disposition that clearly indicates whether they have been cleared, purged, or destroyed. Records should include the date, type of data, disposal methods, dates of disposal, authorized personnel involved and verification results for audit and compliance purposes

• k. Disposal of Active and Back Up Data: data should be deleted from both active and backup storage media including but not limited to locations where temporary and obsolete files are stored

• l. Change Management for Data Disposal: all secure data disposal processes should only be carried out using a well-defined change management approval process

• m. Compliance with Data Privacy Regulations: Ensure that data disposal processes comply with all applicable data privacy regulations, such as the General Data Protection Regulation (GDPR) or the California Consumer Privacy Act (CCPA).

• n. Periodic Audits and Reviews: Establish a schedule for periodic audits and reviews of data disposal processes, including both physical media disposal and data destruction, to ensure ongoing compliance and effectiveness.

Note: Active storage systems are production servers, while backup storage systems are full or incremental backups/copies of active storage systems.

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.

Shared Implementation Guidelines

[All Actors]

1. Inventory data moving between services or cached within the environment the actor controls.

2. Classify and track prompt / response data tied to users that the actor stores or processes.

3. Inventory customer data used in AI workflows that the actor handles.

4. Enable classification, discovery and tagging at the storage level.

[Shared among: MP, OSP, CSP]

1. Maintain metadata & lineage for training / test / fine-tuning data.

Implementation Guidelines for Cloud Service Providers (CSP)

1. Develop a Cloud-Native Data Inventory Framework

   • Implement a framework that enables: o Automatic discovery of data across storage, databases, backups, and logs. o Cataloging of metadata (e.g., file owner, location, sensitivity tag, access logs).

   • Inventory scope should include: o CSP-managed PII (e.g., user profiles, billing info) o Tenant-managed PII stored on the CSP platform (if applicable to shared infrastructure)

2. Enable and Promote Data Classification Services

   • Provide native services (e.g., AWS Macie, Azure Purview, Google Cloud DLP) that: o Automatically scan and identify PII and sensitive data (e.g., credit card numbers, names, SSNs) o Label data with standardized classification tags o Support regex, ML-based, and contextual pattern matching

3. Support Customer Inventory Compliance Needs

   • Provide APIs, dashboards, and logs to help customers: o View, export, and maintain data asset inventory o Assign tags, owners, and processing purposes o Enable integration with external governance tools or data catalogs

   • Offer event-driven updates when new sensitive data is uploaded or modified.

4. Inventory Management of CSP Internal Data

   • For CSP’s own sensitive data (e.g., logs containing customer identifiers): o Maintain internal registries for audit and compliance o Define retention periods and ownership of collected PII (e.g., telemetry, usage data) o Log access and modification events related to internal sensitive data

5. Integrate with Identity and Access Controls

   • Link data inventory records to access policies: o Enforce least privilege access based on classification o Support access review workflows tied to sensitive data locations

   • Enable alerting on unauthorized access or anomaly detection (e.g., accessing untagged PII)

6. Auditability & Lifecycle Logs

   • Maintain detailed logs of: o Data discovery scans o Classification updates o Access to data inventory reports

   • Provide audit trails for regulators and customers, in alignment with GDPR/CCPA/ISO 27018.

7. Ongoing Review and Update Process

   • Automate periodic scans to: o Detect newly introduced data types or stores o Revalidate classifications Set up review cycles for accuracy of inventory and tag mapping (quarterly or annually).   [All Actors]

8. Inventory data moving between services or cached within the environment the actor controls.

9. Classify and track prompt / response data tied to users that the actor stores or processes.

10. Inventory customer data used in AI workflows that the actor handles.

11. Enable classification, discovery and tagging at the storage level.

[Shared among: MP, OSP, CSP]

1. Maintain metadata & lineage for training / test / fine-tuning data.

From CCM v4.1: Control Ownership Rationale. This control ownership and implementation responsibility is defined as “Shared (Dependent)” because both parties are responsible for performing and maintaining a data inventory. The CSP needs to maintain an inventory for the CSC’s customer data (where applicable and possible) and cloud derived data, while the CSC needs to maintain an inventory, at least, for sensitive and/or personal data.

The control is Dependent since the CSC will depend on the technical capabilities available of the CSP to perform a critical data inventory activity, known as data discovery. Also, the CSP may require access to the CSC’s sensitive or personal data in the event of responding to a legal request, including for e-discovery.

Implementation Guidelines. Applicable to all service models: A comprehensive inventory of data fields (henceforth known as data inventory) should be created and maintained, at least for the data that is labeled “sensitive” or “personal data” (e.g., biometric data) throughout the entire lifecycle of data. It should also include data required to respond to compliance requests. The data inventory should:

• a. explicitly identify the CSC data and CSP-derived data

• b. provide visibility into the location (e.g., identification of the cloud service), volume, and context of sensitive and personal data. This can be done using methods such as data discovery or regular audits

• c. cover data types including but not limited to structured (e.g., stored in databases) and unstructured (e.g. stored in files, emails) data and metadata

• d. be used to identify which data is difficult to identify, export, or delete

• e. detail how sensitive and personal data is used, who has access to it, who it is shared with, the geographical location it is stored, and how long it will be retained

• f. track data movement as it travels within, across, or outside the organization (e.g., at third parties, business partners, vendors)

• g. state how data is being protected and who is responsible for data protection within the organization

• h. include a data inventory matrix as an initial master list, and an automated batch process should run daily or under certain conditions, including but not limited to system architecture changes, changes in the classification of the data, changes in the risk posture based on storage, transmission or processing of such data, or changes in laws and regulations, to update the data inventory on a regular basis

DSP-04: Data Classification

Control Specification

Classify data according to its type, criticality and sensitivity level.

Shared Implementation Guidelines

[All Actors]

1. Define and apply a data-classification scheme to every data object the actor stores or processes.

2. Attach and preserve classification metadata on data objects and flows and ensure that metadata follows the data through its lifecycle.

3. Apply appropriate protection controls, according to the assigned classification.

4. Maintain a classification register and review it at least annually or after material change, updating controls when data sensitivity/criticality or regulatory scope changes.

[Shared among : MP, OSP, CSP]

1. Classify and maintain lineage for all training, test and fine-tuning datasets and model artifacts.

Implementation Guidelines for Cloud Service Providers (CSP)

1. Develop a Data Classification Policy Framework

   • Define classification levels for both CSP internal data and customer-facing classifications, such as: o Sensitivity (Public, Internal Use, Confidential, Restricted (e.g., PII, PHI, payment data)), o Criticality (Non Critical, Medium Criticality, High Criticality, Business/Mission Critical),

   • Map these classifications to handling and protection requirements (e.g., access control, encryption, retention).

2. Offer Native Classification Services

   • Provide automated data classification tools integrated into your platform: o AWS Macie for S3 object inspection and PII detection o Azure Purview / Microsoft Purview for structured and unstructured data classification o Google Cloud DLP for content inspection and policy-based classification

   • Enable continuous scanning and classification of data in storage, databases, backups, and logs.

3. Support Metadata and Tagging Mechanisms

   • Allow customers to: o Attach metadata tags to objects (e.g., sensitivity level, owner, business unit) o Use policy-based tagging (e.g., auto-tagging based on file type or pattern match) o Enforce tagging via infrastructure as code (IaC) templates or APIs

4. Enable Policy-Driven Access Control by Classification

   • Allow integration of classification labels into: o Identity and Access Management (IAM) policies o Attribute-based access control (ABAC) mechanisms o Data loss prevention and endpoint protection policies

   • Example: Only users with clearance=restricted can access classification:restricted data.

5. Facilitate Compliance and Reporting

   • Provide dashboards and reports showing: o Data classification coverage across services o Unclassified or misclassified data volumes o Trends and risks by classification level

   • Enable exports to SIEMs or governance tools for compliance tracking (e.g., GDPR, HIPAA, CCPA).

6. Internal CSP Data Classification

   • Classify data used internally by the CSP (e.g., telemetry logs, user metadata, billing records) according to: o Operational sensitivity o Legal/regulatory exposure o Risk of data exposure

   • Enforce internal handling controls (retention, access restrictions, secure transfer).

7. Educate & Enable Customers

   • Provide best practice documentation and templates for: o Creating a classification schema o Automating classification across hybrid/multi-cloud environments o Linking classification to encryption and monitoring policies

   • Offer sample code and APIs to embed classification in CI/CD pipelines.

[All Actors]

1. Define and apply a data-classification scheme to every data object the actor stores or processes.

2. Attach and preserve classification metadata on data objects and flows and ensure that metadata follows the data through its lifecycle.

3. Apply appropriate protection controls, according to the assigned classification.

4. Maintain a classification register and review it at least annually or after material change, updating controls when data sensitivity/criticality or regulatory scope changes.

[Shared among : MP, OSP, CSP]

1. Classify and maintain lineage for all training, test and fine-tuning datasets and model artifacts.

From CCM v4.1: Control Ownership Rationale. The control ownership rationale for IaaS is “Shared (Independent)” since:

• The CSC has more control on IaaS, they can install any tool they wish to perform data classification and hence it is their sole responsibility for data managed on the infrastructure

• The CSP is required to classify data (e.g., cloud derived data) generated by the IaaS infrastructure.

The control ownership for IaaS is “Independent” because the CSP and CSC can classify independently depending on the data type (e.g., The CSP may want to classify log data / cloud derived data from IaaS services, while the CSC may want to classify sensitive or personal data which it stores on IaaS infrastructure).

The control ownership for PaaS and SaaS is Shared “Dependent” because: • The CSC has less control over the underlying infrastructure and has to depend on the CSP in order to provide tools that will classify data • The CSP is dependent on the CSC because it needs to classify cloud-derived data based on the interaction of the CSC with cloud services

Implementation Guidelines. Applicable to all service models:

• a. data classification and labeling of data with clear definitions and examples (e.g., Public, Internal, Restricted, Confidential) should exist. Labels should contain attributes for both security and privacy. Labeling standards such as Carnegie Mellon University: Guidelines for Data Classification and SANS Institute: Tagging Data to Prevent Data Leakage (Forming Content Repositories) should be considered

• b. Asset valuation could potentially store or process data (e.g.,asset valuation ratings such as High, Medium, and Low mapped against Confidentiality, Integrity, Availability, and Impacts such as financial, reputational, customer service, operational and regulatory) should exist. The ratings should be decided based on the label applicable to the dataset and the overall risk it represents

• c. technologies that either label data automatically at various layers of the infrastructure (e.g., email gateway, endpoint) or allow an end user to specifically choose classification should be considered for implementation

Note on Item c: From a control implementation perspective, the CSP should offer Cloud Access Security Broker (CASB) solutions that are able to classify and label data based on known regulations (e.g., HIPAA or PCI-DSS) or custom rules (e.g., financial or proprietary data) and perform Data Leak Prevention (DLP).

• a. data and asset classification should occur before a technology asset or service is being designed and placed into production. An asset value rating should be assigned to every asset in the inventory; cloud-derived data is an exception to this recommendation

• b. a RACI matrix that specifies the task of each role or individual that will act as either data owner, steward/custodian or processor should exist

• c. data protection controls should be commensurate with the classification of data, its associated label, the overall value of the asset that stores or processes the data and should include but not be limited to the following:

  • i. Logical Controls including but not limited to encryption of data in transit, authentication, authorization (access control and permissions), audit trails, digital rights management (DRM), DLP, outbound proxy, SSL/TLS bypass, database access management (DAM), anonymization, tokenization, and pseudonymization. Types of encryption, algorithms, key sizes, and key management should be referenced in the Cryptography, Encryption & Key Management (CEK) control domain

  • ii. physical controls including but not limited to the physical access controls such as locks & keys, biometrics, smart cards and mandatory dual control for opening fireproof safes & cameras

  • iii. environmental controls including but not limited protection against extreme temperatures, humidity, fire, and other acts of nature

  • iv. additional controls including but not limited to protection against acts of war (e.g., terrorism, biological or chemical warfare)

• d. Data Handling should include controls for all types of data, hard copies and/or digital

• e. protection of data on different types of devices including but not limited to end points, servers, mobile devices, removable (e.g., USB drives, SD cards ) & backup media (e.g. encryption of backup tapes)

• f. business continuity and disaster recovery measures that will ensure the confidentiality, integrity, and availability of data (e.g., the use of special air-gapped vaults to recover from ransomware attacks, tape off-siting, recovery from hot, warm, or cold sites, regular recovery testing

• g. data and asset classification review should occur at least annually or based on certain conditions, including but not limited to changes in the classification of the data or changes in laws and regulations

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.

Shared Implementation Guidelines

[All Actors]

1. Document inference pipelines, plugin flows and logs for all components the actor operates or manages.

2. Describe any user input / output flows, APIs and storage the actor designs or manages.

3. Map enterprise data sent to AI systems by the actor and validate flow compliance.

4. Offer infrastructure-flow visibility and document transfer / storage paths.

[Shared among: MP, OSP, CSP]

1. Map training / fine-tuning flow paths and outputs.

Implementation Guidelines for Cloud Service Providers (CSP)

1. Establish Internal CSP Data Flow Mapping

   • Maintain up-to-date data flow diagrams showing: o CSP-controlled PII and telemetry data (e.g., customer usage, billing data, logs) o Flow between regions, availability zones, services (e.g., object storage to analytics service)

   • Include metadata on: o Data type (e.g., customer account info, support tickets) o Purpose of processing o Storage/transit encryption o Third-party integrations

2. Enable Customer Data Flow Mapping

   • Provide tools/APIs to help customers visualize and document data flows across their cloud assets: o Network topology visualization (e.g., VPC, peering, firewalls) o Storage access and location (e.g., S3 buckets, blob storage, database regions) o Workflow integration across services (e.g., from ingestion to analytics to backup)

   • Support integration with CMDBs, asset inventories, or third-party GRC tools.

3. Tagging and Metadata for Flow Identification

   • Encourage tagging of data and services for: o Data owner o Business unit o Classification/sensitivity o Flow purpose

   • Use tags to auto-generate flow diagrams or integrate with policy engines.

4. Review and Update Mechanisms

   • Set internal review schedules for: o Annual reviews of internal and customer-exposed flow documentation o Post-change validation after architecture, region, or service changes

   • Support version-controlled documentation with change logs and approval workflows.

5. Support Regulatory & Cross-Border Requirements

   • Provide clarity on: o Geographic location of data storage and processing o Data transfer mechanisms (e.g., intra-cloud transfers, third-party interconnects) o Compliance with data residency laws (e.g., GDPR, PDPA, CCPA)

   • Offer features to restrict or log data movement across jurisdictions.

6. Logging and Monitoring

   • Enable logging and alerting for: o Unapproved data flow paths (e.g., unauthorized inter-region transfers) o Data flow anomalies or deviations from expected architecture o Provide real-time or scheduled reports on flow and volume metrics

7. Customer-Facing Transparency

   • Document and publish: o CSP’s own data handling practices o Service-specific flow diagrams showing how data is handled within a product (e.g., where backups or logs are stored) o Optional: Data flow templates customers can adapt

[All Actors]

1. Document inference pipelines, plugin flows and logs for all components the actor operates or manages.

2. Describe any user input / output flows, APIs and storage the actor designs or manages.

3. Map enterprise data sent to AI systems by the actor and validate flow compliance.

4. Offer infrastructure-flow visibility and document transfer / storage paths.

[Shared among: MP, OSP, CSP]

1. Map training / fine-tuning flow paths and outputs.

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.

Shared Implementation Guidelines

[All Actors]

1. Define and document data-ownership and stewardship policies for every dataset the actor stores or processes.

2. Maintain an up-to-date inventory (or lineage repository) of personal and sensitive data that records origin, transformations, current location, and designated owner / steward.

3. Implement traceability mechanisms—logs, metadata tagging, or equivalent—to follow data from ingestion to disposal within systems the actor controls.

4. Review and update ownership / stewardship documentation at least annually, or after significant changes, and assess compliance with those policies.

[Shared among: MP, OSP, CSP]

1. Maintain records of training and inference datasets containing personal or sensitive data, including associated ownership and usage-rights metadata.

Implementation Guidelines for Cloud Service Providers (CSP)

1. Define and Document Internal Ownership

   • Identify and document data owners and stewards for: o Customer account information o Support tickets o Logs, telemetry, monitoring, and billing metadata (that may contain identifiers)

   • Assign business units or roles responsible for: o Data accuracy and access o Classification and protection o Privacy and retention compliance

2. Create a Centralized Data Stewardship Registry

   • Maintain an internal data registry that maps: o Data categories (PII, sensitive, operational) o Locations (e.g., databases, log stores) o Owners (e.g., Privacy Officer, Compliance Team) o Stewards (e.g., Service/Engineering Team leads)

   • Tag each data element with its risk level, usage purpose, and regulatory context.

3. Perform Scheduled Reviews

   • Conduct annual reviews of the registry to validate: o Owner/steward assignments are up to date o Compliance with current regulations (e.g., GDPR, ISO 27701, CCPA)

   • Trigger off-cycle reviews upon: o New product launch or service update o Incident involving personal/sensitive data

4. Enable Customer Governance Capabilities

   • Provide features for customers to: o Assign and manage data ownership metadata through tagging or APIs o Use governance tools (e.g., Azure Purview, AWS Glue Data Catalog) to track data stewardship o Audit role-based access to sensitive resources

5. Align with Data Protection and Privacy Regulations

   • Ensure ownership/stewardship records comply with: o GDPR Article 30 (Records of Processing Activities) o ISO/IEC 27701:2019 (PII Controllers/Processors roles) o CCPA roles in data accountability and deletion requests

6. Provide Audit Trails and Evidence

   • Log ownership and stewardship updates

   • Document evidence for regulatory audits: o Owner designation policies o Stewardship review schedules and results o Incident response logs involving data stewards

7. Integrate with Identity & Access Management

   • Link data ownership to IAM: o Ensure data stewards have appropriate role-based access o Log all accesses and changes by data owners or stewards o Use ABAC to tie access to classification and stewardship role

[All Actors]

1. Define and document data-ownership and stewardship policies for every dataset the actor stores or processes.

2. Maintain an up-to-date inventory (or lineage repository) of personal and sensitive data that records origin, transformations, current location, and designated owner / steward.

3. Implement traceability mechanisms—logs, metadata tagging, or equivalent—to follow data from ingestion to disposal within systems the actor controls.

4. Review and update ownership / stewardship documentation at least annually, or after significant changes, and assess compliance with those policies.

[Shared among: MP, OSP, CSP]

1. Maintain records of training and inference datasets containing personal or sensitive data, including associated ownership and usage-rights metadata.

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.

Shared Implementation Guidelines

[All Actors]

1. Apply security controls (encryption, RBAC, logging, vulnerability patching) to every hop identified in the data-flow map for components the actor operates.

2. Verify that protections remain effective after system changes (e.g., new API, new storage location).

3. Document residual risks and mitigation plans.

[Shared among: MP, OSP, CSP]

1. Encrypt training data at rest, restrict access to authorised service roles, and monitor for anomalous reads/writes in training pipelines.

Implementation Guidelines for Cloud Service Providers (CSP)

1. Embed Secure Development Lifecycle (SDL) Practices

   • Adopt a formal Secure Software Development Lifecycle (SSDLC) model (e.g., Microsoft SDL, OWASP SAMM).

   • Include security checkpoints at every phase: o Threat modeling (early design) o Secure coding standards (implementation) o Static/dynamic code analysis (testing) o Secure deployment and monitoring (operations)

2. Apply Infrastructure and Service Hardening Standards

   • Design cloud services based on: o NIST 800-53, CIS Benchmarks, ISO/IEC 27001 o Cloud-specific security baselines (e.g., AWS Well-Architected Framework, Azure Security Benchmark)

   • Apply secure defaults: o Encryption at rest and in transit o No public access by default o Logging enabled by default

3. Integrate Privacy by Design

   • Align with privacy engineering principles: o Minimize data collection and retention o Use data masking and pseudonymization where possible o Enable customer controls for consent, access, and erasure

   • Integrate Privacy Impact Assessments (PIAs) into product development

4. Design for Multi-Tenancy and Isolation

   • Architect systems to ensure: o Logical and physical isolation between tenants o Protection against data leakage or side-channel attacks

   • Use mechanisms like namespace isolation, encryption segregation, and tenant-scoped access controls

5. Build with Zero Trust and Least Privilege Principles

   • Design internal systems and APIs to follow: o Zero Trust (no implicit trust based on location or role) o Least privilege access enforced through granular IAM and just-in-time permissions

   • Regularly review and expire unused permissions or roles

6. Implement Continuous Security Testing

   • Use DevSecOps practices to integrate: o Continuous integration/continuous deployment (CI/CD) security scanning o Dependency checks for vulnerabilities (e.g., using tools like Snyk, Dependabot) o Container image security and secrets scanning

7. Industry Alignment & Certification

   • Align product development with industry-recognized security frameworks and certifications: o SOC 2 Type II, ISO/IEC 27001, CSA STAR, PCI DSS (for relevant services)

   • Participate in standards bodies and industry groups (e.g., CSA, NIST, ENISA)

8. Customer Enablement & Transparency

   • Provide security configuration guides, templates, and best practices for customers using your services

   • Offer: o Well-architected reviews o Security documentation (e.g., threat models, penetration test summaries) Shared responsibility models

[All Actors]

1. Apply security controls (encryption, RBAC, logging, vulnerability patching) to every hop identified in the data-flow map for components the actor operates.

2. Verify that protections remain effective after system changes (e.g., new API, new storage location).

3. Document residual risks and mitigation plans.

[Shared among: MP, OSP, CSP]

1. Encrypt training data at rest, restrict access to authorised service roles, and monitor for anomalous reads/writes in training pipelines.

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.

Shared Implementation Guidelines

[All Actors]

1. Filter, mask and auto-delete sensitive inputs / outputs by default where the actor can inspect content; where content is opaque, ensure upstream or downstream services apply equivalent controls.

2. Enforce user consent, minimise data and give privacy control to users for any personal data the actor collects or processes.

3. Enforce enterprise privacy policies and control what data is shared for any data the actor shares or receives, ensuring onward transfers respect those policies.

4. Provide privacy-protective infrastructure defaults and compliance tools.

[Shared among: MP, OSP, CSP]

1. Use privacy-preserving data, consent-based training and reduce memorisation for any model training the actor performs.

Implementation Guidelines for Cloud Service Providers (CSP)

1. Adopt a Formal “Privacy by Design” (PbD) Framework

   • Integrate the 7 foundational principles of PbD (Cavoukian) into your product and service lifecycle:

2. Proactive not reactive

3. Privacy as the default setting

4. Privacy embedded into design

5. Full functionality — positive-sum, not zero-sum

6. End-to-end lifecycle protection

7. Visibility and transparency

8. Respect for user privacy

   • Align your design with regulations like GDPR (Articles 25, 5) and ISO/IEC 27701.

9. Configure Privacy-Preserving Defaults

   • Ensure default configurations in services: o Do not expose data publicly unless explicitly enabled o Enable encryption at rest and in transit by default o Restrict logs and telemetry collection to the minimum necessary o Mask or anonymize PII in diagnostics by default

10. Data Minimization and Purpose Limitation

• Design systems to: o Collect only the data necessary for the defined processing purpose o Avoid capturing excess metadata unless required o Use pseudonymization or anonymization techniques when storing diagnostic or telemetry data

1. Customer Privacy Controls & Transparency

• Provide fine-grained privacy settings in the cloud console: o Control over telemetry, logging, third-party data sharing o Ability to configure data residency and retention o Interface for consent management, access requests, and erasure

• Document all data collection and processing in public-facing privacy notices

1. Internal Data Governance and Access Control

• Maintain a centralized PII inventory for CSP-managed data (e.g., customer contacts, billing data)

• Enforce role-based access control (RBAC) and just-in-time access to PII

• Perform regular reviews of who can access personal data internally

1. Privacy Impact Assessments (PIAs)

• Mandate PIAs during: o Design of new customer-facing features o Integration of third-party services o New telemetry or metadata collection processes

• Use tools or checklists aligned with GDPR Art. 35 or ISO 29134

1. Retention, Deletion, and Portability

• Implement lifecycle rules to: o Automatically delete or archive data after specified retention periods o Allow customers to export and delete their data on demand o Enable customer-managed keys to support cryptographic erasure

1. Training and Awareness

• Ensure engineering and operations teams are trained in: o Privacy engineering principles o Secure coding practices that prevent privacy violations (e.g., exposure of logs containing PII) Regulatory obligations related to data protection (e.g., GDPR, CCPA, APPI)

[All Actors]

1. Filter, mask and auto-delete sensitive inputs / outputs by default where the actor can inspect content; where content is opaque, ensure upstream or downstream services apply equivalent controls.

2. Enforce user consent, minimise data and give privacy control to users for any personal data the actor collects or processes.

3. Enforce enterprise privacy policies and control what data is shared for any data the actor shares or receives, ensuring onward transfers respect those policies.

4. Provide privacy-protective infrastructure defaults and compliance tools.

[Shared among: MP, OSP, CSP]

1. Use privacy-preserving data, consent-based training and reduce memorisation for any model training the actor performs.

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.

Shared Implementation Guidelines

[All Actors]

1. Conduct a Data-Protection Impact Assessment (DPIA) for every personal-data processing activity the actor controls, evaluating likelihood and severity of risks such as bias, re-identification, unauthorized access, or adversarial misuse.

2. Document the processing purpose, data flows, lawful basis, risk findings and mitigation measures, and retain the DPIA report for audit or regulatory review.

3. Review and update the DPIA at least annually or whenever a material change occurs (new data source, new model version, new recipient, major scale-up, etc.).

4. Verify that processing remains compliant with applicable laws and standards (e.g., GDPR, CCPA, ISO 27701, HIPAA) and record evidence of that verification.

[Shared among: AP, AIC, OSP]

1. Provide user-facing transparency (notices, dashboards) and consent or opt-out mechanisms whenever the DPIA identifies heightened impact on data subjects, and propagate those choices through downstream services.

Implementation Guidelines for Cloud Service Providers (CSP)

1. Data Inventory & Flow Mapping

   • Maintain detailed records of all personal data processed on the cloud platform.

   • Map the end-to-end data lifecycle—from collection to destruction—including third-party access points and transfers.

   • Ensure visibility into multi-cloud and hybrid setups to identify where data resides physically and virtually.

2. DPIA Framework Adoption

   • Adopt a standardized DPIA methodology, such as ISO/IEC 29134 or GDPR-recommended practices.

   • Integrate DPIA as part of service onboarding, updates, and scaling phases—especially in services processing personal/sensitive data.

3. Automation Support

   • Provide tooling support for tenants/customers to conduct DPIAs by enabling: o Automated risk assessments. o Templates for regulatory jurisdictions. o Real-time risk scoring linked to infrastructure and workload changes.

4. Privacy-by-Design Enablement

   • Enable privacy features (e.g., data minimization, pseudonymization, encryption) by default within cloud services.

   • Provide privacy-enhancing technologies (PETs) as part of managed service offerings (e.g., secure enclaves, homomorphic encryption options).

5. Regulatory Jurisdiction Controls

   • Offer geo-fencing and data residency options to help customers meet local regulatory requirements.

   • Provide clear documentation on where personal data is stored, replicated, or transferred across regions.

6. Shared Responsibility Transparency

   • Clearly document the shared responsibility model regarding data protection, DPIA ownership, and breach notification obligations.

   • CSPs are responsible for the security of the cloud, while customers manage security in the cloud.

7. Access Controls and Monitoring

   • Enforce granular Identity and Access Management (IAM) for all data access layers.

   • Log and audit data access events, particularly around personal data.

8. Incident Response and Breach Notification

   • Have predefined procedures for notifying customers in case of data breaches involving personal data.

   • Offer tooling for customers to assess the impact and severity of a breach and integrate this with their DPIA documentation.

9. DPIA Awareness and Documentation

   • Train internal teams on DPIA relevance and implementation for new services.

   • Offer documentation, white papers, and compliance blueprints for services that handle PII or are designed for regulated industries (e.g., healthcare, finance).

10. Third-Party Risk Integration

• Include third-party services used by the CSP (e.g., SaaS integrations or platform extensions) in its DPIA context.

• Ensure due diligence and contracts with subprocessors include clauses on data protection impact and privacy assessments.   [All Actors]

1. Conduct a Data-Protection Impact Assessment (DPIA) for every personal-data processing activity the actor controls, evaluating likelihood and severity of risks such as bias, re-identification, unauthorized access, or adversarial misuse.

2. Document the processing purpose, data flows, lawful basis, risk findings and mitigation measures, and retain the DPIA report for audit or regulatory review.

3. Review and update the DPIA at least annually or whenever a material change occurs (new data source, new model version, new recipient, major scale-up, etc.).

4. Verify that processing remains compliant with applicable laws and standards (e.g., GDPR, CCPA, ISO 27701, HIPAA) and record evidence of that verification.

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.

Shared Implementation Guidelines

[All Actors]

1. Protect any datasets and outputs the actor transmits during cross-system transmission.

2. Secure service-to-service inference and plugin data flow under the actor’s control through authenticated, encrypted channels and strict access controls.

3. Secure user data transfers, log handling and consent-based usage for any user data the actor processes.

4. Classify, encrypt and contractually limit transferred data for any transfers the actor initiates or receives.

5. Provide secure-by-default networking, encryption and transfer logs.

Implementation Guidelines for Cloud Service Providers (CSP)

1. Data Transfer Classification & Scoping

   • Clearly classify data types (e.g., PII, PHI, financial data) and define transfer scopes (intra-region, cross-border, inter-service).

   • Implement data tagging and labeling mechanisms to flag sensitive or personal data that require additional controls during transfer.

2. Strong Data Encryption Mechanisms

   • Encrypt data in transit using strong, up-to-date protocols (e.g., TLS 1.3, IPsec).

   • Provide customer-managed keys (CMKs) or bring-your-own-key (BYOK) options to increase data ownership and compliance.

   • Enforce encryption defaults for all data moving across network segments, APIs, and storage endpoints.

3. Cross-Border Data Transfer Controls

   • Allow customers to control data residency via region selection and geo-fencing features.

   • Support contractual safeguards such as Standard Contractual Clauses (SCCs) or Binding Corporate Rules (BCRs) for international data transfers.

   • Provide APIs and documentation for compliance mapping (e.g., GDPR, HIPAA, CCPA, LGPD) per jurisdiction.

4. Data Flow Monitoring and Logging

   • Monitor and log all personal/sensitive data transfers using Data Loss Prevention (DLP) tools.

   • Provide audit trails and transfer logs for customer access and regulatory reporting.

   • Alert customers on unusual or unapproved data flows.

5. Access Control Policies

   • Enforce least privilege access for systems, services, and personnel involved in data transfers.

   • Use attribute-based access control (ABAC) or role-based access control (RBAC) to enforce restrictions aligned with legal scopes.

6. Data Processing Scope Enforcement

   • Embed mechanisms in services to restrict data usage to the intended purpose and scope.

   • Offer policy-based access controls and tagging, ensuring services can verify data is being processed per purpose limitations.

   • Support consent management integrations where applicable.

7. Secure API Gateways

   • Route all data transfer operations through API gateways with authentication, rate limiting, and logging.

   • Inspect outbound and inbound API traffic for policy violations or leaks of sensitive data.

8. Automated Compliance Evaluation

   • Integrate compliance scoring or rules engines that assess data transfers against policies (e.g., PII not leaving EU without safeguards).

   • Support customers with DPIA support tools, privacy dashboards, and regular compliance posture reviews.

9. Third-Party/Subprocessor Transparency

   • Maintain a subprocessor registry and allow customers to audit or be notified of third-party data handling.

   • Ensure subprocessors meet comparable or higher security and privacy standards.

   • Include contractual data transfer protections with all subprocessors.

10. Periodic Assessments & Updates

• Conduct regular internal reviews and third-party audits of data transfer mechanisms and access policies. Keep up-to-date with regulatory changes that affect data flow policies and reflect them in service-level configurations.

[All Actors]

1. Protect any datasets and outputs the actor transmits during cross-system transmission.

2. Secure service-to-service inference and plugin data flow under the actor’s control through authenticated, encrypted channels and strict access controls.

3. Secure user data transfers, log handling and consent-based usage for any user data the actor processes.

4. Classify, encrypt and contractually limit transferred data for any transfers the actor initiates or receives.

5. Provide secure-by-default networking, encryption and transfer logs.

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.

Shared Implementation Guidelines

[All Actors]

1. Provide technical enforcement for data-at-rest subject to data-subject requests within systems the actor controls.

2. Govern model / training-data handling for data-subject rights for any models or datasets the actor manages.

3. Orchestrate middleware / flow pipelines for rights requests for any integration layers the actor operates.

4. Deliver or expose interfaces that enable end-user access and visibility for rights management for personal data the actor controls.

5. Govern compliance and contracts for data-subject rights.

Implementation Guidelines for Cloud Service Providers (CSP)

1. Data Subject Rights Enablement Framework

   • Establish a standardized framework for supporting customer (data controller) obligations under data protection laws like GDPR, CCPA, or LGPD.

   • Include specific guidance on how the CSP’s platform supports: o Right of access o Right to rectification o Right to erasure (right to be forgotten)

2. Self-Service Privacy Management Portal

   • Offer a privacy dashboard or portal where customers (data controllers) can: o Search and retrieve personal data records o Flag records for correction o Trigger deletion or anonymization processes

   • Provide APIs so customers can integrate these capabilities into their own privacy workflows or customer-facing apps.

3. Data Discovery and Indexing Tools

   • Implement data discovery and classification tools to help customers identify and retrieve personal data across services.

   • Ensure data associated with a specific user (data subject) can be located efficiently, even across distributed systems.

4. Granular Access Logging

   • Provide logs of personal data access, indicating: o Who accessed the data o When and why o Whether the access was authorized

   • Help customers fulfill the obligation to demonstrate processing transparency.

5. Support for Deletion/Anonymization

   • Provide configurable mechanisms for: o Secure deletion of personal data upon request o Data anonymization/pseudonymization where total deletion is not technically feasible due to legal or audit obligations

6. Retention and Deletion Policies

   • Enable customers to configure retention policies based on data type, region, or regulation.

   • Automatically purge or anonymize expired data to reduce the burden of manual deletion under user requests.

7. Standard Response Templates & SLA Support

   • Provide templates for responding to data subject requests (DSRs).

   • Commit to clearly defined support SLAs to help customers meet legal timelines (e.g., GDPR’s 30-day response window).

8. Subprocessor & Multi-Region Coordination

   • Ensure subprocessors and data replicas in other regions honor DSRs, particularly deletion and rectification requests.

   • Implement cascade mechanisms for customer-initiated changes to propagate downstream to all applicable storage and processing layers.

9. Legal and Regulatory Mapping

   • Maintain documentation that maps how the CSP’s data processing infrastructure supports: o GDPR Articles 15–18 (data subject rights) o CCPA §1798.105–110 o Other jurisdictional privacy rights

   • Offer this documentation to customers for their own compliance records or DPIAs   [All Actors]

10. Provide technical enforcement for data-at-rest subject to data-subject requests within systems the actor controls.

11. Govern model / training-data handling for data-subject rights for any models or datasets the actor manages.

12. Orchestrate middleware / flow pipelines for rights requests for any integration layers the actor operates.

13. Deliver or expose interfaces that enable end-user access and visibility for rights management for personal data the actor controls.

14. Govern compliance and contracts for data-subject rights.

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.

Shared Implementation Guidelines

[All Actors]

1. Provide legal accountability and governance enforcement.

2. Maintain data-processing agreements (DPAs) or equivalent contracts with third-party processors for any personal data the actor shares, ensuring it is handled strictly for the declared purposes and in line with applicable laws.

[Shared among: CSP, AP, OSP]

1. Apply technical controls for lawful data location and access.

[Shared among: MP, AIC, OSP]

1. Enforce purpose-bound model training and privacy-by-design.

[Shared among: OSP, CSP, AP]

1. Restrict processing paths through policy-driven routing.

[Shared among: AP, AIC, OSP]

1. Declare purpose and manage consent at the application interface.

Implementation Guidelines for Cloud Service Providers (CSP)

1. Data Purpose Declaration Framework

   • Require data controllers (customers) to specify intended purposes for personal data during setup or configuration of services.

   • Enable tagging or labeling of data sets with metadata fields indicating processing purposes.

   • Provide APIs or templates for integrating purpose declarations during data ingestion.

2. Data Processing Scope Enforcement

   • Implement policy-based access controls (PBAC) that restrict processing activities to authorized functions aligned with declared purposes.

   • Introduce usage constraints at the service level to prohibit downstream processing outside the declared context.

   • Support consent binding, ensuring only data linked to user consent is processed.

3. Consent and Purpose Management Tools

   • Offer integrations with Consent Management Platforms (CMPs) or provide native tools for customers to collect, track, and enforce consent.

   • Ensure that consent updates or revocations are automatically respected by the underlying data services.

4. Data Flow Visibility

   • Provide customers with end-to-end data lineage and flow visualization across regions, services, and subprocessors.

   • Allow auditable records that tie data access and use back to a specific declared purpose and consent.

5. Purpose-Specific Encryption and Access

   • Enable encryption keys or tokenization systems to be bound to processing contexts, so data cannot be decrypted unless the access aligns with purpose-specific policies.

   • Support data access expiration mechanisms where data becomes inaccessible beyond the approved processing window.

6. Compliance Mapping & Configuration

   • Provide tooling or configuration blueprints aligned with major privacy laws (e.g., GDPR, CCPA, LGPD) that restrict data handling to lawful bases and declared uses.

   • Offer compliance posture dashboards to assist customers in identifying misaligned data processing.

7. Data Minimization and Retention Enforcement

   • Integrate data minimization features into services to limit the collection and processing of data to what is necessary.

   • Automate data retention enforcement, where data is purged or anonymized based on the retention policy tied to its declared purpose.

8. Monitoring and Auditing

   • Implement continuous monitoring for policy violations, such as processing outside declared jurisdictions or purposes.

   • Provide exportable audit logs showing which data was accessed, by whom, and for what declared reason.

9. Third-Party and Subprocessor Alignment

   • Ensure subprocessors and service integrations respect the declared purposes of the data.

   • Include purpose-limitation clauses in contracts and conduct regular compliance assessments.

10. Customer Enablement and Documentation

• Provide comprehensive documentation and SDKs to help customers embed purpose declarations and purpose checks into their apps and services.

• Offer training modules or workshops for customers on configuring their services for privacy compliance.

[All Actors]

1. Provide legal accountability and governance enforcement.

2. Maintain data-processing agreements (DPAs) or equivalent contracts with third-party processors for any personal data the actor shares, ensuring it is handled strictly for the declared purposes and in line with applicable laws.

[Shared among: CSP, AP, OSP]

1. Apply technical controls for lawful data location and access.

[Shared among: OSP, CSP, AP]

1. Restrict processing paths through policy-driven routing.

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.

Shared Implementation Guidelines

[All Actors]

1. Control storage location and maintain transfer logging for any personal data the actor stores.

2. Manage sub-processing of model data and telemetry with data-protection-by-design for any data the actor passes to downstream processors.

3. Provide secure routing and plugin governance for any middleware or plugin frameworks the actor operates.

4. Operate plugin / API sub-processors with user transparency for any third-party services the actor integrates.

5. Deliver legal accountability and risk assessments for sub-processing.

Implementation Guidelines for Cloud Service Providers (CSP)

1. Subprocessor Governance Framework

   • Maintain a comprehensive, up-to-date subprocessor registry, publicly available to customers.

   • Include purpose, location, and scope of processing for each subprocessor.

   • Define and enforce data protection agreements (DPAs) or addenda with all subprocessors, aligning with GDPR, CCPA, etc.

2. Contractual & Legal Safeguards

   • Ensure that Standard Contractual Clauses (SCCs) or Binding Corporate Rules (BCRs) are used for international data transfers.

   • Verify that subprocessors implement equivalent or stronger technical and organizational measures (TOMs) than the CSP.

   • Allow customers to review or object to new subprocessors when possible.

3. Data Transfer Impact Assessment (DTIA)

   • For cross-border data transfers, conduct and maintain a Data Transfer Impact Assessment that assesses: o Legal environment of the recipient country. o Nature of the personal data. o Encryption and access control mechanisms.

4. Data Flow Mapping and Labeling

   • Map and visualize data flows involving subprocessors and cross-border data movement.

   • Label sensitive data types and annotate them with transfer policy metadata, such as region boundaries and transfer authorizations.

5. Access and Encryption Controls

   • Enforce end-to-end encryption (data in transit and at rest) for all personal data moving through or between subprocessors.

   • Implement key isolation or customer-managed keys where possible, ensuring that subprocessors do not have decryption access unless contractually authorized.

6. Zero Trust & Segmentation

   • Use Zero Trust architecture principles to restrict subprocessors’ access based on identity, policy, and risk.

   • Apply network segmentation and access boundaries to ensure subprocessors only interact with scoped data sets.

7. Subprocessor Monitoring and Auditing

   • Regularly audit subprocessor compliance with data protection and security obligations.

   • Require third-party SOC 2 Type II, ISO 27001, or equivalent certifications.

   • Share audit summaries or attestation reports with customers on request.

8. Incident Handling & Reporting

   • Require subprocessors to report security incidents or data breaches involving customer data within strict timelines.

   • Integrate subprocessors into the CSP’s incident response playbooks and establish escalation protocols.

9. Transparency and Notification Procedures

   • Provide customers with proactive notification of any changes in subprocessors or data flow configurations.

   • Offer opt-out rights or migration paths for customers when subprocessors are added or changed.

10. Evaluation and Continuous Improvement

• Periodically evaluate the entire subprocessor supply chain for risks, changes in regulatory landscape, or newly discovered threats. Update policies and procedures accordingly, and include results in internal and customer-facing compliance reviews   [All Actors]

1. Control storage location and maintain transfer logging for any personal data the actor stores.

2. Manage sub-processing of model data and telemetry with data-protection-by-design for any data the actor passes to downstream processors.

3. Provide secure routing and plugin governance for any middleware or plugin frameworks the actor operates.

4. Operate plugin / API sub-processors with user transparency for any third-party services the actor integrates.

5. Deliver legal accountability and risk assessments for sub-processing.

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.

Shared Implementation Guidelines

[All Actors]

1. Disclose to data owners or customers every sub-processor that will access personal or sensitive data before processing begins, and promptly update the disclosure when a sub-processor is added, removed, or changes scope.

2. Maintain detailed logs or registers of all sub-processor engagements - including purpose, data categories accessed, approval / consent status, and effective dates - for audit or regulatory review.

3. Provide mechanisms to obtain, record, and honour explicit consent or approval (e-g., in-app settings, contract clauses, service-catalog workflows) wherever law or contract demands it.

4. Share relevant privacy-and-security documentation for each sub-processor (DPIAs, technical controls, certifications, access protocols) with customers, regulators, or internal stakeholders on request.

5. Perform risk-based due-diligence and embed contractual clauses that bind sub-processors to the same data-protection and disclosure obligations the actor has accepted.

[Shared among: MP, OSP, CSP]

1. Implement telemetry and visibility tooling (dashboards, access logs) to track real-time data-access events by sub-processors across model-training, orchestration, or infrastructure layers the actor operates, and surface those records for audit.

Implementation Guidelines for Cloud Service Providers (CSP)

1. Subprocessor Pre-Disclosure Process

   • Develop a standardized process to notify customers (data owners) before any new subprocessor begins processing personal or sensitive data.

   • Disclosures must include: o Subprocessor name and role o Geographic location o Nature and scope of processing o Categories of data involved o Applicable safeguards (e.g., encryption, access controls)

2. Subprocessor Notification Portal

   • Provide a dedicated notification and management portal or API where customers can: o View upcoming subprocessor engagements o Access detailed subprocessor data handling profiles o Subscribe to alerts or RSS feeds for subprocessor changes

3. Change Management and Prior Authorization

   • Define policies requiring minimum notice periods (e.g., 30 days) before a subprocessor begins data processing.

   • Offer customers the ability to: o Opt out o Request alternatives o Terminate services without penalty in case of objection (if legally mandated)

4. Contractual Embedding

   • Embed subprocessor disclosure and notification obligations in the CSP’s Terms of Service and Data Processing Agreement (DPA).

   • Include obligations to describe technical measures (encryption, monitoring, data segregation) to limit subprocessor access.

5. Audit Logs and Proof of Notification

   • Maintain audit logs of all customer notifications and acknowledgments related to subprocessor processing.

   • Store these logs securely to support compliance with GDPR Art. 28(2–4), CCPA, and similar laws.

6. Minimum Disclosure Content Template

   • Standardize what must be disclosed using a template that includes: o Subprocessor’s compliance certifications (e.g., ISO 27001, SOC 2) o Processing purpose and duration o Data retention policies o Subprocessor’s technical and organizational measures (TOMs)

7. Privacy Impact Assessment (PIA) Trigger

   • Require an internal PIA review for any new subprocessor onboarding to evaluate risk to data subjects.

   • Provide a summary of the DPIA results (or assurance letter) to customers upon request.

8. Secure Access Controls

   • Ensure subprocessors have role-based, time-bound, and auditable access to personal data.

   • Provide customers with logs or reports showing when and by whom data is accessed.

9. Customer Dashboard Integration

   • Integrate subprocessor status and notifications into customer-facing dashboards to: o Confirm active subprocessors per workload o Export historical subprocessor access records o View pending changes

10. Regular Reviews & Policy Updates

• Conduct annual or risk-based reviews of subprocessor engagement processes.

• Align disclosures with updated regulations (e.g., GDPR, UK GDPR, CCPA, LGPD) and industry best practices.

[All Actors]

1. Disclose to data owners or customers every sub-processor that will access personal or sensitive data before processing begins, and promptly update the disclosure when a sub-processor is added, removed, or changes scope.

2. Maintain detailed logs or registers of all sub-processor engagements - including purpose, data categories accessed, approval / consent status, and effective dates - for audit or regulatory review.

3. Provide mechanisms to obtain, record, and honour explicit consent or approval (e-g., in-app settings, contract clauses, service-catalog workflows) wherever law or contract demands it.

4. Share relevant privacy-and-security documentation for each sub-processor (DPIAs, technical controls, certifications, access protocols) with customers, regulators, or internal stakeholders on request.

5. Perform risk-based due-diligence and embed contractual clauses that bind sub-processors to the same data-protection and disclosure obligations the actor has accepted.

[Shared among: MP, OSP, CSP]

1. Implement telemetry and visibility tooling (dashboards, access logs) to track real-time data-access events by sub-processors across model-training, orchestration, or infrastructure layers the actor operates, and surface those records for audit.

From CCM v4.1: Control Ownership Rationale. This is a Shared (Independent) control for both the CSP and CSC because both should define processes, procedures, and technical measures for defining, implementing, and evaluating disclosure of the details of any personal or sensitive data accessed by sub-processors to the data owner prior to initiating that processing.

Implementation Guidelines. Applicable to all service models: The control implementation is not service delivery model specific (IaaS, PaaS, or SaaS). Irrespective of cloud service delivery model, the CSP is responsible for defining processes, procedures, and technical measures for disclosure of data to sub-processors.

Recommendations to the CSP are:

• a. detail the disclosure of any personal or sensitive data by sub-processors prior to initiating the processing, through the data processing and security terms agreed upon by the CSC and CSP

• b. ensure processing is as per the policies and procedures in the CSP’s data protection addendum

• c. cover in the privacy policy the practices that the CSP and its subsidiaries and affiliates employ when providing support, consulting, cloud or other services to the CSC. Establish this privacy policy in order to clarify that the use of information to which it may be provided access to provide services is more limited than the use of information covered by CSP’s general privacy policy

• d. work with third-party subcontractors to provide website, application development, hosting, maintenance, backup, storage, virtual infrastructure, payment processing, analysis and other services. These service providers may have access to or process personal data for the purpose of providing those services

• e. disclose to its relevant customers any use of subcontractors who may process the personal data before processing occurs. An external facing list of subcontractors who work with the CSP should be provided. Invite visitors to subscribe to an RSS feed that notifies them when new sub-processors are introduced

• f. where a sub-processor will process personal data subject to EU data protection laws, the CSP should ensure that the sub-processor is subject to contractual obligations regarding Personal Data which satisfy the requirements of EU data protection laws

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.

Shared Implementation Guidelines

[Applicable to all service providers]

1. Establish a policy to specify procedures for secure handling, sanitization, anonymization, and compliance with regulations when using or replicating production data.

2. Conduct risk assessments to identify risks associated with data use.

3. Define and enforce physical and logical boundaries to keep production data secure.

4. Establish and implement policies and procedures for secure development and managing changes.

5. Implement segregation of duties and enforce least privilege access to production environments only after authorization from data owner.

6. Implement principle of least privilege and authorized access to datasets, models, and other sensitive information.

7. Implement security measures to secure datacenters.

8. Provide regular training on security, privacy, and secure coding practices.

9. Implement timely termination and management of employee access.

10. Monitor assets, enforce secure configurations, and manage vulnerabilities on infrastructure and applications processing and storing production data.

11. Enable logs and continuously monitor system access for anomalies.

12. Replicate only the necessary data to minimize potential risks.

13. Anonymize or pseudonymize data to protect privacy and reduce the risk of exposing sensitive information.

14. Implement security measures such as encryption, and secure data transfer protocols.

15. Ensure data replication complies with relevant data protection laws and regulations, such as GDPR.

16. Maintain detailed records of the data replication process and perform periodic audits to ensure compliance.

17. Establish process to inform relevant stakeholders about the data replication process, including its purpose and scope.

18. Detect and remove or remediate sensitive or poisoned data before using it for training.

19. Implement mechanisms to ensure the integrity of data, models, and code used in AI development and deployment.

20. Implement the process of obtaining authorization from data owner before using the data for non-production purposes.

Implementation Guidelines for Cloud Service Providers (CSP)

[Applicable to all service providers]

1. Establish a policy to specify procedures for secure handling, sanitization, anonymization, and compliance with regulations when using or replicating production data.

2. Conduct risk assessments to identify risks associated with data use.

3. Define and enforce physical and logical boundaries to keep production data secure.

4. Establish and implement policies and procedures for secure development and managing changes.

5. Implement segregation of duties and enforce least privilege access to production environments only after authorization from data owner.

6. Implement principle of least privilege and authorized access to datasets, models, and other sensitive information.

7. Implement security measures to secure datacenters.

8. Provide regular training on security, privacy, and secure coding practices.

9. Implement timely termination and management of employee access.

10. Monitor assets, enforce secure configurations, and manage vulnerabilities on infrastructure and applications processing and storing production data.

11. Enable logs and continuously monitor system access for anomalies.

12. Replicate only the necessary data to minimize potential risks.

13. Anonymize or pseudonymize data to protect privacy and reduce the risk of exposing sensitive information.

14. Implement security measures such as encryption, and secure data transfer protocols.

15. Ensure data replication complies with relevant data protection laws and regulations, such as GDPR.

16. Maintain detailed records of the data replication process and perform periodic audits to ensure compliance.

17. Establish process to inform relevant stakeholders about the data replication process, including its purpose and scope.

18. Detect and remove or remediate sensitive or poisoned data before using it for training.

19. Implement mechanisms to ensure the integrity of data, models, and code used in AI development and deployment.

20. Implement the process of obtaining authorization from data owner before using the data for non-production purposes.

From CCM v4.1: Control Ownership Rationale. This is a “Shared (Independent)” control for both the CSP and CSC because both should perform due diligence before replicating or using production data in non-production environments (and periodically thereafter, commensurate with the risk level of the third-party relationship).

Implementation Guidelines. Applicable to all service models: Irrespective of cloud service delivery model, the CSP is responsible for preventing or replicating the use of production data.

Recommendations for the CSP are:

• a. maintain policies and processes for governance and oversight of the infrastructure/platform/application

• b. define physical and logical network boundaries to ensure production data remains in the boundary of the production network

• c. enforce change controls policies and processes

• d. ensure SSDLC coding practices, quality testing, coding scanning, network and application penetration testing, code deployment, code backups, and integrated code testing

• e. establish procedures requiring that production data not be used in non-production environments without sanitization, anonymization, pseudonymization, obfuscation, truncation, tokenization, or replacing with dummy data as applicable

• f. segregate duties to require business approval to access an environment

• g. base physical and logical access to the production cloud environment on the principle of least privilege

• h. physically secure datacenters including hardware management, datacenter security training, and access alarms

• i. provide periodic awareness training on security, privacy, secure infrastructure management, and coding practices to employees

• j. timely termination of employees

• k. enforce asset inventory tracking, secure configuration management, automated vulnerability scanning, and patch management

• l. continuously log and audit system access, with correlation and alerting

• m. perform regular compliance audits to ensure control effectiveness

DSP-16: Data Retention and Deletion

Control Specification

Data retention, archiving and deletion is managed in accordance with business requirements, applicable laws and regulations.

Shared Implementation Guidelines

[Applicable to all service providers]

1. Establish and document data retention policy to specify retention, archiving, and data deletion requirements in accordance with legal, regulatory and business requirements, including contractual obligations. Review and update the policy periodically to keep it current.

2. Create agreements to specify data deletion, retention, and archiving requirements, ensuring compliance with applicable laws and regulations to subprocessors. Obtain a certificate of destruction if using a managed service provider.

3. Maintain audit logs, backups, and redundancy for disaster recovery in accordance with data retention policy. Set up a decommissioning process to destroy defective disks so data cannot be recovered.

4. Implement tools for secure data deletion, including NIST 800-88 compliant data wiping and secure disposal of records.

5. Establish a process to comply with requests to destroy customer data within agreed time periods and provide written certification of destruction.

6. Establish a process to delete customer data after service termination.

Implementation Guidelines for Cloud Service Providers (CSP)

[Applicable to all service providers]

1. Establish and document data retention policy to specify retention, archiving, and data deletion requirements in accordance with legal, regulatory and business requirements, including contractual obligations. Review and update the policy periodically to keep it current.

2. Create agreements to specify data deletion, retention, and archiving requirements, ensuring compliance with applicable laws and regulations to subprocessors. Obtain a certificate of destruction if using a managed service provider.

3. Maintain audit logs, backups, and redundancy for disaster recovery in accordance with data retention policy. Set up a decommissioning process to destroy defective disks so data cannot be recovered.

4. Implement tools for secure data deletion, including NIST 800-88 compliant data wiping and secure disposal of records.

5. Establish a process to comply with requests to destroy customer data within agreed time periods and provide written certification of destruction.

6. Establish a process to delete customer data after service termination.

From CCM v4.1: Control Ownership Rationale. This is a “Shared (Independent)” control for both the CSP and CSC because both should ensure data retention, archiving, and deletion is managed in accordance with business requirements, and applicable laws and regulations (and periodically thereafter, commensurate with the risk level of the third-party relationship).

Implementation Guidelines. Applicable to all service models: The control implementation is not service delivery model specific (IaaS, PaaS, or SaaS). Irrespective of cloud service delivery model, the CSP is responsible for ensuring retention and deletion practices encompassing both physical and electronic data.

Recommendations to the CSP are:

• a. define an information protection policy to set forth the requirements for classifying and handling confidential information, including requirements for visual disclosure. This policy should apply to all confidential information, whether the information belongs to the CSP, its customers, or the CSP’s third party. This policy should be reviewed and revised by the legal team at least annually

• b. maintain data retention, archiving, and deletion policies and procedures in accordance with regulatory, statutory, contractual, and business requirements in order to continue operations of the CSP’s services

• c. the CSP should detail its agreements for data deletion (including retention) and data export per applicable laws and regulations in the data processing and security terms

• d. the CSP should ensure critical system components, including audit evidence and logging records, and backup and redundancy programs are maintained, monitored, reviewed, and validated at least annually for disaster recovery purposes

• e. the CSP should provide tools to securely delete data including removing indices from the primary location of any geo-replicated copy asynchronously. Data wiping should be NIST 800-88 compliant. Destruction of data should include secure erasure of media and secure disposal of records so the information cannot be read or reconstructed

• f. the CSP should follow a decommissioning process that is designed to destroy a defective disk to the point that data cannot be reasonably recovered. Where applicable, if a managed service provider is used for secure destruction, then a certificate of destruction should be obtained

• g. the CSP should promptly comply to the extent practicable with written requests to destroy “Maintained Customer Data” within agreed time periods and provide written certification of destruction of “Maintained Customer Data” upon the CSC’s written request

• h. the CSP should delete customer data from CSP support services systems upon termination of the support services investigation, including deletion of data from the secure FTP site, databases, hard drives, and virtual machines, and delete virtual meeting sessions, provided that correspondence between the CSP and CSC had been retained

DSP-17: Sensitive Data Protection

Control Specification

Define and implement, processes, procedures and technical measures to protect sensitive data throughout its lifecycle.

Shared Implementation Guidelines

[Applicable to all service providers]

1. Establish and implement an agreement to specify the service provider’s role and obligations in processing sensitive data.

2. Establish procedures and implement measures to ensure that sensitive data is used only for the purposes specified in the agreement.

3. Establish and implement procedures to ensure that sensitive data is not used for marketing, advertisement, or AI model training without obtaining consent from the data owner.

4. Establish and implement procedures to inform the data owner if data processing and handling do not comply with applicable legislation and regulations.

5. Establish and implement procedures to provide the required information to support customers in fulfilling their compliance obligations.

6. Identify and maintain necessary records to demonstrate compliance with obligations.

7. Implement mechanisms to ensure temporary files that are created as a result of processing sensitive data are disposed according to established procedures.

8.Establish and implement processes to return, transfer, and dispose sensitive data securely.

1. Establish and implement processes to transmit sensitive data over secure data transmission networks and verify that the data reached its intended destination.

2. Establish and implement processes to inform customers in a timely manner about sensitive data transfer between jurisdictions, and provide customers an opportunity to object such transfers or terminate the agreement.

3. Establish and implement processes to inform customers of the locations to which sensitive data can possibly be transferred.

4. Establish and implement processes to disclose subprocessors used for processing sensitive data, including when and to whom the data was shared.

5. Establish and implement processes to notify customers of any legally binding requests for disclosure of sensitive information.

6. Establish and implement processes to disclose subcontractors, third party AI models, and open-source services used in processing sensitive information.

7. Establish and implement measures to limit or minimize the collection and processing of sensitive data.

8. Establish and implement measures to de-identify or delete sensitive data as soon as the intended purposes of use are completed.

9. Establish and implement measures to identify and address obligations for automated decision-making and automated content generation using sensitive information.

10. Establish and implement processes to perform privacy impact assessments and risk assessments.

11. Implement integrity checks to ensure sensitive data is not altered during transfer.

12. Establish and implement processes to classify data based on sensitivity and to apply appropriate protection measures.

13. Encrypt and or tokenize sensitive data both at rest and in use to prevent unauthorized access.

14. Implement data masking techniques to protect sensitive information during storage.

15. Anonymize or pseudonymize data to protect privacy and reduce the risk of exposing sensitive information.

16. Continuously monitor and log data access and usage to detect and respond to unauthorized activities.

17. Implement DLP tools to control what data can be entered or exported into generative AI systems.

18. Establish and implement data retention policies to ensure sensitive data is kept only as long as necessary.

19. Implement secure deletion methods (e.g., data wiping, degaussing) to permanently remove sensitive data.

20. Provide regular training on data protection practices and policies.

21. Establish and implement an incident response plan to address data breaches and security incidents.

Implementation Guidelines for Cloud Service Providers (CSP)

[Applicable to all service providers]

1. Establish and implement an agreement to specify the service provider’s role and obligations in processing sensitive data.

2. Establish procedures and implement measures to ensure that sensitive data is used only for the purposes specified in the agreement.

3. Establish and implement procedures to ensure that sensitive data is not used for marketing, advertisement, or AI model training without obtaining consent from the data owner.

4. Establish and implement procedures to inform the data owner if data processing and handling do not comply with applicable legislation and regulations.

5. Establish and implement procedures to provide the required information to support customers in fulfilling their compliance obligations.

6. Identify and maintain necessary records to demonstrate compliance with obligations.

7. Implement mechanisms to ensure temporary files that are created as a result of processing sensitive data are disposed according to established procedures.

8.Establish and implement processes to return, transfer, and dispose sensitive data securely.

1. Establish and implement processes to transmit sensitive data over secure data transmission networks and verify that the data reached its intended destination.

2. Establish and implement processes to inform customers in a timely manner about sensitive data transfer between jurisdictions, and provide customers an opportunity to object such transfers or terminate the agreement.

3. Establish and implement processes to inform customers of the locations to which sensitive data can possibly be transferred.

4. Establish and implement processes to disclose subprocessors used for processing sensitive data, including when and to whom the data was shared.

5. Establish and implement processes to notify customers of any legally binding requests for disclosure of sensitive information.

6. Establish and implement processes to disclose subcontractors, third party AI models, and open-source services used in processing sensitive information.

7. Establish and implement measures to limit or minimize the collection and processing of sensitive data.

8. Establish and implement measures to de-identify or delete sensitive data as soon as the intended purposes of use are completed.

9. Establish and implement measures to identify and address obligations for automated decision-making and automated content generation using sensitive information.

10. Establish and implement processes to perform privacy impact assessments and risk assessments.

11. Implement integrity checks to ensure sensitive data is not altered during transfer.

12. Establish and implement processes to classify data based on sensitivity and to apply appropriate protection measures.

13. Encrypt and or tokenize sensitive data both at rest and in use to prevent unauthorized access.

14. Implement data masking techniques to protect sensitive information during storage.

15. Anonymize or pseudonymize data to protect privacy and reduce the risk of exposing sensitive information.

16. Continuously monitor and log data access and usage to detect and respond to unauthorized activities.

17. Implement DLP tools to control what data can be entered or exported into generative AI systems.

18. Establish and implement data retention policies to ensure sensitive data is kept only as long as necessary.

19. Implement secure deletion methods (e.g., data wiping, degaussing) to permanently remove sensitive data.

20. Provide regular training on data protection practices and policies.

21. Establish and implement an incident response plan to address data breaches and security incidents.

From CCM v4.1: Control Ownership Rationale. This is a CSP-owned control because customer data security is a top priority, and several different mechanisms should be in place to ensure sensitive data is protected throughout its lifecycle.

Implementation Guidelines. Applicable to all service models: The control implementation is not service delivery model specific (IaaS, PaaS, or SaaS). Irrespective of the cloud service delivery model, the CSP is responsible for ensuring that mechanisms are in place to protect data throughout its lifecycle.

Recommendations to the CSP are:

• a. the CSP should publish a privacy statement and explain its processes for handling sensitive data. This should be official, signed, legally valid, and issued pursuant to federal or local law and rules. Some of the attributes to be covered in the process are:

  • i. important definitions such as “personal data”, “data subject”, “processing”, “controller” and “processor,” etc.

  • ii. scope of data protection law

  • iii. roles and responsibilities of processor, controller and customer

  • iv. scope of processing, such as it only collects and stores the customer’s user credentials, which includes: first name, last name, username, and password. Do not store, process, or transmit sensitive data like birthdate, personal address, social security number, health information, financial data (SOX) or credit card information

• b. data deletion: deletion by customer, return or deletion when term ends, deferred deletion instruction vi. security measures, controls and assistance: Access and compliance, encryption, use of unique encryption keys for each customer to ensure that customer data is logically separated within the service, data in production is completely segmented from the development, testing, staging, and corporate environments. Use of Trusted Execution Environments (TEEs) for data in use, No customer production data is used in test or development environments. If it is deemed absolutely necessary to use Production Data for the purposes of Testing, then controls that are exactly the same as the Production environment must be applied and replicated. vii. all virtual machine instances within the production environment are allow-listed to only communicate with each other on specific ports and protocols, implement IDS/IPS and strict firewalling at the hypervisor and guest instance layers, no outbound communication is permitted that originates from the production environment, network layer controls ensure that privileged access is always enforced through allow-listed IPs and hosts, using encrypted VPN tunnels through non-standard ports, technical operations personnel are assigned an SSH key pair to authenticate to the production environment, second-factor authentication is provided by a physically separate hardware MFA token, implementation of transaction monitoring on the databases to detect abnormal queries or large exports of customer data, monitoring all outbound traffic from the CSP’s production environment for anomalies using both proprietary and commercial traffic monitoring and intrusion detection systems, sending alerts to both technical operations and security, do not store customer data outside of the service’s production environment, and do not permit the exporting of customer data onto removable media or mobile devices, datacenter security, networks and transmission, and personnel security viii. data incident management ix. customer’s security responsibilities

• c. compliance certifications and SOC reports xi. customer’s audit rights xii. access etc.; data subject rights; data export xiii. data transfers xiv. use of sub-processors

• d. where and when applicable, the CSP should implement Information rights management technology for all sensitive data

• e. the CSP should require a subpoena or its equivalent before disclosing non-content, and only disclose content to law enforcement in response to a warrant (or its local equivalent)

• f. the CSP should redirect the government and other regulatory authorities to seek data from the CSC itself when legally permitted

• g. the CSP should establish a process to capture all law enforcement requests through a secure portal, for which only vetted law enforcement agencies receive access. Once the CSP reviews the demand and determines that it should provide data, the data specified in the valid legal order should be provided to law enforcement through the same secure portal

• h. the CSP should design an acceptable use policy (AUP) for systems and resources to help its employees, suppliers, contractors and partners protect the security and integrity of information and its systems and resources, and specify on how they may, and may not, use systems and resources while performing their job duties

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.

Shared Implementation Guidelines

[Applicable to all providers]

1. Define a policy and process in accordance with applicable laws and regulations that specifies requirements for responding to requests for access to confidential information from law enforcement agencies.

2. Establish processes to evaluate whether the access requests are legally required, and determine appropriate actions including any required notices or disclosures to the public, customers, affected individuals, or law enforcement authorities.

3. Address the need for transparency to the customers by informing them of requests received concerning their data.

4. Designate a legal team to maintain appropriate contacts with relevant authorities (e.g., regulators, law enforcement, government officials) and industry bodies to help with evaluation of requests and obtain guidance as required.

5. When processing personal data in AI applications ensure transparency and compliance in accordance regulations such as EU AI Act to disclose to users: when they are interacting with an AI system, labeling synthetic content, notifying about emotion recognition or biometric categorization, providing details about data processing, and informing of data subjects of their rights.

Implementation Guidelines for Cloud Service Providers (CSP)

[Applicable to all providers]

1. Define a policy and process in accordance with applicable laws and regulations that specifies requirements for responding to requests for access to confidential information from law enforcement agencies.

2. Establish processes to evaluate whether the access requests are legally required, and determine appropriate actions including any required notices or disclosures to the public, customers, affected individuals, or law enforcement authorities.

3. Address the need for transparency to the customers by informing them of requests received concerning their data.

4. Designate a legal team to maintain appropriate contacts with relevant authorities (e.g., regulators, law enforcement, government officials) and industry bodies to help with evaluation of requests and obtain guidance as required.

5. When processing personal data in AI applications ensure transparency and compliance in accordance regulations such as EU AI Act to disclose to users: when they are interacting with an AI system, labeling synthetic content, notifying about emotion recognition or biometric categorization, providing details about data processing, and informing of data subjects of their rights.

From CCM v4.1: Control Ownership Rationale. This is a CSP-owned control because the CSC’s privacy is top priority. The CSP should have a policy that prohibits the disclosure of the CSC’s data unless it is required to do so to comply with the law, or with a valid and binding order of a governmental or regulatory body. The CSP should notify the CSC before disclosing CSC content to law enforcement authorities so that they can seek protection from disclosure.

Implementation Guidelines. Applicable to all service models: Irrespective of cloud service delivery model, the CSP is responsible for having a policy that prohibits the disclosure of the CSC’s data unless required to do so to comply with the law, or with a valid and binding order of a governmental or regulatory body.

Recommendations to the CSP are:

• a. the CSP should define a policy and process in line with applicable laws and regulations that specifies requirements for responding to requests for access to confidential information from third parties, evaluating whether the access requests are legally mandatory, and determining appropriate actions including any required notices or disclosures to the public, CSCs, affected individuals, or law enforcement authorities

• b. the CSP should address the need for transparency to the CSC by regularly publishing a report about the types and volume of information requests received

• c. the CSP should designate a legal team to maintain appropriate contacts with relevant authorities (e.g., regulators, law enforcement, government officials) and industry bodies such as security, risk, compliance and policy organizations to evaluate the list of requests on a regular basis and seek guidance as required

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.

Shared Implementation Guidelines

[Applicable to all providers]

1. Maintain list of all data assets, their owners, sensitivity, origin, and processing methods.

2. Create data flow diagrams (DFDs) to identify data sources, destinations, and storage points, and document the flow to trace data from origin to final destination.

3. Identify physical and logical data repositories, AI models, APIs, and data backups in DFDs and data maps, and use these maps and flow diagrams to identify potential security risks and exposure areas.

4. Determine where data will be stored (on-premises, cloud regions, or countries), who is processing it and ensure it is confined to specific geographic areas as required. Establish measures to limit data storage and processing to specific geographic areas.

5. Implement access controls to restrict data access based on user roles, permissions, and security policies.

6. Secure data at rest, in transit, and in use with encryption techniques.

7. Implement measures to mask and anonymize data to prevent data loss.

8. Establish backup and recovery processes are implemented to restore data in case of loss or system failures.

9. Define data retention policies for how long data should be stored and when to securely dispose of it.

10. Establish a process for customers to specify where their data will be stored and notify them if data is replicated outside that area.

Implementation Guidelines for Cloud Service Providers (CSP)

[Applicable to all providers]

1. Maintain list of all data assets, their owners,sensitivity, origin, and processing methods.

2. Create data flow diagrams (DFDs) to identify data sources, destinations, and storage points, and document the flow to trace data from origin to final destination.

3. Identify physical and logical data repositories, AI models, APIs, and data backups in DFDs and data maps, and use these maps and flow diagrams to identify potential security risks and exposure areas.

4. Determine where data will be stored (on-premises, cloud regions, or countries), who is processing it and ensure it is confined to specific geographic areas as required. Establish measures to limit data storage and processing to specific geographic areas.

5. Implement access controls to restrict data access based on user roles, permissions, and security policies.

6. Secure data at rest, in transit, and in use with encryption techniques.

7. Implement measures to mask and anonymize data to prevent data loss.

8. Establish backup and recovery processes are implemented to restore data in case of loss or system failures.

9. Define data retention policies for how long data should be stored and when to securely dispose of it.

10. Establish a process for customers to specify where their data will be stored and notify them if data is replicated outside that area.

From CCM v4.1: Control Ownership Rationale. This is a “Shared (Dependent)” control for both the CSP and CSC because the CSP will ensure where data is stored, processed, and backed up in accordance with input from the CSC (and periodically thereafter, commensurate with the risk level of the third-party relationship). In cases of shared tenancy, the CSC should be allowed to request the physical location of customer data.

Implementation Guidelines. Applicable to all service models: This control implementation is not service delivery model specific (IaaS, PaaS, or SaaS). Irrespective of cloud service delivery model, the CSP is responsible to define and implement, processes, procedures and technical measures for storing, processing and backing up data in accordance with the requirement specified in the contract with CSC.

Recommendations to the CSP are:

• a. maintain a policy that defines the requirement to identify, classify, and record attributes for all assets (i.e., server hardware, software, data held on information systems, and information needed for disaster recovery and business continuity purposes). All assets should be tracked in an inventory system in accordance with the policy. Owner, classification, location should be identified and tracked in the asset tracking system. The inventory of assets should be reviewed at least on a quarterly basis to make sure each asset is protected in accordance with its classification, and to verify that the data inventory is accurate

• b. require the CSC to specify the particular geography where its data will be stored. The CSP should ensure that data is replicated only within a selected geographic area or region for redundancy. Data should not be replicated outside of a specified geography without first notifying the CSC, unless required by law

• c. design and architect low latency and highly available geographically dispersed storage services such as clustering, and provide replication to backup system software and data it is available with minimum loss

• d. provide services and tools to configure access, encryption, and logging features to help the CSC manage its operations effectively. The CSP should provide the CSC with the option to manage its own encryption keys

• e. not access or use customer content for any purpose other than as legally required and for maintaining the services provided to the the CSC

• f. not access any unencrypted data being transmitted, processed, or stored on the systems that run in their data centers which are geotagged. Data stored as synchronous replicas across different availability zones and regions, and the associated services, should be designed to recover quickly from availability zone and regional data failures

• g. as part of the vendor risk management program, audit its data centers yearly and review / maintain copies of attestation reports such as SOC2 Type 2

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

Shared Implementation Guidelines

[Applicable to all providers]

1. Establish standards and guidelines to track the origin, history, and transformations of data. This should include tracking data from its source through all stages of processing, storage and usage.

2. Identify and document all data sources, along with associated metadata and contextual information.

3. Implement mechanisms to automatically track data lineage and ensure data integrity through immutable logs and data versioning. Use digital signatures, checksums, or hash values to validate the integrity of incoming data.

4. Implement mechanisms to track changes and updates to data.

5. Establish and implement processes to make data sources available according to legal and regulatory requirements.

6. Implement access controls to ensure only authorized personnel can access data.

7. Establish and implement measures to track and manage consent and licensing agreements for data use.

8. Implement data catalogs to manage and audit data access and usage.

9. Establish and implement data handling processes in accordance with data protection laws and regulations, such as GDPR, HIPAA data traceability, AI model traceability under the EU AI act.

10. Perform regular audits to ensure compliance with legal and regulatory requirements.

11. Establish processes to inform stakeholders about data access policies and any changes to them.

12. Document all data transformations, such as imputation, normalization, and encoding.

13. Implement procedures to assign data stewardship roles and implement automated tracking systems.Protect audit logs from unauthorized access or tampering.

14. Implement monitoring and anomaly detection to enforce compliance and adjust processes.

15. Document data gaps and shortcomings that prevent compliance with regulations.

16. Implement data provenance checks as part of data quality and governance audits.

17.Establish mechanisms to integrate provenance tracking with data governance and ETL tools.

18.Implement segregation of duties among users who manage, consume, and audit provenance data to reduce fraud or manipulation risk.

1. Establish a process to securely dispose of provenance records when no longer needed, in alignment with organizational data lifecyle policies.

Implementation Guidelines for Cloud Service Providers (CSP)

[Applicable to all providers]

1. Establish standards and guidelines to track the origin, history, and transformations of data. This should include tracking data from its source through all stages of processing, storage and usage.

2. Identify and document all data sources, along with associated metadata and contextual information.

3. Implement mechanisms to automatically track data lineage and ensure data integrity through immutable logs and data versioning. Use digital signatures, checksums, or hash values to validate the integrity of incoming data.

4. Implement mechanisms to track changes and updates to data.

5. Establish and implement processes to make data sources available according to legal and regulatory requirements.

6. Implement access controls to ensure only authorized personnel can access data.

7. Establish and implement measures to track and manage consent and licensing agreements for data use.

8. Implement data catalogs to manage and audit data access and usage.

9. Establish and implement data handling processes in accordance with data protection laws and regulations, such as GDPR, HIPAA data traceability, AI model traceability under the EU AI act.

10. Perform regular audits to ensure compliance with legal and regulatory requirements.

11. Establish processes to inform stakeholders about data access policies and any changes to them.

12. Document all data transformations, such as imputation, normalization, and encoding.

13. Implement procedures to assign data stewardship roles and implement automated tracking systems.Protect audit logs from unauthorized access or tampering.

14. Implement monitoring and anomaly detection to enforce compliance and adjust processes.

15. Document data gaps and shortcomings that prevent compliance with regulations.

16. Implement data provenance checks as part of data quality and governance audits.

17.Establish mechanisms to integrate provenance tracking with data governance and ETL tools.

18.Implement segregation of duties among users who manage, consume, and audit provenance data to reduce fraud or manipulation risk.

1. Establish a process to securely dispose of provenance records when no longer needed, in alignment with organizational data lifecyle policies.

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.

Shared Implementation Guidelines

[All Actors]

1. Data Governance and Source Validation

   • a. Define clear metrics for “fit for purpose” data

   • b. Develop data source vetting and validation procedures

   • c. Implement data provenance and lineage tracking

   • d. Implement digital signature validation to verify the integrity and authenticity of models, datasets and software components before use in AI pipelines.

2. Data Processing and Monitoring

   • a. Establish a process to periodically audit datasets for integrity.

   • b. Use anomaly detection and drift monitoring to identify deviations, set thresholds for deviations, and implement alerts to notify data owners of potential issues

   • c. Implement real-time monitoring of data distributions and statistical patterns to detect anomalous changes in training data.

   • d. Establish baseline metrics and threshold monitoring for early detection of data manipulation attempts.

3. Technical Measures

   • a. Perform data integrity checks for data used in AI systems to detect alteration, corruption and tampering of data.

   • b. Maintain detailed audit logs of who accessed, modified, or submitted data, with timestamps and user authentication to trace potential poisoning attempts.

   • c. Report unusual patterns or unexpected model behaviors promptly to model provider.

   • d. Conduct periodic reviews of model outputs against expected business outcomes.

Implementation Guidelines for Cloud Service Providers (CSP)

1. Implement access control and authentication mechanism to secure training data.

2. Enable data provenance features for traceability.

3. Monitor datasets to detect unauthorized data access or manipulation.

4. Implement version control and immutability features to track dataset changes.

5. Implement secure transmission channels for data transmission and storage to prevent tampering.

[All Actors]

1. Data Governance and Source Validation

   • a. Define clear metrics for “fit for purpose” data

   • b. Develop data source vetting and validation procedures

   • c. Implement data provenance and lineage tracking

   • d. Implement digital signature validation to verify the integrity and authenticity of models,datasets and software components before use in AI pipelines.

2. Data Processing and Monitoring

   • a. Establish a process to periodically audit datasets for integrity.

   • b. Use anomaly detection and drift monitoring to identify deviations, set thresholds for deviations, and implement alerts to notify data owners of potential issues

   • c. Implement real-time monitoring of data distributions and statistical patterns to detect anomalous changes in training data.

   • d. Establish baseline metrics and threshold monitoring for early detection of data manipulation attempts.

3. Technical Measures

   • a. Perform data integrity checks for data used in AI systems to detect alteration, corruption and tampering of data.

   • b. Maintain detailed audit logs of who accessed, modified, or submitted data, with timestamps and user authentication to trace potential poisoning attempts.

   • c. Report unusual patterns or unexpected model behaviors promptly to model provider.

   • d. Conduct periodic reviews of model outputs against expected business outcomes.

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.

Shared Implementation Guidelines

[All Actors]

1. Conduct Risk and Privacy Impact Analysis

   • a. Define Privacy risk and impact assessment framework which encompasses AI specific privacy risks.

   • b. Document the purpose, scope and intended outcome of AI system.

   • c. Implement a risk classification system (Low, moderate, high) based on use case and data sensitivity.

   • d. Update the Privacy risk and impact assessment framework as new risks are identified, along with regulation changes.

2. Selection of Privacy Enhancing Technologies (PETs) aligned with Business Objectives

   • a. Establish guidelines to facilitate selection of PET based on risk profile and business objective, such as; a.Low Risk - Data minimization, pseudonymization, and anonymization. b.Moderate Risk - Differential Privacy, synthetic data,secure data enclaves. c.High Risk - Federated learning, secure multi-party computation (SMPC) or homomorphic encryption.

   • b. Document selected PETs, and engage legal, compliance and audit team stakeholders for review.

   • c. Conduct periodic evaluation as business use case evolves.

3. List of Privacy Enhancing Technologies for Training Data - Organization should consider selecting PETs aligned with their business use case and results of privacy impact assessment to mitigate identified risks

   • a. Differential Privacy- Mathematical noise added to data or model outputs to prevent leakage of individual data points.

   • b. Business Use Case- Training sensitive datasets without revealing specific individual records.

   • c. Federated Learning- AI models are trained locally on servers and model updates are aggregated.

   • d. Business Use case- Limitation on sharing raw data due to privacy or proprietary concerns.C.Homomorphic Encryption- AI models are trained with encrypted data computations. e.Business Use Case- Limitation of sharing unencrypted data due to privacy concerns.

   • e. Confidential Computing - AI models are trained in hardware-based Trusted Execution Environment (TEEs), known as secure enclaves.

   • f. Business Use Case - Data to be processed in secure hardware environments such as financial transactions.Secure Multi-Party Computation (SMPC) - AI models are trained on split data obtained from multiple parties.

   • g. Business Use Case - Multiple parties need to collaborate on private data without revealing individual inputs.

   • h. Data Anonymization - AI models are trained on datasets which have removed or masked identifiable information.

   • i. Business Use Case - Data sharing should consider privacy law or regulatory standards. k..Data Pseudonymization - AI models are trained on datasets which have replaced identifiable information with reversible tokens or identifiers.

   • j. Business Use Case - Data should remain linkable for analysis and business operations.

4. Monitoring and Review

   • a. Monitor privacy metrics, and perform periodic compliance assessments to verify Privacy Enhancing Technologies (PETs) effectively meet privacy objectives, regulatory requirements, and business use case specifications.

   • b. Evaluate and monitor privacy enhancing technologies effectiveness.

   • c. Establish performance baselines and acceptable latency thresholds for each PET implementation.

Implementation Guidelines for Cloud Service Providers (CSP)

1. Document the purpose, scope and intended outcome of AI models.

2. Implement PETs during model training.

3. Evaluate PET impact on model performance.

[All Actors]

1. Conduct Risk and Privacy Impact Analysis

   • a. Define Privacy risk and impact assessment framework which encompasses AI specific privacy risks.

   • b. Document the purpose, scope and intended outcome of AI system.

   • c. Implement a risk classification system (Low, moderate, high) based on use case and data sensitivity.

   • d. Update the Privacy risk and impact assessment framework as new risks are identified, along with regulation changes.

2. Selection of Privacy Enhancing Technologies (PETs) aligned with Business Objectives

   • a. Establish guidelines to facilitate selection of PET based on risk profile and business objective, such as; a.Low Risk - Data minimization, pseudonymization, and anonymization. b.Moderate Risk - Differential Privacy, synthetic data,secure data enclaves. c.High Risk - Federated learning, secure multi-party computation (SMPC) or homomorphic encryption.

   • b. Document selected PETs, and engage legal, compliance and audit team stakeholders for review.

   • c. Conduct periodic evaluation as business use case evolves.

3. List of Privacy Enhancing Technologies for Training Data - Organization should consider selecting PETs aligned with their business use case and results of privacy impact assessment to mitigate identified risks

   • a. Differential Privacy- Mathematical noise added to data or model outputs to prevent leakage of individual data points.

   • b. Business Use Case- Training sensitive datasets without revealing specific individual records.

   • c. Federated Learning- AI models are trained locally on servers and model updates are aggregated.

   • d. Business Use case- Limitation on sharing raw data due to privacy or proprietary concerns.C.Homomorphic Encryption- AI models are trained with encrypted data computations. e.Business Use Case- Limitation of sharing unencrypted data due to privacy concerns.

   • e. Confidential Computing - AI models are trained in hardware-based Trusted Execution Environment (TEEs), known as secure enclaves.

   • f. Business Use Case - Data to be processed in secure hardware environments such as financial transactions.Secure Multi-Party Computation (SMPC) - AI models are trained on split data obtained from multiple parties.

   • g. Business Use Case - Multiple parties need to collaborate on private data without revealing individual inputs.

   • h. Data Anonymization - AI models are trained on datasets which have removed or masked identifiable information.

   • i. Business Use Case - Data sharing should consider privacy law or regulatory standards. k..Data Pseudonymization - AI models are trained on datasets which have replaced identifiable information with reversible tokens or identifiers.

   • j. Business Use Case - Data should remain linkable for analysis and business operations.

4. Monitoring and Review

   • a. Monitor privacy metrics, and perform periodic compliance assessments to verify Privacy Enhancing Technologies (PETs) effectively meet privacy objectives, regulatory requirements, and business use case specifications.

   • b. Evaluate and monitor privacy enhancing technologies effectiveness.

   • c. Establish performance baselines and acceptable latency thresholds for each PET implementation.

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.

Shared Implementation Guidelines

[All Actors]

1. Data Consistency and Conformity Checks

   • a. Implement a process for validation of datasets to ensure schema consistency, format conformity and label accuracy.

   • b. Define data quality metrics (missing values, duplication rate, label distribution) and monitor deviations over time.

2. Dataset Versioning

   • a. Maintain change logs to document changes along with rationale and approver history.

   • b. Maintain dataset version linkage to corresponding model version and training configuration.

3. Access Control

   • a. Implement role based access controls to ensure access is limited to authorized personnel.

   • b. Implement approval workflows for any modification to AI datasets.

4. Monitoring

   • a. Conduct periodic reviews to detect drift, corruption or misuse of AI datasets.

Implementation Guidelines for Cloud Service Providers (CSP)

1. Implement a process to check data at ingestion for consistency and usability (Schema enforcement).

2. Implement dataset version control to track and manage changes to data.

3. Implement role-based access control (RBAC) and establish approval workflows for any dataset updates.

4. Establish regular data integrity checks to detect dataset corruption, alteration, or tampering.

[All Actors]

1. Data Consistency and Conformity Checks

   • a. Implement a process for validation of datasets to ensure schema consistency, format conformity and label accuracy.

   • b. Define data quality metrics (missing values, duplication rate, label distribution) and monitor deviations over time.

2. Dataset Versioning

   • a. Maintain change logs to document changes along with rationale and approver history.

   • b. Maintain dataset version linkage to corresponding model version and training configuration.

3. Access Control

   • a. Implement role based access controls to ensure access is limited to authorized personnel.

   • b. Implement approval workflows for any modification to AI datasets.

4. Monitoring

   • a. Conduct periodic reviews to detect drift, corruption or misuse of AI datasets.

DSP-24: Data Differentiation and Relevance

Control Specification

Ensure training-data differentiation and relevance to the intended use of the AI Model.

Shared Implementation Guidelines

[All Actors]

1. Data Assessment and Classification - Implement data quality assessment frameworks such as Data Quality for AI (DQAI framework) that evaluate AI aspects like correctness, completeness, consistency , timeliness and bias.

2. Use-case Alignment

   • a. Define the real world problem AI is being designed to solve, document AI objective and expected output, this will determine the selection of dataset for AI model.

   • b. Evaluate relevance of training data periodically to ensure if aligns with defined business use case.

3. Monitoring - Implement a feedback loop among all stakeholders to monitor and obtain feedback on model behavior.

Implementation Guidelines for Cloud Service Providers (CSP)

1. Define the specific problem the AI model is designed to solve, document model objectives and collaborate with model provider.

2. Implement a feedback loop where data collected from Application Provider and AI customer feedback is validated, refined and versioned, this data to be provided to Model Provider for retraining the AI model.

[All Actors]

1. Data Assessment and Classification - Implement data quality assessment frameworks such as Data Quality for AI (DQAI framework) that evaluate AI aspects like correctness, completeness, consistency , timeliness and bias.

2. Use-case Alignment

   • a. Define the real world problem AI is being designed to solve, document AI objective and expected output, this will determine the selection of dataset for AI model.

   • b. Evaluate relevance of training data periodically to ensure if aligns with defined business use case.

3. Monitoring - Implement a feedback loop among all stakeholders to monitor and obtain feedback on model behavior.

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.

Shared Implementation Guidelines

[Application Provider/Orchestrated Service Provider/AI Customer]

1. Establish an internal AI governance policy aligned with the provider’s guidelines, tailoring it to the consumer’s organizational goals and regulatory requirements.

2. Integrate AI risk management into existing governance structures, specifying roles for data governance, risk management, and compliance teams focusing on AI.

3. Evaluate and approve AI use cases, ensuring they comply with established organizational ethics, data protection standards, and risk appetite.

4. Conduct reviews of AI systems and processes, including checks for data integrity, model bias, and performance.

5. Maintain documented procedures that outline the consumer’s responsibilities, escalation paths, and communication protocols with the AI service provider.

Implementation Guidelines for Cloud Service Providers (CSP)

From CCM v4.1: Control Ownership Rationale. This control applies to all service models (IaaS, PaaS, SaaS) because the implementation of a Governance, Risk and Compliance (GRC) program takes place at an organizational level, irrespective of cloud service model. Establishing a program for good information and technology governance, risk management, and compliance is important for all organizations, whether operating in a service consumer or service provider role.

This control’s implementation responsibility is “Shared” because both the CSP and the CSC each need to have their own respective Governance, Risk, and Compliance (GRC) programs to cover their operations, products, and services, and the establishment of such a program is fully internal and unique to each organization, including the associated policies and procedures. The CSP and the CSC each independently establish their own respective policies and procedures for these functions. Because the GRC program is an organizational-level function, the Shared (Independent) ownership of this control applies irrespective of the types of cloud services provided or consumed.

Implementation Guidelines. Applicable to all service models: Establishing robust policies and procedures for an information governance program is paramount for CSPs and CSCs in the context of cloud computing and security.

A well-defined Risk Management Program ensures that potential threats and vulnerabilities associated with cloud services are systematically identified, assessed, and mitigated, reducing the likelihood of security breaches. Organizational policies and procedures contribute to the clarity and consistency of operations, ensuring that all stakeholders, including CSCs, adhere to established standards and regulatory requirements. A policy should be mapped with the organization’s governing mission as its focus and should always remain up-to-date with the direction and needs of the organization.

The implementation of an Information Security Program aids CSPs safeguarding sensitive data, as it delineates encryption standards, access controls, and incident response plans, fortifying the overall security posture. These policies collectively form the cornerstone of a resilient information governance framework, instilling confidence in both CSPs and CSC by addressing risks, ensuring compliance, and enhancing overall cloud security.

Both the CSP and CSC should have a robust governance program in place. Top leadership is ultimately responsible for ensuring the program is properly implemented. A core element of governance is that the people tasked with it should have the authority to enforce it.

The CSP and CSC each have their own business needs and requirements for policies and procedures. These should cover the main security objectives of the cloud organization, the rationale for these objectives, approvals, and the review process. Policies should also delineate roles and responsibilities within the cloud organization, stating who should do what, where, when and how.

Policies should include (but not limited to) provisions on the following:

• a. Scope and Objectives: A comprehensive information governance program should be established to effectively manage and protect the organization’s information assets, supporting business objectives, complying with applicable regulations. The scope of the information governance program should be defined, specifying the types of information covered, the organizational units involved, and the geographic locations where the program applies. The scope should include (but not limited to):

  • i. all relevant information assets, including data, documents, records, and intellectual property.

  • ii. the ownership and custodianship of information assets

  • iii. the appropriate lifecycle management for information assets, including creation, storage, access, retention, and disposal

  • iv. guidelines for handling sensitive information, such as personal data and protected health information (PHI)

• b. Risk Management Program: A risk management framework that aligns with the organization’s overall risk appetite and business objectives should be established. The ERM should:

  • i. Identify, assess, and prioritize cloud-related risks, including data security, privacy, compliance, and operational risks

  • ii. Implement appropriate risk mitigation strategies, such as data encryption, access controls, and regular security audits

  • iii. Continuously monitor and evaluate cloud-related risks and adapt risk mitigation strategies as needed

• c. Organizational Policy Reviews: Organizational policies and procedures should be regularly reviewed and updated to ensure they remain aligned with the organization’s evolving business needs and regulatory requirements.

• d. Policy Exception Process: a formal policy exception process should be established that is transparent, accountable, and auditable

  • i. criteria for approving policy exceptions should be defined, ensuring that exceptions are granted only in emergencies and/or under well justified circumstance

  • ii. senior management approval should be required for all policy exceptions

  • iii. all policy exceptions should be documented and tracked, including the rationale for approval and the mitigating measures implemented

• e. Information Security Program: An information security program should be implemented that aligns with industry best practices and relevant regulatory requirements, and includes all relevant domains of the latest up to date version of the Cloud Controls Matrix (CCM)

• f. Governance Responsibility Model: Roles and responsibilities for planning, implementing, operating, assessing, and improving cloud governance programs should be defined.

  • i. Establish a governance committee or steering group with representatives from various departments, including IT, legal, compliance, and risk management

  • ii. Specific responsibilities should be delegated to individual teams or roles, ensuring that accountability is assigned and documented

  • iii. Regular training should be provided to all stakeholders on their governance responsibilities

• g. Information System Regulatory Mapping: all relevant standards, regulations, legal/contractual, and statutory requirements that apply to cloud-based information systems should be identified and documented. A regulatory mapping registry should be maintained that is regularly updated to reflect changes in regulatory requirements.

• h. Special Interest Groups: relationships with relevant cloud-related special interest groups, industry organizations, and government agencies should be established and maintained

  • i. Participate in industry forums, conferences, and workshops to stay up-to-date on emerging cloud technologies, trends, and regulatory developments

  • ii. Share best practices and insights with other cloud organizations through industry forums and publications

  • iii. Collaborate with cloud industry experts to address common cloud-related challenges and develop innovative solutions i. Approval: Approval requirements and senior management involvement to ensure alignment with the organization’s strategic goals and risk appetite i. An approval process should be established for any changes or modifications to the policy and procedures ii. A documented record of approvals (including dates, names of approvers, and any relevant comments or discussions) should be maintained

• i. Communication: Effective communication of the policy and procedures should be facilitated to all relevant cloud stakeholders

• j. Maintenance and Reviews: Information governance policies and procedures should be documented, reviewed and updated at least annually to ensure alignment with evolving cloud security landscape and to reflect changes in cloud technology, regulations, and risks

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.

Shared Implementation Guidelines

[Application Provider/Orchestrated Service Provider/AI Customer]

1. Establish AI Risk Ownership: Define clear ownership for AI-related risks within your organization, ensuring alignment with the provider’s risk management strategies.

2. Validate AI Model Usage: Identify key risks (e.g., data privacy, potential biases) in the AI solutions consumed and work with the provider to implement safeguards.

3. Integrate AI Into ERM Processes: Incorporate AI-specific risk categories, such as accuracy, fairness, and explainability, into your existing ERM and governance frameworks.

4. Conduct Independent (from Model Provider) Evaluations: Regularly assess critical AI solutions for performance, fairness, and security issues. Request evidence of the provider’s compliance with internal risk management policies.

5. Establish Incident Response Collaboration: Collaborate with the provider to handle AI-related incidents promptly. Document shared responsibilities for remediation, including communication and escalation procedures.

Implementation Guidelines for Cloud Service Providers (CSP)

[Application Provider/Orchestrated Service Provider/AI Customer]

1. Establish AI Risk Ownership: Define clear ownership for AI-related risks within your organization, ensuring alignment with the provider’s risk management strategies.

2. Validate AI Model Usage: Identify key risks (e.g., data privacy, potential biases) in the AI solutions consumed and work with the provider to implement safeguards.

3. Integrate AI Into ERM Processes: Incorporate AI-specific risk categories, such as accuracy, fairness, and explainability, into your existing ERM and governance frameworks.

4. Conduct Independent (from Model Provider) Evaluations: Regularly assess critical AI solutions for performance, fairness, and security issues. Request evidence of the provider’s compliance with internal risk management policies.

5. Establish Incident Response Collaboration: Collaborate with the provider to handle AI-related incidents promptly. Document shared responsibilities for remediation, including communication and escalation procedures.

From CCM:

Control Ownership Rationale. This control’s implementation responsibility is typically shared between the CSP and CSC and expected to be independently implemented by each party, since the establishment of such a program is fully internal and unique to each organization and each needs to have its own respective ERM program established to cover its operations, products, and services. The CSP and the CSC each independently establish their own respective policies and procedures for identification, evaluation, ownership, treatment, and acceptance of risks, including those pertaining to cloud security and privacy risks. Risk management for an organization is ultimately owned by that organization’s leadership.

An ERM program, as with all Governance and Risk Compliance (GRC) topics, should be implemented at the organizational level and should be independent of the type of cloud service delivery model and irrespective of the types of cloud services provided or consumed. Cloud organizations, whether operating in a cloud service consumption or cloud service provider role, need to appropriately manage risk, and to establish a formal, documented, leadership-sponsored Enterprise Risk Management program.

Implementation Guidelines. Applicable to all service models: Enterprise Risk Management (ERM) is the overall management of risk for an organization. The service agreement or contract defines important elements such as the scope of services, service levels, responsibilities and obligations, among others, between a CSP and a CSC. While the contract may or may not define roles and responsibilities in detail, and may not address responsibilities for risk management, an entity can never fully outsource its ultimate responsibility and accountability for risk management to an external provider. The purpose of risk management is the creation and protection of value. The risk management process involves the systematic application of policies, procedures, and practices to the activities of communicating and consulting, establishing the context and assessing, treating, monitoring, reviewing, recording, and reporting risk. Risk for the CSP should be calculated using a risk appetite framework that defines the risk capacity or the maximum amount of residual risk it will accept after controls and other measures have been put in place.

The risk management process should be an integral part of management and decision-making and integrated into the structure, operations and processes of the organization. It can be applied at strategic, operational, program, or project levels. There can be many applications of the risk management process within an organization, customized to achieve objectives and to suit the external and internal context in which they are applied. As part of the ERP program, the Information security risk management process should exist.

The Information security risk management should also include cloud-relevant information security and data privacy risks when applicable to the organization.

The CSP and CSP should both have information security risk management processes in place. They are advised to align to the STAR Program and other widely known cyber/cloud security frameworks and standards

If the CSP uses the services of other providers,, it should ensure information security levels to the CSC are maintained or exceeded. When the CSP provides services based on a supply chain, the CSP should provide information security objectives to suppliers, and request that each of the suppliers perform risk management activities to achieve the objectives.

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.

Shared Implementation Guidelines

[All Actors]

1. Review AI- and cloud-related policy, procedure and governance document at least annually or immediately after a material change (new model, regulation, technology, acquisition).

2. Align policies with current industry standards, ethical-AI guidelines and applicable regulations (data quality, transparency, bias mitigation, security).

3. Run a documented change-management process for policy updates, including stakeholder notification, approval and version control.

4. Maintain a central repository or dashboard that tracks policy status, next-review dates and outstanding actions; grant stakeholders read access.

5. Trigger interim reviews from continuous-monitoring signals (for example, model-drift alerts, incident post-mortems, new threat intel) so that policies evolve with operational risk.

6. Provide periodic training or awareness sessions so staff understand updated responsibilities for responsible-AI, privacy and security.

Implementation Guidelines for Cloud Service Providers (CSP)

[All Actors]

1. Review AI- and cloud-related policy, procedure and governance document at least annually or immediately after a material change (new model, regulation, technology, acquisition).

2. Align policies with current industry standards, ethical-AI guidelines and applicable regulations (data quality, transparency, bias mitigation, security).

3. Run a documented change-management process for policy updates, including stakeholder notification, approval and version control.

4. Maintain a central repository or dashboard that tracks policy status, next-review dates and outstanding actions; grant stakeholders read access.

5. Trigger interim reviews from continuous-monitoring signals (for example, model-drift alerts, incident post-mortems, new threat intel) so that policies evolve with operational risk.

6. Provide periodic training or awareness sessions so staff understand updated responsibilities for responsible-AI, privacy and security.

Map CSP controls and services to major governance frameworks (e.g., ISO/IEC 38505, NIST AI RMF, EU AI Act, COSO ERM).

Provide customers with detailed control mapping documentation to support alignment with enterprise governance policies.

Offer tools or APIs that enable customers to assess alignment between their AI workloads and governance benchmarks.

Publish whitepapers or reference architectures illustrating best practices for governance alignment using CSP services.

Collaborate with enterprise clients to address gaps between their governance models and CSP offerings, including tailored configurations or supplemental controls.

From CCM: Control Ownership Rationale. This control applies to all service models (IaaS, PaaS, or SaaS) because periodical reviews of policies and procedures as with all Governance And Risk Compliance (GRC) topics, should be implemented at the Organizational level, to ensure they are still up to date, relevant and valid for the Organization, independent of the type of cloud service model. The ownership of this control is Shared (Independent) because both the CSP and the CSC each separately need to perform periodic reviews of their organization’s policies and procedures, and each organization is fully responsible for performing the reviews of its own organizational policy while having no responsibilities for the review of another organization’s policies. Because the need for review of an organization’s policies is an organizational-level function covering all operations, products, and services of the enterprise, the Shared (Independent) ownership of this control applies irrespective of the types of cloud services provided or consumed.

Implementation Guidelines. Applicable to all service models: Executive or senior management approval and commitment with the information security policies is necessary to legitimize the need and acts of the information security professionals and ensure that Information security strategy is a key and relevant part of the organization strategy and expectations.

Senior executive responsible parties (CISO, CSO or equivalent responsible) should be able to simply communicate and gain top management on the information security vision and mission to successfully implement any information security strategy or programs. Top management should understand this information in order to provide the necessary support, budgets and resources needed. Information Security policies are the foundations of security strategies and programs and the way to ensure all organizational staff are aware, onboarded and knowing what they need to do.

Updating policies, standards and related guidance regularly is important to ensure that the guidance is still relevant to the business needs, no longer in compliance with new laws and regulations, or no longer valid for the environment and technology currently in use. It’s recommended to review policies, standards and related guidance at least annually or when a substantial change occurs within the organization (e.g. new technology introduced into the organization, cybersecurity incident, major operational change, changes in legal and regulatory environment, etc.)

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.

Shared Implementation Guidelines

[All Actors]

1. Operate a formal, documented exception workflow: all deviations from policy must be raised, risk-assessed, approved at the appropriate level, recorded, and time-boxed.

2. Define clear eligibility criteria for when an exception can be requested (e.g., emergency patch, experimental feature, urgent business need).

3. Perform a risk assessment and specify mitigating controls; confirm the exception will not violate security, privacy, or compliance requirements.

4. Log rationale, approvals, expiry dates and compensating controls in a system accessible for audit and review.

5. Notify all affected stakeholders (security, legal, business owners, external partners if relevant) and coordinate any downstream impacts.

6. Review exceptions on a schedule or when context changes; retire or renew them to maintain alignment with policy, regulation and organisational risk appetite.

Implementation Guidelines for Cloud Service Providers (CSP)

1. Offer AI service availability SLAs and DR options with configurable RTO/RPO parameters.

2. Provide automated failover and multi-region redundancy capabilities for customer workloads.

3. Support customers in defining and testing business continuity and recovery scenarios in shared-responsibility models.

4. Ensure resiliency of cloud-native services (e.g., storage, messaging, compute) to minimize AI downtime.

5. Share documentation and runbooks outlining CSP-side disaster recovery procedures and dependencies.

[All Actors]

1. Operate a formal, documented exception workflow: all deviations from policy must be raised, risk-assessed, approved at the appropriate level, recorded, and time-boxed.

2. Define clear eligibility criteria for when an exception can be requested (e.g., emergency patch, experimental feature, urgent business need).

3. Perform a risk assessment and specify mitigating controls; confirm the exception will not violate security, privacy, or compliance requirements.

4. Log rationale, approvals, expiry dates and compensating controls in a system accessible for audit and review.

5. Notify all affected stakeholders (security, legal, business owners, external partners if relevant) and coordinate any downstream impacts.

6. Review exceptions on a schedule or when context changes; retire or renew them to maintain alignment with policy, regulation and organisational risk appetite.

From CCM v4.1: Control Ownership Rationale. This control applies to all service models (IaaS, PaaS, or SaaS), because following GRC-01, both should have their own security policies. Any exception to those policies will be also independent of a cloud service model.

Managing exceptions to organizational policies, standards, procedures, and other directives is an important aspect of an organization’s risk management. The CSP and the CSC each independently establish their own policies and procedures for their respective organizations as well as independently manage risk for their respective organizations, and the associated process for managing exceptions to such policies is similarly and accordingly a Shared (Independent) function.

Because organizational policy management and organizational risk management programs are organizational-level functions, the Shared (Independent) ownership of this control applies irrespective of the types of cloud services provided or consumed.

Implementation Guidelines. Applicable to all service models: The implementation guidance provided for the CSP applies.

Also, it is recommended that the CSC keeps close contact and open dialogue with the CSP, to understand if an exception or risk that triggered an exception should be included in the CSP’s security roadmap in the future.

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.

Shared Implementation Guidelines

[All Actors]

1. Develop a comprehensive information security program that addresses AI model, data, infrastructure, and platform security requirements.

2. Incorporate AI-specific controls into the broader security framework, including adversarial testing, model integrity checks, and training data validation.

3. Ensure alignment with regulatory frameworks (e.g., NIST CSF, ISO 27001, SOC 2) and AI-specific risk guidance.

4. Regularly review and update the program to reflect threat intelligence, audit findings, and architectural changes.

5. Provide continuous training to all relevant personnel on secure AI system design, deployment, and monitoring.

Implementation Guidelines for Cloud Service Providers (CSP)

1. Enable integration of customer AI workloads with CSP-native incident detection, alerting, and response tools.

2. Provide access to incident dashboards, logs, and root cause analysis reports relevant to customer workloads.

3. Define clear responsibilities and escalation paths for AI-related incidents within shared responsibility.

4. Offer tools for proactive threat hunting and AI service-level anomaly detection.

5. Allow customers to subscribe to real-time incident communications and remediation updates.

[All Actors]

1. Develop a comprehensive information security program that addresses AI model, data, infrastructure, and platform security requirements.

2. Incorporate AI-specific controls into the broader security framework, including adversarial testing, model integrity checks, and training data validation.

3. Ensure alignment with regulatory frameworks (e.g., NIST CSF, ISO 27001, SOC 2) and AI-specific risk guidance.

4. Regularly review and update the program to reflect threat intelligence, audit findings, and architectural changes.

5. Provide continuous training to all relevant personnel on secure AI system design, deployment, and monitoring.

From CCM v4.1: Control Ownership Rationale. This control’s implementation responsibility is shared between the CSP and the CSC, in an independent manner. It is fully and independently the responsibility of each the CSP and the CSC to establish their own separate respective information security programs. It is neither the CSP’s responsibility to develop or implement the CSC’s information security program nor is it the CSC’s responsibility to develop or implement the CSP’s information security program.

The CSP’s ownership of this control relates to developing and implementing one or more information security programs covering the CSP’s own internal organizational units and associated assets and processes as well as covering the services offered to its CSCs and associated assets and processes. The CSP does not have responsibility to develop or implement information security programs for the CSC.

The Shared (Independent) control ownership applies to all provided service models (IaaS, PaaS, and SaaS) because the CSP’s program should address all services offered to its CSCs.

Use of the CCM domains will ensure all relevant cloud security aspects are included within the Information Security Program and provide major alignment to STAR and other widely known cyber/cloud security frameworks and standards.

Implementation Guidelines. Applicable to all service models: The CSP should have its own security program as recommended by industry best practices, and cover all technology, information, process, and personnel aspects. It should designate roles and responsibilities where appropriate that are aligned within their organization, and document allocation of responsibilities with the CSC and its third-party providers..

The CSP should use feedback and reports from the CSC to enhance its Information Security Program. It should try to cover the CSC’s needs and specific regulatory and legal requirements (e.g., HIPAA, PCI DSS, GDPR, FedRAMP). It is key that the CSP understands that the CSC still needs assurance that contractual and regulatory obligations are being met.

The CSP might allow the CSC to perform security assessments of the CSP’s infrastructure. The CSP could also publish its official certifications and attestations, clearly defining the scope, its conditions, and specific controls that were evaluated. STAR offers a central repository for providers to publish such documents.

GRC-06: Governance Responsibility Model

Control Specification

Define and document roles and responsibilities for planning, implementing, operating, assessing, and improving governance programs.

Shared Implementation Guidelines

[All Actors]

1. Define and document governance responsibilities across the AI lifecycle, including roles for data governance, model oversight, risk acceptance, compliance, and incident response.

2. Capture those assignments in a RACI (Responsible / Accountable / Consulted / Informed) matrix that covers internal staff and external partners.

3. Align role definitions with organisational structure, separation-of-duties requirements and applicable regulations / standards.

4. Establish escalation paths and communication channels for governance conflicts or non-compliance.

5. Review and update the role catalogue at least annually (or after major organisational / regulatory change) and redistribute it to all stakeholders.

Implementation Guidelines for Cloud Service Providers (CSP)

1. Provide compliance documentation (e.g., SOC 2, ISO 27001, FedRAMP) relevant to AI infrastructure and workloads.

2. Maintain data processing addendums (DPAs) and regional hosting options aligned with legal requirements.

3. Offer regional failover and localization features to support compliance with jurisdictional boundaries.

4. Enable configurable retention, encryption, and access policies in line with regulatory requirements.

5. Collaborate with customers to map responsibilities in cross-jurisdictional compliance obligations.

[All Actors]

1. Define and document governance responsibilities across the AI lifecycle, including roles for data governance, model oversight, risk acceptance, compliance, and incident response.

2. Capture those assignments in a RACI (Responsible / Accountable / Consulted / Informed) matrix that covers internal staff and external partners.

3. Align role definitions with organisational structure, separation-of-duties requirements and applicable regulations / standards.

4. Establish escalation paths and communication channels for governance conflicts or non-compliance.

5. Review and update the role catalogue at least annually (or after major organisational / regulatory change) and redistribute it to all stakeholders.

From CCM v4.1: Control Ownership Rationale. This control is independent of IaaS, PaaS, SaaS since Governance And Risk Compliance (GRC) is applicable for all cloud service models. Both The CSP and CSC should define and implement their own roles, responsibilities, and management commitment within their respective organizations.

Implementation Guidelines. Applicable to all service models: The CSP, as part of its governance duties, should formalize a clear RACI model to emphasize that information security is a core responsibility. Individuals should be identified who have the accountability and authority to direct, enable, and oversee cloud service offerings, including associated information security and risk.

Specifically, the CSP should appoint a responsible individual or group to deal with the CSC’s security programs related to the infrastructure and applications hosted on its platforms. This person or group should be responsible for addressing all the CSC’s security concerns and communicate clearly and transparently with when relevant security information is available and ready to release.

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.

Shared Implementation Guidelines

[All Actors]

1. Identify and document all relevant regulations, standards, and compliance obligations applicable to the AI systems and supporting infrastructure.

2. Map organizational AI activities to regulatory frameworks (e.g., GDPR, HIPAA, ISO/IEC 27001, NIST AI RMF), and document how compliance is achieved or gaps are mitigated.

3. Maintain a centralized regulatory mapping matrix that associates specific controls and policies with legal and industry requirements.

4. Update the mapping regularly to reflect changes in legal interpretations, industry norms, or AI system capabilities.

5. Ensure teams responsible for AI development and operations have access to the mapped requirements and understand their obligations.

Implementation Guidelines for Cloud Service Providers (CSP)

1. Vet and continuously monitor third-party providers used in delivering AI services (e.g., GPU vendors, SaaS ML tools).

2. Disclose material subcontractors and dependencies in the AI service delivery chain.

3. Offer integration with third-party risk scoring tools and APIs for customer assessments.

4. Notify customers about any changes to third-party vendors that may impact AI workloads.

5. Provide certifications or audit reports for key third-party infrastructure components used.

[All Actors]

1. Identify and document all relevant regulations, standards, and compliance obligations applicable to the AI systems and supporting infrastructure.

2. Map organizational AI activities to regulatory frameworks (e.g., GDPR, HIPAA, ISO/IEC 27001, NIST AI RMF), and document how compliance is achieved or gaps are mitigated.

3. Maintain a centralized regulatory mapping matrix that associates specific controls and policies with legal and industry requirements.

4. Update the mapping regularly to reflect changes in legal interpretations, industry norms, or AI system capabilities.

5. Ensure teams responsible for AI development and operations have access to the mapped requirements and understand their obligations.

From CCM v4.1: Control Ownership Rationale. This control is independent of the service model (IaaS, PaaS, SaaS) or on-premise architecture since GRC is applicable to all. The CSP and CSC should each independently analyze and include into their Information Security Programs all relevant standards-related, regulatory, legal/contractual, and/or statutory security controls applicable, and how these controls serve the business needs and use cases.

Implementation Guidelines. Applicable to all service models: The CSP should carefully consider the alignment and adequacy of its control requirements mapping to ensure all contractual requirements are adequately fulfilled. The CSP should make significant effort to identify, review, and document all legal, regulatory, contractual, statutory, or industry standards and their requirements, including any that are relevant to its country of operation or industry service.

The internal control framework that is utilized, and all policies and governance regimes in place within the organization, should make specific references or incorporate the above requirements to maintain a consistent and cohesive approach to the organization’s responsibilities. The CCM Control A&A-04 requires verification of the requirements as defined within this control. The CSP should make sure it identifies and documents its specific applicability to the various requirements, including how it complies with them.

The CSP should then seek to get external verification through certifications, audits, assessments, or attestations for demonstrating to the CSC due diligence is done (e.g., gaining PCI DSS certification showing compliance with the payment card industry standard).

The CSP should consider the requirements of the majority of its CSCs, and may wish to implement specific or additional controls to enhance its standing and promote growth in new areas.

In arranging services with its own suppliers, the CSP should carefully consider the alignment and adequacy of the subservice organization/upstream supplier’s control requirements mapping (as relevant to the respective service offering contract/service agreement) against the CSP’s own, analyzing and identifying the implication of any gaps, so that it can determine whether it can use the service to achieve its objectives, and implement and manage any additional customer-side controls needed to fulfill its own requirements.

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.

Shared Implementation Guidelines

[All Actors]

1. Establish channels for engaging with cloud- and AI-related special interest groups, consortia, or industry bodies.

2. Encourage participation in technical and regulatory discussions to stay ahead of emerging standards and security risks.

3. Assign internal stakeholders to monitor developments from groups like CSA, ISO/IEC JTC 1/SC 42, NIST, and ENISA.

4. Leverage insights from industry engagement to influence internal policy, architecture, and risk practices.

5. Foster partnerships and knowledge-sharing across peer organizations to enhance resilience and governance maturity.

Implementation Guidelines for Cloud Service Providers (CSP)

1. Define CSP responsibilities for AI workload governance within the shared responsibility model.

2. Offer guidance and templates for defining customer-side roles related to AI governance.

3. Clearly document CSP-side responsibilities in SLAs, contracts, and service descriptions.

4. Maintain internal governance structures and accountability chains for AI service delivery.

5. Collaborate with enterprise customers to align governance practices for co-managed AI workloads.

[All Actors]

1. Establish channels for engaging with cloud- and AI-related special interest groups, consortia, or industry bodies.

2. Encourage participation in technical and regulatory discussions to stay ahead of emerging standards and security risks.

3. Assign internal stakeholders to monitor developments from groups like CSA, ISO/IEC JTC 1/SC 42, NIST, and ENISA.

4. Leverage insights from industry engagement to influence internal policy, architecture, and risk practices.

5. Foster partnerships and knowledge-sharing across peer organizations to enhance resilience and governance maturity.

From CCM v4.1: Control Ownership Rationale. This control is independent of the service model (IaaS, PaaS, SaaS) since GRC applies to all. Each organization should independently identify and develop close contact with the relevant groups and/or of security professionals that will provide advice and additional security and governance information that could enhance the security posture of its services (e.g., using IoC, threat reports, early vulnerability/flaw discoveries).

Implementation Guidelines. Applicable to all service models: In order to maintain and continually improve its Information Security Program, and gain more knowledge about its infrastructure and underlying interfaces and connections with the CSC, the CSP should maintain contact with relevant stakeholders.

The CSP may consider exploring and testing potential flaws in their cloud environment using, for example, bug bounty programs or security research and expert communities (Note: In case of intrusive security testing involved, users should be careful to operate within all parameters set by the CSP and relevant requirements of law).

Additionally, the CSP should be part of both public and nonpublic security feeds to enhance its information security posture. The CSP should make all customer-relevant information available to the CSC, (e.g. white papers, position papers, and participating in research community forums).

When a SaaS CSP makes use of another CSP (e.g., an IaaS or another SaaS provider), it should also pass along information gleaned from them.

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.

Shared Implementation Guidelines

[All Actors]

1. Define and enforce a formal Acceptable Use Policy (AUP) for AI systems and services.

2. Specify prohibited use cases (e.g., surveillance, hate speech, deepfakes) and high-risk applications requiring pre-approval.

3. Clarify acceptable interaction boundaries for users, developers, and third-party integrations.

4. Ensure the AUP is accessible, legally reviewed, and referenced in user onboarding, API usage, and contracts.

5. Establish enforcement mechanisms for violations, including logging, suspension, and escalation protocols.

Implementation Guidelines for Cloud Service Providers (CSP)

1. Provide policy-as-code support (e.g., with OPA, GCP Org Policy, AWS SCPs) for enforcing AI governance controls.

2. Enable customers to define and enforce AI-specific policies (e.g., model usage, data access, export restrictions).

3. Offer centralized policy dashboards and APIs for managing and auditing AI policy enforcement.

4. Implement CSP-level controls to prevent misuse or misconfiguration of hosted AI services.

5. Support alerts and compliance triggers when policies are violated or drift is detected.

[All Actors]

1. Define and enforce a formal Acceptable Use Policy (AUP) for AI systems and services.

2. Specify prohibited use cases (e.g., surveillance, hate speech, deepfakes) and high-risk applications requiring pre-approval.

3. Clarify acceptable interaction boundaries for users, developers, and third-party integrations.

4. Ensure the AUP is accessible, legally reviewed, and referenced in user onboarding, API usage, and contracts.

5. Establish enforcement mechanisms for violations, including logging, suspension, and escalation protocols.

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.

Shared Implementation Guidelines

[All Actors]

1. Conduct a comprehensive impact assessment, for example using the guidance provided in ISO/IEC 42005:2025 on how to conduct AI Impact Assessments before deploying AI systems that process sensitive data, affect individuals, or are used in high-risk contexts.

2. Define the scope of the assessment to include intended use, affected users or communities, risk scenarios, and mitigations.

3. Document potential harms, legal/regulatory implications, fairness concerns, and system limitations.

4. Establish a review and sign-off process involving legal, compliance, risk, and technical stakeholders.

5. Update assessments periodically or when the system’s purpose, data sources, or deployment context changes.

Implementation Guidelines for Cloud Service Providers (CSP)

[All Actors]

1. Conduct a comprehensive impact assessment, for example using the guidance provided in ISO/IEC 42005:2025 on how to conduct AI Impact Assessments before deploying AI systems that process sensitive data, affect individuals, or are used in high-risk contexts.

2. Define the scope of the assessment to include intended use, affected users or communities, risk scenarios, and mitigations.

3. Document potential harms, legal/regulatory implications, fairness concerns, and system limitations.

4. Establish a review and sign-off process involving legal, compliance, risk, and technical stakeholders.

5. Update assessments periodically or when the system’s purpose, data sources, or deployment context changes.

Offer documentation on CSP-hosted model architectures, training data usage, and AI behavior boundaries.

Provide tools for explainable AI (e.g., SHAP, LIME integrations) within AI service offerings where applicable.

Disclose service-level explainability limitations and provide interpretability tooling guidance.

Enable logging of model inputs/outputs to support traceability and post-hoc analysis.

Allow enterprise customers to apply their own explainability frameworks over hosted models.

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.

Shared Implementation Guidelines

[All Actors]

1. Establish a process for regularly evaluating bias and fairness in AI models, data pipelines, and decision systems.

2. Use quantitative and qualitative methods to assess disparate impact across demographic groups.

3. Document fairness metrics, thresholds, and mitigation steps taken.

4. Engage domain experts, ethicists, and legal teams in reviewing fairness practices.

5. Make fairness assessments auditable and repeatable through documentation and tool use.

Implementation Guidelines for Cloud Service Providers (CSP)

Establish dedicated AI oversight groups for monitoring CSP-side practices, risks, and operations.

Share documentation of CSP internal audits, compliance reports, and AI risk registers upon request.

Provide named points of contact for AI governance issues, including support escalation paths.

Support audit trails for model hosting, API usage, and infrastructure changes impacting AI.

Align internal oversight with evolving global standards and regulatory expectations for AI services.

[All Actors]

1. Establish a process for regularly evaluating bias and fairness in AI models, data pipelines, and decision systems.

2. Use quantitative and qualitative methods to assess disparate impact across demographic groups.

3. Document fairness metrics, thresholds, and mitigation steps taken.

4. Engage domain experts, ethicists, and legal teams in reviewing fairness practices.

5. Make fairness assessments auditable and repeatable through documentation and tool use.

GRC-12: Ethics Committee

Control Specification

Establish an ethics committee to review AI applications, ensuring alignment with ethical standards and organizational values.

Shared Implementation Guidelines

[All Actors]

1. Form a cross-functional AI Ethics Committee responsible for oversight of high-risk, controversial, or novel AI use cases.

2. Define the committee’s mandate, including authority to approve, reject, or demand modifications of AI systems.

3. Include representation from technical, legal, business, compliance, and diversity/equity/inclusion functions.

4. Establish a formal intake and escalation process for ethics-related AI concerns.

5. Document decisions, rationales, and meeting minutes for accountability and transparency.

Implementation Guidelines for Cloud Service Providers (CSP)

Offer downloadable compliance artifacts, audit reports, and certification packages via customer portals.

Provide APIs or dashboards for real-time visibility into control status and compliance posture.

Support integration with third-party GRC tools and evidence management systems.

Notify customers promptly of any compliance gaps, findings, or changes to controls.

Maintain documentation for CSP-side implementations of AICM and related governance frameworks.

[All Actors]

1. Form a cross-functional AI Ethics Committee responsible for oversight of high-risk, controversial, or novel AI use cases.

2. Define the committee’s mandate, including authority to approve, reject, or demand modifications of AI systems.

3. Include representation from technical, legal, business, compliance, and diversity/equity/inclusion functions.

4. Establish a formal intake and escalation process for ethics-related AI concerns.

5. Document decisions, rationales, and meeting minutes for accountability and transparency.

GRC-13: Explainability Requirement

Control Specification

Establish, document, and communicate the degree of explainability needed for the AI Services.

Shared Implementation Guidelines

[All Actors]

1. Define explainability expectations for AI systems based on use case criticality, audience, and regulatory context.

2. Use appropriate methods (e.g., LIME, SHAP, saliency maps, rule extraction, counterfactuals or causal based methods) to generate model explanations.

3. Document the explainability strategy, limitations, and interpretability metrics.

4. Ensure explanations are accessible to intended audiences (e.g., end users, regulators, developers).

5. Evaluate explainability outputs for clarity, consistency, and fairness implications.

Implementation Guidelines for Cloud Service Providers (CSP)

Vet third-party components embedded in CSP-hosted AI services (e.g., model APIs, datasets, plugins).

Disclose usage of pretrained models, open datasets, or external APIs included in AI products.

Provide configuration options to allow/deny third-party tool usage within customer environments.

Offer security and compliance documentation for third-party integrations where applicable.

Ensure contractual protections and indemnity clauses for third-party risk where supported.

[All Actors]

1. Define explainability expectations for AI systems based on use case criticality, audience, and regulatory context.

2. Use appropriate methods (e.g., LIME, SHAP, saliency maps, rule extraction, counterfactuals or causal based methods) to generate model explanations.

3. Document the explainability strategy, limitations, and interpretability metrics.

4. Ensure explanations are accessible to intended audiences (e.g., end users, regulators, developers).

5. Evaluate explainability outputs for clarity, consistency, and fairness implications.

GRC-14: Explainability Evaluation

Control Specification

Evaluate, document, and communicate the degree of explainability of the AI Services, including possible limitations and exceptions.

Shared Implementation Guidelines

[All Actors]

1. Define what AI model attributes, performance metrics, datasets, risks, and limitations must be disclosed to stakeholders.

2. Create documentation templates (e.g., model cards, system cards) to standardize disclosures.

3. Publish transparency reports or disclosures when AI models are used in decision-making roles.

4. Update transparency documentation with each major model revision or retraining.

5. Ensure disclosures are accessible, understandable, and tailored to stakeholder needs.

Implementation Guidelines for Cloud Service Providers (CSP)

Provide customers with structured feedback channels (e.g., support tickets, user forums, feedback APIs).

Incorporate customer feedback into CSP product development cycles for AI services.

Publish changelogs and roadmaps to demonstrate responsiveness to enterprise needs.

Enable issue tracking for AI-specific problems, including model performance or deployment risks.

Conduct periodic surveys and reviews to enhance customer experience with AI governance capabilities.

[All Actors]

1. Define what AI model attributes, performance metrics, datasets, risks, and limitations must be disclosed to stakeholders.

2. Create documentation templates (e.g., model cards, system cards) to standardize disclosures.

3. Publish transparency reports or disclosures when AI models are used in decision-making roles.

4. Update transparency documentation with each major model revision or retraining.

5. Ensure disclosures are accessible, understandable, and tailored to stakeholder needs.

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.

Shared Implementation Guidelines

[All Actors]

1. Establish formal processes for ongoing human supervision across all phases of the AI lifecycle, including design, development, deployment, and post-deployment monitoring.

2. Define roles and responsibilities for human oversight, including model reviewers, risk owners, compliance officers, and incident responders.

3. Implement checkpoints where human judgment is required to review and approve high-impact model decisions, outputs, or changes before release.

4. Develop audit trails and documentation practices to record human reviews, override decisions, interventions, and escalations.

5. Continuously assess the effectiveness of human supervision processes and adapt based on system complexity, automation level, and potential for harm or bias.

6. Incorporate user feedback loops, appeals mechanisms, and external review options to supplement internal human oversight models.

Implementation Guidelines for Cloud Service Providers (CSP)

1. Offer supervision-as-a-service or human-in-the-loop orchestration tools to allow customers to integrate oversight checkpoints.

2. Provide APIs or audit hooks to enable monitoring of AI system behavior and decision patterns by human operators.

3. Include guidance and reference architectures for implementing effective human oversight in cloud-hosted AI pipelines.

4. Support tenant-defined intervention mechanisms to pause, review, or reverse AI-driven actions across cloud services.

5. Maintain documentation, training resources, and shared responsibility models that clarify CSP’s and customer’s oversight roles.

[All Actors]

1. Establish formal processes for ongoing human supervision across all phases of the AI lifecycle, including design, development, deployment, and post-deployment monitoring.

2. Define roles and responsibilities for human oversight, including model reviewers, risk owners, compliance officers, and incident responders.

3. Implement checkpoints where human judgment is required to review and approve high-impact model decisions, outputs, or changes before release.

4. Develop audit trails and documentation practices to record human reviews, override decisions, interventions, and escalations.

5. Continuously assess the effectiveness of human supervision processes and adapt based on system complexity, automation level, and potential for harm or bias.

6. Incorporate user feedback loops, appeals mechanisms, and external review options to supplement internal human oversight models.

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.

Shared Implementation Guidelines

[Applicable to all actors]

1. AI-Focused Screening: Verify AI expertise, data governance experience, and relevant certifications for anyone involved in AI development, orchestration, deployment, or management.

2. Compliance and Ethical Requirements: Ensure all candidates understand and agree to comply with legal, regulatory, and ethical standards related to data privacy, intellectual property, responsible AI, etc.

3. Background check: Require background checks before granting access to critical AI systems (e.g., model endpoints, training data, admin consoles). Maintain secure, confidential records of the verification process.

4. Periodic Updates: Review and update screening policies annually, or more frequently if AI risk profiles change, to align with evolving technologies and regulations.

5. Automated Verification & Human Oversight: When AI-enabled background-screening tools are used, a qualified reviewer must validate AI-generated results before onboarding or any adverse employment decision. Audit the accuracy and bias of the tools on a defined schedule.

Implementation Guidelines for Cloud Service Providers (CSP)

[Applicable to all actors]

1. AI-Focused Screening: Verify AI expertise, data governance experience, and relevant certifications for anyone involved in AI development, orchestration, deployment, or management.

2. Compliance and Ethical Requirements: Ensure all candidates understand and agree to comply with legal, regulatory, and ethical standards related to data privacy, intellectual property, responsible AI, etc.

3. Background check: Require background checks before granting access to critical AI systems (e.g., model endpoints, training data, admin consoles). Maintain secure, confidential records of the verification process.

4. Periodic Updates: Review and update screening policies annually, or more frequently if AI risk profiles change, to align with evolving technologies and regulations.

5. Automated Verification & Human Oversight: When AI-enabled background-screening tools are used, a qualified reviewer must validate AI-generated results before onboarding or any adverse employment decision. Audit the accuracy and bias of the tools on a defined schedule.

From CCM v4.1: Control Ownership Rationale. This control’s implementation responsibility is independent of the service model (IaaS, PaaS, SaaS) since GRC is applicable to all. It is shared and should be implemented by each party, CSC and the CSP, however independently from one another. Both entities may have different screening policies and processes that they should fill respective of their countries, contractual and regulatory requirements.

Implementation Guidelines. Applicable to all service models: The CSP is responsible for implementing internal measures to ensure that permanent and temporary staff, outsourced consultants and any other third-party service providers have been appropriately screened and vetted in relation to the level, amount and frequency of access to systems or sites required by their role. The screening processes should be established and precede any activity in granting access to systems.

Screening processes should be conducted by authorized and specialized departments to compartmentalize any and all personal data/sensitive information gathered during the screening processes. The CSP should make reasonable arrangements to assure the CSC of staff trust level. Where appropriate, it should conduct client-specific screening to their requirements for staff with access to the CSC’s systems such as government or law enforcement agencies. In situations where screening is delayed, for example, the inability to contact references or verification checks taking a long time, should implement mitigating controls for the interim, such as:

• a. Delaying start date or onboarding

• b. Not issuing access or credentials

• c. Allowing access but limiting or restricting permissions

Where circumstances cause complications, or screening has detected previous issues such as criminal records or information that causes concern, processes should be in place to escalate matters or to terminate offers of employment.

Policies should include (but not limited to) provisions on the following:

• a. Scope and Objectives: the scope and objectives of background verification, including the types of positions, roles, and access levels of employees, contractors, and third parties that require background checks. The verification process should be tailored to the level of access to sensitive data and the nature of responsibilities

• b. Compliance with Local Laws and Regulations: Ensure compliance with local, regional, and international laws and regulations regarding background checks and data privacy

  • i. obtain necessary consents, ensuring data privacy, and complying with record retention requirements.

  • ii. Consider specific regulations related to the handling of personal information in different jurisdictions

• c. Ethics and Contractual Constraints: ethical considerations and contractual obligations with customers and partners. It should ensure that background checks are conducted in a fair and unbiased manner, minimizing any potential for discrimination or invasion of privacy

• d. Risk Assessment for Background Verification: The extent of background verification should be proportionate to the data classification to be accessed, the business requirements, and the acceptable risk level. More sensitive roles or access to highly confidential data may warrant more rigorous background checks.

• e. Verification Checks: Outline the specific verification checks to be conducted.

  • i. Identity Verification: Confirming the individual’s identity through valid government-issued documents.

  • ii. Education Verification: Verifying educational credentials and qualifications as claimed (e.g., claimed degrees and certifications)

  • iii. Employment History Verification: Verifying previous employment history and job responsibilities (e.g., positions held, duration, and reasons for leaving.

  • iv. Reference Checks: Conduct professional reference checks to assess the candidate’s skills, work habits, and reliability.

• f. Criminal Background Checks: Conduct criminal background checks in accordance with local laws and regulations and define the criteria for disqualification based on the nature of offenses

• g. Third-Party Background Check Services: If using third-party background check providers, the policy should establish strict guidelines for selecting reputable and secure service providers

  • i. Include background verification requirements in contracts with third-party vendors and contractors

  • ii. Specify the level of scrutiny based on the services provided and access granted

  • iii. Require contractors and third parties to undergo security awareness training to align with the organization’s security policies

• h. Disclosure and Authorization: outline the process for obtaining necessary consents and authorizations from individuals for conducting background checks. It should also clarify the purpose of the checks and how the information will be used and protected.

• i. Record Retention: specify requirements for the duration for retaining background check records, ensuring compliance with data privacy regulations and contractual obligations (also regarding storage and disposal of personal information). Maintain audit trails of the background verification process for accountability and compliance purposes

• j. Incident Response: An incident response protocol in case any adverse or unexpected findings are revealed during the background verification process

• k. Approval: Approval requirements and senior management involvement to ensure alignment with the organization’s strategic goals and risk appetite

  • i. An approval process should be established for any changes or modifications to the policy and procedures

  • ii. A documented record of approvals (including dates, names of approvers, and any relevant comments or discussions) should be maintained

• l. Communication: Effective communication of the policy and procedures should be facilitated to all relevant cloud stakeholders

• m. Maintenance and Reviews: Policies and procedures for background verification checks should be documented, reviewed and updated at least annually to ensure alignment with evolving cloud security landscape and to reflect changes in cloud technology, regulations, and risks.

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.

Shared Implementation Guidelines

[Applicable to all actors]

1. Define and Document Policies: Develop clear acceptable use guidelines covering permissible data inputs and outputs, training sets, algorithmic operations, and deployment practices. Incorporate ethical principles (fairness, transparency, bias prevention) and comply with relevant legal and regulatory requirements.

2. Align with External Provider Requirements: Integrate AI service provider policies into internal acceptable use standards, ensuring consistent rules for data handling, model usage, and system integration.

3. Communicate and Train: Communicate policies to all teams and stakeholders. Provide regular training on safe and appropriate AI use, data handling practices, and potential risk mitigation strategies.

4. Oversight and Monitoring: Assign compliance oversight responsibilities and deploy monitoring tools (e.g., usage logs, anomaly detection) to ensure adherence to acceptable use guidelines. Establish metrics and KPIs to evaluate policy effectiveness.

5. Periodic Review and Update: Review and update acceptable use policies at least annually, or when significant changes occur in technology or regulation. Gather input from stakeholders to refine and improve policy scope.

6. Approval: Define policy owner and required approvers (e.g., security, legal, senior management) and require documented approval records (version, date, approver).

Implementation Guidelines for Cloud Service Providers (CSP)

[Applicable to all actors]

1. Define and Document Policies: Develop clear acceptable use guidelines covering permissible data inputs and outputs, training sets, algorithmic operations, and deployment practices. Incorporate ethical principles (fairness, transparency, bias prevention) and comply with relevant legal and regulatory requirements.

2. Align with External Provider Requirements: Integrate AI service provider policies into internal acceptable use standards, ensuring consistent rules for data handling, model usage, and system integration.

3. Communicate and Train: Communicate policies to all teams and stakeholders. Provide regular training on safe and appropriate AI use, data handling practices, and potential risk mitigation strategies.

4. Oversight and Monitoring: Assign compliance oversight responsibilities and deploy monitoring tools (e.g., usage logs, anomaly detection) to ensure adherence to acceptable use guidelines. Establish metrics and KPIs to evaluate policy effectiveness.

5. Periodic Review and Update: Review and update acceptable use policies at least annually, or when significant changes occur in technology or regulation. Gather input from stakeholders to refine and improve policy scope.

6. Approval: Define policy owner and required approvers (e.g., security, legal, senior management) and require documented approval records (version, date, approver).

From CCM v4.1: Control Ownership Rationale. The determination for this control objective remains the same regardless of the cloud architecture adoption, fundamentally this control is shared between both the CSC and the CSP. The controls however are Independent from one another. Both entities may have different Acceptable Use policies requirements for technology standards and requirements within their policies and processes that they should fill respective of their countries , contractual or regulatory requirements.

Implementation Guidelines. Applicable to all service models: The CSP has a responsibility to ensure its staff utilize the organization’s technology appropriately to protect its systems and its clients’ information. These policies should be provided to personnel and included in annual security training.

The policies should encompass all elements of using technology including but not limited to: Social Media usage, Sending & receiving Email, browsing and using the Internet, sending & forwarding content, electronic communications & Instant messaging, Videos, application usage, software security and configuration changes.

These policies should act as general Do’s and Don’ts for an organization’s IT systems. Outlining how to use organizational assets such as authorisation and protecting assets. It should also stipulate if your organization allows personal use of those devices.

Policies should include (but not limited to) provisions on the following:

• a. Scope and Objectives: The scope of assets covered, including cloud resources, devices, software, and data should be defined

  • i. The purpose should be stated as to protect the organization’s assets, data, and reputation by ensuring that cloud services are used in a responsible and ethical manner

  • ii. definitions of key terms, such as “acceptable use,” “unauthorized use,” and “confidential information should be provided

• b. Prohibited Uses: Outline prohibited uses of organizationally-owned or managed cloud assets including company-owned devices, personal devices, and cloud-based services and applications. Examples of prohibited uses may include:

  • i. Using assets for personal or non-work-related activities

  • ii. Installing unauthorized software or applications

  • iii. Accessing or sharing illegal or inappropriate content

  • iv. Engaging in activities that could damage or compromise the security of the assets

• c. Acceptable Uses: The policy should provide guidelines for acceptable uses of organizationally-owned or managed assets. Examples of acceptable uses may include:

  • i. Using assets for work-related activities

  • ii. Installing approved software applications

  • iii. Accessing and sharing work-related information

  • iv. Using assets in a responsible and ethical manner

• d. Compliance with Laws and Regulations: The policy should emphasize the need to comply with all applicable laws and regulations regarding the use of organizationally-owned or managed assets

• e. Consequences of Violation: The policy should outline the consequences of violating the policy, including disciplinary action, up to and including termination of employment

• f. Approval: Approval requirements and senior management involvement to ensure alignment with the organization’s strategic goals and risk appetite

  • i. An approval process should be established for any changes or modifications to the policy and procedures

  • ii. A documented record of approvals (including dates, names of approvers, and any relevant comments or discussions) should be maintained

• g. Communication: Effective communication of the policy and procedures should be facilitated to all relevant cloud stakeholders

• h. Maintenance and Reviews: Policies and procedures should be documented, reviewed and updated at least annually to ensure alignment with evolving cloud security landscape and to reflect changes in cloud technology, regulations, and risks.

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.

Shared Implementation Guidelines

[All Actors] The implementation guidelines provided by the CSP apply.

Implementation Guidelines for Cloud Service Providers (CSP)

[All Actors] The implementation guidelines provided by the CSP apply.

Periodic Review and Update: Review and update clear desk policy and procedure at least annually, or when significant changes occur. Gather input from stakeholders to refine and improve policy scope.

From CCM v4.1: Control Ownership Rationale. The determination for this control objective remains the same regardless of the cloud architecture adoption, fundamentally this control is shared between both the CSC and the CSP. The controls however are Independent from one another. Both entities may have different clean desk standards or requirements that need to be outlined in their policies and processes that they should fulfill respective of their countries , contractual or regulatory requirements.

Implementation Guidelines. Applicable to all service models: The CSP bears the responsibility for fostering a security culture within its organization, safeguarding itself and its clients from both accidental and malicious activities.

A clear desk policy is a fundamental component of information security, ensuring the physical protection of sensitive data from theft. This policy mandates the secure storage of assets in designated furniture, safes, and lockers, effectively shielding sensitive information from unauthorized access. Additionally, it safeguards against overlooking, shoulder surfing, and potential malicious activity by enforcing screen locks, thereby reducing the risk of session capturing, particularly in virtualized environments.

To further enhance security, whiteboards, writable walls, and other writable surfaces, along with notebooks, post-it notes, and similar materials, should be cleared, securely shredded, or wiped clean when not in use. Mobile devices and desktops may be equipped with physical cable locks to prevent theft, while servers and sensitive equipment should be stored within secured racks or cages.

When sending documents to printers, then these documents should be retrieved promptly to prevent unauthorized access to sensitive information.

Policies should include (but not limited to) provisions on the following:

• a. Scope and Objectives: This policy applies to all workspaces, including physical workstations, laptops, mobile devices, and cloud-based workspaces in order to protect data confidentiality and prevent unauthorized access to sensitive information for all employees, contractors, and third parties that leave their workspaces unattended

• b. Screen Locking Mechanism:

  • i. Require all devices to have an automatic screen locking mechanism that activates after a defined period of inactivity (e.g., not exceeding five minutes)

  • ii. Require strong passwords, PIN, or biometric authentication to unlock screens (refer to IAM-02)

  • iii. Implement two-factor authentication (2FA) for all users to further enhance screen lock security

• c. Automatic Logout:

  • i. Implement an automatic session logout feature after a specified period of inactivity to ensure that users are not inadvertently leaving their sessions open

  • ii. automatically lock remote desktop sessions when not in use, and require secure authentication for re-entry

• d. Privacy Screens: Encourage or require the use of privacy screens on devices to limit the visibility of screens to individuals in close proximity

• e. Clear Desk Policy: employees should maintain a clean workspace, ensuring that confidential information is not openly visible when they are away from their desks. Document covers or lockable storage cabinets for sensitive documents are advised

  • i. confidential documents, printouts, or notes should be not left in plain sight

  • ii. confidential documents should be shred or securely disposed of when no longer needed (refer to DSP-02)

• f. Secure Physical Devices:

  • i. Lock workstations, laptops, and mobile devices when left unattended, even for short periods

  • ii. Use strong passwords and enable multi-factor authentication (MFA) for all devices

  • iii. Avoid storing confidential data on removable media, such as USB drives, unless encrypted

• g. Approval: Approval requirements and senior management involvement to ensure alignment with the organization’s strategic goals and risk appetite

  • i. An approval process should be established for any changes or modifications to the policy and procedures

  • ii. A documented record of approvals (including dates, names of approvers, and any relevant comments or discussions) should be maintained

• h. Communication: Effective communication of the policy and procedures should be facilitated to all relevant cloud stakeholders

• i. Maintenance and Reviews: Workspace policies and procedures should be documented, reviewed and updated at least annually, or upon significant changes to ensure alignment with evolving cloud security landscape and to reflect changes in cloud technology, regulations, and risks.

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.

Shared Implementation Guidelines

[All Actors]

1. Secure Remote Access: Apply latest cryptography methodologies (e.g. require VPNs or encrypted tunnels combined with multi-factor authentication (MFA) and privileged credentials) when connecting to AI environments from remote locations, etc.

2. Data Protection and Confidentiality: Enforce data classification and handling procedures; use secure cloud-based development platforms, and restrict or prohibit local storage of sensitive AI datasets.

3. Access Controls and Endpoint Security: Implement role-based access controls for remote AI processes; harden end-user devices with endpoint protection, maintain current OS baselines, and continuously monitor for anomalies.

4. Training and Alignment: Conduct regular training for remote personnel on AI security practices, data governance, and phishing detection. Align remote workflows with relevant legal and provider-specific requirements.

5. Approval: Define policy owner and required approvers (e.g., security, legal, senior management) and require documented approval records (version, date, approver).

6. Regular Policy Review: Review and update remote access and data protection policies at least annually or when significant technological or regulatory changes arise, ensuring stakeholder input is integrated.

Implementation Guidelines for Cloud Service Providers (CSP)

[All Actors]

1. Secure Remote Access: Apply latest cryptography methodologies (e.g. require VPNs or encrypted tunnels combined with multi-factor authentication (MFA) and privileged credentials) when connecting to AI environments from remote locations, etc.

2. Data Protection and Confidentiality: Enforce data classification and handling procedures; use secure cloud-based development platforms, and restrict or prohibit local storage of sensitive AI datasets.

3. Access Controls and Endpoint Security: Implement role-based access controls for remote AI processes; harden end-user devices with endpoint protection, maintain current OS baselines, and continuously monitor for anomalies.

4. Training and Alignment: Conduct regular training for remote personnel on AI security practices, data governance, and phishing detection. Align remote workflows with relevant legal and provider-specific requirements.

5. Approval: Define policy owner and required approvers (e.g., security, legal, senior management) and require documented approval records (version, date, approver).

6. Regular Policy Review: Review and update remote access and data protection policies at least annually or when significant technological or regulatory changes arise, ensuring stakeholder input is integrated.

From CCM v4.1: Control Ownership Rationale. The determination for this control objective remains the same regardless of the cloud architecture adoption, fundamentally this control is shared between both the CSC and the CSP. The controls however are Independent from one another. Both entities may have different Remote and Home Working policies and Procedures which will link to the individual organizations standards and requirements within their policies and processes that they should achieve for their respective countries , contractual or regulatory requirements.

Implementation Guidelines. Applicable to all service models: Remote and Home working policy should be deployed by the CSP where it permits those activities for its personnel. Remote working increases the risk and threat profile of a cloud organization as these boundaries of protection may become weakened or assets may be compromised through various means. The CSP has a responsibility to protect its core systems and its CSC’s data. The policy should be defined and deployed to provide its personnel the appropriate security requirements, controls and procedures to follow while they work remotely.

Personnel should be trained and informed of risks when working remotely, as the shift to a decentralized work environment introduces various cybersecurity threats that individuals must be vigilant against.

One prevalent risk is the increased susceptibility to phishing attacks. Additionally, the use of unsecured Wi-Fi networks in home environments poses a potential threat, as it opens avenues for unauthorized access and data interception. Remote workers should also be cautious about the security of their devices, as the loss or theft of laptops or mobile devices can lead to unauthorized access to corporate data. Furthermore, the reliance on personal devices and unsecured applications for work tasks may expose organizations to data breaches and compromise the confidentiality of sensitive information.

Policies should include (but not limited to) provisions on the following:

• a. Scope and Objectives: This policy applies to all employees, contractors, and third-party vendors who access, process, or store information accessed, processed or stored at remote sites and locations in the context of cloud computing and cloud security. Objective of policy is to ensure that remote employees are aware of and comply with the organization’s cloud security policies and procedures

• b. Secure Network Connections: Require the use of a VPN for secure and encrypted communication, with strong encryption protocols and authentication mechanisms, between remote devices and the corporate network

• c. Remote Working MFA Access: Require the use of MFA for accessing corporate systems and cloud services. The use of MFA on all devices and applications to add an extra layer of security should be encouraged

• d. Endpoints Protection: Require the deployment of endpoint protection software to detect and prevent malware and other security threats

  • i. Implement Mobile Device Management (MDM) or Endpoint Management solutions for remote device configuration, monitoring, and security enforcement (e.g., anti-malware, device encryption, secure email, etc.) (refer to UEM domain)

  • ii. Educate remote workers about the risks of using public Wi-Fi and recommend the use of a VPN when connecting to public networks

  • iii. Provide guidelines for securing home Wi-Fi networks, including the use of strong encryption (WPA3) and changing default credentials

• e. Secure Remote Desktop Solutions: Where applicable, require the use secure remote desktop solutions with strong encryption and authentication

• f. Secure File Transfer: Discourage the use of personal email accounts or insecure file-sharing services for work-related tasks

• g. Regular Software Updates: Enable automatic updates whenever possible and educate users on the importance of keeping software up to date

• h. Remote Data Backups: Require regular backups of critical data stored on remote devices and test data restoration procedures periodically to ensure data can be recovered in case of loss or a security incident

• i. Secure File Transfer: Discourage the use of personal email accounts or insecure file-sharing services for work-related tasks.

• j. Secure Printing: Educate remote workers with secure printing practices, such as immediately retrieving printed documents with sensitive data

• k. Approval: Approval requirements and senior management involvement to ensure alignment with the organization’s strategic goals and risk appetite

  • i. An approval process should be established for any changes or modifications to the policy and procedures

  • ii. A documented record of approvals (including dates, names of approvers, and any relevant comments or discussions) should be maintained

• l. Communication: Effective communication of the policy and procedures should be facilitated to all relevant cloud stakeholders

• m. Maintenance and Reviews: Remote working policies and procedures should be documented, reviewed and updated at least annually to ensure alignment with evolving cloud security landscape and to reflect changes in cloud technology, regulations, and risks

HRS-05: Asset returns

Control Specification

Establish and document procedures for the return of organization-owned assets by terminated employees, contractors and third parties.

Shared Implementation Guidelines

[All Actors]

1. Document Asset Return Procedures: Define clear processes for retrieving or disposing of AI-related assets (e.g., models, datasets, credentials, physical devices, removable media, authentication hardware, etc.) from terminated employees, contractors and third parties. Maintain an up-to-date inventory to track which assets must be returned or wiped.

2. Immediate Access Revocation: Immediately disable user accounts, API keys, tokens, and other credentials upon termination to prevent unauthorized access to AI environments and data.

3. Secure Handling and Verification: Enforce controlled mechanisms to transfer or dispose of AI assets, ensuring confidentiality (e.g., encryption) and integrity (e.g., hashing). Where relevant, require attestations or evidence of secure erasure.

4. Logging and Monitoring: Keep detailed logs of AI asset returns, modifications, and version histories, reducing the risk of unauthorized data retention or model theft.

5. Training and Coordination: Provide regular training for HR and technical teams on asset return procedures. Collaborate with relevant stakeholders (e.g., AI providers or third-party contractors) to address any security incidents stemming from delayed asset returns.

Implementation Guidelines for Cloud Service Providers (CSP)

[All Actors]

1. Document Asset Return Procedures: Define clear processes for retrieving or disposing of AI-related assets (e.g., models, datasets, credentials, physical devices, removable media, authentication hardware, etc.) from terminated employees, contractors and third parties. Maintain an up-to-date inventory to track which assets must be returned or wiped.

2. Immediate Access Revocation: Immediately disable user accounts, API keys, tokens, and other credentials upon termination to prevent unauthorized access to AI environments and data.

3. Secure Handling and Verification: Enforce controlled mechanisms to transfer or dispose of AI assets, ensuring confidentiality (e.g., encryption) and integrity (e.g., hashing). Where relevant, require attestations or evidence of secure erasure.

4. Logging and Monitoring: Keep detailed logs of AI asset returns, modifications, and version histories, reducing the risk of unauthorized data retention or model theft.

5. Training and Coordination: Provide regular training for HR and technical teams on asset return procedures. Collaborate with relevant stakeholders (e.g., AI providers or third-party contractors) to address any security incidents stemming from delayed asset returns.

From CCM v4.1: Control Ownership Rationale. The determination for this control objective remains the same regardless of the cloud architecture adoption; fundamentally this control is shared between both the CSC and the CSP. The controls however are Independent from one another. Both entities may have different requirements for the return of organization-owned assets as per their policies and procedures which link to their respective standards and requirements.

Implementation Guidelines. Applicable to all service models: The CSP is responsible for ensuring it has established and documented procedures for the return of corporate-owned assets including organization-owned data for employees who have been or are to be terminated. By inference this would require the CSP to have defined asset tracking or management procedures in place. Where immediate return is not possible the ability to remotely wipe or lock devices should be deployed.

Return of organizational devices should include:

• a. user endpoint devices (laptops, mobiles and tablets)

• b. portable storage devices (USB, removable hard drives etc)

• c. specialized equipment

• d. authentication hardware (FIDO keys, mechanical keys, tokens, smartcards) for IT systems, physical sites and physical archives

• e. physical copies of information (e.g., handwritten, printed)

The CSP should also make efforts through technical procedures or policy (such as through NDAs) to prevent and deter the unauthorized copying, replication or transfer of information by any person(s) under their notice period for termination.

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.

Shared Implementation Guidelines

[All Actors] Assign and communicate responsibilities to relevant personnel (e.g., HR, IAM administrators, system owners, etc.) for executing the following procedures when employment changes occur:

1. Role Reassignment and Knowledge Transfer: Define AI-related responsibilities (e.g., data handling, model maintenance) and ensure formal handover of tasks and documentation when individuals change roles or leave the organization.

2. Establish procedures for access revocation: For example, revoke or update all credentials, accounts, and permissions upon termination or role change, including access to shared or provider-hosted AI environments. Please check IAM-07 as well.

3. Contractual and Third-Party Coordination: Incorporate access termination requirements in service-level agreements or contracts with external providers, ensuring offboarding processes align for both internal staff and external consultants.

Implementation Guidelines for Cloud Service Providers (CSP)

[All Actors] Assign and communicate responsibilities to relevant personnel (e.g., HR, IAM administrators, system owners, etc.) for executing the following procedures when employment changes occur:

1. Role Reassignment and Knowledge Transfer: Define AI-related responsibilities (e.g., data handling, model maintenance) and ensure formal handover of tasks and documentation when individuals change roles or leave the organization.

2. Establish procedures for access revocation: For example, revoke or update all credentials, accounts, and permissions upon termination or role change, including access to shared or provider-hosted AI environments. Please check IAM-07 as well.

3. Contractual and Third-Party Coordination: Incorporate access termination requirements in service-level agreements or contracts with external providers, ensuring offboarding processes align for both internal staff and external consultants.

From CCM v4.1: Control Ownership Rationale. The determination for this control objective remains the same regardless of the cloud architecture adoption; fundamentally this control is shared between both the CSC and the CSP. The controls however are Independent from one another. Both entities may have different requirements for the return of organization-owned assets as per their policies and procedures which link to their respective standards and requirements.

Implementation Guidelines. Applicable to all service models: The CSP is responsible for establishing and communicating a termination of employment policy or procedure that makes its people aware of the responsibilities and duties that will apply valid post termination. Post Employment Obligations may be presented to a terminating employee in the form of a refreshed NDA, a non-compete, or other form of legal document. These may also apply to a change in employment status.

The policies or documents should include requirements to maintain the confidentiality of organizational information such as trade secrets, intellectual property, client data, or any other information that may be valuable to the organization. The responsibilities should link to those details in the employment terms and conditions.

External personnel should also be subject to the same process for termination or changes when contracts or jobs are terminated or in the event of a role, team or department change is instigated.

The CSP should take caution on any restrictions or additional provisions it has made to specific CSCs with respect to their requirements or contractual agreements.

HRS-07: Employment Agreement Process

Control Specification

Employees sign the employee agreement prior to being granted access to organizational information systems, resources and assets.

Shared Implementation Guidelines

[All Actors]

1. AI-Specific Agreement: Require employees and contractors to sign a formal agreement, including confidentiality, intellectual property (IP), and acceptable use clauses related to AI, before they are granted access to AI systems, datasets, or development tools.

2. Pre-Access Training and Verification: Mandate completion of AI risk awareness and compliance training as a prerequisite for system access. Use automated onboarding workflows to verify training completion and agreement acceptance.

3. Documentation and Access Management: Maintain an up-to-date registry of personnel authorized to use AI workloads. Store AI policies, usage guidelines, and signed agreements in a version-controlled repository. Implement prompt revocation of AI access upon role changes or termination.

4. Provider Coordination: Align internal agreements and data-handling requirements with those of external AI service providers. Verify that any shared data, models, or tools comply with both internal policies and provider requirements defined in service-level agreements (SLAs).

5. Ongoing Training and Reinforcement: Provide regular refresher sessions on AI usage risks, data privacy obligations, and ethical considerations to ensure continued compliance with the signed agreements.

Implementation Guidelines for Cloud Service Providers (CSP)

[All Actors]

1. AI-Specific Agreement: Require employees and contractors to sign a formal agreement, including confidentiality, intellectual property (IP), and acceptable use clauses related to AI, before they are granted access to AI systems, datasets, or development tools.

2. Pre-Access Training and Verification: Mandate completion of AI risk awareness and compliance training as a prerequisite for system access. Use automated onboarding workflows to verify training completion and agreement acceptance.

3. Documentation and Access Management: Maintain an up-to-date registry of personnel authorized to use AI workloads. Store AI policies, usage guidelines, and signed agreements in a version-controlled repository. Implement prompt revocation of AI access upon role changes or termination.

4. Provider Coordination: Align internal agreements and data-handling requirements with those of external AI service providers. Verify that any shared data, models, or tools comply with both internal policies and provider requirements defined in service-level agreements (SLAs).

5. Ongoing Training and Reinforcement: Provide regular refresher sessions on AI usage risks, data privacy obligations, and ethical considerations to ensure continued compliance with the signed agreements.

From CCM v4.1: Control Ownership Rationale. The determination for this control objective remains the same regardless of the cloud architecture adoption; fundamentally this control is shared between both the CSC and the CSP. The controls however are Independent from one another. Both entities may have different requirements for employees when signing or agreeing to any access agreements. Those may be NDAs, AUPs, or contracts.

Implementation Guidelines. Applicable to all service models: The CSP is responsible for establishing and communicating procedures for employees to sign agreements prior to being granted access to organizational assets, information systems, or resources, including physical sites without escort. The agreements may include terms and conditions of employment, roles and responsibilities, or security standards.

When outlining agreements there should be provisions for preventing access without signed agreements, revoking access for breaches of agreements, and disciplinary procedures.

Terms and conditions should be reviewed and updated in line with internal policies and requirements, regulations, or laws change. Changes should be communicated to staff so they can agree to any new terms.

The CSP may be required contractually to also make staff aware of CSC agreements that may need to be signed.

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.

Shared Implementation Guidelines

[All Actors]

1. AI-Specific Contract Clauses: Include clear language in employment and contractor agreements mandating adherence to AI data handling, confidentiality, and security obligations. Extend these clauses to any third-party or subcontractor arrangements.

2. Mandatory Training and Awareness: Require all new hires and existing personnel to undergo initial and periodic AI training sessions covering governance, ethical standards, incident response, and regulatory compliance.

3. Incident Reporting Requirements: Outline employee obligations to promptly report any suspicious activity or potential AI data breach, referencing clearly defined protocols for escalation and investigation.

4. Periodic Review of Contractual Terms: Schedule routine reviews of AI-related contract language to align with evolving best practices, ethical standards, and regulatory requirements.

Implementation Guidelines for Cloud Service Providers (CSP)

[All Actors]

1. AI-Specific Contract Clauses: Include clear language in employment and contractor agreements mandating adherence to AI data handling, confidentiality, and security obligations. Extend these clauses to any third-party or subcontractor arrangements.

2. Mandatory Training and Awareness: Require all new hires and existing personnel to undergo initial and periodic AI training sessions covering governance, ethical standards, incident response, and regulatory compliance.

3. Incident Reporting Requirements: Outline employee obligations to promptly report any suspicious activity or potential AI data breach, referencing clearly defined protocols for escalation and investigation.

4. Periodic Review of Contractual Terms: Schedule routine reviews of AI-related contract language to align with evolving best practices, ethical standards, and regulatory requirements.

From CCM: Control Ownership Rationale. The determination for this control objective remains the same regardless of the cloud architecture adoption; fundamentally this control is shared between both the CSC and the CSP. The controls however are to be implemented independently by each party. Both parties should ensure employment agreements that include terms for adherence to established information governance and security policies, but such agreements are dependent on applicable laws and regulatory requirements.

Implementation Guidelines. Applicable to all service models: The CSP should communicate relevant code of conduct, information governance, and security and privacy policies to employees and contractors upon hire. All employees and contractors should complete relevant training upon hire and annually thereafter. Employees and contractors should sign an acknowledgment of the established policies. Any changes to policies should be communicated to employees and contractors and require a signature of acknowledgment. Employment and service contracts should include confidentiality clauses. The CSP should communicate the consequences of not adhering to the policies and take appropriate and proportionate action if an employee is in breach of an agreement.

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.

Shared Implementation Guidelines

[All Actors]

1. Define and document a formal governance structure that establishes clear roles and responsibilities for all employees involved in protecting information assets. This includes individuals across IT, security, legal, compliance, operations, HR, engineering, and business units who support security and privacy obligations.

2. Create clear reporting lines to ensure every employee understands who they report to regarding security and privacy matters, helping maintain accountability and consistent escalation pathways.

3. Identify key security- and privacy‑related roles and document their responsibilities, such as Data Owner, Data Steward, System Administrator, Security Engineer, Privacy Officer, and Governance Lead, to ensure clarity on who safeguards which information assets.

4. Develop comprehensive job descriptions and contractual terms that define security and privacy expectations for employees, contractors, and third‑party personnel who access or manage information assets.

5. Communicate roles and responsibilities organization‑wide, ensuring all employees, contractors, and contingent staff understand their obligations for protecting information assets.

6. Communicate updates to policies and procedures so employees remain aware of any changes affecting their security or privacy responsibilities.

Implementation Guidelines for Cloud Service Providers (CSP)

[All Actors]

1. Define and document a formal governance structure that establishes clear roles and responsibilities for all employees involved in protecting information assets. This includes individuals across IT, security, legal, compliance, operations, HR, engineering, and business units who support security and privacy obligations.

2. Create clear reporting lines to ensure every employee understands who they report to regarding security and privacy matters, helping maintain accountability and consistent escalation pathways.

3. Identify key security- and privacy‑related roles and document their responsibilities, such as Data Owner, Data Steward, System Administrator, Security Engineer, Privacy Officer, and Governance Lead, to ensure clarity on who safeguards which information assets.

4. Develop comprehensive job descriptions and contractual terms that define security and privacy expectations for employees, contractors, and third‑party personnel who access or manage information assets.

5. Communicate roles and responsibilities organization‑wide, ensuring all employees, contractors, and contingent staff understand their obligations for protecting information assets.

6. Communicate updates to policies and procedures so employees remain aware of any changes affecting their security or privacy responsibilities.

From CCM v4.1: Control Ownership Rationale. The determination for this control objective remains the same regardless of the cloud architecture adoption; fundamentally this control is shared between both the CSC and the CSP. The controls however are independent from one another. Both entities should document and communicate the roles and responsibilities of employees, as they relate to information assets, privacy, and security.

Implementation Guidelines. Applicable to all service models: The CSP should identify, define, document, and communicate information-asset protection guidance and responsibilities.These should be reviewed and updated annually.

All employees, contractors, and contingent staff should receive role-based security training commensurate with their access, duties, and responsibilities at the start of their service agreement before granting them access to corporate facilities, resources, and assets and annually thereafter. Changes to relevant policies should be communicated to employees, contractors, and contingent staff.

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.

Shared Implementation Guidelines

[All Actors]

1. Create NDA templates to meet the security, privacy, ethics, legal and regulatory needs of the organization, and as created or approved by legal counsel. The agreement should include: a. Clear information on protected information; b. Duration of the agreement; c. Parties involved and ownership; d. Responsibilities of each party; e. Definitions; f. Obligations; g. Exclusions; h. Restrictions on unauthorized access; i. Restrictions on unauthorized usage; j. Data destruction terms; k. Breach consequences. Review with legal counsel for approval.

2. Periodically review them with counsel to ensure they remain effective and relevant, reflect changes in business operations, adapt to technological advances, ensure compliance with regulations, and incorporate feedback and lessons learned.

3. Mandatory NDA and confidentiality training should be provided to all stakeholders.

4. Employees, contractors, and interns should be required to sign the NDA during hiring and onboarding, before accessing sensitive information, and after employment ends, depending on the specific terms outlined in the agreement.

5. NDAs should be enforced before sharing confidential information with suppliers and vendors, during partnerships and collaborations, before research and development, during mergers and acquisitions, and before product launches.

Implementation Guidelines for Cloud Service Providers (CSP)

[All Actors]

1. Create NDA templates to meet the security, privacy, ethics, legal and regulatory needs of the organization, and as created or approved by legal counsel. The agreement should include: a. Clear information on protected information; b. Duration of the agreement; c. Parties involved and ownership; d. Responsibilities of each party; e. Definitions; f. Obligations; g. Exclusions; h. Restrictions on unauthorized access; i. Restrictions on unauthorized usage; j. Data destruction terms; k. Breach consequences. Review with legal counsel for approval.

2. Periodically review them with counsel to ensure they remain effective and relevant, reflect changes in business operations, adapt to technological advances, ensure compliance with regulations, and incorporate feedback and lessons learned.

3. Mandatory NDA and confidentiality training should be provided to all stakeholders.

4. Employees, contractors, and interns should be required to sign the NDA during hiring and onboarding, before accessing sensitive information, and after employment ends, depending on the specific terms outlined in the agreement.

5. NDAs should be enforced before sharing confidential information with suppliers and vendors, during partnerships and collaborations, before research and development, during mergers and acquisitions, and before product launches.

From CCM v4.1: Control Ownership Rationale. The determination for this control objective remains the same regardless of the cloud architecture adoption; fundamentally this control is shared between both the CSC and the CSP. The controls however are independent from one another. Both entities should 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.

Implementation Guidelines. Applicable to all service models: The CSP should maintain an NDA/Confidentiality Agreement template and ensure appropriateness and currency through periodic review. Agreement terms should be based on the organization’s information security requirements.

The type of information covered should define permissible access and information handling protocols. The agreement should include, but not be limited to:

• a. what information is protected

• b. the length of the agreement

• c. interested parties to the agreement

• d. the responsibilities of each party in the agreement

• e. terms for the destruction of data once the agreement has ended

• f. expected actions if a breach of agreement terms occurs

• g. the CSP should require that the NDA/confidentiality agreement be put in place before it shares confidential information with third parties

Conditions of employment, encompassing employees, and contractors should be required to sign the confidentiality or non-disclosure agreement before gaining access to the CSP information assets.

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.

Shared Implementation Guidelines

[All Actors]

1. Develop a comprehensive code of conduct, security, and privacy training program using interactive modules, intranet content, webinars, videos, emails, and posters aligned with organizational policies and risk profiles. Note on AI-specific training: Content should provide guidelines on using AI tools to prevent data leaks and attacks, teach employees to recognize AI-generated threats, address AI-related risks, incorporate ethical considerations and compliance, handle data, report incidents, and prevent misuse of AI.

2. Provide training to all employees and contractors during onboarding and annually thereafter to educate personnel about their responsibilities and the necessary means for securing corporate assets.

3. Evaluate the training effectiveness and maintain records of evaluation.

4. Maintain training attendance records.

5. Tailor training based on roles and responsibilities.

6. Review and update the training program annually.

Implementation Guidelines for Cloud Service Providers (CSP)

[All Actors]

1. Develop a comprehensive code of conduct, security, and privacy training program using interactive modules, intranet content, webinars, videos, emails, and posters aligned with organizational policies and risk profiles. Note on AI-specific training: Content should provide guidelines on using AI tools to prevent data leaks and attacks, teach employees to recognize AI-generated threats, address AI-related risks, incorporate ethical considerations and compliance, handle data, report incidents, and prevent misuse of AI.

2. Provide training to all employees and contractors during onboarding and annually thereafter to educate personnel about their responsibilities and the necessary means for securing corporate assets.

3. Evaluate the training effectiveness and maintain records of evaluation.

4. Maintain training attendance records.

5. Tailor training based on roles and responsibilities.

6. Review and update the training program annually.

From CCM: Control Ownership Rationale. The determination for this control objective remains the same regardless of the cloud architecture adoption; fundamentally this control is shared between both the CSC and the CSP. The controls however are independent from one another. Both entities should establish, document, approve, communicate, apply, evaluate and maintain a security awareness training program for all employees of the organization and provide regular training updates.

Implementation Guidelines. Applicable to all service models: The CSP should establish and maintain a robust ongoing integrated security and privacy training program which may include, but not be limited to, interactive training modules, intranet content, online webinars, videos, email communications, posters, checklists and tip cards, etc. Security and privacy awareness training should be provided to all employees and contractors upon onboarding and annually thereafter to educate personnel about their responsibilities and the necessary means for securing corporate assets. A training attendance registry is to be maintained. Roles and responsibilities of organizational members should be considered and training should be tailored accordingly. Targeted training should be provided for developers on secure coding. The Security awareness training program should be reviewed at least annually and updated as needed.

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.

Shared Implementation Guidelines

[All Actors]

1. Develop a comprehensive training program using interactive modules, intranet content, webinars, videos, emails, and posters aligned with organizational policies and risk profiles. Note on AI-specific training on personal and sensitive data could include how to identify personal and sensitive data according to laws like GDPR and CCPA, best practices for data handling, identifying privacy risks in AI workflows, how to ensure data integrity, emphasis on ethical AI practices, understanding how AI systems handle PII and other regulated data, and security topics like data access controls, lawful data acquisition, data labeling, and risks of data leakage and poisoning.

2. Provide training to all employees and contractors during onboarding and annually thereafter to educate personnel about their responsibilities while handling personal and sensitive data.

3. Evaluate the training effectiveness and maintain records of evaluation.

4. Maintain training attendance records.

5. Tailor training based on roles and responsibilities.

6. Review and update the training program annually.

Implementation Guidelines for Cloud Service Providers (CSP)

[All Actors]

1. Develop a comprehensive training program using interactive modules, intranet content, webinars, videos, emails, and posters aligned with organizational policies and risk profiles. Note on AI-specific training on personal and sensitive data could include how to identify personal and sensitive data according to laws like GDPR and CCPA, best practices for data handling, identifying privacy risks in AI workflows, how to ensure data integrity, emphasis on ethical AI practices, understanding how AI systems handle PII and other regulated data, and security topics like data access controls, lawful data acquisition, data labeling, and risks of data leakage and poisoning.

2. Provide training to all employees and contractors during onboarding and annually thereafter to educate personnel about their responsibilities while handling personal and sensitive data.

3. Evaluate the training effectiveness and maintain records of evaluation.

4. Maintain training attendance records.

5. Tailor training based on roles and responsibilities.

6. Review and update the training program annually.

From CCM: Control Ownership Rationale. The determination for this control objective remains the same regardless of the cloud architecture adoption; fundamentally this control is shared between both the CSC and the CSP. The controls however are independent from one another. Both entities should provide internal and external personnel 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.

Implementation Guidelines. Applicable to all service models: Security awareness training should educate personnel on their responsibilities and the necessary means for securing personal and sensitive data. Training should include the various regulatory and legal requirements that impact personal and sensitive data handling. Furthermore, training should occur regularly to incorporate changes in organizational procedures, processes, and policies.

The training should be provided to all employees and contractors upon onboarding and annually thereafter. A training attendance registry is to be maintained.

All persons with systems access should acknowledge the information security and privacy policy.

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.

Shared Implementation Guidelines

[All Actors]

1. Ensure employees know their roles and responsibilities for AI compliance.

2. Establish and maintain a training program that defines roles, departmental responsibilities, and legal obligations through campaigns, newsletters, and training sessions.

3. Conduct periodic training sessions on AI privacy and security, clarifying shared responsibilities.

4. Establish and communicate the process to report compliance issues and AI misuse.

5. Align policies and procedures with legal and regulatory requirements, best practices and industry frameworks.

6. Ensure employees, contractors and third parties understand permissible data usage and its implications.

7. Emphasize ethical AI practices, bias mitigation, transparency, and data privacy.

8. Communicate policies for handling sensitive data and clarify roles and responsibilities.

9. Provide regular updates on AI threats, risks and lessons learned.

10. Ensure all employees, contractors, interns and third parties comply with security and privacy policies by obtaining acknowledgements.

Implementation Guidelines for Cloud Service Providers (CSP)

[All Actors]

1. Ensure employees know their roles and responsibilities for AI compliance.

2. Establish and maintain a training program that defines roles, departmental responsibilities, and legal obligations through campaigns, newsletters, and training sessions.

3. Conduct periodic training sessions on AI privacy and security, clarifying shared responsibilities.

4. Establish and communicate the process to report compliance issues and AI misuse.

5. Align policies and procedures with legal and regulatory requirements, best practices and industry frameworks.

6. Ensure employees, contractors and third parties understand permissible data usage and its implications.

7. Emphasize ethical AI practices, bias mitigation, transparency, and data privacy.

8. Communicate policies for handling sensitive data and clarify roles and responsibilities.

9. Provide regular updates on AI threats, risks and lessons learned.

10. Ensure all employees, contractors, interns and third parties comply with security and privacy policies by obtaining acknowledgements.

From CCM: Control Ownership Rationale. The determination for this control objective remains the same regardless of the cloud architecture adoption; fundamentally this control is shared between both the CSC and the CSP. The controls however are independent from one another. Both entities should make employees aware of their roles and responsibilities for maintaining awareness and compliance with established policies and procedures, regulations, and legal frameworks.

Implementation Guidelines. Applicable to all service models: The CSP should maintain a training and awareness program that regularly reminds personnel of their responsibilities. These responsibilities include maintaining awareness and compliance with established policies and procedures, regulations, and legal frameworks.

The training and awareness program may include several awareness-raising activities via appropriate physical or virtual channels, such as campaigns, booklets, posters, newsletters, websites, information sessions, briefings, e-learning modules, and emails.

All employees, contractors, and interns are responsible for maintaining awareness and complying with security and privacy policies, procedures, and standards relevant to their area of responsibility.

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.

Shared Implementation Guidelines

[All Actors]

1. Evaluate existing AI skills and resources.

2. Set clear objectives, outcomes, and goals for the AI competency program.

3. Determine the specific AI skills and knowledge needed by performing a skill gap analysis.

4. Develop a structured framework outlining AI proficiency levels.

5. Create training programs using online courses, workshops, and mentorship, focusing on AI basics, ethics of AI, data privacy and security, model development, human-centered mindset, AI techniques and applications, and AI system design. Implement an approval process for training materials and procedures to ensure they meet industry standards and regulatory requirements.

6. Administer training according to plan.

7. Monitor employee progress by conducting periodic evaluations and quizzes to measure comprehension of AI principles.

8. Encourage external industry certifications in core AI competencies and academic programs. Foster a learning culture where subject matter experts host workshops and share experiences on AI failures, successes, risks, and best practices.

9. Maintain training records, completion rates and achievement scores.

10. Conduct annual or on-demand reviews to ensure skill set relevancy.

11. Evaluate the training program’s effectiveness through feedback and performance metrics.

Implementation Guidelines for Cloud Service Providers (CSP)

[All Actors]

1. Evaluate existing AI skills and resources.

2. Set clear objectives, outcomes, and goals for the AI competency program.

3. Determine the specific AI skills and knowledge needed by performing a skill gap analysis.

4. Develop a structured framework outlining AI proficiency levels.

5. Create training programs using online courses, workshops, and mentorship, focusing on AI basics, ethics of AI, data privacy and security, model development, human-centered mindset, AI techniques and applications, and AI system design. Implement an approval process for training materials and procedures to ensure they meet industry standards and regulatory requirements.

6. Administer training according to plan.

7. Monitor employee progress by conducting periodic evaluations and quizzes to measure comprehension of AI principles.

8. Encourage external industry certifications in core AI competencies and academic programs. Foster a learning culture where subject matter experts host workshops and share experiences on AI failures, successes, risks, and best practices.

9. Maintain training records, completion rates and achievement scores.

10. Conduct annual or on-demand reviews to ensure skill set relevancy.

11. Evaluate the training program’s effectiveness through feedback and performance metrics.

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.

Shared Implementation Guidelines

[All Actors]

1. Establish and document an AI acceptable use policy and procedure that addresses fair, inclusive, reliable & safe, secure & private, transparent and accountable use of AI technologies.

2. Ensure coverage of all AI technologies, aligning with organizational values and ethical standards.

3. Require using approved AI tools, keeping an updated list of authorized applications, following procurement rules, and prohibiting unauthorized data processing, security bypassing, unapproved automation, and deceptive AI use.

4. Require comprehensive guidelines to ensure compliance and robust data protection, incorporating stringent security measures and thorough validation of AI outputs.

5. Communicated through periodic training to all employees, contractors, interns, and third parties, requiring formal acknowledgments and mandating regular evaluations to assess understanding.

6. Establish mechanisms to monitor compliance, require regular policy reviews, and report on effectiveness.

7.Continuously improve the policy by incorporating feedback, trends, and regulatory changes.

Implementation Guidelines for Cloud Service Providers (CSP)

[All Actors]

1. Establish and document an AI acceptable use policy and procedure that addresses fair, inclusive, reliable & safe, secure & private, transparent and accountable use of AI technologies.

2. Ensure coverage of all AI technologies, aligning with organizational values and ethical standards.

3. Require using approved AI tools, keeping an updated list of authorized applications, following procurement rules, and prohibiting unauthorized data processing, security bypassing, unapproved automation, and deceptive AI use.

4. Require comprehensive guidelines to ensure compliance and robust data protection, incorporating stringent security measures and thorough validation of AI outputs.

5. Communicated through periodic training to all employees, contractors, interns, and third parties, requiring formal acknowledgments and mandating regular evaluations to assess understanding.

6. Establish mechanisms to monitor compliance, require regular policy reviews, and report on effectiveness.

7.Continuously improve the policy by incorporating feedback, trends, and regulatory changes.

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.

Shared Implementation Guidelines

[All Actors] Responsible for establishing and maintaining IAM policies and procedures that cover the following:

1. Identity Inventory: Establish and maintain an inventory of identities having access to the cloud environment. Address cross-platform permission inheritance by implementing centralized policy management that maintains consistent access levels across AI environments.

2. Separation of Duties/Segregation of Privileged Access Roles: Prevent any identity from having excessive access that could be used to compromise the AI environment. Separate roles for AI data ingestion, model development, and model deployment.

3. Principle of Least Privilege (PoLP): Grant identities only the minimum level of access necessary to perform their job functions. Access permissions should be regularly reviewed and updated to ensure that they are still aligned with job roles.

4. Access Provisioning: Outline the process, timeframe and responsibilities for authorizing, recording, and communicating access provisions.

5. Access Changes and Revocation: Outline the process, timeframe, and responsibilities involved in removing access for movers, leavers, or identity changes.

6. Access Review: Procedures to review and revalidate identity access to ensure adherence to the principle of least privilege and separation of duties. Regularly validate AI user accounts and permissions, especially for data scientists and model developers who may need elevated privileges in AI environments.

7. Machine Identity Management: Implement comprehensive lifecycle management for service accounts, API keys, and machine identities used in AI workflows. Include automated rotation, monitoring for usage patterns, and integration with secrets management systems.

8. Management of Privileged Access Roles: Establish requirements for the lifecycle management of access privileges (provisioning, usage, monitoring, and revocation) and scheduled regular reviews to ensure alignment of access privileges with evolving business requirements and identities roles.

9. Safeguard Logs Integrity: Requirements for log files protection from unauthorized modifications or deletion to ensure the integrity of the audit trail. Break-glass procedures should be defined for accessing and modifying log files in emergency situations.

10. Uniquely Identifiable Users: Requirements for the establishment of unique identifiers that are assigned to all identities within the cloud environment. Unique IDs should be used consistently throughout the cloud environment to track and manage access.

11. Strong Authentication and Credentials: Authentication requirements of security measures for accessing systems, applications, and data assets should be defined and established (e.g., authentication frequency and scope, mechanisms, secure credentials, authentication in relation to data sensitivity).

12. Authorization Mechanisms: Authorization requirements that access privileges granted to different user groups and other identities are based on their roles and responsibilities, data sensitivity and business requirements. The requirements should outline the specific data and system functions that each user group is authorized to access.

13. Dynamic Access Controls: Where appropriate, integrate intelligent risk scoring into access decisions so that privileges adapt dynamically to the user’s activity, data sensitivity, and AI workload complexity. Set clear thresholds for elevated access requirements and step-up authentication. Implement dynamic data access patterns including temporary, just-in-time access grants.

14. Identity-Related Incident Response: Establish specific procedures for handling identity compromise scenarios in AI systems, including immediate access revocation, model quarantine capabilities, and forensic analysis requirements. Include procedures for containing incidents across distributed system components.

15. Secure Secret Management: Never hardcode credentials, API keys, or other secrets in application code. Use appropriate secret management services with tightly controlled permissions and audit logging for storing, accessing, and rotating secrets.

Implementation Guidelines for Cloud Service Providers (CSP)

[All Actors] Responsible for establishing and maintaining IAM policies and procedures that cover the following:

1. Identity Inventory: Establish and maintain an inventory of identities having access to the cloud environment. Address cross-platform permission inheritance by implementing centralized policy management that maintains consistent access levels across AI environments.

2. Separation of Duties/Segregation of Privileged Access Roles: Prevent any identity from having excessive access that could be used to compromise the AI environment. Separate roles for AI data ingestion, model development, and model deployment.

3. Principle of Least Privilege (PoLP): Grant identities only the minimum level of access necessary to perform their job functions. Access permissions should be regularly reviewed and updated to ensure that they are still aligned with job roles.

4. Access Provisioning: Outline the process, timeframe and responsibilities for authorizing, recording, and communicating access provisions.

5. Access Changes and Revocation: Outline the process, timeframe, and responsibilities involved in removing access for movers, leavers, or identity changes.

6. Access Review: Procedures to review and revalidate identity access to ensure adherence to the principle of least privilege and separation of duties. Regularly validate AI user accounts and permissions, especially for data scientists and model developers who may need elevated privileges in AI environments.

7. Machine Identity Management: Implement comprehensive lifecycle management for service accounts, API keys, and machine identities used in AI workflows. Include automated rotation, monitoring for usage patterns, and integration with secrets management systems.

8. Management of Privileged Access Roles: Establish requirements for the lifecycle management of access privileges (provisioning, usage, monitoring, and revocation) and scheduled regular reviews to ensure alignment of access privileges with evolving business requirements and identities roles.

9. Safeguard Logs Integrity: Requirements for log files protection from unauthorized modifications or deletion to ensure the integrity of the audit trail. Break-glass procedures should be defined for accessing and modifying log files in emergency situations.

10. Uniquely Identifiable Users: Requirements for the establishment of unique identifiers that are assigned to all identities within the cloud environment. Unique IDs should be used consistently throughout the cloud environment to track and manage access.

11. Strong Authentication and Credentials: Authentication requirements of security measures for accessing systems, applications, and data assets should be defined and established (e.g., authentication frequency and scope, mechanisms, secure credentials, authentication in relation to data sensitivity).

12. Authorization Mechanisms: Authorization requirements that access privileges granted to different user groups and other identities are based on their roles and responsibilities, data sensitivity and business requirements. The requirements should outline the specific data and system functions that each user group is authorized to access.

13. Dynamic Access Controls: Where appropriate, integrate intelligent risk scoring into access decisions so that privileges adapt dynamically to the user’s activity, data sensitivity, and AI workload complexity. Set clear thresholds for elevated access requirements and step-up authentication. Implement dynamic data access patterns including temporary, just-in-time access grants.

14. Identity-Related Incident Response: Establish specific procedures for handling identity compromise scenarios in AI systems, including immediate access revocation, model quarantine capabilities, and forensic analysis requirements. Include procedures for containing incidents across distributed system components.

15. Secure Secret Management: Never hardcode credentials, API keys, or other secrets in application code. Use appropriate secret management services with tightly controlled permissions and audit logging for storing, accessing, and rotating secrets.

The CSP’s ownership of this control relates to the policies and procedures for managing identities (i.e., users, systems/processes, services and other security principals) and access to CSP-controlled resources within its organizational units, infrastructure, and assets relevant to the cloud services offered to the CSC.

Implementation Guidelines. IaaS Provider: The CSP is responsible for establishing, documenting, implementing, enforcing, reviewing, and maintaining identity and access management policies and procedures for the physical infrastructure (including hosts and network) and the associated management interfaces.

PaaS Provider: The CSP is responsible for establishing, documenting, implementing, enforcing, reviewing, and maintaining policies and procedures to manage identities and access to the platform underlying resources, middleware, and APIs for cloud services.

SaaS Provider: The CSP is responsible for establishing, documenting, implementing, enforcing, reviewing, and maintaining policies and procedures to manage identities and access to the underlying platform resources, virtual machines, network resources, and associated management plane or administrative interfaces for cloud services.

For each of the three service models, the CSP should document and communicate to the CSC the identity and access management features and technologies.

Policies should include (but not limited to) provisions on the following:

• a. Scope and Objectives: The scope of the IAM policy should be defined, including the identities, systems and data covered by the policy. The objectives of the IAM policy should be clearly articulated, such as ensuring confidentiality, integrity, and availability of data, as well as complying with relevant regulations

• b. Identity Inventory: Requirements to establish and maintain an inventory of identities within the cloud environment. Identities that are no longer active and required should be disabled or removed

• c. Separation of Duties (SoD): Prevent any identity from having excessive access that could be used to compromise the cloud environment

• d. Principle of Least Privilege (PoLP): Granting identities only the minimum level of access necessary to perform their job functions. Access permissions should be regularly reviewed and updated to ensure that they are still aligned with job roles

• e. Access Provisioning: Outline the process, timeframe and responsibilities for authorizing, recording, and communicating access provisions

• f. Access Changes and Revocation: Outline the process, timeframe, and responsibilities involved in removing access for movers, leavers, or identity changes

• g. Access Review: Procedures to review and revalidate identity access to ensure adherence to the principle of least privilege and separation of duties

• h. Segregation of Privileged Access Roles: Prevent any identity from having excessive privileged access that could be used to compromise the cloud environment. Separate among different identities the privileged access roles, such as administrative, logging, and cryptographic access

• i. Management of Privileged Access Roles: Requirements for the lifecycle management of access privileges (provisioning, usage, monitoring, and revocation) and scheduled regular reviews to ensure alignment of access privileges with evolving business requirements and identities roles

• j. CSCs Approval for Agreed Privileged Access Roles: Formal approval procedures and processes involving CSCs before CSPs granting and modifying privileged access to sensitive data or systems

• k. Safeguard Logs Integrity: Requirements for log files protection from unauthorized modifications or deletion to ensure the integrity of the audit trail. Break-glass procedures should be defined for accessing and modifying log files in emergency situations

• l. Uniquely Identifiable Users: Requirements for the establishment of unique identifiers that are assigned to all identities within the cloud environment. Unique IDs should be used consistently throughout the cloud environment to track and manage access

• m. Strong Authentication and Credentials: Authentication requirements of security measures for accessing systems, applications, and data assets should be defined and established (e.g., authentication frequency and scope, mechanisms, secure credentials, authentication in relation to data sensitivity)

• n. Authorization Mechanisms: Authorization requirements that access privileges granted to different user groups and other identities are based on their roles and responsibilities, data sensitivity and business requirements. The requirements should outline the specific data and system functions that each user group is authorized to access

• o. Approval: Approval requirements and senior management involvement to ensure alignment with the organization’s strategic goals and risk appetite

  • i. An approval process should be established for any changes or modifications to the IAM policy and procedures

  • ii. A documented record of approvals (including dates, names of approvers, and any relevant comments or discussions) should be maintained

• p. Communication: Effective communication of the IAM policy and procedures should be facilitated to all relevant cloud stakeholders

• q. Maintenance and Reviews: IAM policies and procedures policies and procedures should be documented, reviewed and updated at least annually to ensure alignment with evolving cloud security landscape and to reflect changes in cloud technology, regulations, and risks

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.

Shared Implementation Guidelines

[All Actors] Responsible for establishing strong authentication credential management policies and procedures that include:

1. Authentication Standards: Establish requirements for password complexity, length, history, and expiration.

2. Brute-force Attack Prevention: Use brute-force attack prevention mechanisms based on rate limiting and progressive delays (e.g., account lockout after a specified number of failed login attempts).

3. Credential Protection: Use credential protection using strong storage and in transit encryption, utilizing secure hashing algorithms with regular updates and salting, and conducting periodic assessments and updates of encryption practices aligned with industry standards.

4. Credential management tools: Leverage credential management tools (e.g., hardware security modules or encrypted credential vaults) to store and protect passwords and keys.

5. Credential Rotation: Define and enforce credential rotation requirements for all identities within AI development and operations environments, taking into account specialized accounts such as service accounts used by AI frameworks.

6. Password Reset: Define a secure password reset process to prevent unauthorized access in case of forgotten passwords.

7. Credential Recovery: Define a secure process for credential recovery that includes verification steps to prevent unauthorized access.

8. Multi-Factor Authentication (MFA): Use multi-factor authentication to add an extra layer of security in addition to passwords.

9. Approval: Establish an approval process for any changes or modifications to the IAM policy and procedures, including a documented record.

10. Maintenance and Reviews: Conduct reviews on credential policies and procedures documentation at least annually to ensure alignment with evolving security landscape, regulations, and risks.

11. Short-Lived Credentials: Prioritize using short-lived secrets and automatic rotation of credentials where possible to reduce management overhead and minimize impact of leaked credentials.

12. Policy Communication: Ensure credential policies are clearly documented and effectively communicated to all relevant stakeholders.

Implementation Guidelines for Cloud Service Providers (CSP)

[All Actors] Responsible for establishing strong authentication credential management policies and procedures that include:

1. Authentication Standards: Establish requirements for password complexity, length, history, and expiration.

2. Brute-force Attack Prevention: Use brute-force attack prevention mechanisms based on rate limiting and progressive delays (e.g., account lockout after a specified number of failed login attempts).

3. Credential Protection: Use credential protection using strong storage and in transit encryption, utilizing secure hashing algorithms with regular updates and salting, and conducting periodic assessments and updates of encryption practices aligned with industry standards.

4. Credential management tools: Leverage credential management tools (e.g., hardware security modules or encrypted credential vaults) to store and protect passwords and keys.

5. Credential Rotation: Define and enforce credential rotation requirements for all identities within AI development and operations environments, taking into account specialized accounts such as service accounts used by AI frameworks.

6. Password Reset: Define a secure password reset process to prevent unauthorized access in case of forgotten passwords.

7. Credential Recovery: Define a secure process for credential recovery that includes verification steps to prevent unauthorized access.

8. Multi-Factor Authentication (MFA): Use multi-factor authentication to add an extra layer of security in addition to passwords.

9. Approval: Establish an approval process for any changes or modifications to the IAM policy and procedures, including a documented record.

10. Maintenance and Reviews: Conduct reviews on credential policies and procedures documentation at least annually to ensure alignment with evolving security landscape, regulations, and risks.

11. Short-Lived Credentials: Prioritize using short-lived secrets and automatic rotation of credentials where possible to reduce management overhead and minimize impact of leaked credentials.

12. Policy Communication: Ensure credential policies are clearly documented and effectively communicated to all relevant stakeholders.

From CCM v4.1: Control Ownership Rationale. CSP’s ownership of the control is concerned with password policies and procedures for authentication to CSP-controlled resources within the CSP’s organizational units, infrastructure, and assets relevant to the cloud services offered to CSCs.

Implementation Guidelines. IaaS Provider: The CSP is responsible for establishing strong password policies for its internal infrastructure resources (including network devices and physical hosts), and CSC authentication to their management plane.

PaaS Provider: The CSP is responsible for establishing strong password policies for the CSP’s internal users and customers authentication to platform underlying resources, middleware, APIs, and customers authentication to the administrative interface (management plane) of cloud services.

SaaS Provider: CSP is responsible for establishing strong password policies for the CSP’s internal users authentication to application environments (including hosting machines, database, network, middleware and APIs), and customers authentication to administrative accounts of cloud services.

Policies should include (but not limited to) provisions on the following:

• a. Scope and Objectives: The scope should define which users and accounts the policy applies to, including employees, contractors, and any third-parties with system access. Objectives should include requirements on password strength and limitations on reuse of personal data

• b. Password Complexity, Length, History, Expiration: Password complexity, length, history, and expiration requirements in accordance with industry standards

• c. Brute-force Attack Prevention: Brute-force attack prevention mechanisms based on rate limiting (e.g., account lockout after a specified number of failed login attempts)

• d. Password Protection: Passwords protection using strong storage and in transit encryption, utilizing secure hashing algorithms with regular updates and salting, and conducting periodic assessments and updates of encryption practices aligned with industry standards

• e. Password Rotation: The definition and enforcement of password rotation requirements for all identities

• f. Password Reset: A secure password reset process to prevent unauthorized access in case of forgotten passwords

• g. Password Recovery: A secure process for password recovery that includes verification steps to prevent unauthorized access

• h. Multi-Factor Authentication (MFA): Encourage or require the use of multi-factor authentication to add an extra layer of security in addition to passwords

• i. Third-Party Integration: Address third-party applications or services integration with your system and ensure adherence to strong password requirements

• j. Approval: Approval requirements and senior management involvement to ensure alignment with the organization’s strategic goals and risk appetite

  • i. An approval process should be established for any changes or modifications to the IAM policy and procedures

  • ii. A documented record of approvals (including dates, names of approvers, and any relevant comments or discussions) should be maintained

• k. Communication: Effective communication of the IAM policy and procedures should be facilitated to all relevant cloud stakeholders

• l. Maintenance and Reviews: Password policies and procedures documentation, review and updates at least annually to ensure alignment with evolving cloud security landscape and to reflect changes in cloud technology, regulations, and risks

These provisions should be customized based on the CSP’s and CSC’s specific needs and the nature of the cloud environment.

IAM-03: Identity Inventory

Control Specification

Manage, store, and regularly review the inventory of identities, and monitor their level of access.

Shared Implementation Guidelines

[All Actors] Responsible for maintaining a comprehensive inventory of all identities and their level of access

1. Include human users, machine identities, service accounts, API keys, and AI identities.

2. Identity Management System: Where appropriate, a centralized identity management platform should be implemented that consolidates identities’ data from various applications and services.

3. Identity Classification: Identities should be categorized and classified based on their roles, purpose, and sensitivity and in correlation of the resources they access. Include mapping of any inheritance relationships between identities, indirect access paths, and nested group memberships.

4. Access Level Mapping: Maintain mapping between identities and their level of access (RBAC/ABAC), documenting specific permissions, roles, and resource access scopes for each identity. Regularly review these mappings for accuracy.

5. Identity Discovery and Inventory: Automated tools should be utilized to continuously scan the environment and discover all existing identities in real-time.

6. Identity Creation Monitoring: Implement alerting mechanisms to notify security teams when new identities are created or when existing identities receive permission changes, especially for privileged access, to detect potential privilege escalation attempts.

7. Threat Intelligence Integration: Leverage threat intelligence sources to identify potential identity-based threats to proactively address emerging risks.

8. Inventory Access: Identity information should be stored in a secure location and access restricted to authorized personnel.

9. System/AI Identity Ownership: Each system, service, or AI account should be assigned a designated owner to maintain accountability, facilitate future management, and mitigate security risks associated with unmanaged accounts.

10. Inventory Reviews and Updates: Review the inventory to ensure accuracy and completeness and identify any anomalies, on a periodic basis or after any system changes or changes to identities and their level of access.

Implementation Guidelines for Cloud Service Providers (CSP)

[All Actors] Responsible for maintaining a comprehensive inventory of all identities and their level of access

1. Include human users, machine identities, service accounts, API keys, and AI identities.

2. Identity Management System: Where appropriate, a centralized identity management platform should be implemented that consolidates identities’ data from various applications and services.

3. Identity Classification: Identities should be categorized and classified based on their roles, purpose, and sensitivity and in correlation of the resources they access. Include mapping of any inheritance relationships between identities, indirect access paths, and nested group memberships.

4. Access Level Mapping: Maintain mapping between identities and their level of access (RBAC/ABAC), documenting specific permissions, roles, and resource access scopes for each identity. Regularly review these mappings for accuracy.

5. Identity Discovery and Inventory: Automated tools should be utilized to continuously scan the environment and discover all existing identities in real-time.

6. Identity Creation Monitoring: Implement alerting mechanisms to notify security teams when new identities are created or when existing identities receive permission changes, especially for privileged access, to detect potential privilege escalation attempts.

7. Threat Intelligence Integration: Leverage threat intelligence sources to identify potential identity-based threats to proactively address emerging risks.

8. Inventory Access: Identity information should be stored in a secure location and access restricted to authorized personnel.

9. System/AI Identity Ownership: Each system, service, or AI account should be assigned a designated owner to maintain accountability, facilitate future management, and mitigate security risks associated with unmanaged accounts.

10. Inventory Reviews and Updates: Review the inventory to ensure accuracy and completeness and identify any anomalies, on a periodic basis or after any system changes or changes to identities and their level of access.

The CSP owns the control with respect to the system identities accessing resources under the CSP’s control in the cloud environment. The scope of such resources is dependent on the type of cloud service model the CSP offers as detailed below.

Implementation Guidelines. Iaas Provider: The CSP is responsible for maintaining and reviewing the inventory of system identities having access to resources in the cloud environment, including: physical datacenter infrastructure for power, cooling, and networking; hardware for computing, storage, and networking; hypervisors and other virtualization assets. System identities to be documented should include users, services, applications, roles, and groups having access to each asset and the types of access granted them.

PaaS Provider: The CSP is responsible for maintaining and reviewing the inventory of system identities having access to: physical datacenter infrastructure for power, cooling, and networking; hardware for computing, storage, and networking; hypervisors and other virtualization resources; virtual machine images and instances; operating systems, middleware, databases, and management tools. System identities to be documented should include users, services, applications, roles, and groups having access to each asset and the types of access granted them.

SaaS Provider: The CSP is responsible for maintaining and reviewing the inventory of system identities having access to: physical datacenter infrastructure for power, cooling, and networking; hardware for computing, storage, and networking; hypervisors and other virtualization resources; virtual machine images and instances; operating systems, middleware, databases, and management tools; applications and their data storage. System identities to be documented should include users, services, applications, roles, and groups having access to each asset and the types of access granted them.

Applicable to all service models:

• a. Implementation guidelines to establish and maintain an identity inventory include (but are not limited to):

• b. Identity Management System (IDaaS): A centralized IDaaS platform should be implemented that consolidates identities data from various cloud applications and services. The platform should provide visibility into all identities and their access privileges (e.g., Least Privilege, SoDs, ACLs)

• c. Identity Classification: Identities should be categorized and classified based on their roles, purpose, and sensitivity and in correlation of the resources they access (i.e., assign appropriate access permissions and implement stricter controls for critical identities)

• d. Identity Discovery and Inventory: Automated tools should be utilized to continuously scan the cloud environment and identify all existing identities

• e. Threat Intelligence Integration: Leverage threat intelligence sources to identify and prioritize potential identity-based threats to proactively address emerging risks

• f. Inventory Access: Identity information should be stored in a secure location and access restricted to authorized personnel

• g. System Identity Ownership: Each system and service account should be assigned a designated owner to maintain accountability, facilitate future management, and mitigate security risks associated with unmanaged accounts

• h. Inventory Reviews and Updates:

  • i. The inventory should be up-to-date to ensure accuracy and completeness and reflect the current state of identities and their level of access, identify any discrepancies or anomalies and to ensure access is revoked or changed as necessary

  • ii. Reviews should be conducted on a periodic basis or upon changes to identities and their level of access, and according to the CSP’s risk assessment and other compliance requirements

IAM-04: Separation of Duties

Control Specification

Employ the separation of duties principle when implementing information system access.

Shared Implementation Guidelines

[All Actors] Best practices for implementation of Separation of Duties (SoD) include:

1. SoD Role Management and Access:

   • i. A centralized role management system should be implemented to oversee and maintain role permissions

   • ii. Roles overlapping in responsibilities should be minimized to enhance SoD

   • iii. Roles should be created with specific permissions for different functions within the AI system, avoiding assigning a single identity with excessive privileges that could enable unauthorized actions (e.g., critical functions, such as authorization, approval, and execution, should be separated among different identities)

   • iv. Access levels should be segregated to restrict roles and their access to specific portions of the AI system

   • a. For high-risk or critical activities, such as approving transactions or making modifications to sensitive data, a multi-level approval process should be implemented (i.e., multiple individuals from different roles approve an action) separating approval for role assignment and provisioning, role reviews, role changes monitoring, policy exception management, violations reporting, and SoD controls monitoring.

Implementation Guidelines for Cloud Service Providers (CSP)

[All Actors] Best practices for implementation of Separation of Duties (SoD) include:

1. SoD Role Management and Access:

   • i. A centralized role management system should be implemented to oversee and maintain role permissions

   • ii. Roles overlapping in responsibilities should be minimized to enhance SoD

   • iii. Roles should be created with specific permissions for different functions within the AI system, avoiding assigning a single identity with excessive privileges that could enable unauthorized actions (e.g., critical functions, such as authorization, approval, and execution, should be separated among different identities)

   • iv. Access levels should be segregated to restrict roles and their access to specific portions of the AI system

   • a. For high-risk or critical activities, such as approving transactions or making modifications to sensitive data, a multi-level approval process should be implemented (i.e., multiple individuals from different roles approve an action) separating approval for role assignment and provisioning, role reviews, role changes monitoring, policy exception management, violations reporting, and SoD controls monitoring.

CSPs should implement separation of duties (SoD) for safeguarding cloud environments and preventing unauthorized access, fraud, and errors. Both CSPs and CSCs share the responsibility of implementing SoD principles effectively.

Iaas Provider:
The CSP is responsible for ensuring that SoD principle is applied when assigning system access to users for conflicting functions, including SoD among: cloud administrators who are responsible for provisioning and deprovisioning cloud infrastructure resources; security administrators who are responsible for developing and implementing security policies and procedures; system and operational support personnel responsible for monitoring resource performance and availability, troubleshooting, and resolving operational issues

PaaS Provider: The CSP is responsible for ensuring that the SoD principle is applied when assigning system access to users for conflicting functions, including: cloud administrators responsible for provisioning and deprovisioning cloud infrastructure and platform resources; security administrators responsible for developing and implementing security policies and procedures; and the system and operational support teams responsible for monitoring resource performance and availability, troubleshooting, and resolving operational issues.

SaaS Provider: The CSP is responsible for ensuring that the SoD principle is applied when assigning system access to users for conflicting functions, including: cloud administrators responsible for provisioning and deprovisioning cloud infrastructure and platform resources; security administrators responsible for developing and implementing security policies and procedures; developers responsible for developing and deploying applications to the cloud environment; system and operational support teams responsible for monitoring resource and application performance and availability, troubleshooting, and resolving operational issues.

Implementation best practices for CSPs to effectively employ SoD include (but are not limited to):

• a. SoD Role Management and Access:

  • i. A centralized role management system should be implemented to oversee and maintain role permissions

  • ii. Roles overlapping in responsibilities should be minimized to enhance SoD

  • iii. Roles should be created with specific permissions for different functions within the cloud environment in this way avoiding assigning a single identity with excessive privileges that could enable unauthorized actions (e.g., critical functions, such as authorization, approval, and execution, should be separated among different identities)

  • iv. Access levels should be segregated to restrict roles and their access to specific portions of the cloud environment

• b. For high-risk or critical activities, such as approving transactions or making modifications to sensitive data, a multi-level approval process should be implemented (i.e., multiple individuals from different roles approve an action)

• c. Role Assignment and Provisioning: Tools should be utilized (automated where possible) to assign and manage user roles based on job roles and required access levels

• d. Roles Reviews: Regular reviews should be conducted of role definitions and their permissions to minimize the risk of conflicting duties and to ensure they align with current business needs and maintain adequate separation of duties

• e. Role Changes Monitoring: Monitoring and logging mechanisms should be implemented to track changes to identity roles and permissions

• f. Roles Exception Management: An exception management process should be established for cases where multiple roles must be granted to a single user. This should require approval from senior management and documented justification

• g. Violations Reporting: Reporting procedures should be defined for suspected or confirmed SoD violations

• h. SoD Controls Monitoring: SoD controls should be regularly assessed to ensure their effectiveness and address any gaps or vulnerabilities

IAM-05: Least Privilege

Control Specification

Employ the least privilege principle when implementing information system access.

Shared Implementation Guidelines

[All Actors] Best Practices for implementing the Principle of Least Privilege (PoLP) include:

1. LP Infrastructure: The AI system’s infrastructure should be designed and configured with PoLP in mind by limiting the privileges of identities to the bare minimum required for their operation.

2. LP Roles and Permissions: Specific actions, data, and resources each role is required to access to perform their duties should be identified in order to determine the appropriate level of access based for each role/identity (RBAC should be utilized to enforce access control permissions).

3. Permission Change Management: Establish a process for requesting, approving, implementing, and documenting permission changes, to prevent undue privilege escalation. Require justification for changes and maintain an audit log.

4. LP Access of Administrative Accounts:

   • i. Administrative accounts (e.g., root or administrator accounts) should have the most restrictive access that is limited to specific tasks and environments, and ensured that they are only used when absolutely necessary

   • ii. MFA should be enforced for all administrative accounts and any other high-risk access points

5. Sensitive Data Access Limitation: Access to sensitive data should be restricted to the minimum number of identities required to accomplish their job function.

6. Unused Privileges Revocation: Identities access privileges should be proactively reviewed on a regular basis in order to revoke unused or excessive permissions to maintain the PoLP and reduce the attack surface.

7. LP Access Reviews:

   • i. Access privileges should be regularly reviewed and assessed to ensure they align with the current job/function requirements, to identify any unnecessary or excessive access and make adjustments accordingly

   • ii. Automated tools should be implemented to continuously monitor and evaluate the effectiveness of PoLP throughout the AI system

8. Temporary Access Grants: Where possible, temporary access grants with automatic expiration should be used so that persistent access to a resource stays limited to the minimum needed.

9. Comprehensive Access Logging: Log any access to resources including explicit purpose for access, in order to inform which roles need persistent access.

Implementation Guidelines for Cloud Service Providers (CSP)

[All Actors] Best Practices for implementing the Principle of Least Privilege (PoLP) include:

1. LP Infrastructure: The AI system’s infrastructure should be designed and configured with PoLP in mind by limiting the privileges of identities to the bare minimum required for their operation.

2. LP Roles and Permissions: Specific actions, data, and resources each role is required to access to perform their duties should be identified in order to determine the appropriate level of access based for each role/identity (RBAC should be utilized to enforce access control permissions).

3. Permission Change Management: Establish a process for requesting, approving, implementing, and documenting permission changes, to prevent undue privilege escalation. Require justification for changes and maintain an audit log.

4. LP Access of Administrative Accounts:

   • i. Administrative accounts (e.g., root or administrator accounts) should have the most restrictive access that is limited to specific tasks and environments, and ensured that they are only used when absolutely necessary

   • ii. MFA should be enforced for all administrative accounts and any other high-risk access points

5. Sensitive Data Access Limitation: Access to sensitive data should be restricted to the minimum number of identities required to accomplish their job function.

6. Unused Privileges Revocation: Identities access privileges should be proactively reviewed on a regular basis in order to revoke unused or excessive permissions to maintain the PoLP and reduce the attack surface.

7. LP Access Reviews:

   • i. Access privileges should be regularly reviewed and assessed to ensure they align with the current job/function requirements, to identify any unnecessary or excessive access and make adjustments accordingly

   • ii. Automated tools should be implemented to continuously monitor and evaluate the effectiveness of PoLP throughout the AI system

8. Temporary Access Grants: Where possible, temporary access grants with automatic expiration should be used so that persistent access to a resource stays limited to the minimum needed.

9. Comprehensive Access Logging: Log any access to resources including explicit purpose for access, in order to inform which roles need persistent access.

Iaas Provider:
The CSP is responsible for ensuring that the least privilege principle is applied when assigning system access to users, including: cloud administrators responsible for provisioning and deprovisioning cloud infrastructure resources; security administrators responsible for developing and implementing security policies and procedures; system operators responsible for monitoring resource performance and availability, troubleshooting, and resolving operational issues

PaaS Provider:
The CSP is responsible for ensuring that the least privilege principle is applied when assigning system access to users, including: cloud administrators responsible for provisioning and deprovisioning cloud infrastructure and platform resources; security administrators responsible for developing and implementing security policies and procedures; system and operational support teams responsible for monitoring resource performance and availability, troubleshooting and resolving operational issues.

SaaS Provider: The CSP is responsible for ensuring that the least privilege principle is applied when assigning system access to users, including: cloud administrators responsible for provisioning and deprovisioning cloud infrastructure and platform resources; security administrators responsible for developing and implementing security policies and procedures; developers responsible for developing and deploying applications to the cloud environment; system and operational support teams responsible for monitoring resource and application performance and availability, troubleshooting, and resolving operational issues.

Implementation best practices for CSPs to effectively employ the Principle of Least Privilege (PoLP) include (but are not limited to):

• a. LP Infrastructure: The cloud infrastructure should be designed and configured with PoLP in mind by limiting the privileges of identities to the bare minimum required for their operation

• b. LP Roles and Permissions: Specific actions, data, and resources each role is required to access to perform their duties should be identified in order to determine the appropriate level of access based for each role/identity (RBAC should be utilized to enforce access control permissions)

• c. LP Access of Administrative Accounts:

  • i. Administrative accounts (e.g., root or administrator accounts) should have the most restrictive access that is limited to specific tasks and environments, and ensured that they are only used when absolutely necessary

  • ii. MFA should be enforced for all administrative accounts and any other high-risk access points

• d. Sensitive Data Access Limitation: Access to sensitive data should be restricted to the minimum number of identities required to accomplish their job function

• e. Unused Privileges Revocation: Identities access privileges should be proactively reviewed on a regular basis in order to revoke unused or excessive permissions to maintain the PoLP and reduce the attack surface

• f. LP Access Reviews:

  • i. Access privileges should be regularly reviewed and assessed to ensure they align with the current job/function requirements, to identify any unnecessary or excessive access and make adjustments accordingly

  • ii. Automated tools should be implemented to monitor and evaluate the effectiveness of PoLP practices and to identify any potential gaps or misconfigurations

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.

Shared Implementation Guidelines

[All Actors]

1. Establish standardized onboarding processes for granting user access based on role, business need, and risk sensitivity.

2. Define clear approval workflows for access requests, involving appropriate stakeholders (e.g., HR, security, team leads).

3. Establish lifecycle-based access management to automatically manage user access at each stage (onboarding, role change, offboarding).

4. Ensure roles and entitlements are clearly defined and mapped for each application before initiating access provisioning.

5. Implement just-in-time (JIT) provisioning for sensitive systems to reduce standing access and potential exposure.

6. Enforce segregation of duties by restricting conflicting roles during provisioning and role assignment.

7. Monitor user access rights regularly to track misuse, detect potential breaches, and support timely access revocation.

8. Maintain detailed logs of all provisioning actions to support auditing, compliance, and forensic investigation.

Implementation Guidelines for Cloud Service Providers (CSP)

[All Actors]

1. Establish standardized onboarding processes for granting user access based on role, business need, and risk sensitivity.

2. Define clear approval workflows for access requests, involving appropriate stakeholders (e.g., HR, security, team leads).

3. Establish lifecycle-based access management to automatically manage user access at each stage (onboarding, role change, offboarding).

4. Ensure roles and entitlements are clearly defined and mapped for each application before initiating access provisioning.

5. Implement just-in-time (JIT) provisioning for sensitive systems to reduce standing access and potential exposure.

6. Enforce segregation of duties by restricting conflicting roles during provisioning and role assignment.

7. Monitor user access rights regularly to track misuse, detect potential breaches, and support timely access revocation.

8. Maintain detailed logs of all provisioning actions to support auditing, compliance, and forensic investigation.

Provide customers with role-based access provisioning templates tailored to cloud-native services.

Support integration with identity governance platforms for automated provisioning and policy enforcement.

Offer APIs and audit trails to enable downstream systems to track provisioning activities.

Ensure that multi-tenant environments enforce strict isolation when provisioning access across customer boundaries.

From CCM: Control Ownership Rationale. The CSP responsibility for this control relates to user access provisioning to the data and assets controlled and managed by the CSP in the cloud service environment.

Implementation Guidelines. Applicable to all service models: The CSPs should ensure that an access provisioning process is in place for the secure and controlled management of users and systems access to data and assets. Implementing this process effectively involves adhering to best practices that govern authorization, record-keeping, and communication of access changes.

Implementation best practices for CSPs to effectively implement a user access provisioning process include (but are not limited to):

• a. IDaaS for Access Provisioning: The IDaaS system (refer to IAM-03) should be leveraged to consolidate identity management and access provisioning across all cloud services and applications

• b. HR Systems Synchronization: The IDaaS system should be integrated with HR systems to automatically provision user accounts based on employee onboarding or role changes

• c. Provisioning Workflow Automation: The provisioning process should be automated using workflow automation tools to reduce errors and ensure timely and consistent changes

• d. Single-Point of Contact (SPOC) for Access Provisioning Management:

  • i. A role hierarchy and delegation structure should be defined to ensure that provisioning actions propagate effectively across related roles

  • ii. A centralized SPOC responsible should be designated for receiving and managing provisioning access requests

• e. Access Request and Approval Process: A formal access request and approval process for granting new access or modifying existing permissions should be established to ensure that access changes are reviewed and authorized by senior management based on business needs and risk assessments

• f. Access Provisioning Events Logging:

  • i. All identity related events, including creation, modification, and deletion of accounts, access privileges, failed attempts, and resource utilization should be monitored and recorded

  • ii. An accurate and up-to-date record of all access events should be generated and maintained for a specified retention period to facilitate investigations and compliance audits

• g. Access Provisioning Changes Notification:

  • i. Users should be informed of any access changes, such as account creation or updates, through secure channels like email or in-app notifications

  • ii. Periodic reporting of all access modification and provisioning actions should be provided to responsible security managers for review

• h. Access Provisioning Audits: Security audits should be regularly conducted to assess the effectiveness of the identity access provisioning process to identify potential vulnerabilities or misconfigurations

IAM-07: Access Changes and Revocation

Control Specification

De-provision or modify identity access in a timely manner.

Shared Implementation Guidelines

[All Actors]

1. Define time-bound policies for revoking access upon role change, termination, or inactivity.

2. Automate access modification and revocation workflows based on triggers (e.g., HR system updates).

3. Revoke all credentials and tokens (passwords, API keys, cloud roles, third-party SaaS entitlements) and/or any standing sessions the user still holds.

4. Detect and handle orphaned or dormant accounts; auto-disable or flag them for immediate review.

5. Log every modification or revocation action to an immutable store for audit, forensics and compliance reporting.

6. Run periodic access-list reviews to validate that current entitlements match active business roles and projects; document any exceptions and corrective actions.

Implementation Guidelines for Cloud Service Providers (CSP)

[All Actors]

1. Define time-bound policies for revoking access upon role change, termination, or inactivity.

2. Automate access modification and revocation workflows based on triggers (e.g., HR system updates).

3. Revoke all credentials and tokens (passwords, API keys, cloud roles, third-party SaaS entitlements) and/or any standing sessions the user still holds.

4. Detect and handle orphaned or dormant accounts; auto-disable or flag them for immediate review.

5. Log every modification or revocation action to an immutable store for audit, forensics and compliance reporting.

6. Run periodic access-list reviews to validate that current entitlements match active business roles and projects; document any exceptions and corrective actions.

Offer automated access revocation via hooks or event triggers integrated with customer identity systems.

Provide tools to monitor inactive accounts and apply revocation policies after a set period of non-use.

Immediately revoke access when service subscriptions or tenants are deactivated or deleted.

Ensure revocation audit data is available for regulatory inspection and reporting.

Applicable to all service models: As and when it is determined that the access that was previously granted to a user is not required any more, the CSP is responsible for deprovisioning the users’ access. The scope of the control includes all the access and permissions managed by the access management processes.

Implementation best practices for deprovisioning or modifying user access in a timely manner include (but are not limited to):

• a. IDaaS for Access Deprovisioning: The IDaaS system (refer to IAM-03) should be leveraged to consolidate identity management and access deprovisioning across all cloud services and applications

  • i. Deprovisioning tools or scripts should be utilized (automated where possible) as part of the IAM process for revoking access rights upon account termination or reassignment

  • ii. Access rights should be revoked within all the relevant identities following the termination date

• b. HR Systems Synchronization: The IDaaS system should be integrated with HR systems to automatically de-provision user accounts based on employee termination or role changes

• c. Deprovisioning Workflow Automation: The deprovisioning process should be automated using workflow automation tools to reduce errors and ensure timely and consistent changes

• d. Single-Point of Contact (SPOC) for Access Deprovisioning Management:

  • i. A role hierarchy and delegation structure should be defined to ensure that deprovisioning actions propagate effectively across related roles

  • ii. A centralized SPOC responsible should be designated for receiving and managing deprovisioning access requests

• e. Access Deprovisioning Events Logging:

  • i. All identity related events, including modification and deletion of accounts, access privileges, failed attempts, and resource utilization should be monitored and recorded

  • ii. An accurate and up-to-date record of all access events should be generated and maintained for a specified retention period to facilitate investigations and compliance audits

• f. Access Deprovisioning Changes Notification:

  • i. Users should be informed of access changes, such as deprovisioning and modification of access permissions (e.g., due to periodic access recertification, transfer, account termination), through secure channels like email or in-app notifications

  • ii. Periodic reporting of all access modification and deprovisioning actions should be provided to responsible security managers for review

• g. Revocation and Suspension Mechanisms: A process should be implemented for revoking or suspending access rights temporarily, when necessary, to address security breaches or compliance violations

• h. Inactive Identities Deprovision: A process should be implemented (automated if possible) to detect inactive accounts, flag them for review and where necessary deprovision unused or inactive identities

• i. Deprovisioning Incorporation into Crisis Management Plans: Deprovisioning procedures should be integrated into crisis management plans to ensure timely and effective access revocation in the event of incidents or emergencies

• j. Access Deprovisioning Audits: Security audits should be regularly conducted to assess the effectiveness of the user access deprovisioning process and identify potential vulnerabilities or misconfigurations

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.

Shared Implementation Guidelines

[All Actors]

1. Conduct periodic reviews (e.g., quarterly) of all identity access rights for appropriateness and necessity.

2. Validate least-privilege and segregation-of-duties; document explicit rationale for any persistent or elevated access.

3. Use automated tooling to generate review reports, detect orphan / unused accounts, and route tasks to resource owners for sign-off.

4. Require certification and reconciliation; access that is unapproved, stale or in conflict with role definitions must be revoked or remediated promptly.

5. Track outcomes and evidence of each review cycle, with timestamps and approver IDs, to satisfy audit and compliance needs.

Implementation Guidelines for Cloud Service Providers (CSP)

Role based:

1. Provide customers with built-in tools to automate periodic access reviews and remediation actions.

2. Offer prebuilt reports showing current access configurations by user, group, and service.

3. Enable review enforcement through policy-based access expiration or workflow integration.

4. Support compliance requirements like SOX, ISO 27001, and HIPAA through templated access review modules.

[All Actors]

1. Conduct periodic reviews (e.g., quarterly) of all identity access rights for appropriateness and necessity.

2. Validate least-privilege and segregation-of-duties; document explicit rationale for any persistent or elevated access.

3. Use automated tooling to generate review reports, detect orphan / unused accounts, and route tasks to resource owners for sign-off.

4. Require certification and reconciliation; access that is unapproved, stale or in conflict with role definitions must be revoked or remediated promptly.

5. Track outcomes and evidence of each review cycle, with timestamps and approver IDs, to satisfy audit and compliance needs.

From CCM v4.1: Control Ownership Rationale. This control’s implementation responsibility is “Shared (Independent)” since CSP and CSC are individually responsible for managing the processes and procedures related to periodic review of access by supervisors for personnel (employees and contractors) in their respective environments. The CSP owns the control in relation to the entities whose access to the cloud environment the CSP provisions and maintains, including its internal users, external users (vendors and customers), applications, and services.

Implementation Guidelines. Applicable to all service models: The CSP is responsible for classifying the access type by the risk they pose to their organization and facilitating the review of user’s access periodically (frequency determined based on risk level) or when certain specific events occur such as personnel termination or transfer.

To effectively review and validate user access for least privilege and separation of duties, CSPs should implement a comprehensive approach that encompasses implementation best practices, and a risk-based frequency for such reviews:

• a. Access Management and Reviews:

  • i. Access management processes and records should be centralized to facilitate easier identity access review and reduce the risk of inconsistencies across different cloud systems

  • ii. Access reviews should be conducted for remediating obsolete, excessive or unnecessary access, to ensure that access rights adhere to roles and responsibilities, least privilege and SoD principles

  • iii. Access reviews should be automated, if possible, using automated tools and scripts

  • iv. Reviews of high-risk access configurations, such as administrator accounts and access to sensitive data should be prioritized for scheduling

• b. Access reviews should result to a re-approval of the PoLP, SoD or other entitlements that each identity continues to need to fulfill their job responsibilities or denial of any conflicting combinations of entitlements based on the current and future job responsibilities of the user’s role

• c. Access Reviews Frequency: The frequency of identity access reviews should be commensurate with the organization’s risk tolerance and the sensitivity of the data and systems being protected. For high-risk environments, reviews may be conducted on a daily or weekly basis, while less sensitive systems may be reviewed monthly or quarterly

• d. Access Review Documentation: The results of access reviews should be documented and records maintained for audit purposes

• e. Audit and Logging: Audit and logging capabilities should be implemented to track identity access activities and generate records of who accessed, what resources, and when, facilitating investigations and identifying any suspicious activity

• f. Continuous Monitoring and Evaluation: Continuous monitoring solutions should be implemented to scan for unauthorized or anomalous activities and to detect changes in access patterns, privilege escalation, and other potential security breaches

• g. Access Certification: An access certification process should be implemented that requires users to periodically justify their access privileges to ensure that access is still necessary and relevant for their current roles.

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.

Shared Implementation Guidelines

[All Actors]

1. Define clear boundaries between roles such as administrator, developer, auditor, and operator.

2. Restrict conflicting or high-risk role combinations (e.g., developer and production admin) to enforce separation of duties.

3. Segregate duties in provisioning workflows so no single person requests, approves and applies the same privilege.

4. Monitor privilege escalation paths and restrict temporary elevation through strong justification and approval.

5. Regularly assess segregation policies for effectiveness and alignment with risk management frameworks.

6. Enforce role rules through RBAC or ABAC in every system; apply the same constraints to API keys and service accounts.

7. Run periodic certification / reconciliation campaigns to verify that current entitlements match approved role definitions; remediate exceptions.

Implementation Guidelines for Cloud Service Providers (CSP)

Role based:

1. Provide fine-grained access controls to enforce segregation across cloud console, APIs, and CLI interfaces.

2. Offer templates for privileged role separation across dev, ops, and security functions.

3. Monitor for anomalous access patterns that indicate privilege abuse or role merging.

4. Support policy-as-code to encode segregation rules and enforce them programmatically.

[All Actors]

1. Define clear boundaries between roles such as administrator, developer, auditor, and operator.

2. Restrict conflicting or high-risk role combinations (e.g., developer and production admin) to enforce separation of duties.

3. Segregate duties in provisioning workflows so no single person requests, approves and applies the same privilege.

4. Monitor privilege escalation paths and restrict temporary elevation through strong justification and approval.

5. Regularly assess segregation policies for effectiveness and alignment with risk management frameworks.

6. Enforce role rules through RBAC or ABAC in every system; apply the same constraints to API keys and service accounts.

7. Run periodic certification / reconciliation campaigns to verify that current entitlements match approved role definitions; remediate exceptions.

From CCM v4.1: Control Ownership Rationale. This control’s implementation responsibility is “Shared (Independent)” since CSP and CSC are both responsible, but also independently manage their respective processes and procedures to maintain SoD between the privileged roles that have administrative access to data or encryption keys, and the roles that have access to logging capabilities (such as logging configuration and log files in storage) that captures the access to the data or the keys. The CSP owns the control in relation to the entities whose access to the cloud environment the CSP provisions and maintains, including CSP internal users, external users (vendors and customers), applications, and services.

Implementation Guidelines. Applicable to all service models: The CSP is responsible for ensuring the SoD between the privileged roles that have administrative access to the data, the keys that are used to encrypt the data, and the logging capabilities that capture the access to the data or the keys. The CSP is also responsible to maintain separation of accounts and access permissions between the production and non-production environments to ensure the personnel with access only to the non-production accounts are not able to access the production environment using non-production accounts.

Implementation best practices for the segregation of privileged access roles include (but are not limited to):

• a. Privileged Access Roles Segregation:

  • i. The roles and responsibilities of each privileged identity should be defined ensuring that no single identity holds excessive privileges in order to establish a separation of duties and reduce the risk of misuse

  • ii. Privileged roles that, if combined, create conflicting combinations of access should be explicitly identified and labeled in PAM systems

  • iii. The roles and permissions that grant access to non-production environments should be separated from the roles and permissions that grant access to production environments

• b. Access Segregation to Different Privileged Areas:

  • i. Privileged and administrative functions access should be divided into distinct realms, such as administrative access, encryption/key management, configuration changes, and logging, to prevent a single identity from compromising access to all these areas simultaneously

  • ii. Privileged activities should be isolated within a separate environment or virtual machine, where possible

• c. Access Restriction to Sensitive Data and Systems:

  • i. Access controls should be implemented to restrict privileged users from accessing sensitive systems and data that are not directly related to their job duties (enforce PoLP for privileged accounts)

  • ii. SSH keys with strong key encryption and rotation should be utilized to authenticate privileged access over SSH connections

• d. Privileged Access Segregation Reviews:

  • i. Access roles with privileged and administrative capabilities should be reviewed and updated periodically to ensure proper segregation and within reasonable frequencies specified by the CSP’s IAM policy

  • ii. Automated processes should be implemented to regularly review identities’ segregated privilege access permissions

• e. Continuous Monitoring and Evaluation: The effectiveness of privileged access roles segregation and security measures (to data, crypto keys and systems configurations) should be monitored, logged and regularly assessed.

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.

Shared Implementation Guidelines

[All Actors]

1. Implement time bound, purpose driven access to allow timebound access provisioning. Examples could include “Just-In-Time”(JIT), and “Zero Standing Privileges” (ZSP). This can be achieved by temporary provisioning of permissions to the user, temporary assignment of user to a group with the required permissions or temporary impersonation of an account with the required permissions.

2. Implement an approval process for provisioning sensitive privileges.

3. Create an auditing procedure to review activation and activity of privileged roles on a regular basis.

4. Regularly review and certify individuals with the ability to provision privileged credentials.

5. Privileges allocated should be limited by a session duration and revoked following the established time-duration leaving no standing access (Zero Standing Privileges).

[AP, AIC]

1. Document agent-based access to Privileged Roles in a similar manner to users.

2. Perform audits and access certification on AI systems with access to privileged roles and permissions.

Implementation Guidelines for Cloud Service Providers (CSP)

[All Actors]

1. Implement time bound, purpose driven access to allow timebound access provisioning. Examples could include “Just-In-Time”(JIT), and ZSP. This can be achieved by temporary provisioning of permissions to the user, temporary assignment of user to a group with the required permissions or temporary impersonation of an account with the required permissions.

2. Implement an approval process for provisioning sensitive privileges.

3. Create an auditing procedure to review activation and activity of privileged roles on a regular basis.

4. Regularly review and certify individuals with the ability to provision privileged credentials.

5. Privileges allocated should be limited by a session duration and revoked following the established time-duration leaving no standing access (Zero Standing Privileges).

From CCM v4.1: Control Ownership Rationale. This control is “Shared (Independent)” since CSP and CSC are both responsible for managing their respective processes and procedures for managing privileged access in their respective environments. The CSP owns the control in relation to the entities whose access to the cloud environment the CSP provisions and maintains, including CSP internal users, external users (vendors and customers), applications, and services.

Implementation Guidelines. Applicable to all service models: The CSP is responsible for ensuring that privileged access and rights are properly approved for a definite time period, and that the user is provided the privileged access for that time period only. The user’s access should be removed when the approved time period elapses.

Scope of access includes the privileges of: cloud administrators responsible for provisioning and deprovisioning cloud infrastructure resources; security administrators responsible for developing and implementing security policies and procedures; and system operators who are responsible for monitoring resource performance and availability, troubleshooting, and resolving operational issues.

Implementation best practices include (but are not limited to):

• a. Privileged Access Management (PAM):

  • i. A lifecycle management process for privileged access, encompassing provisioning, usage, monitoring, and revocation should be established and regularly reviewed to update access privileges and to align with changing business requirements and user roles

  • ii. The access and rights considered privileged should be defined and communicated to all relevant parties, including all asset owners

  • iii. The roles that can request privileged access should be defined and well documented, including roles and privileges that should not be assigned to the same user

  • iv. Access levels for different types of privileged roles should be defined, including escalating authorization for high-risk access

• b. PAM solutions should be leveraged to manage and monitor privileged account access and credentials over privileged accounts, enabling secure storage and rotation of privileged credentials, auditing and logging access activity, and enforcing MFA for privileged sessions vi. To ensure the security of critical accounts and sensitive data, all modifications to privileged access should trigger real-time notifications to security managers for review

• c. Privileged Access Request:

  • i. A formal privileged access request process should be established that requires users to justify and obtain approval for accessing privileged accounts

  • ii. Privileged access should be granted only after the validation of justification and multiple levels of approvals

• d. Privileged Access Restriction: Privileged access to specific resources and systems, preventing users from traversing beyond their authorized scope should be restricted

• e. Automated Privilege Revocation: Automated processes for revoking privileged access upon termination of employment, role changes, or other relevant events should be implemented

• f. Privileged Access Sessions Duration:

  • i. Session management capabilities should be implemented to limit the duration of privileged access sessions and enforce timed out sessions after inactivity periods

  • ii. Just-in-Time Access (JIT) should be utilized to grant access only for the specific time period that is needed rather than granting permanent access to minimize the window of opportunity for unauthorized access

• g. Privileged Access Password Management: Strong password management practices for privileged accounts should be implemented including regular password changes and complexity requirements

• h. Access Exception Process:

  • i. A process for granting temporary or exceptional access should be established for privileged accounts and only in exceptional circumstances (refer to CCC-08)

  • ii. Authorization from senior management should be acquired and justifications for the access request documented

• i. Credential Vaulting and Rotation: A secure credential vault should be used to store and manage privileged access credentials. Credentials should be rotated regularly to minimize the risk of unauthorized access

• j. Privileged Access Escalation Prevention: Mechanisms to prevent privilege escalation, ensuring that users cannot elevate their access beyond their assigned privileges should be implemented (e.g., use RBAC, MAC access control mechanisms)

• k. Privileged Access Roles Reviews: Roles with privileged access and rights should be included in the periodic access review activities performed at reasonable frequencies specified by the identity and access management policy

• l. Continuous Monitoring and Logging: The effectiveness of privileged access roles should be monitored, logged and regularly assessed. PAM solutions, operating systems, and relevant software should be updated to address potential vulnerabilities

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.

Shared Implementation Guidelines

[All Actors excluding AIC]

1. Inventory high-risk privileged access/roles (such as access to customer data) and/or actions and their relevant AIC approver.

2. Define an access request workflow, including the request initiation method, AIC notification and AIC approval method.

3. Send a notification to the AIC when high-risk privileged access has been activated.

4. Log all actions related to the process (approval, provisioning/de-provisioning, etc) in an audit log visible to the AIC.

5. Ensure the purpose for privileged access utilization is communicated to the AIC in addition to the details of the permission set.

6. Ensure access is time-bound aligning with business needs. For example, privileges (entitlements) should be should be clearly defined and implemented via JIT or Zero Standing Privilege (ZSP) mechanisms and support session duration limits.

[AP, OSP, AIC]

1. Ensure there are mechanisms in place for approval and/or notification from agent-based systems requesting and utilizing privileged access and roles.

Implementation Guidelines for Cloud Service Providers (CSP)

[All Actors excluding AIC] Implementation best practices include (but are not limited to):

1. Inventory high-risk privileged access/roles (such as access to customer data) and/or actions and their relevant AIC approver.

2. Define an access request workflow, including the request initiation method, AIC notification and AIC approval method.

3. Send a notification to the AIC when high-risk privileged access has been activated.

4. Log all actions related to the process (approval, provisioning/de-provisioning, etc) in an audit log visible to the AIC.

5. Ensure the purpose for privileged access utilization is communicated to the AIC in addition to the details of the permission set.

6. Ensure access is time-bound aligning with business needs. For example, privileges (entitlements) should be should be clearly defined and implemented via JIT or Zero Standing Privilege (ZSP) mechanisms and support session duration limits.

From CCM v4.1: Control Ownership Rationale. This control’s implementation responsibility is “Shared (Dependent)” since the CSP and CSC are both responsible for determining the high risk data and granting privileged access to CSP users. The CSP owns the control in relation to the entities whose access to the cloud environment the CSP provisions and maintains, including CSP internal users, external users (vendors and customers), applications, and services.

Implementation Guidelines. Applicable to all service models: The CSP is responsible for identifying the privileged roles that provide access to CSC’s data by the CSP users. The CSP is also responsible for ensuring a process exists to obtain approvals from CSC-authorized persons before the CSP user is provided the privileged roles temporarily or on a continuous basis (the CSP user’s privileged access is properly approved in its authorized access requisition system). The CSP user’s privileged activity should be logged, reported, and monitored for any suspicious activity.

Implementation best practices include (but are not limited to):

• a. Scope and Privileged Roles Definition:

  • i. The scope of high-risk data (e.g., personal data, financial data, intellectual property, medical records, etc.) and the types of privileged roles that require CSC approval for CSP access should be defined

  • ii. CSC approval processes should be established, including timelines, notifications, and documentation. These requirements should be aligned with the CSC’s organizational risk assessment and data classification policies

• b. CSP-CSC Approval Workflow:

  • i. For any CSP privileged access request involving high-risk data, an explicit approval should be required from the relevant CSC representative

  • ii. The approval should involve multiple authorization levels (e.g., approval from designated CSC representatives, legal or compliance personnel, and senior management) and should be documented and retained securely to maintain accountability and traceability of access decisions, including acceptable reasons or justifications for which privileged access may be requested

  • iii. A formal CSC approval workflow process should be established that includes steps and roles for both the CSP and the CSC. Timelines for CSC approval and CSP action should be defined and communicated to relevant parties

  • iv. Automated notification systems should be implemented to keep both parties informed of the status of access requests

• c. Access Request Templates:

  • i. Standardized access request templates for both the CSP and the CSC to use should be established

  • ii. Templates should include all necessary information, such as the purpose of access, the data to be accessed, and the duration of access.

  • iii. Both parties should sign off on the templates before access is granted

• d. Access Control: A secure PAM system should be leveraged to control privileged access to high-risk CSC data and to restrict privileged access to the minimum required for specific tasks (refer to IAM-10)

• e. Audit and Monitoring:

  • i. Audit and monitoring capabilities should be implemented to track all access requests, approvals, and activities related to CSC’s high-risk data (e.g., logging access attempts, successful access, changes to access permissions, and any suspicious or unauthorized activities)

  • ii. The CSP should provide CSCs with access to audit logs for all access to their high risk CSC data, to allow CSCs to track who has accessed their data and when

  • iii. Reporting mechanisms should be established to provide transparency to both the CSP and the CSC. For example, actions such as the following should be logged and reported:

    • modifying permissions of other local system accounts

    • creating backdoors such as establishing custom SSH keys

    • modifying the sudo configuration file on a unix/linux operating system

  • iv. Areas for improvement should be identified and necessary adjustments made to ensure that the processes are compliant with the CSC’s organizational risk assessment and data protection requirements

• f. Access Level Agreements:

  • i. Service levels for granting CSP access to high-risk CSC data should be defined in alignment to CSP-CSC contractual agreements, including response times for request submissions, approval processes, and access duration. Escalation paths for non-compliance should be established (refer to STA domain)

  • ii. Access agreement and rights should be regularly reviewed to ensure that access aligns with the CSC’s organizational risk assessment

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.

Shared Implementation Guidelines

[All Actors]

1. Integrate organization Identity Providers with platforms and applications to streamline unique identity ids management.

2. Integrate procedures for generating unique identifiers for identities and accounts into provisioning processes (e.g. Onboarding new hires, access requests to new systems).

3. When unique identifiers can not be utilized, employ a “checkout” mechanism via technology or administrative controls in which an account is assigned to an identity for a time period.

4. Implement access control measures to ensure identity IDs are authenticated and authorized when accessing information.

[OSP/AP/AIC]

1. Ensure Agent-Based systems are uniquely identified to ensure actions can be attributed to the correct components (e.g service accounts for agents are unique for the tools and model versions [A2A Datacards]).

2. Implement access control with Agent-based systems utilizing their unique IDs for authorization to resources.

3. Regularly Audit identity accounts and their usage to ensure all actors are uniquely identified (check for indication of shared account usage).

[OSP/AP]

1. Ensure that secrets and keys for programmatic access are assigned and associated with a unique Actor ID (user or agent based system).

2. Ensure provided platform supports unique ID for AICs identities.

3. Ensure provided platform provides access control mechanisms supporting unique IDs for AICs identities.

Implementation Guidelines for Cloud Service Providers (CSP)

[All Actors]

1. Integrate organization Identity Providers with platforms and applications to streamline unique identity ids management.

2. Integrate procedures for generating unique identifiers for identities and accounts into provisioning processes (e.g. Onboarding new hires, access requests to new systems).

3. When unique identifiers can not be utilized, employ a “checkout” mechanism via technology or administrative controls in which an account is assigned to an identity for a time period.

4. Implement access control measures to ensure identity IDs are authenticated and authorized when accessing information.

The CSP is responsible for ensuring that the identities requesting system access are uniquely identifiable and can be directly held responsible for their actions. If the CSP permits the use of shared accounts for privileged access or functions, the system logs should capture the unique ID of the identity acting on behalf of the shared account to ensure individual accountability.

The scope of such shared accounts include the accounts for: cloud administrators responsible for provisioning and deprovisioning cloud infrastructure resources; security administrators responsible for developing and implementing security policies and procedures; and system operators who are responsible for monitoring resource performance and availability, troubleshooting, and resolving operational issues.

Implementation guidelines to ensure user identification and association with unique IDs include (but are not limited to):

• a. Unique ID Management:

  • i. The collection purpose, usage, and retention of identity IDs should be established, documented and aligned with the CSP’s privacy and security regulations to provide identities with transparent information about how their data is collected, processed, and shared

  • ii. Use cases for identification and the level of sensitivity of the data being associated with IDs should be defined

  • iii. Each identity account should have a unique ID before any access is granted. If use of shared accounts is permitted, an up-to-date list of shared accounts and all identities that can act on behalf of the shared accounts, including their unique IDs and privileges, should be maintained at all times

  • iv. Any use of a shared account should be traceable to a unique identity ID that acted on behalf of the account

• b. Automated controls should be implemented to enforce unique identifier requirements

• c. Unique ID Generation: A cryptographically secure algorithm to generate unique IDs for identities should be employed to prevent the possibility of collisions or reuse of IDs

• d. Pseudonymous IDs: Instead of directly associating identity IDs with personal data, pseudonymization techniques should be employed and implemented

• e. ID Access Control: Access control measures should be implemented to restrict access to identity IDs to authorized personnel, systems and processes

• f. ID Encryption: All identity IDs should be encrypted at rest and in transit to protect them from unauthorized access and data breaches

• g. ID Mapping and Linking: A secure and auditable mechanism for mapping identity IDs to personal information or other sensitive data should be implemented

• h. ID Lifetime Limitations:

  • i. Limits on the lifetime of identity IDs should be set to prevent the accumulation of excessive personal data over time

  • ii. Collection of more data than is required for the specific purpose should be limited, and that any additional data collected separately should be required with explicit identity consent

• i. Identity Consent and Opt-Out Options: Identities should be provided with explicit consent options for the collection, usage, and sharing of their IDs and allowed to opt out of specific ID usage or request their removal from the CSP’s databases

• j. Continuous Monitoring and Evaluation: Monitoring mechanisms should be implemented to track and evaluate identity ID usage, access, modification and deletion, and regularly reviewed to detect any anomalies or potential security breaches

• k. Regulatory Changes: Keep abreast of evolving data privacy regulations (e.g., GDPR, CCPA) and adapt the ID management practices accordingly

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.

Shared Implementation Guidelines

[ALL Actors - AICM - CSP]

1. Authentication Management:

   • i. A centralized authentication system that can manage identities, authentication credentials, and access control permissions across all AI service components should be implemented

   • ii. Users that require privileged access (e.g.,administrators and IT staff) should be identified to establish stricter authentication measures

   • iii. Specific authentication factors and technical measures should be defined and implemented for each access level, including MF A for privileged identities and sensitive data access

2. MFA Usage Scope:

   • i. Sensitive Data Access: Strong authentication should be enforced at all user accounts, requiring a combination of something the user: Knows (such as a password); Has (such as a mobile device or token); Is (such as biometrics); MFA for all users should be enabled, including non-privileged users who access sensitive data.

   • ii. Administrative Access: MFA should be enforced for all administrative access (e.g., access to management consoles, AI lifecycle components, and other critical AI infrastructure elements). If MFA cannot be implemented in a particular situation, the risk should be formally registered

   • iii. Third-Party Access: MFA should be enforced for third-party access, such as through APIs or AI services, to protect against unauthorized access by external entities.

3. Second Factor Authentication: Second factor authentication should be leveraged in addition to passwords to add an extra layer of security by requiring a second factor of:

   • i. Time-Based One-Time Passwords (TOTPs) to allow users to generate temporary codes via email or a smartphone app synchronized with an authentication server.

   • ii. Hardware tokens or USB keys that generate unique codes for authentication.

4. Passwordless Authentication: Passwordless authentication solutions should be implemented that replace traditional passwords with secure alternatives such as phishing-resistant MFA and FIDO2-compliant security keys or biometrics.

5. Authentication Credentials Protection: All authentication credentials should be transmitted through secure channels (e.g., TLS/HTTPS) and never stored in plaintext but rendered unreadable in storage on all system components using strong cryptography.

6. Authentication Credentials Change Approval: Requests to change or modify authentication credentials (i.e., performing password resets, provisioning new tokens, generating new keys) should be approved only after verification of the user’s identity.

7. Continuous User Authentication (CUA): CUA should be leveraged as a method of maintaining user authentication throughout their session, requiring periodic reauthentication to ensure that the user is still authorized and has not been compromised.

8. Single Sign-On (SSO): SSO should be implemented for accessing multiple services and applications with a single login credential to simplify the authentication process for users.

9. Digital Certificates: Digital certificates should be utilized for authentication and authorization purposes, especially for system identities.

10. CRL and OCSP Checks: Certificate Revocation Lists (CRLs) and Online Certificate Status Protocol (OCSP) checks should be implemented to verify the validity and revocation status of digital certificates.

11. Certificate Lifecycle: The lifecycle of digital certificates should be securely managed including issuance, renewal, and revocation.

12. Certificate Storage: Digital certificates should be stored securely, using encryption and access control mechanisms.

13. Authentication Usage Monitoring:

    • i. All authentication mechanisms and enabled features should be properly installed, configured, and authentication logs monitored for the desired and expected results.

    • ii. MFA, credentials, and digital certificate usage patterns should be continuously monitored and reviewed to proactively identify potential vulnerabilities or compromises.

[All Actors]

1. Implement risk-based authentication controls that evaluate host and user risk (examples: IP reputation and requesting device posture).

2. Enforce the use of phish-resistant MFA (Hardware Key, Certificate Based) for high-risk systems where possible.

3. Provide self-service MFA enrollment for AI service users, supporting FIDO2 security keys, TOTP apps, biometrics, and more.

[OSP & AP]

1. Support secure machine and Agent-Based system authentication such as certificate and token based.

2. Support integration of AIC federated authentication methods (OIDC/OAuth).

3. Disable the usage of insecure protocols and methods by default.

Implementation Guidelines for Cloud Service Providers (CSP)

[ALL Actors - AICM - CSP]

1. Authentication Management:

   • i. A centralized authentication system that can manage identities, authentication credentials, and access control permissions across all AI service components should be implemented

   • ii. Users that require privileged access (e.g.,administrators and IT staff) should be identified to establish stricter authentication measures

   • iii. Specific authentication factors and technical measures should be defined and implemented for each access level, including MF A for privileged identities and sensitive data access

2. MFA Usage Scope:

   • i. Sensitive Data Access: Strong authentication should be enforced at all user accounts, requiring a combination of something the user: Knows (such as a password); Has (such as a mobile device or token); Is (such as biometrics); MFA for all users should be enabled, including non-privileged users who access sensitive data.

   • ii. Administrative Access: MFA should be enforced for all administrative access (e.g., access to management consoles, AI lifecycle components, and other critical AI infrastructure elements). If MFA cannot be implemented in a particular situation, the risk should be formally registered

   • iii. Third-Party Access: MFA should be enforced for third-party access, such as through APIs or AI services, to protect against unauthorized access by external entities.

3. Second Factor Authentication: Second factor authentication should be leveraged in addition to passwords to add an extra layer of security by requiring a second factor of:

   • i. Time-Based One-Time Passwords (TOTPs) to allow users to generate temporary codes via email or a smartphone app synchronized with an authentication server.

   • ii. Hardware tokens or USB keys that generate unique codes for authentication.

4. Passwordless Authentication: Passwordless authentication solutions should be implemented that replace traditional passwords with secure alternatives such as phishing-resistant MFA and FIDO2-compliant security keys or biometrics.

5. Authentication Credentials Protection: All authentication credentials should be transmitted through secure channels (e.g., TLS/HTTPS) and never stored in plaintext but rendered unreadable in storage on all system components using strong cryptography.

6. Authentication Credentials Change Approval: Requests to change or modify authentication credentials (i.e., performing password resets, provisioning new tokens, generating new keys) should be approved only after verification of the user’s identity.

7. Continuous User Authentication (CUA): CUA should be leveraged as a method of maintaining user authentication throughout their session, requiring periodic reauthentication to ensure that the user is still authorized and has not been compromised.

8. Single Sign-On (SSO): SSO should be implemented for accessing multiple services and applications with a single login credential to simplify the authentication process for users.

9. Digital Certificates: Digital certificates should be utilized for authentication and authorization purposes, especially for system identities.

10. CRL and OCSP Checks: Certificate Revocation Lists (CRLs) and Online Certificate Status Protocol (OCSP) checks should be implemented to verify the validity and revocation status of digital certificates.

11. Certificate Lifecycle: The lifecycle of digital certificates should be securely managed including issuance, renewal, and revocation.

12. Certificate Storage: Digital certificates should be stored securely, using encryption and access control mechanisms.

13. Authentication Usage Monitoring:

    • i. All authentication mechanisms and enabled features should be properly installed, configured, and authentication logs monitored for the desired and expected results.

    • ii. MFA, credentials, and digital certificate usage patterns should be continuously monitored and reviewed to proactively identify potential vulnerabilities or compromises.

[All Actors]

1. Implement risk-based authentication controls that evaluate host and user risk (examples: IP reputation and requesting device posture).

2. Enforce the use of phish-resistant MFA (Hardware Key, Certificate Based) for high-risk systems where possible.

3. Provide self-service MFA enrollment for AI service users, supporting FIDO2 security keys, TOTP apps, biometrics, and more.

The CSP is responsible for ensuring that non-console administrative access and remote access require MFA.

MFA and digital certificate implementation best practices for sensitive data access include (but are not limited to):

• a. Authentication Management:

  • i. A centralized authentication system that can manage identities, authentication credentials, and access control permissions across all cloud services should be implemented

  • ii. Users that require privileged access (e.g., administrators and IT staff) should be identified to establish stricter authentication measures

  • iii. Specific authentication factors and technical measures should be defined and implemented for each access level, including MFA for privileged identities and sensitive data access

• b. MFA Usage Scope:

  • i. Sensitive Data Access: Strong authentication should be enforced at all user accounts, requiring a combination of something the user: Knows (such as a password); Has (such as a mobile device or token); Is (such as biometrics); MFA for all users should be enabled, including non-privileged users who access sensitive data

  • ii. Administrative Access: MFA should be enforced for all administrative access (e.g., access to cloud management consoles, virtual machines, remote access gateways, and other critical cloud infrastructure elements). If MFA cannot be implemented in a particular situation, the risk should be formally registered

  • iii. Remote Access: MFA should be enforced for all remote access, whether through VPNs, web applications, or mobile devices

  • iv. Third-Party Access: MFA should be enforced for third-party access, such as through APIs or cloud services, to protect against unauthorized access by external entities

• c. Second Factor Authentication: Second factor authentication should be leveraged in addition to passwords to add an extra layer of security by requiring a second factor of:

  • i. Time-Based One-Time Passwords (TOTPs) to allow users to generate temporary codes via SMS, email, a smartphone app synchronized with an authentication server

  • ii. Hardware tokens or USB keys that generate unique codes for authentication

• d. Passwordless Authentication: Passwordless authentication solutions should be implemented that replace traditional passwords with secure alternatives such as phishing-resistant MFA and FIDO2-compliant security keys or biometrics

• e. Authentication Credentials Protection: All authentication credentials should be transmitted through secure channels (e.g., TLS/HTTPS) and never stored in plaintext but rendered unreadable in storage on all system components using strong cryptography

• f. Authentication Credentials Change Approval: Requests to change or modify authentication credentials (i.e., performing password resets, provisioning new tokens, generating new keys) should be approved only after verification of the user’s identity

• g. Continuous User Authentication (CUA): CUA should be leveraged as a method of maintaining user authentication throughout their session, requiring periodic reauthentication to ensure that the user is still authorized and has not been compromised

• h. Single Sign-On (SSO): SSO should be implemented for accessing multiple services and applications with a single login credential to simplify the authentication process for users

• i. Digital Certificates: Digital certificates should be utilized for authentication and authorization purposes, especially for system identities

• j. CRL and OCSP Checks: Certificate Revocation Lists (CRLs) and Online Certificate Status Protocol (OCSP) checks should be implemented to verify the validity and revocation status of digital certificates

• k. Certificate Lifecycle: The lifecycle of digital certificates should be securely managed including issuance, renewal, and revocation

• l. Certificate Storage: Digital certificates should be stored securely, using encryption and access control mechanisms

• m. Authentication Usage Monitoring:

  • i. All authentication mechanisms and enabled features should be properly installed, configured, and authentication logs monitored for the desired and expected results

  • ii. MFA, credentials, and digital certificate usage patterns should be should be continuously monitored and reviewed to proactively identify potential vulnerabilities or compromises

IAM-14: Credentials Management

Control Specification

Define, implement and evaluate processes, procedures and technical measures for the secure management of authentication credentials, including passwords.

Shared Implementation Guidelines

1. Define and enforce authentication credential policies that align with industry standards (e.g., NIST SP 800-63, ISO/IEC 27001), including minimum length, complexity, expiration, and reuse limits.

2. Implement strong hashing algorithms (e.g., bcrypt, Argon2) and salting practices to securely store authentication credentials.

3. Prohibit credential sharing, hardcoding in codebases, or storing credentials in plain text across all AI and infrastructure components.

4. Require multi-factor authentication (MFA) for all privileged and sensitive access accounts.

5. Implement privileged access tools such as credential vaults that securely store, rotate, and manage credentials. These tools should support automatic password generation, credential expiry, and access logging.

6. Conduct regular credential audits to detect weak, default, or compromised credentials across environments.

7. Enforce secure credential reset and recovery processes, including identity verification and logging of all reset activities.

8. Use secrets management tools to securely handle credentials in code, pipelines, or deployment configurations.

9. Educate users and administrators on secure credential hygiene as part of access management training.

Implementation Guidelines for Cloud Service Providers (CSP)

1. Define and enforce credential policies that align with industry standards (e.g., NIST SP 800-63, ISO/IEC 27001), including minimum length, complexity, expiration, and reuse limits.

2. Implement strong hashing algorithms (e.g., bcrypt, Argon2) and salting practices to securely store authentication credentials.

3. Prohibit credential sharing, hardcoding in codebases, or storing credentials in plain text across all AI and infrastructure components.

4. Require multi-factor authentication (MFA) for all privileged and sensitive access accounts.

5. Implement privileged access tools such as credential vaults that securely store, rotate, and manage credentials. These tools should support automatic password generation, credential expiry, and access logging.

6. Conduct regular credential audits to detect weak, default, or compromised credentials across environments.

7. Enforce secure credential reset and recovery processes, including identity verification and logging of all reset activities.

8. Use secrets management tools to securely handle credentials in code, pipelines, or deployment configurations.

9. Educate users and administrators on secure credential hygiene as part of access management training.

The CSP is responsible for defining, implementing, and evaluating processes and technical measures for the secure management of authentication credentials (including passwords, PINs, tokens, etc.). All related policies, standards, and procedures should be communicated to all users. Authentication credentials, when used, should be securely managed throughout their usable lifecycle and should follow good credential security practices, as mentioned below.

Implementation best practices for secure credentials management include (but are not limited to):

• a. Credential Strength Requirements: Password requirements should be enforced according to industry standards to enhance credentials’ strength and make them more resistant to brute-force attacks

• b. Credential Complexity: Credential complexity requirements should be implemented

  • i. Include a mix of uppercase and lowercase letters

  • ii. Use numbers and special characters

  • iii. Avoid easily guessable information, such as common words or patterns

• c. Minimum Credential Length: Minimum password length should be set to ensure passwords are not too short and easily compromised

• d. Credential History: A credential history policy should be enforced and record of previously used credentials should be kept to prevent users from reusing their previous credentials

• e. Credential Expiration: A credential expiration policy should be enforced and a process implemented to encourage frequent credential updates

• f. Credential Rotation: Users should be encouraged to regularly update their credentials, balanced with the need for strong, unique credentials to avoid predictable patterns

• g. Default Credentials Update: All vendor-supplied default configuration of credentials for identities and accounts should be removed and reset according the organizations credentials management policy

• h. Credentials Protection:

  • i. Strong secrets hashing algorithms should be used (e.g., PBKDF2 and bcrypt), and when necessary updated (secrets re-hashing), in accordance with the most current industry-standards

  • ii. A unique “salt” for each secret should be generated and combined with the secret before hashing to prevent attackers from using precomputed tables (rainbow tables) for attacks

  • iii. Secure secrets in storage and in transit (especially during the login process) using strong encryption i. Credentials Persistence: i. Credentials persistence should be disabled for client-side applications, preventing credentials from being stored locally on user devices ii. Saving credentials in web browsers or email applications should be avoided

• i. Account Lockout Mechanisms: Account lockout mechanisms should be implemented that temporarily restrict access after a certain number of failed authentication attempts

• j. Public Display Prevention: Applications should be configured by default to not display credentials in clear text on any screen (i.e., mask screen display of credentials). A “show password while typing” option should be made available to select

• k. Secrets Managers: Users should be provided with access to secrets managers or integrated secrets storage capabilities to help them generate and manage strong, unique credentials for different accounts

• l. Automated Credential Generation: Credentials that are automatically chosen should be generated with a cryptographically secure pseudorandom number generator (CSPRNG)

• m. Credentials Reset:

  • i. Use of Self-Service Password Reset (SSPR) mechanisms where users can independently reset their credentials

  • ii. Upon credential reset, users should adhere to the organization’s credential complexity requirements

  • iii. Accurate records of all credential reset activities should be maintained (e.g., user involved, date and time of the reset, and the reason for the reset)

  • iv. Use MFA or other additional verification steps (e.g., in-person/telephone confirmation) for credential resets on highly-privileged accounts (e.g., tenant root/admin)

• n. Credential Recovery: Secure mechanisms for credential recovery should be implemented (e.g., via email, time-limited recovery links)

• o. Credentials Management Monitoring: Monitoring tools should be leveraged to detect and alert on suspicious activities related to credential changes or login attempts

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.

Shared Implementation Guidelines

[All Actors]

1. Implement processes and controls to define, maintain and deploy permission set based on roles to systems and applications.

2. Implement processes and controls for request and approval of permissions to the resources owner.

3. Regularly review and certify authorization mechanisms settings and configuration (such as permission sets).

4. Implement alerting mechanisms through SIEM to flag when high-risk permission sets or roles have been changed.

Implementation Guidelines for Cloud Service Providers (CSP)

Role Specific: All access and permissions should be revoked outside the allowed (approved) session duration as per Zero Standing Privileges (ZSP).

[All Actors]

1. Implement processes and controls to define, maintain and deploy permission set based on roles to systems and applications.

2. Implement processes and controls for request and approval of permissions to the resources owner.

3. Regularly review and certify authorization mechanisms settings and configuration (such as permission sets).

4. Implement alerting mechanisms through SIEM to flag when high-risk permission sets or roles have been changed.

From CCM v4.1: Control Ownership Rationale. This control’s implementation responsibility is “Shared (Independent)” since CSP and CSC are both responsible, but also independently manage the processes and procedures to ensure formal approvals are obtained for access granted to users in their respective organizations. The CSP owns the control in relation to the entities whose access to the cloud environment it provides and maintains, including its internal users, external users (vendors and customers), applications, and services.

Implementation Guidelines. Applicable to all service models: Verifying access authorization is a fundamental component of effective access control, ensuring that users are granted access based on their legitimate needs and that unauthorized access attempts are promptly identified and prevented.

The CSPs play a critical role in implementing robust technical measures to verify authorization and prevent unauthorized access. Implementation best practices to defining, implementing, and evaluating these measures include (but are not limited to):

• a. Authorization Mechanisms:

  • i. Identities should be provided with only the access necessary to perform their job duties according to the PoLP

  • ii. Dynamic RBAC, ABAC and Context-aware access control mechanisms should be implemented to assign users specific roles with defined privileges and permissions as part of the access control decision-making process

  • iii. Explicit permissions (read, write, execute) should be assigned to users or groups on individual resources (e.g., files, databases, applications)

  • iv. A process to verify that access is authorized before granting permissions should be implemented

• b. Authorization Request and Approval:

  • i. Senior management should be informed of a new user request to access a resource, and with sufficient justification, review, approve, and document such request

  • ii. Ad-hoc access requests without approvals should not be granted, with exceptions in emergency situations (e.g., resolving a security incident or recovering from a major outage) where they should be approved by senior management

  • iii. Two levels of approvals should be required for granting privileged entitlements (i.e., approval of the user’s manager or supervisor and of the asset owner should be required)

  • iv. Detection mechanisms should be implemented to identify and report any access that is granted without formal approvals

• c. A list of persons who are authorized to approve access types and relevant requests should be documented and maintained vi. Access rights should be immediately revoked after the business justification for such access ceases to exist

• d. Authorization Monitoring and Reviews: Authorization mechanisms should be regularly reviewed and updated. Reviews should be conducted on records of identities activity, including access requests, successful and failed login attempts, and resource usage to ensure that only authorized identities have access

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.

Shared Implementation Guidelines

[All Actors]

1. Define the methods of data and information classification, Tools such as a matrix can be helpful.

2. Define and implement the method of assigning and tracking information ownership/stewardship.

3. Implement approval procedures for accessing that information (either permanent access to or time-limited access).

4. Implement data lineage tools to track the collection, transformation and use of data in MLops to better assign classification to models.

5. Regularly review permissions to data, and have data owners certify access configurations.

6. Ensure tools accessible to Agent-based AI systems are classified and tagged based on the sensitivity of data they have access to.

7. Implement access control mechanisms in agent-based AI systems to ensure access to information is derived from a users credential and limited to their roles need-to-know.

8. Implement principle of least privilege to avoid the violation of “need-to-know” principle.

Implementation Guidelines for Cloud Service Providers (CSP)

[CSP]

1. Implement process and procedures to classify assets and information in various cloud offerings such as virtual machines, containers, AI services (Vector Databases, GPU compute)

2. Implement approval workflows that have data owners and stewards approve access resources such as storage, provide approval workflow customization to AI Customers (Self-service or upon-request)

3. Implement granular access control policy and roles for accessing Cloud & AI infrastructure components based on role

4. Implement segmentation of resources, through controls like logical accounts and network segmentation to limit access to information. Allow AI & Cloud customers to segment resource into security contexts to meet organization needs

5. Provided tools and settings for AICs to manage information & asset classification such as tagging and grouping

6. Provide granular infrastructure permissions for AICs to customize to enforce need-to-know

7. Restrict CSP access to customer data and services to what is necessarily for day-to-day operations, implement approval and privilege escalation procedure for activities that require access to sensitive data and services.

[All Actors]

1. Define the methods of data and information classification, Tools such as a matrix can be helpful.

2. Define and implement the method of assigning and tracking information ownership/stewardship.

3. Implement approval procedures for accessing that information (either permanent access to or time-limited access).

4. Implement data lineage tools to track the collection, transformation and use of data in MLops to better assign classification to models.

5. Regularly review permissions to data, and have data owners certify access configurations.

6. Ensure tools accessible to Agent-based AI systems are classified and tagged based on the sensitivity of data they have access to.

7. Implement access control mechanisms in agent-based AI systems to ensure access to information is derived from a users credential and limited to their roles need-to-know.

8. Implement principle of least privilege to avoid the violation of “need-to-know” principle.

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.

Shared Implementation Guidelines

[All Actors]

1. Implement the procedures and workflow for modification of AI generated output, including approvals form authorized parties.

2. Define based of organization policy and agreements, which roles are allowed to authorization the modification of AI generated output.

3. Ensure all modification of AI generate output are logged and reviewed on a regular basis.

4. Implement SoD to ensure that individuals modifying AI output are separate for the individuals authorizing and the individuals reviewing changes.

[MP/OSP/AP]

1. Ensure that details regarding the modification of AI generated output and the circumstances in which it occurs are shared with AIC through policy and agreements.

2. Clearly label and notify users when the output has been modified, and when appropriate detail what the change is.

Implementation Guidelines for Cloud Service Providers (CSP)

[All Actors]

1. Implement the procedures and workflow for modification of AI generated output, including approvals from authorized parties.

2. Define based of organization policy and agreements, which roles are allowed to authorization the modification of AI generated output.

3. Ensure all modification of AI generate output are logged and reviewed on a regular basis.

4. Implement SoD to ensure that individuals modifying AI output are separate for the individuals authorizing and the individuals reviewing changes.

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.

Shared Implementation Guidelines

[All Actors]

1. Inventory Agent tools and categorize them based:

   • i. Risk of accessible resource and the operations it can perform on those resources

   • ii. Sensitivity and Criticality of resources

   • iii. Establish stakeholder and tool owners

2. Implement access control mechanism that authorize the agent-based system and/or authorize the user interacting with the agent-based system.

3. Implement policies and workflows to ensure users and not given access to information or privileged outside of the role requirements.

[OSP, AP]

1. Provide api and in-platform access control mechanism to restrict access to tools or the capabilities of tools based on the agent-based system and requesting user.

2. Provide methods of tagging resources and/or assigning classification and ownership.

Implementation Guidelines for Cloud Service Providers (CSP)

1. Define Policy Scope: Establish provider-specific policy scopes for restricting access in agent-based solutions. Ensure policies address limiting tools and plugins to those required for specific use cases, enforcing resource segregation (e.g., isolated environments), and adhering to least privilege principles across deployment and runtime.

2. Policy Governance Structure: Define roles for overseeing access restrictions in agent-based solutions, involving cross-functional teams (e.g., security architects, DevOps, compliance). Set approval workflows with senior management and security leads to ensure alignment with organizational access control policies.

3. Policy Documentation Requirements: Create structured documentation standards for access restriction policies, including procedures for defining necessary tools/plugins, implementing segregation (e.g., containerization), and enforcing least privilege (e.g., role-based access). Use templates to document access controls, segregation mechanisms, and compliance checks.

4. Policy Management Framework: Implement a review process for access restriction policies. Conduct reviews at least annually or after significant changes (e.g., new tools/plugins, updated use cases, identified privilege escalations). Align with standards like NIST 800-53 (AC-6 Least Privilege), OWASP Secure Configuration, and AI-specific frameworks like NIST AI RMF where applicable.

5. Communication and Training Standards: Define requirements for communicating access restriction policies: distribute formal documentation, mandate training for teams managing agent-based solutions (e.g., developers, operators), and run awareness campaigns on least privilege. Ensure accessibility via internal portals and comprehension across teams.

6. Quality Control Standards: Set policies for quality assurance in access restrictions, including requirements for automated access reviews (e.g., IAM audits), segregation testing (e.g., network isolation checks), and monitoring for over-privileged access (e.g., anomaly detection). Require audit logs for tool/plugin usage and access attempts.

7. Access restriction policies cover agent-based solutions running on CSP infrastructure (e.g., monitoring agents, deployment agents). Limit tools/plugins to those required for infrastructure tasks, enforce segregation via isolated VMs or containers, and apply least privilege to CSP-managed agents interacting with MPs, OSPs, or APs.

[All Actors]

1. Inventory Agent tools and categorize them based:

   • i. Risk of accessible resource and the operations it can perform on those resources

   • ii. Sensitivity and Criticality of resources

   • iii. Establish stakeholder and tool owners

2. Implement access control mechanism that authorize the agent-based system and/or authorize the user interacting with the agent-based system.

3. Implement policies and workflows to ensure users and not given access to information or privileged outside of the role requirements.

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.

Shared Implementation Guidelines

[All Actors]

1. Define Policy Scope: a) Establish clear policies covering interoperability (API communication, info processing) & portability (app dev, data exchange/usage/integrity/persistence). b) Define/Align with standards for data formats, APIs & protocols.

2. Policy Governance & Review: a) Prepare RACI matrix to define clear responsibilities among different stakeholders. b) Define annual review process (tech, standards, regulations, business needs).

3. Training & Awareness: a) Train personnel on policies/standards.

4. Standardization & Documentation: a) Define specific standards used. b) Provide tools/SDKs/procedures for standard interaction/data transfer. c) Maintain documentation on interfaces, schemas, protocols, procedures. d) Implement version control & communicate changes.

Implementation Guidelines for Cloud Service Providers (CSP)

[All Actors]

1. Define Policy Scope: a) Establish clear policies covering interoperability (API communication, info processing) & portability (app dev, data exchange/usage/integrity/persistence). b) Define/Align with standards for data formats, APIs & protocols.

2. Policy Governance & Review: a) Prepare RACI matrix to define clear responsibilities among different stakeholders. b) Define annual review process (tech, standards, regulations, business needs).

3. Training & Awareness: a) Train personnel on policies/standards.

4. Standardization & Documentation: a) Define specific standards used. b) Provide tools/SDKs/procedures for standard interaction/data transfer. c) Maintain documentation on interfaces, schemas, protocols, procedures. d) Implement version control & communicate changes.

From CCM v4.1: Control Ownership Rationale. The CSP is responsible for policy, standards, guidelines and procedures, and transparency in communicating information related to interoperability and portability of data and associated metadata and code.

Implementation Guidelines. Applicable to all service models: Systems interoperability is the primary concern of the CSC. The degree to which a CSP offers a service based on technology that is published or standardized typically will increase the interoperability across cloud systems. Interoperability and portability controls aim to prepare the CSC to protect their business from failure in case of a CSP outage. This can include plans for interoperability and portability with other CSPs or a different region with the current provider.

IaaS Provider: The CSP should provide standardized hardware and computing resources that can interact with various disparate systems, with minimal effort, and which should strictly adhere to industry standards to maintain interoperability. The CSP should be able to support complex scenarios such as cloud brokerage, cloud bursting, hybrid clouds, multi-cloud federation, etc.

The CSP is responsible for implementing policies, processes, procedures and standards that enable the CSC in deploying architecture that can involve multiple CSPs, hybrid models, or moving to another CSP or private cloud. The policies, processes and procedures should remain current, be reviewed annually, be audited annually, and independent audit reports should be made available to the CSC.

PaaS Provider: The CSP is responsible for providing a platform on which the CSC can build its systems. The CSP provides a runtime environment and an integrated application stack. It allows developers to quickly develop and deploy custom applications on the offered platforms without the need to build the infrastructure. The CSP provides the entire infrastructure and its maintenance to its consumers.

The CSP is responsible for implementing policies, processes, procedures, and standards that support the CSC in developing and deploying applications that can be transferred to another CSP or private cloud. The policies, processes, and procedures should remain current, be reviewed annually, be audited annually, and independent audit reports should be made available to the CSC.

SaaS Provider: The CSP provides application capabilities over the cloud, and the CSC manages its administration and the information flowing in and out of the system. The end customer needs a browser and the majority of the administration at all the levels rests with the provider.

The CSP is responsible for implementing policies, processes, procedures, and standards that support the CSC in retaining data and metadata in line with their data retention standards, and recovering all data and metadata when the service ceases or when moving to another CSP or private cloud. The policies, processes, and procedures should remain current, be reviewed annually, be audited annually, and independent audit reports should be made available to CSCs.

Policies should include (but not limited to) provisions on the following:

• a. Standardized Communication Protocols: Ensure seamless interaction between different application interfaces by mandating the use of widely accepted communication protocols (e.g., RESTful APIs, JSON, XML).

  • i. Adopt industry-standard API protocols, such as RESTful APIs or SOAP APIs.

  • ii. Document API specifications clearly and provide SDKs (software development kits) for developers.

  • iii. Implement API gateways to manage and secure API traffic providing API documentation, including usage guidelines, example requests, and responses

  • iv. Implement versioning to manage changes and maintain backward compatibility.

• b. Secure Communication: Ensure that data exchanged between application interfaces is secure and protected from unauthorized access by implementing transport layer security (TLS/SSL) and enforcing authentication and authorization mechanisms.

• c. Standardized Data Formats: Ensure consistent data processing across diverse systems by defining and adhering to standardized data formats to facilitate interoperability between applications and data processing systems.

  • i. Utilize standardized data formats, such as XML, JSON, or CSV, for data representation.

  • ii. Implement data transformation and normalization techniques to ensure data consistency.

  • iii. Adopt common data models and data exchange protocols to facilitate interoperable data processing

• d. Cross-Platform Compatibility: Support information processing across different platforms and environments by designing applications and processing workflows to be platform-agnostic. Use containerization technologies (e.g., Docker) to encapsulate applications.

  • i. Utilize cloud-neutral development frameworks and tools, such as serverless computing platforms or containerization technologies.

  • ii. Employ cloud-agnostic programming languages and libraries.

  • iii. Adopt standardized deployment processes and configuration management tools for cloud platforms.

• e. Common Data Processing Standards: Ensure that information processing adheres to industry-accepted standards by implementing processing logic based on well-established standards (e.g., SQL for databases, Apache Spark for big data processing).

• f. Cross-Platform Development Tools: Enable developers to create applications that can run on different platforms without significant modification by providing development tools and frameworks that support cross-platform development.

• g. Containerization Support: Simplify the deployment and execution of applications across various environments by supporting containerization technologies (e.g., Kubernetes) to encapsulate applications, making them portable and independent of underlying infrastructure.

• h. Infrastructure As Code (IaC) Practices: Standardize the description and provisioning of infrastructure to ensure consistency across environments by encouraging the use of IaC tools (e.g., Terraform, Ansible) to define and manage infrastructure configurations in a portable manner.

• i. Standardized Data Exchange Formats: Facilitate consistent and unambiguous data exchange between systems by defining and adhering to standardized data exchange formats and structures, ensuring compatibility and reducing data transformation complexities.

• j. Data Integrity and Persistence: Ensure the reliability and integrity of data across different systems and storage environments by implementing data integrity checks, using reliable storage systems, and establishing backup and recovery mechanisms to maintain data persistence.

  • i. Utilize data integrity validation mechanisms to ensure data accuracy during transfers.

  • ii. Employ data masking techniques to protect sensitive data in logs and screenshots.

• k. Common Data Usage Policies: Standardize how data is accessed, utilized, and shared across different applications by defining and enforcing data usage policies, access controls, and permissions to maintain consistency and security.

• l. Data Portability Contractual Obligations:

  • i. Define and document standardized formats for data exchange to facilitate portability

  • ii. The data retention period should specify the length of time data will be stored, taking into account legal and regulatory requirements. Implement automated processes for data retention and deletion.

  • iii. The scope of data retained should be defined and made available to the CSCs

  • iv. A comprehensive data deletion policy for retained data should be defined to include secure deletion methods (refer to DCS-01 and DSP-02)

• m. Contract Termination: Upon contract termination, CSPs should provide reasonable assistance to CSCs in exporting and transferring their data to another cloud environment or on-premises systems. This assistance may include providing technical documentation, data export tools, and necessary support to facilitate seamless data migration.

  • i. Outline CSCs’ access to data upon contract termination in the contractual agreement

  • ii. Implement secure methods for data handover or transfer to CSCs

  • iii. Develop and document an exit plan that ensures a smooth transition of services and data to CSCs

  • iv. Include security measures to protect data during the transition period

• n. Clearly define data ownership and transfer of ownership upon contract termination vi. Include legal and technical mechanisms to ensure data confidentiality and integrity

• o. Approval: Approval requirements and senior management involvement to ensure alignment with the organization’s strategic goals and risk appetite

  • i. An approval process should be established for any changes or modifications to the policy and procedures

  • ii. A documented record of approvals (including dates, names of approvers, and any relevant comments or discussions) should be maintained

• p. Communication: Effective communication of the policy and procedures should be facilitated to all relevant cloud stakeholders

• q. Maintenance and Reviews: Interoperability and portability policies and procedures should be documented, reviewed and updated at least annually to ensure alignment with evolving cloud security landscape and to reflect changes in cloud technology, regulations, and risks

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.

Shared Implementation Guidelines

[All Actors]

1. API Design & Provision: a) Develop/maintain robust, documented APIs for AI service customer (AIC) data retrieval. b) Ensure APIs cover relevant AI service customer data scopes. c) Follow API design best practices. d) Follow applicable industry standards for interoperability.

2. Security & Access Control: a) Implement secure authentication/authorization for AI service customer specific data access. b) Ensure data segregation.

3. Performance & Reliability: a) Design for performance/scalability. b) Monitor availability/latency/errors. c) Implement rate limiting.

4. Documentation & Support: a) Provide comprehensive, current API documentation. b) Offer support channels. c) Communicate API changes/versioning proactively.

Implementation Guidelines for Cloud Service Providers (CSP)

[All Actors]

1. API Design & Provision: a) Develop/maintain robust, documented APIs for AI service customer (AIC) data retrieval. b) Ensure APIs cover relevant AI service customer (AIC) data scopes. c) Follow API design best practices. d) Follow applicable industry standards for interoperability.

2. Security & Access Control: a) Implement secure authentication/authorization for AI service customer specific data access. b) Ensure data segregation.

3. Performance & Reliability: a) Design for performance/scalability. b) Monitor availability/latency/errors. c) Implement rate limiting.

4. Documentation & Support: a) Provide comprehensive, current API documentation. b) Offer support channels. c) Communicate API changes/versioning proactively.

From CCM v4.1: Control Ownership Rationale. The CSP is responsible for providing the CSC with secure APIs that utilize universally recognized and standardized guidelines and protocols that are tested for security, availability, and usability. The CSP should make documentation available to the CSC.

Implementation Guidelines. Applicable to all service models: The CSP should ensure that its APIs are interoperable and facilitate the secure migration of applications and data between environments.

The APIs should be secure by design and in accordance with standardized guidelines and protocols universally recognized to enable the CSC to use for distributed cloud deployments, and to remove data securely from the environment.

The CSP should provide the CSC with accurate documentation and communicate planned changes and updates. Documentation should support API functionality, be updated regularly, and given to customers with new API versions. Furthermore, security issues should be considered during development and updates.

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.

Shared Implementation Guidelines

[All Actors]

1. Protocol Enforcement: a) Mandate current, strong, secure protocols (TLS 1.2+, HTTPS, SFTP, SSH) for all data management/import/export interfaces. b) Disable insecure protocols.

2. Cryptographic Methods: a) Use strong encryption/key lengths for data in transit. b) Implement robust key management. c) Regularly update crypto suites.

3. Data Integrity: a) Implement mechanisms to verify data integrity during transfer (e.g., checksums).

4. Secure Tooling & Endpoints: a) Ensure provided tools/SDKs/endpoints use secure protocols. b) Secure management interfaces (web consoles, APIs) with HTTPS/strong authentication.

Implementation Guidelines for Cloud Service Providers (CSP)

[All Actors]

1. Protocol Enforcement: a) Mandate current, strong, secure protocols (TLS 1.2+, HTTPS, SFTP, SSH) for all data management/import/export interfaces. b) Disable insecure protocols.

2. Cryptographic Methods: a) Use strong encryption/key lengths for data in transit. b) Implement robust key management. c) Regularly update crypto suites.

3. Data Integrity: a) Implement mechanisms to verify data integrity during transfer (e.g., checksums).

4. Secure Tooling & Endpoints: a) Ensure provided tools/SDKs/endpoints use secure protocols. b) Secure management interfaces (web consoles, APIs) with HTTPS/strong authentication.

From CCM v4.1: Control Ownership Rationale. The CSP is responsible for encrypting communications using industry-standard protocols and encryption algorithms. The CSP should make design and configuration documentation available to the CSC.

Implementation Guidelines. Applicable to all service models: The CSP is responsible for the secure configuration, monitoring, certificate renewal, and key management for all APIs within their control. The CSP should comply with applicable regulatory mandates.

The CSP should provide the CSC with accurate documentation, communicate planned changes and updates, and make independent security audit results available. When vulnerabilities are detected, the CSP should alert the CSC of the issue, provide status updates, and mitigation provide advice as applicable.

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

Shared Implementation Guidelines

[All Actors]

1. Standard Contractual Clauses: a) Develop clear clauses detailing data portability rights upon termination. b) Specify machine-readable data format(s). c) State data retention duration post-termination for retrieval. d) Define precise scope of retrievable data. e) Detail data deletion policy (timeline, method, confirmation).

2. Internal Procedures: a) Establish documented procedures for data extraction, formatting, secure delivery per contract. b) Implement verifiable data deletion procedures (e.g., NIST SP 800-88 compliant), c) Ensure secure credential revocation and access termination upon contract exit.

3. Compliance & Audit: a) Maintain records demonstrating compliance with portability requirements, retention, and deletion requirements. b) Ensure relevant teams are aware of terms/procedures.

Implementation Guidelines for Cloud Service Providers (CSP)

[All Actors]

1. Standard Contractual Clauses: a) Develop clear clauses detailing data portability rights upon termination. b) Specify machine-readable data format(s). c) State data retention duration post-termination for retrieval. d) Define precise scope of retrievable data. e) Detail data deletion policy (timeline, method, confirmation).

2. Internal Procedures: a) Establish documented procedures for data extraction, formatting, secure delivery per contract. b) Implement verifiable data deletion procedures (e.g., NIST SP 800-88 compliant), c) Ensure secure credential revocation and access termination upon contract exit.

3. Compliance & Audit: a) Maintain records demonstrating compliance with portability requirements, retention, and deletion requirements. b) Ensure relevant teams are aware of terms/procedures.

From the CCM v4.1: Control Ownership Rationale. The CSP should provide information relating to data lifecycle management, including but not limited to, data formats, data retention, data archival, and data deletion during the service agreement, and when the CSC exits the Cloud service. The CSP will provide information to assist the CSC in data and metadata recovery, along with how and when the CSP will delete the CSC’s data. Control implementation responsibility is determined to be both” Shared” and “Dependent” since In context of service level agreements both parties need to determine and agree on provisions with regards to data portability upon contract termination.

Implementation Guidelines. Applicable to all service models: The CSP should document the data and metadata formats and retention timelines when the CSC enters and exits the service. Transient data or data not retained should be declared.

The CSP should publish and maintain detailed instructions to assist the CSP in securely removing data and metadata from the environment when exiting the service.

Independent audits should cover processes supporting customer exit, and reports made available to the CSC.

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.

Shared Implementation Guidelines

[All Actors]

1. Define Policy Scope: Establish clear security policies covering infrastructure components (servers, hypervisors, virtualization layers, cloud-native infrastructure). Align with regulatory and security standards (ISO 42001, NIST 600-1, CIS Benchmarks, CSA AICM).

2. Policy Governance and Review: Assign clear ownership for policy governance. Define an annual review process incorporating changes in technology, regulatory updates, and risk landscape.

3. Training and Awareness: Develop training programs to ensure personnel understand infrastructure security policies. Conduct periodic audits to verify adherence.

Implementation Guidelines for Cloud Service Providers (CSP)

[All Actors]

1. Define Policy Scope: Establish clear security policies covering infrastructure components (servers, hypervisors, virtualization layers, cloud-native infrastructure). Align with regulatory and security standards (ISO 42001, NIST 600-1, CIS Benchmarks, CSA AICM).

2. Policy Governance and Review: Assign clear ownership for policy governance. Define an annual review process incorporating changes in technology, regulatory updates, and risk landscape.

3. Training and Awareness: Develop training programs to ensure personnel understand infrastructure security policies. Conduct periodic audits to verify adherence.

From CCM: Control Ownership Rationale. The responsibility for this control differs depending upon chosen cloud architecture. For IaaS this is a “Shared (Dependent)” responsibility. While the CSP provides tooling to support the VM lifecycle and policies and procedures around the infrastructure, and policies and procedures around the VMs, the governance and enforcement of such belong to the CSC. For PaaS and SaaS, the CSC is abstracted from the VM layer by consuming either a platform or an application, and all policies and procedures are a CSP-owned responsibility.

Implementation Guidelines. IaaS Provider: The CSP is responsible for creating policies and procedures around the infrastructure, virtual machines, and cloud orchestration tools that they use to deliver the service. However, it is not responsible for creating policies and procedures governing the VM instances that the CSC brings into or builds within the IaaS environment. The CSP may choose to share example policies and procedures with the CSC, or offer services to help the CSC build these policies and procedures. The CSP should provide capabilities and/or technology to enable the CSC to apply the policies and procedures – for example the ability to create network security controls to separate individual VM instances from one another – but it’s up to the CSC to create the policies and procedures to use these capabilities.

PaaS Provider: The CSP is responsible for implementing and governing the policies and procedures relating to virtualization security. The CSC is not expected to interface with the VMs in a PaaS environment in any way other than consuming the development environment which runs on top of the VMs. Therefore, the CSP should build a policy management and enforcement framework to govern the VM lifecycle, storage, and network security of the VM environment. The policies and procedures should be reviewed at least annually, and the approach (but not necessarily the specific policy/procedure detail) may be shared with the customer via the CSP’s website, the CAIQ, and/or as part of an independent auditor’s report.

SaaS Provider: The CSP is responsible for implementing and governing the policies and procedures relating to virtualization security. The CSC does not interface with the VMs in a SaaS environment as they are simply consuming an application. Therefore, the CSP should build a policy management and enforcement framework to govern the VM lifecycle, storage, and network security of the VM environment running below the SaaS application. The policies and procedures should be reviewed at least annually, and the approach (but not necessarily the specific policy/procedure detail) may be shared with the customer via the CSP’s website, the CAIQ, and/or as part of an independent auditor’s report.

Policies should include (but not limited to) provisions on the following:

• a. Scope and Objectives:

  • i. The scope of the infrastructure and virtualization security policies and to ensure that the policies apply to all relevant components within the cloud environment, including networks, operating systems, and virtual machines

  • ii. The security objectives should be well articulated and aligned with industry standards and regulatory requirements applicable to the CSP

• b. Capacity and Resource Planning: Capacity planning requirements and assessments planned to ensure that resources are efficiently allocated, and scalability requirements are met

• c. Network Security: Network security baselines that define acceptable physical and virtual network configurations for network devices, applications, and operating systems. Guidelines for network segmentation, access control, and traffic management should be also defined and regularly reviewed

• d. OS Hardening and Base Controls: Security baseline configurations for all guest/host operating systems (OS), hypervisors, VMs (with VM lifecycle management), including standardized hardening configurations and procedures to apply the latest security patches and updates

• e. Production and Non-Production Environments: Requirements for the separation of production and non-production environments, including relevant access restrictions that are tailored to the specific risks and requirements of each environment

• f. Segmentation and Segregation:

  • i. Network physical and/or logical segmentation and segregation requirements to isolate different customer environments (CSP, CSC and intra-tenant) and prevent unauthorized access between them

  • ii. Intra-tenant access requirements should be defined and access restricted to authorized users and each tenant’s resources and data

• g. Migration to Cloud Environments: Requirements for the establishment of secure channels for data migration to cloud environments using encryption based on secure protocols

• h. Network Architecture Documentation:

  • i. An up-to-date documentation of the cloud network architecture including details on network topology, device configurations, data flows and security controls

  • ii. Documentation that should be regularly reviewed and updated to reflect changes in the network environment i. Network Defense: i. A layered defense strategy to protect the cloud infrastructure from various attack vectors ii. An up-to-date threat intelligence feed and regular vulnerability assessments and penetration testing conducted to identify and remediate network security weaknesses

• i. Infrastructure and Virtualization Security Metrics: Monitoring metrics and key performance indicators (KPIs) related to infrastructure and virtualization security should be defined, such as resource utilization, network traffic patterns, and security alerts

• j. Approval: Approval requirements and senior management involvement to ensure alignment with the organization’s strategic goals and risk appetite

  • i. An approval process should be established for any changes or modifications to the policy and procedures

  • ii. A documented record of approvals (including dates, names of approvers, and any relevant comments or discussions) should be maintained

• k. Communication: Effective communication of the policy and procedures should be facilitated to all relevant cloud stakeholders

• l. Maintenance and Reviews: Infrastructure and virtualization security policies and procedures should be documented, reviewed and updated at least annually to ensure alignment with evolving cloud security landscape and to reflect changes in cloud technology, regulations, and risks

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.

Shared Implementation Guidelines

[All Actors]

1. Define Resource Planning Framework.

2. Establish a structured approach for monitoring and managing infrastructure capacity.

3. Align with best practices (ISO 27001, NIST SP 800-53, ITIL Capacity Management).

4. Capacity Forecasting and Performance Monitoring.

5. Implement predictive analytics to anticipate resource needs.

6. Define KPIs for utilization and performance benchmarks.

7. Scalability and Resiliency Planning.

8. Define strategies for scaling resources based on workload demands.

9. Implement automated scaling policies for cloud and virtualized environments.

10. Incident Response and Contingency Planning.

11. Define procedures for handling resource exhaustion and unexpected demand surges.

Implementation Guidelines for Cloud Service Providers (CSP)

[All Actors]

1. Define Resource Planning Framework.

2. Establish a structured approach for monitoring and managing infrastructure capacity.

3. Align with best practices (ISO 27001, NIST SP 800-53, ITIL Capacity Management).

4. Capacity Forecasting and Performance Monitoring.

5. Implement predictive analytics to anticipate resource needs.

6. Define KPIs for utilization and performance benchmarks.

7. Scalability and Resiliency Planning.

8. Define strategies for scaling resources based on workload demands.

9. Implement automated scaling policies for cloud and virtualized environments.

10. Incident Response and Contingency Planning.

11. Define procedures for handling resource exhaustion and unexpected demand surges.

From CCM: Control Ownership Rationale. The responsibility for this control is the same across all cloud architectures, and is a CSP-owned responsibility. While a CSC may demand a particular service or resource capacity, it is the responsibility of the CSP to ensure that the required system performance is delivered according to these requirements. This applies equally whether the service being delivered is IaaS, PaaS, or SaaS.

Implementation Guidelines. Applicable to all service models: The CSP should develop and maintain a resource planning framework to assess the usage of the infrastructure, platform, or application that is being delivered to the CSC. The framework should be reviewed regularly and be used by the planning, engineering, and infrastructure teams to determine if the required growth of the service meets the CSC demands. The CSP should also maintain an internal operational level agreement (OLA) and SLA with the CSC, which may include service penalties for situations where the CSP is unable to deliver capacity and availability.

Metrics should be leveraged and monitored to establish a resources capacity planning model along with the SLAs that have been determined with the internal teams, and the SLAs that are being promised to the CSC. A regular review cycle should be adopted to ensure that the planning team is able to react swiftly to required resources capacity changes.

Implementation best practices for the CSP include (but are not limited to):

• a. Resource Planning Framework:

  • i. The business objectives, user expectations, and performance requirements should be understood for the various cloud services

  • ii. Strategies should be developed for allocating resources across different cloud services, considering factors like cost optimization, performance optimization, and scalability needs

  • iii. Historical usage patterns, future growth projections, and peak demand scenarios should be analyzed to determine the appropriate resource capacity for each service

  • iv. Annual reviews of resource utilization trends and projections should be performed to identify potential bottlenecks and optimize infrastructure

• b. Resource Monitoring and Alerting Systems:

  • i. Resource utilization metrics like CPU, memory, storage, and network bandwidth should be continuously tracked to identify potential bottlenecks or resource constraints

  • ii. Unusual VM creation times, resource spikes, or sudden changes in allocated resources should be monitored to detect unauthorized activity or resource-intensive attacks

  • iii. Baseline performance levels should be determined for each critical metric to identify deviations and potential issues proactively

  • iv. Automated alerts should be configured to notify the relevant teams when resource utilization exceeds thresholds or performance degrades significantly

• c. Autoscaling and Resource Optimization Techniques:

  • i. Resource optimization techniques like load balancing, virtual machine consolidation, and instance termination should be employed to maximize resource utilization and minimize idle resources

  • ii. Autoscaling features should be utilized to automatically adjust resource capacity in real-time based on demand fluctuations, ensuring optimal performance and cost efficiency

• d. Continuous Monitoring and Evaluation:

  • i. Monitoring data should be analyzed to identify trends, anomalies, and areas for improvement in resource planning and optimization

  • ii. Resource plans and strategies should be adapted in response to changing business requirements, technological advancements, and market fluctuations

  • iii. Periodic reviews of resource plans should be conducted to ensure they align with evolving business needs, usage and capacity patterns, and overall performance requirements

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.

Shared Implementation Guidelines

[All Actors]

1. Define Network Security Framework.

2. Implement network segmentation, firewall controls, and encryption protocols.

3. Align security configurations with relevant standards (e.g. ISO 27001, NIST 800-53, etc.), and CIS benchmarks.

4. Authentication and Access Controls.

5. Enforce multi-factor authentication for all network access points.

6. Implement zero-trust principles for internal and external communications.

7. Encryption and Secure Communications.

8. Enforce encryption for data-in-transit using strong cryptographic controls (e.g., TLS 1.2 or later, IPsec, or equivalent mechanisms).

9. Implement certificate management and key rotation policies.

10. Review these configurations at least annually, and support them by a documented justification of all allowed services, protocols, ports, and compensating controls.

Implementation Guidelines for Cloud Service Providers (CSP)

[All Actors]

1. Define Network Security Framework.

2. Implement network segmentation, firewall controls, and encryption protocols.

3. Align security configurations with relevant standards (e.g. ISO 27001, NIST 800-53, etc.), and CIS benchmarks.

4. Authentication and Access Controls.

5. Enforce multi-factor authentication for all network access points.

6. Implement zero-trust principles for internal and external communications.

7. Encryption and Secure Communications.

8. Enforce encryption for data-in-transit using strong cryptographic controls (e.g., TLS 1.2 or later, IPsec, or equivalent mechanisms).

9. Implement certificate management and key rotation policies.

10. Review these configurations at least annually, and support them by a documented justification of all allowed services, protocols, ports, and compensating controls.

From CCM v4.1: Control Ownership Rationale. The CSP owns the control with respect to the system identities accessing resources under the CSP’s control in the cloud environment. The scope of such resources is dependent on the type of cloud service model the CSP offers as detailed below.

Implementation Guidelines. Iaas Provider: The CSP is responsible for maintaining and reviewing the inventory of system identities having access to resources in the cloud environment, including: physical datacenter infrastructure for power, cooling, and networking; hardware for computing, storage, and networking; hypervisors and other virtualization assets. System identities to be documented should include users, services, applications, roles, and groups having access to each asset and the types of access granted them.

PaaS Provider: The CSP is responsible for maintaining and reviewing the inventory of system identities having access to: physical datacenter infrastructure for power, cooling, and networking; hardware for computing, storage, and networking; hypervisors and other virtualization resources; virtual machine images and instances; operating systems, middleware, databases, and management tools. System identities to be documented should include users, services, applications, roles, and groups having access to each asset and the types of access granted them.

SaaS Provider: The CSP is responsible for maintaining and reviewing the inventory of system identities having access to: physical datacenter infrastructure for power, cooling, and networking; hardware for computing, storage, and networking; hypervisors and other virtualization resources; virtual machine images and instances; operating systems, middleware, databases, and management tools; applications and their data storage. System identities to be documented should include users, services, applications, roles, and groups having access to each asset and the types of access granted them.

Applicable to all service models:

• a. Implementation guidelines to establish and maintain an identity inventory include (but are not limited to):

• b. Identity Management System (IDaaS): A centralized IDaaS platform should be implemented that consolidates identities data from various cloud applications and services. The platform should provide visibility into all identities and their access privileges (e.g., Least Privilege, SoDs, ACLs)

• c. Identity Classification: Identities should be categorized and classified based on their roles, purpose, and sensitivity and in correlation of the resources they access (i.e., assign appropriate access permissions and implement stricter controls for critical identities)

• d. Identity Discovery and Inventory: Automated tools should be utilized to continuously scan the cloud environment and identify all existing identities

• e. Threat Intelligence Integration: Leverage threat intelligence sources to identify and prioritize potential identity-based threats to proactively address emerging risks

• f. Inventory Access: Identity information should be stored in a secure location and access restricted to authorized personnel

• g. System Identity Ownership: Each system and service account should be assigned a designated owner to maintain accountability, facilitate future management, and mitigate security risks associated with unmanaged accounts

• h. Inventory Reviews and Updates:

  • i. The inventory should be up-to-date to ensure accuracy and completeness and reflect the current state of identities and their level of access, identify any discrepancies or anomalies and to ensure access is revoked or changed as necessary

  • ii. Reviews should be conducted on a periodic basis or upon changes to identities and their level of access, and according to the CSP’s risk assessment and other compliance requirements

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.

Shared Implementation Guidelines

[All Actors]

1. Establish OS Hardening Standards.

2. Apply CIS benchmarks and vendor security guidelines for host and guest OS.

3. Implement least privilege principles and disable unnecessary services.

4. Hypervisor and Control Plane Security.

5. Secure hypervisor configurations and implement logging for hypervisor activity.

6. Enforce hypervisor patching and vulnerability management policies.

7. Automation and Compliance Monitoring.

8. Deploy automated scripts to enforce security baselines.

9. Continuously monitor compliance with configuration management tools.

Implementation Guidelines for Cloud Service Providers (CSP)

[All Actors]

1. Establish OS Hardening Standards.

2. Apply CIS benchmarks and vendor security guidelines for host and guest OS.

3. Implement least privilege principles and disable unnecessary services.

4. Hypervisor and Control Plane Security.

5. Secure hypervisor configurations and implement logging for hypervisor activity.

6. Enforce hypervisor patching and vulnerability management policies.

7. Automation and Compliance Monitoring.

8. Deploy automated scripts to enforce security baselines.

9. Continuously monitor compliance with configuration management tools.

From CCM v4.1: Control Ownership Rationale. This control’s implementation responsibility varies between the CSP and CSC across the three cloud service models. With regards to IaaS, there is a Shared and independent implementation responsibility between CSP and CSC for the Host and Guest OS hardening, since the CSP is responsible for the Host’s hardening (OS and/or Hypervisor), and the CSC is responsible for the Guest VM and OS hardening. For PaaS and SaaS the implementation responsibility shifts to the CSP only, since the hardening of OS, hypervisor and underlying infrastructure are not part of CSC’s cloud stack and therefore the CSC has no control over their secure implementation.

Implementation Guidelines. IaaS Provider: The CSP is responsible for provisioning hardware to support customer virtual machines that includes: hardening and maintaining updates to hypervisors, Host operating system, firmware, and utilizing confidential computing including trustworthiness assessment rooted in hardware, as well as Trusted Execution Environments,Trusted Platform Modules (TPM) and other trusted and assured equipment, obtained through a verified and reputable supplier. The CSP is not responsible for the updates to operating systems installed above the host infrastructure.

PaaS Provider: The CSP is responsible for all system hardening host and guest OS patching across the infrastructure plane and it should do this as per the client’s requirements or as defined by good practice, but is not responsible for application level patching.

SaaS Provider: The CSP is responsible for all elements of system patches, including application level requirements.

Where the CSP is responsible for the updates to host (hypervisor)/guest and other system patching, it should deploy suitable testing methods before rolling out updates. Updates should be deployed in a suitable time frame depending on contractual agreements.

Implementation best practices for cloud platforms hardening include (but are not limited to):

• a. Host/Guest OS, Hypervisor, VMs, Control Plane Hardening:

  • i. A secure configuration baseline using industry vendors and benchmarks should be created and utilized to ensure consistency across all platforms

  • ii. A minimal installation should be utilized and implemented, using pre-configured secure templates according to the baseline and having only essential system services/processes enabled (i.e., unnecessary ports, protocols, and network services should be disabled or removed to reduce the attack surface)

  • iii. Software (OSes, Hypervisor, VMs and applications) should be kept up-to-date with the latest security patches

  • iv. Strong authentication (e.g., complex passwords, MFA) should be configured for accessing the hypervisor/VM/OS management interfaces

• b. Security features such as firewalls, anti-malware, and system logging should be enabled vi. Configurations should be regularly reviewed and updated against the configuration baseline to ensure only necessary features are enabled vii. For sensitive CSC workloads:

  • A dedicated, single-tenant or bare-metal hypervisor instances should be used to avoid the exploitation of possible hypervisor vulnerabilities

  • Conventional virtual machines (VMs) should be replaced with confidential VMs for enhanced security

  • Secure boot and virtual Trusted Platform Module (vTPM) should be utilized for enhanced security

  • Hypervisors/OSes/VMs that have been rigorously tested for security should be selected (i.e., evaluated against Common Criteria (CC) Protection Profiles (PP) and assigned an Evaluation Assurance Level (EAL))

VM Lifecycle-Specific Implementation Guidelines.

• a. Creation

  • i. Secure VM templates should be used that are pre-configured with security settings, including hardened OS configurations, patching schedules, and access controls

  • ii. VM images should be scanned for vulnerabilities before provisioning them to CSCs

  • iii. Unnecessary applications, services, and drivers should be removed from VM images to reduce the attack surface

  • iv. A detailed inventory of all VMs should be maintained to track their creation, deployment, and status

• b. Compliance checks should be implemented to ensure VMs meet security and regulatory requirements

• c. Deployment

  • i. Provisioning controls should be implemented to prevent unauthorized deployment of VMs

  • ii. Network segmentation should be used to isolate VMs from each other and the rest of the network.

  • iii. Access controls should be implemented to restrict identities access to VMs based on the cloud IAM access control policy

  • iv. Monitoring and alerting systems should be implemented and configured to detect suspicious activity and potential security breaches

• d. Change management process should be implemented to control and track changes made to VMs (refer to CCC domain)

• e. Operation

  • i. Security patches and updates should be regularly applied to VMs to address vulnerabilities and prevent known exploits

  • ii. Vulnerability scans should be regularly conducted to identify and remediate security weaknesses

  • iii. Configuration management tools should be used to enforce consistent and secure configurations for VMs

  • iv. VMs should be continuously monitored for resource usage, security events, and potential anomalies

• f. Logging and auditing of VM activity should be enabled to track changes and events.

• g. Maintenance

  • i. Backup and recovery strategies should be implemented to protect VM data from loss or corruption

  • ii. Maintenance tasks on VMs should adhere to the change management process

  • iii. Any changes made to VMs should be tested and validated before deploying them to production

  • iv. Documentation of VM configurations, maintenance procedures, and security policies should be maintained

• h. Decommissioning

  • i. VM disks should be encrypted before decommissioning to protect sensitive data from unauthorized access

  • ii. VM disks should be securely destroyed or erased to prevent data recovery

  • iii. Decommissioned VMs should be removed from the inventory and tracking systems and the decommissioning process documented to ensure proper authorization

  • iv. Audit trails should be maintained to record the decommissioning activity and data destruction procedures

Container-Specific Implementation Guidelines. Technical controls should aid situations when only the ports, protocols, and services necessary to meet business needs are provided. Such controls should be based on common benchmarks.

The CSP should implement anti-malware, file integrity monitoring, and logging, and utilize hardware rooted trust in confidential computing (CC) and virtual trusted platform modules (vTPMs).

Whenever possible, organizations should use minimalistic, container-specific host operating systems with all other services and functionality disabled, and with read-only file systems and other hardening practices employed to reduce attack surfaces.

The following best practices for securing containers are also recommended:

• a. Dedicated Container Host: hosts that run containers should only run containers and not other apps—such as web servers or databases—outside of containers

• b. Container Host Patch Management: Hosts that run containers should be continuously scanned for vulnerabilities and updated promptly

• c. Hardened Container Host: The host OS should not run unnecessary system services

• d. Container Host Access: Access to the container host should be based on the need-to-know and least privilege principles

• e. Container Security Monitoring: file integrity monitoring and host intrusion detection should be leveraged for containers.

• f. CC Protection: Where applicable, hosts should be measured by confidential computing hardware and attested to verify trust. This enables verification that the platform on which the host depends including firmware, boot code from the CPU silicon up is measured and attested even before the OS runs.

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.

Shared Implementation Guidelines

[All Actors]

1. Environment Segmentation: Establish strict separation of production and non-production networks. Implement access controls to restrict movement between environments.

2. Data Segregation and sanitization (e.g., masking, tokenization, anonymization, or other appropriate methods, according to NIST SP 800-88 Guidelines for media sanitization): Prohibit use of production data in non-production environments unless properly sanitized.

3. Enforce encryption for sensitive data used in lower environments.

4. Access Control and Least Privilege: Implement role-based access control (RBAC) for environment-specific access. Enforce approval processes for data migration across environments.

5. Access policies should include on-demand approval. All access and permissions should be revoked outside the allowed (approved) session duration with Zero Standing Privileges (ZSP).

[Shared between the MP, AP, OSP and CSP]

1. Define strict boundaries between AI model training, testing, and production environments.

2. Enforce segmentation policies to prevent cross-environment data leakage.

3. Implement monitoring tools to detect unauthorized movements between environments.

Implementation Guidelines for Cloud Service Providers (CSP)

[All Actors]

1. Environment Segmentation: Establish strict separation of production and non-production networks. Implement access controls to restrict movement between environments.

2. Data Segregation and sanitization (e.g., masking, tokenization, anonymization, or other appropriate methods, according to NIST SP 800-88 Guidelines for media sanitization): Prohibit use of production data in non-production environments unless properly sanitized.

3. Enforce encryption for sensitive data used in lower environments.

4. Access Control and Least Privilege: Implement role-based access control (RBAC) for environment-specific access. Enforce approval processes for data migration across environments.

5. Access policies should include on-demand approval. All access and permissions should be revoked outside the allowed (approved) session duration with Zero Standing Privileges (ZSP).

[Shared between the MP, AP, OSP and CSP]

1. Define strict boundaries between AI model training, testing, and production environments.

2. Enforce segmentation policies to prevent cross-environment data leakage.

3. Implement monitoring tools to detect unauthorized movements between environments.

From CCM v4.1: Control Ownership Rationale. Both CSP and CSC are responsible for the implementation of this control but doing so independently from one another. It is a standard best practice to separate production and non-production environments to ensure a stable production environment that is not influenced by changes in the non-production environment, and to ensure that test data never enters into a production environment (and equally that no production data enters the non-production environment). This applies equally for both CSP and CSC whether the service being delivered is IaaS, PaaS, or SaaS.

Implementation Guidelines. Applicable to all service models: The CSP should maintain a non-production environment that is completely separate from the production environment in order to safeguard production systems from potential threats in non-production environments. The non-production environment should be running in an architecturally similar environment which is both logically and physically separated from the production environment through the use of appropriate security controls.

The non-production environment should be used for testing any pre-production releases, and should be exclusively used with test data instead of actual CSC/business data.

Implementation best practices for CSPs include (but are not limited to):

• a. Accounts and Access Permissions Separation:

  • i. Distinct IAM policies should exist and implemented for each environment, strictly defining access control rules and authorization levels

  • ii. Access permissions should be granted based on the specific roles and tasks associated with each environment to ensure that the necessary least privileges are provided

  • iii. Distinct accounts for accessing and managing production and non-production environments should be created

• b. Network Logical/Physical Separation:

  • i. Logical separation between production and non-production environments should be implemented (e.g., using Virtual networks (VNet), Virtual Private Clouds (VPCs) and cloud Network Security Groups (NSGs))

  • ii. Each environment should have its own VNet, encapsulated within its own network security group (NSG) to prevent accidental or deliberate cross-environment communication

  • iii. Physical separation should also be considered (e.g., using separate data centers, racks, or even different physical locations)

  • iv. Network segmentation tools should be utilized to isolate production and non-production environments from each other (e.g., separate subnets, firewalls, and access control lists (ACLs) to prevent unauthorized traffic from traversing between the environments)

• c. Sandbox Environments for Development and Testing:

  • i. Sandbox environments specifically designed for development and testing purposes should be created

  • ii. Sandboxes should be isolated from production systems to prevent accidental or malicious code deployments from affecting critical data and systems

  • iii. Automated testing procedures should be implemented to validate the functionality and security of non-production environments before deployment to production

• d. Resource Management Separation:

  • i. Separate resource management tools should be implemented for each environment to prevent accidental provisioning, configuration changes, or deletions in the wrong environment

  • ii. Data separation strategies should be implemented to prevent the accidental mixing of production and non-production data (e.g., use different storage solutions, data masking techniques, or implementing data segregation rules within data repositories)

  • iii. Different versioning systems should be used for production and non-production environments to avoid conflicts between releases and ensure that only tested and approved changes are deployed to production

  • iv. Different naming conventions should be adopted for resources in production and non-production environments to avoid confusion and accidental changes to the wrong environment

• e. Documentation: Documentation outlining the separation policies, access controls, network configurations, and testing procedures should be developed and maintained for each of production and non-production environments

• f. Updates Management: Patches and updates should be first applied in the non-production environment and after successful testing, then applied to the production environment

• g. Continuous Monitoring and Evaluation: Continuous monitoring and evaluation of both production and non-production environments should be implemented to ensure that are adequately secured and aligned with security standards (e.g., Monitor System logs, network traffic, vulnerability scanning, and user activity to detect suspicious behavior or potential security breaches).

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.

Shared Implementation Guidelines

[All Actors]

1. Use identity-based policies for resource isolation to enforce tenant-specific access controls.

2. Restrict intra-tenant and cross-tenant access based on least privilege.

[Shared between the MP, AP, OSP and CSP]

1. Network and Access Segmentation: Segment internal networks and tenant boundaries at the infrastructure or service level to enforce isolation between service customers (tenants).

2. Implement network and platform controls (e.g., VLANs, virtualization, subnets, ACLs, service isolation mechanisms) to enforce tenant separation and isolate workloads and environments.

3. Continuously monitor tenant interactions and cross-tenant access patterns through logging and anomaly detection mechanisms (e.g. SIEMs, behavioral analytics, or ML-based threat detection, etc.) to detect misuse, unauthorized access, lateral movement, or data leakage between tenants.

4. Zero Trust Architecture (ZTA) principles: to enforce microsegmentation, continuous verification, and minimal implicit trust across services, users, and tenant boundaries.

Implementation Guidelines for Cloud Service Providers (CSP)

[All Actors]

1. Use identity-based policies for resource isolation to enforce tenant-specific access controls.

2. Restrict intra-tenant and cross-tenant access based on least privilege.

[Shared between the MP, AP, OSP and CSP]

1. Network and Access Segmentation: Segment internal networks and tenant boundaries at the infrastructure level.

2. Implement VLANs and firewall rules to enforce tenant separation. Use virtualization and network controls (e.g., subnets, ACLs) to isolate workloads and environments.

3. Continuously monitor tenant interactions with logging and AI-driven anomaly detection: Use tools like SIEMs, behavioral analytics, or ML-based threat detection to detect misuse, lateral movement, or data leakage.

4. Zero Trust Architecture (ZTA) principles: Enforce microsegmentation, continuous verification, and minimal implicit trust across services and users.

From CCM v4.1: Control Ownership Rationale. This is a “Shared (Dependent)” control for both IaaS and PaaS CSPs and CSCs. For the SaaS cloud service delivery model, it is a CSP-owned control.

Implementation Guidelines. Network and system controls should be designed and deployed to isolate (segment and segregate) CSCs in a multi-CSC environment and between the CSP and CSC environments.

IaaS Provider: The CSP is responsible for designing, developing, deploying and configuring the network, host infrastructure and virtualization platform such that the CSP and CSC user access and intra-CSC access is appropriately segmented, monitored, and restricted from other CSCs.

PaaS Provider: The CSP is responsible for designing, developing, deploying, and configuring the network, host infrastructure, virtualization platform, virtual machines, operating systems, and platform software such that CSP and CSC user access and intra-CSC access is appropriately segmented and segregated, monitored, and restricted from other CSCs.

SaaS Provider: The CSP is responsible for designing, developing, deploying, and configuring the network, host infrastructure, virtualization platform, virtual machines, operating systems, and platform software and applications. The CSP and CSC user access and intra-CSP access is appropriately segmented and segregated, monitored, and restricted from other CSCs.

Applicable to all service models: Implementation best practices include (but not limited to):

• a. Segmentation Definition: Possible definitions of segmentation should be defined and understood including a range from “total separation” to “partial logical separation” of business-critical assets and/or personal data and sensitive user data, and sessions

• b. Multi-tenant Infrastructure Isolation: Multi-Tenant environments should be physically and logically separated and isolated to prevent unauthorized access between different tenants using various segmentation techniques like network segmentation, virtual machines, containerization to create isolated compartments for each tenant

• c. Network Segmentation:

  • i. Network segmentation should be enforced at various levels, including virtual private clouds (VPCs), subnets, and security groups to restrict network traffic within and between tenants, and prevent unauthorized cross-tenant access

  • ii. Virtualized networks (VNet) should be utilized to create private, isolated networks for each tenant and to compartmentalize tenant data and applications, preventing unauthorized access from other tenant environments. Implement Network Security Groups (NSGs) to enforce granular access control within each VNet.

• d. Access Segregation:

  • i. Robust IAM practices should be established to control access to cloud resources and enforce segregation. Use RBAC, MFA and PoLP to limit access based on user roles and responsibilities.

  • ii. CSP and CSC user access to cloud resources should be separated. CSPs should be provided with access to infrastructure components and management tools, while restricting CSCs to their own tenants’ resources

  • iii. Cross-CSC protections should be implemented at the application layer to ensure that the CSC cannot compromise the CSP’s applications to gain unauthorized access to the information of other CSCs

• e. Access Monitoring and Reviews: CSP and tenant access activities should be continuously monitored and reviewed to provide visibility into potential security breaches or unauthorized access attempts

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.

Shared Implementation Guidelines

[All Actors]

1. Define Secure Migration Standards.

2. Establish encryption policies for data migration based on NIST and CIS guidelines.

3. Ensure that all cloud migrations follow an approved security framework.

4. Approved Secure Protocols.

5. Use only industry-standard encrypted channels such as TLS 1.2+, IPSec, and SSH.

6. Implement end-to-end encryption for sensitive data transfers.

7. Access Control and Monitoring.

8. Ensure only authorized personnel can initiate migration processes.

9. Implement logging and monitoring mechanisms to track migration activities.

Implementation Guidelines for Cloud Service Providers (CSP)

[All Actors]

1. Define Secure Migration Standards.

2. Establish encryption policies for data migration based on NIST and CIS guidelines.

3. Ensure that all cloud migrations follow an approved security framework.

4. Approved Secure Protocols.

5. Use only industry-standard encrypted channels such as TLS 1.2+, IPSec, and SSH.

6. Implement end-to-end encryption for sensitive data transfers.

7. Access Control and Monitoring.

8. Ensure only authorized personnel can initiate migration processes.

9. Implement logging and monitoring mechanisms to track migration activities.

From CCM: Control Ownership Rationale. This control is a “Shared (Dependent)” control irrespective of the service model. It should be implemented/operated by both the CSP and CSC.

The CSP and CSC should use secure and encrypted communication channels including up-to-date and approved protocols (e.g., FIPS), when migrating servers, services, applications, or data both within and outside its boundary.

Implementation Guidelines. Applicable to all service models: When migrating servers, services, applications, or data to cloud environments, CSPs should implement secure and encrypted communication channels to safeguard sensitive information. This ensures that data remains protected throughout the migration process and during its subsequent operation in the cloud.

The CSPs should adhere to the following implementation best practices:

• a. End-to-End Data Encryption:

  • i. Data should be encrypted at all stages of its lifecycle, from storage to transmission and processing

  • ii. Data-at-rest encryption should be employed to protect data stored on disks or persistent storage devices within the cloud

  • iii. Data-in-transit encryption should be utilized to protect data transmitted between cloud components and between clients and the cloud

• b. Secure Transport Protocols:

  • i. Up-to-date and industry-approved encryption protocols should be leveraged, at the various OSI layers, for communication between cloud infrastructure components and between clients and the cloud (e.g., Use HTTPS/TLS or FTPS (transport layer), IPSec (network layer), and secure file transfer protocols SFTP, SCP over SSH (application layer))

  • ii. These protocols should be configured with strong cryptographic cipher suites and authentication mechanisms (refer to CEK domain) and used in accordance with corporate security standards and industry best practices

• c. VPN Technology:

  • i. VPNs should be implemented to establish a secure and encrypted tunnel between on-premises networks and cloud environments

  • ii. VPN protocols like IPSec or TLS should be employed with strong encryption and authentication mechanisms

• d. API Security: If APIs are used in the migration process, they should be secured with proper authentication, authorization, and data validation mechanisms

• e. Authentication Mechanisms: MFA should be utilized to verify the identity of users and systems participating in the data transfer

• f. Limit Data Exposure:

  • i. The amount of sensitive data being transferred should be minimized and only what is necessary exposed

  • ii. For sensitive data, using data masking or obfuscation techniques during migration should be considered to further reduce the risk of data exposure

• g. Migration Monitoring and Logging:

  • i. All data transfers should be continuously monitored and logged during the migration process

  • ii. The security practices of any third-party vendors involved in the migration process should be evaluated and monitored

I&S-08: Network Architecture Documentation

Control Specification

Identify and document high-risk environments based on data sensitivity, threat exposure, and business impact.

Shared Implementation Guidelines

[All Actors]

1. Define High-Risk Environments.

2. Establish criteria to classify environments as high-risk.

3. Include data sensitivity, criticality, and regulatory impact in classification. It is recommended the BIA help to identify the critical business functions with high business impact risk.

4. Network Documentation Framework.

5. Maintain up-to-date network topology diagrams.

6. Document segmentation strategies and security zones.

7. Review and Update Documentation.

8. Perform periodic audits to validate network architecture documentation.

9. Ensure updates align with infrastructure changes and emerging threats.

Implementation Guidelines for Cloud Service Providers (CSP)

[All Actors]

1. Define High-Risk Environments.

2. Establish criteria to classify environments as high-risk.

3. Include data sensitivity, criticality, and regulatory impact in classification. It is recommended the BIA help to identify the critical business functions with high business impact risk.

4. Network Documentation Framework.

5. Maintain up-to-date network topology diagrams.

6. Document segmentation strategies and security zones.

7. Review and Update Documentation.

8. Perform periodic audits to validate network architecture documentation.

9. Ensure updates align with infrastructure changes and emerging threats.

From CCM v4.1: Control Ownership Rationale. This is a “Shared (Dependent)” control for both IaaS and PaaS CSsP and CSCs. The CSC is responsible for identifying and documenting high-risk environments within CSC-managed workloads but depends on the CSP to provide the technical capabilities for isolation and segregation between CSCs.

The SaaS CSP is responsible for identifying and documenting high-risk environments within the SaaS application. Data flow diagrams should clearly define boundaries and data flows between zones having different data classification, trust levels, or compliance and regulatory requirements which clearly identify high-risk environments.

Implementation Guidelines. CSPs should establish a network architecture documentation to ensure the secure, efficient, and scalable operation of their cloud infrastructure. This documentation should be detailed, consistent, and readily accessible to all relevant stakeholders, including network engineers, security professionals, and customer support teams.

IaaS Provider: The CSP is responsible for identifying and documenting high-risk environments within the network, host infrastructure and virtualization platform.

PaaS Provider: The CSP is responsible for identifying and documenting high-risk environments within the network, host infrastructure, virtualization platform, virtual machines, operating systems and platform software.

SaaS Provider: The CSP is responsible for identifying and documenting high-risk environments within the network, host infrastructure, virtualization platform, virtual machines, operating systems, platform software, and applications. The CSP should make a copy of the documentation available to the CSC on request.

Applicable to all service models: Implementation best practices for network architecture documentation include (but not limited):

• a. Documentation Scope and Objectives: The scope of the network architecture diagrams should be established such as the types of networks, physical and logical components, services, and applications covered, and the specific objectives for creating the documentation

• b. Standardized Terminology and Definitions: Adopt a consistent and standardized set of terminology and definitions that extends to network diagrams, architectural models, and other documentation elements

• c. High-Risk Environments Identification:

  • i. Thorough risk assessments should be conducted to identify potential vulnerabilities and high-risk areas in the network topology

  • ii. High-risk network areas, such as network segments or traffic flows with high volume or sensitive data transfers that are more susceptible to attacks or cause the most damage if compromised, should be prioritized and have stronger security measures applied to

• d. Network Diagrams and Architecture Models:

  • i. Accurate and up-to-date architecture diagrams should be created that visualize the entire network topology, including physical and virtual network components and their corresponding, security zones descriptions, hypervisors, trusted execution environments, workloads on each host and their inter-connectivity and communication paths (e.g., traffic flows, and out-of-band communication channels)

  • ii. Network scanning tools (e.g., open-source Nmap, Zenmap) should be utilized to identify and validate all network components’ topology, including servers, workstations, network devices, and cloud resources

  • iii. Diagrams should be supplemented with architectural models and relevant tools (e.g., open-source GNS3, Ansible, LibreNMS) that represent the logical organization and interactions of network components

  • iv. Tools like network diagram software for visual representation of the network architecture is encouraged that are used (e.g., open-source Diagrams.net, NetBox)

• e. The network diagrams and relevant software should be accessible by authorized personnel and protected against unauthorized access

• f. Network Security Controls Documentation: A detailed description of all security controls implemented in the network should be documented

  • i. The version numbers, patch levels, configuration settings of all network architecture components (e.g., firewall rules, access control lists, and security protocols)

  • ii. The network requirements that govern access, authentication, authorization, and data protection and how these are implemented and enforced throughout the network infrastructure

• g. Network Change Management:

  • i. A change management process for network modifications and updates should be defined (including authorization procedures, testing protocols, and rollback mechanisms)

  • ii. Version control practices should be implemented to track changes to network configurations and documentation over time

• h. Network Documentation Review and Updates: Network architecture and relevant risk assessments documentation should be treated as living documents and updated regularly to reflect changes in the network topology, security policy, new security threats, and evolving compliance requirements.

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.

Shared Implementation Guidelines

[All Actors]

1. Define Network Security Framework.

2. Implement multi-layered security controls.

3. Align security measures with NIST, CIS, and ISO 27001 frameworks.

4. Intrusion Detection and Prevention.

5. Deploy IDS/IPS solutions to monitor and block malicious traffic.

6. Implement anomaly-based detection for AI-driven threat mitigation.

7. Incident Response and Monitoring.

8. Define incident response procedures for network-based attacks.

9. Implement continuous network traffic monitoring and alerting.

Implementation Guidelines for Cloud Service Providers (CSP)

[All Actors]

1. Define Network Security Framework.

2. Implement multi-layered security controls.

3. Align security measures with NIST, CIS, and ISO 27001 frameworks.

4. Intrusion Detection and Prevention.

5. Deploy IDS/IPS solutions to monitor and block malicious traffic.

6. Implement anomaly-based detection for AI-driven threat mitigation.

7. Incident Response and Monitoring.

8. Define incident response procedures for network-based attacks.

9. Implement continuous network traffic monitoring and alerting.

From CCM: Control Ownership Rationale. This is a Shared (Dependent) control for both the IaaS and PaaS CSP and the CSC. For the SaaS solution, it is CSP-owned. In an IaaS service, the CSC shares responsibility with the CSP to deploy, manage, secure, and configure the networking solutions. Most networking security controls in a PaaS solution are provided by the CSP. In a SaaS service, network security controls are managed and secured for the CSC as part of a software core offering because the network infrastructure is abstracted.

Implementation Guidelines. Network-based attacks (such as but not limited to Layer 3 DDoS, man-in-the- middle, SQL Injection, IP spoofing, malware, etc.) attempt to gain unauthorized access to network infrastructure in order to compromise the confidentiality, integrity and availability of assets and information.

Network security controls (defense-in-depth techniques) detect and prevent attacks using advanced threat intelligence and protocol analysis, anomaly detection, indicators of compromise blocking, and signature-based methods.

The CSP should also expose security controls to the CSC so it can properly configure and manage its network security.

Vulnerabilities that exist in a physical environment also apply in a virtual environment. Configuration flaws/vulnerabilities in the applications, firewalls, or networks are vulnerable to exploits. Defense-in-depth techniques should be leveraged for both physical, logical, and administrative controls.

IaaS Provider: The CSP should define, implement and evaluate processes, procedures, and defense-in-depth techniques (e.g., DDoS mitigation solution, network filtering, firewalls, IDS/IPS) for protection, detection, and timely response to network-based attacks against the host infrastructure (hypervisor and operating system) and storage devices.

PaaS Provider: The CSP should define, implement and evaluate processes, procedures, and defense-in-depth techniques (e.g., DDoS mitigation solution, network filtering, firewalls, IDS/IPS) for protection, detection, and timely response to network-based attacks against the host infrastructure (hypervisor and operating system), storage devices, virtual machines, containers, platform-managed software including web services, database services, and analytics.

SaaS Provider: The CSP should define, implement and evaluate processes, procedures, and defense-in-depth techniques (e.g., DDoS mitigation solution, network filtering, firewalls, IDS/IPS) for protection, detection, and timely response to network-based attacks against the host infrastructure (hypervisor and operating system), storage devices, virtual machines, containers, platform-managed software including web services, database services, analytics, applications, and data.

Applicable to all service models: Defense-in-depth techniques/insights that should be considered include (but not be limited to):

• a. Network Assets Scope and Protection Prioritization:

  • i. A detailed and regularly updated inventory of all cloud network technologies and types within the cloud environment should be developed, including both wired and wireless network assets

  • ii. Based on data sensitivity and its classification ensure that the most critical network assets receive prioritized protection measures

• b. Firewalls Management:

  • i. Firewalls should be deployed at each layer of the cloud network (virtual private cloud [VPC], subnet, and application level) to filter traffic based on security rules and prevent unauthorized access

  • ii. Web Application Firewalls should be deployed to protect web applications from common web-based attacks and block malicious requests before they can reach the application server (e.g., SQL injection, cross-site scripting, and denial-of-service [DoS] attacks)

• c. Intrusion Detection and Prevention Systems (IDS/IPS): IDS/IPS solutions should be implemented to monitor network traffic for suspicious activity and identify potential intrusions or attacks (IDS passively detects anomalies, while IPS actively blocks malicious traffic)

• d. Network Traffic Analysis (NTA):

  • i. NTA tools should be utilized to gain deeper insights into network traffic patterns and identify anomalies that may indicate malicious activities (e.g., deep packet analysis, protect DDoS attacks with traffic throttling, and blackholing)

  • ii. Ingress/egress traffic patterns may include media access control (MAC) spoofing, ARP poisoning attacks, and distributed denial-of-service (DDoS) attacks

• e. Network Traffic Encryption: Sensitive data in transit should be encrypted to protect it from interception and unauthorized access using secure network protocols such as TLS/IPsec for data transmissions within the cloud and between cloud and on-premises environments

• f. Network Threat Intelligence:

  • i. Threat intelligence feeds should be utilized to stay informed about emerging network threats, vulnerabilities, and attack methods in the cloud environment

  • ii. Threat intelligence should be integrated into network security systems to proactively detect and prevent cloud network attacks

• g. Network Infrastructure Patching and Updates:

  • i. A vulnerability management program should target be leveraged to identify, assess, and remediate vulnerabilities in the cloud network infrastructure and software/applications (refer to TVM domain)

  • ii. Stay up-to-date with the latest security patches and updates for cloud network infrastructure components to mitigate vulnerabilities that could be exploited by attackers

• h. Network Secure Configuration Management:

  • i. Secure configuration standards for cloud network resources should be enforced (e.g., virtual machines, network devices settings, and cloud-based application deployment configurations)

  • ii. Security settings should be enabled with strong encryption for authentication and transmission, and vendor default settings replaced (e.g., encryption keys, passwords, and SNMP community strings) i. Vendors Diversity of Security Controls: A variety of network and system components from different vendors should be used and integrated to reduce the risk of single points of failure and vulnerabilities

• i. Continuous Monitoring and Evaluation:

  • i. Auditing and logging capabilities (e.g., SIEM solution) should be implemented to track network activity, user actions, and security events from various network assets Monitor logs for anomalies, suspicious activity, and potential breaches

  • ii. Capabilities should be developed to detect unauthorized (rogue) network devices in the network and disconnect them quickly

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.

Shared Implementation Guidelines

[All Actors]

1. Establish Logging and Monitoring Policies.

2. Document types of events to log (e.g., access, errors, configuration changes, inference requests, etc.).

3. Define retention periods, log sensitivity classification, access controls, and escalation paths in line with business, regulatory and contractual needs.

4. Apply and Enforce Policies; make policy documents visible across departments in the entire organization.

5. Implement automated logging across infrastructure, applications, and model endpoints.

6. Ensure all logs are time-synchronized and tamper-resistant across all environments.

7. Get formal approval from compliance and/or security leadership and re-approval whenever material changes occur.

8. Conduct regular reviews and trigger reviews upon: changes in architecture or supply chain, emergence of new threats or vulnerabilities, changes in regulations or threat intel.

Implementation Guidelines for Cloud Service Providers (CSP)

1. Establish and maintain logging and monitoring policies that cover all layers of cloud infrastructure (compute, storage, network, and platform services).

2. Define clear logging requirements for privileged access, system-level changes, API calls, and data plane activities across all customer-facing and internal systems.

3. Ensure procedures specify mechanisms for log collection, centralization, protection (e.g., encryption, integrity checks), and long-term retention in accordance with compliance requirements.

4. Integrate logging systems with real-time monitoring and alerting platforms (e.g., SIEMs) to support threat detection, forensic investigation, and SLA enforcement.

5. Implement audit logging across control planes (e.g., management APIs, orchestration tools) and provide customers with access to relevant logs via dashboards or APIs.

6. Regularly evaluate the effectiveness of logging controls through internal audits, and update policies at least annually or after significant infrastructure or threat landscape changes.

[All Actors]

1. Establish Logging and Monitoring Policies.

2. Document types of events to log (e.g., access, errors, configuration changes, inference requests, etc.).

3. Define retention periods, log sensitivity classification, access controls, and escalation paths in line with business, regulatory and contractual needs.

4. Apply and Enforce Policies; make policy documents visible across departments in the entire organization.

5. Implement automated logging across infrastructure, applications, and model endpoints.

6. Ensure all logs are time-synchronized and tamper-resistant across all environments.

7. Get formal approval from compliance and/or security leadership and re-approval whenever material changes occur.

8. Conduct regular reviews and trigger reviews upon: changes in architecture or supply chain, emergence of new threats or vulnerabilities, changes in regulations or threat intel.

From CCM: Control Ownership Rationale. The implementation responsibility for this control is shared between both the CSC and the CSP, however it is expected that the control is implemented independently by each party. Each party is expected to have different logging and monitoring policy requirements and procedures defined and adopted within their ecosystem that they should achieve respectively to their geographical location, contractual, and regulatory requirements.

Implementation Guidelines. Applicable to all service models: The CSP should have its own policies and procedures for logging and monitoring with a clear purpose, scope, roles, responsibilities, and coordination activities defined among organizational entities, as well as provisioned training exercises.

The former should be tailored to meet the specific requirements that are defined within contractual, legal and regulatory frameworks and should match the guidelines for shared security responsibility for the different cloud architecture models. The CSP should make provision to monitor its internal systems and also systems (cloud services) provided to the CSC.

Policies and procedures should be reviewed or updated when a significant change to systems is made, when an incident occurs, or at least annually.

Policies should include (but not limited to) provisions on the following:

• a. Scope and Objectives: The purpose, scope and objectives of logging and monitoring activities, specifying the systems, applications, and data covered, as introduced by regulations and risk analysis activities. The policy should include with enhanced specificity, the criteria and parameters for defining, categorizing and recording logging “attempts”

• b. Logging Standards:

  • i. Uniform logging standards requirements for all cloud components, outlining the types of events to be logged and the required log format

  • ii. Based on a defined data classification framework (refer to DSP-04), the corresponding logging requirements for sensitive data should be specified in accordance to their assigned classification level

• c. Runtime Requirements: Determine conditions for initializing, stopping, or pausing of the audit logs, while integrating continuous risk assessments

• d. Retention Requirements: Log retention and archiving requirements based on regulatory requirements, addressing operational, forensic analysis and compliance purposes

• e. Monitoring Tools and Technologies:

  • i. The tools and technologies to be used for logs monitoring and analysis, ensuring they align with industry best practices

  • ii. Processes and procedures for anomalies detection and correlation with logs, and response automation, including communication protocols, escalation procedures, and documentation requirements

• f. Alerting and Response: Logs alerting and stakeholders notification criteria based on logs for specific security events that may indicate security threats, ensuring timely response and mitigation

• g. Timestamping: Timestamping requirements for all logs, including those from in-house applications

• h. Access Control: Access control requirements specifying who has access to logs, with strong authentication and authorization mechanisms for log access

  • i. Use of and changes to identification and authentication logging mechanisms, including elevation of privilege

  • ii. Log requirements for physical access control systems

  • iii. CSCs enablement (e.g.,via APIs) to access logs related to the cloud services provisioned and according to established SLAs i. Logs Protection: i. Requirements for the protection of logs and use of cryptography and encryption to secure log data ii. Requirements for key management systems logs (e.g., administrative access on key management systems, key life-cycle management logs)

• i. System Design and Configuration:

  • i. Requirements for the log system itself (e.g., successful/failed access to the log system, changes to the authentication scheme, deletion of logs or indexes)

  • ii. Requirements for the log system that the High Level Design (HLD) should satisfy

• j. Availability and Integrity: Availability and verifiable integrity for log systems and information data should be achieved. Tamper-evident ledgers should be utilized for strengthened security and compliance adherence

• k. Regular Logs Audits and Reviews: Provisions for regular audits and reviews of logs to ensure their integrity, accuracy, and relevance

• l. Approval: Approval requirements and senior management involvement to ensure alignment with the organization’s strategic goals and risk appetite

  • i. An approval process should be established for any changes or modifications to the policy and procedures

  • ii. A documented record of approvals (including dates, names of approvers, and any relevant comments or discussions) should be maintained

• m. Communication: Effective communication of the policy and procedures should be facilitated to all relevant cloud stakeholders

• n. Maintenance and Reviews: Logging and monitoring policies and procedures should be documented, reviewed and updated at least annually to ensure alignment with evolving cloud security landscape and to reflect changes in cloud technology, regulations, and risks

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.

Shared Implementation Guidelines

[All Actors]

1. Encrypt all audit-log data at rest and in transit using industry-standard ciphers; manage keys in an approved KMS.

2. Define and automate retention and disposal policies that meet regulatory, contractual and business requirements.

3. Apply fine grained access control e.g., role- or attribute-based (RBAC/ABAC) and separation-of-duties so only authorised personnel or services can read, write, or delete logs.

4. Guarantee log integrity with tamper-evident controls (hashing, signing, immutability, etc.) and schedule periodic integrity checks.

5. Monitor and alert on log-access events and anomalies, forwarding alerts to the SOC / incident-response process.

6. Document log locations, protection controls and restoration procedures, and test recovery as part of DR / IR exercises.

Implementation Guidelines for Cloud Service Providers (CSP)

1. Deploy a centralized security monitoring system capable of ingesting logs from all layers of cloud infrastructure—compute, storage, networking, and control planes.

2. Define a set of baseline and advanced detection rules to identify security-relevant events such as unauthorized access attempts, privilege escalation, resource anomalies, API abuse, and lateral movement.

3. Integrate monitoring tools with alerting systems (e.g., SIEM, SOAR, cloud-native monitoring) to ensure that alerts are routed to designated security teams or automated response workflows.

4. Implement tiered alerting based on event criticality to avoid alert fatigue and prioritize response efforts.

5. Ensure alert metadata includes sufficient context (e.g., user, resource, location, action) to support triage and investigation.

6. Regularly tune detection logic and alert thresholds based on threat intelligence, incident post-mortems, and evolving customer environments.

[All Actors]

1. Encrypt all audit-log data at rest and in transit using industry-standard ciphers; manage keys in an approved KMS.

2. Define and automate retention and disposal policies that meet regulatory, contractual and business requirements.

3. Apply fine grained access control e.g., role- or attribute-based (RBAC/ABAC) and separation-of-duties so only authorised personnel or services can read, write, or delete logs.

4. Guarantee log integrity with tamper-evident controls (hashing, signing, immutability, etc.) and schedule periodic integrity checks.

5. Monitor and alert on log-access events and anomalies, forwarding alerts to the SOC / incident-response process.

6. Document log locations, protection controls and restoration procedures, and test recovery as part of DR / IR exercises.

From CCM: Control Ownership Rationale. The implementation responsibility for this control is shared between both the CSC and the CSP, however it is expected that the control is implemented independently by each party. Both parties may have different processes, procedures and technical control measures required by contractual, regulatory, or legal factors for the protection and retention of audit logs.

Implementation Guidelines. Applicable to all service models: CSPs should implement a strong regime of protection including physical and logical controls to ensure the protection of logs that should be in line with any legal, regulatory or contractual compliance requirements. In events where these are not applicable they should ensure good practice guidelines are followed.

Protection of logs should ensure the forensic integrity of log files and data, such as restricting unauthorized access, monitoring and auditing log access and changes, and storing in secure environments.

Log data should be retained for a minimum duration as defined by any legal requirements and/or contractual agreement with the CSC, that can allow for operational and legal investigations or detection of malicious activities.

Additional recommendations that aim to ensure the security and retention of audit logs include (but not limited to):

• a. Centralized Audit Logging: Audit logs should be integrated with a Security Information and Event Management (SIEM) system to facilitate centralized storing and management, and for efficient monitoring and correlation of security events

• b. Audit Logs Configuration: Cloud services should be configured to generate comprehensive audit retention logs in accordance to log retention and archiving policy and regulatory requirements

• c. Logs Retention and CSCs:

  • i. Archiving mechanisms should be implemented (and automated where possible) to ensure logs are securely stored and accessible for future investigations

  • ii. Transparent communication with CSCs should be maintained about audit log retention policies, including any changes to retention periods or protection mechanisms

  • iii. CSCs should be provided with the ability to customize data retention settings based on their specific compliance and business needs with options for short-term and long-term data retention

  • iv. Secure data deletion processes should be implemented to permanently remove CSC logged data when it reaches the end of its retention period or when requested by the CSC

• d. Secure and Efficient Logs Storage:

  • i. Audit logs should be stored in secure, tamper-evident storage to prevent unauthorized access or alterations

  • ii. Immutable storage should be employed by storing logs in a write-once-read-many (WORM) format to prevent tampering

  • iii. Data deduplication and compression techniques should be utilized to identify and remove redundant data blocks, reducing the overall storage footprint of retained logs

  • iv. Log rotation mechanisms should be implemented (automated where possible) that periodically move older logs to archival storage, while maintaining access to relevant recent data

• e. Cryptographic mechanisms should be implemented to protect retained log data at rest, in use and in transit

• f. Restricted Log Access:

  • i. Stringent access controls for retained audit logs should be implemented, restricting access to authorized personnel only

  • ii. An audit trail of access to the retained audit logs should be maintained, recording details such as who accessed the logs, when, and for what purpose

• g. Review and Monitoring: Implement a regular review and automated monitoring process for audit logs to detect anomalies and alert on suspicious activities related to access and modifications of audit logs

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.

Shared Implementation Guidelines

[All Actors]

1. Identify and catalogue security-relevant events for applications, infrastructure, supply-chain components and AI models (e.g., authentication failures, config changes, model-drift alarms).

2. Continuously collect and time-stamp those events; normalise them into a central log or telemetry pipeline.

3. Define alert rules and thresholds (including severity, routing and escalation paths) for unauthorised access, integrity violations, performance anomalies and other high-risk conditions.

4. Send alerts to a designated response channel with enough context to support triage (actor, asset, location, action, timestamp).

5. Document investigation and response procedures that map alert severities to required actions and response-time targets.

6. Tune detection logic and threshold values regularly using threat intel, incident post-mortems and changes in architecture or business risk.

Implementation Guidelines for Cloud Service Providers (CSP)

1. Deploy a centralized security monitoring system capable of ingesting logs from all layers of cloud infrastructure—compute, storage, networking, and control planes.

2. Define a set of baseline and advanced detection rules to identify security-relevant events such as unauthorized access attempts, privilege escalation, resource anomalies, API abuse, and lateral movement.

3. Integrate monitoring tools with alerting systems (e.g., SIEM, SOAR, cloud-native monitoring) to ensure that alerts are routed to designated security teams or automated response workflows.

4. Implement tiered alerting based on event criticality to avoid alert fatigue and prioritize response efforts.

5. Ensure alert metadata includes sufficient context (e.g., user, resource, location, action) to support triage and investigation.

6. Regularly tune detection logic and alert thresholds based on threat intelligence, incident post-mortems, and evolving customer environments.

[All Actors]

1. Identify and catalogue security-relevant events for applications, infrastructure, supply-chain components and AI models (e.g., authentication failures, config changes, model-drift alarms).

2. Continuously collect and time-stamp those events; normalise them into a central log or telemetry pipeline.

3. Define alert rules and thresholds (including severity, routing and escalation paths) for unauthorised access, integrity violations, performance anomalies and other high-risk conditions.

4. Send alerts to a designated response channel with enough context to support triage (actor, asset, location, action, timestamp).

5. Document investigation and response procedures that map alert severities to required actions and response-time targets.

6. Tune detection logic and threshold values regularly using threat intel, incident post-mortems and changes in architecture or business risk.

From CCM v4.1: Control Ownership Rationale. This control’s implementation responsibility is shared between the CSP and CSC, however with a dependency between the two parties due to the CSP needing to provide access, forwarding, or the ability for the CSC to deploy its own logging and monitoring requirements for infrastructure and applications, where it may be required. Effective communication and collaboration between the CSP and CSC enables both parties to monitor and promptly detect, analyze, and respond to security-related events in the cloud environment.

Implementation Guidelines. IaaS Provider: The CSP should make provision for the infrastructure to support CSC capabilities where required.

PaaS Provider: The CSP would assume this responsibility in part within PaaS, for applications that are installed within the PaaS environment. This would exclude applications that the CSC installs on the PaaS platform.

SaaS Provider: The CSP is responsible for conducting Infrastructure and application monitoring at a good practice level. Additional levels should be supported by allowing the CSC to customize its monitoring on an on-demand basis and maintain the ability for the CSC to conduct its own activities.

Applicable to all service models: Security events identification and monitoring implementation best practices include (but not limited to):

• a. Monitoring Scope and Objectives:

  • i. The monitoring scope should be determined, including the cloud specific environments, and underlying cloud infrastructure components and resources

  • ii. The objectives of security events monitoring should be defined (e.g., identifying breaches, detecting unauthorized activities, preventing data loss)

  • iii. Security events monitoring tools should be used that align with the monitoring objectives, scope, and technical capabilities of the cloud environment

  • iv. The CSP should prioritize monitoring functions based on the CSC’s categorization of own risks, business requirements and impact

• b. Logs Collection and Analysis: Logs should be collected and analyzed to capture a wide range of security-related events, including all user activities, API calls, and system events to identify any unusual activity (e.g., system logs showing unauthorized access attempts, network traffic spikes and any system anomalies)

• c. Data Normalization: Standardize and normalize collected events to ensure consistent analysis and comparison (e.g., transforming events into a common format and resolving inconsistencies in naming conventions and data structures)

• d. Threat Intelligence Integration: Threat intelligence feeds should be integrated with log systems and the security-events analysis to enhance threat detection and prioritize alerts based on known vulnerabilities and attack patterns

• e. Machine Learning and Anomaly Detection: Machine learning techniques and tools should be leveraged to determine patterns of normal behavior and detect anomalies

• f. Security Analytics and Correlation: Security analytics tools should be employed to correlate identified security events across different sources and identify relationships between seemingly unrelated events, potentially revealing hidden attack patterns

Alerting implementation best practices include (but not limited to):

• a. Alerting Rules Configuration:

  • i. Monitoring rules should be developed and configured to generate alerts for specific types of security events (e.g., unauthorized access attempts, data exfiltration, or anomalous traffic patterns)

  • ii. Alerts should be based on and generated from metrics that indicate risks, events, or incidents that go beyond established or agreed thresholds (e.g., based on CSC requirements)

• b. Alerting Rules Review: Alerting rules should be evaluated and refined periodically based on security trends, threat intelligence updates, and feedback from stakeholders

• c. Alerts Categorization: Alerts should be classified based on severity and type, such as high, medium, and low priority, and anomaly detection, intrusion detection, and log analysis events

• d. Alerting Prioritization: A hierarchical alerting system should be implemented to prioritize and route alerts to appropriate stakeholders based on severity and impact

• e. Alert Data History: Historical alert data should be analyzed to identify patterns, trends, and potential gaps in monitoring coverage

Generated alerts should define (but not limited to):

• a. Alerts Content:

  • i. Event Type: The type of event triggering the alert (e.g., access, modification, deletion) for quick identification and categorization

  • ii. Affected Resource: Information about the specific resource or asset (e.g., user account, server, database) involved in the event to streamline incident investigation

  • iii. Timestamp: The timestamp of the event to establish the timing of the incident for correlation with other logs and to determine the urgency of the response

  • iv. User or Entity Responsible: The user or entity responsible for the action, enabling swift attribution and accountability during incident response

• b. Source IP or Location: The source IP address or location of the event to understand the origin and potential geographic context of the activity vi. Action Details: The action taken, such as the specific data accessed, modified, deleted, or copied, as well as the configurations or settings affected vii. Success/Failure Status: Whether the action was successful or resulted in a failure, helping differentiate normal operations from potential security incidents viii. Thresholds or Anomalies: Threshold values or anomalies that, when exceeded, trigger alerts (e.g., an unusually high number of failed login attempts may indicate a brute-force attack) ix. Contextual Information: Contextual information relevant to the action, such as the context of the access (e.g., during off-hours) or unusual patterns that may indicate malicious activity

• c. Severity Level: A severity level to the alert based on the potential impact and criticality of the event, guiding the urgency of the response (e.g., define Standard Operating Procedures (SOP) to investigate the alerts severity) xi. Compliance Indicators: Relevant compliance indicators or violations that may need immediate attention to ensure adherence to regulatory requirements

LOG-04: Audit Logs Access and Accountability

Control Specification

Restrict audit log access to authorized identities and maintain records of that access.

Shared Implementation Guidelines

[All Actors]

1. Apply least-privilege access control, e.g., role- or attribute-based (RBAC/ABAC) to every audit-log store, service and API.

2. Require unique user identities (e.g., administrator accounts following a defined naming convention such as ADM-Username) and enforce strong authentication mechanisms (e.g. Multi-Factor Authentication (MFA) or a Privileged Access Management (PAM) solution, etc.) for all log access requests.

3. Record every read, write, delete or configuration event on audit logs, capturing user ID, source, timestamp and action.

4. Store logs in tamper-evident or immutable locations and replicate for durability.

5. Monitor access patterns and generate real-time alerts for unauthorised attempts, privilege escalation or anomalous activity.

6. Review and reconcile log-access permissions regularly, on a risk-based schedule and revoke any unnecessary rights.

7. Retain log-access records for the policy-defined period and make them available for audit, forensics and compliance reporting.

Implementation Guidelines for Cloud Service Providers (CSP)

1. Restrict access to audit logs using RBAC and least privilege, ensuring only authorized personnel can view or manage logs.

2. Enforce unique user identification and require MFA for all access.

3. Log all access events, capturing user ID, timestamp, and activity performed.

4. Review access permissions on a scheduled basis and promptly revoke unnecessary access.

5. Monitor for unusual access patterns or unauthorized attempts, and generate alerts accordingly.

6. Ensure all log-related actions are attributable to specific individuals for accountability and audit readiness.

[All Actors]

1. Apply least-privilege access control, e.g., role- or attribute-based (RBAC/ABAC) to every audit-log store, service and API.

2. Require unique user identities (e.g., administrator accounts following a defined naming convention such as ADM-Username) and enforce strong authentication mechanisms (e.g. Multi-Factor Authentication (MFA) or a Privileged Access Management (PAM) solution, etc.) for all log access requests.

3. Record every read, write, delete or configuration event on audit logs, capturing user ID, source, timestamp and action.

4. Store logs in tamper-evident or immutable locations and replicate for durability.

5. Monitor access patterns and generate real-time alerts for unauthorised attempts, privilege escalation or anomalous activity.

6. Review and reconcile log-access permissions regularly, on a risk-based schedule and revoke any unnecessary rights.

7. Retain log-access records for the policy-defined period and make them available for audit, forensics and compliance reporting.

From CCM v4.1: Control Ownership Rationale. This control’s implementation responsibility is shared between the CSP and CSC, however with a dependency between the two parties due to the CSP needing to provide such logging functionality to the CSC and capabilities that allow for the access restriction of logs and accountability of access.

In instances where the CSC does not require their own ability and has shifted obligations for these to the CSP for all deployment models, the CSP would become the owner of the control but would require the CSC guidance on who may be authorized to access logs.

Implementation Guidelines. Applicable to all service models: CSPs should secure audit logs to maintain the integrity and accountability of cloud operations. Both CSPs and CSCs have a responsibility to implement appropriate measures to protect audit logs from unauthorized access and ensure that they are tamper-proof. Audit logs contain information about activities, actions and events that may be sensitive in nature. Appropriate restrictions should be implemented to protect them from unauthorized access. Audit logs can be used to track access to assist in the identification and detection of suspicious activity. They also contain data that supports investigative needs in relation to analysis and security incidents.

Implementation best practices that aim to restrict audit log access include (but not limited to):

• a. Log Access using RBAC: An RBAC system that defines and assigns specific audit log access permissions to different roles within the organization should be implemented

• b. Log Access Restrictions:

  • i. MFA access to audit logs should be implemented for all personnel with a ‘need to know’ (including privileged accounts) and according to the least privilege principle

  • ii. SoD should be implemented to prevent single individuals from escalating privileges or accessing sensitive log information beyond their authorized roles

  • iii. The number of individuals who have direct access to raw audit logs should be restricted (access control lists or dedicated log viewing tools should be used to control access)

  • iv. Access to audit logs of internal systems and systems provided to the CSC should be restricted

• c. The CSP should receive an approved confirmation of any CSC personnel who need access to logs vi. Where the CSC has requested its own logging of audit logs, the CSP should allow the relevant configurations and forwarding to be supported

• d. Unique Access Accountability: Audit log entries should be associated with identities (including usernames, associated roles, purpose of access and resources accessed, IP addresses, and timestamps) to allow for accurate tracking of individual user actions, accountability, and usage for investigations and forensic analysis in accordance to legal/regulatory requirements

• e. Session Timeouts: Time-bound access restrictions for audit log access should be implemented, enforcing session timeouts and requiring audit log access reauthentication

• f. Log Access Infrastructure: The infrastructure that hosts and manages access to audit logs should be protected from cyberattacks and unauthorized access. Network and systems security measures should be implemented (refer to IVS domain)

• g. Audit Log Transfers Limitation:

  • i. The transfer of audit logs to external systems or locations should be minimized, when necessary, in compliance with strict data handling procedures as per SLA

  • ii. Security tools (e.g., DLP) should be utilized to monitor and prevent the unauthorized export or transmission of sensitive information from audit logs

• h. Logging Standardization: Standardized logging and access practices should be established across all cloud environments and services

• i. Log Access Monitoring and Reporting: Access to audit logs should be monitored to identify any anomalies or potential breaches

• j. Log Access Reviews: Regular reviews of implemented access controls should be conducted to ensure that only authorized personnel have access to audit logs and to revoke unnecessary permissions

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.

Shared Implementation Guidelines

[All Actors]

1. Establish behavioral baselines for each system layer (infrastructure, orchestration, application, model endpoints) to distinguish normal from anomalous activity.

2. Continuously ingest and analyse audit logs with rules-based and/or ML-driven detection engines.

3. Generate real-time alerts when events deviate from baseline or match high-severity indicators; include user, asset, action, timestamp and source.

4. Route alerts to an incident-response workflow with defined roles, investigation steps, containment / remediation actions and escalation timelines.

5. Document every anomaly investigation (findings, root cause, actions taken, lessons learned) and link records to the corresponding log events.

6. Review and tune detection logic, thresholds and playbooks on a regular basis, or immediately after major incidents, architecture changes or new threat intelligence.

Implementation Guidelines for Cloud Service Providers (CSP)

1. Continuously monitor audit logs for suspicious, unexpected, or policy-violating activities across infrastructure and services.

2. Define baselines for normal behavior and use automated tools (e.g., SIEM, anomaly detection) to flag deviations.

3. Establish clear procedures for triaging, investigating, and responding to anomalies, with defined roles and response timelines.

4. Integrate log alerts with incident response workflows to ensure rapid containment and escalation when needed.

5. Regularly review detection logic and response playbooks to adapt to new threats and operational changes.

[All Actors]

1. Establish behavioral baselines for each system layer (infrastructure, orchestration, application, model endpoints) to distinguish normal from anomalous activity.

2. Continuously ingest and analyse audit logs with rules-based and/or ML-driven detection engines.

3. Generate real-time alerts when events deviate from baseline or match high-severity indicators; include user, asset, action, timestamp and source.

4. Route alerts to an incident-response workflow with defined roles, investigation steps, containment / remediation actions and escalation timelines.

5. Document every anomaly investigation (findings, root cause, actions taken, lessons learned) and link records to the corresponding log events.

6. Review and tune detection logic, thresholds and playbooks on a regular basis, or immediately after major incidents, architecture changes or new threat intelligence.

From CCM v4.1: Control Ownership Rationale. The CSP is responsible for defining a baseline of expected activity within the cloud infrastructure and access to cloud resources, and for analyzing the audit logs for any other activity that deviates from the baseline. The CSP also establishes a process to investigate the deviations by generating alerts and taking appropriate actions. The implementation responsibility for this control is owned by both CSP and CSC, and in a dependent manner, as the CSP should engage the CSC if the investigation or remediation action requires the involvement of the CSC’s personnel.

Implementation Guidelines. Applicable to all service models: Audit logs contain information about activities, actions, and events that are happening in the cloud environment. These logs can be monitored and analyzed to identify when, what, and who: when the event happened, and of potentially malicious activities that may have occurred. Remediation actions should be considered within the SLA as necessary to minimize the blast radius and business impact.

A baseline of the normal, expected activity should be defined, and logs should be continuously monitored for any malicious behavior.

Implementation best practices for logs monitoring include (but not limited to):

• a. Log Monitoring:

  • i. Audit logs should be monitored for anomalies and suspicious patterns and for all relevant actions (success/failure) such as changes, deletion, copying, or other such modification of settings

  • ii. Audit logs should be integrated with SIEM systems to correlate log data and provide a holistic view of security anomalies and potential security events

• b. Collection and Analysis:

  • i. Automated tools should be leveraged to collect and analyze audit logs in real-time or near real-time

  • ii. The level of detail logged should be limited, especially for sensitive data

  • iii. Logging of personal data or other confidential data should be avoided and in accordance with laws and regulations

  • iv. A forensic process for analyzing audit logs should be established in case of security incidents or compliance audits

• c. Response Procedures:

  • i. Initial response instructions or escalation procedures, including who to contact or what actions to take immediately after anomaly detection should be defined and implemented (e.g., SOP of remediation actions to engage the CSC’s personnel)

  • ii. Response procedures should be implemented (and automated where possible) to streamline the process of investigating detected anomalies, issuing alerts, containing threats, and remediating vulnerabilities

  • iii. Reporting solutions should provide near real-time visibility of anomalies and potential security events to reduce time to respond and resolve

• d. Stakeholders Communication:

  • i. Roles and responsibilities should be defined for receiving and escalating security alerts to relevant stakeholders

  • ii. Multiple communication channels should be employed to ensure timely delivery of alerts

  • iii. Centralized dashboards should be provided for stakeholders to monitor alert trends, visualize data, and drill down into specific events

Logs Monitoring should be enabled for all relevant types of logs, including, but not limited, to the following cloud systems and applications:

• a. Administrative activity logs: These logs pertain to privileged user logins and administrators at all levels of the cloud stack and can be used to identify unauthorized access to sensitive data (e.g., Identity and access management (IAM) systems, cloud storage systems, authentication servers, and Single Sign-On (SSO) solutions)

• b. Network Traffic Logs: These are logs for tools that can be used to identify unauthorized access attempts, malicious traffic, and data exfiltration (e.g., Firewalls, intrusion detection and prevention systems (IDS/IPS), load balancers, web application firewalls (WAFs), virtual private networks (VPNs) Anti-Virus (AV) software, Anti-DDoS, Endpoint Detection and Response (EDR), data loss prevention (DLP) solutions, etc.)

• c. Operating System Logs: Should be used to identify unauthorized access attempts, privilege escalation, and malware infections that apply to systems such as operating systems, virtual machines, cloud instances, containers

• d. Applications Logs: pertaining to CSC-owned applications or use of third-party applications activity that can be used to identify errors, exceptions, and suspicious activity. These logs apply to systems such as application servers, web servers, databases, containerized applications, application servers, Platform-as-a-Service (PaaS) environments, and serverless computing services

• e. Encryption and Key Management Logs: These are Logs from encryption and key management systems/services

• f. API Logs: These are logs and metrics from the APIs of the cloud service provider, for the cloud services they provide such as CPU, network, cloud Storage I/O, databases/message queues, cloud management console, platform service logs and metrics, indicating changes in infrastructure configurations

For all logs types, actions (success/failure) such as access, changes, deletions, copying of data, or other modification of configurations and settings should be monitored and relevant logs collected and analyzed.

LOG-06: Clock Synchronization

Control Specification

Use a reliable time source across all relevant information processing systems.

Shared Implementation Guidelines

[All Actors]

1. Synchronise every system, service, container and device with a trusted, authenticated time source (e.g., NTP, the cloud-provider time service, etc.).

2. Configure at least one fallback time source and generate alerts when drift or sync failure exceeds the defined threshold.

3. Continuously monitor time-sync health; log and raise incidents for repeated drift, spoofing attempts or source unreachability.

4. Record and review time-sync settings in configuration management; verify them at least annually or after architecture changes.

5. Enforce consistent timestamp zones and formats across all logs to support correlation, forensics and auditability.

Implementation Guidelines for Cloud Service Providers (CSP)

1. Configure all systems, services, and infrastructure components to sync time with a trusted, centralized time source (e.g., NTP servers).

2. Use authenticated NTP (e.g., NTS or signed NTP) where supported to prevent tampering or spoofing.

3. Ensure consistent time zones and formats across logs to support correlation and investigation.

4. Monitor time sync status and generate alerts on drift or sync failures.

5. Periodically verify time configurations as part of system audits and baseline checks.

[All Actors]

1. Synchronize every system, service, container and device with a trusted, authenticated time source (e.g., NTP, the cloud-provider time service, etc.).

2. Configure at least one fallback time source and generate alerts when drift or sync failure exceeds the defined threshold.

3. Continuously monitor time-sync health; log and raise incidents for repeated drift, spoofing attempts or source unreachability.

4. Record and review time-sync settings in configuration management; verify them at least annually or after architecture changes.

5. Enforce consistent timestamp zones and formats across all logs to support correlation, forensics and auditability.

From CCM v4.1: Control Ownership Rationale. The CSP should be responsible for synchronizing the system clocks across the cloud infrastructure and systems to ensure that the sequence of events can be properly reconstructed across the systems.

Implementation Guidelines. Applicable to all service models: The audit log generation mechanisms should be synchronized on all systems by using the Network Time Protocol (NTP) in order to capture the date and time stamp of each event that is recorded in the log files. if system logs are not properly synced then there will be differences in the clock settings across systems and infrastructure, the date and time stamps of the activities will not match, as they would have happened in the real time, so those logs would not be beneficial in a security incident investigation or would not be permissible as evidence.

The following guidelines should be applied:

• a. Centralized Time Service:

  • i. A centralized time service should be created and maintained to provide clock synchronization to all assets and systems on their bootup, start, or restart

  • ii. Adhere to industry standards for time synchronization, such as RFC 5905 for Network Time Protocol (NTP) to ensure compatibility and interoperability with various systems and to serve as centralized and reliable time source

• b. Regular Clock Synchronization:

  • i. All servers within the cloud environment should be regularly synchronized with centralized NTP servers to maintain consistency across the infrastructure

  • ii. A clock synchronization service should be provided that the CSC can consume to synchronize its hosted assets

• c. Systems Configuration: A process should be created to ensure all assets and systems are configured to obtain the time for clock synchronization from the centralized service

• d. Clock Settings Integrity: Authentication mechanisms should be implemented to prevent unauthorized access or tampering with time information and to protect the integrity of the time synchronization process

• e. Sync Monitoring and Alerting:

  • i. Monitoring systems should be set up to detect any deviations or discrepancies in time synchronization

  • ii. Alerting mechanisms should be in place to notify relevant stakeholders (e.g., administrators, CSCs) of any time synchronization issues

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.

Shared Implementation Guidelines

[All Actors]

1. Document a definitive list of events to log such as authentication/authorization, configuration changes, data-access, errors, admin actions, security alerts, model-lifecycle events, and third-party API calls.

2. Include essential metadata (timestamp, user/service identity, source IP, resource, action, result code, request ID) to enable correlation, investigation and audit.

3. Align the logging scope with business, regulatory and threat-detection needs.

4. Apply masking or tokenization, or pseudonymization techniques, when collecting sensitive data.

5. Maintain consistent log formats and schemas so that analytics tools, SIEM and forensic workflows can parse events across all environments.

6. Review and update the documented scope on a regular basis or whenever architecture, regulation or threat intelligence changes.

Implementation Guidelines for Cloud Service Providers (CSP)

1. Define and document the types of system events, metadata, and security-related actions to be logged (e.g., authentication, privilege changes, data access, API calls).

2. Ensure coverage across all layers: compute, storage, network, control plane, and management interfaces.

3. Align logging scope with compliance, threat detection, and forensic investigation needs.

4. Review and update the logging scope at least annually or when there are significant architectural or threat changes.

5. Maintain consistency in log formats to support effective analysis and correlation.

[All Actors]

1. Document a definitive list of events to log such as authentication/authorization, configuration changes, data-access, errors, admin actions, security alerts, model-lifecycle events, and third-party API calls.

2. Include essential metadata (timestamp, user/service identity, source IP, resource, action, result code, request ID) to enable correlation, investigation and audit.

3. Align the logging scope with business, regulatory and threat-detection needs.

4. Apply masking or tokenization, or pseudonymization techniques, when collecting sensitive data.

5. Maintain consistent log formats and schemas so that analytics tools, SIEM and forensic workflows can parse events across all environments.

6. Review and update the documented scope on a regular basis or whenever architecture, regulation or threat intelligence changes.

From CCM v4.1: Control Ownership Rationale. The determination for this control objective remains the same regardless of the cloud architecture adoption. This control is shared between the CSC and the CSP. The control implementations however are Independent from each other. Both entities may have different logging and monitoring standards to capture events within their ecosystem with respect to their countries and contractual or regulatory requirements.

Implementation Guidelines. Applicable to all service models: The CSP should have its own directory of system event classifications that require logging. Events meeting those classifications should be logged with necessary details in order to meet the specific requirements that are defined within contractual, legal, or regulatory frameworks. The CSP should log the activity of its internal systems and also the systems it provides to the CSC.

The event type metadata should include everything that is needed to answer the ‘Who’, ‘What’, ‘When’, ‘Where’ and ‘Why’ and any additional details relevant to the respective event type.

Events that should be captured in logs include (but not be limited to):

• a. Authentication and Identity Events:

  • i. Successful and failed login attempts to cloud services (e.g., Username and password login, failed SSH key login, SMS code, authenticator app, type of biometric)

  • ii. User account creations, modifications, and deletions within the cloud IAM system (in particular of accounts with administrative privileges)

  • iii. Identity federation and de-federation activities

  • iv. Activities by privileged users (e.g., Administrator logins and activities)

• b. Authorization and Access Control:

  • i. Changes to access control policies in cloud services

  • ii. Instances of unauthorized access or attempted access to cloud resources and/or sensitive data

  • iii. Modifications to security groups and firewall rules

• c. Resource Provisioning and Deprovisioning:

  • i. Creation, modification, or deletion of cloud resources (e.g., VM instances, storage buckets)

  • ii. Autoscaling events and adjustments to resource allocations

  • iii. API calls related to resource provisioning and management

  • iv. Reboot of critical assets

• d. Cloud Network Events:

  • i. Changes to virtual network rules/configurations, subnets, and routes

  • ii. Detection of suspicious network activities within the cloud environment (IDS/IPS alerting events)

  • iii. Network traffic anomalies and potential security incidents

• e. Cloud Storage Events:

  • i. File or data access, modifications, deletions, or copies within cloud storage

  • ii. Changes to storage configurations and permissions

  • iii. Alerts for unusual or unauthorized data movements

• f. Cloud Service API Calls:

  • i. API calls related to cloud service usage, including infrastructure-as-code deployments (e.g., API key/token used)

  • ii. Changes to API authentication and authorization settings

  • iii. Monitoring for unusual or unexpected API activities

• g. Cloud Security Group Events:

  • i. Changes to security group rules and configurations

  • ii. Instances of denied or allowed traffic based on security group policies

  • iii. Anomalies in security group activities

• h. Audit Logging and Compliance Events:

  • i. Audit log reviews and compliance checks within the cloud environment and security best practices

  • ii. Alerts for non-compliance with industry or regulatory standards i. Container and Orchestration Events: i. Container deployment and scaling events in container orchestration platforms (e.g., Kubernetes) ii. Changes to container configurations and images

  • iii. Container runtime security events

• i. Serverless Computing Events:

  • i. Events related to serverless function invocations and executions

  • ii. Changes to serverless function configurations

  • iii. Monitoring for unusual or suspicious serverless activities

• j. Cloud-Based Firewall and WAF Events:

  • i. Changes to cloud-based firewall rules and configurations

  • ii. Detection of web application firewall (WAF) events and alerts

  • iii. Anomalies in traffic patterns indicating potential security threats

• k. Cloud-Based DDoS Protection Events:

  • i. Alerts and events related to distributed denial-of-service (DDoS) attacks

  • ii. Changes to DDoS protection configurations and thresholds

  • iii. Mitigation actions taken in response to DDoS attacks

• l. Cloud Compliance Assessment Events:

  • i. Events related to the assessment and scanning of cloud resources for vulnerabilities

  • ii. Alerts for compliance violations and recommended remediation actions

  • iii. Continuous monitoring for changes impacting compliance posture

• m. Cloud Incident Response Events:

  • i. Events and alerts generated during incident response activities in the cloud environment

  • ii. Logs related to investigation, containment, eradication, and recovery efforts

  • iii. Documentation of actions taken to address security incidents in the cloud

The event type classifications should be reviewed at least annually or when there are significant changes to the threat landscape.

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.

Shared Implementation Guidelines

[All Actors]

1. Define and document categories of sensitive data requiring sanitization in logs, including PII, credentials, API keys, session tokens, and confidential business data, as well as AI-specific data: user prompts, model responses, embedding vectors, fine-tuning datasets, model decision metadata, etc. Align this with applicable privacy regulations (GDPR, CCPA, HIPAA, PCI-DSS, EU AI Act) and customer contractual obligations.

2. Implement automated detection mechanisms to identify sensitive data patterns in logs before persistence, using techniques such as regular expressions, pattern matching, data classification tags, named entity recognition (NER), or data loss prevention (DLP) tools.

3. Apply appropriate sanitization techniques (redaction, scrubbing, tokenization, hashing, encryption) to each sensitive data category, with clear justification for technique selection based on retention requirements, investigation needs, and regulatory compliance.

4. Implement sanitization at appropriate pipeline stages (application logging libraries, log collection agents, centralized logging platforms, API gateways) to ensure sensitive data is sanitized before storage, transmission, or third-party sharing.

5. Test sanitization effectiveness regularly using synthetic sensitive data injection scenarios, automated validation, and periodic manual log reviews to detect sanitization bypasses or failures.

6. Establish incident response procedures for sanitization failures, including escalation paths, log quarantine procedures, notification requirements, and remediation timelines.

7. Implement strict access controls and audit trails for any systems storing unsanitized logs or tokenization reversal mappings, with privileged access management and complete logging of all access to sensitive data.

8. Review and update sensitive data categories and sanitization rules annually or when architecture, regulations, threat intelligence, or service features change, and maintain version-controlled documentation.

Implementation Guidelines for Cloud Service Providers (CSP)

1. Define sanitization requirements for cloud infrastructure logs, including customer account credentials, instance metadata containing secrets, database connection strings, storage object keys, network traffic patterns, customer resource identifiers, and billing/usage data revealing consumption patterns.

2. Implement cross-tenant isolation in sanitized logs to ensure one customer’s resource identifiers, workload patterns, or configuration data cannot be exposed to another customer or revealed through aggregated analytics.

3. Configure cloud services logging as applicable including hypervisor logging, compute service logging, storage access logging, network flow logging, and database audit logging to sanitize customer-specific sensitive data before log persistence or customer-accessible log streams.

4. Establish policies and technical controls preventing use of customer log data for CSP service improvement, performance optimization, or analytics without explicit customer consent and documented authorization.

5. Test sanitization effectiveness across cloud service scenarios, including compute instance logs with customer metadata, storage access patterns, network traffic, and database queries.

6. Review and update sanitization rules when launching new cloud services, making infrastructure changes, or addressing identified privacy risks such as cross-tenant correlation attacks.

[All Actors]

1. Define and document categories of sensitive data requiring sanitization in logs, including PII, credentials, API keys, session tokens, and confidential business data, as well as AI-specific data: user prompts, model responses, embedding vectors, fine-tuning datasets, model decision metadata, etc. Align this with applicable privacy regulations (GDPR, CCPA, HIPAA, PCI-DSS, EU AI Act) and customer contractual obligations.

2. Implement automated detection mechanisms to identify sensitive data patterns in logs before persistence, using techniques such as regular expressions, pattern matching, data classification tags, named entity recognition (NER), or data loss prevention (DLP) tools.

3. Apply appropriate sanitization techniques (redaction, scrubbing, tokenization, hashing, encryption) to each sensitive data category, with clear justification for technique selection based on retention requirements, investigation needs, and regulatory compliance.

4. Implement sanitization at appropriate pipeline stages (application logging libraries, log collection agents, centralized logging platforms, API gateways) to ensure sensitive data is sanitized before storage, transmission, or third-party sharing.

5. Test sanitization effectiveness regularly using synthetic sensitive data injection scenarios, automated validation, and periodic manual log reviews to detect sanitization bypasses or failures.

6. Establish incident response procedures for sanitization failures, including escalation paths, log quarantine procedures, notification requirements, and remediation timelines.

7. Implement strict access controls and audit trails for any systems storing unsanitized logs or tokenization reversal mappings, with privileged access management and complete logging of all access to sensitive data.

8. Review and update sensitive data categories and sanitization rules annually or when architecture, regulations, threat intelligence, or service features change, and maintain version-controlled documentation.

CCM v4.1: Control Ownership Rationale. This control’s implementation responsibility is shared between the CSP and CSC, with a dependency between the two parties. The dependency exists because the CSC’s ability to detect and scrub sensitive data from logs is contingent upon the CSP providing the necessary technical measures, tools, APIs, and access. The CSP is responsible for developing and offering the sanitization capabilities, while the CSC is responsible for defining what data is sensitive according to its specific use case and regulatory requirements, and for configuring and utilizing the tools provided by the CSP.

Implementation Guidelines. Applicable to all service models: The CSP should provide architecture and enable functionality for audit log sanitization, which includes (but not limited to):

• a. Data Detection and Classification Mechanisms: Implement and offer tools and functionality that can automatically detect sensitive data within log streams and log files, such as Personally Identifiable Information (PII), financial data, Protected Health Information (PHI), and other data types defined by laws and regulations (e.g., GDPR, HIPAA)

  • i. The detection mechanism should utilize pattern matching (e.g., regex for social security or credit card numbers), keyword lists, and/or machine learning algorithms to identify both structured and unstructured sensitive data

• b. Sanitization and Masking Techniques: Provide a range of data sanitization techniques, including redaction, masking, and tokenization

  • i. Ensure these techniques are applied in a manner that minimizes operational impact

• c. CSC Enablement and Configurability: The sanitization measures should be configurable by the CSC

  • i. Enable CSCs to apply different sanitization policies based on log source, data classification, or environment (e.g. production vs. development)

  • ii. Provide APIs or management console settings that allow CSCs to define and manage custom detection patterns, sensitivity labeling, rules, and sanitization policies

• d. Preservation of Original Logs: In adherence with the protection principles outlined in LOG-02, implement a mechanism to securely store the original, unaltered logs in a highly restricted, tamper-evident environment (e.g., immutable storage). Access to these forensic-quality logs must be strictly limited to authorized personnel on a need-to-know basis for legal or investigative purposes, with all access attempts logged and audited

• e. Auditing and Reporting: Generate report or audit trails of sanitization activities, detail what data was detected, scrubbed, when, and based on which policy

• f. Documentation: Provide clear documentation to the CSC on how to use the sanitization tools, their capabilities and limitations as part of the shared security implementation responsibility

LOG-09: Log Records

Control Specification

Generate audit records containing relevant security information.

Shared Implementation Guidelines

[All Actors]

1. Comprehensive AI Lifecycle Logging: Log key events from data ingestion and preprocessing through model training, validation, and inference. Capture relevant metadata (e.g., model versions, data sources, hyperparameters) and link operations to specific users or system events. Include performance metrics (accuracy, loss, latency) and model health indicators (drift detection, anomalies).

2. Automated Monitoring and Incident Management: Deploy real-time analysis and alerting on AI-related logs to detect unusual patterns (e.g., abnormal inference requests, unauthorized model changes). Define incident response procedures for escalations, involving both internal teams and external service providers as necessary.

3. Secure Log Handling and Retention: Encrypt log data at rest and in transit, applying integrity checks to prevent tampering. Use role-based access controls for log review and analysis, and define retention periods that satisfy policy and regulatory requirements.

4. Regular Configuration Reviews: Periodically update logging schemas, retention rules, and alert thresholds to address new AI features, data types, or compliance mandates. Involve stakeholders (security, compliance, engineering) in these reviews to ensure comprehensive coverage.

Implementation Guidelines for Cloud Service Providers (CSP)

[All Actors]

1. Comprehensive AI Lifecycle Logging: Log key events from data ingestion and preprocessing through model training, validation, and inference. Capture relevant metadata (e.g., model versions, data sources, hyperparameters) and link operations to specific users or system events. Include performance metrics (accuracy, loss, latency) and model health indicators (drift detection, anomalies).

2. Automated Monitoring and Incident Management: Deploy real-time analysis and alerting on AI-related logs to detect unusual patterns (e.g., abnormal inference requests, unauthorized model changes). Define incident response procedures for escalations, involving both internal teams and external service providers as necessary.

3. Secure Log Handling and Retention: Encrypt log data at rest and in transit, applying integrity checks to prevent tampering. Use role-based access controls for log review and analysis, and define retention periods that satisfy policy and regulatory requirements.

4. Regular Configuration Reviews: Periodically update logging schemas, retention rules, and alert thresholds to address new AI features, data types, or compliance mandates. Involve stakeholders (security, compliance, engineering) in these reviews to ensure comprehensive coverage.

The CSP should maintain the audit log of security events. The CSP should make provision to log the activity of its internal systems and also the systems it provides to CSCs, and every audit record should have the associated user identity.

Security relevant log information should include (but not be limited to):

• a. LOG Security Information:

  • i. event type

  • ii. event id

  • iii. event index

  • iv. event level

• b. event time generated (time when event was generated) vi. event time recorded (time when event was recorded) vii. event description viii. event location ix. event source

• c. event outcome xi. identities of users or systems associated with the event.

LOG-10: Audit Records Protection

Control Specification

Protect audit records from unauthorized access, modification, and deletion.

Shared Implementation Guidelines

[All Actors]

1. Secure Logging Mechanisms: Implement robust access control and encryption (at rest and in transit) for AI related logs covering training, validation and inference. Capture relevant metadata such as model versions, data sources, input parameters, and system events to facilitate in-depth oversight.

2. Immutable and Tamper-Evident Storage: Store logs in an immutable, tamper-evident repository to protect against unauthorized modification or deletion. Employ cryptographic integrity checks or other mechanisms that enable prompt detection of log tampering.

3. Integration with Security Monitoring: Correlate AI logs with broader security monitoring systems to detect anomalies (e.g., unexpected inference spikes, unapproved dataset uploads). Define workflows to escalate suspicious events for investigation and remediation.

4. Privacy-Preserving Practices: Apply techniques like pseudonymization or data minimization to reduce exposure of sensitive information within AI logs. Align log retention periods and handling with applicable data protection requirements.

5. Regular Review and Alerting: Conduct scheduled reviews of AI logs for unauthorized model changes, suspicious hyperparameter modifications, or attempts to bypass controls. Configure automated alerts to notify incident response teams of critical events (e.g., potential model tampering, unauthorized data access).

Implementation Guidelines for Cloud Service Providers (CSP)

[All Actors]

1. Secure Logging Mechanisms: Implement robust access control and encryption (at rest and in transit) for AI related logs covering training, validation and inference. Capture relevant metadata such as model versions, data sources, input parameters, and system events to facilitate in-depth oversight.

2. Immutable and Tamper-Evident Storage: Store logs in an immutable, tamper-evident repository to protect against unauthorized modification or deletion. Employ cryptographic integrity checks or other mechanisms that enable prompt detection of log tampering.

3. Integration with Security Monitoring: Correlate AI logs with broader security monitoring systems to detect anomalies (e.g., unexpected inference spikes, unapproved dataset uploads). Define workflows to escalate suspicious events for investigation and remediation.

4. Privacy-Preserving Practices: Apply techniques like pseudonymization or data minimization to reduce exposure of sensitive information within AI logs. Align log retention periods and handling with applicable data protection requirements.

5. Regular Review and Alerting: Conduct scheduled reviews of AI logs for unauthorized model changes, suspicious hyperparameter modifications, or attempts to bypass controls. Configure automated alerts to notify incident response teams of critical events (e.g., potential model tampering, unauthorized data access).

The CSP should protect the audit logs according to the following guidelines:

• a. Access Control:

  • i. Strict access control mechanisms should be implemented to restrict access to log data (e.g., RBAC, MFA, SoD, PoLP with read-only access)

  • ii. Access for privileged users with access to log data should be periodically reviewed and revalidated

  • iii. Write/delete access requests to the logging process should require approval from senior management

• b. Log Encryption:

  • i. Log data should be encrypted both at rest and in transit using strong encryption algorithms according to stringent industry standards and regularly updated encryption keys

  • ii. Secure channels (i.e., encrypted connections) should be used when transmitting audit log data to external storage or analysis tools

• c. Log Tamper-Proofing: Mechanisms should be implemented to prevent unauthorized modification or deletion of log data (e..g, using digital signatures, tamper-proof logs, or immutable log storage solutions)

• d. Log Storage Isolation: Store logs in a secure and isolated environment, separate from production systems to prevent unauthorized access and data tampering

• e. Log Monitoring and Alerting: An audit trail mechanism to track all access attempts to log management systems and log storage locations should be implemented (including successful and failed attempts), continuously monitored and audited

• f. Log Systems Vulnerability Management and Patching: Vulnerabilities in log storage and management systems should be regularly scanned and patched

All the audit log changes or deletions should be recorded separately in another read-only change tracker.

The audit log change tracker should include (but not be limited to):

• a. change type (change or deletion)

• b. change time (date and time stamp)

• c. change location (page number, line number)

• d. change reason (pre published catalog of reasons that permit changes to the audit log)

• e. change status (success or failure)

• f. identities of any individuals or systems associated with the change. It should include at least the below source attributes:

  • i. Hostname

  • ii. IP Address

  • iii. MAC address

  • iv. service account identity

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.

Shared Implementation Guidelines

[All Actors]

1. AI Data Encryption Compliance: Collaborate with relevant stakeholders to ensure that AI datasets (training data, inference inputs, outputs) are encrypted in transit and at rest.

2. Policy Alignment and Key Ownership: Document cryptographic policies dictating AI data handling, including data classification, key ownership, and approved encryption methods. Specify reporting channels for incidents or deviations from established cryptographic standards.

3. Access Control and Key Management: Enforce strict role-based permissions to limit access to cryptographic keys for AI workloads (e.g., training, testing, production). Integrate automated key lifecycle management (generation, rotation, retirement) aligned with AI model stages, logging all key-related events.

4. Monitoring and Reporting: Log and audit all cryptographic operations associated with AI data (encryption/decryption events, certificate usage, key access). Implement real-time dashboards or alerts to visualize encryption status and flag anomalies (e.g., unauthorized key usage, suspicious access patterns).

5. Model Integrity and Output Verification: Incorporate checks during AI inference to confirm model outputs have not been tampered with. Automate alerts that notify security teams when cryptographic inconsistencies or anomalies are detected in AI pipelines.

6. Secure Logging and Retention: Store cryptographic logs (key usage, encryption events) in encrypted form with defined retention policies suitable for AI data and model parameters. Use role-based access to restrict who can view or modify these logs, preventing unauthorized disclosure or tampering.

Implementation Guidelines for Cloud Service Providers (CSP)

[All Actors]

1. AI Data Encryption Compliance: Collaborate with relevant stakeholders to ensure that AI datasets (training data, inference inputs, outputs) are encrypted in transit and at rest.

2. Policy Alignment and Key Ownership: Document cryptographic policies dictating AI data handling, including data classification, key ownership, and approved encryption methods. Specify reporting channels for incidents or deviations from established cryptographic standards.

3. Access Control and Key Management: Enforce strict role-based permissions to limit access to cryptographic keys for AI workloads (e.g., training, testing, production). Integrate automated key lifecycle management (generation, rotation, retirement) aligned with AI model stages, logging all key-related events.

4. Monitoring and Reporting: Log and audit all cryptographic operations associated with AI data (encryption/decryption events, certificate usage, key access). Implement real-time dashboards or alerts to visualize encryption status and flag anomalies (e.g., unauthorized key usage, suspicious access patterns).

5. Model Integrity and Output Verification: Incorporate checks during AI inference to confirm model outputs have not been tampered with. Automate alerts that notify security teams when cryptographic inconsistencies or anomalies are detected in AI pipelines.

6. Secure Logging and Retention: Store cryptographic logs (key usage, encryption events) in encrypted form with defined retention policies suitable for AI data and model parameters. Use role-based access to restrict who can view or modify these logs, preventing unauthorized disclosure or tampering.

From CCM v4.1: Control Ownership Rationale. The CSP and CSC are responsible for independently implementing an internal monitoring and reporting process over cryptographic operations. Although the CSP is responsible for implementing the encryption protocol, it is the responsibility of the CSC to monitor and test proper use of cryptographic operations on their portion of their shared cloud infrastructure (refer to the CEK domain for more details on policies, processes, and controls for cryptography).

Implementation Guidelines. Applicable to all service models: The use of cryptography to protect sensitive data from unauthorized disclosure or tampering (while in transit or at rest) needs to be governed through a well defined set of policies, standards, and procedures (refer to CEK-01 for details). The use of encryption keys should be monitored and any deviations should be reported and handled as per the policies.

Cryptographic operations should be logged, monitored, and reported to ensure any unauthorized key usage event is escalated via security incident management process and remediated.

The log data should be protected from unauthorized tampering by implementing various solutions that protect the file integrity.

Implementation best practices for CSPs to establish and maintain effective monitoring and internal reporting capabilities for encryption and key management include (but not limited to):

• a. Monitor Key Encryption and Management Systems:

  • i. The critical cloud components in the cloud infrastructure where encryption and key management activities occur should be identified (e.g., endpoints, data centers, storage systems, network devices, and key management servers).

  • ii. Continuous monitoring should be implemented to track key generation, encryption/decryption operations, key rotation events, and access attempts

• b. Logs and Event Data Analysis:

  • i. Log collection and analysis tools should be implemented to capture relevant data related to encryption and key management activities

  • ii. Collected logs should be analyzed to identify anomalies, suspicious activities, and potential security threats

  • iii. Consider the integration of encryption and key management monitoring data into SIEM systems allowing for centralized aggregation, correlation, and analysis

• c. Baselines and Thresholds: Baselines and thresholds for normal encryption and key management operations should be established (e.g., key usage, access patterns, and error rates)

• d. Alerting and Reporting Mechanisms:

  • i. Alerting and reporting mechanisms should be implemented to notify security teams of activities that deviate from established baselines or exceed defined thresholds

  • ii. Regular reports should be generated summarizing encryption and key management activities (including trends, anomalies, and potential risks)

  • iii. Reports should be shared with stakeholders, including security teams, compliance officers, and CSC to foster transparency and accountability

• e. Monitoring Process Review:

  • i. Monitoring processes of cryptographic operations should be regularly reviewed to ensure they remain effective in detecting and addressing security threats

  • ii. Alert triggers on cryptography relevant events should be reviewed, historical data analyzed, and feedback from security incidents incorporated to refine the monitoring processes

LOG-12: Transaction/Activity Logging

Control Specification

Log and monitor key lifecycle management events to enable auditing and reporting on usage of cryptographic keys.

Shared Implementation Guidelines

[All Actors]

1. Dedicated Logging Framework for Cryptographic Events: Implement a logging framework that records key lifecycle management operations (e.g., generation, rotation, revocation). Include relevant AI model usage events (e.g., data ingestion, inference requests, hyperparameter changes) to correlate cryptographic key actions with AI workflows.

2. Centralized Log Management and Access Controls: Store cryptographic key logs and AI-related logs in a centralized, secure system. Enforce strong authentication and granular, role-based permissions to ensure only authorized personnel can view or modify logs.

3. Continuous Monitoring and Alerting: Use real-time analytics and alerting to detect suspicious key usage (e.g., unexpected key rotations, unauthorized decryption attempts) and abnormal AI model behavior (e.g., large-scale inference spikes). Define escalation paths for key-related incidents, linking them to AI incident response processes where appropriate.

4. Lifecycle Traceability and Auditing: Maintain comprehensive records of key usage, model updates, and data changes for complete traceability. Periodically review logs for anomalies, errors, or policy violations, and ensure logs are retained according to data classification and regulatory requirements.

5. Incident Response and Reporting: Define a collaborative incident management process among internal teams and service providers to investigate cryptographic or AI-related security incidents. Clearly assign incident ownership, notification protocols, and root cause analysis responsibilities.

Implementation Guidelines for Cloud Service Providers (CSP)

[All Actors]

1. Dedicated Logging Framework for Cryptographic Events: Implement a logging framework that records key lifecycle management operations (e.g., generation, rotation, revocation). Include relevant AI model usage events (e.g., data ingestion, inference requests, hyperparameter changes) to correlate cryptographic key actions with AI workflows.

2. Centralized Log Management and Access Controls: Store cryptographic key logs and AI-related logs in a centralized, secure system. Enforce strong authentication and granular, role-based permissions to ensure only authorized personnel can view or modify logs.

3. Continuous Monitoring and Alerting: Use real-time analytics and alerting to detect suspicious key usage (e.g., unexpected key rotations, unauthorized decryption attempts) and abnormal AI model behavior (e.g., large-scale inference spikes). Define escalation paths for key-related incidents, linking them to AI incident response processes where appropriate.

4. Lifecycle Traceability and Auditing: Maintain comprehensive records of key usage, model updates, and data changes for complete traceability. Periodically review logs for anomalies, errors, or policy violations, and ensure logs are retained according to data classification and regulatory requirements.

5. Incident Response and Reporting: Define a collaborative incident management process among internal teams and service providers to investigate cryptographic or AI-related security incidents. Clearly assign incident ownership, notification protocols, and root cause analysis responsibilities.

From CCM v4.1: Control Ownership Rationale. The implementation responsibility for this control is shared by both the CSP and the CSP, independently by each. Encryption techniques as per the organization policies and procedures should be used to preserve the confidentiality and integrity of sensitive data. The use of encryption keys should be monitored and reported.

Implementation Guidelines. Applicable to all service models: CSPs can effectively audit and report on key usage, enabling proactive identification and remediation of potential security risks. The CSP should ensure monitoring and reporting exists for encryption key lifecycle events (refer to CEK domain), including but not limited to:

• a. KMS Logs: KMS logs and metrics should be integrated with a centralized log management system to allow for consolidation of logging data from various cloud services, enabling comprehensive auditing and reporting

• b. Key Management Service (KMS) Logs and Metrics:

  • i. The built-in logging and monitoring capabilities of the CSP’s KMS service should be leveraged for logging of KMS events, thus capturing keys: • generation

    • distribution

    • access

    • usage (encryption, decryption, digital signing)

    • revocation

    • expiry

    • rotation

    • deletion

  • ii. KMS-based metrics should be established and if possible automated to track key performance metrics and identify potential usage anomalies

• c. Key Logs Access Control: Only authorized personnel should have access to key materials, and all access attempts should be logged and reviewed

• d. Storage and Archiving Configuration: Retention requirements for KMS logs and metrics should be identified

• e. Continuous Monitoring and Evaluation:

  • i. Logging and monitoring requirements for cryptographic keys, should be defined outlining the specific events to be captured, retention periods, and access controls

  • ii. Alerts should be raised for unauthorized, anomalous or suspicious key lifecycle events

  • iii. The effectiveness of the implemented logging and monitoring practices should be regularly reviewed and evaluated

• f. Audit Log Data Reviews: Regular reviews of log data should be conducted to identify potential anomalies, suspicious activities, or usage patterns that deviate from established norms. This proactive approach helps to detect and address emerging security risks promptly

• g. Reporting Mechanisms:

  • i. Standard reporting mechanisms should be developed to extract meaningful insights from KMS log and metric data

  • ii. CSP should provide actionable reports to relevant stakeholders, including CSCs, audit committees and security teams

LOG-13: Access Control Logs

Control Specification

Monitor and log physical access using an auditable access control system.

Shared Implementation Guidelines

[All Actors]

1. Physical Access Control Integration: Use auditable access control systems (e.g., smart badges, biometrics) to monitor entry points where AI-related infrastructure or data is hosted. Synchronize physical access events with logical access logs for comprehensive visibility.

2. Centralized Logging and Monitoring: Collect and analyze logs from both physical entry systems and AI-specific events (model training, inference requests) in a unified monitoring environment. Enable real-time detection of anomalies by correlating physical entry with system activities.

3. Logging Security and Retention: Store physical access logs and AI event logs in an encrypted, access-controlled repository. Enforce defined retention periods based on regulatory requirements and organizational policies. Protect logs from tampering with immutability checks or other integrity mechanisms.

4. Automated Alerts and Anomaly Detection: Implement rule-based or AI-driven analytics to detect unusual patterns (e.g., after-hours facility entry followed by large-scale data transfers). Configure automated alerts to escalate suspicious activity to incident response teams.

5. Incident Response and Collaboration: Document clear escalation paths for AI-related security incidents involving physical intrusions. Share relevant logs and coordinate investigations across internal teams and external AI service providers to ensure swift remediation.

6. Regular Reviews and Continuous Improvement: Schedule periodic reviews that reconcile provider-side logs with consumer-side records, identifying discrepancies in physical or system access. Update log requirements, retention policies, and incident response playbooks in line with new AI use cases or emerging threats.

Implementation Guidelines for Cloud Service Providers (CSP)

[All Actors]

1. Physical Access Control Integration: Use auditable access control systems (e.g., smart badges, biometrics) to monitor entry points where AI-related infrastructure or data is hosted. Synchronize physical access events with logical access logs for comprehensive visibility.

2. Centralized Logging and Monitoring: Collect and analyze logs from both physical entry systems and AI-specific events (model training, inference requests) in a unified monitoring environment. Enable real-time detection of anomalies by correlating physical entry with system activities.

3. Logging Security and Retention: Store physical access logs and AI event logs in an encrypted, access-controlled repository. Enforce defined retention periods based on regulatory requirements and organizational policies. Protect logs from tampering with immutability checks or other integrity mechanisms.

4. Automated Alerts and Anomaly Detection: Implement rule-based or AI-driven analytics to detect unusual patterns (e.g., after-hours facility entry followed by large-scale data transfers). Configure automated alerts to escalate suspicious activity to incident response teams.

5. Incident Response and Collaboration: Document clear escalation paths for AI-related security incidents involving physical intrusions. Share relevant logs and coordinate investigations across internal teams and external AI service providers to ensure swift remediation.

6. Regular Reviews and Continuous Improvement: Schedule periodic reviews that reconcile provider-side logs with consumer-side records, identifying discrepancies in physical or system access. Update log requirements, retention policies, and incident response playbooks in line with new AI use cases or emerging threats.

From CCM v4.1: Control Ownership Rationale. The implementation responsibility for this control belongs exclusively to the CSP, since the CSP is the party managing the security of the physical infrastructure. It is therefore responsible for monitoring and logging physical access to it.

Implementation Guidelines. Applicable to all service models: Implementation best practices for CSPs to effectively monitor and log physical access using an auditable access control system include (but not limited to):

• a. Access Control Systems Implementation:

  • i. Physical access control systems should be deployed at all physical entry points, including doors, gates, and controlled areas.

  • ii. Biometric authentication methods should be utilized like fingerprint scanning, facial recognition, or iris recognition for enhanced security

  • iii. Access should be restricted to authorized personnel based on their job functions and responsibilities and should be revoked immediately upon termination. All physical access mechanisms (e.g., keys, access cards) should be returned and/or disabled

  • iv. Access to publicly accessible network jacks should be restricted (e.g., limit physical access to unused ports, wireless access points, gateways, handheld devices, networking/communications hardware, and telecommunication lines)

• b. Access Control Credentials:

  • i. Electronic access control cards or badges should be issued to authorized personnel and integrated with card readers for secure access authorization

  • ii. Track card usage and log card swipe events for accountability and auditing purposes

• c. Video Surveillance Monitoring:

  • i. High-quality security cameras should be installed at all critical areas (e.g., entry points, data centers, and server rooms). Continuous video recording with clear images and sound for detailed monitoring should be used.

  • ii. Recorded footage should be securely stored for potential investigations and forensic analysis

• d. Audit Log Management:

  • i. An audit log management system to capture and store all physical access control events should be implemented (e.g., logs from access control cards, ACPs, and video surveillance systems)

  • ii. Access control logs should be reviewed at least on bi-annual basis or as per relevant laws and regulations requirements

  • iii. Log data should be collected and correlated with other log entries, and stored for at least three months unless otherwise restricted by data retention laws

• e. Visitor Management Systems:

  • i. A visitor management system should be implemented to identify, track and regulate visitor access.

  • ii. Visitors should be escorted and required to register their information, including identification, purpose of visit, and contact details

  • iii. Procedures should be developed for identifying between onsite personnel and visitors (e.g., assigned distinct badges), and for revoking or terminating onsite personnel and expired visitor identification

• f. Authentication and Authorization Mechanisms:

  • i. Multi-factor authentication (MFA) should be employed for all physical access, combining biometrics, access cards, and additional verification methods

  • ii. Access should be restricted to authorized personnel only, verifying their identity and eligibility for specific areas or resources

• g. Monitor and Audit Access Control Systems:

  • i. A real-time monitoring and auditing should be implemented for all physical access control events. Set up automated alerts for anomalous or unauthorized access attempts

  • ii. Access logs and incident reports should be regularly reviewed to identify recurring patterns or potential security risks

  • iii. Security audits should be periodically conducted to assess the effectiveness of access control measures and identify areas for improvement

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.

Shared Implementation Guidelines

[All Actors]

1. Define AI-Specific Anomaly Criteria and Thresholds: Collaborate to set clear criteria for AI anomalies (e.g., performance drops, data drift, out-of-distribution inputs). Configure anomaly thresholds aligned with risk appetite, business requirements, and changing data conditions.

2. Adaptive Thresholding and Diagnostics: Employ adaptive thresholds to account for evolving data distributions and model behaviors. Integrate diagnostic tools that automatically analyze logs, performance metrics, and metadata to identify likely causes of detected anomalies.

3. Continuous Evaluation and Joint Reviews: Conduct regular reviews of model performance and system health with relevant stakeholders. Align on remediation strategies for anomalies driven by consumer-specific data or business logic changes. Update anomaly detection thresholds, response procedures, or backup mechanisms as AI use cases evolve.

4. Oversight of Critical Operations: Monitor high-impact AI functions (e.g., financial approvals, healthcare diagnostics) with real-time alerts and immediate escalation paths. Ensure the system can roll back to stable model versions or activate backup infrastructure to maintain continuity when high-severity anomalies occur.

Implementation Guidelines for Cloud Service Providers (CSP)

[All Actors]

1. Define AI-Specific Anomaly Criteria and Thresholds: Collaborate to set clear criteria for AI anomalies (e.g., performance drops, data drift, out-of-distribution inputs). Configure anomaly thresholds aligned with risk appetite, business requirements, and changing data conditions.

2. Adaptive Thresholding and Diagnostics: Employ adaptive thresholds to account for evolving data distributions and model behaviors. Integrate diagnostic tools that automatically analyze logs, performance metrics, and metadata to identify likely causes of detected anomalies.

3. Continuous Evaluation and Joint Reviews: Conduct regular reviews of model performance and system health with relevant stakeholders. Align on remediation strategies for anomalies driven by consumer-specific data or business logic changes. Update anomaly detection thresholds, response procedures, or backup mechanisms as AI use cases evolve.

4. Oversight of Critical Operations: Monitor high-impact AI functions (e.g., financial approvals, healthcare diagnostics) with real-time alerts and immediate escalation paths. Ensure the system can roll back to stable model versions or activate backup infrastructure to maintain continuity when high-severity anomalies occur.

From CCM v 4.1: Control Ownership Rationale. The determination for this control objective remains the same regardless of the cloud architecture adopted. The control is implemented independently by the CSP and the CSC. The performance of logging process execution should be monitored to ensure the logs and backups are captured and maintained as per policy. Any logging-related failures should be identified and remediated using alternative recovery steps.

Implementation Guidelines. Applicable to all service models: The CSP should define actions to take depending on the type of logging and monitoring failure. Anomalies can include software errors, failures to capture some or all logs, failure to backup audit logs, and storage exceeded notifications. This guidance should apply to all information system logs.

The CSP should implement a process for the timely detection and reporting of failures of critical security control systems, such as (but not limited to):

• a. Monitoring Systems Types:

  • i. Firewalls

  • ii. IDS/IPS

  • iii. File Integrity Monitoring (FIM)

  • iv. Anti-virus Tools

• b. Physical access controls vi. Logical access controls vii. Audit logging mechanisms

Best practices for the detection and reporting of anomalies and failures of the monitoring system include (but not limited to):

• a. Monitoring Baselines and Thresholds:

  • i. Baselines for key performance indicators (KPIs) and metrics should be established to represent monitoring system’s normal behavior and thresholds set to indicate potential anomalies or failures.

  • ii. Thresholds should be tailored to specific cloud services and applications, considering factors like workload patterns, resource utilization, and service level agreements (SLAs)

  • iii. Machine learning algorithms should be utilized to analyze historical data and identify anomalies that may not be captured by traditional thresholding methods

  • iv. Pattern recognition algorithms should be employed to identify deviations from normal system behavior and flag potential anomalies or failures

• b. Logging System Behavior: Logging capabilities should be incorporated within the monitoring system to capture detailed information about system behavior, including timestamps, event types, and error messages

• c. Leverage Event Correlation: Employ event correlation techniques to identify patterns and relationships between logged events

• d. Alerting Mechanisms: Alerting mechanisms should be integrated and automated to trigger notifications to relevant stakeholders when detected anomalies or failures of the monitoring system exceed defined thresholds

• e. Correlation and Aggregation: Correlation and aggregation techniques should be leveraged to identify and analyze patterns in data from multiple sources to identify root causes of anomalies and obtain a more holistic understanding of system health

• f. Event Stream Processing (ESP): ESP technologies should be implemented to process real-time data streams from monitoring systems to achieve a near-instantaneous detection of anomalies and failures, facilitating rapid response and mitigation efforts

• g. Accountable Parties Notification:

  • i. Security professionals or teams responsible for receiving notifications, triaging issues, and taking corrective actions should be identified and notified

  • ii. Third-party notification tools should be integrated to enhance flexibility (e.g., custom incident management systems or chatbots for automated communication)

• h. Automated Response Mechanisms: Response mechanisms should be implemented (and automated where possible) into the monitoring system to initiate remediation actions when anomalies or failures of the monitoring system occur (e.g., restarting services, adjusting resource allocation, triggering rollback or failover mechanisms)

• i. Continuous Monitoring and Evaluation:

  • i. The effectiveness of anomaly and failure reporting processes should be continuously monitored and evaluated.

  • ii. Notification logs, response times, and resolution rates should be regularly reviewed and updated based on lessons learned

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.

Shared Implementation Guidelines

[All Actors]

1. Unified Logging and Monitoring: Capture all inbound requests and metadata (timestamps, source, user ID, model endpoint) for AI model usage. Store logs in a secure, centralized platform with role-based access controls (RBAC) and encryption at rest and in transit. Automate real-time monitoring (SIEM, anomaly detection) for suspicious activity or policy violations.

2. Audit Trails and Reporting: Maintain detailed audit trails (user actions, model inputs) for accountability and compliance. Integrate logs into existing reporting frameworks; schedule periodic reviews to identify unauthorized access or unusual patterns. Enforce retention policies and anonymization practices to protect sensitive data.

3. Access Control and Policy Alignment: Apply RBAC to both log data and AI resources, allowing only authorized personnel to view sensitive input content. Align logging with organizational usage policies (legal, ethical) to ensure captured inputs and metadata meet data governance requirements.

4. Incident Response and Collaboration: Define escalation procedures for AI-specific incidents (e.g., suspicious input patterns, security breaches). Coordinate with external providers or internal teams to share logs and relevant data for prompt investigation and resolution.

5. Continuous Improvement: Regularly refine logging configurations, threshold alerts, and monitoring rules to address evolving AI use cases. Conduct periodic reviews of logged data to spot anomalies and adapt controls as threats or operational needs change.

Implementation Guidelines for Cloud Service Providers (CSP)

[All Actors]

1. Unified Logging and Monitoring: Capture all inbound requests and metadata (timestamps, source, user ID, model endpoint) for AI model usage. Store logs in a secure, centralized platform with role-based access controls (RBAC) and encryption at rest and in transit. Automate real-time monitoring (SIEM, anomaly detection) for suspicious activity or policy violations.

2. Audit Trails and Reporting: Maintain detailed audit trails (user actions, model inputs) for accountability and compliance. Integrate logs into existing reporting frameworks; schedule periodic reviews to identify unauthorized access or unusual patterns. Enforce retention policies and anonymization practices to protect sensitive data.

3. Access Control and Policy Alignment: Apply RBAC to both log data and AI resources, allowing only authorized personnel to view sensitive input content. Align logging with organizational usage policies (legal, ethical) to ensure captured inputs and metadata meet data governance requirements.

4. Incident Response and Collaboration: Define escalation procedures for AI-specific incidents (e.g., suspicious input patterns, security breaches). Coordinate with external providers or internal teams to share logs and relevant data for prompt investigation and resolution.

5. Continuous Improvement: Regularly refine logging configurations, threshold alerts, and monitoring rules to address evolving AI use cases. Conduct periodic reviews of logged data to spot anomalies and adapt controls as threats or operational needs change.

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.

Shared Implementation Guidelines

[All Actors]

1. Comprehensive Output Logging: Capture and store all AI-generated outputs (content and metadata) in structured logs. Include timestamps, user IDs, model versions, and relevant request context for full traceability.

2. Secure Storage and Retention: Encrypt logged data in transit and at rest. Define clear retention and purge policies, ensuring logs remain accessible for compliance or incident investigations.

3. Monitoring and Real-Time Alerts: Implement automated pipelines (e.g., SIEM tools) to analyze AI outputs for anomalies, bias, or disallowed content. Configure alerts for high-risk or unusual output events, escalating them to incident response teams when necessary.

4. Output Validation and Risk Oversight: Periodically review logs and apply additional validation layers for critical or compliance-sensitive use cases (e.g., financial approvals, healthcare insights).

5. Collaboration and Incident Response: Define escalation paths for suspicious or abnormal AI outputs. Coordinate with providers (or other stakeholders) to share logs, investigate root causes, and remediate issues promptly.

6. Audit Trails and Reporting: Maintain detailed audit trails linking outputs to user actions, input data, and model identifiers. Regularly generate usage reports, aligning with regulatory requirements and organizational standards.

Implementation Guidelines for Cloud Service Providers (CSP)

[All Actors]

1. Comprehensive Output Logging: Capture and store all AI-generated outputs (content and metadata) in structured logs. Include timestamps, user IDs, model versions, and relevant request context for full traceability.

2. Secure Storage and Retention: Encrypt logged data in transit and at rest. Define clear retention and purge policies, ensuring logs remain accessible for compliance or incident investigations.

3. Monitoring and Real-Time Alerts: Implement automated pipelines (e.g., SIEM tools) to analyze AI outputs for anomalies, bias, or disallowed content. Configure alerts for high-risk or unusual output events, escalating them to incident response teams when necessary.

4. Output Validation and Risk Oversight: Periodically review logs and apply additional validation layers for critical or compliance-sensitive use cases (e.g., financial approvals, healthcare insights).

5. Collaboration and Incident Response: Define escalation paths for suspicious or abnormal AI outputs. Coordinate with providers (or other stakeholders) to share logs, investigate root causes, and remediate issues promptly.

6. Audit Trails and Reporting: Maintain detailed audit trails linking outputs to user actions, input data, and model identifiers. Regularly generate usage reports, aligning with regulatory requirements and organizational standards.

The CSP should ensure that all outputs from AI models, along with their metadata, are securely logged, monitored, and made available for auditing.

• Capture output events including:   • Output content (where permitted by policy)   • Output metadata (timestamp, model version, output classification/tags)   • Associated request ID and user/service identity

• Encrypt output logs at rest and during transmission.

• Implement retention policies based on regulatory and contractual requirements, with purging processes for obsolete or sensitive outputs.

• Monitor output logs in real-time with alerting systems (e.g., SIEM) to identify anomalies such as biased outputs, sensitive data leaks, or unauthorized use cases.

• Establish mechanisms for linking outputs to specific inputs, model versions, and user actions to ensure traceability.

• Provide audit trails and reporting dashboards for consumer visibility.

• Apply additional scrutiny and validations on outputs related to high-risk AI functions (e.g., finance, healthcare).

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.

Shared Implementation Guidelines

[Shared Responsibilities (Applicable to MP, CSP)]

1. Configuration Management: Secure configurations and credentials with a secrets management tool.

2. Logging and Monitoring: Implement logging, monitoring, and SIEM integration for activity detection.

Implementation Guidelines for Cloud Service Providers (CSP)

[Shared Responsibilities (Applicable to MP, CSP)]

1. Configuration Management: Secure configurations and credentials with a secrets management tool.

2. Logging and Monitoring: Implement logging, monitoring, and SIEM integration for activity detection.

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.

Shared Implementation Guidelines

[Shared Responsibilities (Applicable to MP, AP)]

1. Determine which scanners will be used: Periodically conduct research for which attacks have been proven detectable in model files. Ensure that the scanners used are up to date on these attacks and tested for accuracy.

2. Periodic checks: According to risk, deployed models in production should be scanned periodically, especially if running inference on user data.

3. Documentation: Keep logs of model scan results including scan configuration, model identifier, timestamp, stage of service lifecycle, and results. Collect overall metrics from these logs such as issue detection rate and any errors encountered.

4. Resolution Processes: Determine a response plan for any issues found. For critical issues, this should be immediate model quarantine, stopping it in the development cycle or removing it from production, and launching an investigation. For lower severity issues, this may involve limiting the model deployment scope until the issues are investigated. Applications relying on compromised models can be rolled back to a previous model version determined to have a clean scan.

Implementation Guidelines for Cloud Service Providers (CSP)

1. Ensure the availability of secure and isolated execution environments specifically designed for running model artifact scans, minimizing the risk of data leakage or unauthorized access during the scanning process.

2. Offer highly scalable and reliable compute resources capable of handling the intensive workloads associated with comprehensive model artifact scanning, ensuring performance and efficiency even under high-demand conditions.

3. Provide robust and secure storage solutions for both storing model artifacts and retaining scan results, ensuring data integrity, access control, and compliance with security and privacy requirements.

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.

Shared Implementation Guidelines

[Shared Responsibilities (Applicable to MP, AP)]

1. Review and Approval Process: Organizations should establish a review process involving relevant stakeholders to review the model card and determine approval for use, based on fit and risk level. The review process and decisions made should be documented.

2. Access and Communication: Access controls should be defined for model cards, and version control should be implemented.

3. Auditing and Compliance: Model cards should be periodically audited for compliance with organizational standards and any relevant governmental regulations. The model card should be verified for completion and adherence to security standards, and the information included should be verified as accurate where applicable.

Implementation Guidelines for Cloud Service Providers (CSP)

1. Establish secure, role-based storage systems for housing documentation artifacts such as Model Cards, ensuring that access is tightly governed and limited to permitted stakeholders.

2. Integrate change tracking and audit capabilities within documentation storage workflows, allowing for full visibility into edits, authorship, and historical versions over time.

3. Provide trusted collaboration workspaces that enable controlled joint editing and distribution of model-related documentation, facilitating teamwork while preserving security and integrity.

4. Implement reliable data protection strategies, including regular backups and continuity planning, to preserve and recover Model Card data in the event of system issues or unforeseen disruptions.

MDS-04: Model Documentation Requirements

Control Specification

Establish and implement baseline requirements for Model documentation.

Shared Implementation Guidelines

Not Applicable

Implementation Guidelines for Cloud Service Providers (CSP)

Not Applicable

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.

Shared Implementation Guidelines

[Shared Responsibilities (Applicable to MP, OSP, AP)]

1. Perform regular Validation including:

   • Automated schema validation

   • Full model behavior validation

   • Comprehensive documentation review

2. Perform Event-Triggered Validation

   • Model updates - consider training data changes

   • API modifications

   • Dependency updates

3. Define thresholds to be used in the validation process, which trigger an alert for investigation

4. Review Procedures and Documentation

   • Compare model card against actual implementation

   • Verify accuracy of all technical specifications

   • Validate example inputs and outputs

   • Review evaluation metrics and results

5. Incident Response

   • Document validation failures

   • Track resolution progress

   • Update relevant stakeholders

   • Maintain audit trail

6. Continuous Improvement Optional

   • Regular review of validation processes

   • Update procedures based on findings

   • Incorporate feedback from stakeholders

   • Maintain validation documentation

Implementation Guidelines for Cloud Service Providers (CSP)

1. Provide protected and compliant data storage options for preserving validation outputs and audit evidence, ensuring long-term availability, traceability, and tamper resistance.

2. Enforce granular permission models to restrict Model Card validation activities to designated roles, reducing the risk of unauthorized actions and ensuring accountability throughout the validation process.

MDS-06: Adversarial Attack Analysis

Control Specification

Define, implement, and evaluate processes and technical measures to assess adversarial threats specific to each AI model.

Shared Implementation Guidelines

[Shared Responsibilities (Applicable to MP, AP)]

1. Ensure Adequate Training for Security Teams: If an internal Vulnerability Assessment and Penetration Testing (VA/PT) service is available, ensure that operators and security professionals undergo specific training programs to assess AI model vulnerabilities and adversarial threats effectively.

2. Analyze and Score Vulnerabilities: Analyze identified vulnerabilities based on their likelihood and potential impact. Assign scores to help prioritize the most significant risks.

3. Prioritize Mitigation Efforts: Focus on addressing high-risk threats first, ensuring that critical vulnerabilities are mitigated in a timely manner.

4. Establish Periodic Reporting on VA/PT Activities: Generate regular reports—at least annually—summarizing Vulnerability Assessment and Penetration Testing (VA/PT) activities. These reports should highlight key security findings, provide actionable insights, and outline recommended remediation strategies to enhance AI model security.

5. Regular Reviews: Organizations should schedule regular reviews of their models’ security posture, at minimum on a semi-annual basis. These reviews should include updated risk assessments that take into account newly deployed models and emerging threat landscapes.

Implementation Guidelines for Cloud Service Providers (CSP)

1. Conduct Testing for Model Infrastructure Vulnerabilities and Attack Paths: Leverage AI Security Posture Management (AISPM) and traditional Pen Testing tools to identify security gaps in the underlying infrastructure.

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.

Shared Implementation Guidelines

Not Applicable (Access to model artifacts and weights is needed for robustness (hardening) training)

Implementation Guidelines for Cloud Service Providers (CSP)

Not Applicable (Access to model artifacts and weights is needed for robustness (hardening) training)

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.

Shared Implementation Guidelines

[Shared Responsibilities (Applicable to MP, OSP, AP)]

1. Comparison of checksums should be applied both in production and test environment at least annually based on the level of risk, or during any change of hands.

Implementation Guidelines for Cloud Service Providers (CSP)

1. Deliver isolated and trusted execution environments for performing integrity verification operations such as checksum computation and validation, ensuring data confidentiality and preventing unauthorized tampering during the process.

2. Make available standardized libraries and utilities that support the generation of cryptographic digests for model artifacts, enabling consistent and verifiable tracking of model integrity across development stages.

3. Deploy resilient and access-controlled storage infrastructure for safeguarding both model checkpoint files and their associated integrity metadata, preserving availability and ensuring secure long-term retention.

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.

Shared Implementation Guidelines

[Shared Responsibilities (MP, OSP, AP, CSP)]

1. Model signatures should be verified whenever the model is changing hands or being moved between locations.

2. Signing keys or identities should be clearly associated with the code producers, ensuring an unambiguous link to the corresponding code as the owning entity. Public registries should be used wherever possible to support this association.

3. Only verified models and model files from trusted sources should be loaded or used in applications.

4. Enforce automated signature verification at model loading time to prevent unauthorized or tampered models from being used.

5. Maintain a model signing and verification audit log, documenting all signature validations, transfers, and ownership changes for traceability.

Implementation Guidelines for Cloud Service Providers (CSP)

[Shared Responsibilities (MP, OSP, AP, CSP)]

1. Model signatures should be verified whenever the model is changing hands or being moved between locations.

2. Signing keys or identities should be clearly associated with the code producers, ensuring an unambiguous link to the corresponding code as the owning entity. Public registries should be used wherever possible to support this association.

3. Only verified models and model files from trusted sources should be loaded or used in applications.

4. Enforce automated signature verification at model loading time to prevent unauthorized or tampered models from being used.

5. Maintain a model signing and verification audit log, documenting all signature validations, transfers, and ownership changes for traceability.

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.

Shared Implementation Guidelines

[Shared Responsibilities (MP, AP)]

1. Revising or optimizing the prompts used in applications to ensure they generate accurate and relevant outputs, particularly as the model evolves or data context shifts.

2. Continuously monitor these metrics for signs of drift or unexpected changes leveraging Model Observability Platforms.

3. Set up automated alerts to notify stakeholders when significant deviations or anomalies are detected.

Implementation Guidelines for Cloud Service Providers (CSP)

1. Ensure visibility into AI LLMs’ requests, responses, and overall performance metrics to support monitoring, auditing, and troubleshooting.

2. Determine Model Types and Use Cases: Identify which hosted models require continuous monitoring (e.g., LLMs, CV models, tabular models).

3. Define Metrics: Choose relevant performance metrics—accuracy, F1, latency, error rate, drift metrics, fairness scores.

4. Set Monitoring Goals: Clarify what constitutes performance degradation, prediction anomalies, or business risk.

[Shared Responsibilities (Applicable to ALL actors)]

1. Define service-level agreements (SLAs) or objectives (SLOs) that include metrics reflecting overall model performance and reliability.

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.

Shared Implementation Guidelines

[Shared Responsibilities (Applicable to ALL actors)]

1. Define service-level agreements (SLAs) or objectives (SLOs) that include metrics reflecting overall model performance and reliability.

[Shared Responsibilities (Applicable to AP, OSP)]

1. Redundancy Management:

   • Implement Multiple model support with weighted importance

   • Perform Quality and performance monitoring

   • Implement Automatic detection of degraded or failed models

   • Adopt Quorum-based decision making techniques

2. Model Configuration:

   • Set appropriate weights for each model based on reliability

   • Configure quality thresholds based on your use case

   • Adjust quorum size based on reliability requirements

   • Implement fallback scenarios for complete model failure

3. Implement Failure Detection techniques such as:

   • Quality score tracking

   • Error rate monitoring

   • Latency monitoring

   • Historical metrics tracking

   • Trend analysis for early warning

4. Failover Mechanisms:

   • Automatic model exclusion when quality degrades

   • Dynamic load balancing across healthy models

   • Cooldown periods between recovery attempts

   • Graceful degradation when insufficient models are available

5. Monitoring Setup:

   • Implement comprehensive logging

   • Set up alerts for degraded performance

   • Monitor recovery attempts and success rates

   • Track load distribution across models

   • Monitor long-term quality trends

6. Recovery Strategy:

   • Implement model-specific recovery logic

   • Consider automatic scaling for heavy loads

   • Perform and validate Disaster Recovery or Chaos Engineering tests

Implementation Guidelines for Cloud Service Providers (CSP)

1. Deliver resilient infrastructure built for high availability, leveraging redundant compute, storage, and networking layers to minimize downtime and ensure continuous service delivery.

2. Adopt robust, fault-tolerant system designs—such as multi-region or multi-zone deployments with automatic failover capabilities—to sustain operations during infrastructure failures or outages.

3. Establish comprehensive backup strategies and tested disaster recovery plans to protect essential system components and minimize recovery time in the event of service disruptions or data loss.

4. Implement scalable, distributed storage architectures with built-in replication to securely persist model files, configuration settings, and related datasets, ensuring data durability and accessibility.

[Shared Responsibilities (Applicable to ALL actors)]

1. Define service-level agreements (SLAs) or objectives (SLOs) that include metrics reflecting overall model performance and reliability.

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.

Shared Implementation Guidelines

[Shared Responsibilities (OSP, AP, AIC)]

1. Continuous Monitoring and Updating: Regularly monitor the model for new vulnerabilities and update it accordingly.

2. Community and Peer Review: Eventually engage with the broader AI community for peer reviews and feedback.

Implementation Guidelines for Cloud Service Providers (CSP)

Not Applicable

MDS-13: Secure Model Format

Control Specification

Adopt secure model formats and processes for AI model serialization where applicable.

Shared Implementation Guidelines

[Shared Responsibilities (OSP-AP)]

1. Verify compliance of models with secure formats before loading them into production systems.

2. Apply security controls to models before deployment, ensuring they do not contain malicious code or deserialization vulnerabilities.

Implementation Guidelines for Cloud Service Providers (CSP)

1. Deploy robust and encrypted storage solutions purpose-built for housing serialized model files along with their associated metadata, ensuring long-term protection and controlled access.

2. Implement comprehensive monitoring and audit logging features to track access patterns, usage history, and any changes made to serialized models, supporting accountability and forensic readiness.

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.

Shared Implementation Guidelines

[All Actors]

1. Establish a unified AI Security Policy Framework encompassing data security, access control, incident response, change management, logging and monitoring, vulnerability management, and responsible AI use.

2. Align AI-related policies with industry frameworks such as ISO/IEC 27001, NIST SP 800-53, CSA CCM, and EU AI Act governance requirements.

3. Maintain a centralized and version-controlled repository of security policies applicable to AI lifecycle stages (e.g., data ingestion, model training, model inference, decommissioning).

4. Conduct annual reviews of policies to ensure continued relevance with emerging AI risks, technological changes, and regulatory updates.

5. Ensure policy accessibility and enforce policy awareness across all relevant internal teams, including development, operations, compliance, and security.

Implementation Guidelines for Cloud Service Providers (CSP)

1. Provide incident management templates and automation workflows for AI services hosted in the cloud.

2. Support real-time forensic collection, preservation, and secure handoff for cross-organization investigations.

3. Ensure shared responsibility models are clearly defined for multi-tenant AI service incidents.

[All Actors]

1. Establish a unified AI Security Policy Framework encompassing data security, access control, incident response, change management, logging and monitoring, vulnerability management, and responsible AI use.

2. Align AI-related policies with industry frameworks such as ISO/IEC 27001, NIST SP 800-53, CSA CCM, and EU AI Act governance requirements.

3. Maintain a centralized and version-controlled repository of security policies applicable to AI lifecycle stages (e.g., data ingestion, model training, model inference, decommissioning).

4. Conduct annual reviews of policies to ensure continued relevance with emerging AI risks, technological changes, and regulatory updates.

5. Ensure policy accessibility and enforce policy awareness across all relevant internal teams, including development, operations, compliance, and security.

From CCM v4.1: Control Ownership Rationale. This control’s ownership is “Shared (Independent)” as both the CSP and CSC need to independently establish their own policies and procedures for Security Incident Management.

Implementation Guidelines. Applicable to all service models: The Security Incident Management, E-Discovery, and Cloud Forensics Policies and Procedures should be established and documented with clearly-defined roles and responsibilities, and for each cloud service model (IaaS, PaaS, and SaaS). Shared responsibilities should become identified with the use of Key Shared Security Responsibility Indicators (KSSRI) or Key Shared Cloud Security Responsibility Indicator (KSCSRI) where possible.

Policies, procedures, and supporting systems should incorporate provisions concerning the chain of custody for forensic evidence, so that such evidence becomes legally admissible.

The CSP is responsible for establishing and following company policies, resource management, regulatory and insurance requirements set forth with regards to managing incidents or performing eDiscovery and forensics-based investigations. The CSP is not responsible for maintaining knowledge of, or carrying out forensics investigations on behalf of the CSC. Nevertheless, the CSP should collaborate with the CSC during the forensic-based investigations, specifically in cases where incidents could have originated from the CSP and third-party vendors in the supply chain.

The policies and procedures should include the phases of the IR life cycle and indicate when the CSP should engage the CSC for security incidents that affect the CSC, as well as the frequency at which the CSP is expected to provide updates during incidents.

The CSP should communicate the Security Incident Management, E-Discovery, and Cloud Forensics Policies within the organization and may publish or share the IR policy for the CSC’s awareness.

Policies should require establishing a core, qualified, and standing IR team that has the capability to assess, respond, learn, and communicate appropriately.

Policies should include (but not limited to) provisions on the following:

• a. Incident Handling Process: Time-stamped recording of activities in the IR process is necessary for metrics, SLA’s, service recovery, and availability

• b. Detection:

  • i. the location of the activity resulting in an incident: SaaS (e.g., api, GUI, user, data), PaaS (e.g., api, GUI, user, application, data), IaaS (e.g., api, GUI, user, application, solution stack, VM, data), or at the hypervisor, OS, compute and storage, network, or facility, and the event source logs, including which party (either the CSP or CSC) is responsible for the activity (success and/or failure) logs, as well as the availability of the logs that will be used for detection and other security incident management phases

  • ii. implementation of advanced detection tools (behavioral and rule-based) with automated alerting should be used by both the CSP and CSC to provide early detection and indication of potential incidents, as well as mechanisms for end user and third-party detection of incidents to be self-reported via ticket, email, telephoning help desk, or other available channels

• c. Analysis:

  • i. policy and process should follow an attack vector taxonomy process which may include referencing the Mitre ATT&CK IaaS, PaaS, and SaaS tactics and techniques.

  • ii. incident scope, type, impact (functional and informational), and severity should be defined, including the data classification (e.g., personal data, Top Secret, Secret, Confidential, Health) involved in the incident

  • iii. major incidents related to data breach, DDoS, malware, Data Leakage (DL), exploit types, local vs. remote, internal vs. external, perimeter, management plane incidents, and expected IR steps and consequences should be understood and demonstrated where the CSC’s cloud environment is affected

  • iv. reference to consulted Incident classification and categorization techniques from organization-approved sources (e.g., US-CERT Federal Incident Notification Guidelines or FedRAMP Incident Communications Procedures). The CSC can obtain CSP support via the CSP’s Customer Incident Response Team (CIRT)

• d. Containment:

  • i. the most common containment techniques (e.g., network, filtering, routing, firewall and port rule changes to deny traffic, traffic filtering or isolation) are usually the responsibility of the CSP and can be automated with capable SIEM/SOAR, logic apps, and workbooks, unless it is a CSP-provided security group firewall which would be the CSC’s responsibility

  • ii. the CSP should contain the security incident by reducing or removing the attacker’s ability to continue to exploit the functionality.

  • iii. the CSP should ensure that forensic evidence is not compromised and that a read-only backup or creating a snapshot should be taken (e.g., cloud block-storage snapshot)

  • iv. The CSP should follow guidelines on managing the chain of custody for forensic evidence collected from affected systems, devices, cloud services, applications, and personnel. These policies, procedures, and supporting systems should result in legally admissible evidence

• e. Eradication:

  • i. the responsibility for addressing the root cause and returning the environment to a safe state needs to be defined between the CSP and CSC, or indicate where it is shared (e.g., removing malware could be the responsibility of both the CSP and the CSC)

  • ii. the responsibility for closing exposures, removing or resetting credentials, performing key rotation/revocation, stopping an instance, moving to a secure resource, restricting privilege access, ensuring least privilege, need to know and need to use principles should be updated accordingly

• f. Recovery:

  • i. restoring from backups, depending on the backup strategy if within the same CSP or another CSP, should be indicated in the policy and follow BCP or DR plans to maintain prioritized sequential restoration and recovery of resources

  • ii. Both the CSP and CSC will need to meet the changing needs of the scalable environment with adaptable RTO/RPO capabilities when resources delivering the services have expanded dynamically as with auto scaling groups, increased storage, and increased data consumption.

  • iii. responsibilities for rebuilding systems and allocation of resources to achieve recovery, and for ensuring the security of the recovered environment will need to be defined between the CSP and CSC

• g. Post-Mortem: Recommend configuration changes to the environment to prevent or mitigate future incidents where the CSP and CSC agree, include lessons learned, and KPIs defined and implemented for IR processes and training

• h. Response Time Agreement:

  • i. Agree on severity and response time for security incidents between the CSP and CSC where shared responsibility is agreed

  • ii. Organization-approved industry standards should be consulted i. Communication Path with CSC: define the following prior to security incidents in the policies and procedures:

• i. Reporting path: which security incident types should be reported to the CSC

• j. Escalation path: the escalation path with the CSC prior to a security incident

• k. Notification path: automate where possible, via a security incident management tool, or an alerting service via email. An out-of-band notification path may need to be defined. The IR policy and procedures should include notification requirements and timelines as per regulatory and legal requirements, especially “Breach Notification” requirements. Reference the Federal Incident Notification Guidelines where applicable

• l. IR Plan Testing: Test the IR plan periodically, either through paper walk through/table top exercise or simulation with the participation of both the CSP and CSC as well as other relevant parties

• m. Approval: Approval requirements and senior management involvement to ensure alignment with the organization’s strategic goals and risk appetite

  • i. An approval process should be established for any changes or modifications to the policy and procedures

  • ii. A documented record of approvals (including dates, names of approvers, and any relevant comments or discussions) should be maintained

• n. Communication: Effective communication of the policy and procedures should be facilitated to all relevant cloud stakeholders

• o. Maintenance and Reviews: Security Incident Management, E-Discovery, and Cloud Forensics policies and procedures should be documented, reviewed and updated at least annually to ensure alignment with evolving cloud security landscape and to reflect changes in cloud technology, regulations, and risks.

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.

Shared Implementation Guidelines

[All Actors]

1. Define a Service Management Policy that addresses secure, reliable, and compliant service operations across the AI/ML lifecycle.

2. Document lifecycle processes including deployment, scaling, deprecation, and emergency patching of AI systems.

3. Embed security, privacy, and resilience considerations into operational workflows.

4. Ensure the policy includes business continuity expectations during service disruptions related to AI components.

Implementation Guidelines for Cloud Service Providers (CSP)

[All Actors]

1. Define a Service Management Policy that addresses secure, reliable, and compliant service operations across the AI/ML lifecycle.

2. Document lifecycle processes including deployment, scaling, deprecation, and emergency patching of AI systems.

3. Embed security, privacy, and resilience considerations into operational workflows.

4. Ensure the policy includes business continuity expectations during service disruptions related to AI components.

From CCM v4.1: Control Ownership Rationale. This control’s ownership is “Shared (Independent)” as the CSP and CSC independently establish their own policies and procedures for Security Incident Management. The policies and procedures should clearly define roles and responsibilities and any shared responsibilities with the use of KSSRIs or KSCSRIs throughout all phases of the Security Incident Management process, including chain of custody for forensic evidence and legal obligations between the CSP and CSC.

Implementation Guidelines. Applicable to all service models: Policies should include (but not limited to) provisions on the following:

• a. CSP-CSC Collaboration: Address personnel designated to report incidents between the CSP and CSC, the timeframes established, and agreed-upon impact and severity rating applicable to the CSC and CSP for incident management practices. This ensures that an incident categorized by the CSP or CSC does not negate or dictate the appropriate response to contain and eradicate the incident, or cause variations in the understanding of the appropriate response from either party (e.g., a personal data breach requires shorter response time than a DDoS attack), the frequency to provide reports throughout the incident lifecycle, and how the incident should be reported

• b. Roles and Responsibilities: Clear roles and responsibilities of the personnel in the entire incident and event management lifecycle should be defined

• c. Proactive Measures: aim to reduce IR time by including preventative measures following a defense-in-depth strategy, least privilege, need-to-know, need-to-use, and zero trust models where possible, as some defense mechanisms will be available from the CSP as part of the service or at a cost to the CSC

• d. IR Automation SOAR: address automation with a Security Orchestration and Automation Response (SOAR) solution to reduce the time to alert, contain, remediate, and eradicate the incident automatically, (e.g., when a malware attack is detected, quarantine the impacted systems, then either clean them automatically, reimage them, or perform other activities as programmed in the SOAR). The CSP will need to define what automated responses can be provided to the CSC where SOAR technology is used

• e. IR Containment: define roles between the CSC and CSP for containment strategy. Also, predetermined criteria informing how to contain the incident should be defined in the procedures to ensure timely and cost effective containment and management. Use of KSCSRIs may assist with ensuring CSP and CSC have awareness of their containment responsibilities

• f. Evidence Cloud Storage: consider the use of either a separate cloud account or of another CSP for storage of evidence. The CSP will need to inform the CSC how to accomplish this

• g. Approval: Approval requirements and senior management involvement to ensure alignment with the organization’s strategic goals and risk appetite

  • i. An approval process should be established for any changes or modifications to the policy and procedures

  • ii. A documented record of approvals (including dates, names of approvers, and any relevant comments or discussions) should be maintained

• h. Communication: Effective communication of the policy and procedures should be facilitated to all relevant cloud stakeholders

• i. Maintenance and Reviews: Policies and procedures for the management of security incidents should be documented, reviewed and updated at least annually to ensure alignment with evolving cloud security landscape and to reflect changes in cloud technology, regulations, and risks

Other policy and procedural considerations for timely management of security incidents for both CSP and CSC should include agreements on:

• a. IR Alerting: alerting procedures should be defined and implemented within a defined time frame based on event, severity, impact, and threat intelligence

• b. IR Time: response time depending on incident severity (e.g., number of minutes/hours per severity level) as per contractual agreement or SLA

• c. investigation of the time and date (including time zone) of each occurrence of evidence handling, the shared responsibility to produce (through secure auditing, logging, and monitoring), collect, safely store (with encryption and integrity), and transfer information or evidence related to the incident. Use of KSCSRIs may be used to assist with identifying when responsibility changes between the CSP and CSC and vice versa if another CSP will be used to store the evidence

• d. RTO Metrics: recovery time frame based on RTO and SLAs. Use of KSCSRIs may assist with meeting these required time frames

• e. IR Records: chronological record of all activities during the incident lifecycle with indicators to notify, report, and communicate as per agreed time frames between the CSP and CSC

The CSP should communicate the Security Incident Management, E-Discovery, & Cloud Forensics, Service Management Policy and Procedures within the organization and may publish or share the Incident Response Policy with the CSC for awareness.

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.

Shared Implementation Guidelines

[All Actors]

1. Establish and maintain documented incident response plans for AI systems and supporting infrastructure that address the full incident lifecycle, including detection, containment, eradication, recovery, post-incident analysis, developing a breach notification policy that includes AI-specific data types (e.g., training data, model parameters) and exposure scenarios.

2. Ensure incident response procedures account for threats specific to AI systems, such as prompt injection, adversarial inputs, model evasion, training data poisoning, and unintended or harmful model outputs.

3. Define incident classification criteria, severity thresholds, and escalation procedures, including conditions that may trigger regulatory notification, contractual reporting obligations, or executive escalation.

4. Integrate AI incident response procedures with the organization’s broader security incident management, digital forensics, and business continuity processes.

Implementation Guidelines for Cloud Service Providers (CSP)

1. Provide predefined response playbooks and operational procedures for managing security incidents affecting AI hosting environments and supporting cloud services.

2. Provide cross-service logging, telemetry, and correlation capabilities to assist customers in identifying the origin, scope, and impact of incidents affecting cloud-hosted AI workloads.

3. Support incident response investigations by maintaining infrastructure logs, audit trails, and other forensic artifacts necessary to reconstruct security events, as per SLA commitments.

4. Ensure service agreements and operational processes define support expectations and communication channels during incident response activities, including escalation procedures for security events affecting AI workloads.

[All Actors]

1. Establish and maintain documented incident response plans for AI systems and supporting infrastructure that address the full incident lifecycle, including detection, containment, eradication, recovery, post-incident analysis, developing a breach notification policy that includes AI-specific data types (e.g., training data, model parameters) and exposure scenarios.

2. Ensure incident response procedures account for threats specific to AI systems, such as prompt injection, adversarial inputs, model evasion, training data poisoning, and unintended or harmful model outputs.

3. Define incident classification criteria, severity thresholds, and escalation procedures, including conditions that may trigger regulatory notification, contractual reporting obligations, or executive escalation.

4. Integrate AI incident response procedures with the organization’s broader security incident management, digital forensics, and business continuity processes.

From CCM v4.1: Control Ownership Rationale. Incident Response Plans control ownership is “Shared (Independent)” as both the CSP and CSC need to independently establish their own security IR plan and own the responsibility. The IR plans should clearly define roles and responsibilities and any shared responsibilities with the use of KSSRIs or KSCSRIs where possible.

Implementation Guidelines. Applicable to all service models: The IR plan relates back to the SEF-01 implementation guidelines to ensure that corresponding policy and procedure requirements are incorporated for all phases of the IR life cycle.

The IR plan should provide a methodology that enables efficient management of security incidents for the organization’s cloud products and services (SaaS, PaaS, IaaS) and clearly defines the relied-upon CSP’s services to achieve a coordinated response. Once the IR plan is established and documented the plan needs to be approved and communicated.

The IR plan should include the following provisions:

• a. Scope: The IR plan should apply to both internal dependencies (such as IT, operations, support, and legal) and external dependencies (suppliers, vendors, partners, customers, and other third parties). The cloud services, systems, applications, users, and data that are in scope and monitored for events and incidents. Ensure the scope network and infrastructure is monitored by the CSP

• b. Incident Response Team and Stakeholders: The stakeholders include customers, law enforcement who receive information about incidents and/or can be involved in incident management

• c. Incident Tracking and Classification: Define the issue and tracking system used for recording the incident. Classify incidents by severity and urgency (e.g., High, Medium, Low, Major vs Minor), using threat intelligence, attack vector taxonomy Mitre ATT&CK for PaaS, IaaS, and SaaS tactics and techniques, and data classification for any data involved, the scope, and the impact of the incident.

• d. Response Type and Expected Response Timeframes: The plan should indicate when a manual vs. automated response is required by the CSP or CSC, the time frames to respond by (e.g., mean time to acknowledge aka MTTA), by when the CSP or CSC is required to report an incident, who is responsible for containment of the incident, and the average expected mean time to containment (MTTC). The response may invoke subsequent IR plans such as an encryption key compromise-recovery plan for restoring cryptographic security services

• e. Evidence Gathering and Handling: Steps to collect and maintain the integrity of the evidence should be provided, when and where to make copies, when to use exact replicas for analysis, the CSP’s or CSC’s responsibilities around logs, other collected evidence, storing in restricted read-only repositories, using a separate account or another CSP, hashing procedures, and chain of custody for ensuring admissibility in legal proceedings

• f. Incident Lifecycle Phases and Procedures: Procedures for preparation, detection and analysis, eradication and recovery, post-mortem with continuous analysis at each phase to determine effectiveness, the CSC’s preventative measures such as IDS/IPS, and provide specificity around incidents with shared responsibilities.

• g. Roles and Responsibilities: Common shared security responsibilities between the CSP and CSC in relation to incident response:

  • i. Client and endpoint incidents – (SaaS) shared CSC and CSP

  • ii. Identity and access incidents – (PaaS, SaaS) shared CSC and CSP

  • iii. Application Incidents – (PaaS) shared CSC and CSP

  • iv. Network incidents – (IaaS) shared CSC and CSP

• h. Host incidents – (IaaS) shared CSC and CSP Common non-shared responsibilities: vi. Data classification and accountability incident – CSC vii. Client and endpoint incidents (IaaS, PaaS) – CSC viii. Identity and access incidents (IaaS) – CSC ix. Application incidents (IaaS) – CSC

• i. Application incidents (SaaS) – CSP xi. Network incidents (PaaS, SaaS) – CSP xii. Host incidents (PaaS, SaaS) - CSP xiii. Infrastructure incidents (IaaS, PaaS, SaaS) - CSP

• j. Notification and Reporting: List of personnel at the CSP and CSC, third-party personnel, and distribution lists for notification. Use internal and external websites or portals where incidents and service outage information can be published and updated regularly to advise on the status of incidents that affect major services. US-CERT (required for US federal agencies and systems operated on behalf of the federal government) serves as the federal incident response center

• k. Business Impact Assessment Information: The CSP and CSC should have BIA information for each asset, system, application, and associated classified data, with owners identified and the relevant internal departments, upstream/downstream interdependencies, services (IaaS, PaaS, SaaS), and other business-critical relationships (such as supply chain) that may be impacted

• l. Reference Information: Information on how to determine the applicable RPO, RTO, and MTD of a particular system or set of systems for restore from backup recovery procedures to restore affected services, logs, and data as per agreements between the CSC and CSP to maintain business continuity. Outline the criteria required to select the appropriate eradication and recovery choice, e.g., restore, rebuild, replace, redirect or remove.

• m. Schedule: A schedule to review, test, evaluate, and maintain and approve the plan. Define the frequency or schedule to conduct the review, test coordination, and approve the plan.

• n. Plan Testing: Conduct a paper walk through/table top exercise or simulation where feasible with the participation of both the CSP and CSC as defined in the schedule. Evaluate and maintain/update the plan accordingly:

  • i. after testing the plan and with lessons learned obtained

  • ii. after incidents that resulted in changes to the response methodology, e.g., new attack vectors, containment strategies, false positives, false negatives, or caused a deviation from the response plan, and exposures detected from penetration testing.

  • iii. Timing: When services (IaaS, PaaS, SaaS), critical assets, applications, and classified data are either added or removed

  • iv. Plan Reapproval: The plan should be reapproved after all necessary changes are made

• o. Change Control: The IR plan should maintain a document control section indicating when the plan was tested and the changes to the plan content with each iteration.

SEF-04: Incident Response Testing

Control Specification

Exercise the incident response plans at planned intervals or upon significant changes.

Shared Implementation Guidelines

[All Actors]

1. Conduct periodic testing of AI incident response procedures through structured exercises such as tabletop simulations, technical drills, or red team engagements.

2. Validate the readiness of incident response teams to address threats targeting AI system components, including training data pipelines, inference services, model interfaces, and supporting infrastructure.

3. Include coordination with vendors, service providers, and other third parties in incident response exercises where AI systems rely on externally managed services.

4. Document exercise outcomes, lessons learned, and identified gaps, and incorporate improvements into incident response procedures, playbooks, and cross-functional workflows.

Implementation Guidelines for Cloud Service Providers (CSP)

1. Support tenant-specific incident response testing by enabling simulations involving cloud-hosted AI services, infrastructure components, and related platform capabilities.

2. Provide audit-ready reports of testing outcomes, improvements made (corrective actions), and gaps identified to help customers analyze detection effectiveness and incident response performance.

3. Offer support during cross-tenant or zero-day simulation testing for large language models and other shared systems to validate response procedures for incidents affecting shared or multi-tenant AI services.

[All Actors]

1. Conduct periodic testing of AI incident response procedures through structured exercises such as tabletop simulations, technical drills, or red team engagements.

2. Validate the readiness of incident response teams to address threats targeting AI system components, including training data pipelines, inference services, model interfaces, and supporting infrastructure.

3. Include coordination with vendors, service providers, and other third parties in incident response exercises where AI systems rely on externally managed services.

4. Document exercise outcomes, lessons learned, and identified gaps, and incorporate improvements into incident response procedures, playbooks, and cross-functional workflows.

From CCM v 4.1: Control Ownership Rationale. The control’s ownership is “Shared (Independent)” as both the CSP and CSC need to independently test and update their individual organization’s IR plan.

Implementation Guidelines. Applicable to all service models: Incident Response plans should be tested periodically either through paper walk through/table top exercise or simulation where feasible with the participation of both CSP and CSC to verify the IRP’s effectiveness using various event scenarios.

The CSP should:

• a. validate and update all contact information and IR team members

• b. validate and update the scope of the IR plan, both internal dependencies (such as IT, operations, support, and legal) and external (suppliers, vendors, partners, customers, and other third parties). The cloud services, systems, applications, users and data that are in scope and monitored for events and incidents. Ensure the scoped network and infrastructure is monitored by the CSP

• c. define the scope for the IR test (e.g., an environment for the IR plan testing should include the following options, but not be limited to: a duplicate test/simulation environment, an alternate non production environment, and a third party CSP cloud service/account)

• d. decide which area in the threat landscape to test the IR plan with e.g., the tactics techniques procedures (initial access, execution, persistence, privilege escalation, defense evasion, credential access, discovery, lateral movement). Follow an attack vector taxonomy process using the Mitre ATT&CK for IaaS, PaaS, SaaS tactics and techniques to simulate events and activities that would result in an incident

• e. schedule the IR plan test – arrange meetings with participants, the CSP, and the CSC as defined in the plan

• f. conduct the paper walk through or simulation following the IR plan and all phases of the incident. Maintain a chronological log of the testing activities for metrics and indicators of successfully completing all timed activities and steps outlined in the plan

• g. coordinated test, review, and update manual processes and automated incident management features, detection, alerting, playbooks, logic apps, rules, containment, eradication and recovery strategies

• h. reconcile the organization’s BC and DR plans with the IR plan, and address discrepancies

• i. document and communicate the IR plan test results, with resulting action items that address areas that failed during the test, deviated from the response methodology, containment strategies, false positives, false negatives, or could not be executed

• j. update the plan to address discrepancies and failures, and obtain reapproval of the plan

The CSP and CSC should also test, update, and improve IR plans after:

• a. significant organizational changes

• b. external supply chain disruptions and natural disasters

• c. security attacks, particularly those resulting in security breaches

SEF-05: Incident Response Metrics

Control Specification

Establish, monitor and report information security incident metrics.

Shared Implementation Guidelines

[All Actors]

1. Define a baseline set of incident response metrics such as Mean Time to Detect (MTTD), Mean Time to Respond (MTTR), containment time, and incident closure rate.

2. Track and report severity distribution (e.g., critical, high, medium, low) of security incidents over time to identify systemic issues.

3. Measure the volume of incidents escalated vs. resolved at first triage level to assess effectiveness of frontline defenses.

4. Monitor adherence to Service Level Objectives (SLOs) and regulatory deadlines (e.g., breach notification windows under GDPR, HIPAA).

5. Analyze incident recurrence frequency and use root cause tracking metrics to drive continuous improvements.

6. Maintain metric dashboards accessible to stakeholders for transparency and trend analysis.

Implementation Guidelines for Cloud Service Providers (CSP)

1. Provide tools and dashboards for tenants to visualize incident metrics for AI services hosted on cloud platforms.

2. Ensure metrics reflect the shared responsibility model and support transparency during post-incident reviews.

[All Actors]

1. Define a baseline set of incident response metrics such as Mean Time to Detect (MTTD), Mean Time to Respond (MTTR), containment time, and incident closure rate.

2. Track and report severity distribution (e.g., critical, high, medium, low) of security incidents over time to identify systemic issues.

3. Measure the volume of incidents escalated vs. resolved at first triage level to assess effectiveness of frontline defenses.

4. Monitor adherence to Service Level Objectives (SLOs) and regulatory deadlines (e.g., breach notification windows under GDPR, HIPAA).

5. Analyze incident recurrence frequency and use root cause tracking metrics to drive continuous improvements.

6. Maintain metric dashboards accessible to stakeholders for transparency and trend analysis.

From CCM v4.1: Control Ownership Rationale. This is a shared responsibility between the CSP and the CSC to ensure that appropriate security incident metrics are established and monitored.

Implementation Guidelines. Applicable to all service models: Security metrics need to be established, monitored and analyzed to detect weaknesses in operational processes or technical controls to support effective incident management.

The CSP should define, implement and monitor security incident metrics related to:

• a. all supporting infrastructure, virtual elastic compute, server operating systems, storage, and networking

• b. middleware, development tools, BI services, and database management systems

• c. applications configured as contractually agreed with the CSC

Implementation best practices for establishing and monitoring security incident metrics include (but not limited to):

• a. Detection Metrics:

  • i. Time to Identify (TTI) metric measures the average time to identify an incident

  • ii. False positives metric tracks the percentage of alerts that weren’t actual incidents

• b. Response Metrics:

  • i. Time to Contain (TTC) metric measures the average time to isolate and prevent further damage

  • ii. Mean Time to Respond (MTTR) metric tracks the average time to respond and fully resolve an incident

• c. Recovery Metrics:

  • i. Data Recovery Time (DRT) measures the average time to restore affected systems and data (e.g., downtime due to incident)

  • ii. Downtime Cost metric tracks the financial impact of service disruptions due to incidents

• d. Quantify Security Events:

  • i. Number of security alerts metric that tracks the volume of alerts generated by security tools

  • ii. Incident volume metric monitors the volume of the events monitored and the ratio of those events to incidents

• e. Business Impact:

  • i. Downtime metric tracks the duration of service disruptions due to security incidents

  • ii. Data Loss metric measures the volume of data compromised during an incident

• f. Incident Metrics in SLAs: Outline security incident metrics baselines and goals within SLAs to ensure transparency and accountability towards CSCs

• g. Metrics Prioritization: Focus should be on metrics for business continuity and CSC impact (e.g., MTTR for critical systems)

• h. Monitoring Incident Metrics:

  • i. SIEM solutions should be leveraged to collect, analyze, and visualize security data and provide real-time insights into potential incidents

  • ii. SIEM solutions should be configured to trigger automated alerts for suspicious activities based on predefined thresholds for chosen metrics i. Incident Metrics Review: i. Security incident metrics should be regularly reviewed to identify areas for improvement and updated based on lessons learned from incidents and evolving threats i. Metrics should be compared against industry standards and other CSPs (when possible) to identify areas for improvement

SEF-06: Event Triage Processes

Control Specification

Define, implement and evaluate processes, procedures and technical measures supporting business processes to triage security-related events.

Shared Implementation Guidelines

[All Actors]

1. Define a standardized triage playbook to guide classification, prioritization, and routing of security events.

2. Ensure initial triage criteria include impact assessment, asset criticality, threat severity, and confidence score.

3. Automate event enrichment using contextual data (e.g., asset tags, threat intelligence, user behavior) to improve triage accuracy.

4. Align event tagging and prioritization with MITRE ATT&CK, NIST CSF, or equivalent frameworks to drive consistency.

5. Establish centralized coordination between all stakeholder teams (MP, OSP, AP, AIC, CSP) for synchronized triage actions and escalation procedures.

6. Perform regular cross-stakeholder triage simulations and post-mortems to refine playbooks and improve responsiveness.

Implementation Guidelines for Cloud Service Providers (CSP)

1. Enable customers to integrate AI telemetry into native security monitoring services.

2. Offer event prioritization tools and tagging capabilities to streamline triage in multi-tenant environments.

[All Actors]

1. Define a standardized triage playbook to guide classification, prioritization, and routing of security events.

2. Ensure initial triage criteria include impact assessment, asset criticality, threat severity, and confidence score.

3. Automate event enrichment using contextual data (e.g., asset tags, threat intelligence, user behavior) to improve triage accuracy.

4. Align event tagging and prioritization with MITRE ATT&CK, NIST CSF, or equivalent frameworks to drive consistency.

5. Establish centralized coordination between all stakeholder teams (MP, OSP, AP, AIC, CSP) for synchronized triage actions and escalation procedures.

6. Perform regular cross-stakeholder triage simulations and post-mortems to refine playbooks and improve responsiveness.

From CCM v4.1: Control Ownership Rationale. The implementation responsibility between the CSP and the CSC is typically both shared and dependent, as collaboration is necessary for effective triage of a security event. Triage is used for identifying, evaluating, prioritizing and responding to security events (and potential incidents) that impact both parties. The CSP can provide valuable insights into potential sources or root causes of the security event, while the CSC can contribute information specific to their data, configuration, applications, and user activity. This joint effort helps to identify the event’s scope and potential impact, leading to a more targeted and efficient response.

For example, a security incident occurring in the platform layer for an IaaS infrastructure should be driven jointly by the CSC and the CSP to determine if it originated in the CSC’s environment or the CSP’s environment. This may involve containment measures implemented by the CSP, such as isolating affected resources, while the CSC can take steps like user account suspension or data recovery, depending on the specific event.

Implementation Guidelines. Applicable to all service models: A fully documented and annually reviewed and approved triage management process should be in operation to ensure that all security events are investigated and evaluated in a timely manner.

The CSP should perform a triage process for all supporting infrastructure, virtual elastic compute, server operating systems, storage, and networking, but also middleware, development tools, BI services, database management systems, and applications configured for use by the CSC. The CSP should have visibility into the triage process to ensure the security incident management process is followed as contractually agreed.

Implementation best practices for security events triaging include (but not limited to):

• a. Stakeholders Collaboration:

  • i. Roles and responsibilities should be established for internal security teams, CSC support, and any external partners involved in incident response, as per contractual agreements

  • ii. A communication plan should be established for notifying relevant stakeholders, including internal teams, impacted CSCs, and regulatory bodies (if necessary)

• b. Events Classification Scheme: A standardized method for classifying security events based on severity, potential impact, and urgency should be defined, to support events prioritization. A multi-tiered approach can be considered:

  • i. Tier 1.Low-risk events might involve automated containment and basic investigation (e.g., suspicious login attempts)

  • ii. Tier 2.Medium-risk events require deeper investigation and potential CSC notification (e.g., potential malware infection)

  • iii. Tier 3.High-risk events necessitate immediate action, full investigation, and potential regulatory reporting (e.g., confirmed data breach)

• c. Standardized Playbook: A documented playbook outlining steps for each tier, should be developed, including:

  • i. Procedures for an initial assessment and gathering initial details about the event, including source, timeframe, and potential indicators of compromise (IOCs)

  • ii. Measures should be implemented for containment and to prevent further damage (e.g., isolating compromised systems or limiting user access)

  • iii. A thorough investigation should be conducted to determine the root cause, scope of the incident, and potential data loss (e.g., log analysis, threat intelligence feeds, and security tools)

  • iv. Actions should be implemented to eradicate the threat, recover affected systems, and prevent future occurrences

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.

Shared Implementation Guidelines

[All Actors]

1. Incident Response Planning: Define AI-specific incident categories, informed by frameworks like Mitre ATLAS, and establish severity levels based on risk. Document decision trees and procedures for response, investigation, and escalation to each incident type.

2. Detection and Analysis: Implement logging and monitoring capabilities (aligned with LOG controls) to detect anomalies and indicators of model compromise (e.g., poisoning, drift, misuse). Implement output validation as defined in AIS-09 and configure alerting thresholds for incident classification.

3. Response Automation: Develop response playbooks and automate response actions where appropriate, such as blocking model or application access, when validation fails or removing models from use when data integrity issues are identified. Maintain logging and audit trails of all automated and manual response actions.

4. Recovery activities: Establish recovery activities to restore models, data pipelines, prompts, and supporting services after failures or security incidents and automate where possible to follow BCP/DR procedures (e.g. aligned with BCR-04).

5. Testing and Validation: Test incident response and automated response mechanisms regularly, including tabletop exercises and scenario-based validation. Periodically (at least annually) review effectiveness and update processes based on lessons learned.

6. Compliance and Reporting: Ensure alignment with applicable regulatory and contractual incident reporting requirements. Maintain documentation to support auditability, including incident records, investigation findings, and remediation actions.

Implementation Guidelines for Cloud Service Providers (CSP)

1. Provide frameworks for tagging and classifying AI-related incidents within cloud-native tools.

2. Support dynamic severity reclassification as more incident context becomes available.

3. Provide necessary support for incident investigation as defined by contractual and regulatory obligations, e.g. access to relevant logs, telemetry, forensic artifacts, etc.

[All Actors]

1. Incident Response Planning: Define AI-specific incident categories, informed by frameworks like Mitre ATLAS, and establish severity levels based on risk. Document decision trees and procedures for response, investigation, and escalation to each incident type.

2. Detection and Analysis: Implement logging and monitoring capabilities (aligned with LOG controls) to detect anomalies and indicators of model compromise (e.g., poisoning, drift, misuse). Implement output validation as defined in AIS-09 and configure alerting thresholds for incident classification.

3. Response Automation: Develop response playbooks and automate response actions where appropriate, such as blocking model or application access, when validation fails or removing models from use when data integrity issues are identified. Maintain logging and audit trails of all automated and manual response actions.

4. Recovery activities: Establish recovery activities to restore models, data pipelines, prompts, and supporting services after failures or security incidents and automate where possible to follow BCP/DR procedures (e.g. aligned with BCR-04).

5. Testing and Validation: Test incident response and automated response mechanisms regularly, including tabletop exercises and scenario-based validation. Periodically (at least annually) review effectiveness and update processes based on lessons learned.

6. Compliance and Reporting: Ensure alignment with applicable regulatory and contractual incident reporting requirements. Maintain documentation to support auditability, including incident records, investigation findings, and remediation actions.

From CCM v4.1: Control Ownership Rationale. The implementation responsibility between the CSP and the CSC is shared, and collaboration may be necessary for a timely and effective response to a security incident based on the incident’s assigned categorization and severity level. Both the CSP and CSC have responsibility to define an incident response process, technical measures, and categorization and severity levels for security incidents they are responsible for. This responsibility is defined in the shared responsibility within the service level agreement (SLA) between CSP and CSC and based on the services and products in scope.

Implementation Guidelines. Applicable to all service models: A fully documented and annually reviewed and approved incident response process should be established to include defined technical measures and categorization and severity levels to ensure that all security incidents receive timely and effective response. Both the CSP and CSC are responsible for timely and effective response to security incidents within their scope of responsibility. For this collaboration, the CSP can provide targeted resources, while the CSC can contribute information specific to their data, configuration, applications, and user activity. This joint effort is based on the shared responsibility defined in the SLA between CSP and CSC. For example, a security incident occurring in the platform layer for an IaaS infrastructure should be driven jointly allowing the CSP to provide targeted resources. For a SaaS environment, the CSP may drive the joint effort based on the shared responsibility defined in the CSC’s Service Level Agreement (SLA). Implementation best practices for timely and effective response to security incidents include (but not limited to):

• a. Establish roles and responsibilities for responses, reporting, and collaboration between internal and external stakeholders, to include regulatory bodies (as necessary), per contractual agreements.

• b. Establish Incident categorization and severity levels for incidents/events based on an industry standard and include examples of indicators of compromise (IOCs) this. For example:

  • i. Tier 3 or High-risk incident require immediate response, for example, within 24 hrs, this category should include those that may require reporting, such as a ransomware attack.

  • ii. Tier 2 or Medium-risk incidents require less immediate response, for example up to 96 hrs, this category should include those that could impact operations for CSP and CSC, such as potential malware infection.

  • iii. Tier 1 or Low-risk incidents require non-immediate response, for example, over 96 hrs, such as suspicious login attempts.

• c. Establish recommended technical measures and information to apply those, including if authorization is needed and that contact for such, for different incident scenarios within each defined category and severity level. For example, isolating compromised systems for a ransomware attack under Tier 3 or High-risk, or malware infections under Tier 2 or Medium-Risk, while limiting user access is for Tier 1 or Low-Risk of suspicious login attempts. D. Establish “tool bags” for response to incident/event scenarios, especially those under the Tier 3 or High-Risk category.

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.

Shared Implementation Guidelines

[All Actors]

1. Develop a breach notification policy for AI-specific data types (e.g., training data, model parameters, prompt history,) and exposure scenarios. Include AI considerations such as compromised model outputs, unauthorized access to inference APIs, or exposure of proprietary models.

2. Establish a tiered system with defined breach thresholds that trigger notification for reportable breaches (actual or suspected) based on contractual, regulatory, and operational risk factors regarding individuals, the organization, or the broader ecosystem.

3. Define clear procedures for notifying internal stakeholders and external parties (regulators, partners, third-parties, and customers) to ensure transparency and legal compliance, within required timeframes.

4. Maintain a chronological log of the breach, including discovery methods, immediate containment actions, mitigation steps and the overall impact for audit and legal review.

5. Document specific mitigation steps, such as rolling back model versions, rotating API keys, or retraining on sanitized data, to demonstrate due diligence for audit and legal reviews.

Implementation Guidelines for Cloud Service Providers (CSP)

1. Provide breach notification support for AI tenants, including logs, timeline verification, and contact escalation.

[All Actors]

1. Develop a breach notification policy for AI-specific data types (e.g., training data, model parameters, prompt history,) and exposure scenarios. Include AI considerations such as compromised model outputs, unauthorized access to inference APIs, or exposure of proprietary models.

2. Establish a tiered system with defined breach thresholds that trigger notification for reportable breaches (actual or suspected) based on contractual, regulatory, and operational risk factors regarding individuals, the organization, or the broader ecosystem.

3. Define clear procedures for notifying internal stakeholders and external parties (regulators, partners, third-parties, and customers) to ensure transparency and legal compliance, within required timeframes.

4. Maintain a chronological log of the breach, including discovery methods, immediate containment actions, mitigation steps and the overall impact for audit and legal review.

5. Document specific mitigation steps, such as rolling back model versions, rotating API keys, or retraining on sanitized data, to demonstrate due diligence for audit and legal reviews.

From CCM v4.1: Control Ownership Rationale. This is “Shared (Independent)” since both CSP and CSC are responsible for ensuring that security breach notifications are disclosed according to the local legal and regulatory requirements as stated in the services agreement. The controls however are Independent from one another. Both entities may require different processes, procedures, and technical controls.

Implementation Guidelines. Applicable to all service models: The CSP should implement a process and procedures to report security breaches and assumed security breaches for all supporting infrastructure, virtual elastic compute, server operating systems, storage, and networking, and also middleware, development tools, BI services, database management systems, and applications configured as contractually agreed for use by the CSC.

Implementation best practices for security breach notifications include (but not limited to):

• a. Breach Notification Plan:

  • i. What constitutes a security breach, and the types of incidents requiring notification (unauthorized access attempts, data exfiltration) should be defined

  • ii. Breach information should be included in breach notifications and specify the nature of the breach, affected data types, potential risks, and mitigation steps taken

  • iii. Procedures for notifying relevant parties should be defined including impacted CSCs, regulatory bodies, and internal stakeholders, as per SLAs and relevant regulations

  • iv. Timeframes for notifying impacted parties based on the severity of the breach and relevant regulations should be defined (e.g., 72 hours as mandated by some data breach laws)

• b. Supply Chain Breach Notification:

  • i. Vendor contracts should include provisions requiring notification of security incidents impacting the CSPs’ services

  • ii. Breach notification procedures should adhere to data protection regulations

• c. Breach Notification Channels: Appropriate communication channels for notifying affected parties about security breaches should be established.

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.

Shared Implementation Guidelines

Each actor should independently maintain their own secure repository of security events/incidents records, as well establish a regular review cycle.

Shared responsibilities across all actors [All Actors]:

• a. Secure Repository: A dedicated, logically isolated, and highly secure storage solution should be utilized for all AI security incident records. This may be implemented using an object storage service with robust access controls (PoLP, need‑to‑know, MFA), encryption at rest and in transit, and versioning enabled. ii. Incident records should not be stored alongside operational, customer, or application data. iii. The repository should support structured query and filtering to enable efficient pattern analysis without requiring manual triage. iv. Incident records should be replicated to a secure secondary location to maintain availability during active incidents or service disruptions.

• b. Incident Record Classification and Handling: A classification scheme should be implemented for AI security incident/event records based on sensitivity, criticality, and impact. Incident record management processes should include the topics of information classification, handling, sharing, and redaction.

• c. Separation and Ownership of Incident Records: Each actor in the AI supply chain should maintain separate repositories to ensure integrity, autonomy, and compliance with jurisdictional data control requirements. Ownership, custodianship, and responsibilities for AI incident data should be defined in contractual agreements and SLAs.

• d. Records Retention Policy: A data retention policy for AI incident records should be defined and enforced, aligning with regulatory requirements (e.g., GDPR, CCPA, EU AI Act) and internal organizational policies. Securely archive or dispose of records once their retention period expires.

• e. Records Regular Review and Analysis: A formal schedule for the regular review of AI incident records should be established (e.g., weekly, bi-weekly, monthly, or quarterly, depending on incident volume and criticality). Analytical tools and techniques should be leveraged (e.g., data visualization, statistical analysis, machine learning) to identify recurring patterns, trends, and anomalies in AI incident data. For every significant incident, a thorough root cause analysis should be performed to identify the underlying reasons, investigating technical, process, and human factors. Document the root cause analysis findings as part of the incident record. Identified incident patterns and root causes should be linked to specific systemic vulnerabilities (e.g., misconfigurations, unpatched systems, weak access controls, design flaws).

• f. Corrective Measures: Based on the review and analysis, a prioritized and actionable remediation plan should be developed for identified vulnerabilities and systemic issues. AI incident insights should be used to inform the enhancement or development of new security controls. This includes updating security policies, improving monitoring capabilities, refining incident response procedures, and enhancing security awareness training.

• g. Post-Incident Reviews and Lessons Learned: Document lessons learned, including what went well, what could be improved, and specific action items. Share these lessons across relevant teams and stakeholders (MP, OSP, AP, AIC, CSP).

Please note: Each incident record should contain: Unique incident ID, Date/time of detection and closure, Incident category and severity, Affected assets, services, identities, or data, Indicators of compromise (IOCs), Timeline of events, Actions taken (containment, eradication, recovery), Root cause analysis (RCA), Lessons learned, Corrective and preventive actions (CAPA), Evidence artifacts (logs, screenshots, forensic data).

Implementation Guidelines for Cloud Service Providers (CSP)

[All Actors]:

• a. Secure Repository: A dedicated, logically isolated, and highly secure storage solution should be utilized for all AI security incident records. This may be implemented using an object storage service with robust access controls (PoLP, need‑to‑know, MFA), encryption at rest and in transit, and versioning enabled. ii. Incident records should not be stored alongside operational, customer, or application data. iii. The repository should support structured query and filtering to enable efficient pattern analysis without requiring manual triage. iv. Incident records should be replicated to a secure secondary location to maintain availability during active incidents or service disruptions.

• b. Incident Record Classification and Handling: A classification scheme should be implemented for AI security incident/event records based on sensitivity, criticality, and impact. Incident record management processes should include the topics of information classification, handling, sharing, and redaction.

• c. Separation and Ownership of Incident Records: Each actor in the AI supply chain should maintain separate repositories to ensure integrity, autonomy, and compliance with jurisdictional data control requirements. Ownership, custodianship, and responsibilities for AI incident data should be defined in contractual agreements and SLAs.

• d. Records Retention Policy: A data retention policy for AI incident records should be defined and enforced, aligning with regulatory requirements (e.g., GDPR, CCPA, EU AI Act) and internal organizational policies. Securely archive or dispose of records once their retention period expires.

• e. Records Regular Review and Analysis: A formal schedule for the regular review of AI incident records should be established (e.g., weekly, bi-weekly, monthly, or quarterly, depending on incident volume and criticality). Analytical tools and techniques should be leveraged (e.g., data visualization, statistical analysis, machine learning) to identify recurring patterns, trends, and anomalies in AI incident data. For every significant incident, a thorough root cause analysis should be performed to identify the underlying reasons, investigating technical, process, and human factors. Document the root cause analysis findings as part of the incident record. Identified incident patterns and root causes should be linked to specific systemic vulnerabilities (e.g., misconfigurations, unpatched systems, weak access controls, design flaws).

• f. Corrective Measures: Based on the review and analysis, a prioritized and actionable remediation plan should be developed for identified vulnerabilities and systemic issues. AI incident insights should be used to inform the enhancement or development of new security controls. This includes updating security policies, improving monitoring capabilities, refining incident response procedures, and enhancing security awareness training.

• g. Post-Incident Reviews and Lessons Learned: Document lessons learned, including what went well, what could be improved, and specific action items. Share these lessons across relevant teams and stakeholders (MP, OSP, AP, AIC, CSP).

Please note: Each incident record should contain: Unique incident ID, Date/time of detection and closure, Incident category and severity, Affected assets, services, identities, or data, Indicators of compromise (IOCs), Timeline of events, Actions taken (containment, eradication, recovery), Root cause analysis (RCA), Lessons learned, Corrective and preventive actions (CAPA), Evidence artifacts (logs, screenshots, forensic data).

From CCM v4.1: Control Ownership Rationale.

This control is “Independent” where the CSP and CSC each are responsible to establish and maintain their own secure repository for security incident/events records, as well as establish a regular review cycle.

Implementation Guidelines. Applicable to all service models:

The CSP should establish and maintain a secure repository of security incident/event records. The records may contain Information that could be considered sensitive in nature. Security incident/event record management processes should include the topics of information classification, handling, sharing and redaction.

Implementation best practices include (but not limited to):

• a. Secure Repository: A dedicated, logically isolated, and highly secure storage solution should be utilized for incident records. This could be an object storage service with robust access controls (following PoLP, need-to-know, MFA), encryption (at rest and in transit), and versioning enabled. Avoid storing incident records alongside operational or customer data. b.Incident Record Classification and Handling: A classification scheme should be implemented for security incident/event records based on sensitivity, criticality, and impact

• b. Separation and Ownership of Incident Records

  • i. The service provider and service customer should each maintain separate repositories to ensure integrity, autonomy, and compliance with jurisdictional data control requirements

  • ii. Ownership, custodianship, and responsibilities for incident data should be defined in the contractual agreements and SLAs

• c. Records Retention Policy: a data retention policy for incident records should be defined and enforced, aligning with regulatory requirements and internal organizational policies. Securely archive or dispose of records once their retention period expires.

• d. Records Regular Review and Analysis

  • i. A formal schedule for the regular review of incident records should be established (e.g., weekly, bi-weekly, monthly, or quarterly, depending on incident volume and criticality)

  • ii. Analytical tools and techniques should be leveraged (e.g., data visualization, statistical analysis, machine learning) to identify recurring patterns, trends, and anomalies in incident data. This includes identifying common attack vectors, compromised systems, or vulnerabilities exploited.

  • iii. For every significant incident, a thorough root cause analysis should be performed to identify the underlying reasons for the incident. This involves investigating technical, process, and human factors. Document the root cause analysis findings as part of the incident record

  • iv. Identified incident patterns and root causes should be linked to specific systemic vulnerabilities (e.g., misconfigurations, unpatched systems, weak access controls, design flaws).

• e. Corrective Measures:

  • i. Based on the review and analysis, a prioritized, and actionable remediation plan should be developed for identified vulnerabilities and systemic issues.

  • ii. incident insights should be used to inform the enhancement or development of new security controls. This includes updating security policies, improving monitoring capabilities, refining incident response procedures, and enhancing security awareness training

• f. Post-Incident Reviews and Lessons Learned: Formal post-incident reviews should be conducted for all major incidents. Document lessons learned, including what went well, what could be improved, and specific action items. Share these lessons across relevant teams.

• g. Sharing and Collaboration Procedures: Incident record sharing should be governed by:

  • Formalized sharing policies and SOPs

  • Regulatory requirements (e.g., GDPR, HIPAA, CCPA)

  • Inter-party agreements (e.g., SLAs, data processing agreements)

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.

Shared Implementation Guidelines

[All Actors]

1. Establish and maintain a centralized registry of designated points of contact (PoCs) for security, compliance, and incident response across all participating entities.

2. Ensure contact information includes role-specific PoCs for legal, regulatory, compliance, security, and DevSecOps functions, along with backup personnel.

3. Define procedures to regularly verify and update PoC information, especially when there are organizational changes, role transitions, or partner onboarding/offboarding.

4. Ensure availability of PoC data during incident triage and e-discovery, with clearly assigned responsibilities for rapid engagement.

5. Maintain contact retention and access procedures in alignment with applicable regulatory or contractual requirements (e.g., GDPR, HIPAA, CJIS).

Implementation Guidelines for Cloud Service Providers (CSP)

1. Offer customers dedicated AI support representatives for escalations and risk response.

2. Provide a self-service portal to manage and update tenant-specific contact preferences and SLAs.

[All Actors]

1. Establish and maintain a centralized registry of designated points of contact (PoCs) for security, compliance, and incident response across all participating entities.

2. Ensure contact information includes role-specific PoCs for legal, regulatory, compliance, security, and DevSecOps functions, along with backup personnel.

3. Define procedures to regularly verify and update PoC information, especially when there are organizational changes, role transitions, or partner onboarding/offboarding.

4. Ensure availability of PoC data during incident triage and e-discovery, with clearly assigned responsibilities for rapid engagement.

5. Maintain contact retention and access procedures in alignment with applicable regulatory or contractual requirements (e.g., GDPR, HIPAA, CJIS).

From CCM v4.1: Control Ownership Rationale. This control is “Shared (Independent)” since both the CSP and CSC are responsible for the maintenance and documentation of points of contact for applicable regulation authorities, national and local law enforcement, and other legal jurisdictional authorities.

Implementation Guidelines. Applicable to all service models: The CSP should document and maintain security incident contact information with relevant authorities and implement a communication process, and assign responsibilities to the communications team (personnel authorized to send notifications) and external regulatory entities, to prepare them for investigations requiring engagement with law enforcement.

Implementation best practices for maintaining points of contact include (but not limited to):

• a. Authorities Identification:

  • i. The relevant regulatory bodies should be searched for and identified in each region where the CSP operates (e.g., financial regulators, data protection authorities).

  • ii. Points of contact should be established within national and local law enforcement agencies in operational regions

  • iii. Legal jurisdictions should be identified where CSC data might be stored or processed due to international operations.

• b. Centralized Contact Repository:

  • i. A secure repository should be developed containing contact information for all identified authorities (e.g., names, titles, phone numbers, email addresses, jurisdiction areas, and preferred communication methods)

  • ii. The repository should be updated at least annually and upon any changes in personnel or contact information within the included authorities

• c. Communication Channels:

  • i. Communication protocols for each authority type should be established (e.g., secure email for regulatory bodies, dedicated hotlines for law enforcement)

  • ii. A process should be implemented for verifying the legitimacy of any communication received from claiming authorities

• d. Legal Counsel: Legal counsel should be considered to ensure proper procedures and data sharing protocols are followed when interacting with authorities.

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.

Shared Implementation Guidelines

[All Actors]

1. Policy establishment and documentation:

   • a. Identify all external dependencies (third-party libraries, APIs, models, datasets, hosting infrastructure).

   • b. Develop formal Supply Chain Risk Management (SCRM) policies that address: Selection and onboarding of third parties, Security posture assessments, Requirements for transparency and attestations.

2. Approval and Governance:

   • a. Define roles and responsibilities for approving and overseeing the SCRM policies.

   • b. Involve legal, compliance, and risk functions in formal policy approvals.

3. Communication and Training

   • a. Disseminate SCRM policies to relevant internal teams.

   • b. Provide role-based training on how to apply policies during procurement, development, integration, and deployment.

4. Application and Enforcement:

   • a. Ensure third-party suppliers are vetted through standardized due diligence (e.g., questionnaires, evidence-based audits).

   • b. Apply security clauses and SLAs in contracts.

   • c. Integrate enforcement into procurement workflows and automated pipelines (e.g., software composition analysis).

5. Monitoring, Evaluation, and Updating:

   • a. Establish continuous monitoring mechanisms for suppliers (e.g., vulnerability feeds, breach intelligence).

   • b. Conduct annual reviews or sooner if there are: Major supplier changes, Regulatory updates, Security incidents.

   • c. Maintain version-controlled documentation of policy updates.

Implementation Guidelines for Cloud Service Providers (CSP)

1. Maintain and enforce robust SCRM policies for their own supply chain (e.g., hardware vendors, hypervisor software, co-tenants).

2. Provide secure service catalogs with pre-vetted services and infrastructure.

3. Offer transparency to customers via: Attestation services (e.g., Confidential Computing attestations), Continuous compliance dashboards, SLAs on infrastructure and component patching.

4. Document internal supplier reviews and make summaries available to customers upon request.

[All Actors]

1. Policy establishment and documentation:

   • a. Identify all external dependencies (third-party libraries, APIs, models, datasets, hosting infrastructure).

   • b. Develop formal Supply Chain Risk Management (SCRM) policies that address: Selection and onboarding of third parties, Security posture assessments, Requirements for transparency and attestations.

2. Approval and Governance:

   • a. Define roles and responsibilities for approving and overseeing the SCRM policies.

   • b. Involve legal, compliance, and risk functions in formal policy approvals.

3. Communication and Training

   • a. Disseminate SCRM policies to relevant internal teams.

   • b. Provide role-based training on how to apply policies during procurement, development, integration, and deployment.

4. Application and Enforcement:

   • a. Ensure third-party suppliers are vetted through standardized due diligence (e.g., questionnaires, evidence-based audits).

   • b. Apply security clauses and SLAs in contracts.

   • c. Integrate enforcement into procurement workflows and automated pipelines (e.g., software composition analysis).

5. Monitoring, Evaluation, and Updating:

   • a. Establish continuous monitoring mechanisms for suppliers (e.g., vulnerability feeds, breach intelligence).

   • b. Conduct annual reviews or sooner if there are: Major supplier changes, Regulatory updates, Security incidents.

   • c. Maintain version-controlled documentation of policy updates.

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.

Shared Implementation Guidelines

[All Actors]

1. Establish formal approval workflows for SSRM policy changes, ensuring executive and legal stakeholder review.

2. Develop and document a comprehensive Supply Chain Security Risk Management (SSRM) policy that outlines procedures for identifying, assessing, and mitigating risks related to the supply chain.

3. Ensure the SSRM policy aligns with organizational goals and regulatory requirements, providing clear guidance on roles, responsibilities, and risk tolerance.

4. Regularly review and update the SSRM policy to adapt to changes in regulations, industry standards, and emerging threats.

5. Communicate the SSRM policy to all relevant stakeholders, ensuring that they understand their responsibilities in maintaining supply chain security.

6. Implement training programs to ensure employees and third-party vendors are familiar with the SSRM policy and procedures.

Implementation Guidelines for Cloud Service Providers (CSP)

Role Specific:

1. Establish infrastructure foundation SSRM procedures covering hardware procurement security policies, data center operational requirements, physical security protocols, and multi-tenant isolation standards specific to foundational infrastructure operations.

2. Document shared responsibility model policies including customer security boundary definitions, infrastructure control ownership matrices, customer audit facilitation procedures, and compliance support protocols for all AI ecosystem customer types (MP, OSP, AP, AIC).

3. Create multi-customer service delivery procedures including Infrastructure Assurance Documentation compilation requirements, compliance certification maintenance protocols, and customer-specific regulatory support procedures across multiple jurisdictions and standards.

4. Establish infrastructure resilience SSRM policies covering disaster recovery procedures, business continuity protocols, infrastructure monitoring standards, and capacity management security requirements supporting critical AI workloads for all customer types.

[All Actors]

1. Establish formal approval workflows for SSRM policy changes, ensuring executive and legal stakeholder review.

2. Develop and document a comprehensive Supply Chain Security Risk Management (SSRM) policy that outlines procedures for identifying, assessing, and mitigating risks related to the supply chain.

3. Ensure the SSRM policy aligns with organizational goals and regulatory requirements, providing clear guidance on roles, responsibilities, and risk tolerance.

4. Regularly review and update the SSRM policy to adapt to changes in regulations, industry standards, and emerging threats.

5. Communicate the SSRM policy to all relevant stakeholders, ensuring that they understand their responsibilities in maintaining supply chain security.

6. Implement training programs to ensure employees and third-party vendors are familiar with the SSRM policy and procedures.

From CCM: Implementation Guidelines. Applicable to all service models: The SSRM is pivotal in ensuring comprehensive and effective cybersecurity risk management. The CSC and CSP jointly engage in implementing, managing, and monitoring the cloud services. The various controls (e.g., from the CCM) should be performed by one party or the other, by both parties independently, or by both parties in a dependent manner.

The SSRM serves as the key mechanism to:

• a. comprehensively elaborate the controls necessary to implement, use, manage, and monitor the cloud services in a secure manner

• b. establish and document a common agreement between the CSP and CSC about their respective responsibilities and expectations regarding the controls

• c. serve as the basis for contractual service agreement and ongoing contractual management and compliance

• d. support effective ongoing control execution, management, monitoring, and assessment activities

• e. facilitate rapid and effective IR and management through clear delineation of responsibilities and communication protocols

• f. foster transparency regarding responsibilities and relationship expectations

Other parties engaged by the CSP or CSC may also be involved in supporting the delivery of cloud services. For example, a SaaS service provided by one CSP may involve the use of another CSP to provide underlying IaaS services. The security responsibilities of any supporting service providers in the supply chain should also be reflected in the SSRM.

Given the SSRM’s critical role in supporting effective cloud security practices, the CSC and CSP should establish and maintain policies and procedures for the application of the SSRM across their respective cloud services. This ensures consistency and adequate coverage across all services.

The specific SSRM policies and procedures needed for the CSP or CSC may be influenced by a number of factors. They should align with and augment broader organizational policies and procedures for procurement and contract management, third-party risk management, and cybersecurity risk management to adequately address the unique considerations and risks of cloud services.

Further, the rigor and comprehensiveness of an organization’s SSRM policies and procedures should be commensurate with the risks, complexity, and criticality of the cloud services it uses or provides. For example, the SSRM policies and procedures of a CSC that uses a few non-critical SaaS services do not need to be as extensive and rigorous as a CSC whose business fundamentally relies on extensive IaaS. Additionally, the CSC’s expectations for security program management will drive the scope and rigor of the SSRM policies and procedures.

The CSP’s policies and procedures should recognize and take into consideration the many CSP- and CSC-specific circumstances that may arise in their cloud service implementations. In particular, exceptions to policies and procedures should be formally managed and approved at the appropriate level of management. This guidance is particularly relevant to contractual commitments between the parties that engender potentially more risk to the CSP or CSC (e.g., compromises a small organization may need to make due to lack of negotiating leverage).

The SSRM policies and procedures should be documented, reviewed and updated at least annually to ensure alignment with the evolving cloud security landscape and to reflect changes in cloud technology, regulations, and risks. Updates should consider and incorporate lessons learned from the CSP’s own cloud service implementations, as well as current industry standards and guidance (e.g., current CCM versions and implementation guidelines). Additionally, if a significantly large, complex, and/or business-critical cloud services implementation is contemplated, the CSP may first want to review existing SSRM policies and procedures to ensure that they adequately address the anticipated risks and complexity.

The need to implement and maintain SSRM policies and procedures is the same for all cloud service models, however there may be differences in the specific procedures needed for different cloud service models or for specialized cloud services obtained (e.g., IDaaS). For example, the SSRM procedures employed to manage an IaaS implementation may be more extensive than for a SaaS implementation given the greater responsibilities placed on the CSC under the IaaS model.

Policies should include (but not limited to) provisions on the following:

• a. organizational SSRM risk management objectives

• b. integration and alignment of SSRM policy and procedures with procurement, legal, third-party risk management, and cyber risk management policies and procedures

• c. how the SSRM is integrated and aligned with service contracts

• d. roles and responsibilities for SSRM implementation across the cloud implementation lifecycle (i.e., in due diligence, contracting, implementation, management and monitoring, and service termination)

• e. definition of risk levels applicable to the extent and rigor of due diligence, management, and monitoring activities and procedures

• f. how the SSRM is reviewed, validated, and maintained in collaboration with the CSP over the lifecycle of a cloud service implementation (e.g., by different risk levels)

• g. how exceptions to SSRM policy and/or issues and exceptions with respect to the allocation or performance of responsibilities are identified and managed

• h. reporting requirements for SSRM program activities and performance

• i. approval levels required for SSRM-related decisions

STA-03: SSRM Supply Chain

Control Specification

Apply, document, implement and manage the SSRM throughout the supply chain.

Shared Implementation Guidelines

[All Actors]

1. Apply the SSRM policy to manage risks throughout the entire supply chain, from the selection of suppliers to the delivery of products and services.

2. Implement processes to regularly assess the security posture of key suppliers and partners, ensuring they meet organizational security and compliance standards.

3. Document the identification and categorization of supply chain risks based on their potential impact on business operations and security.

4. Develop and document mitigation strategies to address high-priority supply chain risks and vulnerabilities.

5. Implement monitoring mechanisms to track supply chain security performance, ensuring continuous improvement.

Implementation Guidelines for Cloud Service Providers (CSP)

Role Specific:

1. Apply SSRM requirements to physical infrastructure and hardware suppliers by: Implementing security standards for data center operators and hardware manufacturers, Establishing security requirements for global network and connectivity providers, Applying consistent security controls across all regions and availability zones.

2. Document infrastructure SSRM processes covering hardware lifecycle management workflows, physical security procedures, multi-tenant isolation mechanisms, and infrastructure compliance validation across the entire foundational platform.

3. Manage the cloud platform ecosystem through: Continuous security monitoring of overall infrastructure operations, Coordinated incident response across multiple regions and services, Transparency reporting and compliance certification maintenance.

4. Implement foundational infrastructure SSRM monitoring covering hardware integrity validation metrics, physical security compliance verification, and multi-tenant isolation effectiveness unique to foundational infrastructure operations supporting the entire AI ecosystem.

[All Actors]

1. Apply the SSRM policy to manage risks throughout the entire supply chain, from the selection of suppliers to the delivery of products and services.

2. Implement processes to regularly assess the security posture of key suppliers and partners, ensuring they meet organizational security and compliance standards.

3. Document the identification and categorization of supply chain risks based on their potential impact on business operations and security.

4. Develop and document mitigation strategies to address high-priority supply chain risks and vulnerabilities.

5. Implement monitoring mechanisms to track supply chain security performance, ensuring continuous improvement.

From CCM: Implementation Guidelines. Applicable to all service models: CCM control STA-02 is the primary control whereby the SSRM for a given cloud service implementation is documented, implemented, and managed.

SSRM Documentation.
CCM controls STA-03 and STA-04 provide input to this control in the form of SSRM guidance from the CSP to the CSC (STA-03), and the CSP and CSC working together to specifically delineate control ownership and responsibilities for all CCM controls (STA-04).

For controls that are CSC-owned, the CSP should provide it with clear and concise guidance on expectations for the CSC’s SSRM responsibilities.

For controls that are CSP-owned or “Shared (Independent),” the CSP is responsible for documenting those for which they are fully or partially responsible. This documentation is developed under control STA-03 to fully document the service offering and provide SSRM guidance to prospective CSCs. The CSP should specifically document the responsibilities of any third party it has engaged to fulfill a control responsibility. Such documentation should address, in particular, any necessary coordination between the third party, the CSC, and the CSP.

For those controls that are “Shared (Dependent),” the CSP should collaborate with the CSC to ensure that each party’s responsibilities are fully documented and consistent with the delineation of responsibilities developed under STA-04.

SSRM documentation should also address or reference service level expectations, workload management, contact, escalation, supporting tools, reporting, or other information that may be necessary or helpful in managing the CSC’s and CSP’s respective responsibilities.

To ensure adequate coverage, all CCM controls should be addressed in the SSRM, even if specifically noted to be not applicable. Further, the delineation of responsibilities in the SSRM should be consistent with any contractual terms agreed to by the parties under STA-09, or may be incorporated directly or by reference in the contract. The CSC and CSP may defer documenting certain details of the SSRM until after the contract is executed or the service is implemented, however, the SSRM should always remain consistent with the contractual agreement.

SSRM Implementation and Management.
Once agreed to by the CSP and CSC, the SSRM for a given cloud service implementation guides many aspects of the ongoing relationship.

Each party is responsible for implementing, managing, monitoring, and auditing their respective responsibilities for each CCM control as delineated in the SSRM (see STA-06). If questions or issues arise regarding control responsibility, the SSRM and contract agreement should be consulted to address and resolve any ambiguities. The CSP and CSC should review their supply chain agreement, and the associated SSRM for the services, at least annually (see STA-10). The SSRM should be updated as necessary to address any changes or clarifications in the shared security responsibilities. If an SSRM requires an update, the CSP should determine if the update is specific to a given CSC implementation, or if the SSRM for the service offering at large should be updated (see STA-03).

The CSP may choose to implement automated tools or reporting to facilitate the ongoing monitoring and management of the SSRM or the underlying service’s controls.

The need for the CSP and CSC to document, implement, and maintain the SSRM for a cloud service implementation remains the same for all cloud service models. However, the specifics of each SSRM could change from implementation to implementation.

STA-04: SSRM Guidance

Control Specification

Provide SSRM Guidance to the service customers detailing information about the SSRM applicability throughout the supply chain.

Shared Implementation Guidelines

[All Actors]

1. Develop clear and comprehensive SSRM guidance resources that explain how the SSRM framework applies to your products/services and how those requirements extend across your upstream and downstream supply chain.

2. Communicate your SSRM responsibilities to customers by outlining which security controls you implement and how they protect customer data, as opposed to which controls remain within the customer’s responsibility domain.

3. Provide transparency into supply‑chain SSRM applicability by documenting how SSRM requirements flow down to your own suppliers, partners, and third‑party service providers, including any inherited or shared controls.

4. Ensure customers have easy access to SSRM guidance through documentation portals, customer support channels, technical repositories, or service onboarding materials.

5. Maintain and update SSRM guidance regularly to reflect changes in your services, supply‑chain partners, regulatory obligations, or security practices that may alter SSRM applicability for your customers.

Implementation Guidelines for Cloud Service Providers (CSP)

Role Specific:

1. Develop infrastructure SSRM guidance for all AI customers (APs, MPs, OSPs, AICs) explaining: Shared responsibility model for AI workloads and data, Infrastructure security controls and compliance certifications, Regional compliance and data sovereignty requirements.

2. Create infrastructure service guidance that clearly explains how customers should securely configure and consume CSP services, including network security settings, storage encryption options, and compute isolation requirements for AI workloads.

3. Provide shared responsibility document guidance detailing CSP infrastructure security responsibilities (physical security, hypervisor isolation, network protection) versus customer responsibilities (application security, data encryption, access management) tailored to each customer type’s specific needs.

4. Establish infrastructure security communication channels for ongoing SSRM guidance delivery to all customer types, including infrastructure security updates, compliance certification changes, and evolving best practices for secure cloud infrastructure usage.

[All Actors]

1. Develop clear and comprehensive SSRM guidance resources that explain how the SSRM framework applies to your products/services and how those requirements extend across your upstream and downstream supply chain.

2. Communicate your SSRM responsibilities to customers by outlining which security controls you implement and how they protect customer data, as opposed to which controls remain within the customer’s responsibility domain.

3. Provide transparency into supply‑chain SSRM applicability by documenting how SSRM requirements flow down to your own suppliers, partners, and third‑party service providers, including any inherited or shared controls.

4. Ensure customers have easy access to SSRM guidance through documentation portals, customer support channels, technical repositories, or service onboarding materials.

5. Maintain and update SSRM guidance regularly to reflect changes in your services, supply‑chain partners, regulatory obligations, or security practices that may alter SSRM applicability for your customers.

From CCM v4.1: Control Ownership Rationale. Implementation responsibility for CCM control STA-03 lies solely with the CSP.

Implementation Guidelines. Applicable to all service models: The CSP should develop SSRM guidance documentation for each cloud service offering. The documentation should demonstrate the CSP’s transparency, and clearly articulate expectations for the security responsibilities provided by the CSP and any supporting providers. Controls STA-03 and STA-04 address the development of this guidance.

The SSRM guidance should detail the CSP’s responsibilities with respect to each control for the service offering, as well as the responsibilities that need to be undertaken by any third party in the CSP’s supply chain. The guidance should be as detailed and unambiguous as possible, particularly where a control has a shared responsibility between the CSP and its supply chain.

Any third-party suppliers involved in the delivery of services for the cloud offering should be identified in the SSRM documentation. This information should complement control STA-12, which addresses how the CSP manages the security responsibilities of its suppliers, and STA-09, which addresses the CSP’s commitments for managing its suppliers.

The CAIQ provides a thorough and convenient means for the CSP to document the ownership of the controls for its cloud service offerings.

The need for the CSP to provide SSRM guidance to the CSC for the service offering is the same for all cloud service models.

STA-05: SSRM Control Ownership

Control Specification

Delineate the shared ownership and applicability of all CSA AICM controls according to the SSRM.

Shared Implementation Guidelines

[All Actors]

1. Clearly delineate ownership of SSRM controls across all relevant stakeholder groups to ensure accountability and continuity of implementation, support, and maintenance throughout the AI system lifecycle.

2. Assign control owners to oversee specific SSRM activities, such as risk assessments, security audits, and incident response for supply chain-related issues.

3. Establish regular reporting mechanisms to ensure that control owners provide updates on the status of risk mitigation efforts.

4. Hold control owners accountable for implementing SSRM procedures and ensuring compliance with organizational policies.

5. Document control ownership matrices that clearly map each SSRM control to specific roles, responsibilities, and escalation paths.

Implementation Guidelines for Cloud Service Providers (CSP)

Role Specific:

1. Assign ownership of infrastructure foundation SSRM controls to data center operations teams for physical security, network teams for infrastructure connectivity, and platform teams for multi-tenant isolation and resource management.

2. Establish clear ownership boundaries between infrastructure security, platform services, and customer-facing security responsibilities aligned with the shared responsibility model.

3. Define escalation paths for global security incidents that ensure coordinated response across regions and services while maintaining service availability for AI workloads.

4. Define multi-customer service control ownership between platform teams for customer isolation enforcement, compliance teams for regulatory attestation maintenance, and incident response teams for cross-customer impact management.

[All Actors]

1. Clearly delineate ownership of SSRM controls across all relevant stakeholder groups to ensure accountability and continuity of implementation, support, and maintenance throughout the AI system lifecycle.

2. Assign control owners to oversee specific SSRM activities, such as risk assessments, security audits, and incident response for supply chain-related issues.

3. Establish regular reporting mechanisms to ensure that control owners provide updates on the status of risk mitigation efforts.

4. Hold control owners accountable for implementing SSRM procedures and ensuring compliance with organizational policies.

5. Document control ownership matrices that clearly map each SSRM control to specific roles, responsibilities, and escalation paths.

From CCM: Implementation Guidelines. Applicable to all service models:

SSRM Guidance Documentation.
The CSP should develop SSRM guidance documentation for each cloud service offering. The documentation should demonstrate the CSP’s transparency to the CSC, and clearly articulate expectations for the security responsibilities expected of the CSC.

The SSRM guidance should detail the CSP’s responsibilities with respect to each control for the service offering, as well as the responsibilities that need to be undertaken by any third party in the CSP’s supply chain. The guidance should be as detailed and unambiguous as possible, particularly where a control has a shared responsibility between the CSP and its supply chain.

The SSRM guidance should also detail the CSP’s expectations to be undertaken by the CSC (or, possibly, by the CSC’s supply chain). The guidance should detail the controls where the CSC is expected to be fully responsible, as well as the controls where there is a shared responsibility with the CSP. For areas of shared responsibility, the CSP should provide any expectations for how that shared responsibility will be undertaken and managed.

The below responsibility designations should be documented for each control in the SSRM, and for each cloud service model, as:

• a. CSP-Owned: The CSP is fully responsible for implementing, managing, and assessing the control

• b. CSC-Owned: The CSC is fully responsible for implementing, managing, and assessing the control

• c. Shared (Independent): The CSP and CSC both need to implement the control, but their implementations are independent of one another

• d. Shared (Dependent): The CSP and CSC have joint responsibilities for the implementation, management, and assessment of the control

For some service offerings there may be controls where the CSP undertakes responsibility on a conditional basis or for an additional fee. For example, the CSP may offer backup services as an additional service offering. Any such contingent services or areas where SSRM responsibilities may be determined at a later time should be clear in the SSRM guidance.

The CAIQ provides a thorough and convenient means for CSPs to document the SSRM ownership of the controls for its cloud service offerings. The SSRM product offering guidance may additionally reference other control or product documentation, service level objectives, test or assessment results, compliance mappings, etc.

Providing Guidance to the CSC.
The CSP should provide the SSRM guidance documentation to the prospective CSC. It serves as the basis for the detailed review of SSRM responsibilities between the CSP and the CSC under control STA-05. The documentation may be augmented by other product information, CSP organizational information, technical presentations, sales presentations, etc. over the sales cycle.

The SSRM guidance provided to the CSC is a key component in ensuring transparency and in avoiding later issues related to service responsibilities or contractual terms. The CSP should be prepared to educate and assist the prospective CSC in SSRM principles and implementation in order to effectively allocate, document, and implement their respective SSRM responsibilities.

STA-06: SSRM Documentation Review

Control Specification

Review and validate the SSRM documentation.

Shared Implementation Guidelines

[All Actors]

1. Regularly review and validate SSRM documentation to ensure it accurately reflects current system design, business objectives, threat landscape, and mitigation practices.

2. Conduct a comprehensive review of SSRM-related documents, including risk assessments, mitigation plans, and supplier evaluations.

3. Ensure that all relevant stakeholders have access to the most current and accurate SSRM documentation.

4. Document changes made during the review process and communicate updates to all relevant parties.

Implementation Guidelines for Cloud Service Providers (CSP)

Role Specific:

1. Review and validate Infrastructure Assurance Documentation to ensure accurate representation of physical security controls, hardware integrity measures, multi-tenant isolation capabilities, and shared responsibility matrices for all customer types.

2. Validate infrastructure supply chain documentation including hardware supplier certifications, component provenance records, firmware integrity validations, and vendor security assessments throughout the infrastructure stack.

3. Review multi-customer compliance documentation ensuring accuracy of regulatory attestations (SOC 2, FedRAMP, ISO 27001), audit reports, certification maintenance records, and compliance support capabilities across multiple jurisdictions.

4. Ensure infrastructure resilience documentation accurately reflects current disaster recovery procedures, backup capabilities, failover mechanisms, and business continuity plans supporting critical AI workloads for all ecosystem actors.

5. Validate shared responsibility documentation including customer security obligation matrices, infrastructure boundary definitions, control ownership clarifications, and support procedures for each AI ecosystem actor type (MP, OSP, AP, AIC).

[All Actors]

1. Regularly review and validate SSRM documentation to ensure it accurately reflects current system design, business objectives, threat landscape, and mitigation practices.

2. Conduct a comprehensive review of SSRM-related documents, including risk assessments, mitigation plans, and supplier evaluations.

3. Ensure that all relevant stakeholders have access to the most current and accurate SSRM documentation.

4. Document changes made during the review process and communicate updates to all relevant parties.

From CCM v4.1: Control Ownership Rationale. The CSP and CSC should jointly review the SSRM documentation and finalize responsibilities for the cloud service offering.

Implementation Guidelines. Applicable to all service models: The CSP and CSC should independently and jointly review the SSRM documentation and guidance for each cloud service implementation. For the CSP, these reviews should include any cloud services used for delivering services to the CSC, as well as cloud services used for internal organizational purposes (e.g., cloud-based financial or HR applications).

The SSRM guidance for the cloud service offering under STA-03 and STA-04 should provide the basis for initial review. The CSC should request joint meetings to clarify any questions the CSC may have about control implementation and responsibilities. The CSP should use this feedback to adjust and improve its cloud service SSRM guidance.

The SSRM review should focus particularly on controls designated as “Shared (Dependent)” in the SSRM. Both parties should ensure that they are clear on their respective responsibilities for coordinated operations.

The review may also include discussion of any controls offered on an optional basis by the CSP. The CSP should clearly inform the CSC of additional fees or conditions of such optional services.

The SSRM should be updated to reflect any changes warranted by the review. As needed, the cloud service contract agreement should be updated (under control STA-10) to reflect the change. It is important that the SSRM documentation and contract agreement are aligned and consistent with each other.

STA-07: SSRM Control Implementation

Control Specification

Implement, operate, and audit or assess the portions of the SSRM which the organization is responsible for.

Shared Implementation Guidelines

[All Actors]

1. Identify applicable SSRM controls relevant to organizational role and implement them according to framework requirements.

2. Establish operational procedures for maintaining and executing implemented SSRM controls with defined responsibilities and schedules.

3. Conduct regular audits and assessments of implemented SSRM controls to verify effectiveness and proper operation.

4. Document control implementation and operation including deployment status, operational metrics, and assessment results.

5. Maintain continuous improvement of SSRM controls based on audit findings and evolving requirements.

Implementation Guidelines for Cloud Service Providers (CSP)

Role Specific:

1. Implement infrastructure security controls including physical data center security, hardware integrity verification, network segmentation, hypervisor isolation, and multi-tenant resource protection across all infrastructure platforms.

2. Operate cloud service foundational controls including: Identity and Access Management (IAM) system operations, Encryption key management services, Network security group and firewall management.

3. Implement customer isolation and segmentation controls covering virtual machine separation, network isolation, storage segregation, and cross-tenant security protection throughout the infrastructure platform.

4. Implement AI service-specific controls for: AI/ML platform security configurations, GPU/TPU compute resource isolation, Model training environment security.

5. Operate infrastructure resilience controls including disaster recovery procedures, backup systems, failover mechanisms, and business continuity capabilities supporting critical AI workloads.

[All Actors]

1. Identify applicable SSRM controls relevant to organizational role and implement them according to framework requirements.

2. Establish operational procedures for maintaining and executing implemented SSRM controls with defined responsibilities and schedules.

3. Conduct regular audits and assessments of implemented SSRM controls to verify effectiveness and proper operation.

4. Document control implementation and operation including deployment status, operational metrics, and assessment results.

5. Maintain continuous improvement of SSRM controls based on audit findings and evolving requirements.

From CCM v4.1: Control Ownership Rationale. The implementation and ongoing operation of the SSRM is a shared activity between the CSC and CSP.

Implementation Guidelines. Applicable to all service models:

SSRM Implementation. Once the SSRM has been agreed upon by the CSC and CSP, and a contract agreement is in place, they should begin the implementation of the control environment for the cloud service. The relevant controls should be designed in as the cloud service is built, and tested iteratively as components are put into service.

As is documented in the SSRM, some CCM controls may be implemented independently by the CSP and CSC.

It is important that the CSP and CSC coordinate and collaborate on the implementation of the controls that are identified as “Shared (Dependent)” in the SSRM. These controls may require some degree of coordination over the course of time, so it is important that the design and operation of the controls are well understood by both parties from the onset.

SSRM Operation.
As the cloud service is in operation, the CSP and CSC are each responsible for the operation of the controls assigned to them in the SSRM. The controls identified as “Shared (Dependent)” are operated jointly as agreed by the parties. The “-01” controls for each of the CCM domains describe the control policies and procedures that should guide control operation.

SSRM Management, Monitoring, and Audit. The implementation, operation, and management of the controls should be monitored on an ongoing basis. Additionally, the controls should be audited periodically by an independent audit group within the organization (i.e., a third-line function) and/or an external audit firm. Control design and operation may also be reviewed by an internal enterprise risk management group (i.e., a second-line function).

The Audit and Assurance (A&A) domain provides guidance on control audit programs. Additionally, the CAIQ provides a sound basis for establishing an assessment regimen.

The CSP should expect to share the results of security assessments with both prospective and existing CSCs. The specific information should be agreed to in contracts. Control STA-10 describes the ongoing joint review of the SSRM and contract compliance for an existing cloud service implementation. Controls STA-08, STA-13, and STA-14 further describe ongoing review by the CSC. These reviews provide the opportunity to determine if changes to either the SSRM or contract are warranted.

STA-08: Supply Chain Inventory

Control Specification

Develop and maintain an inventory of all supply chain relationships.

Shared Implementation Guidelines

[All Actors]

1. Establish comprehensive supply chain relationship inventories documenting all vendors, suppliers, service providers, and partners involved in AI system development, deployment, and operations.

2. Maintain detailed relationship records including contact information, service descriptions, contract terms, risk classifications, and dependency mappings for all supply chain entities.

3. Implement regular inventory updates to reflect new relationships, terminated partnerships, service changes, and evolving dependencies across the AI ecosystem.

4. Document relationship interdependencies showing how supply chain entities connect and impact each other within the AI service delivery chain.

5. Maintain an inventory of AI systems, tools, datasets, and dependencies to ensure traceability and accountability throughout the AI system lifecycle.

6. All parties should contribute to and validate an inventory of upstream and downstream entities involved in AI systems.

Implementation Guidelines for Cloud Service Providers (CSP)

Role Specific:

1. Maintain comprehensive inventory of hardware supplier relationships including server manufacturers, storage vendors, networking equipment providers, GPU/TPU suppliers, and component manufacturers with procurement details, warranty terms, and supply chain security documentation.

2. Document data center and facilities relationships covering power suppliers, cooling system vendors, physical security services, and environmental monitoring providers with service level agreements and operational dependencies, etc.

3. Catalog customer relationships across all AI ecosystem actors including Model Providers, OSPs, Application Providers, and AI Customers with infrastructure usage patterns, resource allocation, and shared responsibility matrices.

4. Inventory infrastructure service and support relationships documenting network connectivity providers, maintenance contractors, hardware support services, software licensing vendors, and infrastructure monitoring tools with contact information and service scope.

5. Maintain subcontractor and third-party service relationships covering facilities management, security services, compliance auditors, and specialized infrastructure support providers with contractual obligations and performance metrics.

6. Document global compliance and certification partners: e.g. Audit firms conducting certifications, Regional compliance and regulatory bodies, Industry standards organizations.

[All Actors]

1. Establish comprehensive supply chain relationship inventories documenting all vendors, suppliers, service providers, and partners involved in AI system development, deployment, and operations.

2. Maintain detailed relationship records including contact information, service descriptions, contract terms, risk classifications, and dependency mappings for all supply chain entities.

3. Implement regular inventory updates to reflect new relationships, terminated partnerships, service changes, and evolving dependencies across the AI ecosystem.

4. Document relationship interdependencies showing how supply chain entities connect and impact each other within the AI service delivery chain.

5. Maintain an inventory of AI systems, tools, datasets, and dependencies to ensure traceability and accountability throughout the AI system lifecycle.

6. All parties should contribute to and validate an inventory of upstream and downstream entities involved in AI systems.

From CCM v4.1: Control Ownership Rationale. This control is independently implemented by the CSP and CSC. Each party’s supply chain inventory and inventory management practices are independent of the other.

Implementation Guidelines. Applicable to all service models: The CSP should establish and maintain an inventory of all supply chain relationships. This inventory can be used to support various supply chain management activities including:

• a. recurring due diligence review scheduling and coordination

• b. management of contractual and legal matters (e.g., renewals, notices, disputes)

• c. ongoing management of the SSRM

• d. supply chain risk management program reporting to management

• e. management of licenses

• f. BIA for the business continuity management program

• g. communication, coordination, and escalation during cybersecurity or availability incidents

• h. analysis of supply chain aggregate and concentration risk

The supply chain inventory should generally track the following key information, as needed, in support of the above activities:

• a. internal and supplier contacts (e.g., business owner, relationship manager, legal, technical, support services, emergency)

• b. supplier risk ranking

• c. general contract terms (e.g., contract duration, renewal dates, termination dates, etc.)

• d. license counts or use restrictions

• e. key business process support or dependency information (e.g., in support of BIA)

• f. ongoing requirements and schedules for due diligence, periodic reviews, and monitoring

The CSP may choose to “risk rank” or create a risk-based classification scheme for their suppliers. Risk ranking of suppliers facilitates determining the appropriate level of effort and comprehensiveness for supplier due diligence and ongoing management and monitoring activities. Risk ranking of suppliers also supports analyses of aggregate supply chain risk.

The CSP may implement practices for identifying, or incorporating, supply chain relationships that are established outside of normal organizational procurement practices (so-called “shadow” purchases of products or services).

Maintenance of the supply chain inventory should be embedded in procurement and supplier security management procedures, and responsibilities for inventory maintenance should be clearly established. The inventory should be updated at various key points over the life cycle of the supplier relationship, including contract termination. The inventory should be reviewed and updated, if necessary, at least annually.

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.

Shared Implementation Guidelines

[All Actors]

1. Maintain a detailed AI Service BOM listing all software, data sources, libraries, models, services, and infrastructure components used in each AI system.

2. Include version numbers, sources, licenses, and third-party dependencies to support traceability and vulnerability management.

3. Update the BOM regularly to reflect changes due to retraining, reconfiguration, or infrastructure migration.

4. Ensure BOMs are accessible to relevant engineering, security, and audit stakeholders.

5. Use BOMs as part of incident response, regulatory disclosure, and risk assessment workflows.

6. Integrate BOM management directly with existing asset inventory systems to maintain a single source of truth and avoid data synchronization issues.

Implementation Guidelines for Cloud Service Providers (CSP)

Role Specific:

1. Publish CSP’s AI ethics charter and responsible AI practices related to model hosting, training, and APIs.

2. Provide transparency into AI service capabilities, limitations, and any embedded models or bias mitigations.

3. Enable features for fairness checks, explainability, and model impact assessments where supported.

4. Collaborate with enterprise customers on shared accountability for responsible AI implementation.

5. Maintain AI ethics review boards or responsible innovation programs for cloud-hosted AI offerings.

[All Actors]

1. Maintain a detailed AI Service BOM listing all software, data sources, libraries, models, services, and infrastructure components used in each AI system.

2. Include version numbers, sources, licenses, and third-party dependencies to support traceability and vulnerability management.

3. Update the BOM regularly to reflect changes due to retraining, reconfiguration, or infrastructure migration.

4. Ensure BOMs are accessible to relevant engineering, security, and audit stakeholders.

5. Use BOMs as part of incident response, regulatory disclosure, and risk assessment workflows.

6. Integrate BOM management directly with existing asset inventory systems to maintain a single source of truth and avoid data synchronization issues.

From CCM v4.1: Control Ownership Rationale. CSPs should maintain visibility into all software and hardware components used in delivering their core infrastructure and platform services. This ensures transparency and supports the downstream risk management obligations of customers.

Implementation Guidelines. Applicable to all service models: CSPs should maintain visibility into the components that comprise their service delivery infrastructure, from open-source libraries to commercial software modules and hardware firmware. A comprehensive and regularly updated BOM enables transparency, facilitates rapid vulnerability response, and aligns with national cybersecurity recommendations.

Implementation best practices include (but not limited to):

• a. BOM Governance Process: i.A formal policy for managing the service BOM should be created and documented, including roles and responsibilities. ii.Ownership should be assigned to a dedicated BOM manager or team (e.g., service architect, security officer). iii.BOM processes should be integrated with existing Change Management and Risk Management frameworks.

• b. BOM Scope and Structure:

  • i. Should include components such as:

    • Third-party services (e.g., SaaS, PaaS, IaaS providers)

    • Open-source libraries

    • APIs, SDKs, and runtime environments

    • Infrastructure dependencies (e.g., regions, cloud zones)

    • Internal services/modules

  • ii. Metadata defined for each BOM item, such as:

    • Component Name

    • Version

    • Supplier

    • Licensing

    • Criticality

    • Known vulnerabilities (if any)

• c. Automated BOM Creation and Maintenance:

  • i. Automated tools (e.g., SBOM generators, CI/CD integration tools) should be used to scan and generate BOMs from sources such as development pipelines, including Infrastructure-as-Code (IaC), container images or VM templates or via internal configuration management repositories ii.Ensure all third-party software libraries or binaries used are tracked in internal inventory systems and validated periodically for vulnerability disclosures. iii.Cloud-native tools should be leveraged to enhance visibility and automate BOM generation. iv. Maintain an updated BOM that includes all critical software components, versions, and suppliers used in the delivery of services

• d. BOM Versioning and Change Tracking: i.Maintain version history of BOMs should be maintained. ii.Configuration management controls should be applied to ensure the BOM is updated to reflect changes made to systems and infrastructure iii.configuration management system (CMS) or source control (e.g., Git) should be used to track BOM updates. iv.Triggers for BOM updates should be identified and documented, such as:

  • New component additions

  • Third-party service updates

  • Component deprecations or replacements

• e. BOM Regular Reviews: i.The BOM should be reviewed at least annually or upon:

  • Major service redesigns

  • Component deprecation

  • Regulatory changes

  • Incident response findings ii.Review outcomes and any required actions should be documented.

• f. Communicate BOM to Stakeholders: Service customers should be provided with visibility on relevant service/infrastructure vulnerabilities that require customer attention (either because customer actions are required for vulnerability mitigation or to provide informational awareness)

STA-10: Supply Chain Risk Management

Control Specification

Periodically review risk factors associated with supply chain relationships.

Shared Implementation Guidelines

[All Actors]

1. Establish a structured process to identify and assess risks associated with third-party AI tools, datasets, models, libraries, infrastructure, and service providers.

2. Periodically review supply chain relationships to evaluate exposure to vulnerabilities, data poisoning, model manipulation, licensing issues, and trustworthiness of upstream sources.

3. Maintain an up-to-date inventory of third-party AI dependencies and their associated risk classification.

4. Integrate threat intelligence, software composition analysis, and vendor assessments into the risk management process.

5. Define and test contingency plans for third-party failures, deprecations, or integrity violations that may impact AI system availability or performance.

[Shared between the MP, AP, OSP, CSP]

1. Implement incident response protocols for AI models, services, and cloud platforms to address security breaches or vulnerabilities in the supply chain.

2. Ensure all stakeholders are trained on incident response procedures and that these procedures are regularly tested.

Implementation Guidelines for Cloud Service Providers (CSP)

Role Specific:

1. Maintain a Verified Inventory of Third-Party Infrastructure and Service Components.

2. Provide Supply Chain Transparency and Attestations to Customers.

3. Integrate Threat Intelligence and Vulnerability Feeds into Supplier Monitoring.

[All Actors]

1. Establish a structured process to identify and assess risks associated with third-party AI tools, datasets, models, libraries, infrastructure, and service providers.

2. Periodically review supply chain relationships to evaluate exposure to vulnerabilities, data poisoning, model manipulation, licensing issues, and trustworthiness of upstream sources.

3. Maintain an up-to-date inventory of third-party AI dependencies and their associated risk classification.

4. Integrate threat intelligence, software composition analysis, and vendor assessments into the risk management process.

5. Define and test contingency plans for third-party failures, deprecations, or integrity violations that may impact AI system availability or performance.

[Shared between the MP, AP, OSP, CSP]

1. Implement incident response protocols for AI models, services, and cloud platforms to address security breaches or vulnerabilities in the supply chain.

2. Ensure all stakeholders are trained on incident response procedures and that these procedures are regularly tested.

From CCM v4.1: Control Ownership Rationale. This control is independently implemented by the CSP and CSC. Each party’s review of its own supply chain risks is independent of the other.

Implementation Guidelines. Applicable to all service models: Supply chain risk is significant for most organizations. The assessment and management of these risks is not complete when the contract with a supplier is signed. There should be an ongoing program in place to monitor and manage supply chain risk.

The policies, procedures, and results from reviewing CSP supply chain risk will be the subject of initial due diligence reviews by the prospective CSC. The CSP should be transparent in these practices.

The CSP should implement procedures, and allocate sufficient resources with the requisite knowledge and experience, to manage and monitor their supply chain relationships to a degree and extent commensurate with criticality (reference control STA-07).

Examples of supplier risk factors that should be assessed on a periodic basis include:

• a. changes in a supplier’s business posture that could pose adverse risk to the organization (e.g., financial condition, reputation, adverse news, compliance/regulatory issues, key personnel loss, business relationships, consumer complaints)

• b. supplier’s financial statements, independent audit reports, pooled/shared assessments, independent control test reports, and internal scorecards and assessments

• c. supplier’s adherence to service level agreements, product specifications, performance metrics, resource level/skill commitments, and quality expectations

• d. Supplier’s software supply chain risk management practices for ensuring software integrity, traceability, and provenance (e.g., software build practices, component management, and use of Software Bill of Materials (SBOMs))

• e. supplier’s program and ability to manage its own suppliers and partners (fourth parties) and the risks those fourth parties may pose

• f. supplier’s or fourth-party foreign-based operations and activities

• g. critical dependencies on the supplier that may warrant the development of alternative solutions or exit strategies and plans

Reference controls STA-13 and STA-14 regarding the periodic review of supplier IT governance policies and procedures, and supplier security programs, respectively. Various industry references and standards are available that provide more guidance on ongoing supplier management and monitoring, and for structuring supply chain risk management programs more broadly.

On-site visits and independent audits (if provided for in the contract) may be warranted for suppliers of critical products or services.

Any concerns, contract exceptions, policy exceptions, or other risks identified in the reviews should be reported to the contract owner and other responsible management, as warranted.

In addition to assessing the ongoing risks associated with specific suppliers, It is recommended to periodically evaluate aggregate risk exposure across all suppliers. Such analyses may focus on vendor, nth-party, geographic, foreign-based, or other risk concentration factors and dependencies than span the organization’s suppliers.

It is recommended that supply chain risk management activities align and be integrated with broader enterprise risk management programs.

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

Shared Implementation Guidelines

[All Actors]

1. Develop standardized contract templates that include all required STA-10 provisions as baseline requirements for all supply chain agreements. Incorporate all required provisions into service agreements including scope definition, service characteristics, geographic locations, and business relationship terms for all supply chain partnerships.

2. Include comprehensive requirements in all service agreements, specifically referencing SSRM compliance obligations, required information security standards, and needed controls, along with other key terms such as service scope, change management, monitoring, incident response, audit rights, termination, interoperability, data privacy, and operational resilience.

3. Maintain a repository of negotiated contract clauses for each STA-10 requirement to ensure consistency and leverage best practices across all agreements. Establish logging and monitoring requirements in agreements specifying data collection obligations, retention periods, access rights, and reporting frequencies.

4. Implement a process to update standard contractual terms when SSRM requirements, security standards, or regulatory obligations change. Define change management processes in contractual terms including notification procedures, approval workflows, impact assessments, and rollback provisions for service modifications.

5. Define approval workflows that require security and legal stakeholders to confirm STA-10 compliance before contracts are executed.

6. Define service termination procedures including data return/destruction, transition assistance, and post-termination obligations.

Implementation Guidelines for Cloud Service Providers (CSP)

Role Specific:

1. Include infrastructure resource and capacity provisions in agreements with AI ecosystem customers (MP, OSP, AP, AIC) specifying compute guarantees, storage allocation terms, network performance baselines, and scaling commitments for AI workloads.

2. Define shared responsibility matrix terms in contracts clearly delineating CSP infrastructure obligations versus customer application-layer responsibilities, including security boundary definitions and control ownership.

3. Specify infrastructure compliance and certification provisions including regulatory attestation delivery (SOC 2, FedRAMP, ISO 27001), compliance reporting frequencies, and customer audit facilitation for infrastructure components.

4. Establish multi-tenancy and isolation terms covering customer workload separation guarantees, resource contention protections, data segregation requirements, and cross-tenant security provisions.

5. Define infrastructure lifecycle and maintenance provisions including hardware refresh schedules, planned maintenance notification procedures, emergency maintenance protocols, and infrastructure update impact assessments.

6. Include disaster recovery and business continuity terms specifying infrastructure resilience commitments, backup and recovery capabilities, geographic redundancy options, and service restoration timelines.

[All Actors]

1. Develop standardized contract templates that include all required STA-10 provisions as baseline requirements for all supply chain agreements. Incorporate all required provisions into service agreements including scope definition, service characteristics, geographic locations, and business relationship terms for all supply chain partnerships.

2. Include comprehensive requirements in all service agreements, specifically referencing SSRM compliance obligations, required information security standards, and needed controls, along with other key terms such as service scope, change management, monitoring, incident response, audit rights, termination, interoperability, data privacy, and operational resilience.

3. Maintain a repository of negotiated contract clauses for each STA-10 requirement to ensure consistency and leverage best practices across all agreements. Establish logging and monitoring requirements in agreements specifying data collection obligations, retention periods, access rights, and reporting frequencies.

4. Implement a process to update standard contractual terms when SSRM requirements, security standards, or regulatory obligations change. Define change management processes in contractual terms including notification procedures, approval workflows, impact assessments, and rollback provisions for service modifications.

5. Define approval workflows that require security and legal stakeholders to confirm STA-10 compliance before contracts are executed.

6. Define service termination procedures including data return/destruction, transition assistance, and post-termination obligations.

From CCM v4.1: Control Ownership Rationale. The CSC and CSP should jointly negotiate and execute a contractual agreement that addresses the security provisions for the cloud service offering.

Implementation Guidelines. Applicable to all service models:

• a. General Contract Matters:

  • i. The contract for the cloud service offering is the legally binding agreement between the CSC and CSP. It is important that the contract agreement and SSRM are consistent. An expectation established in the SSRM in the sales or due diligence phases leading up to contract may have no force or effect if not captured in the contract. In some cases the SSRM may be included as an exhibit or attachment to the contract. The CSP and CSC should both cross check that all CCM control responsibilities in the SSRM are covered and accurately reflected in the proposed contract.

  • ii. The contract should cover matters beyond just SSRM and security considerations, such as payment terms, limitations of liability, intellectual property rights, etc. The CSP will generally provide the initial proposed contract document, along with any exhibits and referenced provisions (e.g., service offering descriptions maintained online). The CSC may also have template provisions drafted that address its specific requirements or regulatory expectations. Attorneys (either inside counsel or outside counsel) will likely be involved in the negotiating process and review of the final document before signature. It is advisable to engage legal counsel that has prior experience with cloud service agreements and information security matters.

• b. Common SSRM and Security Provisions: Depending on the cloud service model, nature and scope of the specific services involved, and the distribution of security responsibilities, the contract may address many of the CCM control domains. For example, data backup frequency, storage location, and immutability may be addressed for SaaS services or if included in the service offering for IaaS services. Backups may otherwise be the responsibility of the CSC and not specifically addressed in the contract.

A non-exhaustive list of security provisions that should be addressed in a contract for cloud services include:

• a. requirements for HR security practices, to include training and awareness, background checks, termination procedures, insider threat management, etc.

• b. SLAs for availability and support response for issues of various types, to include penalties for failure to meet SLAs

• c. non-disclosure and confidentiality provisions appropriate to the types and manner of information being shared

• d. data protection and data privacy considerations, to include limitations on data storage locations (e.g., cross-border data transfer), environment segregation, CSC segregation, data access, data use, and data disposal

• e. requirements for compliance with laws, regulations, standards, or other contracts (e.g., license or subcontract agreements)

• f. implementation and maintenance of technical controls, such as logging and monitoring, network service protections, etc.

• g. where applicable, requirements for Confidential Computing and workload isolation

• h. joint maintenance and monitoring responsibilities for network connections, APIs, data transfer, and access control interfaces

• i. responsibilities, communications, and restrictions related to change management

• j. clauses for threat and vulnerability management and threat intelligence information exchange

• k. requirements for security incident reporting, to include thresholds, minimum timeframes, and escalation paths, as well as expectations for coordination and information sharing in IR

• l. maintenance of BC and DR plans by the CSP, periodic recovery plan testing, and any expectations for joint or bilateral testing with the CSC

• m. requirements for physical and environmental security, to include the availability of redundant services

• n. requirements for the conduct of independent assessments of the CSP’s services, rights for CSC audit, and requirements for demonstrating ongoing compliance with the contract’s security provisions

• o. in alignment with CCM control STA-12, requirements for the CSP to establish and manage the security requirements of its suppliers

• p. any requirements related to contract termination and transition, such as portability and data return expectations

Together, the controls and SSRM provide sound mechanisms for verifying that all requisite security requirements are addressed in the contract agreement.

STA-12: Supply Chain Agreement Review

Control Specification

Review supply chain agreements at least annually, or upon significant changes.

Shared Implementation Guidelines

[All Actors]

1. Establish annual review schedules for all supply chain agreements, contracts, and service level agreements with vendors, suppliers, and partners involved in AI system delivery

2. Define review triggers for agreement updates including significant business changes, regulatory updates, security incidents, vendor changes, or technology modifications

3. Evaluate agreement adequacy by assessing whether current contractual terms address evolving security requirements, data protection needs, and operational dependencies

4. Review contractual obligations including security commitments, liability terms, data handling requirements, incident notification procedures, and termination clauses

5. Update agreements based on review findings, incorporating new security requirements, regulatory changes, lessons learned from incidents, and evolving business needs

6. Document review outcomes including identified gaps, required updates, renegotiation priorities, and timelines for agreement modifications

7. Coordinate cross-functional reviews involving legal, security, procurement, and technical teams to ensure comprehensive agreement evaluation.

Implementation Guidelines for Cloud Service Providers (CSP)

Role Specific:

1. Review infrastructure service agreements with all customer types (MP, OSP, AP, AIC) to ensure shared responsibility matrices, resource allocation terms, and infrastructure security commitments remain appropriate for evolving AI workloads.

2. Evaluate hardware and facilities agreements with suppliers regarding data center operations, equipment lifecycle management, and physical security provisions that support AI infrastructure requirements.

3. Assess multi-tenancy and isolation agreements to verify customer separation guarantees, resource contention protections, and cross-tenant security provisions meet current AI security standards. Review upstream service dependencies (e.g., GPU scheduling systems, orchestration frameworks, container runtimes) to ensure they don’t introduce shared risk across tenants. Validate that these components are governed by supply chain agreements that enforce security and availability commitments.

4. Review infrastructure compliance and certification terms to ensure customer audit rights, compliance reporting obligations, and regulatory attestation provisions support customers’ AI governance needs.

5. Update capacity and scaling agreement terms based on reviews to reflect changes in AI compute demands, new hardware capabilities, and evolving customer performance expectations

[All Actors]

1. Establish annual review schedules for all supply chain agreements, contracts, and service level agreements with vendors, suppliers, and partners involved in AI system delivery

2. Define review triggers for agreement updates including significant business changes, regulatory updates, security incidents, vendor changes, or technology modifications

3. Evaluate agreement adequacy by assessing whether current contractual terms address evolving security requirements, data protection needs, and operational dependencies

4. Review contractual obligations including security commitments, liability terms, data handling requirements, incident notification procedures, and termination clauses

5. Update agreements based on review findings, incorporating new security requirements, regulatory changes, lessons learned from incidents, and evolving business needs

6. Document review outcomes including identified gaps, required updates, renegotiation priorities, and timelines for agreement modifications

7. Coordinate cross-functional reviews involving legal, security, procurement, and technical teams to ensure comprehensive agreement evaluation.

From CCM: Control Ownership Rationale. The annual review of the contractual agreement is a shared activity between the CSP and CSC.

Implementation Guidelines. Applicable to all service models: The CSP and CSC should establish an annual cycle of contract agreement review. This review should consider any issues, risks, or other considerations that may be raised in the ongoing reviews described for controls STA-08 (periodic review of supply chain risk factors), STA-11 (internal control assessments), STA-13 (periodic review of supplier governance policies and procedures), and STA-14 (periodic security assessments).

Any issues of contract non-compliance, inability to meet defined SLAs, or situations where either party’s needs or expectations are not fully met should be discussed and resolved. Ongoing reviews provide the opportunity to maintain full transparency in the business relationship.

Reviews should also address changes in either the CSP’s or CSC’s services or business circumstances that could affect the ongoing relationship. For example, new products or new partnerships may be of interest to the other party.

If required, the contractual agreement should be formally renegotiated and modified to reflect any necessary changes. As warranted, the SSRM should be also updated to reflect any changes made to the contractual agreement to ensure that the two documents remain consistent.

In planning their review cycle activities, the CSP and CSC should consider any advance notice periods, for example, 60-day advance notice of contract termination or service price increases.

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.

Shared Implementation Guidelines

[All Actors]

1. Establish annual internal assessment processes to evaluate conformance with AI supply chain security standards, policies, procedures, and service level agreements across all organizational functions.

2. Define assessment scope and criteria covering policy compliance, procedural effectiveness, control implementation, and service level agreement performance for all AI-related activities.

3. Conduct systematic compliance reviews using standardized assessment frameworks, checklists, and metrics to measure adherence to established standards and identify gaps.

4. Document assessment findings including compliance status, control effectiveness ratings, identified deficiencies, and recommendations for improvement across all assessed areas.

5. Implement corrective action processes to address identified non-conformance issues, track remediation progress, and verify effectiveness of corrective measures.

6. Report assessment results to appropriate stakeholders including management, audit committees, and relevant governance bodies to support continuous improvement and accountability.

Implementation Guidelines for Cloud Service Providers (CSP)

Role Specific:

1. Internally assess the end-to-end process for achieving and renewing global certifications (e.g., SOC 2, ISO 27001, PCI DSS). Validate that: The scope of each audit is correct and complete, All control evidence is gathered and presented accurately to auditors, There is a process for addressing auditor findings before reports are finalized.

2. Assess the Shared Responsibility Model Implementation: Review how effectively the CSP’s operations, support, and documentation ensure customers understand and can fulfill their security responsibilities (security in the cloud). This includes assessing the clarity and accuracy of service-specific security documentation.

3. Perform internal audits of the physical supply chain, including: Vetting and monitoring processes for hardware manufacturers, Security controls at data center facilities (access logs, environmental controls, resilience), Hardware lifecycle management (secure decommissioning of drives).

4. Compliance Evidence Portal: Test the security, accuracy, and reliability of the self-service portal (e.g., AWS Artifact, Azure Compliance Manager) that provides customers with audit reports. Ensure that reports are updated promptly after renewal and that access controls are robust.

5. Test Global Incident Response Effectiveness: Conduct large-scale tabletop exercises that simulate incidents affecting global infrastructure (e.g., a software vulnerability in a hypervisor, a regional outage). Measure the response against public SLAs and internal playbooks to ensure coordination across massive scale.

[All Actors]

1. Establish annual internal assessment processes to evaluate conformance with AI supply chain security standards, policies, procedures, and service level agreements across all organizational functions.

2. Define assessment scope and criteria covering policy compliance, procedural effectiveness, control implementation, and service level agreement performance for all AI-related activities.

3. Conduct systematic compliance reviews using standardized assessment frameworks, checklists, and metrics to measure adherence to established standards and identify gaps.

4. Document assessment findings including compliance status, control effectiveness ratings, identified deficiencies, and recommendations for improvement across all assessed areas.

5. Implement corrective action processes to address identified non-conformance issues, track remediation progress, and verify effectiveness of corrective measures.

6. Report assessment results to appropriate stakeholders including management, audit committees, and relevant governance bodies to support continuous improvement and accountability.

From CCM: Implementation Guidelines. Applicable to all service models: The CSP and CSC should establish an ongoing program of internal control assessment.

The scope and rigor of assessment programs can vary substantially based on the scope and criticality of the cloud service offering, organization size, industry, and regulatory or compliance requirements. Assessment programs may span reviews performed by the security organization (i.e., “first-line” program review); reviews performed by an internal, but independent risk management organization (i.e., “second-line” program review); and audits performed by internal audit teams or independent auditors (i.e., “third-line” program review). The Audit & Assurance (A&A) domain describes recommended audit program controls. The internal program assessment performed under this control should take into consideration the assessment of the CSP’s supply chain performed under control STA-14 to obtain a holistic view of the control environment.

Assessment programs may involve a combination of regular, periodic manual control reviews, as well as elements that are continuous or automated in nature. Manual assessment of controls may include various inspection, sampling, and interviewing techniques. Automated controls and control reporting help ensure continuous assurance of control operation, and should be implemented wherever possible.

All controls covered by the SSRM should be included in the assessment, and all components or elements of the cloud service offering, and related activities, should be addressed. The “-01” CCM controls for each domain describe the control policies and procedures that should guide the assessment of control design and operating effectiveness. Review of the coverage and adequacy of the policies and procedures should be included in the assessment.

The CSP may be asked to assist the CSC in their assessment of those controls identified in the SSRM as “Shared (Dependent)”.

The need for the CSC and CSP to independently assess their SSRM control programs is the same for all cloud service models.

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.

Shared Implementation Guidelines

[All Actors]

1. Establish comprehensive service provider compliance policies covering information security, confidentiality, access control, privacy, audit, personnel, and service level requirements applicable to all supply chain partners.

2. Require contractual commitments from all service providers to comply with organizational security standards, regulatory requirements, and industry best practices relevant to their services.

3. Implement compliance verification processes including regular assessments, audits, and certifications to ensure service providers maintain adherence to required standards.

4. Monitor ongoing compliance through service level monitoring, security assessments, incident reporting, and periodic compliance reviews with all supply chain service providers.

5. Enforce compliance consequences including remediation requirements, service restrictions, or contract termination for service providers who fail to meet compliance obligations.

6. Document compliance status and maintain records of service provider compliance assessments, certifications, and remediation activities for audit and risk management purposes.

Implementation Guidelines for Cloud Service Providers (CSP)

Role Specific:

1. Define Standardized Contractual Terms and Service-Level Agreements (SLAs). Develop clear, standardized contractual terms for all customers that define:

   • The Shared Responsibility Model, explicitly delineating security of the cloud (CSP’s duty) from security in the cloud (customer’s duty).

   • Uptime, availability, and incident response SLAs.

   • Data processing terms that comply with global regulations (e.g., GDPR, CCPA, etc.)

2. Establish comprehensive compliance policies for hardware suppliers, data center operators, network providers, facilities management vendors, subcontracted infrastructure services, and third-party maintenance providers covering information security, confidentiality, access control, privacy protection, audit requirements, personnel screening policies, and service level standards.

3. Document compliance status in Infrastructure Assurance Documentation for handover to all customer types (MP, OSP, AP, AIC), providing foundational evidence of infrastructure supply chain compliance and shared responsibility matrices.

4. Secure the Physical and Hardware Supply Chain. Define and implement a rigorous process for assessing the security of hardware manufacturers, data center operators, and other physical infrastructure providers. This involves: Vetting and auditing hardware suppliers, Ensuring integrity of the hardware from manufacturing to data center installation, Maintaining an internal SBOM for critical infrastructure components.

[All Actors]

1. Establish comprehensive service provider compliance policies covering information security, confidentiality, access control, privacy, audit, personnel, and service level requirements applicable to all supply chain partners.

2. Require contractual commitments from all service providers to comply with organizational security standards, regulatory requirements, and industry best practices relevant to their services.

3. Implement compliance verification processes including regular assessments, audits, and certifications to ensure service providers maintain adherence to required standards.

4. Monitor ongoing compliance through service level monitoring, security assessments, incident reporting, and periodic compliance reviews with all supply chain service providers.

5. Enforce compliance consequences including remediation requirements, service restrictions, or contract termination for service providers who fail to meet compliance obligations.

6. Document compliance status and maintain records of service provider compliance assessments, certifications, and remediation activities for audit and risk management purposes.

From CCM: Control Ownership Rationale. The CSP and CSC should independently implement policies and contract provisions to require that all organizations in their supply chain implement adequate security program controls related to the cloud service offering.

Implementation Guidelines. Applicable to all service models: All organizations involved, directly or indirectly, in implementing the SSRM controls for the cloud service offering should have sound security programs and practices in place. The CSP and CSC should each have policies in place to establish the security program and security control expectations for their suppliers, and implement those policies in contractual agreements.

Policies should consider both direct and indirect suppliers of services (i.e., third-, fourth-, and nth-party relationships). An example of an indirect relationship that should be considered is where there may be a primary supplier for datacenter infrastructure services, but that supplier outsources facility cleaning services. The background screening requirements for employees performing cleaning services (who have direct physical access to sensitive equipment and data) should be addressed.

Both the CSP and CSC should include provisions in their supplier contracts that address the supplier’s requirements for managing the security of their suppliers. Such contract provisions should address both the initial determination that supplier security programs and practices are in place and adequate (initial due diligence), and also the ongoing management and monitoring of suppliers to confirm ongoing compliance (see control STA-11). These supplier management contract considerations should be addressed in the performance of control STA-09, where other contract-related security considerations are also addressed.

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.

Shared Implementation Guidelines

[All Actors]

1. Establish periodic review schedules (annually or based on risk assessment) to evaluate supply chain partners’ IT governance policies, procedures, and compliance frameworks.

2. Assess partner governance maturity including their change management processes, incident response procedures, data governance controls, and security oversight mechanisms.

3. Require standardized evidence handovers from supply chain partners that document their governance practices, including:

   • Current governance policy documentation

   • Compliance attestations and audit reports

   • Risk management and incident response procedures

   • Change control and approval workflows.

4. Verify alignment between partner IT governance practices and your organization’s security requirements, regulatory obligations, and risk tolerance levels.

5. Document governance review outcomes including identified gaps, partner improvement commitments, and any residual risks requiring ongoing monitoring or mitigation.

6. Maintain a governance assurance chain by:

   • Providing downstream partners with summaries of your governance reviews

   • Creating transparency into upstream partner governance status

   • Enabling end-to-end governance visibility for final customers (AICs).

7. Integrate governance review findings into vendor risk assessments, contract negotiations, and ongoing supplier relationship management processes.

Implementation Guidelines for Cloud Service Providers (CSP)

Role Specific:

1. Implement and Maintain a Globally Certified Infrastructure. Obtain and renew comprehensive, internationally recognized security certifications (e.g., SOC 1, SOC 2, SOC 3, ISO 27001, ISO 27017 (cloud security), ISO 27018 (cloud privacy), PCI DSS, FedRAMP) through independent third-party audits.

2. Provide Transparent, Self-Service Access to Compliance Evidence. For example, develop and maintain a secure portal (e.g., AWS Artifact, Azure Compliance Manager, GCP Assurance Reports) where customers can instantly access and download the CSP’s latest compliance reports and certifications on demand.

3. Publish a Clear Shared Responsibility Model. Clearly and publicly document the division of security responsibilities:

   • CSP Responsibility: Security of the Cloud (global infrastructure, hardware, software, facilities).

   • Customer Responsibility: Security in the Cloud (their data, platform configuration, identity & access management, application security).

4. Secure the Physical and Hardware Supply Chain: Define and implement a process for assessing the security of hardware manufacturers, data center operators, and other physical infrastructure providers that form the foundation of the cloud. (This is a critical but often hidden part of the CSP’s supply chain security).

5. Maintain a Public and Detailed Service-Specific BOM/Compliance: Provide detailed documentation on the security properties of individual services (e.g., “How encryption is handled in S3 vs. EBS”). This goes beyond the infrastructure-level certifications to help customers build securely.

[All Actors]

1. Establish periodic review schedules (annually or based on risk assessment) to evaluate supply chain partners’ IT governance policies, procedures, and compliance frameworks.

2. Assess partner governance maturity including their change management processes, incident response procedures, data governance controls, and security oversight mechanisms.

3. Require standardized evidence handovers from supply chain partners that document their governance practices, including:

   • Current governance policy documentation

   • Compliance attestations and audit reports

   • Risk management and incident response procedures

   • Change control and approval workflows.

4. Verify alignment between partner IT governance practices and your organization’s security requirements, regulatory obligations, and risk tolerance levels.

5. Document governance review outcomes including identified gaps, partner improvement commitments, and any residual risks requiring ongoing monitoring or mitigation.

6. Maintain a governance assurance chain by:

   • Providing downstream partners with summaries of your governance reviews

   • Creating transparency into upstream partner governance status

   • Enabling end-to-end governance visibility for final customers (AICs).

7. Integrate governance review findings into vendor risk assessments, contract negotiations, and ongoing supplier relationship management processes.

From CCM v4.1: Control Ownership Rationale. This control should be independently implemented by both the CSC and CSP. Each party’s review of the IT governance policies and procedures of their suppliers is independent of each other.

Implementation Guidelines. Applicable to all service models: As a part of managing the ongoing risks of its supply chain described for control STA-08, the CSP should periodically evaluate the IT governance policies and procedures of their key suppliers. This control should be performed by the CSP in coordination with control STA-08.

IT governance policies and procedures guide, bound, and provide oversight for an organization’s overall approach to technology and cybersecurity risk management. It is important that the IT governance practices of the CSP’s key suppliers are in alignment with its own needs and the needs of the CSC.

The following supplier IT governance topics may be reviewed periodically by the CSP:

• a. requirements for periodic reporting of technology, cybersecurity, and risk matters to the board or governing authority

• b. alignment of IT to organizational mission, strategy, and tactical initiatives

• c. requirements for the escalation of risk matters to management and the board or governing authority

• d. the establishment of a formal risk appetite and risk tolerance by the board or governing authority

• e. compliance with relevant laws, regulations, and contractual agreements

• f. roles and responsibilities for technology, cybersecurity, and risk management programs

• g. coverage and extent of IT policies and procedures

• h. alignment with and adherence to industry standards and best practices

• i. practices for determining the adequacy of resources (staff and other IT investments)

Reference control STA-08 for related supplier review considerations and the Governance, Risk, and Compliance (GOV) control domain for further guidance on IT governance matters.

STA-16: Supply Chain Data Security Assessment

Control Specification

Define and implement a process for conducting risk-based security assessments of the supply chain.

Shared Implementation Guidelines

[All Actors]

1. Establish and conduct risk‑based security assessments across the entire supply chain, including all AI‑related third‑party vendors, tools, datasets, APIs, and managed services, to proactively identify and prioritize security risks.

2. Assess whether supply‑chain entities apply appropriate security and privacy controls, such as encryption, access management, data minimization, monitoring, and secure development practices, based on the risk level of the data, systems, or services involved.

3. Implement mandatory contractual and governance requirements for all suppliers, ensuring commitments to data protection, breach notification, secure data handling, and responsible disposal of sensitive assets throughout the supply chain lifecycle.

4. Continuously validate how data flows through the supply chain, including transmission, processing, and storage paths, to ensure confidentiality, integrity, and resilience against tampering or unauthorized access.

5. Maintain a central inventory of all suppliers involved in data ingestion, labeling, model training, or hosting, and categorize them based on risk exposure.

Implementation Guidelines for Cloud Service Providers (CSP)

Role Specific:

1. Train internal teams including cloud platform operators, infrastructure engineers, security operations staff, data center personnel, and customer support teams on SSRM policies and supply chain security risks.

2. Provide ongoing security awareness training for all roles involved in provisioning, managing, and securing cloud infrastructure that hosts AI workloads and applications.

3. Require contractual commitments from third-party vendors (hardware suppliers, network providers, facilities management, subcontracted services) to maintain SSRM-compliant training for personnel accessing CSP infrastructure.

4. Verify vendor training compliance through security assessments, facility audits, and certifications from infrastructure suppliers and service partners.

5. Coordinate with customers (Model Providers, OSPs, APs) to ensure they understand shared responsibility models and security training requirements for their use of CSP services.

[All Actors]:

1. Establish and conduct risk‑based security assessments across the entire supply chain, including all AI‑related third‑party vendors, tools, datasets, APIs, and managed services, to proactively identify and prioritize security risks.

2. Assess whether supply‑chain entities apply appropriate security and privacy controls, such as encryption, access management, data minimization, monitoring, and secure development practices, based on the risk level of the data, systems, or services involved.

3. Implement mandatory contractual and governance requirements for all suppliers, ensuring commitments to data protection, breach notification, secure data handling, and responsible disposal of sensitive assets throughout the supply chain lifecycle.

4. Continuously validate how data flows through the supply chain, including transmission, processing, and storage paths, to ensure confidentiality, integrity, and resilience against tampering or unauthorized access.

5. Maintain a central inventory of all suppliers involved in data ingestion, labeling, model training, or hosting, and categorize them based on risk exposure.

From CCM v4.1: Control Ownership Rationale. This control should be independently implemented by both the CSP and CSC. Each party’s review of the security programs of their suppliers is independent of each other.

Implementation Guidelines. Applicable to all service models: As a part of managing the ongoing risks of its supply chain described for control STA-08, the CSP should periodically, or on an ongoing basis, assess the security programs and controls of their suppliers.

The policies, procedures, and results of ongoing CSP reviews of their supplier’s security will, in most circumstances, be the subject of initial due diligence reviews by prospective CSCs, and ongoing due diligence reviews by existing CSC customers. The CSP should be transparent in these practices.

Where possible, the ability for a CSP to assess the security of a supplier’s controls should be automated and provided as close to real-time as possible. Control reporting, alerting mechanisms, and other such continuous control monitoring methods should be built into cloud service or other IT offerings wherever possible. Where a supplier’s controls are not automated, or control operation data is not provided proactively by the supplier, periodic manual review and assessment may be required. Such reviews should generally be performed by the CSP in coordination with control STA-08.

The general objectives of the review are to determine if the supplier’s security program and practices remain sufficient for the CSP’s requirements, and that the supplier is complying with the expectations set forth in the SSRM and in the contract agreement. The reviews should include all direct and indirect suppliers that the CSP relies upon to provide key services (e.g., infrastructure hosting).

The following supplier security program and security control elements may be reviewed periodically by the CSP:

• a. security policies, procedures, standards, and ongoing compliance with industry standards and practices

• b. the supplier’s risk management, risk assessment, control assessment and testing, and exception management procedures

• c. documentation and testing of the specific technical controls implemented to support the product or service (e.g., identity and access management, network design and security)

• d. configuration control, change management, product lifecycle, and operations policies, procedures, and controls

• e. software supply chain risk management practices for ensuring software integrity, traceability, and provenance (e.g., software build practices, component management, and use of Software Bill of Materials (SBOMs))

• f. the supplier’s own supply chain risk management policies and procedures, supplier reviews of their suppliers, and procedures employed by the supplier to manage and monitor their suppliers on an ongoing basis

• g. supplier BC program plan, DR procedures, and reports of the testing of IR and recovery plans, to include any bilateral or joint testing with customers

• h. threat management, logging, monitoring, and event analysis capabilities and procedures

• i. supplier incident management procedures, incident reporting standards, and any provided reports of security or availability incidents

• j. supplier human resources management practices, to include its acceptable use policies, insider threat management program, and practices for noncompliance with policies

• k. datacenter, environmental, and physical practices and controls

• l. privacy and data management policies, procedures, and controls m.independent security audit practices

The specific elements reviewed will depend on the SSRM, the contract agreement, and the criticality of the product or service offering. A variety of methods of review, assessment, and testing may be employed depending on the level of due diligence required. Reviews may involve on-site visits, reviews of independent audits or assessments provided by the supplier, reviews of shared assessments, reviews of supplier-provided reports and control tests, and direct control testing.

Reference control STA-08 for related supplier review considerations and the policy-relevant controls for each CCM control domain for guidance on specific security control policies and procedures.

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.

Shared Implementation Guidelines

[All Actors]

1. Establish a unified vulnerability-management framework that covers identification, classification, remediation and reporting.

2. Define clear roles and responsibilities for discovery, assessment, triage and patch deployment.

3. Implement automated scanning tools and complementary manual assessments to continuously monitor source code, container images, model artefacts, APIs, and third-party dependencies for known vulnerabilities (e.g., CVEs) and emerging threats identified via threat-intelligence feeds.

4. Prioritize vulnerabilities using a risk-based approach and define remediation SLAs aligned with business impact and exploitation likelihood.

5. Maintain a centralized tracking system with severity, deadlines, remediation status, and validation results visible to all relevant parties.

6. Review and synchronize the framework and policies at least annually, and following any significant changes, incorporating lessons learned.

7. Collaborate to remediate shared-stack vulnerabilities (e.g., APIs, orchestration, cloud infrastructure) within agreed timelines.

Implementation Guidelines for Cloud Service Providers (CSP)

1. Apply the vulnerability management framework to all areas of AI model development, deployment, application services, and cloud infrastructure.

2. Regularly assess and address vulnerabilities in AI models, applications, and cloud environments through automated and manual scanning processes.

3. Continuously monitor for new vulnerabilities in model and application code, using threat intelligence feeds and vulnerability databases.

4. Prioritize vulnerabilities based on their potential to compromise data integrity, security, or model performance, and remediate according to severity.

5. Collaborate across roles to ensure that vulnerabilities in shared systems, like APIs or cloud infrastructure, are remediated quickly to minimize risks.

[All Actors]

1. Establish a unified vulnerability-management framework that covers identification, classification, remediation and reporting.

2. Define clear roles and responsibilities for discovery, assessment, triage and patch deployment.

3. Implement automated scanning tools and complementary manual assessments to continuously monitor source code, container images, model artefacts, APIs, and third-party dependencies for known vulnerabilities (e.g., CVEs) and emerging threats identified via threat-intelligence feeds.

4. Prioritize vulnerabilities using a risk-based approach and define remediation SLAs aligned with business impact and exploitation likelihood.

5. Maintain a centralized tracking system with severity, deadlines, remediation status, and validation results visible to all relevant parties.

6. Review and synchronize the framework and policies at least annually, and following any significant changes, incorporating lessons learned.

7. Collaborate to remediate shared-stack vulnerabilities (e.g., APIs, orchestration, cloud infrastructure) within agreed timelines.

From CCM v4.1: Control Ownership Rationale. The implementation responsibility for this control is “Shared” and both parties CSP and CSC are independently responsible for implementing policies and procedures to identify, report and prioritize the remediation of vulnerabilities, according to their own business needs and compliance requirements, and irrespectively of the cloud service delivery models (IaaS/PaaS/SaaS).

The CSP may provide the CSC with reasonable and sufficient capabilities and tools to identify vulnerabilities and protect their workloads (including but not limited to: virtual machines, serverless, databases, networks, containers, and web applications).

Implementation Guidelines. Applicable to all service models: The CSP should establish policy on threat and vulnerability management (TVM) that includes the intent, purpose, and governance of how the CSP will identify and address threats and vulnerabilities for its respective scope under the SSRM.

The CSP is responsible for establishing and implementing procedures to identify, assess, report, and prioritize the remediation of vulnerabilities on the host infrastructure, network devices, virtualization technologies, operating systems, platform applications such as databases and web applications.

Policies should include (but not limited to) provisions on the following:

• a. Scope and Objectives:

  • i. A well defined scope for vulnerability management including both on-premise and cloud-based infrastructure (cloud systems, applications, and data).

  • ii. Objectives to establish a comprehensive and effective vulnerability management program

• b. Threat and Vulnerability Management Program: A threat and vulnerability management program that encompasses the methods that should be used for managing threats and vulnerabilities (incl. the modeling, analysis, threat intel and assessment of threats in the cloud environment and cloud service offering, the methods for vulnerability scanning, assessment, prioritization and remediation processes, and related security validation methods)

• c. Detection Tools Updates: Requirements for a process to update detection tools and configurations

  • i. A regular update schedule for all detection tools (e.g., vulnerability scanners, threat intelligence feeds, and IDS/IPS signatures)

  • ii. Detection tool updates (automated, if possible), by utilizing automation tools to streamline the update process and minimize manual intervention for timely updates and continuous protection

• d. External Library Vulnerabilities: A process to inventory and monitor external libraries and track external libraries and components within applications and infrastructure

• e. Penetration Testing: Requirements to perform regular penetration testing of cloud infrastructure and applications to uncover potential vulnerabilities and security weaknesses

  • i. Appropriate forms of security testing (pentesting, red/blue/purple teaming, breach and attack simulation, etc.)

  • ii. Requirements on how sensitive data will be handled during penetration testing

  • iii. Requirements for the prioritization and remediation of vulnerabilities identified during penetration testing

• f. Vulnerability Identification: Requirements to utilize automated vulnerability scanning tools to identify known vulnerabilities across cloud infrastructure, applications, and software components

• g. Vulnerability Prioritization: Requirements for the prioritization of identified vulnerabilities based on their severity and potential impact on data security

• h. Vulnerability Remediation Schedule: A well-defined schedule for remediating vulnerabilities based on their priority and urgency

• i. Vulnerability Management Reporting: Requirements to generate regular reports and communicate them to stakeholders, which include a summary of identified vulnerabilities, their severity levels, and remediation status

• j. Vulnerability Management Metrics: Key Performance Indicators (KPIs) defined to measure the effectiveness of vulnerability management processes

• k. Approval: Approval requirements and senior management involvement to ensure alignment with the organization’s strategic goals and risk appetite

  • i. An approval process should be established for any changes or modifications to the policy and procedures

  • ii. A documented record of approvals (including dates, names of approvers, and any relevant comments or discussions) should be maintained

• l. Communication: Effective communication of the policy and procedures should be facilitated to all relevant cloud stakeholders

• m. Maintenance and Reviews: Vulnerability management policies and procedures should be documented, reviewed and updated at least annually to ensure alignment with the evolving cloud security landscape and to reflect changes in cloud technology, regulations, and risks

This policy should reflect the allocation of responsibilities as determined in the service agreement/contract, SLA, and other terms, and make assignments to address any unaddressed needs as determined by any control gap assessment.

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.

Shared Implementation Guidelines

[All Actors]

1. Establish and maintain an anti-malware policy that covers prevention, detection, response and annual review.

2. Implement continuous threat identification through automated scanning and threat-intelligence feeds.

3. Integrate real-time malware detection tools in development and production environments (source, container images, model artefacts, APIs).

4. Classify detected malware or malicious instructions by severity, exploitability and potential business impact; prioritise remediation accordingly.

5. Keep threat-intelligence sources and detection signatures up to date, and align classification criteria with the organisation’s risk-management framework.

Implementation Guidelines for Cloud Service Providers (CSP)

1. Use automated tools and manual methods to identify vulnerabilities within the AI development lifecycle, application services, and cloud infrastructure.

2. Classify identified vulnerabilities by risk level and potential impact on AI models, applications, and cloud environments.

3. Collaborate with stakeholders to ensure vulnerabilities are identified across the entire AI ecosystem, from model training to deployment and operation.

4. Regularly update vulnerability classification criteria to reflect changes in technology, emerging threats, and regulatory requirements.

[All Actors]

1. Establish and maintain an anti-malware policy that covers prevention, detection, response and annual review.

2. Implement continuous threat identification through automated scanning and threat-intelligence feeds.

3. Integrate real-time malware detection tools in development and production environments (source, container images, model artefacts, APIs).

4. Classify detected malware or malicious instructions by severity, exploitability and potential business impact; prioritise remediation accordingly.

5. Keep threat-intelligence sources and detection signatures up to date, and align classification criteria with the organisation’s risk-management framework.

From CCM v4.1: Control Ownership Rationale. Malware protection policies and procedures should be implemented and integrated across all computing infrastructure, including compute, network devices, endpoints, and secure access gateways. Therefore, the implementation responsibility of this control pertains to both CSP and CSC, irrespective of the three cloud service delivery models (IaaS/PaaS/SaaS) and it should be independently implemented by each party.

Implementation Guidelines.

Applicable to all service models: The CSP bears the primary responsibility for the effective implementation of policies and procedures aimed at malware protection within the cloud environment. This involves safeguarding CSC data and the cloud infrastructure from evolving malware threats by implementing a layered approach to security and deploying and maintaining robust malware prevention tools, such as antivirus and anti-malware software, across all cloud instances. The CSP must diligently enforce network security controls, including firewalls and intrusion detection/prevention systems, to monitor and filter incoming and outgoing traffic for potential malware threats, as well as, access controls, data encryption, and vulnerability management best practices.

Policies should include (but not limited to) provisions on the following:

• a. Scope and Objectives:

  • i. Requirements for both CSPs and CSCs using managed devices that need protection against malware infections

  • ii. Objectives to develop and implement malware protection solutions in the cloud computing environment

• b. Layered Malware Protection: A layered approach to malware protection by employing a combination of security solutions, including antivirus, anti-malware, host-based firewalls, network security controls, endpoint detection and response (EDR) tools

  • i. Malware protection integration across all cloud computing infrastructure, including VMs, network devices, endpoints’ OSes, and secure access gateways

  • ii. Malware protection centralized management, including planning, implementing, assessing, authorizing, and monitoring organizationally-defined malware protection security controls to cohesively address malware within predefined timeframes

  • iii. Malware protection on inspecting both inbound and outbound traffic and implementing controls to detect, prevent, block, and remove malware

  • iv. Malware protection solutions security configuration to optimize their effectiveness, including enabling real-time protection, scheduled scans, and automatic updates

• c. Malware protection solutions integration with other security controls, such as firewalls, intrusion detection systems (IDS), and data loss prevention (DLP) tools, to create a unified security posture vi. Remediation of malware (automated, if possible) by integrating automated malware scanning into the email and file upload systems

• d. Threat Intelligence Integration: Integration of threat intelligence feeds into malware protection solutions to stay updated on the latest threats, indicators of compromise (IOCs), and attack methods

• e. Machine Learning and Artificial Intelligence (ML/AI): Utilization of ML/AI techniques to analyze vast amounts of data, identify patterns, and detect anomalies indicative of malware infections

• f. Sandbox Analysis: Sandbox environments to safely execute suspicious files or code in isolation to observe their behavior and determine their malicious intent

• g. Signature-based and Signatureless Detection: A combined approach of signature-based detection that relies on known malware signatures, with signatureless detection that analyzes file behavior and heuristics to identify unknown threats

• h. Malware Solutions Updates: Regular updates of malware protection solutions with the latest signatures, patches, and detection mechanisms to maintain effectiveness against evolving threats

• i. Malware Solutions Testing: Rigorous testing and evaluation of malware protection solutions to assess their performance, accuracy, and impact on system performance

• j. Monitoring and Alerting: Establishment of monitoring and alerting mechanisms to promptly identify and respond to malware infections

• k. Approval: Approval requirements and senior management involvement to ensure alignment with the organization’s strategic goals and risk appetite

  • i. An approval process should be established for any changes or modifications to the policy and procedures

  • ii. A documented record of approvals (including dates, names of approvers, and any relevant comments or discussions) should be maintained

• l. Communication: Effective communication of the policy and procedures should be facilitated to all relevant cloud stakeholders

• m. Maintenance and Reviews: Malware protection policies and procedures should be documented, reviewed and updated at least annually to ensure alignment with the evolving cloud security landscape and to reflect changes in cloud technology, regulations, and risks

The policy should also include expectations of time objectives for remediation programs that seek to ensure systems are free of infection when they connect to enterprise computing resources.

If malware is identified by antivirus or anti-malware applications using a signature- or behavior-based detection process, its removal should be updated according to applicable contractual agreements and organizational standards.

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.

Shared Implementation Guidelines

[All Actors]

1. Identify and prioritize vulnerabilities across systems and AI/ML components using scanning and threat intelligence sources (e.g., CVEs, advisories) to detect vulnerabilities on organizationally managed assets at least monthly.

2. Identify findings through scanning and threat intelligence solutions and ensure coverage of infrastructure, applications, and dependencies.

3. Implement testing procedures to validate the effectiveness of patches and ensure they do not introduce new vulnerabilities or performance issues.

Implementation Guidelines for Cloud Service Providers (CSP)

1. Identify vulnerabilities across cloud infrastructure, platforms, applications, containers, and AI/ML components using automated scanning, SAST/DAST, and threat intelligence sources (e.g., CVEs, advisories).

2. Perform identification at least monthly, integrate into CI/CD where applicable, prioritize based on risk, and track findings through resolution.

[All Actors]

1. Identify and prioritize vulnerabilities across systems and AI/ML components using scanning and threat intelligence sources (e.g., CVEs, advisories) to detect vulnerabilities on organizationally managed assets at least monthly.

2. Identify findings through scanning and threat intelligence solutions and ensure coverage of infrastructure, applications, and dependencies.

3. Implement testing procedures to validate the effectiveness of patches and ensure they do not introduce new vulnerabilities or performance issues.

From CCM v4.1: Control Ownership Rationale. This is a “Shared (Independent)” control for IaaS, PaaS, and SaaS as in the three service models, assets and resources can exist under the control of either the CSP or CSC, where the respective systems and technologies are potentially subject to vulnerabilities that should be detected and managed. For IaaS and PaaS, potential vulnerabilities of the assets and resources often include both software flaws, misconfigurations, and control gaps and can exist for assets and resources under the control of the CSP as well as those under the control of the CSC. For SaaS, potential vulnerabilities of the assets and resources generally include software flaws only for the CSP’s area of control, and misconfiguration and control gap vulnerabilities in both the CSP’s and the CSC’s areas of control.

Implementation Guidelines. Organizations should ensure that processes and technologies are in place to identify all types of vulnerabilities applicable to their environment, including but not limited to configuration vulnerabilities, software coding flaws and vulnerabilities, software and system design vulnerabilities, and control gaps.

CSPs provide CSCs with the capabilities and tools to identify vulnerabilities and protect their workloads (such as but not limited to: virtual machines, databases, networks, containers, and web applications).

Under non-disclosure agreement (NDA), the CSC can request from the CSP a summary of identified vulnerabilities on the application they consume and how they are tracked and verified following remediation.

IaaS Provider: The CSP is responsible for defining, implementing. and evaluating processes, procedures, and technical measures for the detection of vulnerabilities on organizationally-managed assets (host infrastructure, network devices, and virtualization technologies) at least monthly.

IaaS CSP implementation guidelines for vulnerabilities identification include (but are not limited to):

• a. Automated Vulnerability Scanning: Regularly use vulnerability scanning tools (e.g., open-source OpenVAS) to identify and assess vulnerabilities in virtual machines, operating systems, network devices, and storage within the IaaS environment

• b. Network Traffic Monitoring: Monitor network traffic to detect suspicious patterns that may indicate the presence of vulnerabilities. Look for unusual traffic patterns, such as large amounts of data being transferred or connections from unauthorized sources (e.g., leverage open source tools like Nmap, Wireshark, Nikto)

• c. Penetration Testing: Conduct regular penetration tests using tools (e.g., open-source Metasploit) to simulate attacks on IaaS components, such as virtual machines and network devices’ configurations

PaaS Provider: The CSP is responsible for defining, implementing, and evaluating processes, procedures, and technical measures for the detection of vulnerabilities on organizationally-managed assets (host infrastructure, virtualization technologies, operating systems platform & software development of applications, databases, etc.) at least monthly.

PaaS CSP implementation guidelines for vulnerabilities identification include (but are not limited to):

• a. Static Application Security Testing (SAST): Integrate SAST tools (e.g., open-source SonarQube, OSV-Scanner) into the development lifecycle to identify vulnerabilities in the source code and dependencies of applications built on PaaS platforms. Such tools can scan source code to identify potential security flaws, such as SQL injection vulnerabilities and cross-site scripting (XSS) vulnerabilities (e.g., leverage open source tool sqlmap).

• b. Dynamic Application Security Testing (DAST): Perform dynamic testing to identify vulnerabilities during applications runtime (consider leveraging open-source tools like OWASP Zed Attack Proxy (ZAP))

• c. Container Security Scanning: Integrate container security scanning tools (e.g., open-source Clair) into the CI/CD pipeline to identify vulnerabilities in container images

SaaS Provider: The CSP is responsible for defining, implementing, and evaluating processes, procedures and technical measures for the detection of vulnerabilities on organizationally-managed assets (host infrastructure, network devices, virtualization technologies, operating systems, platform applications such as databases, and web applications) at least monthly.

SaaS CSP implementation guidelines for vulnerabilities identification include (but are not limited to):

• a. Application Security Assessments: Conduct thorough security assessments on the SaaS applications and web applications using a combination of manual code reviews and open-source automated scanners (e.g., Bandit, ESLint, Wapiti, OpenSCAP, Nikto2, Burp Suite Community Edition, MobSF).

• b. API Security Testing: Test the security of APIs used in SaaS applications using relevant tools (e.g., open source Postman and OWASP API Security Project).

• c. Data Protection Measures: Implement measures to protect sensitive data within the SaaS application, including encryption, access controls, and data loss prevention (DLP) policies (e.g., leverage open-source tools like OpenDLP)

Applicable to all service models: Implementation best practices for vulnerabilities identification include (but are not limited to):

• a. Vulnerability Scanning Tools and Schedule:

  • i. Vulnerability scanning tools (automated, if possible) should be utilized to regularly scan the cloud infrastructure, applications, and data for known vulnerabilities. Examples include Attack Surface Management tools, Cloud Security Posture Management tools, and Breach and attack simulation tools

  • ii. Vulnerability scanning tools should be integrated into continuous integration/continuous delivery (CI/CD) pipelines to identify and address vulnerabilities early in the development process

  • iii. A regular scanning schedule should be defined to ensure timely detection of newly discovered vulnerabilities and minimize exposure to potential attacks

• b. Log Analysis: Logs from the cloud infrastructure components should be analyzed to identify anomalies and potential open vulnerabilities (e.g., improperly defined access rules, gaps to systems configurations)

• c. Threat Intelligence Feeds: Threat intelligence feeds should be leveraged to stay informed about emerging vulnerabilities, threat trends, and exploited vulnerabilities in order to prioritize vulnerability scanning and remediation efforts, focusing on vulnerabilities that are actively being targeted by attackers

• d. Vulnerability Databases and CVEs:

  • i. A vulnerability database of known vulnerabilities, including their severity levels, potential exploits, and recommended remediation steps. Lessons learned from vulnerability incidents should be integrated for continuous improvement

  • ii. This database should be maintained and regularly updated with the latest Common Vulnerabilities and Exposures (CVEs) that serves as a reference point for identifying and prioritizing vulnerabilities

• e. Vulnerability Assessments and Penetration Testing (VAPT): Engage in regular VAPT exercises to identify and exploit potential vulnerabilities that may not be detected by automated scanning tools (refer to TVM-06)

• f. Configuration Management: Configuration management tools should be leveraged (e.g., open-source Ansible) to enforce secure configurations and reduce the risk of misconfigurations

• g. Reporting and Escalation Procedures: Reporting and escalation procedures for identified vulnerabilities should be implemented

  • i. These procedures should outline who is responsible for remediation, the timelines for addressing vulnerabilities, and the mechanism for escalation in case of critical or high-risk vulnerabilities

  • ii. The CSP should provide CSC with guidelines to protect against threats and vulnerabilities and external library vulnerabilities using appropriate tools, relevant automation, and operational frameworks within risk tolerance

• h. Continuous Monitoring and Evaluation: The effectiveness of vulnerability identification processes should be continuously monitored and evaluated, and adjustments made as needed

The integrated TVM system should track vulnerabilities to closure and report them to build oversight of residual risks. Furthermore, the system should retain information that can be reused in future remediation activities.

The CSP should consider establishing an external-facing vulnerability disclosure program to allow external parties to communicate detected vulnerabilities.

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.

Shared Implementation Guidelines

[All Actors]

1. Model / System Understanding – document the architecture, data sources, algorithms and use-case context of each AI or cloud component under review.

2. Threat Identification – use recognised frameworks (e.g., CSA GenAI Risk Scenarios, Mitre ATLAS) to enumerate malicious actors, insider threats and unintentional failure modes; create concrete scenarios (data poisoning, model inversion, availability attacks, etc.).

3. Vulnerability Analysis – perform data reviews, code reviews, penetration testing and other assessments to discover weaknesses; rate each finding for severity and likelihood.

4. Risk Analysis & Mitigation Strategy – combine impact and likelihood into a risk matrix, prioritise events and define counter-measures (hardening data pipelines, model-integrity checks, drift / skew monitoring, access controls).

5. Documentation & Governance – keep a transparent record of threat logic, data sources, mitigation plans and moderator / human-in-the-loop rules; review the documentation periodically to reflect regulatory change or new attack vectors.

6. Continuous Monitoring – deploy telemetry and alerting to detect emerging threats; include advanced techniques such as AI honeypots (decoy data lakes, dummy APIs, fake model endpoints) to attract and study attackers.

7. Risk Acceptance & Compensating Controls – when residual risks are formally accepted, document rationale, stakeholder sign-off and compensating measures (enhanced monitoring, restricted access); revisit accepted risks on a scheduled basis.

Implementation Guidelines for Cloud Service Providers (CSP)

1. Ensure that risk acceptance decisions are made transparently, with input from stakeholders and a clear understanding of the potential consequences.

2. Regularly evaluate accepted vulnerabilities to ensure that they do not compromise model performance, service availability, or cloud infrastructure security.

3. Implement compensating controls, such as additional monitoring or restricted access, to mitigate the impact of accepted risks.

4. Document accepted risks and their justifications for future reference, audits, and compliance assessments.

[All Actors]

1. Model / System Understanding: document the architecture, data sources, algorithms and use-case context of each AI or cloud component under review.

2. Threat Identification: use recognised frameworks (e.g., CSA GenAI Risk Scenarios, Mitre ATLAS) to enumerate malicious actors, insider threats and unintentional failure modes; create concrete scenarios (data poisoning, model inversion, availability attacks, etc.).

3. Vulnerability Analysis: perform data reviews, code reviews, penetration testing and other assessments to discover weaknesses; rate each finding for severity and likelihood.

4. Risk Analysis & Mitigation Strategy: combine impact and likelihood into a risk matrix, prioritise events and define counter-measures (hardening data pipelines, model-integrity checks, drift / skew monitoring, access controls).

5. Documentation & Governance: keep a transparent record of threat logic, data sources, mitigation plans and moderator / human-in-the-loop rules; review the documentation periodically to reflect regulatory change or new attack vectors.

6. Continuous Monitoring: deploy telemetry and alerting to detect emerging threats; include advanced techniques such as AI honeypots (decoy data lakes, dummy APIs, fake model endpoints) to attract and study attackers.

7. Risk Acceptance & Compensating Controls: when residual risks are formally accepted, document rationale, stakeholder sign-off and compensating measures (enhanced monitoring, restricted access); revisit accepted risks on a scheduled basis.

From CCM v4.1: Control Ownership Rationale. This control applies to all service models (IaaS, PaaS, SaaS) because threats exist to all cloud service models and appropriate threat analysis and modelling are needed irrespective of cloud service model and type of cloud service provided or consumed. The type of service model provided or consumed will undoubtedly affect the scope of the threat analysis and modelling, but not the applicability of such processes. CSP threat modelling focuses on threats to the CSP’s secure deployment and operation of the cloud, while CSC threat modelling focuses on threats to the CSC’s secure deployments and operations in the cloud. Adeptly identifying, analyzing and modelling relevant threats is important for all organizations, whether operating in a service consumer or service provider role. This control’s implementation responsibility is typically shared independently between the CSP and CSC because both the CSP and the CSC each need to have their own processes to manage threats, including those to identify, analyze, and model relevant threats specific to their respective operations, products, and services. The establishment of such processes is fully internal and unique to each organization, including the scopes, methodologies used, analytical frameworks, scenarios of interest, as well as associated policies and procedures. The threat analysis and modelling activities for the CSP are performed wholly by the CSP.

Implementation Guidelines. Threat management processes should be in place to effectively ensure that potential relevant threats associated with cloud services are systematically identified, analyzed, and assessed, so that appropriate mitigations can be prioritized, planned, and implemented, reducing the likelihood and impact of security breaches. The scope and rigor of threat analysis and modelling processes should be commensurate to the scope and criticality of the cloud service offering, organization size, industry, and regulatory or compliance requirements, and provide useful, actionable information for threat response. Threat analysis and modeling should occur throughout the lifecycle of a system or service, first performed early on in the System Development Life Cycle (SDLC) and then continued to be performed iteratively and progressively as development continues to ensure security-by-design and privacy-by-design and allowing the threat model to be refined and improved as knowledge, needs, and capabilities grow and change. The threat model should be maintained as the system evolves, in particular updated to remain current as the threat environment and technology environment changes. The threat modeling process results in various artifacts and, importantly, updates to the threat models; however, these artifacts and model updates are incidental and are not the ultimate objectives or target products of threat modelling. The objective outcomes are the improvements made to the security, privacy, and safety of the system—i.e., better designs, better code, better architectures, better processes, and better controls.

Applicable to all service models: Processes for threat analysis and modelling vary and should include at a minimum, but are not limited to, provisions on the following:

• a. Defined Methodology: Threat analysis should be performed in the context of a defined, documented methodology that is structured, systematic, consistent, and repeatable. Organizations may use industry open methodologies, proprietary methodologies, custom methodologies, or a hybrid. While methodologies vary in detail, complexity, form, focus, and nomenclature, a functional methodology should address the following:

  • i. Threat Analysis and Modelling

    • Identification and characterization of the system

    • Identification, analysis, and assessment of potential threats

  • ii. Threat Response

    • Prioritization of threat responses

    • Determination and implementation of responses and countermeasures

    • Review, validation, and monitoring of remediations

• b. Scope and Objectives (for system under model): i.Threat modelling can be performed on a single process or system, a small set of related processes and systems, or a large and complex set of interconnected processes and services in an enterprise. The scope of system or services covered in any threat analysis and modelling activity should be clearly and precisely defined and documented. ii.Scoping requires understanding and documenting all applicable objectives and requirements, including business objectives, security objectives, privacy objectives, safety objectives, and compliance objectives. iii.The detailing of system and process scope includes decomposing and deconstructing the scoped systems and processes into their constituent components and elements, including systems, connections, data stores, dataflows, transformation functions, trust boundaries, external services, controls, entities/actors, technologies, protocols, locations, and other pertinent elements to prepare for analysis.

• c. Analytical framework for identifying and evaluating threats: i.Within the overarching methodology, one or more analytical frameworks are selected and used for enumerating, conceptualizing, examining, and evaluating threats and their potential threat vectors.

  • Such frameworks should be chosen based on their topical focus (e.g., privacy, cybersecurity, physical security, safety, etc.), their technology focus (software, enterprise systems, AI, IoT, etc.), or other criteria based on the context and objective of the organization and cloud service.

  • Analysis should include identifying relevant threat scenarios and performing scenario analysis against the system design to determine possible threat outcomes.

  • Integrated approaches may bring in vulnerability analysis and attack analysis (attack trees, attack kill chains, and adversary patterns, tactics and techniques such as those defined by the MITRE CAPEC and ATT&CK frameworks).

  • The analysis of threats should culminate in an informed assessment of risk for the identified unmitigated threats, including an evaluation of their likelihoods and impacts. d Documentation of Threat Analysis: i.Key process artifacts of the threat analysis activity, including inputs and outputs, should be documented and tracked to provide for clarity and traceability.

  • Threat model inputs of the process include system representations and identified threats, including requirements and objectives, methodologies, and frameworks.

  • Threat model outputs of the process include system representations and identified threats, including:

  • system description details, decompositions and diagrams including DFDs.

  • threat outcomes, actors, vectors, patterns, attack methods and TTPs.

  • risk evaluations for the respective identified threats.

  • Threat model process artifacts include assumptions, analysis techniques, conditions, evaluation scales, calculations, reasoning and rationales, and tools used.

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.

Shared Implementation Guidelines

[All Actors]

1. Set up continuous monitoring systems to track vulnerabilities and patch statuses in real-time across the organization’s systems and applications.

2. Automate the generation of vulnerability reports to provide visibility into the status of identified vulnerabilities, remediation efforts, and patching activities.

3. Define thresholds for reporting vulnerability statuses to senior management and relevant stakeholders.

4. Ensure that vulnerability monitoring systems are integrated with incident response systems for quick action on high-risk vulnerabilities.

5. Implement automated reporting tools to ensure real-time visibility into vulnerability statuses and resolution efforts; regularly review vulnerability reports to ensure that emerging threats are being addressed and to track progress toward remediation goals.

6. Update detection engines, threat signatures, and indicators of compromise regularly or whenever a critical release is issued, to keep monitoring systems effective against emerging threats.

Implementation Guidelines for Cloud Service Providers (CSP)

1. Continuously monitor AI models, services, applications, and cloud environments for vulnerabilities, ensuring that they are identified and reported promptly.

2. Provide stakeholders with detailed vulnerability reports that highlight current threats, progress on remediation, and any critical vulnerabilities that need attention.

3. Implement automated reporting tools to ensure real-time visibility into vulnerability statuses and resolution efforts.

4. Track the performance of vulnerability management programs, adjusting strategies based on recurring patterns or emerging threats.

[All Actors]

1. Set up continuous monitoring systems to track vulnerabilities and patch statuses in real-time across the organization’s systems and applications.

2. Automate the generation of vulnerability reports to provide visibility into the status of identified vulnerabilities, remediation efforts, and patching activities.

3. Define thresholds for reporting vulnerability statuses to senior management and relevant stakeholders.

4. Ensure that vulnerability monitoring systems are integrated with incident response systems for quick action on high-risk vulnerabilities.

5. Implement automated reporting tools to ensure real-time visibility into vulnerability statuses and resolution efforts; regularly review vulnerability reports to ensure that emerging threats are being addressed and to track progress toward remediation goals.

6. Update detection engines, threat signatures, and indicators of compromise regularly or whenever a critical release is issued, to keep monitoring systems effective against emerging threats.

From CCM 4.1: Control Ownership Rationale. This is a Shared (Independent) control for IaaS, PaaS, and SaaS and should be implemented and operated both by the CSP and the CSC. The types of activities, events, or states for which detection tools, signatures, and indicators of compromise are defined, implemented, and evaluated will vary across each instance of IaaS, PaaS, and SaaS. The CSP and the CSC are independently responsible for determining which such detection specifications are necessary for their respective requirements and to ensure these are adequately defined, implemented, and operated. For SaaS implementations, CSPs will typically be responsible for this control; however, there are specific use cases where the CSC and CSP have a shared responsibility in this area.

Implementation Guidelines. Applicable to all service models: To maintain an effective threat detection posture, the CSP should ensure that the latest stable version of detection tools (e.g., network firewalls, WAF, NIDS, NIPS, HIDS, HIPS, network layer distributed DDoS protection, application layer DDoS protection, anti-malware software) are installed, and threats signatures and indicators of compromise (IoC) updated on a regular basis, preferably weekly or more frequently. The CSP should ensure that relevant updates are made available for the CSC to apply.

Implementation best practices for updating detection tools, threat signatures, and indicators of compromise vulnerabilities include (but are not limited to):

• a. Threat Intelligence Platform: A centralized threat intelligence platform should be implemented to aggregate and curate threat data from various sources, including internal security feeds, industry reports, external threat intelligence providers, and open-source intelligence (OSINT) to provide unified access to threat indicators, signatures, and vulnerabilities

• b. Threat Data Collection and Processing: The process of collecting and processing threat data from various sources should be automated (e.g., via scripts, APIs, or dedicated threat intelligence feeds) and threat data integrated into the threat intelligence platform for analysis and correlation

• c. Threat Prioritization Criteria: Criteria for prioritizing threat data should be established and based on factors such as the severity of the threat, the potential impact on cloud infrastructure and CSCs data

• d. Threat Signatures and Update Framework: A framework should be created for updating threat signatures for detection tools. This framework should include:

  • i. Continuous monitoring of threat intelligence feeds and internal security logs for new threats and IoCs

  • ii. Analysis of newly identified threats to determine their relevance to the CSP’s cloud environment and CSC base

  • iii. Updates of threat signatures and IoCs based on the analysis of new threats

  • iv. Testing and validation of new signatures and IoCs before deployment to ensure they accurately detect threats without causing false positives

• e. Detection Tool Updates: Updates for detection tools should be regularly scheduled and such tools should be configured to enable streamlined, timely, risk-informed implementation of updates from the vendor or threat intelligence platform (e.g., IDS/IPS tools, anti-malware software, firewalls) in an appropriately secure manner (e.g., allowing for sufficient pre-deployment testing and gating based on an organizationally-appropriate method such as staggered roll-outs based on system criticality, etc.).

• f. Version Control for Signatures and IoCs: A version control process for threat signatures and IoCs should be maintained to track changes and facilitate rollbacks if necessary. A version control system (e.g., Git) can be used to manage and store signatures and IoCs

• g. Continuous Monitoring and Evaluation:

  • i. The effectiveness of detection tools and the impact of updates on system performance and resource utilization should be continuously monitored. Metrics should be used to measure the success of the threat detection process (e.g., number of threats detected, the rate of false positives, and the time taken to respond to threats)

  • ii. Lessons learned from security incidents and threat analysis should be incorporated into the threat detection process

  • iii. Security audits and penetration testing should be regularly conducted to assess the effectiveness of the threat detection process and identify potential gaps or weaknesses. Findings should be used to refine the threat detection strategy

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.

Shared Implementation Guidelines

[All Actors]

1. Prioritize vulnerabilities based on their risk to critical systems, data, and services, taking into account business impact and the likelihood of exploitation.

2. Implement a risk based prioritization method to rank vulnerabilities and determine remediation timelines.

3. Use automated risk assessment tools to dynamically evaluate the new vulnerabilities and adjust priorities accordingly.

4. Develop a risk mitigation plan for critical vulnerabilities, focusing on high-impact systems and services that are critical to business continuity.

5. Regularly review the effectiveness of risk-based vulnerability management practices and update risk criteria and the overall process to ensure they align with business goals and threat landscape changes.

6. Maintain and exchange SBOMs among supply chain actors to support transparency, tracking and coordinated patching of vulnerable dependencies.

Implementation Guidelines for Cloud Service Providers (CSP)

1. Use a risk-based approach to manage vulnerabilities within the AI development pipeline, application infrastructure, and cloud environments.

2. Prioritize vulnerabilities based on their potential impact on model performance, data integrity, and business continuity, and implement remediation strategies accordingly.

3. Collaborate across roles to ensure that high-risk vulnerabilities are addressed promptly, with appropriate resources allocated for remediation.

4. Regularly assess and update risk criteria to ensure that vulnerability management practices remain aligned with evolving business and security needs.

[All Actors]

1. Prioritize vulnerabilities based on their risk to critical systems, data, and services, taking into account business impact and the likelihood of exploitation.

2. Implement a risk based prioritization method to rank vulnerabilities and determine remediation timelines.

3. Use automated risk assessment tools to dynamically evaluate the severity of new vulnerabilities and adjust priorities accordingly.

4. Develop a risk mitigation plan for critical vulnerabilities, focusing on high-impact systems and services that are critical to business continuity.

5. Regularly review the effectiveness of risk-based vulnerability management practices and update risk criteria and the overall process to ensure they align with business goals and threat landscape changes.

6. Maintain and exchange SBOMs among supply chain actors to support transparency, tracking and coordinated patching of vulnerable dependencies.

From CCM 4.1: Control Ownership Rationale. This is a “Shared (Independent)” control for IaaS and PaaS, as in both the IaaS and PaaS service models, external libraries and the capabilities and responsibilities for the management of external libraries, including their associated vulnerabilities, can exist in both the CSP- and CSC-controlled layers. For IaaS and PaaS, this control specification therefore should be implemented by each the CSP and the CSC.

For SaaS, external libraries and the capabilities and responsibilities for the management of external libraries, including their associated vulnerabilities, exist exclusively in the CSP layer, and the CSP is solely responsible for the implementation and operation of this control.

Implementation Guidelines. Applicable to all service models: To effectively identify updates for applications that utilize third-party or open-source libraries, CSPs should implement a comprehensive vulnerability management strategy that encompasses the following implementation best practices:

• a. Third-Party Libraries Inventory: An accurate inventory of all third-party libraries used across the cloud environment should be maintained.

  • i. The inventory should include the library name, version, and associated applications and should leverage resources such as SBOMs where possible.

  • ii. Tools should be utilized to automate this process and continuously monitor for changes in library usage (e.g., software composition analysis (SCA), dependency management solutions)

• b. Vulnerability Databases Integration: The inventory should be correlated with vulnerability databases (e.g., CVE) to obtain timely notifications about new vulnerabilities affecting the third-party libraries used in the CSP environment

• c. Patching and Deployment: The patching and deployment process for third-party libraries should be automated whenever possible

• d. Open Source Library Security: When incorporating open-source libraries, follow open-source security best practices, such as reviewing the library’s code, checking for known vulnerabilities, and ensuring the library is actively maintained

• e. Dependency Management Tools: Employ dependency management tools to keep track of library dependencies and automatically update libraries when new versions are released

• f. Automated Scanning Tools:

  • i. Automated scanning tools should be employed to regularly scan applications for vulnerabilities, including those associated with third-party libraries

  • ii. Ensure that patching third-party libraries does not introduce new vulnerabilities or compatibility issues

• g. Third-party Vendors Management:

  • i. A vendor management process should be implemented to assess the security practices of third-party library vendors for adherence to your organization’s security requirements

  • ii. A vulnerability disclosure policy should be established for external library vendors, outlining reporting procedures and timelines for vulnerability disclosure and remediation

  • iii. Open communication channels should be established with third-party vendors to receive timely information on vulnerabilities and updates.

• h. Third Party Libraries Updates: Subscribe to security advisories and mailing lists related to third-party libraries to stay updated on the latest vulnerabilities and patches.

• i. CI/CD Integration: CI/CD pipelines should be adopted to automate the integration and deployment of new code and library updates

• j. Third-party Libraries License: Compliance should be maintained with open-source licenses and legal obligations associated with third-party libraries (e.g., tracking license changes, adherence to license terms)

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.

Shared Implementation Guidelines

[All Actors]

1. Assess the potential impact of each vulnerability on the organization’s systems, services, and data.

2. Classify vulnerabilities based on their potential to cause disruption to critical business functions, such as model integrity, service availability or data privacy.

3. Conduct impact assessments for high-priority vulnerabilities to understand potential consequences and prioritize remediation efforts.

4. Use risk management frameworks to guide impact assessments and ensure they align with organizational goals and compliance requirements.

5. Ensure that impact assessments are communicated effectively to all stakeholders to inform decision-making around remediation efforts.

6. Regularly review and update impact-assessment procedures to reflect new threats, regulatory changes and technology shifts.

7. Schedule penetration tests at defined intervals and after major system changes; ensure tests are executed by qualified, independent third parties and that results feed into the impact-assessment workflow above.

Implementation Guidelines for Cloud Service Providers (CSP)

1. Collaborate across roles to assess the impact of vulnerabilities on AI models, orchestrated services, and applications.

2. Assess the potential consequences of vulnerabilities on model behavior, service availability, and data integrity.

3. Regularly update impact assessment procedures to account for new threats, regulatory requirements, and technological changes.

4. Ensure that vulnerability impact assessments guide remediation decisions and inform stakeholders on potential business risks.

[All Actors]

1. Assess the potential impact of each vulnerability on the organization’s systems, services, and data.

2. Classify vulnerabilities based on their potential to cause disruption to critical business functions, such as model integrity, service availability or data privacy.

3. Conduct impact assessments for high-priority vulnerabilities to understand potential consequences and prioritize remediation efforts.

4. Use risk management frameworks to guide impact assessments and ensure they align with organizational goals and compliance requirements.

5. Ensure that impact assessments are communicated effectively to all stakeholders to inform decision-making around remediation efforts.

6. Regularly review and update impact-assessment procedures to reflect new threats, regulatory changes and technology shifts.

7. Schedule penetration tests at defined intervals and after major system changes; ensure tests are executed by qualified, independent third parties and that results feed into the impact-assessment workflow above.

From CCM 4.1: Control Ownership Rationale. This is a “Shared (Dependent)” control for IaaS and PaaS, as in both the IaaS and PaaS service models, systems, resources, and technologies can exist under the control of either the CSP or CSC where the systems, resources, and technologies are potentially subject to misconfiguration, inadequate design or implementation, or inadequate control against which the performance of such a simulated attack is desirable to determine whether the vulnerability is genuine. For IaaS and PaaS, this control specification should be implemented by each the CSP and the CSC. For SaaS, the systems, the resources, and technologies for which a penetration test is valuable exist exclusively in the CSP layer, and the CSP is solely responsible for the implementation and operation of this control. Irrespective of the cloud service delivery model, the CSP is responsible for defining, implementing, and evaluating processes, procedures, and technical measures for the periodic performance of penetration testing by independent third parties.

Implementation Guidelines. Applicable to all service models: CSPs should implement a comprehensive penetration testing strategy that encompasses the following implementation best practices:

• a. PenTesting Scope:

  • i. The scope of penetration testing should be defined, encompassing cloud infrastructure, applications, and data storage

  • ii. Objectives for each engagement should be defined, such as identifying critical vulnerabilities, assessing the effectiveness of security controls, and validating compliance with industry standards.

  • iii. Limitations or constraints should be identified, such as testing hours and potential impact on production systems

• b. Authorization and Notification:

  • i. Formal authorization should be obtained from senior management and ensure alignment with the cloud penetration testing policy

  • ii. The CSP should obtain explicit authorization from relevant stakeholders before conducting penetration testing

  • iii. Affected CSCs and relevant parties should be notified about the upcoming penetration testing to prevent unnecessary alerts or escalations

• c. Third-Party Pen Testers Selection: Reputable and experienced third-party pen testers should be selected who possess expertise in cloud security and penetration testing methodologies

  • i. Third-party pen testers credentials, experience, and ability to handle sensitive data should be evaluated

  • ii. The testing firm should comply with industry standards and certifications (e.g., ISO 27001, CREST, or Offensive Security Certified Professional)

• d. Engagement Procedures: Engagement procedures should be established that outline the process from planning and authorization to execution and reporting. Specify communication channels, timelines, and deliverables

• e. Appropriate Testing Environment: The appropriate environment(s) to conduct pen testing should be identified and authorized based on organizational objectives, constraints, and testing approach, including such constraints as minimization of disruption to services, realistic equivalence/replicative fidelity of the testing environment, compliance requirements, etc.

• f. Data Handling and Privacy: Data anonymization techniques or sanitized data sets should be implemented and used to prevent unauthorized access or disclosure of sensitive information

• g. PenTesting Methodology: The penetration testing engagement should be initiated by coordinating with the CSP’s security team and relevant stakeholders. Industry-standard penetration testing methodologies include OWASP, NIST, or PTES

  • i. Thorough reconnaissance should be conducted to gather information about the cloud environment, including its architecture, configurations, and potential vulnerabilities.

  • ii. Open-source intelligence (OSINT), vulnerability scanners, and network mapping tools should be utilized and identified vulnerabilities analyzed to assess their severity and potential impact

  • iii. Proofs-of-concept (PoCs) are recommended to exploit identified vulnerabilities to demonstrate their real-world impact

  • iv. The findings of the penetration testing engagement should be documented to clearly outline the identified vulnerabilities, their severity, and potential impact

• h. Detailed recommendations for remediation should be provided including mitigation strategies and suggested timelines vi. A mechanism should be established to track the progress of vulnerability remediation based on the penetration testing findings vii. The closure of reported vulnerabilities should be monitored and timely implementation of mitigation strategies ensured viii. Follow-up penetration testing engagements should be scheduled to verify the effectiveness of remediation efforts and identify any newly introduced vulnerabilities

• i. PenTesting Results Communication: The results of penetration testing should be communicated to senior management and CSCs providing insights into security enhancements and improvements

• j. Continuous Improvement:

  • i. Cloud penetration testing processes should be periodically reviewed and updated based on evolving security threats, cloud technologies, and industry best practices. The scope, objectives, and engagement procedures should be continuously refined to ensure the program remains effective

  • ii. Metrics should be defined to measure the success of the cloud penetration testing program, such as the number of vulnerabilities identified, the percentage of vulnerabilities remediated, and the overall improvement in cloud security posture

There will almost certainly be limits on performing penetration tests without the permission of the CSP. The CSP and CSC should ensure that the scope of penetration tests is limited to the boundaries that each is responsible for.

Under non-disclosure agreement (NDA), the CSC may be able to request from the CSP a summary of penetration test findings on the application it consumes, and learn how identified vulnerabilities are tracked and verified following remediation.

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.

Shared Implementation Guidelines

[All Actors]

1. Integrate threat intelligence feeds into the vulnerability management process to identify emerging threats and vulnerabilities across AI models, orchestrated services, applications and cloud platforms.

2. Use threat intelligence to assess the relevance of vulnerabilities, including zero-day exploits and vulnerabilities targeting specific industries.

3. Regularly update vulnerability management systems with the latest threat intelligence to keep pace with evolving risks.

4. Share threat intelligence across teams to enhance the organization’s ability to respond to new vulnerabilities quickly.

5. Monitor industry reports and security advisories regularly to stay informed of emerging vulnerabilities and threats that may impact the organization.

6. All resource (service) access should leverage Just in Time (JIT) or Zero Standing Privilege (ZSP) to reduce access vulnerabilities and allow privileged access during scheduled and emergency response.

Implementation Guidelines for Cloud Service Providers (CSP)

1. Integrate threat intelligence into vulnerability management processes for AI models, orchestrated services, applications, and cloud platforms.

2. Ensure that vulnerability scanning tools are updated with the latest threat intelligence to identify relevant risks.

3. Collaborate with security teams to ensure that emerging threats and zero-day vulnerabilities are addressed in a timely manner.

4. Use threat intelligence to inform security posture and vulnerability prioritization across services.

[All Actors]

1. Integrate threat intelligence feeds into the vulnerability management process to identify emerging threats and vulnerabilities across AI models, orchestrated services, applications and cloud platforms.

2. Use threat intelligence to assess the relevance of vulnerabilities, including zero-day exploits and vulnerabilities targeting specific industries.

3. Regularly update vulnerability management systems with the latest threat intelligence to keep pace with evolving risks.

4. Share threat intelligence across teams to enhance the organization’s ability to respond to new vulnerabilities quickly.

5. Monitor industry reports and security advisories to stay informed of emerging vulnerabilities and threats that may impact the organization.

6. All resource (service) access to leverage Just in Time (JIT) or Zero Standing Privilege (ZSP) to reduce access vulnerabilities and allow privileged access during scheduled and emergency response.

From CCM 4.1: Control Ownership Rationale. The implementation responsibility for this control is “Shared” and both parties CSP and CSC are independently responsible for implementing a vulnerability remediation schedule according to their own business needs and compliance requirements, irrespective of the cloud service delivery models (IaaS/PaaS/SaaS).

Implementation Guidelines. The CSP should maintain a structured approach to establishing timelines for and following through on the remediation of—and the validation of remediation of—vulnerabilities across cloud environments, through the implementation and operation of a comprehensive cloud services Vulnerability Remediation Schedule (VRS). The schedule should take into account determined prioritizations as well as real-world capabilities and constraints for the selected specific technical and non-technical remediation actions to ensure appropriately timely and effective vulnerability remediation management.

For vulnerabilities affecting infrastructure, platforms, or application software, the CSP is responsible for defining, implementing and evaluating processes, procedures, and technical measures to timely enable both scheduled and emergency responses based on the prioritization assigned for the remediation of identified vulnerabilities.

Such scheduling should encompass every type of organizationally determined response to vulnerabilities, including those for remediation or mitigation with preventive, detective, and corrective controls, whether supplementary, complementary, or compensating in nature, including permanent/long-term controls and temporary workarounds.

IaaS Provider: Remediations and mitigations for infrastructure vulnerabilities can include combinations of patch management, configuration management, network security controls, and logging, monitoring, and alerting controls, among others.

PaaS Provider: Remediations and mitigations for platform vulnerabilities can include combinations of vulnerabilities patching, implementation of secure coding and runtime application security protection (including for container security and serverless security), PaaS configuration management, PaaS security assessment, and runtime application security protection (RASP).

SaaS Provider: Remediations and mitigations for application software vulnerabilities can include combinations of API Security, application and data access control configuration, SaaS activity and usage monitoring, among others.

Applicable to all service models: Implementation best practices for vulnerabilities remediation include (but are not limited to):

• a. Vulnerability Remediation Schedule (VRS): A structured and well-defined vulnerability remediation schedule should be developed and implemented. The VRS should:

  • i. Establish timeframes for vulnerability remediation to be applied to all vulnerabilities, consistent with risk-based prioritizations determined as part of the organizational prioritization and categorization activities (such as those carried out through SSVC, EPSS, and CVSS) in alignment with TVM policy.

  • ii. Allow for appropriate incorporation and reflection of realistic and pragmatic factors such as required remediation scope, scale, and effort as well as organizational capabilities and constraints for the selected specific technical and non-technical remediation actions.

  • iii. Define processes for managing necessary exceptions to the remediation schedule, including requesting, reviewing, approving, documenting, monitoring, tracking, and managing exceptions, in accordance with requirements of the organizational policy exception process.

  • iv. Coordinate with, or incorporate outputs from, other relevant organizational security management and testing processes, including those from vulnerability prioritization, threat response, penetration testing, risk management, audit and assurance, and similar processes, as appropriate to the organization’s security operations and lifecycle management processes.

• b. Be approved and communicated to all relevant stakeholders and included in SLAs.

• c. Established processes and procedures: Organizations should establish streamlined processes and procedures for both regularly scheduled as well as out-of-band/emergency updates to enable timely, risk-informed implementation of security updates in an appropriately secure manner. Standard Operating Procedures

  • i. Procedures should be developed for routine vulnerability management processes, based on the timeframes established in the VRS.

  • ii. Procedures should allow for sufficient pre-deployment testing and gating based on an organizationally-appropriate method (e.g., staggered rollouts across deployment rings based on system criticality, etc., with relevant monitoring).

  • iii. Testing and distribution processes and procedures should leverage automation whenever appropriate to reduce unnecessary manual intervention and minimize the window of vulnerability exposure. Note that the implementation of automated processes does not require the implementation of automatic processes.

  • iv. Regular maintenance windows should be scheduled for applying routine patches to support planning for and minimization of impacts of service disruptions. Emergency Operating Procedures

• d. Procedures should be developed for emergency/out-of-band vulnerability management processes. Such procedures address vulnerability management for especially critical urgent cases requiring response outside the timeframes established in the VRS. vi. Emergency procedures should include provisions for special prioritizations, modifications, and/or exceptions for pre-deployment testing.

• e. Responsibilities and Authorities: Responsibilities, authority, and accountabilities should be well-defined for both standard and emergency vulnerability responses.

  • i. Vulnerability response procedures should be established by policy and backed by clear authority and clear authorization.

  • ii. Authority and decision-making structures, including for determining response prioritizations, authorizing resource allocations within organizational operations, program, and project management, and authorizing service interruptions, should be carefully determined, defined, and communicated.

• f. Vulnerability Remediation Technological Capabilities: Operable technological capabilities should be established to support the implementation of security updates and other vulnerability responses in an appropriately timely, effective, and secure manner, including the implementation of special-purpose remediation and response management systems as well as the appropriate integration of remediation processes with general technological processes, as applicable.

  • i. Vulnerability Remediation and Response Management Systems: Centralized management systems should be implemented to enable and streamline the deployment and tracking of security remediation and response actions, such as those for patch, security configuration, and other control implementation.

  • ii. General Management System Integration: Response processes should be integrated and/or coordinated with the organization’s general technological management systems and processes, such as asset management, change management (and associated CM technology, QA testing, exceptions), risk management (and associated exceptions, and tracking), the development, testing, integration, deployment, and monitoring activities of the system development life cycle, and enterprise architecture. For example, VRS scheduling decision-making is most effective when informed by mature asset inventory management for technology, data, identity, and service assets.

  • iii. Access to systems should leverage on-demand access or Zero Standing Privilege (ZSP) to reduce access vulnerabilities and allow privileged access during scheduled and emergency response.

• g. Remediation progress monitoring, validation, and tracking

  • i. Monitoring and tracking of remediations and mitigations against the schedule should be performed, with appropriate tie-ins to Vulnerability Management Reporting and Vulnerability Management Metrics processes to ensure adequate monitoring, reporting, and communication to support timely and effective mitigation of security risks.

  • ii. Processes to validate the effectiveness of remediation efforts should be implemented to ensure vulnerabilities have been successfully addressed, for all remediation types.

  • iii. Vulnerability remediation tracking should include all special cases applicable to the organization, including but not limited to:

    • Mitigations that are temporary until permanent remediations can be implemented,

    • Permanent or semi-permanent compensating controls, or

    • Permanent or semi-permanent vulnerability remediation exceptions for non-patchable systems.

• h. Review and Updates: Regular reviews and updates of the VRS, the associated vulnerability remediation processes and procedures, and the associated technologies and integrations should be conducted to reflect changes in cloud environments, security threats, and vulnerability management tools. The schedule, processes, and technological capabilities should be adapted to address changes in the volume and velocity of new vulnerabilities, evolving threats, and emerging security best practices

TVM-09: Vulnerability Prioritization

Control Specification

Use a risk-based method for effective prioritization of vulnerability remediation using an industry recognized framework.

Shared Implementation Guidelines

[All Actors]

1. Adopt an industry-recognized framework (e.g latest version CVSS) to prioritize vulnerabilities consistently across all partners.

2. Ensure consistent scoring across systems, and leverage threat intelligence to adjust prioritization based on active and emerging threats that considers severity, exploitability, asset criticality, and business impact.

Implementation Guidelines for Cloud Service Providers (CSP)

1. Prioritize vulnerabilities across infrastructure, platforms, and services using risk-based frameworks, considering multi-tenant impact, exposure, and service availability.

[All Actors]

1. Adopt an industry-recognized framework (e.g latest version CVSS) to prioritize vulnerabilities consistently across all partners.

2. Ensure consistent scoring across systems, and leverage threat intelligence to adjust prioritization based on active and emerging threats that considers severity, exploitability, asset criticality, and business impact.

From CCM v4.1: Control Ownership Rationale. The implementation responsibility for this control is shared between both parties CSP and CSC, and both are independently responsible for implementing a risk-based model for vulnerability prioritization according to their own business needs and compliance requirements, and irrespectively of the cloud service delivery models (IaaS/PaaS/SaaS). Each party, CSP and CSC is responsible for the remediation of vulnerabilities identified within the assets they own and securely manage.

Implementation Guidelines. Applicable to all service models: Vulnerability prioritization is a critical security control for CSPs to effectively manage and mitigate security risks in cloud environments. By prioritizing vulnerabilities based on their potential impact and likelihood of exploitation, CSPs can focus their resources on the most critical threats and reduce the overall attack surface of their cloud infrastructure.

For all identified vulnerabilities on the host infrastructure, network devices, virtualization technologies, operating systems, platform applications such as databases, and web applications, the CSP should use a risk-based model for effective prioritization of vulnerability remediation using an industry-recognized framework, such as but not limited to: CVSS, the OWASP risk rating methodology, EPSS, SSVC, etc.

Vulnerabilities should be prioritized in terms of their relative risk, importance, organizational impact, and urgency. When evaluating impact, the CSP should consider exposure levels to applicable threats from its specific usage and/or implementation. When evaluating importance, the CSP should consider the criticality and value of the affected assets. Finally, when assessing urgency, the CSP should consider the vulnerability scoring ratings and timeframes, the relevance to current and ongoing threats, and the effort required for remediation.

Implementation best practices for vulnerabilities prioritization include (but not be limited to):

• a. Risk-based Vulnerabilities Prioritization:

  • i. Vulnerabilities that pose the greatest risk to the cloud organization should be prioritized first, based on their severity, likelihood of exploitation, and potential impact

  • ii. A vulnerability prioritization matrix can be used to guide decision-making and ensure a consistent approach to vulnerability management

• b. Vulnerability Scoring System: An appropriate scoring system (e.g., CVSS, EPSS, SSVC, etc.) should be integrated into the vulnerabilities management process and used for assessing the severity of vulnerabilities based on their potential impact and exploitability. CSPs should use appropriate scoring to objectively prioritize vulnerabilities and make informed decisions about remediation efforts

• c. Threat Intelligence Feeds: Threat intelligence feeds provide real-time information about emerging threats, vulnerabilities, and exploits and should be integrated into the vulnerability management processes to dynamically prioritize vulnerabilities

• d. Asset Criticality: Vulnerabilities prioritization should consider the criticality of the assets affected (i.e., Assets with higher criticality, such as those that store sensitive data or support critical business functions, should be prioritized for remediation)

• e. Remediation Workflows: CSPs should establish clear remediation workflows to ensure that prioritized vulnerabilities are addressed promptly and effectively

• f. Prioritization Effectiveness: The effectiveness of vulnerability prioritization strategies should be continuously measured (e.g., by tracking remediation times), to help refine prioritization criteria and improve overall security effectiveness

• g. CSCs Collaboration: The CSP should collaborate with the CSCs to understand their specific security requirements and priorities in order to tailor its vulnerability prioritization strategies to better align with CSC needs and risk tolerance h.Continuous Monitoring and Evaluation: The CSP should continuously monitor and adopt evolving cloud security best practices, including those related to vulnerability prioritization.

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.

Shared Implementation Guidelines

[All Actors]

1. Adopt a Risk-Based Threat Management Framework (e.g. NIST SP 800-30, SO/IEC 27005, MITRE ATT&CK for AI and Cloud, etc.)

   • Establish a continuous threat intelligence process.

   • Identify relevant AI and cloud-specific threat vectors.

   • Classify assets, data flows, and AI components to prioritize risks based on impact and likelihood.

   • Use threat modeling (e.g., STRIDE, DREAD) on AI pipeline stages.

2. Prioritize threats based on: Potential for model manipulation, poisoning, inversion attacks, Data exposure risk, Business impact (e.g., customer-facing models vs. internal tools).

3. Implement risk response options: mitigate, accept, transfer, avoid.

4. Align with the organization’s incident response plan (IRP).

5. Map AI-specific threats (e.g., adversarial ML inputs) to response playbooks.

6. Document and automate detection-and-response logic where feasible.

Implementation Guidelines for Cloud Service Providers (CSP)

1. Offer built-in threat detection for AI workloads (e.g., abnormal model behavior, training data exfiltration).

2. Prioritize infrastructure-level threats: VM escape, Tenant cross-contamination, GPU resource abuse.

3. Implement shared responsibility guidance for AI-specific controls.

4. Provide secure service catalogs and pre-hardened deployment templates.

[All Actors]

1. Adopt a Risk-Based Threat Management Framework (e.g. NIST SP 800-30, SO/IEC 27005, MITRE ATT&CK for AI and Cloud, etc.)

   • Establish a continuous threat intelligence process.

   • Identify relevant AI and cloud-specific threat vectors.

   • Classify assets, data flows, and AI components to prioritize risks based on impact and likelihood.

   • Use threat modeling (e.g., STRIDE, DREAD) on AI pipeline stages.

2. Prioritize threats based on: Potential for model manipulation, poisoning, inversion attacks, Data exposure risk, Business impact (e.g., customer-facing models vs. internal tools).

3. Implement risk response options: mitigate, accept, transfer, avoid.

4. Align with the organization’s incident response plan (IRP).

5. Map AI-specific threats (e.g., adversarial ML inputs) to response playbooks.

6. Document and automate detection-and-response logic where feasible.

From CCM v4.1: Control Ownership Rationale. This control applies to all service models (IaaS, PaaS, SaaS) because threats exist to all cloud service models and appropriate threat decision making and response are needed irrespective of cloud service model and type of cloud service provided or consumed.

Adeptly prioritizing, responding to, and validating residual risk from threats is important for all organizations, whether operating in a service consumer or service provider role. This control’s implementation responsibility is typically shared independently between the CSP and CSC because both the CSP and the CSC each need to have their own processes to manage threats, including the prioritization and response to threats specific to their respective operations, products, and services. The establishment of such processes is fully internal and unique to each organization, and the threats upon which the processes operate are unique to each respective organization, being identified and analyzed as part of their respective threat analysis and modelling programs.

Implementation Guidelines. Threat response processes should be in place to effectively ensure that relevant identified threats associated with cloud services are appropriately prioritized and addressed, and that associated mitigations are tested and validated for sufficiency and effectiveness. Threat response activities should be performed iteratively and progressively throughout the lifecycle of a system or service, integrated within the overall threat management process following the threat analysis activities.

Applicable to all service models: Processes for threat response should include at a minimum, but are not limited to, provisions on the following:

• a. Prioritization of Risks from Threats: Risk-driven prioritization that takes into account threat severities, organizational obligations and requirements, and realities of technical aspects (e.g., interdependencies, complexities).

• b. Identification of Risk Response to Threats: Identification and selection of appropriate risk response strategies for each identified threat, and associated investigation and planning.

  • i. Common strategies include mitigation, transference, avoidance, and acceptance.

  • ii. Mitigation strategies may require the identification and selection among multiple detailed technical remediation alternatives, each with different constraints, complexities, costs, and benefits, and may include design changes, new requirements, new controls, bug fixes, or similar.

  • iii. Mitigations should address not only the specific identified threat exposures of the system or process under immediate review but also any contributory factors and root causes where applicable, including gaps or deficiencies in architectural and design standards, organizational policy, and/or organizational processes that enabled the originally identified threat exposures.

• c. Implementation of Risk Response to Threats: The selected risk responses for each threat should be implemented into the solution through the organization’s appropriate integration into the respective system development and operational lifecycles, including testing for validation of effectiveness.

• d. Update of Threat Model (including residual risk acceptability): The threat model should be updated to reflect risk responses to threats, and threat analysis including risk evaluation performed to ensure that any residual risks due to identified threats are acceptable.

• e. Documentation of Threat Response: Key process artifacts of the threat response activity should be documented and tracked to provide for clarity, traceability, and risk tracking.

  • i. Threat model inputs of the threat response process include:

    • threats and associated risk ratings, including for impact and probability

    • evaluation scales, calculations, reasoning and rationales, and tools used

  • ii. Threat model outputs of the threat response process include

    • Prioritizations for response strategy

    • Response options and alternatives, deliberations, assumptions, analysis techniques

    • Response decisions and action items

    • Carryover and tracking of action items to system requirements, design, and control processes

    • Tracking of effectiveness testing and validation results, residual risk determinations, and acceptance

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.

Shared Implementation Guidelines

[All Actors]

1. Maintain a central system that tracks vulnerabilities from discovery through remediation, showing status, owner, severity and due date.

2. Implement a process for verifying the effectiveness of vulnerability remediation efforts, ensuring that identified vulnerabilities have been fully addressed.

3. After remediation, conduct tests to confirm that the vulnerability is no longer exploitable and that the system functions as intended.

4. Use automated tools and manual testing to verify that the patch or mitigation has been successfully applied.

5. Record verification activities, including test results and verification reports, to ensure accountability and transparency.

6. Communicate verification results to relevant stakeholders, including internal teams, management, and external parties if necessary.

7. Periodically review the tracking and verification process to ensure it remains aligned with evolving business goals, threat landscape and regulatory duties. Communicate verification results to relevant stakeholders, including notification of downstream or dependent actors when the vulnerability or patch is relevant to their systems.

Implementation Guidelines for Cloud Service Providers (CSP)

1. Ensure that AI models, services, applications, and cloud infrastructure undergo verification after vulnerability remediation to confirm that patches or mitigations have been successfully implemented.

2. Validate that AI models and application services are functioning correctly after patching, with no regression in performance or security.

3. Collaborate with security teams to integrate vulnerability verification into automated CI/CD pipelines and testing processes.

4. Document verification results and remediation efforts for audit purposes, ensuring traceability of actions taken.

[All Actors]

1. Maintain a central system that tracks vulnerabilities from discovery through remediation, showing status, owner, severity and due date.

2. Implement a process for verifying the effectiveness of vulnerability remediation efforts, ensuring that identified vulnerabilities have been fully addressed.

3. After remediation, conduct tests to confirm that the vulnerability is no longer exploitable and that the system functions as intended.

4. Use automated tools and manual testing to verify that the patch or mitigation has been successfully applied.

5. Record verification activities, including test results and verification reports, to ensure accountability and transparency.

6. Communicate verification results to relevant stakeholders, including internal teams, management, and external parties if necessary.

7. Periodically review the tracking and verification process to ensure it remains aligned with evolving business goals, threat landscape and regulatory duties. Communicate verification results to relevant stakeholders, including notification of downstream or dependent actors when the vulnerability or patch is relevant to their systems.

From CCM v4.1: Control Ownership Rationale. The implementation responsibility for this control is shared between both parties CSP and CSC, and both are independently responsible for implementing a vulnerabilities tracking and reporting process, according to their own business needs and compliance requirements, and irrespectively of the cloud service delivery models (IaaS/PaaS/SaaS). The CSP and CSC are responsible for tracking and reporting vulnerability identifications within the assets they own and securely manage.

Implementation Guidelines. Applicable to all service models: For all identified vulnerabilities on the host infrastructure, network devices, virtualization technologies, operating systems, platform applications such as databases, and web applications, the CSP is responsible for defining and implementing a process for tracking and reporting vulnerability identification and remediation activities that includes stakeholder notification.

The integrated TVM system should have comprehensive vulnerability tracking capabilities. Capabilities should include tracking when discoveries were made and remediated, systems impacted, reasons for the delay (where applicable), and any communications with stakeholders.

Implementation guidelines of a tracking and reporting system for all service models include (but not be limited to):

• a. Tracking System: A tracking system should be established to maintain a record of all vulnerabilities identified, prioritized, and remediated. This system should provide a view of vulnerability history, remediation status, and remaining open issues

  • i. The format and structure of vulnerability data stored in the tracking system should be standardized

  • ii. The aggregation of vulnerability data from various sources should be automated, where possible, including vulnerability scanners, remediation tools, and third-party feeds

  • iii. CSP APIs should be leveraged to automatically collect vulnerability data from cloud services and resources to provide real-time visibility into cloud-specific vulnerabilities

  • iv. A secure platform established for sharing threat intelligence and vulnerability information with CSCs. APIs and integration options for CSCs should be offered, to incorporate vulnerability remediation data into their own security tools

• b. Reporting and Notification:

  • i. A process and procedure should be implemented to communicate remediation plans to stakeholders, providing clear timelines and expected outcomes for vulnerability resolution

  • ii. Standardized reporting templates should be created that communicate vulnerability information, including context and content about the vulnerability, asset classification, vulnerability severity, potential impact and recommended remediation steps

  • iii. Reports can be tailored to the specific needs and interests of different stakeholder groups, such as security teams, application owners, and business stakeholders

  • iv. The distribution of vulnerability reports could be automated and sent to relevant stakeholders via email, secure file sharing platforms, or designated intranet channels

• c. All relevant stakeholders who need to be notified about vulnerability identification and remediation activities should be identified (e.g., security teams, product development teams, CSC support teams, and external auditors) vi. A notification protocol should be defined for alerting stakeholders about newly identified vulnerabilities. This protocol should specify the severity threshold for triggering notifications, the channels for communication, and the escalation process for critical vulnerabilities vii. A record of all notifications sent to stakeholders, including the date, time, recipient, and vulnerability details should be maintained viii. Escalation procedures should exist for notifying senior management or external parties in the event of severe or widespread vulnerabilities

TVM-12: Vulnerability Management Metrics

Control Specification

Establish, monitor and report metrics for vulnerability identification and remediation at defined intervals.

Shared Implementation Guidelines

[All Actors]

1. Implement continuous vulnerability scanning processes to detect vulnerabilities in real-time across systems, services, and applications.

2. Use automated scanning tools to monitor for new vulnerabilities as they arise, ensuring that systems are regularly checked for emerging threats.

3. Set thresholds for triggering alerts on identified vulnerabilities, prioritizing high-risk issues for immediate remediation.

4. Ensure that vulnerability scanning is integrated into the development lifecycle, with scans conducted during each stage (development, testing, deployment).

5. Maintain a dashboard for real-time visibility into scanning results, ensuring that teams are informed about the current security status of systems and applications.

6. Define standard metrics across partners. Align on core metrics like Mean time to Detect, Mean time to Remediate, and their calculation rules and reporting frequency.

Implementation Guidelines for Cloud Service Providers (CSP)

1. Implement continuous vulnerability scanning for AI models, orchestrated services, applications, and cloud platforms to identify new and emerging vulnerabilities.

2. Integrate vulnerability scanning into development workflows, ensuring that systems are scanned for vulnerabilities at every stage of the lifecycle.

3. Use automated tools to prioritize vulnerabilities based on risk and impact to ensure timely remediation.

4. Regularly review scanning results to identify patterns or recurring vulnerabilities, refining scanning practices as needed.

[All Actors]

1. Implement continuous vulnerability scanning processes to detect vulnerabilities in real-time across systems, services, and applications.

2. Use automated scanning tools to monitor for new vulnerabilities as they arise, ensuring that systems are regularly checked for emerging threats.

3. Set thresholds for triggering alerts on identified vulnerabilities, prioritizing high-risk issues for immediate remediation.

4. Ensure that vulnerability scanning is integrated into the development lifecycle, with scans conducted during each stage (development, testing, deployment).

5. Maintain a dashboard for real-time visibility into scanning results, ensuring that teams are informed about the current security status of systems and applications.

6. Define standard metrics across partners. Align on core metrics like Mean time to Detect, Mean time to Remediate, and their calculation rules and reporting frequency.

From CCM v4.1: Control Ownership Rationale. The implementation responsibility for this control is shared between both CSP and CSC, and both are independently responsible for establishing, monitor and report metrics on vulnerabilities identification and remediation, according to their own business needs and compliance requirements, and irrespectively of the cloud service delivery models (IaaS/PaaS/SaaS). The CSP and CSC should each have established a defined frequency of collecting metrics for vulnerability identification, remediation, and reporting within the assets they own and securely manage. This activity can be part of an existing and overarching policy and standard such as TVM, Vulnerability Scanning, and Patch Management policies.

Implementation Guidelines. Applicable to all service models: For all identified vulnerabilities on the host infrastructure, network devices, virtualization technologies, operating systems, platform applications such as databases, and web applications, the CSP is responsible for establishing, monitoring, and reporting metrics for vulnerability identification and remediation at defined intervals.

The integrated TVM system should be used to collect and report metrics about the vulnerability management program. Metrics should demonstrate the coverage, efficacy, and efficiency of operational TVM activities. Vulnerability management metrics should be used in assessing the effectiveness of an organization’s efforts to identify, prioritize, and remediate vulnerabilities.

• a. A process should be implemented to track vulnerability management metrics over time to identify trends, assess progress, and make data-driven decisions to enhance security posture (e.g., of metrics such as time-to-remediate, number of vulnerabilities closed, and recurrence of vulnerabilities)

• b. Vulnerability management metrics should be benchmarked against industry standards and best practices to identify areas for improvement

Here are some examples of vulnerability management metrics:

• a. Vulnerability Identification Rate:

  • i. Definition: The rate at which new vulnerabilities are identified within the organization’s systems

  • ii. Metric Calculation: Number of newly identified vulnerabilities / Total assets or systems

• b. Time-to-Remediate:

  • i. Definition: The average time taken to remediate or mitigate identified vulnerabilities

  • ii. Metric Calculation: Average time from vulnerability discovery to resolution

• c. Vulnerability Severity Distribution:

  • i. Definition: Breakdown of identified vulnerabilities based on their severity levels (e.g., critical, high, medium, low)

  • ii. Metric Calculation: Percentage distribution of vulnerabilities by severity level

• d. Open Vulnerabilities Over Time:

  • i. Definition: The trend of open vulnerabilities tracked over a specific period

  • ii. Metric Calculation: Number of open vulnerabilities at specific intervals (daily, weekly, monthly)

• e. Patch Compliance Rate:

  • i. Definition: Percentage of systems or assets that are up-to-date with the latest patches

  • ii. Metric Calculation: (Number of patched systems / Total systems) * 100

• f. False Positive Rate:

  • i. Definition: The percentage of reported vulnerabilities that are later determined to be false positives

  • ii. Metric Calculation: (Number of false positives / Total vulnerabilities reported) * 100 i. Vulnerability Rescan Rate: i. Definition: Frequency at which vulnerability scans are repeated to verify remediation effectiveness ii. Metric Calculation: Number of vulnerability rescan events per month or quarter

• g. Top Remediated Vulnerabilities:

  • i. Definition: Identification of the most frequently remediated vulnerabilities

  • ii. Metric Calculation: Number of times specific vulnerabilities are remediated

• h. Vulnerability Aging:

  • i. Definition: Average age of open vulnerabilities, indicating how long vulnerabilities remain unresolved

  • ii. Metric Calculation: Average time vulnerabilities have been open (current date - discovery date)

• i. Coverage of Vulnerability Assessments:

  • i. Definition: Percentage of systems or assets that undergo regular vulnerability assessments

  • ii. Metric Calculation: (Number of assessed systems / Total systems) * 100

These metrics help organizations gauge their vulnerability management program’s efficiency, identify areas for improvement, and demonstrate the overall security posture.

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.

Shared Implementation Guidelines

[All Actors]

1. Identify critical guardrail requirements, by reviewing applicable regulatory standards (e.g., GDPR) and internal policies and by assessing potential impact on safety, privacy, fairness and transparency.

2. Implement Technical Safeguards:

   • a. Develop Input and Output Validation Mechanisms:

     • Ensure the AI model processes only authorized inputs and generates outputs within pre-defined acceptable parameters.

     • Apply filters to flag or reject anomalous inputs or outputs, particularly in cases where outputs could be harmful.

     • Leverage canary tokens to detect potential prompt leakage attacks and block responses containing unauthorized system instructions.

   • b. Set Thresholds for Model Confidence:

     • Establish a threshold confidence level below which the AI system must defer to human intervention or request additional validation.

     • Log instances when outputs fall below the threshold for future analysis and system improvement.

   • c. Integrate Risk-Based Guardrails:

     • Apply risk-scoring methods to outputs, adjusting system responses accordingly based on risk level (e.g., higher scrutiny for high-impact decisions).

3. Develop Fail-Safe Mechanisms:

   • a. Implement Emergency Stop Mechanisms:

     • Include a shutdown feature that can be triggered automatically in response to detected anomalies, or manually by a human supervisor.

     • Ensure that shutdowns do not lead to data loss and create recovery checkpoints where possible.

   • b. Set Up Recovery Protocols:

     • Establish recovery protocols that enable safe system restart following a shutdown, ensuring that unresolved issues are addressed before the system is reactivated.

4. Establish Governance and Monitoring Procedures:

   • a. Assign a Guardrail Review Team:

     • Designate a team responsible for reviewing guardrail effectiveness, responding to flagged issues, and recommending guardrail adjustments based on system performance and risk assessment.

     • Ensure the team includes personnel capable of intervening and making decisions in case of system failures or unexpected outputs.

   • b. Continuously Monitor System Performance and Risk Indicators:

     • Implement continuous monitoring tools to track system performance, accuracy, and risk indicators in real time.

     • Set up automated alerts to notify the guardrail review team of anomalies or potential risks.

     • Include human-in-the-loop (HITL) mechanisms for reviewing flagged anomalies or when the system reaches critical decision thresholds.

5. Define Operational Protocols for Guardrail Adjustments:

   • a. Regularly Review and Update Guardrails:

     • Conduct regular reviews of guardrails, considering changes in regulatory requirements, new risk scenarios, and feedback from system monitoring.

     • Ensure that human oversight is involved when adjustments to guardrails are necessary, particularly when dealing with high-impact or high-risk decisions.

   • b. Document Adjustments and Interventions:

     • Maintain a log of all guardrail adjustments and system interventions, including the rationale for changes and the outcome of each intervention.

     • Conduct periodic audits to evaluate the effectiveness of guardrails and identify opportunities for improvement.

Implementation Guidelines for Cloud Service Providers (CSP)

1. Ensure that vulnerability reports related to AI models, applications, and cloud platforms are well-documented and shared with relevant teams for analysis and remediation.

2. Use standardized templates for vulnerability reporting to ensure that all necessary details are included and that reports are easily understood.

3. Provide regular vulnerability reports to stakeholders, including internal teams, senior management, and clients, as needed, to maintain transparency.

4. Integrate vulnerability reporting into regular governance and security reviews to ensure ongoing visibility and accountability.

[All Actors]

1. Identify critical guardrail requirements, by reviewing applicable regulatory standards (e.g., GDPR) and internal policies and by assessing potential impact on safety, privacy, fairness and transparency.

2. Implement Technical Safeguards:

   • a. Develop Input and Output Validation Mechanisms:

     • Ensure the AI model processes only authorized inputs and generates outputs within pre-defined acceptable parameters.

     • Apply filters to flag or reject anomalous inputs or outputs, particularly in cases where outputs could be harmful.

     • Leverage canary tokens to detect potential prompt leakage attacks and block responses containing unauthorized system instructions.

   • b. Set Thresholds for Model Confidence:

     • Establish a threshold confidence level below which the AI system must defer to human intervention or request additional validation.

     • Log instances when outputs fall below the threshold for future analysis and system improvement.

   • c. Integrate Risk-Based Guardrails:

     • Apply risk-scoring methods to outputs, adjusting system responses accordingly based on risk level (e.g., higher scrutiny for high-impact decisions).

3. Develop Fail-Safe Mechanisms:

   • a. Implement Emergency Stop Mechanisms:

     • Include a shutdown feature that can be triggered automatically in response to detected anomalies, or manually by a human supervisor.

     • Ensure that shutdowns do not lead to data loss and create recovery checkpoints where possible.

   • b. Set Up Recovery Protocols:

     • Establish recovery protocols that enable safe system restart following a shutdown, ensuring that unresolved issues are addressed before the system is reactivated.

4. Establish Governance and Monitoring Procedures:

   • a. Assign a Guardrail Review Team:

     • Designate a team responsible for reviewing guardrail effectiveness, responding to flagged issues, and recommending guardrail adjustments based on system performance and risk assessment.

     • Ensure the team includes personnel capable of intervening and making decisions in case of system failures or unexpected outputs.

   • b. Continuously Monitor System Performance and Risk Indicators:

     • Implement continuous monitoring tools to track system performance, accuracy, and risk indicators in real time.

     • Set up automated alerts to notify the guardrail review team of anomalies or potential risks.

     • Include human-in-the-loop (HITL) mechanisms for reviewing flagged anomalies or when the system reaches critical decision thresholds.

5. Define Operational Protocols for Guardrail Adjustments:

   • a. Regularly Review and Update Guardrails:

     • Conduct regular reviews of guardrails, considering changes in regulatory requirements, new risk scenarios, and feedback from system monitoring.

     • Ensure that human oversight is involved when adjustments to guardrails are necessary, particularly when dealing with high-impact or high-risk decisions.

   • b. Document Adjustments and Interventions:

     • Maintain a log of all guardrail adjustments and system interventions, including the rationale for changes and the outcome of each intervention.

     • Conduct periodic audits to evaluate the effectiveness of guardrails and identify opportunities for improvement.

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.

Shared Implementation Guidelines

[Applicable to all actors except CSP]

1. Establish a UEM governance committee with representatives from MP, OSP, AP, and AIC to approve and review endpoint policies collaboratively.

2. Maintain a central repository for all endpoint policies and procedures, including onboarding/decommissioning steps, patching schedules, and technical policy baselines (e.g., device hardening configurations, DLP rules, secure boot/device integrity checks, access control policies, encryption standards, and remote wipe criteria).

3. Integrate endpoint policy enforcement into the UEM platform (e.g., with automated compliance checks, alerting on misconfigurations or non-compliance like jailbreaks/rooting, and enforcing policy-based access restrictions).

4. Implement monthly KRI/KPI reporting (e.g., percentage of compliant devices, encryption coverage, patch timeliness, anti-malware status), complemented by quarterly joint audits of endpoint compliance metrics and policy effectiveness to feed results back into policy refinement cycles.

Implementation Guidelines for Cloud Service Providers (CSP)

1. Expose IAM‑UEM Integration APIs: Publish reference architectures and APIs to tie CSP identity/access controls into customer UEM solutions, enabling conditional access and device‑based policy enforcement (e.g., Azure AD Conditional Access, AWS IAM policy integration)

2. Continuous Logging & Monitoring: Maintain, by default, detailed logs and real‑time metrics from CSP infrastructure endpoints and management consoles (via AWS CloudTrail, Azure Monitor, GCP Cloud Logging) to support audit, alerting, and incident response.

3. Publish Best‑Practice Guidance: Provide comprehensive documentation, including sample configurations, reference architectures, and use‑case playbooks for secure endpoint onboarding, patching, and decommissioning.

4. Align to Industry Frameworks: Deliver cloud‑specific samples that map to e.g. CIS Benchmarks, NIST SP 800‑53, or ISO 27001 Annex A controls, helping customers translate generic policies into concrete CSP implementations.

5. Support Remote Quarantine & Wipe: Expose native capabilities (e.g., Microsoft Intune’s remote wipe, AWS SSM Automation runbooks) so that customers can swiftly isolate or sanitize compromised endpoints.

From CCM v4.1: Control Ownership Rationale. This is a “Shared (Independent)” control for both the CSP and CSC since all endpoint devices utilized to access cloud services should be managed within corporate policy and in line with industry standards.

Implementation Guidelines. Applicable to all service models: Irrespective of cloud service delivery model, the CSP is responsible for establishing, communicating and implementing policies, standards, processes/procedures, and tooling for all endpoints.

Policies should include (but not limited to) provisions on the following: Policies and procedures for both managed and unmanaged endpoints (including BYOD) should include the following components:

• a. Scope and Objectives: A definition and scope of endpoints and the acceptable-use policy objectives and requirements for all endpoints (mobile devices, virtual, desktop, etc.)

Note: physical and virtual servers, containers, and similar endpoints are addressed in the DCS and IVS domains, while application and interface endpoints are discussed in the AIS domain

• a. Application and Service Approval: A list of approved cloud services and applications that personnel are permitted to use on their endpoints should be maintained. The list should be regularly reviewed and updated (incl. approved systems, servers, applications, application stores, application extensions, and plugins)

• b. Endpoints Compatibility: Minimum OS requirements for endpoints to ensure compatibility with essential applications and security tools should be established. An compatibility matrix for approved applications should be maintained to ensure they function properly on the supported operating systems

• c. Endpoint Inventory: A maintained inventory of all endpoints connected to the organization’s network, including laptops, desktops, tablets, mobile phones, IoT devices, servers, and virtual environments (should include device details, ownership information, security status, and software configurations)

Note: each endpoint device should be assigned to a named person who is responsible for it. Such devices may be shared (e.g., in shared work areas), but a single individual should still be assigned responsibility for it. Non-device endpoints should also have owners responsible for assessing risks and ensuring appropriate controls.

• a. Endpoint Management: Granular access control mechanisms to restrict endpoint access to authorized systems and resources. Data access limitations should be enforced to prevent unauthorized data storage, transmission, or processing on endpoints

• b. Endpoint Operating System: A change management process for endpoint operating systems to control and review changes to configurations, software installations, patches and updates

• c. Storage Encryption: Whole-disk encryption should be utilized on all endpoints to protect sensitive data at rest

• d. Anti-Malware Detection and Prevention: Real-time anti-malware software deployment on all endpoints and regular scans scheduling to detect and prevent malicious software infections

• e. Software Firewall: Software firewalls should be configured on all endpoints to control inbound and outbound network traffic

• f. Data Loss Prevention: DLP technologies should be configured to monitor and control the movement of sensitive data from endpoints. Enforce data access restrictions and prevent unauthorized data transfer to external devices or cloud services

• g. Remote Locate: Remote geo-location capabilities enabled on mobile devices to track their location in case of loss or theft

• h. Remote Wipe: Remote wipe capabilities enabled on all endpoints to remotely delete company data in case of loss or theft. Requirements related to non-company data loss if a full or partial wipe of a device is required should be defined

• i. Third-Party Endpoint Security Posture: Security requirements, responsibilities, and obligations related to third-party endpoint access in contractual agreements and SLAs

• j. Privacy: Requirements regarding privacy expectations for remote location identification, litigation, e-discovery, and legal holds (especially for personally-owned devices) should be defined

• k. Approval: Approval requirements and senior management involvement to ensure alignment with the organization’s strategic goals and risk appetite

  • i. An approval process should be established for any changes or modifications to the policy and procedures

  • ii. A documented record of approvals (including dates, names of approvers, and any relevant comments or discussions) should be maintained

• l. Communication: Effective communication of the policy and procedures should be facilitated to all relevant cloud stakeholders

• m. Maintenance and Reviews: Endpoint security policies and procedures should be documented, reviewed and updated at least annually to ensure alignment with the evolving cloud security landscape and to reflect changes in cloud technology, regulations, and risks

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.

Shared Implementation Guidelines

[Applicable to all actors except CSP]

1. Use a unified approval workflow (e.g., ticketing system or governance portal) where MP, OSP, AP, and AIC submit requests, perform formal reviews, and authorize new applications or services.

2. Maintain a single source of truth for the approved software/services list with version control, change logs, categorization by risk level, sensitivity, and purpose, and an established exception handling process backed by formal risk assessment and approval.

3. Automate enforcement of the approved list via UEM controls (such as application whitelisting, allowlisting, and device compliance gating), including mechanisms for access denial or quarantine based on integrity checks or policy violations (e.g., jailbroken or non‑compliant devices).

4. Define review frequency based on risk tier and conduct periodic triage reviews (e.g., monthly or quarterly) for critical/high‑risk apps and semi‑annual or annual reviews for lower‑risk ones, with provisions for ad‑hoc or event‑driven reassessments (triggered by incidents or threat intelligence).

5. Embed audit and monitoring capabilities that log and flag installation attempts for unauthorized or sensitive applications, and ramp up user awareness via training and communication of application usage policies.

Implementation Guidelines for Cloud Service Providers (CSP)

1. Expose IAM UEM Integration APIs: Publish reference architectures and APIs to tie CSP identity/access controls into customer UEM solutions,enabling conditional access and device based policy enforcement (e.g., Azure AD Conditional Access, AWS IAM policy integration).

2. Continuous Logging & Monitoring: Maintain, by default, detailed logs and real time metrics from CSP infrastructure endpoints and management consoles (via AWS CloudTrail, Azure Monitor, GCP Cloud Logging) to support audit, alerting, and incident response.

From CCM v4.1: Control Ownership Rationale. This is a “Shared (Independent)” control for both the CSP and CSC since the they should both should maintain an approved list of applications that can be installed on all endpoint devices utilized to access cloud services based on operating systems (OS)/platforms, such as but not limited to: Linux, Windows, macOS, Android, and iOS. This is not a service delivery model (IaaS, PaaS, or SaaS) specific.

Implementation Guidelines. Applicable to all service models: 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):

• a. Centralized Configuration: For managed endpoints, universally enforce policies through one or more centralized configuration management tools

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

• c. 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)

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

UEM-03: Compatibility

Control Specification

Define and implement a process for the validation of the endpoint device’s compatibility with operating systems and applications.

Shared Implementation Guidelines

[Applicable to all actors except CSP, AIC]

1. Develop and publish a compatibility matrix covering OS versions, hardware specs, and required security agents that is jointly maintained by MP, OSP, and AP.

2. Require that pilot testing of OS upgrades or new security tools occur in a controlled lab environment before enterprise wide deployment via UEM.

3. Automate compatibility checks within the UEM toolchain, blocking non compliant endpoints from accessing critical resources until remediation.

4. Schedule annual reviews of compatibility requirements to incorporate new platform releases and deprecate unsupported configurations.

Implementation Guidelines for Cloud Service Providers (CSP)

1. Provide clear documentation of any endpoint compatibility requirements or constraints related to using the CSP’s services (e.g., supported operating systems and browser versions for cloud management tools or agents).

2. Ensure any CSP-provided client software or agents (for endpoint management, cloud access, etc.) are tested and supported on the operating systems and device types commonly used by the AIC, MP, OSP, and AP, and communicate any known incompatibilities or required updates.

From CCM v4.1: Control Ownership Rationale. This is a “Shared (Independent)” control for both the CSP and CSC since they should both have documented processes and procedures in place to ensure endpoint device compatibility with operating systems and applications.

Implementation Guidelines. Applicable to all service models: Irrespective of cloud service delivery model, the CSP is responsible for defining and implementing a process for the validation of the endpoint device’s compatibility with operating systems and applications.

The CSP should implement a diagnostic tool that checks endpoint security features for noncompliance and automates remedial activities before endpoints are allowed to access corporate networks.

The CSP should have a documented application validation process to test for compatibility issues regarding mobile devices, operating systems, and applications. Consistent operating system versions should be enforced across the organization to simplify management and reduce compatibility issues.

Misconfigured endpoints may not only impact operations but also introduce attack vectors. Poor configuration settings could involve open ports, outdated exceptions, and insecure protocols allowed. Any configuration changes once in production should follow change management guidelines (why, what, how) and require appropriate approvals.

UEM-04: Endpoint Inventory

Control Specification

Maintain an inventory of all endpoints used to store, access and process company data.

Shared Implementation Guidelines

[Applicable to all actors except CSP]

1. Sync UEM managed device inventories with the central asset management system (e.g., CMDB) to ensure a unified view of all endpoints across stakeholders.

2. Enforce automated discovery agents on endpoints to capture new or rogue devices and flag discrepancies against the approved inventory.

3. Implement real time dashboards for inventory health, highlighting unregistered endpoints or those pending decommissioning.

4. Conduct monthly reconciliation between UEM inventory and network logs, escalating any unknown devices to the governance committee for review.

Implementation Guidelines for Cloud Service Providers (CSP)

1. Provide visibility into the devices and endpoints interacting with the cloud environment (e.g., through logs or device posture information), to help the AIC identify and track all endpoints accessing organizational data.

2. Support integration between the cloud platform and the AIC’s asset management or CMDB systems (for instance, API access to cloud-hosted asset information)

From CCM v4.1: Control Ownership Rationale. This is a “Shared (Independent)” control for both the CSP and CSC since they should both maintain an accurate and up-to-date centralized inventory of all endpoints used to store and access organizational data.

Implementation Guidelines. Applicable to all service models: Irrespective of cloud service delivery model, the CSP is responsible for maintaining an accurate and up-to-date centralized inventory (refer to DCS-06) of all endpoints used to store and access organization data.

The CSP should implement discovery tools to identify all endpoint devices connected to the organization’s network and update the asset inventory.

Where possible, the CSP should ensure that the asset inventory records the network address, hardware address, device name, asset owner, and department for each asset, and whether the asset has been approved to connect to the network.

The CSP should ensure that any unauthorized endpoints are removed from the network, quarantined, or added to the inventory in a timely manner.

An inventory of all mobile devices used to store and access company data should be kept, maintained and regularly updated to reflect changes in device ownership, configurations, and software versions.

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.

Shared Implementation Guidelines

[Applicable to all actors except CSP]

1. Integrate UEM with patch management, antivirus, and configuration management databases to automate enforcement of baseline security settings.

2. Apply role based profiles in the UEM system so that MP, OSP, AP, and AIC endpoints each receive the correct security baselines and application packages.

3. Enable real time compliance monitoring and alerting for critical deviations (e.g., missing patches, disabled malware protection) on managed endpoints, with risk based prioritization of remediation activities.

4. Run monthly compliance reports across all endpoint categories, reviewing exceptions and ensuring timely remediation of any non compliant devices. Implement an exception management workflow for temporary or unregistered assets.

Implementation Guidelines for Cloud Service Providers (CSP)

1. Enable integration of the AIC’s UEM or device compliance data with the cloud environment (for example, support conditional access policies that only allow devices meeting security baseline requirements to access cloud services).

2. Provide baseline security benchmarks or templates for cloud-hosted endpoints (e.g., recommended OS security settings or hardened configurations) to assist the AIC in establishing and enforcing consistent endpoint controls.

3. Offer patch management and threat intelligence services that can integrate with the customer’s UEM, helping automate the enforcement of security policies (such as providing up-to-date patch feeds or malware signatures that the UEM can use to keep endpoints secure).

From CCM v4.1: Control Ownership Rationale. This is a “Shared (Independent)” control for both the CSP and CSC, since they should each implement measures to enforce their respective policies and controls across all endpoints uniformly, ideally with a centralized configuration management tool.

Implementation Guidelines. Applicable to all service models: Implementation best practices include (but not limited to):

• a. Endpoints Management: Technical measures to enforce controls that manage endpoints permitted to access systems and/or store, transmit, or process organizational data

• b. Endpoints Access Control: Risk assessments to determine what (if any) endpoint types are acceptable for system access or information storage if alternate protection mechanisms are used

• c. Centralized Configuration: For managed endpoints, universal enforcement of policies through one or more centralized configuration management tools

• d. Endpoints Security Circumvention Prevention: Circumvention of vendor-supported and integrated (built-in) security controls on endpoints (e.g., jailbreaking or rooting) should be prohibited. These restrictions should be enforced through detective and preventive controls on the endpoint, managed through a centralized system (e.g., an endpoint system configuration control, or mobile device management system)

• e. Unmanaged Endpoints Hardening: For unmanaged endpoints, best practices for hardening the endpoints should be considered by updating the default configurations, disabling unnecessary services, encrypting data on the endpoint, and segmenting the unmanaged endpoints from the main network

UEM-06: Automatic Lock Screen

Control Specification

Configure all relevant interactive-use endpoints to require an automatic lock screen.

Shared Implementation Guidelines

[Applicable to all actors except CSP]

1. Enforce a common idle timeout (e.g., 15 minutes or less) on all user endpoints across MP, OSP, AP, and AIC via UEM policies to automatically lock devices after inactivity.

2. Configure the UEM platform to apply this lock screen policy uniformly and prevent end-user modifications, with any non-compliant endpoints flagged to all stakeholders’ security teams for prompt action.

3. Include automatic lock screen checks in joint security audits, verifying every participant’s devices lock properly and require re-authentication (password or biometric) after the idle period.

4. Establish a shared standard for lock screen settings (such as requiring MFA or strong passwords upon unlock) so that all organizations maintain a consistent baseline for endpoint access security.

5. Encourage the use of passkeys (FIDO2/WebAuthn) as the primary unlock mechanism on managed endpoints, leveraging device biometrics or PIN and to replace or supplement passwords and traditional MFA.

Implementation Guidelines for Cloud Service Providers (CSP)

1. Enforce a standard auto-lock policy for all interactive management consoles and devices under the cloud provider’s control, requiring screen lock activation after a short period of inactivity (e.g., 5 minutes).

2. Deploy centralized UEM configurations that push uniform lock-screen settings to all relevant devices across the service environment, ensuring no device used in administration operates without an automatic lock.

3. Prevent tampering with lock settings by using administrative controls, for example, lock the ability to extend timeout durations or disable the lock screen on any CSP-issued laptops or support workstations.

4. Monitor and audit compliance with the auto-lock requirement through the UEM platform, receiving alerts or reports on any device that is not enforcing the policy and remediating those exceptions immediately.

From CCM v4.1: Control Ownership Rationale. This is a “Shared (Independent)” control for both the CSP and CSC, since each should configure their respective interactive-use endpoints to require an automatic lock screen.

Implementation Guidelines. Applicable to all service models: Inactivity timeout should be set to automatically trigger the lock screen when the endpoint device is idle for a specified period. The security lockout controls should automatically initiate after the endpoint remains idle from user interaction after a predefined time period. The user should then re-enter their credentials to gain access to the endpoint.

Lock screen settings should be configured to require strong passwords, biometric authentication or passwordless authentication (device PINs, fingerprint recognition) for unlocking.

UEM-07: Operating Systems

Control Specification

Manage changes to endpoint operating systems, patch levels, and/or applications through the company’s change management processes.

Shared Implementation Guidelines

[Applicable to all actors except CSP]

1. Align OS and critical application patching and update schedules across MP, OSP, AP, and AIC so all endpoints receive critical security updates within an agreed timeframe, minimizing any one party’s exposure to vulnerabilities.

2. Use UEM-driven reports to verify OS version and patch level compliance uniformly; all stakeholders should regularly exchange endpoint patch status or attestations to ensure mutual trust in each other’s device security posture.

3. Coordinate major operating system changes through a joint change management process – if one provider plans a significant OS upgrade or configuration change, notify and review with other stakeholders (e.g., via a cross-organization Change Advisory Board) to preempt compatibility or security issues.

4. Rapidly communicate and address emergency OS vulnerabilities as a team: if a zero-day patch is released, all parties agree to fast-track its deployment and inform one another when their endpoints have been updated, maintaining parity in defense.

Implementation Guidelines for Cloud Service Providers (CSP)

1. Integrate endpoint changes (operating system updates, critical patches, or new administrative tool deployments on CSP-operated devices) into the formal change management process. Require that any change affecting cloud operations endpoints is documented in a change ticket and approved by the appropriate authority before implementation.

2. Coordinate maintenance windows for endpoint updates with all relevant parties. For example, if the CSP plans to update software on support engineer laptops or rotate certificates on devices, schedule these changes during agreed-upon periods and notify MP, OSP, AP, and AIC stakeholders if the changes could indirectly affect them.

3. Maintain an inventory and configuration baseline for all CSP administrative endpoints and use this as a reference during change management. Any deviation from the baseline (such as a new software installation or a configuration tweak) should trigger a review and record in the change log, ensuring traceability of who made the change and why.

4. After deploying changes to CSP-managed endpoints, perform post-change validation. For instance, if a new security patch is applied to an admin workstation, verify the device can still connect to management consoles and that security tools are functioning. Document the outcome of the change implementation and any lessons learned in the change management system.

From CCM v4.1: Control Ownership Rationale. This is a “Shared (Independent)” control for both the CSP and CSC, since they should each manage their changes inclusive of patching to endpoint operating systems and applications through their respective change management processes.

Implementation Guidelines. Applicable to all service models: The organization should include a formal change and patch management process to ensure that endpoint operating systems and applications are up to date with the latest security patches and that changes are performed in a controlled and consistent manner (refer to CCC domain). Patch deployment should be automated to minimize vulnerability windows and reduce the risk of exploitation.

Implementation best practices for endpoints OS change management include (but not limited to):

• a. Endpoints Change Management:

  • i. Identification and recording of significant changes

  • ii. Planning and testing of changes

  • iii. Assessment of the potential impacts (including security impacts) of such changes

  • iv. Formal approval for proposed changes

• b. Communication of change details to all respective stakeholders vi. Rollback procedures in case of unsuccessful changes or unforeseen events

UEM-08: Storage Encryption

Control Specification

Protect information from unauthorized disclosure on managed endpoint devices with storage encryption.

Shared Implementation Guidelines

[Applicable to all actors except CSP]

1. Mandate full-disk encryption on all managed endpoints for every AI supply chain participant, using approved tools (e.g., BitLocker, FileVault) and verifying compliance via UEM dashboards to ensure data at rest on any device is protected.

2. Set a unified policy that no sensitive AI data (models, training data, customer information) may reside on an endpoint unless storage encryption is active; configure UEM to block or quarantine devices that report as unencrypted.

3. Adopt a consistent cryptographic strength standard across stakeholders (e.g., AES-256 encryption, FIPS 140-2 compliant solutions) for endpoint encryption, so that all data is secured to an equivalent level regardless of which organization’s device it is on.

4. Include encryption status in regular joint security reviews or compliance attestations, requiring each stakeholder to demonstrate that lost or stolen devices from their environment were encrypted (providing mutual assurance that a device breach at one party won’t expose plaintext data).

Implementation Guidelines for Cloud Service Providers (CSP)

1.Apply full-disk encryption on all Cloud Service Provider-managed endpoints and portable media that store or handle service data. This includes laptops used by cloud operations staff, support engineers’ devices, and any removable drives or backup media containing configuration files or customer information.

1. Use industry-standard encryption solutions (e.g., BitLocker for Windows, FileVault for Mac, LUKS for Linux) with strong algorithms (AES-256 or equivalent) and tie encryption to secure hardware elements like TPM chips to prevent tampering. Manage the recovery keys in a secure key management system, ensuring only authorized personnel can retrieve them in case a device needs to be unlocked.

2. Enforce encryption policies through automated checks: the UEM platform should flag any CSP device that is not reporting an active encryption status. Devices that are unencrypted or where encryption is turned off should be quarantined from network access or prompted for immediate remediation.

3. Include encryption verification as part of routine security audits. For example, when performing quarterly audits or risk assessments, confirm that 100% of sampled CSP devices have encryption enabled. Document these findings and address any gaps by promptly encrypting those devices or removing them from service.

From CCM v4.1: Control Ownership Rationale. This is a “Shared (Independent)” control. Its implementation is not service delivery model specific (IaaS, PaaS, or SaaS). Both the CSP and CSC are responsible for enforcing storage encryption on their respective endpoint devices.

Implementation Guidelines. Applicable to all service models: The CSP should document formal encryption policies based on the sensitivity of the data being protected. In addition, the CSP should leverage technology to enforce various levels of encryption such as file encryption, full-disk encryption, endpoint protection, etc.

The CSP should utilize industry-standard encryption algorithms and strong encryption for data identified as sensitive.

Wherever possible, the CSP should also:

• a. Endpoints Disk Encryption: Implement full disk encryption for endpoint devices that store data identified as sensitive

• b. Endpoints Container Security: Utilize container technology to secure and encrypt sensitive data on mobile devices

UEM-09: Anti-Malware Detection and Prevention

Control Specification

Configure managed endpoints with anti-malware detection and prevention technology and services.

Shared Implementation Guidelines

[Applicable to all actors except CSP]

1. Deploy and maintain anti-malware or EDR on all endpoints (laptops, mobiles, virtual machines, virtual desktops, jump hosts, etc.), with real-time protection and behavior or ML-based detection, and keep engines and signatures current.

2. Continuously monitor agent health in UEM (installed, running, current, scans performed) and enforce access restrictions for non-compliant devices using Conditional Access or NAC, including auto-quarantine until remediated.

3. Standardize protection settings and scanning policy across parties: require on-access scanning and periodic scans on a risk-based cadence; use vendor guidance for full scans and run them when catch-up or incident conditions warrant.

4. Share threat intelligence and coordinate response across stakeholders so that new IoCs and detections propagate quickly and comparable protective actions are triggered everywhere.

5. Maintain malware response playbooks that define containment, isolation, eradication, and recovery steps, with roles and escalation, and test them periodically.

Implementation Guidelines for Cloud Service Providers (CSP)

1. Install and maintain enterprise-grade anti-malware or endpoint detection and response (EDR) software on all devices and servers under the CSP’s control. This includes administrative laptops, support desktops, and any bastion hosts that might be used to manage cloud infrastructure, ensuring they are continuously protected against viruses, trojans, ransomware, and other malicious code.

2. Configure the anti-malware solution to receive updates in real time or on a very frequent schedule. CSP devices should always have the latest virus definitions and heuristic algorithms given their critical role, outdated definitions on an admin system could miss a new threat that puts the entire cloud environment at risk.

3. Integrate endpoint anti-malware alerts with the CSP’s security operations monitoring. Any malware detection or quarantine event on a CSP endpoint should generate an alert in the security incident and event management (SIEM) system and be treated with high priority, since an infection on an admin device could be a stepping stone to broader compromise.

4. Perform periodic security sweeps and device health checks. Even with active anti-malware, the CSP should schedule regular full system scans on their endpoints (e.g., weekly or monthly) and also run external integrity checks (like using secondary malware scanners or cloud-based scanning of critical files) to double-check that nothing slipped past primary defenses. Document and review the results of these scans as part of continuous security improvement.

From CCM v4.1: Control Ownership Rationale. This is a “Shared (Independent)” control for both the CSP and CSC, since both should implement endpoint security on processes and technology, including anti-malware software to mitigate the risk of exploitation by malicious actors.

Implementation Guidelines. Applicable to all service models: Configurations should include installing and regularly updating anti-malware software, signatures and virus definitions (automatically) whenever updates are available to ensure protection against the latest threats (refer also to TVM-02).

The CSP should periodically review and scan installed software and system data content to identify and remove unauthorized code/software when possible. Procedures should be defined to respond to malicious code or unauthorized software identification.

Technical measures should be implemented to prohibit using or installing unauthorized software, including restrictions on obtaining data and software from external networks.

Also, wherever possible, organizations should:

• a. Endpoints Removable Media Management: Control use of removable media such as USB, CDs, DVDs, hard drives, FireWire devices, and external serial advanced technology attachment devices

• b. Endpoints Application Whitelisting: Implement application whitelisting technology to ensure that only authorized software executes and all unauthorized software including malware is blocked.

• c. BYOD Anti-malware: Ensure that all BYOD devices leverage anti-malware software

UEM-10: Software Firewall

Control Specification

Configure managed endpoints with properly configured software firewalls.

Shared Implementation Guidelines

[Applicable to all actors except CSP]

1. Require host-based firewalls to be active on all endpoints across MP, OSP, AP, and AIC, with a baseline rule set that blocks unauthorized inbound/outbound traffic. Use UEM policies to deploy a standardized configuration and ensure it cannot be disabled by end users.

2. Establish a common set of minimum firewall rules (e.g., allow only necessary traffic for approved applications, block all other services by default) that every stakeholder applies to their devices, providing consistent network protection regardless of device owner.

3. Utilize the UEM platform to monitor firewall status and configurations on managed endpoints; establish logging requirements and set up alerts or compliance checks that flag any device with its firewall turned off or with rules that deviate from the approved baseline, so all parties can take corrective action quickly.

4. Coordinate firewall exception handling among stakeholders. Any request to open additional ports or services on endpoints (for integration or special use cases) should be reviewed collectively and documented, ensuring that no organization unilaterally weakens endpoint firewall defenses without group awareness and agreement.

Implementation Guidelines for Cloud Service Providers (CSP)

1. Enable and configure host-based firewalls on all CSP systems. Every server and admin workstation should have its native firewall (Windows Firewall, iptables/UFW on Linux, etc.) turned on with a rule set that by default denies unnecessary inbound traffic and tightly restricts outbound traffic to only what’s needed for its role.

2. Define a standard firewall rule baseline for CSP devices. For example, administrative laptops might only allow inbound RDP/SSH from specific jump hosts, and perhaps block all inbound requests on other ports; while a support server might have no inbound open except from the internal network. Document these baselines and apply them uniformly through configuration management.

3. Use the UEM or a centralized security policy management system to distribute and enforce firewall settings. This ensures consistency and that any changes to firewall rules (perhaps in response to a new threat or a needed exception) are applied across all relevant devices quickly and tracked.

4. Regularly review and update firewall rules. Remove rules that are no longer needed and add new ones as services change. At least annually (or whenever network architecture updates occur), audit the firewall configurations on CSP devices to ensure they adhere to the principle of least privilege and log any deviations or justifications for exceptions.

From CCM 4.1: Control Ownership Rationale. This is a “Shared (Independent)” control for both the CSP and CSC, since they should each maintain properly configured firewalls on their respective endpoints. The endpoint firewalls should inspect traffic, apply rules, and perform behavioral monitoring.

Implementation Guidelines. Applicable to all service models: Configurations should include installing and regularly updating firewall software and firewall rules (automatically) on all endpoints. The CSP should periodically review and scan the firewall rules to ensure unapproved rules do not exist.

Implementation best practices should include (but not limited to):

• a. Endpoints Firewall Security:

  • i. Ensure all endpoints have the currently active baseline ruleset

  • ii. Ensure the changes to baseline rules are properly approved through a well-documented change management process

  • iii. Ensure new rules are properly approved through a well-documented change management process

  • iv. Check the web traffic, such as hypertext markup language (HTML), JavaScript, and hypertext transfer protocol (HTTP), for malicious code

• b. Note anomalies that exceed normal traffic patterns, and take appropriate action to address them

UEM-11: Data Loss Prevention

Control Specification

Configure managed endpoints with Data Loss Prevention (DLP) technologies and rules in accordance with a risk assessment.

Shared Implementation Guidelines

[Applicable to all actors except CSP]

1. Deploy endpoint DLP agents on all devices handling sensitive AI data across MP, OSP, AP, and AIC, enforcing consistent protection for model code, training data, PII, etc.

2. Align DLP policy and data classification among stakeholders, ensuring consistent enforcement (e.g. blocking key patterns, file types).

3. Monitor DLP agent status via UEM and share clear metrics (agent coverage %, incidents, response times) among parties to maintain visibility and encourage program improvement.

4. Conduct privacy impact assessments (PIAs / DPIAs) before enabling DLP for sensitive or regulated data to verify legal compliance, especially under GDPR or equivalent data protection regimes.

5. Tailor DLP controls based on user roles and data sensitivity, adjusting monitoring and blocking thresholds accordingly to uphold the principle of least privilege.

6. Educate users and administrators on DLP objectives, mechanisms, and reporting pathways to support compliance and reduce accidental exposures.

7. Maintain a joint incident response process for DLP alerts, prompt notification, investigation, and containment across stakeholders to quickly address potential data loss.

Implementation Guidelines for Cloud Service Providers (CSP)

1. Collaborate with all supply-chain parties to implement a unified Data Loss Prevention strategy for the AI service environment. As the CSP, provide baseline DLP capabilities or guidelines (covering network egress points and endpoints) that each stakeholder can adopt to prevent sensitive data (like model data, training datasets, or customer information processed by AI) from leaving authorized channels.

2. Enable DLP or similar content monitoring on CSP-managed endpoints (admin computers, etc.) focusing on cloud service data. For example, configure rules to detect when files with sensitive configurations or customer data are being copied from a secure zone to an external drive or uploaded to an external site, and block or alert on such actions.

3. At the cloud infrastructure level, offer tools that integrate with endpoint DLP – such as CASB (Cloud Access Security Broker) features or cloud storage DLP that can extend policies to remote virtual desktops or published applications used by MP/OSP/AP. Ensure these tools can be utilized to cover scenarios where data might otherwise bypass on-premise DLP (like direct cloud-to-cloud transfers).

4. Work with stakeholders to regularly update DLP policies based on emerging risks. For instance, if a new type of sensitive AI dataset is identified, update the definitions or patterns that the DLP should look for. Similarly, share threat intel with MP/OSP/AP about how attackers might try to exfiltrate data so everyone can tighten rules accordingly.

From CCM v4.1: Control Ownership Rationale. This is a “Shared (Independent)” control for both the CSP and CSC since they should each prevent data leakage by implementing an effective data leakage prevention (DLP) program that covers all endpoints and ensures that appropriate rules are defined and implemented, with monitoring, alerting, and response process in place.

Implementation Guidelines. Applicable to all service models: Implementation best practices for a DLP program include (but not limited to):

• a. Endpoints Data Classification: Formal data classification standard that classifies data based on sensitivity for business, customers, clients, partners and regulatory obligations (refer to DSP domain)

• b. Endpoints Data Inventory: structured and unstructured data inventories that are kept up to date

• c. Endpoints Data Protection: Discovering, monitoring, and protecting data with regulatory or compliance implications during transit and at rest across the network, storage, and endpoint systems

• d. Endpoints Data Monitoring: Monitoring for sensitive information (e.g., personal data, special keywords, and metadata to discover unauthorized attempts for disclosure across network boundaries, and block such transfers by alerting information security personnel. The organization should configure the DLP solution to enforce ACLs even when data is copied off a server

• e. Endpoints SOPs Definition: Defined Standard Operating Procedures (SOPs) to handle data leakage events

• f. Endpoints DLP Policy Violation Detection: Detection of DLP policy violations and take remediation actions based on the SOPs. Furthermore, any anomalies that exceed normal traffic patterns should be noted, and appropriate action should be taken to address them

UEM-12: Remote Locate

Control Specification

Enable remote geo-location capabilities for all managed mobile endpoints, according to all applicable laws and regulations.

Shared Implementation Guidelines

[Applicable to all actors except CSP]

1. Enable geo-location tracking via UEM for all mobile endpoints (laptops, tablets, smartphones) used by MP, OSP, AP, and AIC in the AI supply chain, ensuring that each organization’s device can report its last known location if lost or stolen.

2. Develop a shared procedure for utilizing remote locate during security incidents, for example, clearly define who within each stakeholder’s team is authorized to trigger a “find device” command and under what circumstances, and agree on how location information will be shared or handed off if a device from one party is lost in another’s facility or jurisdiction.

3. Protect location data by restricting access to authorized security personnel across the organizations; all stakeholders should mutually ensure that any collected device location info is used solely for recovery/security purposes and handled in compliance with privacy expectations.

4. Periodically test the remote locate function on a sample of endpoints from each stakeholder (e.g., as part of an annual drill) to confirm that devices report accurate location data and that all teams know how to initiate and respond to a device location query in practice.

Implementation Guidelines for Cloud Service Providers (CSP)

1. Enable geo-location tracking on all mobile devices and laptops that the CSP provides to its personnel for managing the cloud environment. This way, if a device with access to cloud admin interfaces is lost or stolen, the CSP can quickly determine its last known location and assist in recovery or further security actions.

2. Use the MDM/UEM system to perform location checks. For example, ensure that whenever a CSP-managed device comes online, it reports its general location (GPS or network-based) to the central console. Set policies such as triggering an automatic location fetch when a device is reported as missing or when it hasn’t checked in for an unusual amount of time.

3. Protect location data as sensitive information and limit access to it. Only allow authorized security or IT personnel to query a device’s location, and log all such queries for audit purposes. This ensures that geo-location is used strictly for legitimate security reasons (like device recovery or investigating a potential theft) and not misused for employee surveillance.

4. Include geo-location in incident response drills. Simulate scenarios like “an admin tablet was forgotten in a taxi” and practice using the system to locate it. Ensure the team knows how to remotely make the device display a message or alarm sound (features often available with device location services) to facilitate retrieval, and how to involve law enforcement with the location info if needed.

From CCM v4.1: Control Ownership Rationale. This is a “Shared (Independent)” control for both the CSP and CSC since both the CSP and CSC should be able to remotely manage the endpoint device if it is lost or stolen.

Implementation Guidelines. Applicable to all service models: Irrespective of cloud service delivery model, the CSP and CSC are both responsible for ensuring that endpoint devices, if lost or stolen, are remotely tracked.

Implementation best practices for remote geo-location include (but not limited to):

• a. Endpoints Remote Locate:

  • i. Inventory of the endpoint devices, whether provisioned or BYOD

  • ii. Geolocational tracking configured and GPS or network-based location services utilized to identify the device’s whereabouts

  • iii. if endpoint goes off the tracking, the response team should be alerted

The CSP should regularly test the remote wipe functionality on various endpoint device types supported by BYOD program and preserve the testing evidence.

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.

Shared Implementation Guidelines

[Applicable to all actors except CSP]

1. Ensure all managed endpoints across the supply chain (MP, OSP, AP, AIC) are configured for remote wipe via the UEM solution, and verify this capability on each device that stores sensitive or proprietary AI data, so any lost or compromised endpoint can be sanitized immediately.

2. Define a unified set of criteria and an approval workflow for triggering a remote wipe event - for instance, agreeing that a device reported stolen or showing signs of active compromise warrants an immediate wipe - so that every stakeholder follows the same decision thresholds and no time is lost deliberating in a crisis.

3. Establish cross-notification protocols for remote wipe actions: if one organization initiates a remote wipe on an endpoint (e.g., a model provider wiping a laptop that had AI customer data), they must promptly inform all other relevant parties, enabling those parties to revoke credentials or monitor for related suspicious activity stemming from that device.

4. Regularly rehearse and validate remote wipe processes on non-production devices for each stakeholder. Share the results (such as wipe success rate and time to complete) in joint security meetings to build confidence that all parties can effectively destroy data on a compromised device and to refine procedures as needed.

Implementation Guidelines for Cloud Service Providers (CSP)

1. Implement remote wipe capabilities for any device that has administrative access to the cloud environment or stores cloud service data, as part of the CSP’s incident response toolkit. If a laptop used by a cloud engineer is lost or suspected compromised, the CSP should be able to send a command that either completely erases the device or at least wipes all corporate data on it (for devices with a container/work profile setup).

2. Test the remote wipe function on a regular basis. For example, maintain a non-production “test” device or a virtual device enrolled in the system, and simulate a wipe to ensure the command is reliably executed and fully clears data. Update procedures if you find any gaps (like wipe not occurring if device is offline; in such cases, ensure it triggers as soon as the device comes online).

3. When a wipe is triggered, also revoke the device’s credentials and access tokens immediately. The remote wipe will handle data at rest on the device, but if an attacker has the device powered and connected, they might use saved VPN tokens or sessions. Therefore, in tandem, disable that device’s accounts in IAM, reset any associated API keys, and invalidate active sessions to cloud consoles.

4. Keep an audit trail of all remote wipe actions initiated. Given the destructive and potentially privacy-impacting nature of a wipe, log who authorized it, when it was sent, which device was targeted, and confirmation of completion. This not only helps for accountability but also for post-incident analysis to ensure the wipe achieved the desired security outcome (and no data lingered).

From CCM 4.1: Control Ownership Rationale. This is a “Shared (Independent)” control for both the CSP and CSC, since they each need to remotely manage a mobile device if it is lost or stolen.

Implementation Guidelines. Applicable to all service models: Irrespective of cloud service delivery model, the CSP and CSC are both responsible for ensuring that endpoint devices, whether provisioned or BYOD, if lost or stolen can be remotely tracked, have corporate data deleted, or be wiped clean.

Implementation best practices for remote data wipe include (but not limited to):

• a. Endpoints Remote Wipe:

  • i. Inventory of the endpoint devices, whether provisioned or BYOD

  • ii. Geolocational tracking configured and GPS or network-based location services utilized to identify the device’s whereabouts

  • iii. if endpoint goes off the tracking, the response team can be alerted

  • iv. Remote wipe feature/ability turned on, and unable to be turned off by the user of the device

• b. Secure wipe processes should be implemented to ensure thorough data removal without compromising device functionality vi. Remote wipe capabilities should be restricted to authorized personnel to prevent unauthorized data deletion

The CSP should regularly test the remote wipe functionality on various endpoint device types supported by BYOD program and preserve the testing evidence.

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.

Shared Implementation Guidelines

[Applicable to all actors except CSP]

1. Require any third-party or contractor devices that access AI systems to meet the same endpoint security baseline as the primary stakeholders’ devices. All core participants should collectively mandate that external user endpoints have up-to-date patches, active anti-malware, host firewall enabled, and full disk encryption before they are granted access to project resources.

2. Enforce third-party endpoint compliance through technical controls: implement pre-access checks (e.g., via a zero-trust network access gateway or NAC) to validate that a vendor or partner device is managed and compliant with security policies. Whenever possible, have external users either use company-managed devices or enroll their equipment in a segregated UEM instance to continuously monitor their posture.

3. Include stringent endpoint security requirements in contracts or service agreements with third parties. For example, stipulate that consultants must adhere to your UEM policies, allow security audits of their devices if necessary, and report any device breach. All stakeholders should review these provisions together to ensure consistency and collectively follow up on any non-compliance.

4. Maintain shared visibility into third-party access: jointly keep an inventory of approved third-party personnel and their devices, and review this list in cross-organization security meetings. This ensures every stakeholder knows which external endpoints have access to their environments, enabling coordinated oversight and quick revocation of access for any device that falls below the agreed security standards.

Implementation Guidelines for Cloud Service Providers (CSP)

1. Establish strict security requirements for third-party entities (vendors, contractors, managed service providers) that access the CSP’s systems or data. Contractually require that any endpoint used by third-party personnel to connect to the CSP environment meets your security standards: it must have up-to-date patches, encryption, anti-malware, firewall, and not be rooted/jailbroken (for mobile). These requirements should be clearly enumerated in contracts or Master Service Agreements.

2. Where feasible, provide a secured access environment for third parties instead of direct access from their devices. For example, offer a hardened virtual desktop or a citadel jump-server that third-party support engineers must use, rather than logging in from their own laptop. This way, the CSP controls the environment (and its endpoint security) even when third parties are doing work.

3. Implement technical controls to enforce third-party device compliance. For instance, use network access control or client certificate checks that validate a device’s identity and health posture before allowing it to connect to internal admin networks or cloud management interfaces. If a third-party’s device doesn’t pass (say it’s not recognized or doesn’t have the corporate certificate installed), it gets blocked or put in a very limited sandbox.

4. Monitor and audit third-party activities aggressively. Because third-party endpoints are an extension of your security perimeter, keep detailed logs of their access, when they logged in, what they did, what data they accessed. Periodically review these logs for any anomalies. Additionally, conduct periodic security reviews with the third-party: request evidence of their endpoint security measures (like audit reports or screenshots of their AV/patch status) to ensure they uphold their end of the security agreement.

From CCM v4.1: Control Ownership Rationale. This is a “Shared (Independent)” control for both the CSP and CSC since they each should perform due diligence before granting third-party access to the organizational data or establishing connectivity (and periodically thereafter, commensurate with the risk level of the third-party relationship).

Implementation Guidelines. Applicable to all service models: Irrespective of cloud service delivery model, the CSP and CSC are both responsible for ensuring proper security of third-party endpoints that have access to organizational assets.

Implementation best practices include (but not limited to):

• a. Third-party Endpoint Access Management: Cloud Identity and Access Management (IAM) tools should be leveraged to provision and manage access for third-party endpoints

• b. Third-party Endpoint Isolation: Network segmentation practices should be implemented to isolate third-party endpoint traffic from sensitive internal resources

• c. Third-party Endpoint Security Tools: The installation and configuration of endpoint security software (antivirus, endpoint detection and response) should be enforced on all authorized third-party devices

• d. Third-party Endpoint Secure Channels: Ensure secure communication channels (e.g., VPN) for all data transfer between third-party endpoints and organizational assets

• e. Third-party Endpoint Agreements: Written agreements (contracts) should be established and maintained between CSP and third-parties, including an acknowledgment that the third party is responsible for the security of the data they store, process, or transmit on the CSP’s behalf. Agreements should include requirements to address the information security risks associated with third-party endpoint access, including guidelines for authentication, authorization, data encryption, and device management. These requirements are subsequently applicable to relevant nth-party subcontractors throughout the supply chain

• f. Third-party Agreements Provisions: formal contracts that specify, at a minimum:

  • i. A joint risk assessment with the CSC to identify potential vulnerabilities associated with third-party endpoints accessing organizational cloud assets

  • ii. The covered information’s confidential nature and value

  • iii. The types of devices and operating systems supported for secure access

  • iv. The security measures to be implemented and/or complied with as required by applicable federal laws, executive orders, directives, policies, regulations, standards, and guidance, and third-party endpoints access limitations

• g. Responsibilities for patching and updating third-party endpoint software vi. The service levels to be achieved in the services provided vii. The format and frequency of reporting to the CSP’s information security management forum viii. The arrangement for representation of the third party in appropriate organizational meetings and working groups ix. The arrangements for Third-party security assessments to ensure compliance with contractual agreements and regulatory requirements (refer to STA)

• h. The penalties exacted if any of the preceding specifications fail

• i. Third-party Endpoints Responsible: The Third Party should designate a specific individual or role (e.g., within contract or supply chain function) responsible for managing access privileges granted to its personnel who require access to the CSP systems and data (e.g., personnel access changes, access privileges, credentials management by third-party personnel)

• j. Continuous Monitoring and Evaluation: Logs related to third-party endpoint access should be continuously monitored for suspicious activity