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 AI Customers (AIC)

Policy Scope Audit and assurance policies covering the consumption and use of AI services, including validation that AI providers’ attestations meet organizational control objectives and compliance requirements. Policies should address the evaluation of the entire AI supply chain, including subservice providers that AI providers rely upon.

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

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 AI Customers (AIC)

[AI Customers]

1. Review independent assessments conducted by the provider to verify alignment with organizational requirements. (e.g. Obtain the provider’s audit report or certification, review it for any gaps relevant to your use case, and raise concerns if needed).

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 AI Customers (AIC)

[AI Customer (AIC)] Implementation best practices for this actor include (but are not limited to):

1. Verify provider attestations, assess internal validation controls, and evaluate AI implementation against business risk tolerance.

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 AI Customers (AIC)

[AI Customer (AIC)] Implementation best practices for this actor include (but are not limited to):

The AIC’s responsibilities focus primarily on ensuring compliant usage of AI systems rather than development compliance.

1. Review provider compliance documentation to verify alignment with organizational requirements.

2. Validate that AI system usage complies with internal policies, ethical guidelines, and applicable regulations.

3. Maintain documentation of compliance with data protection laws when using AI for processing sensitive information.

4. Establish monitoring protocols to validate AI outputs for quality, fairness, and compliance.

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 AI Customers (AIC)

[AI Customers (AIC)]

1. Review provider audit reports to assess compliance with your requirements. Request evidence of AI-specific controls such as model safety measures and data handling practices. Document your organization’s AI service usage configurations to support internal compliance reviews.

2. Establish clear documentation of audit responsibilities across the AI supply chain. Define boundaries for security control implementation and validation between providers and customers. Share relevant findings that may impact other parties while respecting confidentiality requirements.

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 AI Customers (AIC)

[AI Customers (AIC)]

1. Develop processes to track remediation of critical findings in third-party AI service provider audit reports that could impact your organization.

2. Establish verification procedures to confirm that provider remediation actions adequately address risks to your specific AI implementations and use cases.

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 AI Customers (AIC)

1. Implement application and interface security policies covering the evaluation and use of AI-powered applications and services provided by CSPs, MPs, OSPs, or APs.

2. Policies should focus on validating that provider security controls meet organizational risk tolerances, including secure consumption of APIs and interfaces.

3. Include procedures for assessing the security of the AI supply chain, such as third-party dependencies or subservice providers, and ensuring compliance with internal security standards.

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 AI Customers (AIC)

1. Establish a process for evaluating AI solution providers against your organization’s security requirements and industry standards.

2. Evaluation baselines: define a baseline for security assessment and due diligence, including criteria for evaluating the provider’s security controls, policies, and certifications to ensure consistent assessment of the security posture of AI providers.

3. Due diligence baselines: develop a baseline for AI governance and risk management, including processes for monitoring AI use, detecting deviations from expected behavior, and responding to incidents to ensure a thorough review of the provider’s security controls and practices.

4. AI governance and risk management baselines: the AIC should document these baselines in its organization’s AI governance framework and maintain them as part of its overall security program to maintain ongoing oversight of AI use.

5. Regular assessments against the baselines: regularly assess AI solutions against these baselines and work with providers to address any gaps or non-conformances.

6. Establish evaluation, due diligence, and AI governance/risk management baselines.

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

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 AI Customers (AIC)

1. Organization-wide metrics: define organization-wide AI security metrics that align with business objectives, risk management strategies, and compliance obligations to provide a holistic view of AI security aligned with business objectives.

2. Aggregating metrics from all AI providers roles: collect and aggregate security metrics from all relevant AI providers roles (MP, OSP, AP) to gain a comprehensive view of the AI security posture to ensure a comprehensive understanding of the AI security landscape.

3. Centralized dashboards and reporting systems: establish a centralized dashboard or reporting system to monitor and visualize key security metrics for effective monitoring and communication.

4. Regular reviews with stakeholders: conduct regular reviews of AI security metrics with stakeholders to identify trends, gaps, and improvement opportunities to ensure collaborative problem-solving and continuous improvement.

5. Insights from metrics: use insights from security metrics to inform strategic decision-making and prioritize security investments.

6. Continuously Review and Update: Regularly review and update security metrics, monitoring systems, and reporting processes to adapt to evolving threats and technologies.

7. Define organization-wide AI security metrics aligned with business objectives and risk management. Aggregate metrics from all providers.

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

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 AI Customers (AIC)

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

1. Establish organizational security requirements and standards that align with business objectives and compliance obligations.

2. Communicate security requirements to all roles (PI, MP, OSP, AP) and ensure they are incorporated into their respective secure SDLC processes.

3. Regular assessments: Conduct regular assessments to verify that secure SDLC processes are being followed effectively by AI providers, either by third-party audit or contractual obligations.

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 AI Customers (AIC)

1. Define and communicate clear security testing requirements and acceptance criteria to all roles (MP, OSP, AP) involved in the AI supply chain to ensures all roles understand and align with organizational expectations.

2. Require evidence of automated security testing results and compliance with acceptance criteria from each role before approving the use of AI systems or components to ensures only secure AI systems and components are approved for use.

3. Conduct independent security assessments and penetration testing of AI systems and applications to validate the effectiveness of the automated testing practices implemented by all relevant roles.

4. Establish a process for monitoring and auditing the automated security testing practices of MP, OSP, and AP to ensure ongoing compliance with organizational standards and identify improvement opportunities.

5. Provide guidance and support to help other roles continuously improve their automated security testing practices and adapt to emerging threats and regulatory requirements to maintain a strong security posture.

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

5. Eliminate Standing privileges by leveraging Zero Standing Privileges (ZSP) to reduce security vulnerabilities.

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 AI Customers (AIC)

Policy Scope: Secure deployment evaluation strategies for consuming AI-powered applications and services provided by CSPs, MPs, OSPs, or APs. Policies should focus on validating provider deployment processes, ensuring secure integration with internal systems, and verifying compliance with organizational security standards. Include procedures for assessing the security of third-party deployment pipelines and dependencies, and automate compliance checks where possible to ensure secure consumption.

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 AI Customers (AIC)

Policy Scope: Remediation evaluation processes for vulnerabilities in AI-powered applications and services consumed from CSPs, MPs, OSPs, or APs. Policies should focus on validating provider remediation efforts, ensuring secure integration with internal systems, and verifying compliance with organizational security standards. Include procedures for assessing the security of third-party remediation processes and dependencies, and automate compliance checks where possible to ensure secure consumption.

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 AI Customers (AIC)

API security policies cover the evaluation and use of APIs in AI-powered applications from CSPs, MPs, OSPs, or APs.

1. Focus on validating provider API security controls (e.g., key management, authorization) against organizational standards (one example could be AI STAR, and so on).

2. Include procedures for assessing API supply chain risks (e.g., third-party API dependencies) and ensuring secure API consumption practices.

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 AI Customers (AIC)

Policy Scope: Input validation evaluation policies covering the consumption of AI-powered applications and services provided by CSPs, MPs, OSPs, or APs. Policies should focus on validating provider input validation mechanisms, ensuring secure integration with internal systems, and verifying compliance with organizational security and regulatory standards. Include procedures for assessing the security of third-party input validation processes and dependencies to mitigate risks from adversarial or faulty inputs.

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 AI Customers (AIC)

Policy Scope: Output validation evaluation policies covering the consumption of AI-powered applications and services provided by CSPs, MPs, OSPs, or APs. Policies should focus on validating provider output validation mechanisms, ensuring secure handling of received outputs, and verifying compliance with organizational security and regulatory standards. Include procedures for assessing the security of third-party output validation processes and dependencies to mitigate risks from adversarial or faulty outputs.

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 AI Customers (AIC)

