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 Orchestrated Service Providers (OSP)

Policy Scope

1. Audit and assurance policies covering AI model deployment infrastructure, scaling mechanisms, API integrations, resource management, and operational monitoring of AI services.

[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. Establish 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 (GDPR, CCPA, ISO 27001/42001). 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 Orchestrated Service Providers (OSP)

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.

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 Orchestrated Service Providers (OSP)

[Orchestrated Service Provider (OSP)] Implementation best practices for this actor include (but are not limited to):

1. Prioritize assessments of infrastructure and deployment risks, including model serving security, multi-tenancy isolation, and operational resilience.

2. 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. Implement monitoring systems to track risk levels and trigger reassessments as needed.

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 Orchestrated Service Providers (OSP)

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

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 Orchestrated Service Providers (OSP)

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

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 Orchestrated Service Providers (OSP)

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

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 Orchestrated Service Providers (OSP)

1. Implement application and interface security policies covering the orchestration and management of AI services, including secure API integrations, runtime environment protections, and monitoring of application interfaces.

2. Policies should ensure secure interaction between orchestrated AI components and external applications.

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

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 Orchestrated Service Providers (OSP)

1. Deployment and operation baselines: establish baseline security requirements for the deployment and operation of AI services, including secure provisioning, configuration management, and access controls.

2. Runtime security monitoring and incident response baselines: define baseline requirements for runtime security monitoring, logging, and incident response processes.

3. API security baselines: specify API security baselines, covering authentication, authorization, input validation, and rate limiting for prompt detection and mitigation of threats to protect against unauthorized access and abuse of AI services where applicable.

4. Document the operational security baseline for the minimum acceptable security posture, and maintain it in alignment with the MP’s baseline and industry best practices.

5. Collaboration with MP and AP: collaborate with the MP and AP to ensure the baseline is consistently implemented across the AI supply chain to ensures the operational baseline is integrated with other security measures.

[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 Orchestrated Service Providers (OSP)

1. Define Operational metrics: define operational security metrics, such as service availability, response time, error rates, and security incident counts to provide visibility into the security and performance of AI services in production.

2. Automated monitoring and alerting: implement automated monitoring and alerting systems to track these metrics in real-time to ensure proactive identification and response to security incidents.

3. SLAs and thresholds: establish service-level agreements (SLAs) and thresholds for each metric based on business and security requirements to ensure services meet business and security expectations.

4. Regular reporting: generate regular reports on operational security metrics and share them with relevant stakeholders, including AP and AIC to keep stakeholders informed and supports collaborative problem-solving.

5. Continuous review and update: continuously review and update metrics to ensure alignment with evolving business objectives and security requirements to ensure operational metrics remain relevant and effective over time.

6. Define operational security metrics for AI services (e.g., availability, response time, error rates, security incidents).

[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 Orchestrated Service Providers (OSP)

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

1. Extend the secure SDLC process to cover the deployment, operation, and scaling of AI services.

2. Secure Deployment and configuration management practices: Implement secure configuration management practices, including version control, immutable infrastructure, and automated deployment pipelines.

3. Secure Key Management: Establish a secure key management system to protect sensitive data, such as API keys, credentials, and certificates.

4. Implement runtime application security controls, such as authentication, authorization, and input validation, to protect AI services from unauthorized access and abuse.

5. Continuous monitoring and incident response: Monitor orchestrated AI services for security events, anomalies, and performance issues, and establish incident response procedures to promptly address any security incidents.

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

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 Orchestrated Service Providers (OSP)

1. Implement automated security testing for AI services during the deployment, upgrade, and release processes to ensure consistent security validation.

2. Develop tests to validate the secure configuration and hardening of AI service infrastructure, including containers, APIs, and cloud resources to mitigate the risk of misconfigurations and vulnerabilities.

3. Automate vulnerability scanning and penetration testing to identify and remediate security weaknesses in AI services to ensure identification and remediation of security weaknesses proactively.

4. Establish a gated release process that requires successful completion of automated security tests before promoting AI services to production to ensure prevention of the deployment of insecure AI services to production environments.

5. Continuously monitor AI services for security issues and anomalies, and trigger automated tests to validate the effectiveness of remediation actions to maintain the security posture of AI services over time.

[All Actors]

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

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

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

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

AIS-06: Secure Application Deployment

Control Specification

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

Shared Implementation Guidelines

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

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

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

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

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

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

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

Implementation Guidelines for Orchestrated Service Providers (OSP)

Policy Scope:

1. Secure deployment strategies for orchestrated AI services, including automated deployment of service configurations, secure API integrations, and runtime environment protections. Policies should address secure scaling, load balancing, and monitoring of deployed services to ensure resilience and compliance.

2. Automate orchestration workflows using tools like Kubernetes or service meshes to enforce security and compliance during deployment.

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

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 Orchestrated Service Providers (OSP)

Policy Scope: Remediation processes for vulnerabilities in orchestrated AI services, including API integrations, runtime environments, and service configurations. Policies should ensure secure scaling, load balancing, and monitoring of remediated services to prevent re-exploitation. Automate vulnerability remediation using orchestration tools (e.g., Kubernetes, service meshes) and validate fixes to ensure compliance and resilience.

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

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 Orchestrated Service Providers (OSP)

Policy Scope:

API security policies cover orchestration and management of AI services, including secure API integrations, runtime protections, and monitoring of orchestrated API interactions. Address authorization flaws in scaling/load balancing APIs, key management and rotation for service APIs, and testing for vulnerabilities in multi-component interactions.

[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 emerging risks associated with AI service like requirements of strong access controls using RBAC (role-based access controls) for APIs accessing training data, model parameters, or inference services.

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

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

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

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

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

AIS-09: Input Validation

Control Specification

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

Shared Implementation Guidelines

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

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

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

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

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

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

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

Implementation Guidelines for Orchestrated Service Providers (OSP)

Policy Scope: Input validation policies covering the orchestration and management of AI services, including validation of API inputs, runtime configurations, and inter-service data flows. Policies should ensure protection against adversarial patterns (e.g., API abuse), failure patterns (e.g., orchestration misconfigurations), and unwanted behavior (e.g., service disruptions). Automate input validation using orchestration tools (e.g., Kubernetes, service meshes) and monitor for compliance with organizational policies.

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

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

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

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

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

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

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

AIS-10: Output Validation

Control Specification

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

Shared Implementation Guidelines

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

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

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

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

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

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

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

Implementation Guidelines for Orchestrated Service Providers (OSP)

Policy Scope: Output validation policies covering orchestrated AI services, including API responses, runtime metrics, and inter-service data outputs. Policies should ensure protection against adversarial patterns (e.g., malicious API outputs), failure patterns (e.g., orchestration errors), and unwanted behavior (e.g., service disruptions). Automate output validation using orchestration tools (e.g., container orchestration platforms, service meshes) and monitor for compliance with organizational policies.

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

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

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

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

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

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

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

AIS-11: Agents Security Boundaries

Control Specification

Establish security boundaries for agents.

Shared Implementation Guidelines

[All Actors]

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

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

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

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

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

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

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

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

Implementation Guidelines for Orchestrated Service Providers (OSP)

1. Enforce runtime policies in pipelines (e.g., admission controllers) that block workloads breaching boundary rules; log violations, trigger real-time alerts/tickets, and surface aggregated trends.

[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 Orchestrated Service Providers (OSP)

Policy Scope:

Model development policies cover orchestration tools and scripts used to manage AI model deployment and scaling. Ensure version control for orchestration code (e.g., Kubernetes manifests), code reviews for automation scripts, and static analysis of orchestration logic within the SDLC. Address secure handoffs to APs or CSPs during runtime.

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

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

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

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

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

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

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

AIS-13: AI Sandboxing

Control Specification

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

Shared Implementation Guidelines

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

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

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

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

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

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

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

Implementation Guidelines for Orchestrated Service Providers (OSP)

Policy Scope:

Sandboxing policies cover tools and plugins in orchestrated AI services (e.g., scaling tools, monitoring plugins). Implement isolated environments (e.g., container pods with strict namespaces) to prevent interactions with critical orchestration systems and limit lateral movement across CSPs, MPs, or APs.

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

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

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

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

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

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

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

AIS-14: AI Cache Protection

Control Specification

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

Shared Implementation Guidelines

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

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

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

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

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

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

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

Implementation Guidelines for Orchestrated Service Providers (OSP)

Policy Scope:

Cache security policies cover cache systems in orchestrated LLM services (e.g., distributed caches, session caches). Implement encryption for cached orchestration data, strict access controls for scaling/monitoring processes, and mechanisms to clear sensitive LLM-related data from fast memory, mitigating risks of lateral movement or poisoning across CSPs, MPs, or APs.

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

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

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

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

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

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

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

AIS-15: Prompt Differentation

Control Specification

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

Shared Implementation Guidelines

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

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

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

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

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

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

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

Implementation Guidelines for Orchestrated Service Providers (OSP)

Policy Scope:

Input distinction policies cover orchestrated AI services (e.g., multi-model pipelines, scaling workflows). Implement formatting techniques (e.g., tagged inputs) and templates for inputs passed between orchestrated components, ensuring clarity in user/system/data distinctions across CSPs, MPs, or APs. Prevent ambiguity in distributed instruction handling.

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

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

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

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

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

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

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

BCR: Business Continuity Management and Operational Resilience

BCR-01: Business Continuity Management Policy and Procedures

Control Specification

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

Shared Implementation Guidelines

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

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

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

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

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

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

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

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

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

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

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

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

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

Implementation Guidelines for Orchestrated Service Providers (OSP)

[Policy Scope] The OSP is accountable for sustaining seamless integration and coordination of multiple AI services. This includes:

• Build structured support plans to address failures in processing pipelines, routing logic, or inter-service communication.

• Record configuration baselines and routing logic to enable rapid restoration.

• Secure leadership endorsement for continuity strategies and platform-wide preparedness.

• Keep relevant parties informed about operational dependencies and fallback mechanisms.

• Design systems to respond dynamically in the event of upstream failure or degraded model performance.

• Perform simulated incident runs to confirm the effectiveness of layered protections.

• Reassess and realign strategies annually, or when major components are introduced or restructured.

• Designing and aligning operational safeguards tailored to orchestration layers and interdependent workflows.

• Formally recording resilience standards and seeking organizational validation.

• Disseminating continuity plans to relevant teams and affiliates.

• Putting redundancy, load balancing, and failover mechanisms into action.

• Continuously inspecting orchestration performance under duress and refining mitigation tactics.

• Reassessing resilience protocols following major platform updates or partnership transitions, and at a minimum, once annually.

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

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 Orchestrated Service Providers (OSP)

Policy Scope:

1. Evaluate resilience of connection points between integrated services.

2. Analyze transaction integrity risks during partial system failures.

3. Assess risks related to asynchronous operations and transaction reconciliation.

4. Calculate business impact of different connection failure scenarios.

5. Document data consistency requirements during recovery operations.

6. Establish alternative routing capabilities for critical information flows.

[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 Orchestrated Service Providers (OSP)

[Policy Scope]

• Preserve essential data flows despite component interruptions by implementing circuit breaker patterns to isolate failing components.

• Maintain transaction integrity during partial system availability by enabling transaction logging, which help in reconstruction of in-flight operations.

• Enable progressive service restoration based on priority and dependency-aware service restoration sequencing.

• Defined verification checkpoints during restore phase.

[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 Orchestrated Service Providers (OSP)

[Policy Scope]

• Document all service connections with criticality ratings.

• Identify maximum acceptable interruption periods for each pathway.

• Implement circuit breakers preventing problem propagation.

• Develop alternative routing capabilities for essential transactions.

• Develop reconciliation procedures ensuring data consistency after disruptions.

• Create dependency-aware restoration sequencing for connected services.

• Conduct connection failure simulations across integration points.

• Validate successful rerouting of critical information flows.

[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 Orchestrated Service Providers (OSP)

[Policy Scope]

• Create detailed maps showing integration connections between services and document workflow configurations with decision logic and routing rules.

• Preserve authentication frameworks and access dependency information.

• Maintain configuration repositories with detailed parameter documentation.

• Develop progressive restoration sequences for complex orchestration environments.

• Create process models showing orchestration steps with decision points.

• Document expected performance parameters and timeout thresholds.

• Document reconciliation procedures for interrupted transactions.

[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 Orchestrated Service Providers (OSP)

[Policy Scope]

• Component Isolation Drill: Practice containing failing services without system-wide impact.

• Rerouting Challenge: Test alternative pathways when primary connections fail. Simulate failure signals from integrated components

• Gradual Restoration Sequence: Validate priority-based service resumption. Practice rebuilding orchestration flows from backup configurations.

• Coordination Breakdown: Exercise communication when usual channels unavailable. Conduct exercises with artificially limited communication channels

[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 Orchestrated Service Providers (OSP)

[Policy Scope]

1. Key Stakeholder Matrix

   • Internal Teams: Integration specialists, operations center, and support personnel.

   • Direct Customers: Application providers and enterprise intelligence consumers.

   • Upstream Partners: Model providers and specialized service vendors.

   • Downstream Recipients: End-user systems dependent on orchestrated AI systems.

2. Communication Framework :

   • Develop service dependency maps with communication routing rules and status dashboards showing integration point health.

   • Configure bidirectional alert mechanisms for upstream and downstream
     notifications.

   • Design templates focusing on transaction impact and routing changes.

   • Establish coordination protocols for multi-component incidents

   • Create technical translation guides for different stakeholder perspectives

3. Testing & Maintenance :

   • Conduct integration point communication exercises with connected services.

   • Review cross-entity incident communication effectiveness after actual events.

   • Validate notification reach through periodic contact verification tests.

[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 Orchestrated Service Providers (OSP)

[Policy Scope]

1. Critical Assets Backup Strategy:

   • Implement comprehensive preservation of integration configurations and connection mappings.

   • Establish secure repositories for workflow definitions and orchestration rules.

   • Maintain secure backups of transaction state information and processing histories.

2. Connection Configuration Backup:

   • Deploy automated daily snapshots of integration definitions and endpoints.

   • Implement configuration-as-code with version control for all connection specifications.

   • Create secure storage for authentication credentials with appropriate encryption.

3. Workflow State Safeguards:

   • Establish transaction logging with point-in-time recovery capabilities.

   • Create replicated storage for in-flight operation states.

   • Implement backup rotation ensuring adequate historical depth for complex workflows.

4. Recovery Readiness:

   • Develop service reconnection procedures with verification checkpoints.

   • Create isolated testing environments for configuration restoration validation.

   • Establish dependency maps guiding restoration sequence planning.

[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 Orchestrated Service Providers (OSP)

[Policy Scope]

1. Response Structure:

   • Establish cross-functional team including integration specialists and service owners.

   • Designate coordination leads managing communication with connected services.

   • Create clear decision authority for routing changes during disruptions.

   • Develop responsibility matrices for various failure scenarios.

2. Incident Classification:

   • Implement tiered response levels based on connection integrity impacts.

   • Define activation thresholds for different recovery strategies.

   • Create assessment procedures for transaction consistency evaluation.

   • Establish criteria for implementing alternative routing pathways.

3. Response Phase:

   • Deploy automated service mapping to identify affected connections.

   • Implement transaction state analysis determining data consistency impacts.

   • Activate circuit breaker patterns containing cascading failures.

   • Deploy pre-configured routing alternatives for critical services.

   • Execute connectivity testing identifying viable alternative paths.

   • Execute service verification before resuming normal message volumes.

   • Activate transaction reconciliation procedures ensuring data consistency.

4. Post-Incident Activities:

   • Conduct flow analysis identifying areas needing resilience improvement.

   • Update orchestration configurations based on performance insights.

   • Document effective rerouting patterns for future scenarios.

[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 Orchestrated Service Providers (OSP)

[Policy Scope]

1. Create scenarios targeting connection failures and transaction integrity challenges.

2. Develop simulation approaches for authentication disruptions and routing failures.

3. Establish exercise progression exploring increasingly complex integration issues.

4. Design specialized drills testing alternative routing and reconciliation procedures.

5. Develop decision-making simulations for transaction recovery situations.

6. Conduct isolated testing of circuit breaker implementations in controlled environments.

7. Practice transaction reconciliation procedures following simulated disruptions.

8. Organize full-scale simulations involving upstream and downstream partners.

[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 Orchestrated Service Providers (OSP)

[Policy Scope]

1. Identify connection pathways requiring uninterrupted availability.

2. Deploy redundant API gateways with automated traffic rerouting.

3. Evaluate message handling systems needing redundant capacity.

4. Deploy parallel message queue systems with cross-replication.

5. Assess authentication mechanisms requiring alternative implementations.

6. Determine state management systems needing distributed resilience.

7. Deploy mirrored monitoring infrastructure with independent alerting.

8. Implement redundant configuration stores with multi-region presence.

[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 Orchestrated Service Providers (OSP)

[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 Orchestrated Service Providers (OSP)

1. Apply testing strategies to deployment pipelines, ensuring that configuration and orchestration changes are validated before release.

2. Use automated testing and canary deployments to validate behavior under real workloads without exposing users to risk.

3. Ensure rollback procedures are tested and functional during CI/CD pipeline runs.

4. Document and track testing results related to orchestration workflows, component integration, and versioning policies.

[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 Orchestrated Service Providers (OSP)

1. Assess risks introduced by changes to orchestration pipelines, deployment logic, and environment configurations.

2. Use pipeline monitoring to track change impact and detect cascading failures across components.

3. Designate engineering owners for rapid triage and recovery in case of orchestration-related issues.

[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 Orchestrated Service Providers (OSP)

1. Maintain secure baseline templates for orchestration environments (e.g., IaC/GitOps templates, Helm charts, Terraform modules, Kubernetes manifests).

2. Ensure baselines define security posture (e.g., network policies, RBAC rules, resource limits) across orchestrated deployments.

3. Validate orchestration baselines through peer reviews before making them available for 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 Orchestrated Service Providers (OSP)

1. Use infrastructure-as-code (IaC) and GitOps practices to implement configuration changes with automated approval gates.

2. Require pre-deployment testing (e.g., dry runs, sandbox validation) for all orchestration logic modifications.

3. Maintain rollback procedures for orchestration failures, including automated reversion of broken changes.

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

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 Orchestrated Service Providers (OSP)

1. Establish and maintain baseline orchestration artefacts, (e.g., Kubernetes manifests, Helm charts, deployment templates, CI/CD pipeline configurations, and resource policies), that define the approved configuration and deployment state of AI system infrastructure.

2. Monitor orchestration environments for unauthorized or unapproved modifications to orchestration logic (e.g., runtime overrides or drift, dynamic scaling policies).

3. Ensure orchestration-related deviations from approved baselines, generate audit logs and alerts, and trigger appropriate remediation actions such as rollback to a previously approved configuration or initiation of change management procedures.

4. Manage orchestration configurations using version-controlled infrastructure-as-code or DevOps workflows where feasible, ensuring that changes to orchestration logic are traceable, reviewed, and aligned with approved configuration baselines.

[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 Orchestrated Service Providers (OSP)

1. Monitor pipeline and cluster events (deployment failures, scaling anomalies, config drifts) and auto-trigger rollback or quarantine when baselines are violated.

2. Expose deviation metrics in dashboards and send webhook notifications to the responsible DevOps or SecOps channels.

[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 Orchestrated Service Providers (OSP)

1. Provide a controlled break-glass mechanism in pipeline definitions that can bypass policy checks (e.g., image-signing) when two authorised approvers sign off, and that automatically expires or is removed after a defined window.

2. Capture all pipeline-level exceptions in an immutable audit log.

[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 Orchestrated Service Providers (OSP)

1. Maintain version-controlled baselines for orchestration workflows (e.g., Kubernetes manifests, Helm charts, CI/CD configs).

2. Ensure deployment pipelines include automatic rollback triggers based on failed health checks, policy violations, or regression metrics.

3. Test rollback procedures regularly as part of CI/CD pipeline health validation.

[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 Orchestrated Service Providers (OSP)

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 Orchestrated Service Providers (OSP)

Role Specific

1. Define and assign encryption-related responsibilities for service orchestration layers, covering tasks such as securing inter-service tokens, encrypted configuration files, and workflow metadata.

2. Implement automated checks to enforce role assignments during workflow creation or modification, ensuring cryptographic controls are applied consistently across orchestrated services.

3. Validate that orchestration role assignments align with upstream and downstream encryption responsibilities through integration testing and system-level security reviews.

[All Actors] Applies to all Roles (Baseline) before application of role context:

1. Establish and document policies and procedures for Cryptography, Encryption, and Key Management.

2. Approve the policies and procedures through formal governance processes (e.g., security committee, CISO).

3. Communicate the policies and procedures to all relevant stakeholders.

4. Apply the approved policies and procedures to all systems, services, and processes under the role’s control.

5. Evaluate the effectiveness of policy and procedure implementation using internal audits, technical reviews, and encryption control validations.

6. Review and update the policies and procedures at least annually, or when significant system, model, or regulatory changes occur.

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 Orchestrated Service Providers (OSP)

Role Specific

1. Enforce encryption policy compliance by integrating checks into orchestration workflow definitions, preventing deployment of services that lack approved encryption configurations.

2. Configure service mesh and broker-level policies to automatically apply encryption to all inter-service traffic, using mutual TLS and key rotation where supported.

3. Periodically audit orchestration metadata and workflow state storage to confirm that sensitive scheduling data, tokens, and runtime logs are encrypted according to approved standards.

[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 Orchestrated Service Providers (OSP)

Role Specific

1. Embed encryption algorithm validation into orchestration templates and deployment manifests, ensuring all services launched through the platform conform to approved cryptographic standards.

2. Configure service meshes and message brokers to enforce approved algorithms (e.g., TLS 1.3, AES-256) for both control plane and data plane traffic, with automated alerts on protocol downgrade attempts.

3. Conduct periodic validation of orchestrated service environments to detect weak or legacy encryption usage in transient artifacts, such as secrets, runtime tokens, and ephemeral storage volumes.

[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 Orchestrated Service Providers (OSP)

Role Specific

1. Integrate encryption change tracking into orchestration manifests and CI/CD pipelines, enforcing pre-deployment validation of updated cryptographic settings for service-to-service communications.

2. Maintain documentation of all encryption-related changes applied to orchestration frameworks, including service mesh configurations, broker updates, and metadata encryption policies.

3. Schedule periodic service graph audits to confirm that updated encryption configurations are applied consistently across interconnected services and have not introduced exposure points.

[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 Orchestrated Service Providers (OSP)

Role Specific

1. Conduct service dependency mapping before cryptographic changes to identify potential disruptions in inter-service communication and inform cost-benefit tradeoffs.

2. Include platform operations and service integration leads in change review boards to assess operational impact and validate feasibility of proposed updates.

3. Analyze orchestration workflow metrics post-implementation to verify whether the expected performance and security benefits justified the costs and complexity introduced.

[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 Orchestrated Service Providers (OSP)

Role Specific

1. Perform encryption-specific risk mapping across orchestration layers, identifying threats related to token exposure, metadata leakage, and inter-service protocol mismatches.

2. Integrate risk treatment plans into orchestration configuration templates, enforcing secure defaults for encryption protocols and key handling practices.

3. Deploy continuous monitoring tools to detect policy violations or weak cryptographic configurations in live orchestration environments, triggering automated remediation when feasible.

[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 Orchestrated Service Providers (OSP)

Role Specific

1. Configure orchestration pipelines to preserve AIC key boundaries during service chaining, ensuring that key ownership is respected across encrypted inter-service data exchanges.

2. Integrate CSP key management APIs into orchestration templates to allow automated enforcement of AIC-managed key policies during workflow execution.

3. Audit service mesh and control plane configurations to detect any overrides of AIC encryption controls, verifying that encryption operations consistently defer to customer-held keys where supported.

[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 Orchestrated Service Providers (OSP)

Role Specific

1. Implement automated orchestration-layer audit hooks that log encryption enforcement, key usage, and service handoff validations during runtime across interconnected workflows.

2. Conduct recurring service graph audits to identify breaks in encryption enforcement, insecure inter-service communication, or gaps in key boundary enforcement.

3. Maintain a repository of orchestration audit artifacts, including service logs, key transaction records, and policy compliance snapshots, to support internal reviews and external assessments.

[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 Orchestrated Service Providers (OSP)

Role Specific

1. Integrate key generation modules within orchestration services that rely exclusively on certified libraries and enforce algorithm and entropy settings via orchestration templates.

2. Perform orchestration-layer audits to verify that keys used for workflow coordination, token encryption, and secure routing are generated with approved cryptographic primitives.

3.Monitor orchestration logs and telemetry to detect fallback to insecure key generation practices, triggering remediation workflows for non-compliant components.

[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 Orchestrated Service Providers (OSP)

Role Specific

1. Enforce key-scoping rules in orchestration templates to assign distinct keys for securing service communication, API access, and control plane operations, avoiding any overlap in purpose.

2. Integrate policy-as-code validations into deployment pipelines to detect and reject configurations where keys are assigned to multiple orchestration functions.

3. Audit orchestration layers periodically to verify that each cryptographic key is used exclusively within its designated workflow component and not reused across services or layers.

[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 Orchestrated Service Providers (OSP)

Role Specific

1. Integrate cryptoperiod-based key rotation into orchestration manifests and service mesh configurations, ensuring service-to-service communication keys are refreshed within defined lifespans.

2. Coordinate key rotation events across interdependent orchestration components, triggering service reloads or configuration updates to apply new keys without interrupting encrypted workflows.

3. Track key transition states and maintain audit logs of all orchestration-layer key changes, capturing timing, purpose, affected services, and any errors during rollout or rollback.

[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 Orchestrated Service Providers (OSP)

Role Specific

1. Integrate key revocation hooks into orchestration frameworks to trigger automated key invalidation upon service removal, access change, or failure detection.

2. Enable dynamic service discovery mechanisms to propagate key revocation events across all dependent components, ensuring synchronized encryption policy enforcement.

3. Log revocation events and dependency updates across orchestration layers, enabling post-event validation of key invalidation and rollback integrity.

[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 Orchestrated Service Providers (OSP)

Role Specific

1. Embed key destruction routines into orchestration teardown workflows to ensure temporary or container-based keys are securely wiped when workflows are dismantled.

2. Automate the revocation of HSM-managed keys used in orchestration control planes once services are decoupled, decommissioned, or replaced, ensuring system state is updated accordingly.

3. Record and retain destruction metadata across orchestration layers, validating that keys are no longer referenced in distributed caches, service registries, or policy engines.

[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 Orchestrated Service Providers (OSP)

Role Specific

1. Configure orchestration control planes to register newly generated keys in a pre-activated state, tagging them as inactive until deployment approvals are completed.

2. Integrate key activation approval logic into service registration or deployment sequencing, ensuring that orchestration services cannot consume keys until explicitly authorized.

3. Maintain audit logs within orchestration management systems to record key activation events, associated approvers, and the system context in which activation was permitted.

[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 Orchestrated Service Providers (OSP)

Role Specific

1. Integrate automatic suspension mechanisms into service meshes and orchestration control planes that immediately disable keys used for inter-service communication in the event of access violations or risk assessments.

2. Ensure that reactivation workflows are gated by approval processes involving security teams, with audit logging of all reactivation events to validate compliance with internal policies.

3. Maintain visibility into key suspension events through centralized logging, highlighting affected services, operational disruptions, and key recovery actions to ensure timely resolution and compliance.

[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 Orchestrated Service Providers (OSP)

Role Specific

1. Integrate automatic key expiration and deactivation controls into service mesh and orchestration workflows, ensuring service-to-service credentials and control plane secrets are automatically revoked once their expiration date is reached.

2. Implement visibility and reporting tools that notify platform engineers when keys near expiration, and trigger deactivation processes to prevent unauthorized access.

3. Maintain a centralized logging system that captures key expiration events, detailing when keys were deactivated, who authorized the action, and which orchestration services were impacted.

[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 Orchestrated Service Providers (OSP)

Role Specific

1. Archive decommissioned orchestration-layer keys alongside associated service dependency maps and orchestration version metadata to support integrity verification during incident response or rollback operations.

2. Limit access to archived orchestration keys using automation-enforced access controls integrated with orchestration policy engines, ensuring only platform security leads and compliance personnel may initiate access workflows.

3. Perform quarterly validation of archived key states within orchestration vaults, ensuring that keys marked for long-term storage are encrypted, access logs are complete, and no active orchestration workflows reference deprecated key material.

[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 Orchestrated Service Providers (OSP)

Role Specific

1. Enforce decryption-only policies for compromised orchestration-layer keys, ensuring that they are restricted to decrypting previously protected orchestration data and are prevented from being used for any further encryption tasks, in line with legal and regulatory obligations.

2. Review and track decryption activity for compromised keys, ensuring that such activity is documented, logged, and compliant with incident response procedures, while maintaining platform integrity and securing data in orchestration workflows.

3. Ensure clear communication among orchestration engineers, DevOps, and security teams to guarantee that all personnel understand the risks and proper procedures for using compromised keys, and the mechanisms in place to prevent unauthorized key use.

[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 Orchestrated Service Providers (OSP)

Role Specific

1. Assess recovery risks by balancing the impact of key recovery on orchestrated service operations with the potential risks of exposing sensitive service metadata or communication channels, ensuring that recovery actions are aligned with business continuity and compliance obligations.

2. Approve recovery strategies by evaluating orchestration key recovery mechanisms such as recovery automation and fallback workflows, confirming that they are based on risk thresholds, tested for resiliency, and comply with regulatory requirements.

3. Integrate secure recovery methods by implementing key recovery processes for orchestration services that ensure access is restricted to authorized personnel, are logged for accountability, and are aligned with transparency and operational risk reduction 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-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 Orchestrated Service Providers (OSP)

Role Specific

1. Track orchestration-specific keys by ensuring all keys used in service-to-service communication, control-plane components, and encrypted workflows are accurately inventoried throughout their lifecycle, including key generation, activation, suspension, and revocation.

2. Ensure key inventory compliance by implementing systems to register, track ownership, and monitor the status transitions of orchestration-layer keys, ensuring compliance with internal governance policies and external regulatory requirements.

3. Conduct regular audits by monitoring key inventory integrity through internal audits and technical reviews, ensuring that key material changes are logged and discrepancies are resolved according to the defined escalation and resolution procedures.

[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 Orchestrated Service Providers (OSP)

1. OSPs should implement and maintain physical and environmental security policies covering infrastructure used to orchestrate AI services, including compute clusters, container platforms, and workflow engines.

2. Policies should define controls for data center access, environmental monitoring, and protection of orchestration pipelines.

3. OSPs should ensure that dependencies on underlying infrastructure providers are governed by contractual and technical assurance mechanisms.

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

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 Orchestrated Service Providers (OSP)

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

1. Implementation of verification system for data removal across interconnected services and have disposal coordination procedures with upstream and downstream partners.

2. Removal of configuration data and access credentials and a post-disposal security validation should be done, to verify no orchestration metadata remains accessible.

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

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 Orchestrated Service Providers (OSP)

Role Specific

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.

2. Implement service dependency mapping to ensure complete transfer packages with Pre and Post validations to verify system integrity.

[All Actors except AIC]

1. Providers should ensure that they have robust and clearly documented processes and procedures for the relocation or transfer of hardware, software, or data/information to an offsite or alternate location, including devices that handle model development, data processing, or inference tasks. These include but not limited to the procedures listed for the CSP. If using third-party datacenter vendors, ensure they have these procedures in place.

DCS-04: Secure Area Policy and Procedures

Control Specification

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

Shared Implementation Guidelines

[All Actors except AIC]

1. Providers should ensure that they have documented, approved, communicated, applied, evaluated and maintained policies and procedures for maintaining a safe and secure working environment in offices, rooms, and facilities that processes data for models or inference tasks. These include but not limited to the procedures listed for the CSP.

Implementation Guidelines for Orchestrated Service Providers (OSP)

Role Specific

1. OSP position between model providers and applications requires enhanced security at connection points.

2. Establish secure corridors for data transit between interconnected systems.

3. Document all physical cable maps with appropriate classification levels.

4. Create emergency shutdown protocols for compromised orchestration components

[All Actors except AIC]

1. Providers should ensure that they have documented, approved, communicated, applied, evaluated and maintained policies and procedures for maintaining a safe and secure working environment in offices, rooms, and facilities that processes data for models or inference tasks. These include but not limited to the procedures listed for the CSP.

DCS-05: Secure Media Transportation Policy and Procedures

Control Specification

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

Shared Implementation Guidelines

[All Actors Except AIC]

1. Providers should ensure that they have document, approve, communicate, apply, evaluate and maintain policies and procedures for secure transportation of media that processes data for models or inference tasks.

2. Implement Physical protection standards for transfer of media.

3. Design/Implement procedural safeguards/steps in place to authorize and verify such transfers, with separation of duties of personnel involved.

Implementation Guidelines for Orchestrated Service Providers (OSP)

Role Specific

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. Deploy hardware security modules (HSMs) for transporting API keys and authentication materials.

3. Use specialized protective cases with environmental controls for sensitive orchestration hardware.

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

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 Orchestrated Service Providers (OSP)

Role Specific

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. Document the connections between various AI services and the data paths across orchestration platform. Create visual diagrams of service workflows and how 3rd party AI services are integrated.

[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 Orchestrated Service Providers (OSP)

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. Create visual representations of service connections and dependencies.

3. Document API versions and compatibility requirement with SLA for each integrated component.

4. Maintain a secure repository of all orchestration configurations.

[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 Orchestrated Service Providers (OSP)

Role Specific

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 .

2. Establish dedicated secure zones for critical orchestration servers with mantrap entrances with role-based physical access systems tied to identity management platforms.

3. Develop documented physical access procedures for maintenance activities.

[All Actors Except AIC]

1. Providers should implement physical security measures to safeguard personnel, data and information systems that are involved in tasks, such as data processing, inference, training.

DCS-09: Equipment Identification

Control Specification

Use equipment identification as a method for connection authentication.

Shared Implementation Guidelines

[All Actors Except AIC]

1. Providers should implement equipment identification as a means for authenticating to connection for systems that perform data processing, inference tasks.

2. Providers should have hardware identity foundations with trusted platform modules and unique fingerprinting across infrastructure, which combined with authentication mechanism, such as mutual TLS, certificate-based validation, and hardware-bound access controls.

3. Providers should establish continuous attestation services and anomaly detection while protecting infrastructure through secure boot capabilities and hardware roots of trust.

Implementation Guidelines for Orchestrated Service Providers (OSP)

Role Specific

1. Providers should implement equipment identification as a means for authenticating to connection for systems that perform data processing, inference tasks.

2. OSP needs to focus on secure intermediation via dedicated gateway hardware with tamper-resistant features by adding hardware-based identity management for orchestration nodes and use the identity as federation systems to broker trust between entities.

[All Actors Except AIC]

1. Providers should implement equipment identification as a means for authenticating to connection for systems that perform data processing, inference tasks.

2. Providers should have hardware identity foundations with trusted platform modules and unique fingerprinting across infrastructure, which combined with authentication mechanism, such as mutual TLS, certificate-based validation, and hardware-bound access controls.

3. Providers should establish continuous attestation services and anomaly detection while protecting infrastructure through secure boot capabilities and hardware roots of trust.

4. Providers should have hardware identity foundations with trusted platform modules and unique fingerprinting across infrastructure, which combined with authentication mechanism, such as mutual TLS, certificate-based validation, and hardware-bound access controls.

5. Providers should establish continuous attestation services and anomaly detection while protecting infrastructure through secure boot capabilities and hardware roots of trust.

DCS-10: Secure Area Authorization

Control Specification

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

Shared Implementation Guidelines

[All Actors except AIC]

1. Providers should allow only authorized personnel access to secure areas that contain equipment that perform tasks, data processing, inference. The access should be restricted by physical security controls and reviewed on a periodic basis.

Implementation Guidelines for Orchestrated Service Providers (OSP)

No Role Specific

[All Actors except AIC]

1. Providers should allow only authorized personnel access to secure areas that contain equipment that perform tasks, data processing, inference. The access should be restricted by physical security controls and reviewed on a periodic basis.

DCS-11: Surveillance System

Control Specification

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

Shared Implementation Guidelines

[All Actors except AIC,AP,OSP]

1. Providers should implement and maintain surveillance around data centres that perform tasks related to data processing, inference, etc.

2. Full coverage of DC with no blind spots. Establish formal chain of custody procedures for access recordings.

3. Maintain comprehensive access logs for all entry and exit events including maintenance activities performed on surveillance systems for regulatory compliance reviews.

Implementation Guidelines for Orchestrated Service Providers (OSP)

Role Specific and Shared

1. Providers should implement and maintain surveillance around data centres that perform tasks related to data processing, inference etc .

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 Orchestrated Service Providers (OSP)

No Role Specific

[All Actors except AIC]

1. Providers should have trained personnel to handle unauthorized access into areas of data center that perform sensitive tasks, such as data processing.

DCS-13: Cabling Security

Control Specification

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

Shared Implementation Guidelines

[All Actors except AIC]

1. Providers should implement measures that ensure risk based approach to protection of equipment such as cables, server racks, that perform sensitive tasks, such as data processing, inference, training, etc.

2. Provider should establish redundant connections for critical systems, deploy real-time monitoring with tamper detection, and restrict physical access through role-based controls.

3. Regular inspections, maintenance schedules during minimal usage windows, and comprehensive disaster recovery plans ensure ongoing protection.

Implementation Guidelines for Orchestrated Service Providers (OSP)

Role Specific

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 deploy cable management systems with visual verification capabilities and tamper-evident seals on connection points between services.

3. Maintain service maps with physical dependency documentation.

[All Actors except AIC]

1. Providers should implement measures that ensure risk based approach to protection of equipment such as cables, server racks, that perform sensitive tasks, such as data processing, inference, training, etc.

2. Provider should establish redundant connections for critical systems, deploy real-time monitoring with tamper detection, and restrict physical access through role-based controls.

3. Regular inspections, maintenance schedules during minimal usage windows, and comprehensive disaster recovery plans ensure ongoing protection.

DCS-14: Environmental Systems

Control Specification

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

Shared Implementation Guidelines

[All Providers except AIC]

1. Providers should implement environmental control systems around data centres that perform sensitive tasks such as training, data processing, inference to ensure continual effectiveness and humidity conditions is within accepted standards.

2. Providers should establish comprehensive environmental control systems that address the specific environmental conditional such as temperature and humidity requirements of AI computing hardware.

3. Implement multi-tiered monitoring systems with real-time dashboards and automated alerts for deviations that might impact system performance.

4. Develop documented emergency protocols for environmental failures, including graceful degradation and workload shifting capabilities.

5. Create redundant cooling and power systems with N+1 redundancy for critical AI workloads.

6. Conduct regular effectiveness testing and maintenance of all environmental controls, with quarterly performance analysis to optimize for both reliability and energy efficiency.

Implementation Guidelines for Orchestrated Service Providers (OSP)

Role Specific

1. Integrate environmental monitoring data (temperature, humidity, airflow) into orchestration dashboards and alerting systems. Enable automated responses, such as workload migration or throttling, in the event of environmental anomalies to protect critical infrastructure.

2. Schedule and conduct periodic audits of environmental control systems to verify operational effectiveness and compliance with industry standards. Document findings and implement corrective actions as needed.

[All Providers except AIC]

1. Providers should implement environmental control systems around data centres that perform sensitive tasks such as training, data processing, inference to ensure continual effectiveness and humidity conditions is within accepted standards.

2. Providers should establish comprehensive environmental control systems that address the specific environmental conditional such as temperature and humidity requirements of AI computing hardware.

3. Implement multi-tiered monitoring systems with real-time dashboards and automated alerts for deviations that might impact system performance.

4. Develop documented emergency protocols for environmental failures, including graceful degradation and workload shifting capabilities.

5. Create redundant cooling and power systems with N+1 redundancy for critical AI workloads.

6. Conduct regular effectiveness testing and maintenance of all environmental controls, with quarterly performance analysis to optimize for both reliability and energy efficiency.

DCS-15: Secure Utilities

Control Specification

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

Shared Implementation Guidelines

[All Actors except AIC]

1. Providers should test utility services that power data centres that perform sensitive tasks such as training, data processing, inference to ensure continual effectiveness on a periodic basis.

2. Providers should establish comprehensive environmental control systems that address the specific environmental conditional such as temperature and humidity requirements of AI computing hardware.

3. Implement multi-tiered monitoring systems with real-time dashboards and automated alerts for deviations that might impact system performance.

4. Develop documented emergency protocols for environmental failures, including graceful degradation and workload shifting capabilities.

5. Create redundant cooling and power systems with N+1 redundancy for critical AI workloads.

6. Conduct regular effectiveness testing and maintenance of all environmental controls, with quarterly performance analysis to optimize for both reliability and energy efficiency.

Implementation Guidelines for Orchestrated Service Providers (OSP)

Role Specific

1. Develop and enforce centralized policies for securing utility services across all orchestrated environments. Ensure consistent application of security controls for utilities such as power, HVAC, and network infrastructure.

[All Actors except AIC]

1. Providers should test utility services that power data centres that perform sensitive tasks such as training, data processing, inference to ensure continual effectiveness on a periodic basis.

2. Providers should establish comprehensive environmental control systems that address the specific environmental conditional such as temperature and humidity requirements of AI computing hardware.

3. Implement multi-tiered monitoring systems with real-time dashboards and automated alerts for deviations that might impact system performance.

4. Develop documented emergency protocols for environmental failures, including graceful degradation and workload shifting capabilities.

5. Create redundant cooling and power systems with N+1 redundancy for critical AI workloads.

6. Conduct regular effectiveness testing and maintenance of all environmental controls, with quarterly performance analysis to optimize for both reliability and energy efficiency.

DCS-16: Equipment Location

Control Specification

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

Shared Implementation Guidelines

[All Actors except AIC]

1. Providers should isolate critical equipment that contains data centres that perform business sensitive tasks, such as training, data processing away from environment related risks such as flooding, tornadoes, etc.

2. Providers should implement a strategic approach to select equipment location that minimizes environmental failure risks to critical systems.

3. Conduct comprehensive environmental and geological risk assessments before selecting datacenter locations, ensuring facilities avoid flood zones, seismic risk areas, and regions prone to extreme weather events. Implement geographic diversity with distributed infrastructure across multiple regions, preventing any single environmental event from disrupting essential AI services.

4. Establish continuous environmental monitoring with predictive capabilities to anticipate potential hazards.

5. Develop formal business continuity plans with specific protocols for equipment protection during environmental emergencies. Regularly review and update risk profiles considering evolving climate patterns.

Implementation Guidelines for Orchestrated Service Providers (OSP)

Role Specific

1. Establish and enforce policies that prohibit the placement of orchestration servers and control nodes in areas prone to environmental risks such as flooding, fire, or power instability.

2. Require environmental risk evaluations as part of the site selection and approval process for new orchestration infrastructure deployments.

[All Actors except AIC]

1. Providers should isolate critical equipment that contains data centres that perform business sensitive tasks, such as training, data processing away from environment related risks such as flooding, tornadoes, etc.

2. Providers should implement a strategic approach to select equipment location that minimizes environmental failure risks to critical systems.

3. Conduct comprehensive environmental and geological risk assessments before selecting datacenter locations, ensuring facilities avoid flood zones, seismic risk areas, and regions prone to extreme weather events. Implement geographic diversity with distributed infrastructure across multiple regions, preventing any single environmental event from disrupting essential AI services.

4. Establish continuous environmental monitoring with predictive capabilities to anticipate potential hazards.

5. Develop formal business continuity plans with specific protocols for equipment protection during environmental emergencies. Regularly review and update risk profiles considering evolving climate patterns.

DCS-17: Datacenter Metrics

Control Specification

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

Shared Implementation Guidelines

[All actors]

1. Organizations should define, monitor, and report security-relevant metrics to evaluate the protection and reliability of infrastructure supporting AI systems.

2. Metrics should include indicators of physical and environmental conditions, infrastructure availability, access control events, hardware and platform health, and configuration integrity.

3. Organizations should monitor for deviations from approved configurations, patch levels, and security baselines that could impact the confidentiality, integrity, or availability of data center assets and services.

4. Metric thresholds, alerting mechanisms, and reporting processes should be defined, reviewed periodically, and integrated into operational response and risk management workflows.

Implementation Guidelines for Orchestrated Service Providers (OSP)

1. Orchestrated Service Providers should establish and monitor security and reliability metrics across orchestration platforms, including compute node availability, container runtime stability, access controls, and configuration integrity of orchestration components.

2. Metrics should detect deviations from approved platform configurations, unauthorized workload placement, and infrastructure anomalies that may affect service reliability or security.

3. Providers should integrate metrics into automated alerting and recovery workflows to support continuous service availability.

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 Orchestrated Service Providers (OSP)

1. Orchestrated Service Providers should implement resilience mechanisms across orchestration platforms, including workload failover, service redundancy, and automated recovery of orchestration components.

2. Ensure that orchestration services can tolerate node failures, zone outages, and infrastructure degradation without disrupting AI service availability.

3. Recovery procedures should be tested periodically (at least annually), and monitoring should verify that orchestration pipelines can recover to a known good state following disruptions.

4. Dependencies on 3rd party infrastructure providers should be incorporated into continuity strategies.

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 Orchestrated Service Providers (OSP)

Primary Responsibility: Secure handling of data in AI service orchestration

1. Ensure data security in model orchestration and integration services.

2. Implement robust access controls and API security for data exchanges between AI models and applications.

3. Provide monitoring and logging capabilities to track data flows through orchestration layers.

4. Enforce policies that prevent unauthorized data retention or exposure across orchestrated services.

[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 Orchestrated Service Providers (OSP)

1. Ensure all cache, log, or staging data in orchestration environments is wiped post-processing.

2. Use secure deletion workflows for pipeline data residues (temporary files, buffers).

3. Validate that all service layers involved in orchestration support and log secure disposal operations.

4. Establish TTL (time-to-live) and auto-purge functions in orchestration logic.

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

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 Orchestrated Service Providers (OSP)

1. Maintain visibility into data flows between AI models, APIs, and services.

2. Implement logging and monitoring for data movement across orchestrated layers.

3. Support federated data governance policies that integrate with upstream and downstream data owners.

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

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 Orchestrated Service Providers (OSP)

1. Classify data exchanged between AI models and services.

2. Ensure APIs and orchestration layers enforce data security policies.

3. Implement logging mechanisms to track sensitive data movements.

4. Use encryption and tokenization for sensitive data in transit

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

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 Orchestrated Service Providers (OSP)

1. Create and maintain a data flow map for AI model orchestration processes.

2. Ensure APIs and microservices interactions are documented and reviewed periodically.

3. Implement logging and auditing mechanisms to track data movement between AI services.

4. Update documentation upon changes in orchestration or integrations.

[All Actors]

1. Document inference pipelines, plugin flows and logs for all components the actor operates or manages.

2. Describe any user input / output flows, APIs and storage the actor designs or manages.

3. Map enterprise data sent to AI systems by the actor and validate flow compliance.

4. Offer infrastructure-flow visibility and document transfer / storage paths.

[Shared among: MP, OSP, CSP]

1. Map training / fine-tuning flow paths and outputs.

DSP-06: Data Ownership and Stewardship

Control Specification

Document ownership and stewardship of all relevant documented personal and sensitive data. Perform review at least annually.

Shared Implementation Guidelines

[All Actors]

1. Define and document data-ownership and stewardship policies for every dataset the actor stores or processes.

2. Maintain an up-to-date inventory (or lineage repository) of personal and sensitive data that records origin, transformations, current location, and designated owner / steward.

3. Implement traceability mechanisms—logs, metadata tagging, or equivalent—to follow data from ingestion to disposal within systems the actor controls.

4. Review and update ownership / stewardship documentation at least annually, or after significant changes, and assess compliance with those policies.

[Shared among: MP, OSP, CSP]

1. Maintain records of training and inference datasets containing personal or sensitive data, including associated ownership and usage-rights metadata.

Implementation Guidelines for Orchestrated Service Providers (OSP)

1. Document data flow between AI models and orchestration services.

2. Ensure data ownership and stewardship policies are enforced at the API and service interaction level.

3. Maintain a central repository for tracking data movement and processing.

4. Review and update documentation annually or upon service modifications.

[All Actors]

1. Define and document data-ownership and stewardship policies for every dataset the actor stores or processes.

2. Maintain an up-to-date inventory (or lineage repository) of personal and sensitive data that records origin, transformations, current location, and designated owner / steward.

3. Implement traceability mechanisms—logs, metadata tagging, or equivalent—to follow data from ingestion to disposal within systems the actor controls.

4. Review and update ownership / stewardship documentation at least annually, or after significant changes, and assess compliance with those policies.

[Shared among: MP, OSP, CSP]

1. Maintain records of training and inference datasets containing personal or sensitive data, including associated ownership and usage-rights metadata.

DSP-07: Data Protection by Design and Default

Control Specification

Develop systems, products, and business practices based upon a principle of security by design and industry best practices.

Shared Implementation Guidelines

[All Actors]

1. Apply security controls (encryption, RBAC, logging, vulnerability patching) to every hop identified in the data-flow map for components the actor operates.

2. Verify that protections remain effective after system changes (e.g., new API, new storage location).

3. Document residual risks and mitigation plans.

[Shared among: MP, OSP, CSP]

1. Encrypt training data at rest, restrict access to authorised service roles, and monitor for anomalous reads/writes in training pipelines.

Implementation Guidelines for Orchestrated Service Providers (OSP)

1. Enforce security policies in AI pipeline orchestration.

2. Implement access controls, API security, and secure data flows between AI services.

3. Monitor AI supply chain for security vulnerabilities and compliance risks.

4. Ensure secure configuration management and vulnerability patching.

[All Actors]

1. Apply security controls (encryption, RBAC, logging, vulnerability patching) to every hop identified in the data-flow map for components the actor operates.

2. Verify that protections remain effective after system changes (e.g., new API, new storage location).

3. Document residual risks and mitigation plans.

[Shared among: MP, OSP, CSP]

1. Encrypt training data at rest, restrict access to authorised service roles, and monitor for anomalous reads/writes in training pipelines.

DSP-08: Data Privacy by Design and Default

Control Specification

Develop systems, products, and business practices based upon a principle of privacy by design and industry best practices. Ensure that systems’ privacy settings are configured by default, according to all applicable laws and regulations.

Shared Implementation Guidelines

[All Actors]

1. Filter, mask and auto-delete sensitive inputs / outputs by default where the actor can inspect content; where content is opaque, ensure upstream or downstream services apply equivalent controls.

2. Enforce user consent, minimise data and give privacy control to users for any personal data the actor collects or processes.

3. Enforce enterprise privacy policies and control what data is shared for any data the actor shares or receives, ensuring onward transfers respect those policies.

4. Provide privacy-protective infrastructure defaults and compliance tools.

[Shared among: MP, OSP, CSP]

1. Use privacy-preserving data, consent-based training and reduce memorisation for any model training the actor performs.

Implementation Guidelines for Orchestrated Service Providers (OSP)

1. Ensure privacy controls for AI orchestration workflows, including secure data flow tracking.

2. Enforce data masking, role-based access control (RBAC), and privacy-respecting API interactions.

3. Configure default privacy settings to restrict unnecessary data exposure.

4. Monitor AI pipelines for data leakage and unauthorized access risks.

[All Actors]

1. Filter, mask and auto-delete sensitive inputs / outputs by default where the actor can inspect content; where content is opaque, ensure upstream or downstream services apply equivalent controls.

2. Enforce user consent, minimise data and give privacy control to users for any personal data the actor collects or processes.

3. Enforce enterprise privacy policies and control what data is shared for any data the actor shares or receives, ensuring onward transfers respect those policies.

4. Provide privacy-protective infrastructure defaults and compliance tools.

[Shared among: MP, OSP, CSP]

1. Use privacy-preserving data, consent-based training and reduce memorisation for any model training the actor performs.

DSP-09: Data Protection Impact Assessment

Control Specification

Conduct a Data Protection Impact Assessment (DPIA) to evaluate the origin, nature, particularity and severity of the risks upon the processing of personal data, according to any applicable laws, regulations and industry best practices.

Shared Implementation Guidelines

[All Actors]

1. Conduct a Data-Protection Impact Assessment (DPIA) for every personal-data processing activity the actor controls, evaluating likelihood and severity of risks such as bias, re-identification, unauthorized access, or adversarial misuse.

2. Document the processing purpose, data flows, lawful basis, risk findings and mitigation measures, and retain the DPIA report for audit or regulatory review.

3. Review and update the DPIA at least annually or whenever a material change occurs (new data source, new model version, new recipient, major scale-up, etc.).

4. Verify that processing remains compliant with applicable laws and standards (e.g., GDPR, CCPA, ISO 27701, HIPAA) and record evidence of that verification.

[Shared among: AP, AIC, OSP]

1. Provide user-facing transparency (notices, dashboards) and consent or opt-out mechanisms whenever the DPIA identifies heightened impact on data subjects, and propagate those choices through downstream services.

Implementation Guidelines for Orchestrated Service Providers (OSP)

1. Assess risks related to personal data processing across AI workflows.

2. Ensure secure data transmission, storage, and processing in AI orchestration services.

3. Monitor AI supply chain risks associated with third-party data processing.

4. Conduct periodic DPIAs to evaluate evolving risks and compliance obligations.

[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 Orchestrated Service Providers (OSP)

1. Secure APIs and orchestrated workflows that handle sensitive data transfers.

2. Use encryption and data classification techniques across service layers.

3. Log data flow paths and enforce role-based access controls (RBAC) at each orchestration step.

4. Monitor compliance with data protection regulations for the complete orchestrated service.

[All Actors]

1. Protect any datasets and outputs the actor transmits during cross-system transmission.

2. Secure service-to-service inference and plugin data flow under the actor’s control through authenticated, encrypted channels and strict access controls.

3. Secure user data transfers, log handling and consent-based usage for any user data the actor processes.

4. Classify, encrypt and contractually limit transferred data for any transfers the actor initiates or receives.

5. Provide secure-by-default networking, encryption and transfer logs.

DSP-11: Personal Data Access, Reversal, Rectification and Deletion

Control Specification

Define and implement, processes, procedures and technical measures to enable data subjects to request access to, modification, or deletion of their personal data, according to any applicable laws and regulations.

Shared Implementation Guidelines

[All Actors]

1. Provide technical enforcement for data-at-rest subject to data-subject requests within systems the actor controls.

2. Govern model / training-data handling for data-subject rights for any models or datasets the actor manages.

3. Orchestrate middleware / flow pipelines for rights requests for any integration layers the actor operates.

4. Deliver or expose interfaces that enable end-user access and visibility for rights management for personal data the actor controls.

5. Govern compliance and contracts for data-subject rights.

Implementation Guidelines for Orchestrated Service Providers (OSP)

1. Integrate data subject request handling across multiple services using orchestration logic.

2. Track provenance of data requests and ensure propagation of deletion/modification requests downstream.

3. Automate DSR execution workflows (e.g., using orchestration tools like Apache Airflow or Kubernetes).

4. Validate partner systems for DSR compliance during service onboarding.

5. Implement the technical and procedural controls specified by the AIC and provide evidence of these controls upon request.

[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 Orchestrated Service Providers (OSP)

1. Implement purpose-aware orchestration using tags or metadata enforcement at pipeline levels.

2. Monitor for unauthorized re-routing or data reuse not aligned with declared intents.

3. Coordinate with upstream and downstream partners to verify declared processing purposes.

4. Support automated decision logic based on data purpose (e.g., deny routing if purpose misaligned).

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

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 Orchestrated Service Providers (OSP)

1. Implement data flow transparency dashboards across orchestrated services.

2. Monitor data handoffs between components to identify any privacy leakage risks.

3. Ensure interoperability of privacy policies across multi-vendor orchestrations.

4. Verify regulatory alignment for international transfers (e.g., standard contractual clauses, data residency constraints).

[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 Orchestrated Service Providers (OSP)

1. Implement orchestration-level visibility tools to track data access events by components and sub-services.

2. Establish inter-provider coordination for joint disclosure of sub-processor roles and activities.

3. Notify data owners about any planned integrations or changes involving sensitive data access.

4. Coordinate sub-processor access approval flows with model and app providers.

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

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 Orchestrated Service Providers (OSP)

[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 Orchestrated Service Providers (OSP)

[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 Orchestrated Service Providers (OSP)

[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 Orchestrated Service Providers (OSP)

[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 Orchestrated Service Providers (OSP)

[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 Orchestrated Service Providers (OSP)

[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 Orchestrated Service Providers (OSP)

1. Validate data quality and integrity at source before submission to the AI system, including checks for anomalous patterns, outliers, or suspicious changes in data distributions.

2. Maintain detailed audit logs of who accessed, modified, or submitted data, with timestamps and user authentication to trace potential poisoning attempts.

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

4. Conduct periodic reviews of model outputs against expected business 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 Orchestrated Service Providers (OSP)

1. Define Privacy risk and impact assessment framework for AI platform.

2. Implement risk classification system to prioritize identified risk.

3. Select and implement platform-level PETs such as SMPC, confidential computing.

4. Monitor privacy metrics and PET effectiveness.

5. Establish performance baselines for PETs.

6. Monitor privacy metrics, conduct compliance audits, and set up feedback loops to ensure PETs continue to meet privacy goals and regulatory requirements.

[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 Orchestrated Service Providers (OSP)

1. Implement a process to validate input data format, schema, labels, duplication and drift before model training or fine tuning to detect data leakage, out of range or invalid values and semantic duplicates.

2. Implement role based access control mechanisms and establish approval workflows for data updates across all integrated systems.

3. Implement a process to monitor for data leakage or invalid patterns, along with a mechanism to alert appropriate stakeholders.

4. Perform data integrity checks to detect alteration, corruption and tampering of data.

[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 Orchestrated Service Providers (OSP)

1. Implement data transformation and integration services to standardize and maintain consistency in datasets, differentiating them properly before entering the AI model training phase.

2. Implement version control and monitoring systems to track relevant changes to the dataset over time, using only properly differentiated and relevant data.

3. Define policies to ensure data used for AI training adheres to industry regulations and standards such as GDPR, HIPAA and is aligned with defined service level objectives.

[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 Orchestrated Service Providers (OSP)

[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 Orchestrated Service Providers (OSP)

[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 Orchestrated Service Providers (OSP)

1. Align pipeline-security and CI/CD-governance policies with the shared catalogue; surface policy-compliance widgets in the orchestration UI.

[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 Orchestrated Service Providers (OSP)

1. Apply the exception process to CI/CD pipelines and cluster configurations; surface active exceptions on orchestration dashboards.

[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 Orchestrated Service Providers (OSP)

1. Ensure orchestration tools and CI/CD pipelines include hardening configurations, secure credentials handling, and tamper-evident deployment logs.

2. Incorporate container/image scanning, signature verification, and policy-as-code enforcement into orchestration stages.

3. Regularly test rollback procedures and failover configurations in security-sensitive environments.

4. Provide runtime protections such as least-privileged service accounts and dynamic access policy enforcement.

5. Embed audit logging for orchestration tools to detect abnormal behavior or unauthorized configuration changes.

[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 Orchestrated Service Providers (OSP)

1. Designate pipeline owners and release managers who enforce deployment security and version control.

2. Assign reviewers for IaC templates, Helm charts and container images; block releases until sign-off.

3. Give runtime monitoring and rollback authority to operational teams, with dashboards that flag overlapping privileges.

[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 Orchestrated Service Providers (OSP)

1. Ensure orchestration processes comply with deployment and access control requirements from regulatory mandates.

2. Document how infrastructure-as-code templates and CI/CD practices enforce compliance baselines.

3. Map technical controls (e.g., code promotion gates, logging) to security and audit requirements.

4. Validate runtime orchestration against data residency and jurisdictional restrictions.

5. Support ongoing evidence collection for regulated environments (e.g., SOC 2, ISO 27017).

[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 Orchestrated Service Providers (OSP)

1. Engage with DevOps, MLOps, and CI/CD governance SIGs to remain updated on secure deployment patterns.

2. Contribute to container security standards and policy-as-code templates shared in industry groups.

3. Track innovations in runtime protection and configuration validation through SIG communities.

4. Encourage DevSecOps team participation in CNCF or similar SIGs.

5. Evaluate recommendations from SIGs and align orchestration tooling with industry trends.

[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 Orchestrated Service Providers (OSP)

1. Enforce AUP-relevant constraints in deployment configurations (e.g., feature flags, service exposure).

2. Integrate AUP policies into CI/CD pipelines for automated validation of configuration compliance.

3. Monitor system telemetry for behavior inconsistent with intended use or flagged by abuse detection.

4. Support automated service shutdown or isolation workflows when AUP violations are detected.

5. Ensure version-controlled policy mapping for AI-related configurations.

[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 Orchestrated Service Providers (OSP)

1. Evaluate whether orchestration introduces systemic risks due to automation, scale, or configuration drift.

2. Document risks related to runtime failure, rollback failure, or excessive privilege in deployment pipelines.

3. Assess impact of auto-scaling, multi-region deployment, or resource exhaustion on service reliability.

4. Include orchestration risk in integrated AI impact assessment templates.

5. Ensure alignment with model-level risk documentation.

[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 Orchestrated Service Providers (OSP)

1. Ensure fairness-sensitive models are not altered by pipeline logic without validation.

2. Include fairness evaluation as a quality gate or CI/CD checkpoint.

3. Automate alerts if retrained models show fairness regressions.

4. Preserve pipeline metadata to support post-hoc fairness analysis.

5. Validate pipeline reproducibility to maintain consistent fairness outcomes.

[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 Orchestrated Service Providers (OSP)

1. Present pipeline-level risks (e.g., data leakage, auto-scaling drift) to the committee for review when relevant.

2. Support ethics committee with reproducibility evidence and audit logs.

3. Implement technical safeguards required by the ethics committee (e.g., environment isolation).

4. Log deployment events linked to ethics-reviewed models or policies.

5. Include the committee in rollback decisions for ethically non-compliant deployments.

[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 Orchestrated Service Providers (OSP)

1. Ensure pipelines retain explainability metadata and outputs during inference and deployment.

2. Support integration of explainability tools within the CI/CD flow.

3. Log explanation generation steps for auditability.

4. Validate explanations remain consistent across model re-deployments.

5. Flag missing or corrupted explanation artifacts in the deployment workflow.

[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 Orchestrated Service Providers (OSP)

1. Ensure orchestration metadata (e.g., environment, hyperparameters, dependencies) is captured and disclosed.

2. Include reproducibility metadata in transparency artifacts.

3. Ensure runtime environments match documented configurations.

4. Support linking deployment logs to transparency documentation.

5. Enable export of disclosure bundles from pipelines.

[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 Orchestrated Service Providers (OSP)

1. Embed manual review gates within the orchestration pipeline to allow human override before executing critical workflows or automated decisions.

2. Maintain a centralized dashboard for human supervisors to monitor AI system performance, flags, and decisions in real time.

3. Train operations staff on interpreting AI system alerts and guidelines for when to override or intervene in automated processes.

4. Schedule periodic manual audits of orchestrated decisions to ensure compliance with ethical and regulatory standards.

5. Ensure clear escalation paths are in place for human reviewers to take action when AI systems exhibit unexpected or undesirable behavior.

[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 Orchestrated Service Providers (OSP)

1. Personnel Vetting: Vet personnel managing AI pipelines (MLOps, CI/CD) for secure deployment practices and compliance awareness.

2. Automated Verification: Use automated verification tools (where permissible) to speed up checks for relevant AI/DevOps credentials.

[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 Orchestrated Service Providers (OSP)

[Orchestrated Service Provider (OSP)]

1. Infrastructure Standards: Extend acceptable use policies to cover AI deployment infrastructure, scaling mechanisms, API integrations, and resource management.

2. Integration Compliance: Validate that all orchestrated services and third-party integrations comply with documented acceptable use provisions, especially where multi-tenant environments are involved.

[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 Orchestrated Service Providers (OSP)

[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 Orchestrated Service Providers (OSP)

[Orchestrated Service Provider (OSP)]

1. Infrastructure-Based Remote Connections: Design remote orchestration services with encrypted endpoints, identity and access management (IAM), and privileged session monitoring.

2. Coordination with Clients: Collaborate with clients to ensure remote orchestration aligns with established data protection practices and standardized deployment procedures, especially in multi-tenant or hybrid-cloud environments.

[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 Orchestrated Service Providers (OSP)

[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 Orchestrated Service Providers (OSP)

[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 Orchestrated Service Providers (OSP)

[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 Orchestrated Service Providers (OSP)

[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 Orchestrated Service Providers (OSP)

[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 Orchestrated Service Providers (OSP)

[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 Orchestrated Service Providers (OSP)

[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 Orchestrated Service Providers (OSP)

[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 Orchestrated Service Providers (OSP)

[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 Orchestrated Service Providers (OSP)

[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 Orchestrated Service Providers (OSP)

[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 Orchestrated Service Providers (OSP)

[OSP] The orchestrated service provider is responsible for IAM policies surrounding service access to AI capabilities, including:

1. Separate roles for each service accessing AI capabilities

2. Establishing permission between services

[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 Orchestrated Service Providers (OSP)

[OSP] The OSP is responsible for establishing strong authentication credential management policies for accessing model storage, for any fine-tuning pipelines, for the accounts used by any AI models used in the service, and for authentication of internal customers and MPs, both to the OSP and to each other.

[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. Credential Reset: Define a secure reset process to prevent unauthorized access in case of forgotten passwords and other identity validation mechanism.

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 Orchestrated Service Providers (OSP)

[OSP]

1. The Orchestrated Service Provider is responsible for inventorying identities including:

   • Identities with access to shared AI resources

   • Service-to-service identities across the AI ecosystem

   • Workload identities in container environments

   • Privileged identities for infrastructure management

   • Identities used for logging and monitoring of AI services.

[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 Orchestrated Service Providers (OSP)

[OSP]

1. The Orchestrated Service Provider is responsible for implementing SoD by

   • SoD between those AI service configuration and monitoring

   • SoD between different AI applications using the service

   • Separate authentication for resource allocation activities

   • Multi-party approval for shared service modifications

[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 Orchestrated Service Providers (OSP)

[Orchestration Service Provider]

1. The Orchestration Service Provider is responsible for implementing PoLP by:

   • Restricting infrastructure access to only what’s required for specific service management tasks

   • Limiting customer data access to personnel with direct support responsibilities

   • Providing scoped permissions for monitoring versus configuration activities

   • Creating role-based access controls that align with specific service management functions

   • Establishing temporary elevated access for incident response with automatic expiration

[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 Orchestrated Service Providers (OSP)

1. Define access roles specific to orchestration components (e.g., CI/CD pipelines, deployment orchestrators).

2. Ensure provisioning systems support automated role assignments upon user onboarding in line with tenant requirements.

3. Use identity federation or SSO for cross-platform access provisioning where applicable.

4. Log all provisioning events across services and enforce time-bound access for external collaborators or contractors.

[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 Orchestrated Service Providers (OSP)

1. Auto-revoke pipeline, dashboard and cluster roles via identity-federation APIs when HR status changes.

2. Strip admin privileges first, then normal roles, to minimise window for misconfiguration.

[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 Orchestrated Service Providers (OSP)

1. Audit access to orchestrator components such as pipeline runners, deployment systems, and secrets managers.

2. Support scheduled access certification campaigns and policy-driven revocation based on review results.

[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 Orchestrated Service Providers (OSP)

1. Enforce segregation between roles responsible for deploying, approving, and monitoring orchestrated workloads.

2. Prohibit configuration changes by monitoring roles without secondary validation.

3. Provide dashboards for visibility into overlapping privileges across services and tenants.

4. Support dynamic RBAC mappings based on environment (e.g., staging vs. production).

[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 Orchestrated Service Providers (OSP)

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

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 Orchestrated Service Providers (OSP)

[OSP]

1. Implement AIC approval workflows for accessing high-risk roles with permission to perform actions that may expose sensitive customer information or affect production, such as but not limited to:

   • i. Administrative access to the customers’ tenant

   • ii. Access to customer key management or secret infrastructure

   • iii. Access to ML/AI Ops platforms.

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

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 Orchestrated Service Providers (OSP)

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

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 Orchestrated Service Providers (OSP)

[OSP]

1. Enforce Strong Authentication(such as phish-resistant MFA) is required to access sensitive components such as

   • i. Tenant configuration

   • ii. Networking Access Control Rules

   • iii. AI and ML Ops platforms.

[Shared with the 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.

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

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 Orchestrated Service Providers (OSP)

1. Ensure a secure method of authentication credential management, such as JIT secret vaults checkout for Agent Based systems that require access to secrets and credentials for tool usage.

2. When providing services and platforms that require credentials or keys for accessing them, ensure the first-time password is dynamically generated for the AIC.

3. Support and enforce features such as, strength requirements and lockout mechanisms for services and systems provided to AICs.

4. Prevent the use of “exposed” credentials detected from trusted sources.

5. Train staff of secure credential management including, secret management.

6. Support passwordless authentication for AICs such as passkeys.

[All Actors]

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.

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 Orchestrated Service Providers (OSP)

[OSP]

1. Ensure platform and services support interoperable standards for Agent based systems identification and authorization to resources (such as A2A).

2. Ensure only authorized actors can access, modify, train, manage, or deploy specific tenant infrastructure and setting including resources, networking and access controls.

3. When applicable develop and implement a process for the AIC to approve and review access to sensitive.

4. Ensure provided API endpoints and Interfaces support and are configured with granular authorization mechanism (such as resource, permission [read, write, update, etc]).

5. Implement granular access control method to components such as:

   • i. Resource configuration and rules (such as GPU usage, scaling, etc)

   • ii. Orchestration settings and configuration

   • iii. Tenant Configuration

[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 Orchestrated Service Providers (OSP)

[OSP]

1. Implement process and procedures to classify assets and data, such as tagging.

2. Implement approval workflows that have data owners and stewards approve access resources such as storage or compute with access to their data.

3. Implement granular access control policy and roles for accessing AI infrastructure components based on information.

4. Implement segmentation of resources, through controls like logical accounts and network segmentation to limit access to information.

5. Provided tools and settings for AICs to manage information & asset classification such as tagging and grouping.

6. Provide granular infrastructure permissions for AICs to customize to enforce need-to-know.

[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 Orchestrated Service Providers (OSP)

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

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 Orchestrated Service Providers (OSP)

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

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 Orchestrated Service Providers (OSP)

1. Define and enforce policies for platform APIs (management, deployment, monitoring) adhering to open standards.

2. Ensure platform components support interoperable data formats/protocols which are based on open standards.

3. Implement industry standard log/metric formats.

[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 Orchestrated Service Providers (OSP)

1. Offer APIs for AI service customers (AICs) to retrieve and configure platform usage data, billing info, operational logs, monitoring metrics, deployment status, and relevant configuration data tied to their account.

[All Actors]

1. API Design & Provision: a) Develop/maintain robust, documented APIs for AI service customer 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.

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 Orchestrated Service Providers (OSP)

1. Secure all platform management APIs/interfaces (deployment, scaling, monitoring) with HTTPS/TLS.

2. Use secure protocols for transferring logs, metrics, backups.

3. Secure import/export of configurations/snapshots.

[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 Orchestrated Service Providers (OSP)

1. Agreements cover export of platform configuration data, deployment artifacts, operational logs, monitoring/billing data.

2. Specify formats and timelines for retrieval post-termination.

[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 Orchestrated Service Providers (OSP)

1. Define policies covering virtualization and orchestration security, including cloud workload protection and API security measures.

2. Implement logging and monitoring and alerting for infrastructure changes to detect unauthorized modifications or security misconfigurations.

3. Enforce infrastructure security across multi-cloud and hybrid environments using secure configuration management tools.

[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 Orchestrated Service Providers (OSP)

1. Define capacity planning for managing infrastructure orchestration across cloud/on-prem environments.

2. Implement auto-scaling mechanisms for AI workloads.

3. Monitor and alert on AI workload execution, API interactions, and underlying system resource utilization to detect anomalies to ensure stable AI operations.

[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 Orchestrated Service Providers (OSP)

1 Enforce network security policies for AI model deployment infrastructures.

1. Implement network traffic monitoring and anomaly detection.

2. Secure API communications with encrypted authentication mechanisms.

[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 Orchestrated Service Providers (OSP)

1. Secure orchestration layers against OS and hypervisor vulnerabilities.

2. Ensure control plane protection with strong authentication and encryption.

3. Regularly assess OS-level security compliance in multi-tenant environments.

[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 Orchestrated Service Providers (OSP)

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

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 Orchestrated Service Providers (OSP)

[All Actors]

1. Use identity-based policies for resource isolation to enforce tenant-specific access controls.

2. Restrict intra-tenant and cross-tenant access based on least privilege.

[Shared between the MP, AP, OSP and CSP]

1. Network and Access Segmentation: Segment internal networks and tenant boundaries at the infrastructure level.

2. Implement VLANs and firewall rules to enforce tenant separation. Use virtualization and network controls (e.g., subnets, ACLs) to isolate workloads and environments.

3. Continuously monitor tenant interactions with logging and AI-driven anomaly detection: Use tools like SIEMs, behavioral analytics, or ML-based threat detection to detect misuse, lateral movement, or data leakage.

4. Zero Trust Architecture (ZTA) principles: Enforce microsegmentation, continuous verification, and minimal implicit trust across services and users.

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 Orchestrated Service Providers (OSP)

1. Ensure all inter-service communications in cloud environments are encrypted.

2. Implement automated security checks before and after migrations.

3. Monitor API and network traffic for anomalies during migrations.

[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 Orchestrated Service Providers (OSP)

1 Maintain detailed network documentation for AI orchestration layers.

1. Implement monitoring and logging for high-risk network segments.

2. Ensure compliance with security frameworks for cloud networking.

[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 Orchestrated Service Providers (OSP)

1. Implement network segmentation and zero-trust security models.

2. Deploy AI-driven security analytics for anomaly detection.

3. Ensure continuous monitoring of AI orchestration layers.

[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 Orchestrated Service Providers (OSP)

1. Establish logging and monitoring procedures covering orchestration pipelines, API requests, infrastructure modifications, and failure recovery events.

2. Ensure policies address logging for load balancing, scaling, orchestration failures, communication between subsystems, and incident response - activities.

3. Regularly review and update policies based on changes in deployment frameworks or orchestration tools.

[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 Orchestrated Service Providers (OSP)

1. Ensure secure handling of logs generated by orchestration processes, including pipeline execution, model deployment, and configuration changes.

2. Implement controls to prevent unauthorized modification of logs, including hashing and timestamping mechanisms.

3. Periodically validate log integrity and availability for auditing purposes.

[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 Orchestrated Service Providers (OSP)

1. Monitor orchestration systems for anomalies, including failures, unauthorized access attempts, pipeline executions, deployment rollouts, CI/CD credential use and API traffic or malicious requests.

2. Implement automated alerting systems for detecting suspicious activities within the infrastructure.

[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 Orchestrated Service Providers (OSP)

1. Protect logs for pipeline execution, deployment, scaling and API-gateway traffic; hash/timestamp each record.

2. Log configuration changes in orchestrators (e.g., Kubernetes, Apache Airflow) and surface integrity results to tenants.

3. Update detection rules as pipelines or cluster addons evolve to maintain high-quality alerts.

[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 Orchestrated Service Providers (OSP)

1. Monitor orchestration systems: pipeline executions, deployment roll-outs, scaling actions, API-gateway traffic and cluster-config changes for anomalies.

2. Regularly update monitoring and response mechanisms to adapt to new threats and changes in deployment infrastructure (e.g. pipeline plugins, Kubernetes versions or CI/CD tooling changes).

3. Implement distributed logging frameworks compatible with orchestration tools (e.g., Kubernetes, Apache Airflow).

4. Hash/timestamp orchestration logs and feed them into distributed detection engines; flag unauthorised role escalation, unexpected container images.

[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 Orchestrated Service Providers (OSP)

1. Configure cluster nodes, pipeline runners and API gateways to the same time hierarchy; expose drift metrics on the ops dashboard.

2. Auto-quarantine nodes whose drift exceeds policy until re-sync succeeds.

[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 Orchestrated Service Providers (OSP)

1. Establish comprehensive logging for orchestration activities, including deployments, pipeline executions, scale-out/in events, API-gateway activities or API interactions, cluster-config changes and service-discovery updates.

[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 Orchestrated Service Providers (OSP)

1. Define sanitization requirements for orchestration-specific sensitive data, including tenant credentials, container secrets, environment variables, workflow parameters, service mesh authentication tokens, and cross-tenant identifiers.

2. Implement tenant isolation in sanitized logs to ensure one tenant’s sensitive data cannot be exposed in another tenant’s accessible logs or aggregated analytics.

3. Configure orchestration service logging as applicable, such as container runtime logging, Kubernetes audit logging, service mesh logging, and infrastructure-as-code (IaC) deployment logs, to sanitize secrets, credentials, and sensitive configuration data before log persistence.

4. Test sanitization effectiveness across multi-tenant scenarios, including cross-tenant log aggregation, autoscaling events, and failover operations.

5. Review and update sanitization rules when introducing new orchestration features, container runtimes, or multi-tenant security enhancements.

[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 Orchestrated Service Providers (OSP)

1. Log pipeline and deployment events (CI/CD triggers, resource provisioning).

2. Maintain multi-tenant environment audits, detecting cross-tenant anomalies or misconfigurations.

[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 Orchestrated Service Providers (OSP)

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 Orchestrated Service Providers (OSP)

[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 Orchestrated Service Providers (OSP)

[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 Orchestrated Service Providers (OSP)

[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 Orchestrated Service Providers (OSP)

[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 Orchestrated Service Providers (OSP)

1. Ensure tenant isolation for logs and enable unified dashboards or alerts for rapid anomaly detection.

[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 Orchestrated Service Providers (OSP)

[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 Orchestrated Service Providers (OSP)

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 Orchestrated Service Providers (OSP)

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 Orchestrated Service Providers (OSP)

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 Orchestrated Service Providers (OSP)

1) Extend templated Model Cards with additional deployment-specific information, such as:

• Service-level performance metrics and SLAs

• Integration and dependency details

• Operational monitoring and alerting configurations

• Security and compliance measures implemented in the deployment environment.

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 Orchestrated Service Providers (OSP)

[Orchestrated Service Provider (OSP)]

1. Automated Validation Process- extract the fields from the model card for a) Source Information, b) Creation Date and c) Version Control- match the extracted fields against the values derived from the deployed model- highlight any conflicts between model card values and values derived from deployed model.

[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

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 Orchestrated Service Providers (OSP)

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 Orchestrated Service Providers (OSP)

Not Applicable (Access to model artifacts and weights is needed for robustness (hardening) training)

MDS-08: Model Integrity Checks

Control Specification

Regularly calculate and compare checksums using cryptographic hashes of model checkpoints to detect unauthorized modifications. Apply at least annually based on the level of risk, or after any change of hands.

Shared Implementation Guidelines

[Shared Responsibilities (Applicable to MP, OSP, AP)]

1. Comparison of checksums should be applied both in production and test environment at least annually based on the level of risk, or during any change of hands.

Implementation Guidelines for Orchestrated Service Providers (OSP)

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

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 Orchestrated Service Providers (OSP)

[Shared Responsibilities (MP, OSP, AP, CSP)]

1. Model signatures should be verified whenever the model is changing hands or being moved between locations.

2. Signing keys or identities should be clearly associated with the code producers, ensuring an unambiguous link to the corresponding code as the owning entity. Public registries should be used wherever possible to support this association.

3. Only verified models and model files from trusted sources should be loaded or used in applications.

4. Enforce automated signature verification at model loading time to prevent unauthorized or tampered models from being used.

5. Maintain a model signing and verification audit log, documenting all signature validations, transfers, and ownership changes for traceability.

MDS-10: Model Continuous Monitoring

Control Specification

Define, implement, and evaluate processes, procedures, and technical measures for continuous monitoring of model performance metrics over time to identify sudden shifts or unexpected changes in predictions that could degrade model performance.

Shared Implementation Guidelines

[Shared Responsibilities (MP, AP)]

1. Revising or optimizing the prompts used in applications to ensure they generate accurate and relevant outputs, particularly as the model evolves or data context shifts.

2. Continuously monitor these metrics for signs of drift or unexpected changes leveraging Model Observability Platforms.

3. Set up automated alerts to notify stakeholders when significant deviations or anomalies are detected.

Implementation Guidelines for Orchestrated Service Providers (OSP)

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 Orchestrated Service Providers (OSP)

[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

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 Orchestrated Service Providers (OSP)

[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 Orchestrated Service Providers (OSP)

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

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 Orchestrated Service Providers (OSP)

1. Define a structured policy for AI incident response, including rollback and containment strategies to be triggered upon incident detection.

2. Establish a change control policy specific to orchestration layers (e.g., pipeline updates, CI/CD automation) to enforce version control and auditability.

3. Develop a formal policy for runtime access and privilege elevation during orchestration tasks, aligned with least privilege principles.

4. Define a policy for continuous monitoring and anomaly detection during AI model orchestration, incorporating thresholds for automated responses.

5. Maintain documentation and approval workflows for orchestration policy exceptions and emergency overrides.

[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 Orchestrated Service Providers (OSP)

1. Enforce deployment policies that include gatekeeping for model integrity and security checks.

2. Automate service scaling and resilience features with compliance-aware guardrails.

3. Document service dependencies and ensure disaster recovery strategies cover AI workloads.

[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 Orchestrated Service Providers (OSP)

1. Implement containment and recovery procedures and mechanisms (e.g. isolate, suspend, or roll back) compromised orchestration workloads or services supporting AI systems.

2. Use runtime policy enforcement or workload security controls to detect anomalous behavior within orchestration environments, such as unauthorized service calls, unexpected API interactions, or abnormal resource usage.

3. Maintain infrastructure telemetry, logging, and audit records sufficient to support forensic investigation and reconstruction of events during security incident analysis.

[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 Orchestrated Service Providers (OSP)

1. Conduct simulations of incidents affecting AI deployment pipelines, such as compromised CI/CD components, unauthorized configuration changes, or manipulation of model deployment artifacts.

2. Test orchestration-level containment and recovery procedures, including workload isolation, service failover, and rollback of orchestration policies or deployment configurations.

3. Review telemetry, logs, and detection signals generated during exercises/testing to evaluate the effectiveness of monitoring controls and improve orchestration resilience.

[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 Orchestrated Service Providers (OSP)

1. Measure responsiveness to pipeline failures, misconfigurations, and runtime anomalies affecting AI deployments.

2. Maintain logs for incident resolution efficiency across orchestrated workflows.

[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 Orchestrated Service Providers (OSP)

1. Triage failures in deployment pipelines, policy violations, and suspicious system behavior across orchestrated components.

2. Enable fine-grained logging for service handoffs and model promotion events.

[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 Orchestrated Service Providers (OSP)

1. Classify incidents affecting deployment pipelines or environment integrity separately from model-level issues.

2. Correlate with runtime telemetry to estimate scope of impact.

3. Investigate orchestration pipelines, deployment environments, and runtime infrastructure for configuration issues or execution anomalies.

4. Maintain infrastructure telemetry, logging, and audit records sufficient to support forensic investigation and reconstruction of events during security incident analysis.

[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 Orchestrated Service Providers (OSP)

1. Communicate pipeline integrity violations that could have introduced insecure model versions into production.

2. Include rollback confirmation and timeline of exposure in disclosures.

[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 Orchestrated Service Providers (OSP)

1. Record incidents arising from unauthorized model promotions, security policy enforcement failures, unauthorized access to orchestration pipelines, and exploitation of service chaining or inter-component trust relationships.

2. Maintain audit trails for service handoff and model promotion events, capturing metadata (e.g., model version, data lineage, pipeline stage) to support forensic investigation of security incidents spanning multiple orchestrated components.

[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 Orchestrated Service Providers (OSP)

1. Define contacts for service-level security, deployment failures, and incident automation tooling.

2. Maintain vendor support escalation channels.

[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 Orchestrated Service Providers (OSP)

Role Specific:

1. Establish service-delivery SCRM policies for: Workforce and subcontractor security management, Client data handling and processing security, Tool and platform security for service operations.

2. Implement OSP-specific verification controls including: Requiring attestations from tool providers and subcontractors, Maintaining chain-of-custody evidence for client data, Documenting service delivery quality assurance processes.

3. Integrate SCRM into service workflows by: Adding security checkpoints in data processing pipelines, Implementing access controls for distributed workforces, Maintaining audit trails for service delivery activities.

[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 Orchestrated Service Providers (OSP)

Role Specific:

1. Establish service orchestration SSRM procedures covering API gateway security policies, service mesh configuration requirements, multi-tenant isolation protocols, and service integration security standards specific to platform operations.

2. Document OSP-specific SSRM procedures for: Data annotation/moderation quality assurance and validation, Secure data transfer and return protocols, Incident response for service delivery disruptions.

3. Develop approval workflows for: Subcontractor security requirement modifications, Client data handling procedure updates, Service tooling security configuration changes.

4. Establish consolidated assurance delivery policies covering upstream security evidence aggregation procedures, customer communication protocols for security status, and coordinated incident response procedures with both upstream and downstream partners.

[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 Orchestrated Service Providers (OSP)

Role Specific:

1. Apply SSRM requirements to workforce and subcontractor management by: Implementing security controls for temporary and distributed workforces, Ensuring subcontractors comply with data handling and confidentiality requirements, Applying access controls based on the principle of least privilege for service delivery.

2. Document service delivery SSRM processes covering service integration security workflows, consolidated logging procedures, incident coordination mechanisms, and performance monitoring across the entire service orchestration platform.

3. Implement service-specific risk management by: Assessing risks related to workforce turnover and subcontractor reliability, Managing data quality and validation process security, Addressing service delivery continuity and incident response.

4. Manage upstream provider SSRM integration through specialized coordination with Model Providers for secure model API access, CSPs for infrastructure security alignment, and third-party services for platform integration security.

[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 Orchestrated Service Providers (OSP)

Role Specific:

1. Provide service integration SSRM guidance detailing how customers should securely configure and consume OSP services, including API security requirements, service level expectations, and integration monitoring responsibilities.

2. Document consolidated supply chain SSRM compliance in customer guidance, explaining how upstream security from Model Providers and CSPs flows through OSP services to support customer risk management decisions.

3. Create service orchestration responsibility matrices that clearly delineate OSP security responsibilities (service integration, platform management, upstream coordination) versus customer responsibilities (application security, user management, configuration compliance).

4. Establish service delivery communication channels for ongoing SSRM guidance updates, including service security notifications, platform changes affecting customer security, and evolving best practices for secure service consumption.

[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 Orchestrated Service Providers (OSP)

Role Specific:

1. Establish clear ownership boundaries between client data handling, workforce management, and service quality responsibilities to ensure complete coverage of OSP-specific risks.

2. Define escalation paths for service-specific security issues that ensure rapid response to data breaches, quality failures, or subcontractor security incidents.

3. Delineate upstream integration control ownership between integration teams for Model Provider API management, security teams for Service Assurance Documentation validation, and vendor management teams for supplier relationship oversight.

4. Delineate multi-tenant service control ownership between infrastructure teams for resource allocation, security teams for tenant isolation validation, and monitoring teams for cross-tenant security oversight.

[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 Orchestrated Service Providers (OSP)

Role Specific:

1. Specifically review and validate service delivery SSRM documentation including: Data handling and processing procedures for client AI data, Workforce training and security compliance records, Subcontractor management and oversight documentation.

2. Validate that service-level documentation accurately reflects: Quality assurance and validation processes, Secure data transfer and return procedures, Incident response plans for service-specific issues (data breaches, quality failures)

3. Ensure tool and platform documentation is current and complete, covering: Software and tool security configurations, Access controls for annotation/platform systems, Integration security with client AI systems.

4. Validate service orchestration documentation including service discovery configurations, inter-service communication security, monitoring and logging procedures, and service coordination workflows across the integrated platform.

[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 Orchestrated Service Providers (OSP)

Role Specific:

1. Implement service orchestration security controls including API gateway security configurations, service mesh protection, inter-service communication encryption, and service discovery access controls.

2. Operate multi-tenant service isolation controls covering tenant separation mechanisms, resource allocation controls, cross-tenant data protection, and service level monitoring across customer workloads.

3. Audit service integration security controls including regular assessment of upstream Model Provider integrations, downstream Application Provider handoffs, and consolidated service delivery security effectiveness.

4. Maintain Service Assurance Documentation processes ensuring accurate representation of implemented security controls, regular updates reflecting service changes, and proper evidence consolidation from upstream providers.

5. Implement service delivery monitoring controls covering real-time security event detection, service performance monitoring, incident escalation procedures, and consolidated logging across the service orchestration platform.

6. Operate service coordination security controls including secure configuration management, change control procedures, and security validation for service updates and integrations.

[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 Orchestrated Service Providers (OSP)

Role Specific:

1. Document cloud infrastructure and platform relationships covering hosting providers, API gateway services, load balancers, monitoring tools, and service mesh components with configuration details and dependency mappings.

2. Catalog downstream Application Provider relationships including all customers consuming OSP services, integration requirements, service level commitments, and support obligations with usage patterns and performance metrics.

3. Inventory middleware and integration service dependencies documenting third-party API services, authentication providers, logging services, caching solutions, and orchestration platforms with version tracking and supplier information.

4. Maintain service delivery chain relationships including backup service providers, failover partners, content delivery networks, and disaster recovery services with activation procedures and dependency hierarchies.

5. Document operational support relationships covering monitoring service providers, incident response partners, maintenance contractors, and specialized OSP platform support services with contact information and service scope definitions.

[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 Orchestrated Service Providers (OSP)

Role Specific:

1. Maintain BOMs for orchestration stacks including Helm charts, IaC modules, deployment templates, and automation scripts.

2. Ensure BOM updates are version-controlled and reviewed during change approvals.

3. Monitor third-party tools integrated into orchestration workflows for vulnerabilities.

4. Integrate SBOM generation into CI/CD pipelines for reproducibility.

5. Use BOM data to support compliance or incident response when orchestration components are implicated.

[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 Orchestrated Service Providers (OSP)

Role Specific:

1. Assess service orchestration risks including API gateway security failures, service mesh vulnerabilities, inter-service communication breaches, and service discovery system compromises.

2. Cross-model monitoring: Compare outputs across different models in a pipeline to detect anomalies or adversarial drift.

3. Develop contingency plans for critical service dependencies, multi-service failure scenarios, and service orchestration breakdowns that could impact integrated service delivery.

4. Ensure runtime resilience. For example, if one model exhibits signs of poisoning or evasion, automatically switch to a backup or ensemble.

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

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 Orchestrated Service Providers (OSP)

Role Specific:

1. Include service orchestration provisions in agreements with Model Providers specifying API integration requirements, service level guarantees, model update handling procedures, and service mesh security obligations.

2. Define middleware and integration terms in contracts including API gateway responsibilities, load balancing commitments, service discovery requirements, and multi-tenant isolation provisions.

3. Specify Service Assurance Documentation delivery obligations in downstream agreements with Application Providers including consolidated upstream compliance status, service integration security evidence, and performance reporting requirements.

4. Establish service integration provisions covering end-to-end service delivery responsibilities, upstream vendor coordination obligations, and consolidated incident response procedures.

5. Define multi-service orchestration terms including service dependency management, cascading failure prevention, and integrated monitoring across the service delivery chain.

[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 Orchestrated Service Providers (OSP)

Role Specific:

1. Establish and regularly review contractual and operational agreements that define security responsibilities across chained services or APIs. OSPs typically orchestrate multiple upstream and downstream services, and must ensure each service’s role in the security boundary is contractually and operationally clear. E.G. When composing services that invoke multiple AI APIs, ensure SLAs and security clauses reflect risks introduced by inter-service latency, failures, or data leakage.

2. Evaluate middleware and integration platform agreements for service delivery requirements such as API gateway terms, load balancing provisions, and service mesh security obligations.

3. Assess downstream service agreements with Application Providers to ensure Service Assurance Documentation delivery obligations, API reliability commitments, and service integration support requirements remain adequate.

4. Review multi-tenant service agreements to verify isolation guarantees, resource allocation terms, and cross-customer security provisions meet evolving service delivery needs.

5. Update service level agreement terms based on reviews to reflect changes in service orchestration capabilities, integration security requirements, or shifts in customer service consumption patterns. Pay special attention to liability and indemnification clauses related to service errors, data quality issues, or breaches originating from the OSP’s operations.

[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 Orchestrated Service Providers (OSP)

Role Specific:

1. Conduct internal audits to validate that all employees and subcontractors involved in service delivery have completed required security training, signed confidentiality agreements, and are adhering to documented data handling procedures. This involves reviewing training records and access logs.

2. Perform periodic reviews of the software and tools used to deliver the service (e.g., annotation platforms, data processing tools). Verify that they are configured according to security policies, are included in the SBOM, and that their use conforms to client agreements.

3. If using subcontractors, internally assess the process for onboarding and managing them. This includes validating that contracts flow down security requirements and that there is a process for verifying their compliance (e.g., checking their SOC 2 reports).

4. Periodically review and test the evidence that makes up the “OSP Assurance Pack” (compliance reports, procedures documents) to ensure it is accurate, up-to-date, and provides a true representation of the security posture to clients.

5. Test Incident Response Readiness for Service Breaches: Conduct tabletop exercises or simulations based on service-specific scenarios (e.g., a data breach within the labeling platform, a subcontractor leaking data). Measure the response against the documented incident response plan and SLA commitments to clients.

[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 Orchestrated Service Providers (OSP)

Role Specific:

1. Establish comprehensive compliance policies for Model Providers, cloud infrastructure providers, API gateway services, monitoring tools, third-party integrations, and managed services covering information security, data confidentiality, access control, privacy protection, audit requirements, personnel policies, and service level standards.

2. Require contractual commitments from all service providers including: Model Providers to comply with model security and data handling standards, Cloud providers to meet infrastructure security and availability requirements, API services to follow access control and data transmission security policies, Monitoring services to adhere to data privacy and audit logging standards.

3. Monitor service provider compliance through service performance monitoring, security incident tracking, access control audits, and periodic compliance reporting from all suppliers involved in service delivery.

4. Enforce compliance consequences including service restrictions, provider replacement, or remediation requirements for suppliers who fail to meet OSP security, privacy, and service level standards.

5. Document compliance status in Service Assurance Documentation for handover to Application Providers, providing consolidated evidence of upstream and OSP compliance posture throughout the service delivery chain.

6. Keep a central register that links each client contract to the specific subcontractor agreements and tooling vendors used to fulfill that service. This provides a clear audit trail to demonstrate how requirements are flowed down and enforced across the OSP operations.

[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 Orchestrated Service Providers (OSP)

Role Specific:

1. Conduct periodic governance reviews of Model Providers, cloud infrastructure providers, API gateway services, monitoring tools, and third-party integration partners to assess their IT governance policies and operational procedures.

2. Evaluate partner governance maturity including their service level management, incident response governance, data processing controls, and security oversight frameworks.

3. Require governance evidence from suppliers including:

   • Service governance documentation and SLAs

   • Model Security Manifests from Model Providers

   • Infrastructure compliance reports from CSPs

   • API security and change management policies.

4. Prepare Service Assurance Documentation for handover to Application Providers, including:

   • Summary of upstream governance reviews (MP and CSP status)

   • OSP’s own governance policies and controls

   • Service integration security practices

   • Clear delineation of shared responsibilities.

5. Verify ongoing governance alignment through regular service reviews, ensuring partners maintain governance standards for services that impact OSP operations.

6. Document governance review outcomes and integrate findings into service risk assessments, partner management processes, and customer-facing assurance materials.

7. Maintain governance transparency by providing Application Providers with evidence of both OSP governance practices and upstream partner governance status.

[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 Orchestrated Service Providers (OSP)

Role Specific:

1. Train internal teams including application developers, DevOps engineers, security personnel, and customer support staff on SSRM policies and supply chain security risks.

2. Provide ongoing security awareness training for all roles involved in integrating AI models, managing APIs, handling customer data, and maintaining service infrastructure.

3. Require contractual commitments from third-party vendors (model providers, cloud infrastructure providers, API services, monitoring tools) to maintain SSRM-compliant training for personnel who handle OSP systems or data.

4. Verify vendor training compliance through security assessments, certifications, and regular audits of supplier security practices.

5. Establish clear security requirements and communication protocols with upstream model providers and downstream application integrators regarding their SSRM training obligations.

[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 Orchestrated Service Providers (OSP)

1. Continuously scan orchestration components and API gateways for vulnerabilities.

2. Validate that CI/CD pipelines rebuild images with patched base layers

[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 Orchestrated Service Providers (OSP)

1. Scan container images, pipeline scripts and plugin code before deployment.

2. Provide sandbox execution for untrusted plugins and monitor egress traffic for exfiltration patterns.

[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 Orchestrated Service Providers (OSP)

1. Identify vulnerabilities across orchestration platforms, infrastructure, containers, and managed services using automated scanning and threat intelligence sources (e.g., CVEs, vendor advisories).

[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 Orchestrated Service Providers (OSP)

1. Scope threat models to application-layer threats (e.g., insecure APIs, broken authentication, injection, insecure integration).

2. Map threats against CI/CD and workflow engines (e.g., supply-chain injection, malicious pipeline plugins)

[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 Orchestrated Service Providers (OSP)

[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 Orchestrated Service Providers (OSP)

1. Enforce policy checks for container images lacking an SBOM or containing components with unresolved high-risk CVEs.

[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 Orchestrated Service Providers (OSP)

[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 Orchestrated Service Providers (OSP)

[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 Orchestrated Service Providers (OSP)

1.Prioritize vulnerabilities in orchestration platforms, containers, and infrastructure based on system criticality, exploitability, and potential impact to service availability and operations.

[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 Orchestrated Service Providers (OSP)

1. Map threat vectors across composite AI workflows (data pre-processing, model chaining).

2. Use threat management to detect dependency attacks or orchestrated misuse.

3. Ensure prioritized mitigation aligns across supply chain (e.g., verify attestation from Model and App Providers).

4. Employ automated rollback and fault isolation for compromised components.

[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 Orchestrated Service Providers (OSP)

[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 Orchestrated Service Providers (OSP)

[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 Orchestrated Service Providers (OSP)

1. Enforce guardrails across pipelines by blocking or quarantining workloads that violate input / output policies.

[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 Orchestrated Service Providers (OSP)

1. Endpoint Policies: Document and enforce endpoint security policies specific to administration and orchestration consoles, including patch levels, access controls, and usage restrictions.

2. Application Approval: Curate an approved catalog of administrative tools and services, reviewing and updating it periodically, and enforce through application control policies in the UEM platform.

3. Compatibility Testing: Maintain a compatibility matrix for orchestration infrastructure endpoints, conducting compatibility testing for OS upgrades or security agent changes prior to deployment.

4. Inventory Reconciliation: Track and reconcile all administrative endpoints in a centralized inventory, leveraging automated discovery and monthly audits to detect unauthorized 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 Orchestrated Service Providers (OSP)

1. Define an approved catalog of applications and services for any endpoint used in administering the AI service (for instance, approved remote administration tools, security software, and communication channels).

2. Ensure personnel use only these authorized tools to access or manage the orchestration environment, thereby reducing exposure from unsanctioned software.

3. Periodically re-evaluate and update the list of approved admin tools in line with security best practices and operational needs, obtaining proper approval for any changes.

4. Implement enforcement measures so that OSP-managed devices cannot run or install software outside of the approved set (using endpoint management settings or application control policies).

[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 Orchestrated Service Providers (OSP)

1. Communicate and document the orchestrated service’s supported endpoint configurations (approved OS versions, required hardware/software) and update this compatibility matrix with input from Model and Application Providers as platforms change.

2. Test the integrated AI solution (model and application components) on upcoming OS or software updates in a staging environment to catch any compatibility issues before the AI Customer deploys them widely.

3. Coordinate with the Model and Application Providers to resolve any discovered compatibility problems (through software updates or configuration changes) and confirm that all components remain compatible with the AI Customer’s standard endpoint environment.

4. Work with the AI Customer to incorporate compatibility checks into the service workflow (for example, detecting unsupported device OS versions) and proactively communicate any identified incompatibilities or needed endpoint upgrades.

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

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 Orchestrated Service Providers (OSP)

1. Maintain a current inventory of all OSP-managed systems (orchestration servers, integration components, admin devices, etc.) that store or access the AI solution’s data.

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. Provide the AI Customer with regular updates on the OSP’s endpoints (or integrate OSP device records into the consumer’s asset management system) to ensure these assets are included in the overall inventory.

4. Employ automated discovery or monitoring tools in the OSP environment to detect any new or unauthorized systems connected to the service, updating the inventory immediately and addressing any unrecognized devices.

5. Collaborate with the Model and Application Providers to gather and validate their endpoint information related to the AI service, helping maintain a complete inventory across all participating providers.

[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 Orchestrated Service Providers (OSP)

1. Enroll all OSP-controlled devices (e.g., orchestration platforms, management consoles) in the AI Customer’s endpoint management program to enforce the required security baseline on those systems.

2. Keep OSP systems fully compliant by promptly applying mandated patches, security software updates, and configuration settings, and continuously monitoring each device for any deviations from policy to remediate them immediately.

3. Work with the Application and Model Providers to ensure any of their systems interfacing with the orchestration (such as application servers or model hosts) meet the AI Customer’s endpoint security requirements and are subject to equivalent controls.

4. Report the compliance status of OSP-managed endpoints to the AI Customer on a regular basis, including any incidents of non-compliance (and the remediation actions taken) for transparency and accountability.

[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 Orchestrated Service Providers (OSP)

1. Mandate automatic screen locking on all orchestration service provider devices that interface with the AI environment – for example, laptops used by cloud administrators or technicians managing deployment pipelines must lock quickly when not in use.

2. Enforce idle timeout settings through the UEM or operating system policies: ensure OSP administrative consoles, whether on-premises or remote, are configured to lock or log out after the approved inactivity period and require a strong credential to unlock.

3. Integrate this requirement into staff onboarding and training, so OSP personnel understand to never leave an unlocked session unattended and to manually invoke a lock (Ctrl+Alt+Del or equivalent) when stepping away, in addition to the automatic trigger.

4. Periodically audit OSP-managed endpoints for compliance by reviewing device configuration snapshots or running spot tests (e.g., attempt to wake a sample of unattended machines to confirm they are locked), and correct any deviations immediately.

[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 Orchestrated Service Providers (OSP)

1. Adhere to formal change management for endpoints used in orchestration and administration of the AI service. Any change on an OSP-managed admin device or configuration (such as updating the orchestration software on a control laptop or changing a network setting on an admin tablet) should go through a documented review and approval process.

2. Plan changes in advance and communicate them. For instance, if the OSP needs to install a new version of a cloud orchestration tool on all admin machines, announce a maintenance window to the team and potentially to the CSP and AP if their operations might be impacted, ensuring everyone knows when and what is changing.

3. Utilize automation where possible to manage changes at scale. If a security patch is approved for all OSP devices, use the UEM or patch management system to deploy it systematically under the change ticket, rather than ad-hoc manual updates. Automation helps ensure consistency and provides logs of deployment results.

4. Include back-out plans for each change in case something goes wrong. For example, if a new endpoint security agent version is deployed and it causes system instability, the OSP change plan should specify how to revert to the previous version. Having clear rollback procedures as part of the change record ensures the AI service remains stable and secure even if a change has unforeseen issues.

[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 Orchestrated Service Providers (OSP)

1. Ensure all orchestrator-owned endpoints and any on-site servers or appliances contain only encrypted storage. Administrative consoles that manage AI deployments often hold highly sensitive credentials and configuration data; encrypting their drives protects this information if the device falls into the wrong hands.

2. Use centralized policy enforcement to require encryption and verify it. The OSP’s IT management tools should automatically detect if an endpoint does not have encryption enabled and then initiate the encryption process or block the device’s access until compliance is achieved.

3. Include stipulations in the OSP’s internal security policy that no sensitive data should be stored outside encrypted volumes. If OSP staff need to use removable media (USB drives, etc.) to transfer logs or configuration files, those media should be encrypted as well, or the files themselves should be in encrypted containers.

4. Provide training and support to OSP personnel about encrypted devices: for example, instruct them on how to verify their device’s encryption status and what to do if they see encryption is off. Make it clear that disabling encryption is not permitted and outline disciplinary action or technical controls to prevent that from happening.

[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 Orchestrated Service Providers (OSP)

1. Protect all orchestration service provider endpoints with advanced anti-malware/EDR solutions configured in a hardened mode. OSP admin devices often have elevated permissions, so the anti-malware on these should be configured not just for basic virus scanning but for aggressive monitoring of suspicious behaviors (e.g., unusual PowerShell execution, persistence mechanisms) that could indicate a targeted attack.

2. Enable centralized logging and analysis for the anti-malware running on OSP devices. All events (like malware blocked, suspicious file detected, or user attempts to override the agent) should feed into a central dashboard the OSP security team reviews daily. This helps catch subtle signs of attack that automated responses alone might not flag.

3. Enforce that OSP personnel cannot disable or ignore anti-malware alerts. Remove local administrative rights if necessary, so that the anti-malware agent cannot be shut off by the user. If maintenance is needed (like a performance issue with the scanner), it should be done in coordination with security to ensure continuous protection.

4. Test the anti-malware effectiveness on OSP endpoints through simulated attack exercises. For example, run benign test files that are flagged as malware (like the EICAR test file) on a sample admin machine to ensure the agent catches them, or engage in periodic red-team exercises where an internal security tester attempts to introduce a benign code execution to see if the EDR’s behavior analytics catch the activity. Use results to fine-tune the configuration.

[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 Orchestrated Service Providers (OSP)

1. Lock down network access on OSP-administered endpoints via host firewall rules that complement network-level firewalls. Even if the data center or cloud environment has perimeter defenses, assume an OSP admin device could be isolated or on an untrusted network and thus rely on its own firewall as the first line of defense.

2. Only allow management protocols and services that are necessary on orchestration devices. For example, if an orchestration admin workstation only needs to access the cloud provider’s API endpoints and the internal monitoring system, configure its firewall to allow outbound traffic only to those specific services/addresses, and block other outbound traffic which could indicate misuse or compromise.

3. Use host firewall logs for security oversight. Ensure logging is enabled for blocked connection attempts on OSP machines. These logs can reveal if someone/something is trying to access an admin device inappropriately (e.g., a malware on the local network scanning for open ports). The OSP security team should periodically review these logs or set alerts for unusual spikes.

4. If OSP personnel sometimes work remotely, enforce that their devices use a local firewall profile appropriate for public networks. For instance, when not on the corporate LAN, their laptop firewall might automatically switch to a stricter rule set (public profile) that blocks all inbound traffic and only allows outbound VPN. Configure this via group policy and test it to ensure it triggers correctly based on network identification.

[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 Orchestrated Service Providers (OSP)

1. Implement DLP controls on devices used by the orchestration service provider to ensure that critical system information (like deployment scripts, configuration files, or credentials) isn’t leaked. For instance, set DLP rules to detect files containing API keys, passwords, or IP addresses of critical infrastructure, and block attempts to transfer those outside the trusted network or save them in unapproved locations.

2. Monitor administrative interfaces for potential data exfiltration. If OSP admins use web dashboards or terminals, consider DLP-like monitoring of copy/paste activities. For example, if an admin copies a large chunk of configuration from a console, the system could log that or prevent copying to a plain text file, since that could be a data leak vector.

3. Ensure that DLP policies consider both intentional and accidental data loss. An OSP engineer might accidentally attach the wrong file to a ticket or email (e.g., a config file with secrets). The DLP should ideally scan attachments and block those that contain forbidden content, prompting the user to double-check.

4. Coordinate with the CSP and AP on cross-environment DLP events. For example, if the OSP’s DLP agent blocks an attempt to move data that actually originated from the AI application (AP domain) or from the cloud logs (CSP domain), have a communication channel to alert the relevant party. This helps everyone get a full picture of potential leakage attempts across the supply chain.

[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 Orchestrated Service Providers (OSP)

1. Activate remote tracking for orchestration service provider devices, especially those that are mobile by nature (laptops taken home by on-call engineers, tablets used in data centers, etc.). Knowing where these devices are can be crucial given they likely have credentials or access to the AI service infrastructure.

2. Implement a geo-fencing policy for particularly sensitive OSP devices. For instance, if an admin laptop is expected to only be used within the OSP’s office, get an alert if its location is detected far outside that area (indicating it might have been taken unexpectedly off-premises). This could prompt an immediate check-in with the user or pre-emptive security measures.

3. Combine geo-location with other telemetry for robust security. If a device is reported lost and its last location was, say, at an airport, you might immediately decide to remote-wipe it (UEM-13) in addition to tracking. Conversely, if a device is misplaced in the office building, you might just use location to find it under a desk rather than wipe it. Having location context helps choose the right action.

4. Keep the geo-location feature tested and up-to-date on OSP devices. Sometimes OS updates can affect location services or users might disable location settings; as part of device compliance, ensure that the ability for the MDM to request location is not turned off. If a device doesn’t report location when requested, treat that as a compliance failure and follow up with the user or service.

[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 Orchestrated Service Providers (OSP)

1. Maintain the ability to remotely erase any OSP-controlled endpoint, particularly those used by administrators, as they often contain the “keys to the kingdom” for the AI service. The moment one of these devices is known to be lost or an admin reports it missing, trigger a remote wipe to preempt any chance of an outsider using it to infiltrate the orchestration environment.

2. Coordinate remote wipe actions with incident response. For example, if an admin device is stolen, a wipe is crucial, but also have a parallel process to investigate if any data from that device was backed up or synced somewhere (did the admin perhaps have local notes that synced to a personal cloud?). The wipe secures the device, but you may need to consider other copies of data. Update the OSP’s procedures to consider those angles.

3. In scenarios where a device cannot be reached for a wipe (e.g., it’s offline), use the management system’s options to issue a wipe command that will execute as soon as the device reconnects. Additionally, put that device’s status as “compromised” in your asset database so that if it somehow comes online in the company network, network access control can quarantine it instantly.

4. Communicate with the CSP and potentially the AIC if a device with high privilege is lost. For instance, if the OSP loses a device that contained credentials or VPN access to the AI infrastructure, after wiping, inform the CSP (and AP if relevant) so they can be on alert for any suspicious activity. This fosters a shared responsibility approach: everyone keeps an eye out in their domain for misuse of the OSP’s lost device credentials.

[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 Orchestrated Service Providers (OSP)

1. Require that any subcontractors or partner companies that interface with the AI orchestration service adhere to the OSP’s endpoint security policies. For example, if you outsource some part of infrastructure management, ensure their engineers follow the same endpoint hardening (patches within X days, no local admin rights unless needed, two-factor authentication on device, etc.). Put these requirements formally in the contract.

2. Control the access path: set up dedicated accounts for third-party users on your systems that are separate from internal accounts, and use an access gateway that can enforce device checks. For instance, an OSP could have a privileged access management (PAM) system where third-party admins must login; that PAM can require they come from a certain device or run certain endpoint software to proceed.

3. Monitor third-party compliance by requesting periodic attestations or reports. You might ask the third-party’s IT/security to provide quarterly confirmation that “All devices used to access OSP systems in the last quarter were fully patched and had no outstanding high-severity vulnerabilities.” This puts responsibility on them to stay secure and keeps it in writing.

4. If a security incident occurs that is traced to a third-party’s endpoint (e.g., their laptop was infected and used to access your admin portal), have an established procedure: suspend their connectivity immediately, investigate the extent of what that device did in your environment, require the third-party to remediate (clean and fortify the device) and possibly perform a security audit on their side before restoring trust. Learn from it to tighten the requirements further if needed (for instance, you might start requiring third-parties to use a company-provided VDI after such an incident).

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