[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 AI Customers (AIC)

Policy Scope:

Model development policies cover evaluation of provider-supplied AI models and applications within organizational SDLC processes. Focus on validating that CSPs, MPs, OSPs, or APs follow secure development practices (e.g., version control, code reviews) through audits or documentation requests. Include procedures for assessing risks from poorly developed models (e.g., lack of code review) before integration.

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 AI Customers (AIC)

Policy Scope:

Sandboxing policies cover evaluation of sandboxing techniques in tools and plugins within AI-powered applications from CSPs, MPs, OSPs, or APs. Focus on validating that provider sandboxing prevents unintended interactions and lateral movement through audits or documentation requests. Include procedures for assessing risks from inadequate isolation (e.g., data leakage) before adoption.

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 AI Customers (AIC)

Policy Scope:

Cache security policies cover evaluation of cache systems in LLM-powered applications from CSPs, MPs, OSPs, or APs. Focus on validating provider cache security measures (e.g., encryption, access controls, data retention mitigation) through audits or documentation requests. Include procedures for assessing risks from inadequate cache protection (e.g., data leaks, poisoning) before adoption.

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 AI Customers (AIC)

Policy Scope:

Input distinction policies cover evaluation of input handling mechanisms in AI-powered applications from CSPs, MPs, OSPs, or APs. Focus on validating that provider mechanisms (e.g., border strings, templates) clearly distinguish user/system/data inputs through audits or documentation requests. Include procedures for assessing risks from ambiguous instruction handling (e.g., prompt injection) before adoption.

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 AI Customers (AIC)

[Policy Scope] The AI Customer must embed risk preparedness strategies within their organizations use of AI technologies. Some of the actions include:

• Outline internal response actions in case AI-driven processes become impaired or inconsistent.

• Maintain reference materials on AI dependencies across business units and workflows.

• Validate internal preparedness through executive review and operational risk assessments.

• Align vendor expectations through clear communication and contract-level assurances.

• Incorporate alternative paths or manual controls to support essential operations if AI services are interrupted or become unavailable.

• Engage in periodic drills to identify potential weaknesses or bottlenecks in AI reliance.

• Revisit and fine-tune protocols annually or when introducing new AI capabilities or suppliers.

• Tailoring resilience measures to the organization’s dependency on AI outputs and business functions.

• Recording internal risk strategies and acquiring executive acknowledgment.

• Ensuring team-wide understanding of responsibilities in case of AI service interruption.

• Deploying contingency procedures for essential operations reliant on AI insights.

• Regularly assessing preparedness effectiveness using simulated disruptions.

• Adjusting continuity strategies upon experiencing process re-engineering, business model changes, or annually at a minimum.

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 AI Customers (AIC)

Policy Scope:

1. Assess operational impact of various AI service disruption scenarios and business process dependencies on these systems.

2. Determine acceptable service level degradation and customer experience implications during alternative operations.

3. Create alternative workflow procedures for critical business functions and well formed triggers for invoking contingency operations.

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

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 AI Customers (AIC)

[Policy Scope] -Maintain an AI Dependency Register for all critical operations and develop alternative procedures for critical AI-dependent processes. -Define acceptable service interruption windows and map them to business outcomes. -Establish communication protocols with service providers during outages. -Train personnel on manual workarounds for AI-enabled processes. -Participate in joint tabletop exercises with providers to test response effectiveness.

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

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 AI Customers (AIC)

[Policy Scope]

• Document all AI-dependent business functions with criticality ratings.

• Identify maximum acceptable interruption periods for each processes.

• Establish performance thresholds for manual vs. automated operations.

• Establish clear trigger definition for activating contingency operations.

• Conduct service interruption simulation and stakeholder communication during the exercise.

[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

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 AI Customers (AIC)

[Policy Scope]

• Document alternative procedures for AI-augmented functions.

• Maintain decision frameworks for operations during automation limitations.

• Record maximum tolerable downtime for each intelligence-dependent process and maintain resource requirements for alternative operational modes.

• Preserve stakeholder communication templates for service disruptions.

• Develop verification criteria for safe return to normal operations.

• Document progressive transition plans for returning to automated operations.

• Document verification methods confirming safe system reliance.

• Maintain reconciliation procedures for activities conducted during disruptions.

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

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 AI Customers (AIC)

[Policy Scope]

1. Manual Procedure Activation: Schedule regular practice of manual alternatives during controlled periods. Validate alternative workflows without machine assistance.

2. Decision Quality Assessment: Create realistic business scenarios requiring decisions without AI input and compare outcomes using backup processes.

3. Stakeholder Communication Drill: Practice explaining disruptions to affected parties/stakeholders.

4. Progressive Resumption: Simulate gradual restoration of capabilities to test transition management and phased return to normal operations.

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

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 AI Customers (AIC)

[Policy Scope]

1. Key Stakeholder Matrix

   • Internal Teams: Operations staff, business leaders, and technical liaisons.

   • Organization Partners: Departments dependent on intelligence capabilities.

   • External Stakeholders: Clients, regulators, and business partners.

   • Service Providers: Application vendors and technology support teams.

2. Communication Framework :

   • Develop business impact assessment guides with communication triggers.

   • Create stakeholder maps with appropriate information needs by group.

   • Establish escalation criteria based on operational significance.

   • Configure business continuity notification system with role-based distribution.

   • Establish leadership briefing protocols for significant disruptions.

   • Create collaborative workspaces for cross-functional response coordination.

   • Design templates translating technical issues into business impact terms.

   • Develop alternative procedure distribution mechanisms.

3.Testing & Maintenance :

• Conduct periodic business scenario exercises testing communication effectiveness.

• Review message clarity through recipient comprehension assessment.

• Validate contact information through regular verification processes.

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

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 AI Customers (AIC)

[Policy Scope]

1. Critical Assets Protection Strategy:

   • Implement comprehensive preservation of business process configurations and decision rules.

   • Establish secure repositories for custom implementation details and integration settings.

   • Create versioned archives of historical transactions and intelligence interactions.

   • Maintain secure backups of organization-specific knowledge and training materials.

2. Configuration Preservation:

   • Deploy automated daily snapshots of customized business rules and workflows.

   • Implement version control for decision thresholds and process configurations.

   • Create secure storage for organization-specific data with appropriate classification.

3. Operational Data Safeguards:

   • Establish transaction logging with business context preservation.

   • Create secured archives of AI-assisted decisions with supporting rationales.

   • Implement retention policies aligned with business and compliance requirements.

4. Recovery Readiness:

   • Develop business function restoration procedures with verification steps.

   • Create simulation environments for backup effectiveness validation.

   • Establish prioritized recovery sequences based on operational importance.

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

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 AI Customers (AIC)

[Policy Scope]

1. Response Structure:

   • Establish response team including business process owners and technical liaisons.

   • Designate operational continuity leads for each critical function.

   • Create clear decision authority for activating manual alternatives.

   • Develop stakeholder communication responsibility assignments.

2. Incident Classification:

   • Implement business impact categories based on operational significance.

   • Define escalation levels aligned with process criticality.

   • Create assessment procedures evaluating intelligence service dependencies.

   • Establish criteria for activating alternative operational procedures.

3. Response Phase:

   • Deploy business process impact analysis identifying affected functions.

   • Implement dependency evaluation determining recovery requirements.

   • Implement resource reallocation supporting alternative operations.

   • Deploy documented manual procedures,if any, for critical functions.

   • Activate monitoring for decision quality during limited automation.

   • Execute stakeholder notification using predetermined templates

4. Post-Incident Activities:

   • Conduct operational effectiveness analysis during disruption.

   • Implement process resilience improvements addressing vulnerabilities.

   • Update alternative procedure documentation based on practical experience.

   • Document effective decision approaches during automation limitations.

   • Document communication method effectiveness and if improvement are needed.

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

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 AI Customers (AIC)

[Policy Scope]

1. Create scenarios targeting business process disruption and intelligence service failures.

2. Develop simulation approaches for operating with limited automation support.

3. Establish exercise progression exploring increasingly complex operational challenges.

4. Design specialized drills testing alternative procedures and decision frameworks.

5. Organize full-scale simulations involving multiple business departments.

6. Conduct surprise exercises testing readiness for unexpected service loss.

7. Implement cross-functional activities validating coordination during complex scenarios.

8. Execute verification drills confirming business continuity during extended disruptions.

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

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 AI Customers (AIC)

[Policy Scope]

1. Identify business systems with critical intelligence dependencies.

2. Deploy redundant connection points to intelligence services.

3. Implement alternative access methods for critical capabilities.

4. Evaluate integration points requiring redundant connectivity.

5. Create simplified frameworks supporting manual processing.

6. Assess decision support tools needing alternative data sources.

7. Determine automated workflows requiring manual fallback options.

8. Establish offline reference materials for guideline-based decisions.

9. Establish backup communication channels for coordination during 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.

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 AI Customers (AIC)

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

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 AI Customers (AIC)

1. Define expectations for testing and quality assurance in contracts or SLAs with vendors making changes to AI systems.

2. Maintain internal validation procedures for vendor-delivered changes, particularly in high-risk or compliance-sensitive environments.

3. Require visibility into change test results and documentation before authorizing deployments to production environments.

4. Collaborate with providers to ensure that all changes undergo appropriate testing and meet jointly defined quality benchmarks.

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

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 AI Customers (AIC)

1. Require change control submissions from vendors to include risk analysis and fallback procedures.

2. Maintain a risk acceptance or approval log for significant changes to AI-driven processes or configurations.

3. Assign internal owners to validate post-deployment performance and trigger escalation if needed.

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

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 AI Customers (AIC)

1. Review and approve baseline configurations from service providers to ensure they align with internal security, compliance, and operational standards.

2. Maintain documentation of accepted configurations for hosted models, applications, and orchestrated environments.

3. Require vendors to disclose any proposed deviation from baselines before deployment.

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

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 AI Customers (AIC)

1. Review and approve high-impact changes to hosted configurations (e.g., tuning inference thresholds, changing model versions).

2. Maintain documentation of accepted changes and expected outcomes from providers.

3. Monitor post-change performance and trigger escalation if SLAs or model behavior deviate unexpectedly.

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

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 AI Customers (AIC)

1. Maintain internal records of accepted model versions, expected input/output schemas, and data processing logic as part of vendor oversight.

2. Regularly validate that vendor-hosted environments are consistent with agreed-upon baselines.

3. Require providers to notify the customer of any deviations, especially in regulated or high-impact contexts.

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

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 AI Customers (AIC)

1. Maintain accepted vendor performance / fairness thresholds; automate re-evaluation of third-party models when drift or anomaly alerts occur.

2. Keep an internal register of deviation incidents and use findings to update risk assessments and contract SLAs.

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

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 AI Customers (AIC)

1. Maintain a vendor exception register to track provider-initiated emergency changes that affect contractual SLAs, data handling or compliance posture.

2. Validate closure evidence from providers and update internal risk registers accordingly.

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

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 AI Customers (AIC)

1. Request providers include rollback plans in change documentation, along with conditions under which rollbacks are initiated.

2. Maintain internal procedures to validate rollback effectiveness, particularly for models affecting regulated or mission-critical domains.

3. Track and review rollback incidents to identify recurring change-related risks.

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

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 AI Customers (AIC)

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.

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 AI Customers (AIC)

Role Specific

1. Assign internal owners for encryption responsibilities across AI-related data usage, including user inputs, API credentials, and inference outputs stored in enterprise systems.

2. Embed encryption roles into vendor management workflows by mapping external service responsibilities and defining internal oversight roles for cryptographic compliance.

3. Review and update encryption responsibilities as part of AI system risk assessments, particularly when adding new AI integrations, adjusting business logic, or onboarding new users.

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

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 AI Customers (AIC)

Role Specific

1. Incorporate encryption requirements into third-party AI service evaluations, confirming that vendors support in-transit and at-rest encryption for prompts, completions, and log data.

2. Configure enterprise integration platforms and gateways to enforce encryption policies during API calls to external AI models, including verification of TLS version and certificate validity.

3. Monitor internal AI usage logs and audit trails to detect unencrypted data flows involving sensitive AI-generated or user-provided content, initiating remediation where policy violations are found.

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

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 AI Customers (AIC)

Role Specific

1. Embed encryption algorithm validation into onboarding and vendor review processes for AI services, confirming approved algorithms are used for in-transit and at-rest protection of prompts, completions, and logs.

2. Configure internal gateways, proxies, or integration middleware to enforce algorithm-specific controls (e.g., TLS version pinning) for all communications with third-party AI providers.

3. Conduct periodic internal reviews of AI data handling workflows to ensure approved cryptographic standards are applied consistently, including within stored model outputs and long-term log retention systems.

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

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 AI Customers (AIC)

Role Specific

1. Maintain a centralized encryption change log documenting updates to algorithms or key management settings applied to AI data workflows, including timestamps, rationale, and affected systems.

2. Establish coordination procedures with third-party AI vendors to review and confirm the impact of cryptographic updates on API integrations, data flow protections, and service interoperability.

3. Perform internal validation of all approved encryption changes by simulating AI data exchange scenarios and verifying the secure handling of prompts, completions, and associated logs.

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

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 AI Customers (AIC)

Role Specific

1. Establish a structured intake form for proposed cryptographic changes that requires justification based on security improvement, compliance alignment, and cost efficiency.

2. Coordinate with third-party AI providers to assess the downstream implications of encryption changes, including compatibility with external APIs and secure data exchanges.

3. Monitor the post-change performance of AI systems and conduct stakeholder feedback reviews to verify that the benefits of implemented cryptographic updates were realized.

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

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 AI Customers (AIC)

Role Specific

1. Maintain a centralized AI encryption risk register documenting threats to AI data such as prompt leakage, model output exposure, and insecure key usage, along with corresponding mitigation actions.

2. Conduct collaborative risk reviews with third-party AI vendors to assess and treat shared encryption risks, particularly across API data flows and integrated logging pipelines.

3. Embed real-time monitoring rules into AI workflows to detect anomalies related to encrypted data handling, including misrouted prompts or logs stored without proper encryption.

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

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 AI Customers (AIC)

Role Specific

1. Configure CSP key management settings to enforce organizational control over key creation, access, and revocation policies across AI data workflows.

2. Establish tiered access controls and logging around AIC-managed keys to ensure only authorized systems and users can perform encryption operations in the CSP environment.

3. Conduct periodic reviews of key usage activity and retention policies to ensure key lifecycle practices support the organization’s data protection, compliance, and AI privacy goals.

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

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 AI Customers (AIC)

Role Specific

1. Implement logging and audit trail requirements across all AI-related systems to track encryption events, key usage, and access to sensitive AI data such as prompts and completions.

2. Perform periodic audit reviews of CSP-integrated key management systems to ensure key access controls and logging configurations align with AIC ownership expectations.

3. Use anomaly detection tools to monitor for deviations from expected cryptographic behavior, including unauthorized key access or unexpected data flows involving encrypted AI-related content.

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

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 AI Customers (AIC)

Role Specific

1. Configure cloud and on-prem environments to enforce the use of approved cryptographic libraries and secure random number generators when generating AIC-managed keys.

2. Establish validation procedures that verify the algorithm strength and entropy sources used during key creation in AI-integrated systems and storage platforms.

3. Perform regular audits of key generation logs and configuration baselines to ensure alignment with defined standards across all systems responsible for AI-related data protection.

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

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 AI Customers (AIC)

Role Specific

1. Configure key management policies to assign unique AIC-held keys for distinct AI data types, such as prompts, completions, logs, and API secrets, with no overlapping usage.

2. Apply tagging and key-labeling conventions within cloud KMS or local key vaults to enforce key purpose separation and facilitate audit and access control mapping.

3. Periodically review AI data encryption workflows to validate that key usage aligns with documented purposes and that cross-context key application is prevented across integrated 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.

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 AI Customers (AIC)

Role Specific

1. Configure automated key rotation policies for AIC-controlled keys used in securing AI prompts, completions, and logs, aligning cryptoperiods with data classification levels and service usage frequency.

2. Maintain rotation schedules and renewal workflows for keys stored in CSP KMS or local vaults, ensuring that AI systems consistently consume current keys without service disruption.

3. Review rotation logs and re-encryption outcomes to verify that expired keys are decommissioned properly and no residual access exists to data encrypted under outdated keys.

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

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 AI Customers (AIC)

Role Specific

1. Configure CSP-integrated key vaults to support on-demand revocation of AIC-managed keys tied to AI prompts, completions, logs, and tokens, with alerts triggered by access changes or anomaly detection.

2. Implement revocation workflows that automatically terminate access to encrypted AI data when a key is decommissioned, ensuring dependent services and applications are updated or rekeyed.

3. Maintain audit trails documenting key revocation events, including justification, affected systems, and validation of secure removal across all AI environments.

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

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 AI Customers (AIC)

Role Specific

1. Configure automated routines to destroy locally stored AIC-managed keys used for securing AI prompts, completions, or logs when services are decommissioned or use cases expire.

2. Revoke HSM-resident keys associated with AI platform integrations when access to encrypted data is no longer required or after third-party vendor separation.

3. Maintain auditable key destruction records that map each revocation or removal action to a defined data retention policy, legal basis, or system decommissioning trigger.

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

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 AI Customers (AIC)

Role Specific

1. Configure external key vaults and AI service integrations to enforce a pre-activation state for newly generated AIC-managed keys, including prompt and completion encryption keys.

2. Define and enforce activation workflows that require dual authorization, technical and compliance, before any AI-related key is marked as active and available for operational use.

3. Maintain detailed activation logs to track who authorized each key, what data type it protects, and the compliance context supporting its activation.

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

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 AI Customers (AIC)

Role Specific

1. Implement pre-defined triggers for key suspension in AI-related services, such as AI prompt logging or completion encryption, based on threat detection or unauthorized access.

2. Integrate automatic key suspension into AI service workflows, ensuring keys are temporarily rendered inactive when service conditions (e.g., unauthorized access) warrant such action.

3. Log all suspension and reactivation activities to ensure that access changes, reactivation conditions, and compliance obligations are tracked for audit 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.

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 AI Customers (AIC)

Role Specific

1. Integrate key expiration and deactivation mechanisms into AI service workflows, ensuring that keys associated with sensitive AI-related data (e.g., prompts, completions, API tokens) are deactivated automatically upon reaching their expiration date.

2. Implement a process for validating key expiration across AI-related storage services and API endpoints, ensuring no expired keys are active or used in data processing workflows.

3. Maintain audit logs for all key deactivation events, ensuring traceability and compliance with legal retention and data protection 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.

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 AI Customers (AIC)

Role Specific

1. Archive AIC-managed encryption keys used in AI-related operations such as prompt processing, model output delivery, and token-based API sessions, together with metadata indicating purpose, expiration, and associated AI workflow.

2. Restrict access to archived keys using identity-based controls mapped to AI governance roles, ensuring only designated data custodians or regulatory compliance personnel may retrieve keys under documented justification.

3. Conduct semi-annual reviews of AI key archival records, verifying that keys associated with deprecated AI integrations or retired datasets are retained only for approved retention periods and access logs remain intact for audit readiness.

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

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 AI Customers (AIC)

Role Specific

1. Control decryption-only use for compromised keys, ensuring that they are restricted to decrypting AI-related data such as prompts, completions, and API keys, while ensuring these keys are not used for any new encryption, and their use is tightly controlled according to legal and regulatory requirements.

2. Ensure formal reviews and documentation of any use of compromised keys, confirming that decryption activities are justified, logged, and compliant with incident response procedures, and that access to the compromised keys is limited.

3. Train and communicate key management practices to AI platform operators, security teams, and IT administrators, emphasizing the specific conditions under which compromised keys are to be used and the process for isolating these keys from encryption functions.

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

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 AI Customers (AIC)

Role Specific

1. Evaluate recovery impact by assessing the trade-off between the need for continued AI service access and the potential risk of data exposure, ensuring recovery actions align with legal, regulatory, and organizational data protection standards.

2. Approve recovery methods by formalizing and reviewing AI key recovery strategies in line with data classification, operational risk tolerance, and compliance obligations, ensuring that recovery activities are both secure and compliant.

3. Implement secure recovery mechanisms by integrating key recovery processes into AI systems, ensuring that all recovery actions are controlled, logged, and aligned with data access policies, and are only accessible by authorized personnel.

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

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 AI Customers (AIC)

Role Specific

1. Track AI-specific encryption keys by ensuring that all AI-related keys, including those for prompts, completions, API keys, and encrypted data, are accurately inventoried and aligned with cryptoperiods and regulatory retention requirements.

2. Establish key tracking mechanisms to log key ownership, status transitions, and usage logs for AI systems, ensuring compliance with internal controls and data protection obligations.

3. Monitor and audit key inventory by conducting regular internal audits and technical reviews, ensuring that all key status changes are logged, inventory records are accurate, and unauthorized usage is identified and mitigated.

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

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 AI Customers (AIC)

1. If applicable, AI Customers should establish appropriate policies governing physical and environmental protections for any on-premises infrastructure used to access, integrate, or operate AI systems.

2. Customers should ensure secure facilities, restricted access to AI-integrated systems, and environmental safeguards where sensitive workloads or data are processed.

3. Customers should also validate that external service providers meet contractual physical security requirements.

4. Customers need to align their Policies with CSP to permit a consistent and coherent physical security integration approach.

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 AI Customers (AIC)

Not applicable

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 AI Customers (AIC)

Not Applicable

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 AI Customers (AIC)

Not Applicable

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 AI Customers (AIC)

Not Applicable

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 AI Customers (AIC)

Role Specific Control Ownership Rationale. The control ownership rationale provided for the CSP applies.

Implementation Guidelines. The AIC should ensure that its data is properly protected and that the CSP implements appropriate classification and security controls on its physical and logical assets based on the sensitivity of such data.

The following implementation best practices apply for the AIC :

• a. Data Classification Policy: The AIC should develop a comprehensive data classification policy (refer to DSP-01 and DSP-04) that defines the different data sensitivity levels and the criteria for classifying data into those levels. The policy should be communicated to the CSP to guide their asset classification process.

• b. Data Usage Patterns: Data usage patterns, such as data access frequencies, data flows, and data processing activities could be shared with the CSP. This information can help the CSP understand the context in which your data is used and make informed classification decisions over the physical and logical assets.

• c. Regulatory Compliance Requirements: The CSP should be informed about applicable legal and regulatory compliance requirements that apply to CSC data, such as industry standards or government regulations. This will ensure that these requirements are taken into account by the CSP when classifying assets and implementing security controls.

• d. Change Management and Communication: Open communication channels should be maintained with the CSP regarding any changes to physical and logical assets handling AIC data, or any changes to the AIC’s data classification policy or usage patterns. This communication will enable the CSP to keep asset classifications and security controls aligned with the AIC’s evolving data security and protection requirements.Prioritize documenting usage patterns, data sharing agreements, and security requirements for AI vendors.

• e. Ensure that contractual agreements with CSPs cover data handling and physical access restrictions” or “periodically review third-party audit reports.

[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 AI Customers (AIC)

Role Specific

1. Providers should catalogue and track the different types of assets that are involved in tasks such as data processing , inference, training

2. Maintain a registry of all application modules with AI integrations.

3. Document accessibility features and compliance requirements.

[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 AI Customers (AIC)

Not Applicable

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 AI Customers (AIC)

Not Applicable

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 AI Customers (AIC)

Not Applicable

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 AI Customers (AIC)

Not Applicable

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 AI Customers (AIC)

Not Applicable

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 AI Customers (AIC)

Not Applicable

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 AI Customers (AIC)

Not Applicable

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 AI Customers (AIC)

Not Applicable

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 AI Customers (AIC)

Not Applicable

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 AI Customers (AIC)

1. AI Customers should monitor, assess and document operational and security-relevant indicators associated with AI services and any on-premises or customer-managed infrastructure that supports AI system integration.

2. Metrics should include service availability, access control events, configuration integrity of customer-managed components, and indicators of service degradation that could impact AI-dependent business processes.

3. Customers should review provider-supplied service health and availability reporting, and establish escalation and response procedures when infrastructure metrics indicate potential security or continuity risks.

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 AI Customers (AIC)

AI Customers should define and maintain continuity strategies for business processes that rely on AI services, including contingency workflows, service failover options, and escalation procedures for prolonged service disruptions. Customers should assess the resilience capabilities and recovery commitments of service providers, and ensure contractual or operational arrangements support business continuity objectives. Where customer-managed infrastructure supports AI integrations, customers should implement appropriate backup, recovery, and restoration procedures and periodically validate continuity measures.

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 AI Customers (AIC)

Primary Responsibility: Securing customer data and ensuring compliance with user data privacy policies.

1. Ensure AI-generated content is validated to not expose sensitive user data.

2. Validate privacy-by-design principles in application development.

3. Provide transparency to users regarding data collection, usage, and retention policies.

4. Support user consent management and data deletion requests per compliance requirements.

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

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 AI Customers (AIC)

1. Define and enforce data disposal schedules aligned with regulatory and contractual requirements.

2. Ensure vendors support secure delete upon offboarding or service change.

3. For on-prem data, follow ISO/NIST guidance for media disposal; for cloud, use provider tools and verify deletion.

4. Document and archive evidence of completed data destruction (e.g., certificates of destruction).

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

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 AI Customers (AIC)

1. Define clear policies on what data is considered sensitive or personal.

2. Maintain internal data inventory and perform periodic reviews.

3. Ensure compliance with internal security and privacy policies.

4. Leverage encryption and access control mechanisms for data stored in enterprise applications.

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

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 AI Customers (AIC)

1. Define policies for classifying internal business data and user information.

2. Maintain a record of classified data and enforce security measures accordingly.

3. Implement security best practices for handling sensitive enterprise or personal data.

4. Conduct regular audits to ensure compliance with classification policies.

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

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 AI Customers (AIC)

1. Maintain internal documentation for enterprise data processing, storage, and transmission.

2. Define policies for reviewing and updating data flow documentation.

3. Implement regular security audits to validate data flow accuracy.

4. Ensure compliance with data protection regulations through continuous monitoring.

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

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 AI Customers (AIC)

1. Clearly define internal data ownership policies for corporate and user data.

2. Maintain a data inventory that tracks data ownership and stewardship responsibilities.

3. Implement role-based access controls (RBAC) to enforce ownership rules.

4. Review ownership and stewardship policies annually and upon organizational changes.

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

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 AI Customers (AIC)

1. Define security requirements for AI implementations based on risk assessment.

2. Conduct security audits and compliance assessments for AI services.

3. Ensure proper security awareness training for employees handling AI data.

4. Enforce security controls in business operations leveraging AI.

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

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 AI Customers (AIC)

1. Establish organizational policies that enforce privacy-by-design principles in AI deployments.

2. Ensure compliance with relevant privacy laws through continuous monitoring and audits.

3. Maintain transparency with stakeholders about AI data processing practices.

4. Require contractual commitments from AI service providers regarding privacy protection.

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

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 AI Customers (AIC)

1. Conduct DPIAs to assess the impact of AI services on user and enterprise data.

2. Ensure compliance with applicable regulations (GDPR, CCPA, HIPAA, etc.).

3. Maintain documentation of data processing activities and risk assessments.

4. Implement risk mitigation strategies based on DPIA findings.

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

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 AI Customers (AIC)

1. Classify data before uploading and apply pseudonymization if required.

2. Enforce secure upload channels and validate provider compliance certifications.

3. Document lawful basis for processing and ensure usage remains within the agreed scope.

4. Periodically audit downstream vendors for regulatory alignment.

[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. contractually limit transferred data for any transfers the actor initiates or receives.

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 AI Customers (AIC)

1. Define policies for handling DSRs in compliance with regional regulations (e.g., within 30 days for GDPR).

2. Coordinate execution of DSRs with upstream vendors and verify data deletion/modification.

3. Maintain a record of DSR requests and proof of compliance.

4. Clearly communicate user rights and data retention policies.

5. Provide tools and services that enable other actors to implement AIC-defined controls securely.

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

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 AI Customers (AIC)

1. Define lawful basis and purposes for all personal data collected.

2. Map processing activities to each purpose and document in privacy impact assessments (PIAs).

3. Audit and review all vendor contracts to ensure purpose-aligned processing.

4. Monitor data pipeline for misuse or repurposing and maintain records of declared intents.

[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: MP, AIC, OSP]

1. Enforce purpose-bound model training and privacy-by-design.

[Shared among: AP, AIC, OSP]

1. Declare purpose and manage consent at the application interface.

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 AI Customers (AIC)

1. Define clear roles and responsibilities for data controllers and processors in contracts.

2. Ensure due diligence is done on upstream providers (APs, OSPs) before data is transferred.

3. Implement internal data transfer protocols and incident response plans.

4. Conduct periodic audits to validate compliance with laws like GDPR/CCPA.

[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 AI Customers (AIC)

1. Ensure contractual language mandates sub-processor disclosure before processing begins.

2. Conduct due diligence on upstream providers’ data handling and transparency practices.

3. Implement internal review and approval processes to vet third-party data access.

4. Require service providers to document data access paths and roles clearly.

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

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 AI Customers (AIC)

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

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 AI Customers (AIC)

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

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 AI Customers (AIC)

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

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 AI Customers (AIC)

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

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 AI Customers (AIC)

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

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 AI Customers (AIC)

[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 AI Customers (AIC)

1. Report unusual patterns or unexpected model behaviors promptly to model provider.

2. Conduct periodic reviews of model outputs against expected business outcomes.

3. Monitor model output to detect illogical or unexpected outcomes.

[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 AI Customers (AIC)

1. Define business objectives and data sensitivity requirements.

2. Validate PET effectiveness for defined business use case.

3. Perform periodic compliance assessments to verify Privacy Enhancing Technologies (PETs) effectively meet privacy objectives, regulatory requirements, and business use case specifications.

[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 AI Customers (AIC)

1 Implement schema and label validation rules aligned with business logic and use cases; define drift thresholds.

1. Maintain internal version history for domain-specific datasets and document changes.

2. Define roles, responsibilities, and access levels for data stakeholders. Implement approval workflows for dataset changes., including sign offs by legal or compliance teams.

3. Implement data integrity checks in pre- and post-upload to model pipelines.

[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 AI Customers (AIC)

1. Document the AI system’s purpose, including its target domain, users, use cases and operational context. Example- A fraud detection model for retail should not be trained on healthcare data.

2. Conduct data audits to check for relevance to the intended function, remove or flag low quality data by providing feedback to model provider.

3. Document the provenance of all training data sources. This could include evaluation of: Validity, completeness, freshness, consistency, and plausibility of the data, Visibility of data readiness signals to agents or orchestration layers, etc.

4. Implement review checkpoints to reassess relevance with business use case and regulation changes.

[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 AI Customers (AIC)

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

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 AI Customers (AIC)

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

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 AI Customers (AIC)

1. Coordinate with vendors to understand upstream policy changes that affect data handling or AI usage; record accepted deviations and compensating controls.

2. Include contractor and third-party access clauses in policy reviews and communicate revisions to external partners.

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

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 AI Customers (AIC)

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

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 AI Customers (AIC)

1. Extend the internal InfoSec program to include third-party AI risk management, vendor security evaluations, and compliance alignment.

2. Define requirements for acceptable encryption, access control, and monitoring of provider-hosted AI services.

3. Participate in shared incident response planning with key AI providers.

4. Track how AI outputs interact with customer environments and evaluate downstream risks.

5. Require formal documentation of provider InfoSec practices and map them to internal risk tolerances.

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

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 AI Customers (AIC)

1. Create roles to track provider compliance with internal and external obligations; appoint contract & SLA reviewers for AI services.

2. Ensure legal, privacy and risk teams are consulted on major AI onboarding or feature expansions.

3. Establish personnel responsible for monitoring AI output appropriateness and escalating anomalies; require periodic review of vendor data-usage practices.

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

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 AI Customers (AIC)

1. Perform third-party risk assessments to validate provider compliance with jurisdictional and sector-specific regulations.

2. Map AI service provider controls to internal regulatory obligations and risk tolerances.

3. Ensure contractual terms require transparency and documentation of how regulatory obligations are fulfilled.

4. Monitor regulatory mapping updates and ensure gaps are communicated and mitigated.

5. Participate in shared control reviews and compliance audits with providers.

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

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 AI Customers (AIC)

1. Follow updates from SIGs focused on procurement, AI assurance, and cross-border compliance.

2. Engage with communities of AI risk officers, auditors, and policy leads.

3. Adopt risk frameworks (e.g., ALTAI, OECD AI Principles) championed by regulatory SIGs.

4. Monitor recommendations related to AI output risk evaluation and human-in-the-loop governance.

5. Contribute to enterprise buyer SIGs to advocate for greater provider transparency.

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

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 AI Customers (AIC)

1. Incorporate provider AUP terms into internal usage policy training and governance workflows.

2. Monitor usage patterns to detect any violations from internal teams or integrated third-party tools.

3. Flag ambiguous or high-risk use cases to providers for joint review before deployment.

4. Include AUP compliance clauses in vendor contracts and incident handling plans.

5. Develop internal processes for responding to provider-flagged AUP breaches.

[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 AI Customers (AIC)

1. Request completed AI impact assessments from providers during onboarding or before activating new features.

2. Perform internal risk assessments for downstream integration of AI outputs into customer workflows.

3. Use AI impact assessments to guide procurement, internal usage policies, and exception approvals.

4. Ensure that legal and ethics teams participate in high-impact deployment reviews.

5. Map provider risk assessments to internal risk appetite and escalation protocols.

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

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 AI Customers (AIC)

1. Request provider fairness assessments and compare them to internal ethical standards.

2. Conduct external audits or impact assessments for sensitive AI use cases.

3. Use fairness metrics as part of model selection and acceptance criteria.

4. Ensure business leaders are trained to interpret fairness results responsibly.

5. Document and escalate bias concerns identified through usage or audit.

[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 AI Customers (AIC)

1. Participate in vendor ethics review processes when using high-risk AI externally or with end users.

2. Develop an internal ethics committee for AI usage in regulated or sensitive domains.

3. Include committee recommendations in executive approvals for major rollouts.

4. Ensure whistleblower protections and confidential reporting channels.

5. Use committee guidance to build ethical escalation trees in governance policies.

[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 AI Customers (AIC)

1. Define minimum explainability requirements for each use case during procurement.

2. Review vendor explanations for clarity, completeness, and consistency with contractual terms.

3. Translate explanations into business-specific impact insights.

4. Include explainability documentation in internal audit and compliance reporting.

5. Work with providers to address cases where explanation quality degrades over time.

[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 AI Customers (AIC)

1. Request detailed model documentation from vendors during onboarding and procurement.

2. Ensure transparency disclosures are reviewed by internal compliance and risk teams.

3. Map model transparency claims to actual performance and behavior in production.

4. Disclose AI usage to end users where legally or ethically required.

5. Report gaps in transparency to vendor or regulator channels.

[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 AI Customers (AIC)

1. Establish internal policies requiring human supervision for AI outputs that affect user rights, financial outcomes, or legal exposure.

2. Define threshold criteria (e.g., risk level, confidence score) that trigger mandatory human review before acting on AI recommendations.

3. Assign human reviewers to AI decision workflows in domains like healthcare, hiring, credit decisions, or law enforcement.

4. Maintain training programs for staff involved in AI oversight to ensure informed evaluation of algorithmic decisions.

5. Regularly assess supervision effectiveness and adapt policies to reflect evolving risks and feedback from impacted users.

[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 AI Customers (AIC)

1. Internal/Contractor Screening: Define and apply a background screening process for internal teams or contracted professionals deploying or managing AI solutions.

2. Frequent Updates for High-Risk Use Cases: Update screening criteria more frequently for advanced or higher-risk AI use cases (e.g., facial recognition, biometric data analysis).

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

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 AI Customers (AIC)

1. Adopt Provider Policies: Review and adhere to the acceptable use requirements defined by AI providers. Align internal processes to meet the provider’s documented AI usage limitations.

2. Internal Oversight and Governance: Define internal governance processes to monitor AI usage, evaluate compliance, and handle potential misuse or incident response. Update acceptable use guidelines based on emerging risks or regulatory changes.

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

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 AI Customers (AIC)

[All Actors]

The implementation guidelines provided by the CSP apply.

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 AI Customers (AIC)

1. Secure AI Workflow Integration: Configure consumer-side systems with approved secure communication channels when accessing the provider’s AI environment. Enforce MFA and privileged credentials for staff handling AI datasets or models remotely.

2. AI Data Protection Policies: Establish clear guidelines for classifying and handling AI data offsite; maintain an inventory of approved remote tools and ensure they meet privacy requirements.

3. Regular Training & Awareness: Provide recurring training on remote security practices, endpoint configurations, and responsible handling of confidential AI algorithms. Emphasize legal and business consequences of data breaches.

4. Alignment with Provider Standards: Work with AI providers to confirm that remote processes meet shared encryption, identity management, and logging standards, ensuring compatibility with the provider’s remote protection measures.

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

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 AI Customers (AIC)

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

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 AI Customers (AIC)

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

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 AI Customers (AIC)

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

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 AI Customers (AIC)

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

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 AI Customers (AIC)

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

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 AI Customers (AIC)

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

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 AI Customers (AIC)

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

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 AI Customers (AIC)

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

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 AI Customers (AIC)

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

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 AI Customers (AIC)

[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 AI Customers (AIC)

[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 AI Customers (AIC)

[AIC] The AI service customer is responsible for IAM policies for the end user

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

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 AI Customers (AIC)

[AIC] The AIC is responsible for establishing strong authentication credential management policies for their internal users’ and end users’ authentication to accounts and endpoints.

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

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 AI Customers (AIC)

[AIC]

1. The AI Customer is responsible for inventorying identities including:

   • End-user identities using AI-enabled features

   • Privileged user accounts that can configure user-facing AI settings

   • Admin accounts with elevated access

   • Group memberships that grant access to AI capabilities.

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

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 AI Customers (AIC)

[AIC]

1. The AI Customer is responsible for implementing SoD by

   • Using SoD for any privileges given to AI agents

   • SoD between human oversight roles and agent configuration roles

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

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 AI Customers (AIC)

[AI Customer]

1. The AI Customer is responsible for implementing PoLP by:

   • Limiting AI system access based on specific business needs and user roles

   • Restricting AI configuration capabilities to designated administrators

   • Providing department-specific permissions for AI resources aligned with legitimate use cases

   • Limiting agent configuration rights to designated technical personnel

   • Restricting agent authorization capabilities based on a risk assessment of potential actions

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

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 AI Customers (AIC)

1. Align user access provisioning with organizational HR events (e.g., onboarding, transfers) via workflow automation.

2. Maintain a role-to-entitlement mapping for each department, then provision access according to that mapping—granting only the least-privilege entitlements needed for the data sensitivity and AI-model criticality involved (including vendor-hosted systems).

3. Require dual-approval or elevated workflows for access to privileged AI environments.

4. Regularly audit access provisioning activities to ensure alignment with internal policy and contractual obligations.

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

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 AI Customers (AIC)

1. Coordinate closely with HR and vendors to confirm off-boarded staff—and contractors—lose access across all supplier portals.

2. Track outstanding revocations on a central dashboard and escalate items that exceed SLA.

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

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 AI Customers (AIC)

1. Review access to AI models, training environments, and evaluation dashboards as part of broader IT audits.

2. Include contractor and vendor access in review cycles, especially for shared workspaces or repositories.

3. Use automated workflows for multi-approver access review processes.

4. Maintain documented evidence of reviews for regulators, auditors, and third-party assurance.

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

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 AI Customers (AIC)

1. Establish policy controls to prevent internal users from holding conflicting access roles.

2. Periodically audit segregation adherence, particularly in small teams with overlapping responsibilities.

3. Limit access to model deployment systems to designated personnel with oversight.

4. Develop escalation paths for privilege separation exceptions, with compensating controls and justification.

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

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 AI Customers (AIC)

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

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

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 AI Customers (AIC)

[AIC]

1. Ensure the appropriate stakeholder are assigned approval rights to relevant resources.

2. Regularly audit events to ensure actions high risk privileged access has been granted in the appropriate manner.

3. Regularly review and certify privileged access role approvers.

4. Regularly review and audit vendors/partners procedures and controls for granting high risk roles.

5. Contractual Agreements: enter into a formal agreement (SLA) that outlines the specific terms and conditions for granting privileged access to high-risk data.

6. High-risk Data Scope: AIC should define the scope of data considered high risk.

7. Request Approval Process: The AIC should require explicit approval from the relevant representative for any access request involving high-risk data.

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

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 AI Customers (AIC)

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

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 AI Customers (AIC)

[AIC]

1. Educate users on credential hygiene and identifying phishing/social engineering

2. Integrate central idP with AI providers to provide federated authentication ensuring organization authentication controls are supported

3. Regularly review and verify AI providers authentication methods for strong authentication practices.

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

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 AI Customers (AIC)

[AIC]

1. Enabled and Enforce secure password complexity.

2. Train employees on secure credentials management including topics such as:

   • i. secure storage and secrets manager usage

   • ii. identifying phishing.

[All Actors]

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.

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 AI Customers (AIC)

[AIC]

1. Ensure access to AI application and services is configured with granular access control based on actor (user/system) role and responsibilities.

2. Implement approval processes for changes to authorization (RBAC) configuration for users.

3. Regularly review AI application and services authorization configuration to ensure principle of least privilege.

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

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 AI Customers (AIC)

[AIC]

1. Implement policies, processes and procedures to track the sharing/training of information with AI systems.

2. Apply granular permission to roles in tools, application and infrastructure to ensure access to information is on a need to know basis.

3. Ensure Agent-based.

[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 AI Customers (AIC)

[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 AI Customers (AIC)

Policy Scope:

Access restriction policies cover evaluation of agent-based solutions in AI-powered applications from CSPs, MPs, OSPs, or APs. Focus on validating that provider agents adhere to least privilege and resource segregation through documentation or audits. Include procedures for assessing risks from over-privileged agents (e.g., excessive tool access) before adoption.

[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 AI Customers (AIC)

1. Establish procedures for evaluating provider adherence to interoperability standards & portability commitments.

2. Ensure understanding of provider’s policies regarding data formats, APIs, protocols & data portability options.

3. Review provider documentation & policies annually or upon changes.

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

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 AI Customers (AIC)

1. Utilize provided APIs for programmatic data retrieval as needed for interoperability or portability.

2. Verify that the scope and format of data available via APIs meet requirements.

3. Adhere to API usage policies (e.g., rate limits, authentication)

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

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 AI Customers (AIC)

1. Configure client tools/apps to exclusively use mandated secure protocols.

2. Ensure client systems have up-to-date secure communication libraries.

3. Verify authenticity of provider endpoints (e.g., TLS certs) before transferring data.

4. Ensure all interactions (API calls, data transfers, console access) use secure channels.

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

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 AI Customers (AIC)

1. Contract Review & Negotiation: a) Carefully review data portability/exit clauses before signing. b) Ensure format, scope, retention, deletion policy meet requirements. Negotiate if needed.

2. Exit Planning: a) Understand process, timelines, potential costs for data retrieval upon termination. b) Factor provisions into business continuity/exit strategy.

3. Verification: Ensure agreement clearly states right to retrieve your data in a usable, defined format for a specified period, and confirms deletion policy.

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

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 AI Customers (AIC)

1. Establish infrastructure security policies for AI service consumption, including vendor security assessments and compliance validation.

2. Ensure infrastructure security policies cover integration security for AI services, including network segmentation and API controls.

3. Periodically review AI service providers’ infrastructure security practices.

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

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 AI Customers (AIC)

1. Validate AI service providers’ capacity planning processes.

2. Ensure SLAs cover system performance and scalability.

3. Periodically review AI provider reports on capacity and performance.

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

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 AI Customers (AIC)

1. Validate AI providers’ network security measures.

2. Ensure compliance with security SLAs regarding encrypted communications.

3. Periodically review network security reports from AI service providers.

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

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 AI Customers (AIC)

1. Validate OS security baselines of AI service providers.

2. Ensure Hypervisor Security for AI Workloads Aligns with Organizational Policies.

3. Regularly Assess Infrastructure Hardening Measures in SLAs for AI Hosting and Compute Services.

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

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 AI Customers (AIC)

1. Define Environment Usage Policies for AI Workflows: Establish internal policies that define what constitutes production vs. non-production for AI systems (e.g., sandbox for model evaluation, staging for pre-launch testing). Ensure development and experimentation activities occur only in designated non-production environments.

2. Require Separation of Environments in Supplier Agreements: Verify that CSPs, Model Providers, and Application Providers enforce logical and physical separation between production and non-production environments. Include this requirement in contracts, security questionnaires, or data protection addendums.

3. Implement Role-Based Access Controls (RBAC) for Internal Teams. Ensure access to production and non-production AI systems is restricted by job role and approved through a formal process.

4. Monitor Environment Usage for Anomalies: Request access to or reports from provider audit logs for: Environment changes, Deployment approvals, Data access between environments. Define alerting thresholds for unauthorized access or cross-environment data movement.

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

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 AI Customers (AIC)

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

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 AI Customers (AIC)

1. Validate encryption and security controls used by cloud service providers.

2. Ensure compliance with regulatory requirements for cloud data migration.

3. Conduct security assessments of cloud migration activities.

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

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 AI Customers (AIC)

1. Review network documentation of AI providers for security risks.

2. Ensure network segmentation strategies align with security requirements.

3. Validate compliance with security best practices.

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

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 AI Customers (AIC)

1. Assess network security controls implemented by AI service providers.

2. Ensure security SLAs cover network protection measures.

3 Conduct periodic penetration testing on AI service environments.

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

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 AI Customers (AIC)

1. Establish policies for logging and monitoring usage patterns, performance metrics, and data interactions.

2. Implement logging mechanisms for customer-specific environments, including on-premises, cloud, or hybrid deployments.

3. Regularly review policies to ensure alignment with operational objectives and regulatory requirements.

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

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 AI Customers (AIC)

1. Implement access control mechanisms for logs according to organizational policies.

2. Regularly review access permissions and implement logging of all access attempts.

3. Implement mechanisms for validating log authenticity and accuracy.

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

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 AI Customers (AIC)

1. Monitor usage patterns within within your organization environment for signs of suspicious log-ins, excessive queries or anomalous resource consumption.

2. Implement tailored alerting rules to fit specific use cases and risk profiles.

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

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 AI Customers (AIC)

1. Establish comprehensive policies governing log access based on user roles, AI model use cases, and contractual obligations with service providers. Review and update policies to meet evolving security requirements.

2. Monitor and document all access attempts, including failed attempts, with emphasis on high-risk operations like model modification, training data access, or configuration file changes.

3. Implement logging mechanisms to capture API usage metrics, user interactions with AI models, and input/output logs for validation and troubleshooting.

4. Ensure logs are categorized appropriately for analysis, accountability, and auditing, particularly for sensitive AI workflows.

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

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 AI Customers (AIC)

1. Implement monitoring solutions tailored to the customer’s environment, to catch unauthorised model use, excessive queries or anomalous access.

2. Capture logs from AI system interactions, ensuring the ability to detect and respond to abnormal usage patterns.

3. Regularly update logging configurations based on evolving threats and operational requirements.

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

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 AI Customers (AIC)

1. Ensure systems logging activities have accurate timestamps for auditing and accountability.

2. Monitor for discrepancies in timestamps, particularly when correlating logs from distributed systems.

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

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 AI Customers (AIC)

1. Define logging scope according to internal risk appetite, operational needs and regulatory requirements. Ensure logs are categorized appropriately for analysis and reporting.

2. Periodically validate that logs from vendor systems include required fields and do not expose prohibited data.

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

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 AI Customers (AIC)

1. Define sanitization requirements for customer application logs integrating AI services, including end-user prompts to AI features, AI-generated responses, API authentication credentials, user session identifiers, and business-confidential queries.

2. Implement sanitization in application integration code to ensure end-user inputs to AI services and AI-generated outputs are sanitized before application logging or error handling.

3. Configure AI SDK logging settings and error handling middleware to sanitize sensitive API payloads, authentication tokens, and user-identifiable information in integration logs.

4. Validate AI service provider contracts include specific commitments for provider-side sanitization of customer data in logs, with audit rights and data processing agreements specifying log handling requirements.

5. Establish procedures for annual validation of AI provider compliance with log sanitization obligations through provider attestations, SOC 2 reports, or third-party audit access.

6. Review and update sanitization rules when integrating new AI services, deploying new AI features, or changing data classification policies.

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

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 AI Customers (AIC)

1. Maintain customer-side logs of data flows to and from the provider’s AI environment.

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

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 AI Customers (AIC)

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

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

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 AI Customers (AIC)

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

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 AI Customers (AIC)

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

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 AI Customers (AIC)

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

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 AI Customers (AIC)

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

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 AI Customers (AIC)

1. Adhere to usage guidelines (legal, ethical) and periodically review logs for unauthorized behaviors or policy noncompliance.

[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 AI Customers (AIC)

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

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 AI Customers (AIC)

Not Applicable

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 AI Customers (AIC)

Not Applicable

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 AI Customers (AIC)

Not Applicable

MDS-04: Model Documentation Requirements

Control Specification

Establish and implement baseline requirements for Model documentation.

Shared Implementation Guidelines

Not Applicable

Implementation Guidelines for AI Customers (AIC)

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 AI Customers (AIC)

Not Applicable

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 AI Customers (AIC)

Not Applicable

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 AI Customers (AIC)

Not Applicable

(The customer does not train the model and does not have access to the physical model to perform model hardening)

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 AI Customers (AIC)

1. As part of vendor due diligence, require the AP to provide verifiable evidence of model integrity controls.

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 AI Customers (AIC)

Not Applicable

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 AI Customers (AIC)

Not Applicable

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 AI Customers (AIC)

[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 AI Customers (AIC)

1. Define the organization’s risk tolerance and security requirements for open weight models.

2. Conduct periodic audits and assessments to validate the effectiveness of risk management processes across the AI supply chain

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

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 AI Customers (AIC)

Not Applicable

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 AI Customers (AIC)

1. Align internal incident response playbooks with the policies of service providers to ensure coordinated action.

2. Establish secure communication channels with vendors for real-time updates during incidents.

3. Participate in joint incident review meetings to assess vendor responsiveness and impact.

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

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 AI Customers (AIC)

1. Review provider service management policies and map them to internal operational controls.

2. Maintain contingency plans in case of AI model unavailability or degraded service quality.

3. Periodically assess service provider compliance with defined SLAs and operational commitments.

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

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 AI Customers (AIC)

1. Maintain internal procedures to triage and respond to incidents in vendor-hosted AI environments.

2. Simulate AI-specific incident scenarios in tabletop exercises (e.g., AI-generated misinformation).

3. Collaborate with vendors to ensure coordinated containment and disclosure.

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

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 AI Customers (AIC)

1. Participate in joint incident response exercises with AI model providers, cloud service providers, and other relevant vendors to validate coordinated response procedures.

2. Evaluate the effectiveness of incident detection, escalation, and response coordination across both internally managed systems and vendor-hosted AI services.

3. Use findings from testing activities to prioritize improvements in monitoring, detection, resilience, vendor coordination, and recovery capabilities for AI-enabled 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.

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 AI Customers (AIC)

1. Collaborate with providers to measure and improve incident responsiveness across vendor-managed services.

2. Benchmark internal metrics with vendor SLAs for continuous oversight.

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

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 AI Customers (AIC)

1. Establish intake procedures for AI-generated anomalies and route them into existing security event management workflows.

2. Work with providers to ensure shared triage protocols are aligned.

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

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 AI Customers (AIC)

1. Harmonize provider-assigned severity levels with internal response tiers and escalation paths.

2. Use shared definitions across internal security, compliance, and legal teams.

3. When possible, coordinate internal investigation activities and integrate findings into enterprise risk management and incident response processes.

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

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 AI Customers (AIC)

1. Coordinate breach notifications with providers to ensure consistent messaging, transparency, and alignment on technical facts before public or client disclosure.

2. Maintain internal logs of third-party breach notifications and downstream user communications.

3. Provide affected users and customers with specific details regarding their individual risk exposure, alongside actionable recovery steps and a summary of the corrective measures taken to secure their data.

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

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 AI Customers (AIC)

1. Establish intake and logging procedures for security anomalies observed during consumption of AI services, such as unauthorized data exposure in model responses, unexpected access to restricted information, or indicators of compromised AI service behavior, and route them into existing organizational security incident management workflows.

2. Collaborate with providers per SLA terms to ensure security incident records are shared, correlated, and reviewed jointly where incidents span the provider-consumer boundary.

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

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 AI Customers (AIC)

1. Maintain mapped contact lists for every critical provider in the AI supply chain.

2. Assign internal liaison roles for cross-vendor incident coordination.

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

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 AI Customers (AIC)

1. Demand and review supplier risk documentation (e.g., security whitepapers, penetration test results).

2. Integrate SCRM policies into enterprise procurement, risk, and vendor management systems.

3. Establish internal processes for validating AI supplier claims (e.g., robustness, bias testing).

4. Evaluate software bills of materials (SBOMs) for AI systems and services.

[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 AI Customers (AIC)

Role Specific:

1. Establish organizational AI consumption policies covering vendor selection criteria, internal usage governance requirements, business unit AI adoption procedures, and employee AI service usage standards specific to organizational AI governance.

2. Document vendor management SSRM procedures including Application Provider evaluation requirements, due diligence processes, contract security term validation, and ongoing vendor performance monitoring protocols.

3. Develop internal AI governance policies covering user access management procedures, data classification for AI usage requirements, business unit compliance monitoring protocols, and regulatory adherence validation specific to organizational AI adoption.

4. Create organizational compliance integration procedures including regulatory requirement mapping to AI services, audit preparation protocols, compliance documentation management, and internal reporting procedures for AI-related regulatory obligations.

5. Establish business continuity SSRM policies covering AI service dependency management procedures, alternative vendor evaluation requirements, service transition protocols, and organizational resilience planning for AI service disruptions

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

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 AI Customers (AIC)

Role Specific:

1. Implement SSRM throughout organizational AI consumption including secure vendor selection procedures, internal usage governance requirements, and employee training protocols for all AI service adoption and organizational AI governance activities.

2. Document vendor risk management and compliance oversight including: Vendor security assessment results and risk ratings, Contractual security requirement compliance evidence, Business impact analyses for critical AI dependencies.

3. Implement AI service consumption risk management by: Assessing risks related to service dependencies, Managing business process integration security requirements, Addressing regulatory compliance across the AI supply chain.

4. Manage the vendor relationship lifecycle through: Ongoing vendor performance and security monitoring, Regular compliance reviews and audit right executions, Business continuity planning for critical AI service disruptions.

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

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 AI Customers (AIC)

Role Specific:

1. Provide procurement and due diligence frameworks detailing: SSRM assessment criteria for vendor selection, Contractual security requirement templates, Ongoing monitoring and audit expectations.

2. Create internal stakeholder materials covering: Business risk acceptance criteria for AI services, User responsibility guidelines for AI system consumption, Incident reporting and escalation procedures.

3. Create departmental responsibility matrices/documentation that clearly delineate organizational SSRM responsibilities (governance, policy compliance, vendor oversight) versus individual user responsibilities (secure usage, data protection, policy adherence).

4. Provide user-facing SSRM guidance detailing secure AI service usage practices, acceptable use policies, data submission requirements, and incident reporting procedures for employees consuming AI applications.

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

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 AI Customers (AIC)

Role Specific:

1. Assign specific ownership for vendor governance SSRM controls to roles including: Vendor Risk Management Owner: Responsible for AP due diligence, contract compliance, and performance monitoring, Regulatory Compliance Owner: Responsible for ensuring AI services meet industry-specific regulations (e.g. HIPAA, GDPR, etc.), Business Integration Owner: Responsible for AI system alignment with business processes and risk tolerance.

2. Establish clear ownership boundaries between internal AI consumption governance and external vendor management responsibilities to ensure comprehensive oversight.

3. Delineate business continuity control ownership between business continuity teams for AI service dependency planning, IT teams for alternative vendor evaluation, and operations teams for service transition and recovery procedures.

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

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 AI Customers (AIC)

Role Specific:

1. Review and validate vendor governance SSRM documentation including: Application Provider compliance evidence and audit reports, Vendor risk assessment methodologies and results, Contractual security requirement compliance documentation.

2. Validate that business integration documentation accurately reflects: AI system integration with business processes and workflows, User access management and training procedures, Business continuity and disaster recovery plans for AI services.

3. Ensure regulatory compliance documentation is current and complete, covering: Industry-specific regulatory requirement mappings (e.g., HIPAA, GDPR), Data sovereignty and cross-border transfer compliance records, Audit readiness documentation for regulatory examinations.

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

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 AI Customers (AIC)

Role Specific:

1. Implement vendor governance controls for: AP selection and due diligence procedures, Contractual security requirement enforcement, Performance and compliance monitoring frameworks.

2. Operate internal AI governance controls covering user access management, usage monitoring systems, policy compliance tracking, and organizational AI adoption oversight procedures.

3. Audit vendor compliance controls including regular assessment of Application Provider security documentation, validation of Application Assurance Reports, and verification of contractual security commitments.

4. Maintain internal AI usage documentation ensuring accurate records of implemented governance controls, user training completion, policy compliance status, and vendor relationship management.

5. Operate user training and awareness controls including AI security education programs, usage policy communication, incident reporting procedures, and ongoing competency validation for AI service users.

6. Implement organizational risk management controls covering AI service risk assessments, business impact analysis, continuity planning, and regulatory compliance validation for AI adoption

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

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 AI Customers (AIC)

Role Specific:

1. Maintain comprehensive inventory of AI service provider relationships including Application Providers, direct AI service subscriptions, SaaS AI tools, and enterprise AI platforms with contract details, usage scope, and organizational dependencies.

2. Document internal AI tool and service relationships covering departmental AI subscriptions, shadow IT AI usage, employee-purchased AI tools, and business unit-specific AI implementations with approval status and usage governance.

3. Catalog AI vendor and supplier relationships including procurement contacts, account managers, technical support providers, and professional services partners with contract terms, renewal dates, and escalation procedures.

4. Inventory AI-related infrastructure dependencies documenting any direct cloud service relationships, on-premises AI infrastructure, hybrid deployment partners, and data integration services supporting AI consumption.

5. Maintain AI governance and compliance relationships including AI auditors, regulatory consultants, legal advisors specializing in AI, and compliance service providers with expertise areas and engagement scope.

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

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 AI Customers (AIC)

Role Specific:

1. Request BOMs from providers during procurement or onboarding to assess component risk and compliance posture.

2. Use BOM insights to assess exposure to deprecated, insecure, or unlicensed components.

3. Maintain internal mappings between provider BOMs and internal risk categorizations.

4. Request BOM refreshes following major model, service, or infrastructure updates.

5. Integrate BOM reviews into third-party risk assessments and supply chain governance.

[All Actors] [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.

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 AI Customers (AIC)

Role Specific:

1. Maintain an Inventory of AI Supply Chain Dependencies: Catalog all third-party AI components and services used, including: Models (e.g., LLMs, vision models), Data sources or preprocessing pipelines, Libraries, SDKs, and APIs, Hosting providers (e.g., CSPs), etc. Include metadata such as: Vendor name, Licensing type, Risk classification (e.g., high/medium/low). Update regularly to track evolving dependencies.

2. Define and Enforce Third-Party Risk Requirements in Contracts and SLAs: Require vendors (APs, MPs, CSPs) to: Disclose their own supply chain dependencies, Maintain secure development and deployment practices, Support incident reporting, change notifications, and impact analysis. Include supply chain risk clauses in: Procurement contracts, Vendor risk assessments, Due diligence checklists.

3. Define Contingency Plans for Supply Chain Failures: Establish backup plans for: Critical AI services being deprecated or compromised, Shifting workloads to alternative vendors, Model/service rollback if changes fail quality or compliance checks.

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

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 AI Customers (AIC)

Role Specific:

1. Include organizational usage and governance provisions in agreements with AI service providers specifying internal policy compliance requirements, user training obligations, usage monitoring responsibilities, and organizational risk tolerance parameters.

2. Define data ownership and control terms in contracts ensuring customer data sovereignty, export rights, deletion guarantees, and organizational control over data processing locations and methods.

3. Specify regulatory compliance support provisions requiring vendors to provide compliance documentation, regulatory change notifications, audit support, and assistance with organizational compliance obligations (e.g. GDPR, HIPAA, SOX, etc.).

4. Include liability and recourse mechanisms that protect the AIC’s business interests: Financial remedies for business disruption, Clear accountability for business-impacting failures, Insurance and indemnification requirements. Include organizational exit and transition terms ensuring business continuity support, internal process transition assistance, and minimal disruption to organizational operations during vendor changes.

5. Define vendor performance and accountability provisions including organizational KPI alignment, business outcome metrics, internal SLA requirements, and vendor management reporting standards. Define performance metrics aligned with business outcomes such as: Key business indicators tied to AI service performance, Impact metrics on customer experience or operational efficiency, Business value realization measurements, etc.

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

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 AI Customers (AIC)

Role Specific:

1. Review AI service consumption agreements with Application Providers to ensure usage rights, data ownership terms, and service level commitments align with evolving organizational needs and regulatory requirements.

2. Evaluate internal AI governance policy agreements and usage guidelines to verify they remain consistent with external vendor commitments and organizational risk tolerance.

3. Assess data processing agreements with AI service providers to ensure compliance terms, data residency requirements, and breach notification provisions meet current regulatory and organizational standards.

4. Review vendor indemnification and liability terms to verify adequate protection for AI-related risks, regulatory compliance failures, and potential AI system performance issues. Schedule formal reviews, at least annually or upon substantial model/system upgrades, to assess whether AI providers are meeting their contractual and security assurance obligations. Use a structured checklist for each role (MP, AP, OSP, CSP) based on their responsibilities in the AI supply chain.

5. Update procurement and vendor selection criteria based on agreement reviews to reflect lessons learned, changing AI risk landscape, and evolving organizational AI adoption maturity.

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

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 AI Customers (AIC)

Role Specific:

1. Internally audit the AIC’s own process for selecting and onboarding new AI vendors. Review a sample of recent AP contracts to validate that:

   • A formal risk assessment was performed before procurement.

   • The “Application Assurance Report” (or equivalent evidence) was received and reviewed from the AP.

   • Contracts mandate required security, privacy, and breach notification clauses.

2. Assess the internal process for periodically re-evaluating incumbent APs (e.g., annually). Check that: There is a schedule and it is followed. Check that the process for requesting and reviewing updated compliance evidence (e.g., the AP’s newest SOC 2 report) is effective. Check that risks are re-assessed and the AI Vendor Risk Register is updated.

3. Test the Third-Party Incident Response Integration: Conduct a tabletop exercise that simulates a security incident reported by an AP. Measure the effectiveness of the AIC’s internal process for receiving the notification, assessing the impact on the business, and executing their own communication and response plans.

4. Review the centralized AI Vendor Risk Register for accuracy, completeness, and actionability. Validate that:

   • All AI vendors are included and accurately categorized by risk.

   • The compliance status for each vendor is current.

   • Open risks have owners and remediation timelines.

5. Validate the Flow-Down of Regulatory Requirements: For AICs in regulated industries, assess the internal process for ensuring that their regulatory obligations (e.g., GDPR, HIPAA) are correctly flowed down to APs through contracts. Review a sample of contracts to confirm these clauses are present and adequate.

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

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 AI Customers (AIC)

Role Specific:

1. Establish comprehensive compliance policies for Application Providers, direct AI service providers, SaaS integrations, and any third-party AI tools covering information security, data confidentiality, access control, privacy protection, audit requirements, personnel policies, and service level standards aligned with organizational and regulatory requirements.

2. Require contractual commitments from all AI service providers including: Application Providers to comply with enterprise security and data handling standards, Direct AI services to meet organizational privacy and compliance requirements, Integration partners to follow data transmission security and access control policies, All providers to adhere to relevant regulatory standards (e.g., GDPR, HIPAA, SOX, etc.).

3. Enforce compliance consequences including service usage restrictions, vendor replacement, or remediation requirements for providers who fail to meet organizational security, privacy, and regulatory compliance standards.

4. Conduct Rigorous Pre-Contract Due Diligence. Perform a thorough review of the AP’s “Application Assurance Report” before signing the contract. Validate the evidence provided to ensure it meets your standards. (This could be the most critical step to de-risk the procurement).

5. Maintain an AI Vendor Risk Register. Keep a centralized register of all AI application providers in use. For each provider, record the risk rating, the status of their compliance evidence, and any open risks or action items. This register is a key tool for reporting AI supply chain risk to executive leadership and the board.

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

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 AI Customers (AIC)

Role Specific:

1. Establish and document the minimum security and compliance standards required for any procured AI application. This includes required certifications (e.g., SOC 2 Type II, ISO 27001), data handling policies, and breach notification SLAs. Integrate these requirements into the organization’s procurement and vendor risk management policies.

2. Mandate the “Application Assurance Report” Contractually: During contract negotiations, mandate that the Application Provider (AP) must provide a comprehensive “Application Assurance Report” (as defined in the AP’s guidelines) prior to signing and periodically thereafter (e.g., annually). Ensure the contract grants the right to audit this report and the evidence behind it.

3. Conduct Focused Reviews of Provider Evidence: Do not attempt to assess every supplier in the AP’s chain. Instead, focus the review on:

   • The AP’s own credentials: Their SOC 2 report, penetration test results.

   • The AP’s supply chain management process: How do they assess their Model Providers and OSPs? Is their process rigorous?

   • Spot-checking key evidence: Samples from the “Model Security Manifest” of a critical model or the “OSP Assurance Pack” from a high-risk data processor to validate the AP’s claims.

4. Create and maintain a centralized register of all AI application providers in use. For each provider, record the risk rating (based on data sensitivity and application criticality), the status of their “Application Assurance Report,” and any open risks or action items from the review.

5. Integrate AI Supply Chain Risk into Broader Enterprise Risk Management (ERM). Ensure the risks identified from AI procurement (e.g., “Dependency on AP X’s model, which is trained on data of questionable provenance”) are formalized and reported into the organization’s overall Enterprise Risk Management framework.

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

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 AI Customers (AIC)

Role Specific:

1. Train internal staff including business users, data analysts, procurement personnel, and IT support staff on SSRM policies and risks associated with using AI services.

2. Provide ongoing security awareness training for all roles involved in procuring, configuring, using, and monitoring AI applications and services.

3. Require contractual commitments from AI service providers (Application Providers, OSPs) regarding their SSRM compliance training programs and security practices.

4. Verify vendor training compliance through due diligence questionnaires, security certifications, and periodic reviews of provider security practices.

5. Establish clear usage guidelines and incident response procedures for internal teams consuming AI 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.

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 AI Customers (AIC)

1. Assess vendor releases against internal risk tolerances; request compensating controls if applicable.

2. Maintain evidence that third-party fixes were applied within contractual SLAs.

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

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 AI Customers (AIC)

1. Deploy endpoint-detection & response (EDR) on corporate hosts that interact with AI systems; monitor for malicious macros, scripts or binaries.

2. Require suppliers to attest that anti-malware controls are in place and patches are applied within SLA.

3. Conduct staff awareness training on malicious-prompt and phishing techniques that target AI workflows.

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

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 AI Customers (AIC)

1. Identify and monitor vulnerabilities affecting consumed AI services by reviewing vendor advisories, CVEs, and threat intelligence.

2. Validate that providers perform vulnerability identification, assess potential business impact, and track identified issues 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.

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 AI Customers (AIC)

1. Scope threat models to business logic abuse and insider misuse within the customer environment.

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

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 AI Customers (AIC)

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

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 AI Customers (AIC)

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

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 AI Customers (AIC)

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

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 AI Customers (AIC)

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

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 AI Customers (AIC)

1. Establish and document a risk-based vulnerability prioritization process that incorporates business impact, data sensitivity (e.g., CUI, PII), and AI system criticality.

2. Incorporate AI-specific risk factors into vulnerability prioritization decisions by evaluating potential impacts to model integrity (such as model poisoning or tampering, exposure of sensitive training or inference data, risks associated with adversarial inputs influencing model outputs, and dependencies on third-party models, APIs, or datasets, etc.)

3. Define and enforce remediation timelines (SLAs) based on risk levels.

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

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 AI Customers (AIC)

1. Understand threat assumptions from upstream providers (SLA-based).

2. Conduct independent risk assessments considering: Integration into business workflows, Regulatory exposure (e.g., GDPR, AI Act).

3. Prioritize threats such as: Unauthorized output generation, Shadow AI usage.

4. Integrate AI-specific risks into enterprise GRC systems.

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

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 AI Customers (AIC)

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

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 AI Customers (AIC)

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

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 AI Customers (AIC)

1. Validate that vendor-supplied guardrails meet corporate policy; request compensating controls when regulatory or business-risk gaps are found.

[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 AI Customers (AIC)

1. Corporate Endpoint Policy: Define and enforce corporate endpoint policies for any device accessing the AI service, including minimum OS versions, anti malware requirements, and data protection controls.

2. Service Approval: Approve and manage the list of sanctioned AI applications and client software, using device based conditional access and UEM allow listing to block unapproved tools.

3. Inventory Management: Maintain a comprehensive inventory of user endpoints via integrated UEM and CMDB systems, conducting periodic reconciliations against HR and network logs.

4. Real Time Monitoring: Monitor endpoint compliance in real time and leverage automated remediation (patch deployment, device quarantine) for non compliant or compromised devices.

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

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 AI Customers (AIC)

1. Define which AI-based applications and cloud services are approved for use within the organization, especially those that will process or store the company’s data.

2. Specify acceptable sources for installing such applications on corporate endpoints (for example, only allowing downloads from verified vendors or internal app portals).

3. Prohibit or restrict the use of unapproved AI services or apps on company devices through policy and technical controls, to protect against data leakage or shadow IT.

4. Update the approved services list as needed, following a risk assessment for each new AI application before allowing it, and inform employees about which tools are sanctioned.

[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, review, and authorize new applications or services.

2. Maintain a single source of truth for the approved software/services list, with versioning and change logs to track additions or removals over time.

3. Automate enforcement of the approved list through UEM controls (e.g., application whitelisting, endpoint allow listing) to prevent unauthorized AI enabled application installations.

4. Review approval decisions bi-annually with cross stakeholder input to ensure lists remain aligned with evolving technical and security requirements.

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 AI Customers (AIC)

1. Develop and maintain a comprehensive endpoint compatibility matrix that specifies the approved hardware configurations, operating system versions, and required security software/agents for all endpoints, incorporating input from CSP, MP, OSP, and AP.

2. Validate new or changed endpoint configurations in a lab or pilot environment before enterprise-wide deployment via UEM (for example, test critical applications and tools with the latest OS updates or security patches to ensure compatibility).

3. Configure the UEM platform to enforce compatibility rules by detecting or blocking endpoints that do not meet the minimum required specifications or that run unapproved OS/software versions, until those devices are updated or removed.

4. Keep all stakeholders informed of current compatibility standards and upcoming changes (e.g., if support for an older OS version will be phased out), providing guidance and timelines so that each party can upgrade their systems accordingly.

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 AI Customers (AIC)

1. Establish and maintain a centralized inventory (e.g., in a CMDB) of all endpoints that handle organizational data, spanning devices managed by CSP, MP, OSP, AP, as well as internal AIC assets.

2. Maintain logs for changes made within inventory when a new asset is added or removed. Establish a process of reviewing the inventory of endpoints within centralized UEM /CMDB (Configuration Management Database) to keep the inventory updated and remove inactive endpoints.

3. Integrate the UEM platform with the asset inventory system to automatically update endpoint records as devices are onboarded, updated, or decommissioned, ensuring a single source of truth for all endpoint assets.

4. Deploy discovery agents or network scanning tools to identify any unrecognized or rogue devices on the network, and reconcile these findings against the authorized inventory list.

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

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 AI Customers (AIC)

1. Integrate the UEM with patch management systems, anti-malware platforms, and configuration management databases to automatically enforce security baseline requirements on all endpoints.

2. Define role-based UEM profiles for each stakeholder group (CSP, MP, OSP, AP, as well as internal AIC users) so that each category of endpoint receives the appropriate security controls and authorized applications tailored to their role.

3. Enable real-time compliance monitoring and alerting in the UEM for critical security deviations on endpoints (e.g., detect immediately if a device is missing a high-priority patch or if antivirus is disabled) and ensure alerts are acted upon quickly.

4. Conduct routine compliance reporting (e.g., monthly) across all endpoint categories and review these reports to identify any patterns of non-compliance. Follow up with the responsible stakeholder for each issue to ensure that any non-compliant devices are brought back into compliance in a timely manner.

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

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 AI Customers (AIC)

1. Enforce enterprise-wide policies that all AI Customer organization endpoints (employee laptops, tablets, and smartphones) automatically lock after a short period of inactivity to reduce the window of opportunity for unauthorized access.

2. Configure the corporate UEM/MDM solution to deploy and enforce uniform lock settings: for example, require all managed devices to auto-lock after 5 minutes idle and mandate a secure unlock method (strong password, biometrics) before access is restored.

3. Restrict users from altering lock screen settings – the timeout duration and lock requirement should be non-modifiable by end users on managed devices. Any attempt to disable or delay auto-lock (where possible) should be blocked or logged for review.

4. Conduct regular compliance audits using the UEM reports to identify any devices not adhering to the auto-lock policy (such as BYOD devices that might not have the policy applied) and promptly remedy those by enrolling them in management or revoking their access to corporate resources until compliant.

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

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 AI Customers (AIC)

1. Route all enterprise endpoint changes through organizational change management processes. User workstations, especially those used by departments handling sensitive AI outputs or data, should receive updates on a planned schedule with IT oversight rather than users self-updating software unpredictably.

2. Evaluate patches (particularly critical security patches) promptly and, if urgent, use an expedited but still controlled change process to deploy them. For example, if there’s a zero-day exploit targeting endpoint software, get approval from the change board for an emergency rollout to all PCs and document this exception process after the fact.

3. Communicate device changes to end users in advance. If the IT team is pushing a new version of an AI client application or enforcing an OS upgrade on all machines, provide notice to employees about when it will happen, what they need to do (e.g., leave devices on overnight), and whom to contact if something goes wrong.

4. Post-implementation, gather feedback and verify success. After a wide-scale change like a corporate laptop patch deployment, review automated deployment reports for failures, and survey a small set of users or IT support tickets to ensure no major productivity issues arose. Record these results in the change management log to inform future changes and demonstrate due diligence.

[Applicable to all actors except CSP]

1. Align OS 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.

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 AI Customers (AIC)

1. Require full-disk encryption on all enterprise endpoints through corporate policy. Every laptop and desktop in the AI customer organization, especially those used by executives, analysts, or others accessing AI-generated sensitive data, must have encryption enabled to protect data at rest.

2. Utilize the organization’s MDM/endpoint management to enforce and monitor encryption. The system should only mark a device as “compliant” if its storage is encrypted. For BYOD devices accessing company email or AI systems, enforce conditional access that allows access only if the device reports an encrypted state.

3. Manage encryption keys carefully: integrate with directory services or MDM for key escrow so that if employees forget their passcodes or leave the company, IT can recover the device data. Regularly test a sample of recovery keys to ensure they have been recorded correctly and can unlock the drives when needed.

4. Educate employees about the importance of device encryption. Let them know that if their device is lost or stolen, encryption is what prevents data leakage. This can improve compliance (for example, employees will be less likely to attempt to circumvent encryption for convenience if they understand its value) and ensure they report lost devices immediately knowing the data is protected.

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

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 AI Customers (AIC)

1. Roll out a standardized anti-malware/EDR agent to all user endpoints in the organization, configured via policy to automatically receive updates and actively scan for threats. Users’ machines should be uniformly protected, whether they are on the corporate network or off (agents should be cloud-managed to get updates anywhere).

2. Prevent users from uninstalling or disabling the endpoint protection. Use management policies to gray out those options or immediately re-enable protection if it’s found off. The idea is to ensure that even tech-savvy users or those who feel a slowdown cannot opt out of security: exceptions should be extremely rare and handled by IT with compensating controls.

3. Set the anti-malware to scan external media and new files in real time. For example, if an employee downloads a file from an AI service or plugs in a USB drive with data, the agent should automatically scan those for malicious content to prevent infection or spread within the company.

4. Tie the anti-malware status into access control if possible. For instance, utilize network access control or zero-trust gateway checks that confirm an endpoint has an active, up-to-date anti-malware agent before allowing it to connect to internal applications or data. If a device falls out of compliance (e.g., definitions out of date by more than a set threshold), restrict its network access until it’s back in compliance to reduce risk.

[Applicable to all actors except CSP]

1. Deploy and maintain anti-malware/EDR agents on all endpoints across MP, OSP, AP, and AIC, ensuring every device in the AI supply chain has real-time threat detection and prevention in place with up-to-date signatures or machine learning models.

2. Leverage UEM to continuously monitor the health of endpoint anti-malware (agent installed and running, definitions current, scans performed); configure automated alerts to all relevant security teams if any device falls out of compliance or reports a malware infection.

3. Standardize malware protection configurations and response across organizations, for example, align on similar quarantine settings and critical malware alert thresholds, so that a threat detected on one stakeholder’s endpoint triggers comparable protective actions elsewhere.

4. Share threat intelligence and coordinate incident response for malware attacks: if one stakeholder’s endpoint encounters a new malware or indicator of compromise, quickly inform the others and distribute IoCs or updates, enabling all parties to bolster their defenses and respond in a unified manner.

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 AI Customers (AIC)

1. Enforce host-based firewall usage on all corporate endpoints by policy. Users should not have the ability to turn off their device’s firewall. Set the default configuration to a secure state (block inbound, allow necessary outbound) across the enterprise, and manage any needed exceptions centrally.

2. Develop a corporate firewall policy profile that is deployed to all machines. For example, allow outbound web browsing and email, but block ports commonly abused by malware (like SMB outbound to the internet, or RPC). Inbound should be mostly closed except for specific cases like IT remote assistance tools which can be permitted from IT subnet or via management software.

3. Implement network location awareness if available: when laptops are off the corporate network (on public Wi-Fi), automatically have them switch to an even more restrictive firewall stance (perhaps even blocking certain outbound traffic except through a VPN). Many systems support different firewall profiles (Private vs Public networks); configure these to maximize protection outside the office.

4. Periodically audit a sample of user machines to ensure firewall rules haven’t been altered beyond the centrally mandated ones. Although users shouldn’t be able to change them if policies are correctly applied, verifying through an audit (or via the centralized console comparing actual rules vs. expected) helps catch any misconfigurations. Use these audits to also update the policy if needed (e.g., if you find many users legitimately need a certain type of connection that was initially blocked, adjust the corporate policy rather than everyone doing workarounds).

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

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 AI Customers (AIC)

1. Roll out a comprehensive DLP program on all corporate endpoints to protect the organization’s data, including any data received from using AI services or sensitive outputs generated by AI. Classify data such as “Confidential – AI Derived” if, for example, the AI produces sensitive analytics or decisions, so that this data is covered by DLP rules just like other confidential business data.

2. Set DLP policies to cover common exfiltration vectors in the enterprise: printing, USB copying, upload via web, email, instant messaging, and even screen captures if possible. For instance, if an employee attempts to screenshot a sensitive internal AI dashboard and paste it into a chat, a robust DLP agent could detect the sensitive content in that image and block it.

3. Use DLP to enforce policies around AI usage: if the company has rules like “Do not input client confidential data into external AI tools,” the DLP could assist by monitoring clipboard or keystrokes for telltale signs (like pasting a client record into a web chatbot) and warning the user or blocking the action. This blends data protection with acceptable use enforcement for AI.

4. Regularly update the DLP dictionaries and rules as new sensitive data types emerge. If the AI systems start handling a new category of data (e.g., health data, financial data), ensure the DLP is configured to recognize and protect that. Also review DLP incident reports at a management level to identify trends – for example, if marketing is frequently tripping DLP by sending out certain reports, maybe they need a sanctioned process to do so or a tweak to the rules if it’s a false positive.

[Applicable to all actors except CSP]

1. Deploy endpoint Data Loss Prevention agents or content filtering tools on all devices handling sensitive AI data across MP, OSP, AP, and AIC, so that every organization’s endpoints have controls to detect and block unauthorized data transfers (e.g., source code, training datasets, customer data).

2. Align DLP policies and classification rules among stakeholders by defining what constitutes sensitive data for the AI project in a shared manner – for example, agreeing to block certain file types or patterns (API keys, model weights, PII) from being emailed or moved to external drives – and implementing those rules consistently on all endpoints.

3. Use UEM or integrated security management to ensure DLP software is installed, active, and updated on every managed endpoint; share high-level DLP compliance status or metrics between organizations (such as number of incidents or agents offline) to maintain collective visibility into data protection coverage.

4. Establish a cross-organization incident response process for DLP alerts: if one stakeholder’s DLP system flags a potential data leakage event involving shared AI assets, that stakeholder must promptly notify the others and collaboratively investigate and contain the incident, ensuring that data loss threats are addressed with everyone’s awareness.

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 AI Customers (AIC)

1. Utilize geo-location on all company-owned mobile endpoints to protect corporate data. Company smartphones and laptops often have this feature built-in (e.g., “Find My Device” services); integrate those with IT’s management so that if a device that can access AI systems goes missing, IT can attempt to locate it immediately.

2. Make lost device reporting easy for employees and part of security policy. Employees should know that if they misplace a device, reporting it promptly is crucial. Once reported, IT should without delay activate tracking and retrieval measures. Speed is important: a device reported within an hour of loss and tracked has a much higher chance of recovery than one reported days later.

3. Leverage geo-location in combination with law enforcement for theft scenarios. If a device is stolen, provide its real-time location info to law enforcement rather than trying to recover it alone. Ensure that the local police in areas of operation know that your company may reach out with such requests so they treat them seriously and urgently.

4. Periodically remind and reassure staff about the device tracking policy: for instance, send an annual notice that “if you lose your corporate device, we have tools to help find it or erase it: here’s what you need to do…” This not only reinforces awareness but also signals that the company is actively prepared for such events (making employees more likely to report quickly rather than hesitating or attempting their own search first).

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

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 AI Customers (AIC)

1 Leverage remote wipe for all enterprise devices to prevent data loss when devices go astray. Company laptops and phones issued to employees should be configured such that IT can send a wipe command over the internet or via the mobile network that will erase company email, documents, and any locally cached AI service data (reports, etc.) on that device.

1. Develop a policy on when to use full device wipe vs. selective wipe. For corporate-owned devices, a full wipe (factory reset) might be standard for loss. For employee-owned devices under BYOD that contain a mix of work and personal data, opt for a selective wipe that only removes corporate data (utilizing containerization or OS BYOD features). Outline these in the BYOD agreement so users are aware of what could happen if their device is lost or they leave the company.

2. Train the IT help desk and security team in executing remote wipes swiftly. Time is often critical; the sooner a lost device is wiped, the less chance its data can be compromised. Ensure that after business hours there is an on-call capability or an automated way (perhaps through a self-service portal or pre-approval) to initiate wipes for urgent cases like a traveling employee losing a laptop at 2 AM.

3. Follow up a remote wipe with a thorough review. Confirm via the management console that the wipe command was received and the device is confirmed erased. If confirmation isn’t received (device never came online), assume worst-case and escalate the incident (monitor accounts for misuse, etc.). If it is confirmed, document the incident — what happened, when wipe was done, and outcome — to improve future responses and for compliance records if needed (especially if regulated data was on the device and authorities or clients need notification of the protective actions taken).

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

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 AI Customers (AIC)

1. Impose endpoint security requirements on any third-party that connects to your systems. If you have consultants who log into your AI analytics dashboard or an outsourced IT support that remotes into employee machines, define minimum security standards for their devices (e.g., “Consultant PCs must run our approved VPN with MFA, have an active EDR agent, and lock screen policies matching our own”). Ideally, bake these into contracts or agreements.

2. Provide secure access methods for external parties interacting with your data. For example, if an external marketing firm needs some AI-generated data to work with, consider giving them access through a secured web portal or VDI that you control, rather than sending them raw data files to open on their laptops. In that portal/VDI, prevent copy-paste or file download if possible, to keep the data within your environment.

3. Use conditional access and identity federation with device compliance for third-parties. If your directory supports marking devices as compliant, require that third-party accounts can only log in if their device is registered and meets compliance checks. For a one-time consultant, you might instead set them up with an account on a hardened cloud VM they must use, achieving a similar effect.

4. Continuously evaluate the risk of third-party endpoints. Keep track of which third parties have access to what systems and data. Perform annual (or more frequent) risk reviews for each vendor: how do they manage security? Have they had breaches? Are they still necessary to have access? This can lead to decisions like terminating access for a vendor that no longer needs it or enhancing requirements for one that handles more sensitive data than before. By treating third-party devices as an extension of your network, you maintain a high security bar for your overall ecosystem.

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