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 Application Providers (AP)

Policy Scope:

1. Audit and assurance policies covering AI feature implementation, user interactions, application-specific controls, and end-user protection measures.

[Applicable to all providers]

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

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

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

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

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

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

A&A-02: Independent Assessments

Control Specification

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

Shared Implementation Guidelines

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

[All Providers: MP, AP, OSP]

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

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

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

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

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

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

Implementation Guidelines for Application Providers (AP)

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 Application Providers (AP)

[Application Provider (AP)] Implementation best practices for this actor include (but are not limited to):

1. Concentrate on integration security, input/output validation controls, and user protection mechanisms.

[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 Application Providers (AP)

[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 Application Providers (AP)

[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 Application Providers (AP)

[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 Application Providers (AP)

1. Implement application and interface security policies covering the implementation of AI features within applications, including secure user authentication, input validation, and protection of application-specific APIs.

2. Policies should address secure integration with OSP or MP services and safeguards for interactive interfaces against threats like XSS, CSRF, or API abuse.

[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 Application Providers (AP)

1. Application baseline security requirements: define baseline security requirements for integrating AI capabilities into applications, covering user authentication, authorization, and data protection.

2. Input validation and output encoding baselines: establish input validation and output encoding baselines to prevent injection attacks and protect against sensitive data leakage to ensure protection against common application-level attacks.

3. Secure coding and testing baselines: specify secure coding practices and testing procedures as part of the application security baseline to ensure AI features are developed and integrated safely.

4. Document the application security baseline for the minimum acceptable security posture, and maintain it in alignment with the MP and OSP baselines and relevant industry standards (e.g., OWASP).

5. Communication with AIC: communicate the application security baseline to the AIC and provide guidance on how to verify compliance to help customers verify the security of the AI-powered application.

6. Establish baseline security requirements for the deployment and operation of AI services, including runtime security and API security.

7. Define baseline security requirements for integrating AI capabilities into applications, including user authentication, authorization, data protection, input validation, output encoding, and secure coding/testing.

[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 Application Providers (AP)

1. Application-level metrics: establish application-level security metrics, such as user authentication success rates, access control violations, and data protection failures to provide insights into the security posture of AI-powered applications.

2. Logging and monitoring mechanisms: implement logging and monitoring mechanisms to capture and analyze application security events.

3. Acceptable thresholds: define acceptable thresholds for each metric based on business risk tolerance and compliance requirements to determine if applications meet risk tolerance and compliance requirements.

4. Real-time monitoring and alerts: monitor application security metrics in real-time and generate alerts for any breaches or anomalies for prompt response to security breaches or anomalies.

5. Regular review and update: regularly review and update application security metrics to align with evolving threats and regulations to ensure application metrics keep pace with evolving threats and regulations.

6. Define application-level security metrics (e.g., authentication success rates, access control violations, data protection failures).

[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 Application Providers (AP)

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

1. Incorporate the secure SDLC process into the development and integration of AI-powered applications.

2. Threat Modelling: Conduct threat modeling and risk assessments to identify and prioritize application-specific security requirements.

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 (OWASP, etc) secure coding guidelines should be incorporated in the secure SDLC, and (iii) secure coding practices 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) to prevent common and AI-specific application security vulnerabilities.

4. Security Testing: Perform thorough security testing, including penetration testing and vulnerability scanning, before releasing applications to end-users.

5. Continuous monitoring and patching: Establish a process for continuously monitoring application security, including tracking and applying security patches and updates.

[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 Application Providers (AP)

1. Integrate automated security testing into the application development lifecycle, covering both the application code and the integration of AI components to ensures comprehensive coverage.

2. Implement static code analysis to identify security vulnerabilities and weaknesses in the application codebase early in the development process, reducing the cost of remediation.

3. Perform dynamic application security testing (DAST) to detect runtime vulnerabilities and issues in the integrated AI functionality.

4. Conduct automated penetration testing to simulate real-world attacks and identify potential exploitation paths.

5. Establish a continuous testing approach that automatically triggers security tests on each code commit and as part of the application release process to ensure catchment of security issues early and prevents the release of insecure applications.

[All Actors]

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

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

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

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

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

AIS-06: Secure Application Deployment

Control Specification

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

Shared Implementation Guidelines

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

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

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

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

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

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

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

Implementation Guidelines for Application Providers (AP)

Policy Scope: Secure deployment strategies for AI-powered end-user applications, including automated deployment of application code, secure integration with OSP or MP services, and protection of user-facing interfaces. Policies should address secure configuration of application dependencies, input validation, and compliance with standards like OWASP ASVS. Automate deployment using CI/CD pipelines with integrated security checks to ensure secure and consistent releases.

[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 Application Providers (AP)

Policy Scope: Remediation processes for vulnerabilities in AI-powered end-user applications, including application code, user authentication systems, and APIs. Policies should address mitigation of threats like XSS, CSRF, or API abuse, and validation of fixes through secure coding practices and testing. Automate vulnerability scanning and remediation within CI/CD pipelines to ensure secure and timely updates.

[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 Application Providers (AP)

Policy Scope:

API security policies cover APIs within AI-powered end-user applications, including secure user authentication, input validation, and protection of app-specific APIs. Address API key management for integrations with OSPs or MPs, regular testing for threats like API abuse or DDoS, and safeguards against client-side attacks (e.g., XSS, CSRF).

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

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

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

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

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

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

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

AIS-09: Input Validation

Control Specification

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

Shared Implementation Guidelines

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

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

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

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

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

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

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

Implementation Guidelines for Application Providers (AP)

Policy Scope: Input validation policies covering AI-powered end-user applications, including user inputs, authentication data, and application-specific APIs. Policies should address protection against adversarial patterns (e.g., XSS, SQL injection), failure patterns (e.g., invalid inputs), and unwanted behavior (e.g., unauthorized access). Implement automated validation and sanitization within CI/CD pipelines and align with standards like OWASP ASVS to ensure secure user-facing interfaces.

[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 Application Providers (AP)

Policy Scope: Output validation policies covering AI-powered end-user applications, including user-facing data, API responses, and application outputs. Policies should address protection against adversarial patterns (e.g., malicious content delivery), failure patterns (e.g., incorrect or incomplete outputs), and unwanted behavior (e.g., non-compliant or offensive content). Implement automated validation and sanitization within CI/CD pipelines and align with standards like OWASP ASVS to ensure secure user-facing outputs.

[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 Application Providers (AP)

1. Apply UI-level guards (prompt filtering, rate limits) and ensure integrated AI components adhere to the same boundary controls as back-end services.

[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 Application Providers (AP)

Policy Scope:

Model development policies cover integration of AI models into end-user applications, including client-side and server-side code. Ensure version control for application code interfacing with models, code reviews for integration logic, and static code analysis of app-specific code within the SDLC. Ensure API calls to MPs or OSPs follow organizational API security controls around access, data security, and logging.

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

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

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

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

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

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

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

AIS-13: AI Sandboxing

Control Specification

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

Shared Implementation Guidelines

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

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

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

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

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

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

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

Implementation Guidelines for Application Providers (AP)

Policy Scope:

Sandboxing policies cover tools and plugins in AI-powered applications (e.g., analytics plugins, update tools). Implement isolated environments through both application-level controls (e.g., browser sandboxes, app containers, process isolation) and network-level segregation (e.g., VPCs, network segmentation, service meshes) where applicable to prevent interactions with critical app data or systems and limit lateral movement to user devices or backend APIs.

[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 Application Providers (AP)

Policy Scope:

Cache security policies cover cache systems in LLM-powered applications (e.g., user session caches, response caches). Implement encryption for cached app data, strict access controls for app-level caches, and mechanisms to avoid retention of sensitive user inputs/outputs in fast memory, mitigating risks of unauthorized access or client-side poisoning.

[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 Application Providers (AP)

Policy Scope:

Input distinction policies cover AI-powered applications interfacing with users (e.g., chatbots, analytics apps). Implement input formatting (e.g., UI-level tagging of user inputs) and standard templates for user-provided instructions, ensuring clarity when passed to MPs or OSPs. Limit ambiguity in app-level instruction processing to prevent misuse or errors.

[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 Application Providers (AP)

[Policy Scope] Application Providers must ensure their solutions incorporating AI components remain functional and secure during adverse events. Responsibilities include:

• Prepare coverage plans that ensure AI-enabled features remain responsive or degrade gracefully during outages.

• Keep well-defined recovery paths for AI modules embedded in customer applications.

• Resilience measures align with service delivery commitments and client expectations.

• Make stakeholders aware of potential points of failure and embedded safeguards.

• Embed responsiveness into both frontend experiences and backend processing layers.

• Routinely test for interruption tolerance and service degradation thresholds.

• Refresh strategies in line with product changes, platform upgrades, or new AI service integrations.

• Crafting and adopting resilience measures relevant to application performance, data integrity, and user access.

• Enforcing automatic recovery, fallback options, and monitoring utilities.

• Conducting regular drills and simulations to test robustness of the application environment.

• Revalidating and revising continuity strategies annually or after significant updates, such as the integration of new AI features or regulatory shifts.

[ 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 Application Providers (AP)

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 Application Providers (AP)

[Policy Scope]

• Build applications to detect and handle inference/API failures gracefully.

• Enable local caching or stub inference when model APIs are down.

• Provide transparent fallback UX to users using graceful degradation patterns, when AI functions are unavailable.

• Document dependencies on AI models and services in the application codebase.

• Integrate application-level RTO/RPO thresholds and auto-scaling logic.

[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 Application Providers (AP)

[Policy Scope]

• Enable graceful degradation and data consistency following synchronization after disruptions.

• Develop offline capabilities reducing real-time service dependencies.

• Create caching strategies preserving recent outputs.

• Conduct backend service interruption simulations

• Validate user experience during degraded operations

[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 Application Providers (AP)

[Policy Scope]

• Create feature inventories identifying AI dependencies and criticality levels.

• Document user experience designs for degraded operation modes.

• Maintain interface specifications with graceful degradation patterns.

• Preserve caching strategies and offline operation capabilities.

• Develop user communication templates for various disruption scenarios.

• Create wireframes showing interfaces during normal and limited operations. – Maintain verification methods confirming successful user experience recovery.

[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 Application Providers (AP)

[Policy Scope]

• AI System Unavailability: Validate fallback to simplified functionality by temporarily disconnecting from AI services during controlled periods.

• Introduce artificial latency to test timeout and retry mechanisms.

• Data Synchronization Challenge: Test recovery after offline operation periods.

• User Experience Continuity: Engage real users(can be beta testers) in simplified journey testing during scheduled exercises. Assess interface adaptations during degraded service.

• Feature Prioritization Drill: Practice selective capability management under constraints.

[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 Application Providers (AP)

[Policy Scope]

1. Key Stakeholder Matrix:

   • Internal Teams: Product management, customer support, and engineering

   • Direct Customers: End users and organizational administrators.

   • Upstream Partners: Orchestration providers and model developers.

   • Business Stakeholders: Account managers and client relationship teams.

2. Communication Framework :

   • Develop in-application alert frameworks with appropriate visibility levels.

   • Create user-appropriate explanations avoiding unnecessary technical complexity.

   • Establish escalation pathways for high-impact customer segments.

   • Configure multi-channel notification systems (in-app, email, SMS).

   • Establish status page with appropriate detail and update frequency.

   • Create customer support brief templates ensuring consistent messaging.

   • Design templates focused on user impact and alternative workflows.

   • Develop progressive disclosure mechanisms for varying detail needs.

   • Create visual indicators for feature availability status.

3. Testing and Maintenance:

   • Conduct user experience testing for disruption notifications.

   • Review message effectiveness through customer feedback collection.

   • Validate notification systems through periodic end-to-end 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 Application Providers (AP)

[Policy Scope]

1. Critical Assets Protection Strategy:

   • Implement comprehensive preservation of application code and configuration settings.

   • Establish secure repositories for user data and personalization preferences.

   • Create versioned archives of interface definitions and design components.

   • Maintain secure backups of integration specifications and API dependencies.

2. Application Environment Preservation:

   • Deploy automated daily snapshots of deployment configurations and code bases.

   • Implement infrastructure-as-code with version control for environment definitions.

   • Create secure storage for application secrets and configuration parameters.

3. User Data Safeguards:

   • Establish incremental backup system with point-in-time recovery capabilities.

   • Create geographically distributed copies with appropriate encryption.

   • Implement backup verification ensuring data consistency and integrity.

4. Recovery Readiness:

   • Develop application restoration procedures with functional testing checkpoints.

   • Create isolated environments for backup restoration validation.

   • Establish tiered recovery plans optimizing for critical user functions.

[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 Application Providers (AP)

[Policy Scope]

1. Response Structure:

   • Establish response team including user experience designers and backend specialists.

   • Designate customer communication leads for consistent messaging

   • Create clear decision authority for feature availability changes

2. Incident Classification:

   • Implement impact categories based on user-facing functionality effects.

   • Define graduated response levels aligned with business criticality.

   • Create assessment templates for user experience degradation evaluation.

   • Establish thresholds for implementing alternative interface modes.

3. Response Phase:

   • Deploy pre-designed limited functionality modes preserving core features

   • Implement feature availability evaluation determining critical functions.

   • Implement user notification systems with appropriate transparency.

   • Activate caching strategies reducing backend dependencies.

   • Activate degradation monitoring tracking user experience metrics

4. Post-Incident Activities:

   • Conduct user experience analysis during degraded operations.

   • Implement resilience improvements based on identified weaknesses.

   • Update graceful degradation patterns improving future responses.

   • Document effective communication approaches for similar 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 Application Providers (AP)

[Policy Scope]

1. Create scenarios targeting user experience disruption and backend service failures.

2. Develop simulation approaches for graceful degradation and feature limitation.

3. Establish exercise progression exploring increasingly complex availability issues.

4. Design specialized drills testing communication strategies and alternative user flows.

5. Design collaborative exploration of user communication scenarios.

6. Execute partial recovery drills focusing on critical functionality restoration.

7. Organize full-scale simulations involving customer support and communication teams.

8. Execute verification drills confirming user experience during progressive restoration.

[All actors]

1. Designing Effective Scenarios:

   • a. Develop progressive difficulty levels building team capabilities over time, include both technical complications and communication challenges.

   • b. Design scenarios that test decision-making under uncertainty and time pressure.

2. Building a Comprehensive Program:

   • a. Begin with tabletop sessions exploring response strategies without system impact.

   • b. Introduce unexpected complications challenging assumptions and standard approaches.

3. Hands-On Validation:

   • a. Conduct controlled technical testing in isolated environments which validate processes and with actual tools and systems.

   • b. Execute partial recovery activities focused on critical functions.

4. Full-Scale Exercises:

   • a. Organize comprehensive simulations involving all response team members, and incorporate surprise elements to test readiness and adaptability.

   • b. Conduct immediate debriefs while experiences remain fresh.

   • c. Focus evaluation on specific improvement opportunities rather than general observations.

   • d. Translate lessons into concrete procedure updates before the next incident.

   • e. Share non-sensitive insights that could benefit other ecosystem participants.

5. Cross-Entity Readiness

   • a. Participate in joint exercises exploring scenarios that cross organizational boundaries, may include local authorities to facilitate and test such exercise response.

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 Application Providers (AP)

[Policy Scope]

1. Identify user-facing components requiring continuous availability.

2. Evaluate backend integration points needing redundant connections.

3. Deploy redundant web/application servers with automated failover.

4. Implement multi-region content delivery networks with dynamic routing.

5. Assess data presentation layers requiring alternative delivery methods.

6. Determine user state information requiring protected persistence.

7. Establish offline capability supporting basic functions during disruptions.

[All actors]

1. Strategic Assessment:

   • Inventory all physical and virtual components supporting critical functions.

   • Classify infrastructure elements based on maximum tolerable downtime.

   • Identify specialized hardware with unique replacement challenges.

   • Map dependencies between components to understand failure implications.

   • Document resource requirements for minimum acceptable operations.

2. Design Principles for Resilient Systems:

   • Create true redundancy rather than mere backup capabilities.

   • Implement geographic distribution for critical system components.

   • Build capacity ensuring secondary systems handle full production loads.

   • Develop isolation boundaries preventing cascade failures across components.

3. Core Processing Safeguards:

   • Deploy parallel computing environments using N+1 redundancy principles.

   • Establish automated health checking with failover triggers.

   • Create load balancing across redundant processing instances.

   • Design resource isolation preventing “noisy neighbor” problems.

4. Network Resilience Measures:

   • Implement diverse routing paths between essential components.

   • Establish multiple external connectivity providers with dynamic balancing.

   • Create redundant internal communication channels with automatic switching.

   • Design independent management networks for emergency administration.

Environmental Protection:

• Deploy redundant power systems with seamless transition capabilities.

• Implement alternative cooling approaches with independent controls.

• Create multiple physical security layers with overlapping coverage.

• Establish diverse monitoring systems with independent alerting mechanisms.

1. Validation and Maintenance:

   • Conduct regular failover testing under realistic load conditions.

   • Perform scheduled operation from secondary systems to verify readiness.

   • Implement automated verification ensuring configuration synchronization.

   • Create capacity validation confirming redundant systems remain adequate.

2. Cross-Entity Considerations:

   • Establish clear documentation of redundancy capabilities and limitations.

   • Create shared understanding of expected transition times during failures.

   • Develop notification protocols when activating redundant systems.

   • Design complementary approaches where systems interconnect.

CCC: Change Control and Configuration Management

CCC-01: Change Management Policy and Procedures

Control Specification

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

Shared Implementation Guidelines

[All Actors]

1. Establish well-documented policies outlining responsibilities, procedures, and reporting mechanisms for ensuring adherence to change control policies.

2. Implement a schedule for regular internal audits and external assessments to evaluate adherence to change control policies and identify improvement areas.

3. Define measurable metrics to track the effectiveness and consistency of change control implementation.

4. Leverage automation tools to support the implementation of change control processes, including change tracking, logging, and reporting.

5. Define clear escalation paths for instances of non-adherence or ineffective change control implementation to ensure timely remediation and accountability.

[Shared between the MP and AP]

1. Focus on managing changes in application logic, APIs, ML models, and data schemas.

2. Use GitOps, CI/CD pipelines, and change tracking in model registries.

Implementation Guidelines for Application Providers (AP)

[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. Manage changes in application logic, APIs, ML models, and data schemas in a controlled and documented manner. For ML models, the MP must provide formal change documentation (e.g., a Model Delta Report) that summarizes changes in performance, bias metrics, and feature importance compared to the prior version.

2. The AP must review the MP’s change documentation prior to deployment and validate the updated model using structured rollout methods (e.g., A/B testing or canary deployment) to confirm alignment with business KPIs and application stability. Document validation results as part of the change record.

3. Use GitOps, CI/CD pipelines, and model registry change tracking to ensure traceability and auditability of all changes.

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 Application Providers (AP)

1. Define application-level quality gates that must be met before promoting any change, including code linting, unit test coverage, and vulnerability thresholds.

2. Document comprehensive testing strategies covering functional, performance, and security aspects.

3. Use automation tools to run regression and smoke tests as part of each deployment cycle.

4. Ensure failed tests prevent changes from being promoted to production unless justified and formally approved.

[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 Application Providers (AP)

1. Evaluate user-facing risks introduced by application changes tied to AI model outputs or dynamic decision-making features.

2. Simulate potential failures (e.g., degraded accuracy, latency spikes) in staging to assess business impact.

3. Ensure business continuity and product owners are part of the change approval process when user impact is high.

[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 Application Providers (AP)

1. Establish baseline application configurations for production (e.g., logging levels, API gateway settings, authentication flows).

2. Ensure baseline includes fail-safe defaults, error handling expectations, and secure feature toggling.

3. Use version-controlled configuration files with formal review checkpoints before any rollout.

[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 Application Providers (AP)

1. Log all application-level configuration changes, including API routing rules, model endpoint bindings, and feature toggles.

2. Require peer review and testing validation before production configuration changes are applied.

3. Use feature flags or blue/green deployments to minimize risk during rollout.

[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 Application Providers (AP)

1. Establish and maintain application configuration baselines (e.g., model endpoints, API routing rules, business logic parameters, feature toggles and integration configurations) and document their intended behavior.

2. Monitor deployed applications for changes in behavior or structure that may indicate deviation from approved baseline (e.g., API routing changes, interface schema changes, configuration drift, or application, version mismatches).

3. Configure monitoring, alerting, and remediation workflows to detect deviations affecting production environments and initiate appropriate corrective actions such as rollback, configuration restoration, or escalation through change management processes.

[All Actors]

1. Identify and define critical baseline elements that must be monitored for deviation, including system configurations, AI model versions, training datasets, hyperparameters, infrastructure specifications, and access control settings.

2. Maintain version-controlled records of all approved baselines, ensuring traceability and auditability of original configuration states.

3. Implement automated tools to detect configuration drift or unauthorized deviations from the approved baselines in real-time or near real-time.

4. Establish materiality threshold criteria for what constitutes a material deviation that warrants investigation, rollback or emergency change.

5. Document procedures for responding to baseline deviations, including root cause analysis, corrective actions, and optional incident escalation.

6. Ensure deviation detection mechanisms are tested periodically and integrated with the organization’s broader change control and security operations workflows.

7. Review and approve configuration baselines at least annually or upon major changes to organization assets.

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 Application Providers (AP)

1. Establish baselines for API error rate, response-time, data-integrity and AI-output constraints; integrate alerts with release-gate logic to halt canary/blue-green roll-outs.

2. Log anomalous input/output sequences for later model or rules updating.

[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 Application Providers (AP)

1. Support blue/green or feature-flag roll-forwards as an emergency path; require post-mortem review before the flag remains permanent.

2. Link application exceptions to user-impact metrics (latency, error rate) to justify urgency.

[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 Application Providers (AP)

1. Capture configuration baselines for application services before each deployment (e.g., feature flags, routing rules, UI logic versions).

2. Use blue/green or canary deployments with integrated rollback capabilities tied to alerting and anomaly detection.

3. Document rollback approval criteria and user impact thresholds that trigger reversion.

[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 Application Providers (AP)

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 Application Providers (AP)

Role Specific

1. Assign encryption responsibilities within the application development team by formally designating key owners for API-level encryption, model output handling, and secure storage of AI-driven user interaction data (e.g., prompts, completions, and audit logs).

2. Integrate defined roles into the secure SDLC by embedding responsibility checkpoints into design reviews, code repositories, and CI/CD templates, ensuring only authorized personnel can modify or deploy encryption-related components.

3. Verify downstream service providers’ adherence to defined cryptographic role boundaries through supplier questionnaires, contractual terms, or security attestations, particularly when external services interface with encrypted data flows.

[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 Application Providers (AP)

Role Specific

1. Integrate encryption policy requirements into automated testing frameworks to detect insecure data transmission and ensure approved cryptographic libraries are used in build artifacts.

2. Establish procedures for validating encryption of AI-generated outputs, including logging mechanisms to ensure sensitive completions or model responses are properly encrypted at rest.

3. Conduct peer code reviews focused on verifying encryption controls for data inputs and outputs handled through application interfaces, including APIs and user-facing modules.

[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 Application Providers (AP)

Role Specific

1. Integrate approved encryption algorithm checks into CI/CD pipelines and pre-deployment security gates to prevent use of outdated or non-compliant cryptographic libraries in application components.

2. Maintain an up-to-date application encryption reference guide that maps approved algorithms to use cases such as securing API traffic, encrypting logs, and protecting AI-generated data.

3. Perform targeted source code reviews and automated dependency scans to detect unauthorized cryptographic functions and enforce remediation procedures for deprecated algorithm usage.

[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 Application Providers (AP)

Role Specific

1. Embed encryption-related change checkpoints into application development workflows, requiring security sign-off before deploying any updates that affect cryptographic libraries, key handling logic, or data protection settings.

2. Maintain a version-controlled changelog documenting all encryption-related updates, including algorithm upgrades, key rotation processes, and relevant application-layer impacts.

3. Conduct post-deployment validation of encryption changes using integration tests, vulnerability scanning, and verification that updated components align with approved standards and do not disrupt protected user flows or AI interactions.

[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 Application Providers (AP)

Role Specific

1. Integrate cost-benefit impact assessments into encryption-related change proposals by estimating performance, integration complexity, and downstream user experience effects.

2. Track historical change records to compare projected versus actual outcomes of encryption upgrades, using the insights to refine future decision-making processes.

3. Collaborate with product managers and security leads during change planning to balance feature velocity with cryptographic protection and regulatory obligations.

[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 Application Providers (AP)

Role Specific

1. Integrate encryption-specific threat modeling into application design reviews to proactively identify risks tied to data exposure, key misuse, and algorithm deprecation.

2. Use application-layer logging and telemetry to track anomalies in encryption behavior, such as failed encryption operations, invalid key access, or deprecated protocol usage.

3. Maintain a centralized encryption risk register that maps specific application components to known risks, mitigation strategies, and residual risk ratings, updated with input from security and DevOps leads.

[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 Application Providers (AP)

Role Specific

1. Design application components to support CSP-integrated key control features, such as bring-your-own-key (BYOK) and key usage APIs, ensuring AIC preferences are honored in all encryption workflows.

2. Validate that application deployment templates and infrastructure-as-code artifacts defer to AIC key configurations by default, including cloud storage, API endpoints, and database encryption settings.

3. Perform targeted configuration reviews during application updates to confirm that no hardcoded or default key references override CSP-enabled AIC-managed encryption key paths.

[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 Application Providers (AP)

Role Specific

1. Integrate automated encryption and key usage audit hooks into CI/CD pipelines and application runtime environments to detect deviations from approved practices during deployment and operation.

2. Maintain an audit evidence repository that captures encryption control test results, access logs, and key usage data, supporting both internal oversight and third-party assessments.

3. Schedule targeted application encryption audits following major changes, including new feature releases or API integrations that affect key handling or encrypted data flows.

[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 Application Providers (AP)

Role Specific

1. Enforce use of approved cryptographic libraries (e.g., OpenSSL, Bouncy Castle) within application components, ensuring key generation functions specify algorithm strength and secure RNG sources.

2. Integrate static analysis tools and CI/CD policy checks to detect use of weak key generation functions or non-compliant libraries during code development and deployment.

3. Conduct periodic configuration and source code reviews to validate key generation practices within authentication modules, encrypted data storage routines, and secure session management logic.

[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 Application Providers (AP)

Role Specific

1. Design application services to assign unique cryptographic keys to distinct functions such as API authentication, token signing, and data encryption, avoiding cross-purpose reuse.

2. Embed key purpose validation checks into application startup routines or deployment pipelines, ensuring that configuration files and secrets managers enforce strict separation of key usage.

3. Periodically review application architecture diagrams and key mappings to confirm that each key is bound to a single operational context and complies with defined usage policies.

[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 Application Providers (AP)

Role Specific

1. Integrate automated key rotation schedules into application environments based on cryptoperiod guidance, with overrides triggered by security events or role changes.

2. Configure deployment pipelines and runtime policies to revoke keys tied to deprecated services, developer offboarding, or compromised modules, ensuring dependent resources are re-encrypted as needed.

3. Maintain an auditable record of key revocation and rotation events, documenting risk rationale, affected systems, and cleanup verification results to support compliance and incident review.

[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 Application Providers (AP)

Role Specific

1. Configure automated revocation workflows within CI/CD pipelines to immediately retire keys upon developer offboarding, service deprecation, or detection of compromise indicators.

2. Integrate application-level key revocation triggers into incident response playbooks, enabling security teams to invalidate keys tied to breached or misused components in real time.

3. Maintain an audit trail of all key revocation actions, including timestamps, reason codes, affected components, and confirmation of access remediation.

[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 Application Providers (AP)

Role Specific

1. Integrate secure key destruction protocols into application decommissioning workflows, ensuring that keys stored outside secure environments are completely wiped from storage systems or containerized environments.

2. Implement automated processes for revoking keys stored in HSMs, including a defined procedure for HSM key retirement and ensuring compliance with legal and organizational guidelines for key lifecycle closure.

3. Maintain key destruction logs and retention schedules, documenting the successful removal or revocation of keys in accordance with regulatory requirements, and ensuring they are available for compliance audits.

[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 Application Providers (AP)

Role Specific

1. Configure application CI/CD pipelines to generate encryption keys in a disabled or pre-activated state, using flag-based controls or metadata labels that prevent premature use.

2. Establish an approval workflow that transitions keys from pre-activated to active status only after security validation and stakeholder authorization are recorded.

3. Log and review all key activation events to ensure traceability and that no application-layer encryption functions are executed using unapproved or pre-activated keys.

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

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

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

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

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

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

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

CEK-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 Application Providers (AP)

Role Specific

1. Integrate suspension flags into application key management interfaces, enabling immediate deactivation of keys during downtime, incident response, or suspected misuse.

2. Establish reinstatement procedures that require documented approval and risk review before suspended keys are reactivated within CI/CD pipelines or runtime environments.

3. Maintain an audit trail of all key suspension and reactivation events, capturing trigger sources, decision authorities, duration of suspension, and associated impacts on encrypted services.

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

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

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

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

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

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

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

CEK-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 Application Providers (AP)

Role Specific

1. Integrate automatic key deactivation into application lifecycle management, ensuring that expired keys (e.g., API tokens, session credentials) are flagged for immediate deactivation through CI/CD and runtime checks.

2. Establish a process for auditing deactivation events, tracking when keys expire, who authorized the deactivation, and how it impacts users or services interacting with the application.

3. Implement and document rollback mechanisms to restore services or user access promptly if keys are prematurely deactivated, ensuring minimal disruption.

[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 Application Providers (AP)

Role Specific

1. Tag and classify deprecated application-layer encryption keys for archival at the point of revocation or decommissioning, ensuring they are flagged as non-active but retained according to regulatory and operational data retention policies.

2. Store archived keys in encrypted vaults integrated with access control lists scoped only to compliance, forensic, or recovery roles, ensuring application runtime environments have no access path to historical keys.

3. Conduct quarterly reviews of archived key access logs and retention statuses, validating that archived keys remain untouched except for authorized recovery events and continue to comply with jurisdictional preservation mandates.

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

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

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

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

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

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

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

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 Application Providers (AP)

Role Specific

1. Isolate compromised CSP-managed keys in a dedicated, restricted-access environment where they are only allowed to perform decryption tasks for incident recovery, with all operations logged and reviewed periodically to ensure compliance with customer SLAs and regulatory requirements.

2. Enforce strict access controls by leveraging HSMs or secure key management systems (KMS) to ensure compromised keys cannot be used for new encryption operations, and configure automated systems to alert and block unauthorized encryption attempts.

3. Implement regular audits to confirm that all instances of compromised key usage are for decryption only, ensuring that keys are formally retired when no longer required and that any usage outside of authorized decryption processes is flagged for immediate review.

[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 Application Providers (AP)

Role Specific

1. Evaluate trade-offs between operational continuity and the potential exposure of sensitive data (such as user information, logs, or model outputs) when establishing key recovery plans, ensuring a balance between maintaining business operations and mitigating data exposure risks.

2. Approve key recovery mechanisms such as key backups or escrow, validating that they are aligned with the organization’s risk assessments, operational needs, and legal requirements for handling sensitive data and ensuring compliance with regulatory standards.

3. Securely implement recovery mechanisms, ensuring key recovery processes are tightly controlled, authorized, and auditable, with safeguards to prevent unauthorized access or misuse of recovered keying 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-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 Application Providers (AP)

Role Specific

1. Track key lifecycle by documenting key inventory requirements and ensuring all keys related to user data, model outputs, and third-party APIs are tracked through their lifecycle, including classification, rotation, and usage status.

2. Review key status changes by ensuring key changes such as activation, rotation, and deactivation are accurately recorded and reviewed for compliance with application-specific risk and legal requirements.

3. Integrate key tracking mechanisms by implementing key inventory policies in systems like integrated key vaults and encrypted logging mechanisms, ensuring that key status updates are properly logged and traceable for audits and incident response.

[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 Application Providers (AP)

1. Application Providers (AP) should define physical and environmental security requirements for facilities hosting AI-enabled applications and supporting services.

2. Policies should address access control to application infrastructure, protection of backend services, and environmental safeguards for systems that store or process AI outputs.

3. Where infrastructure is outsourced, APs should verify that hosting partners maintain appropriate physical and environmental security controls.

[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 Application Providers (AP)

Role Specific Verify the AP reviews CSP attestations specifically for:

• High-compute AI workload environments

• GPU cluster availability SLAs (99.95% minimum)

• Cooling capacity for sustained AI workloads

• Power redundancy for training continuity

• Network bandwidth for distributed training

• Hardware failure contingency plans

[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 Application Providers (AP)

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 staging environments to validate transfers before production deployment.

3. Establish transfer authorization tied to application release management processes and have a rollback plan in place for recovery from a failed transfer.

[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 Application Providers (AP)

Role Specific

1. Establish check-in/check-out procedures for development devices.

2. Implement workspace zoning based on application sensitivity.

[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 Application Providers (AP)

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. Implement digitally-signed handover processes for application media. Use specialized compartmentalized cases for transporting application components.

3. Establish dedicated secure channels for emergency code transfers.

[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 Application Providers (AP)

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. Documenting the application architecture that incorporates AI capabilities.

3. Classify each component based on its interaction with sensitive data and AI models.

[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 Application Providers (AP)

Role Specific

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

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

3. Document accessibility features and compliance requirements.

[All Actors]

1. Maintaining detailed catalogs of physical and digital assets relevant to each entity’s role.

2. Documenting dependencies, connections, and data flows between components.

3. Monitoring assets from creation through deployment to retirement.

4. Implementing appropriate protection mechanisms based on asset classification.

5. Ensuring asset management practices support industry frameworks.

DCS-08: Controlled Physical Access Points

Control Specification

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

Shared Implementation Guidelines

[All Actors Except AIC]

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

Implementation Guidelines for Application Providers (AP)

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. Implement smart card access to development floors with differing clearance zones.

[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 Application Providers (AP)

Role Specific

1. Create hardware-based code signing requirements tied to registered devices, which are used for application release.

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

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 Application Providers (AP)

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 Application Providers (AP)

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 Application Providers (AP)

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 Application Providers (AP)

No Role Specific

[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 Application Providers (AP)

Role Specific

1. Develop and maintain service continuity and disaster recovery plans that address potential disruptions caused by environmental system failures (e.g., overheating, excessive humidity) in data centers hosting application services.

2. Periodically verify that hosting environments for application services meet the required environmental standards. Require evidence of compliance from third-party data center providers as part of vendor management.

[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 Application Providers (AP)

Role Specific

1. Identify and document all utility dependencies (power, cooling, network) for application services. Assess risks associated with each utility and implement mitigation strategies.

[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 Application Providers (AP)

Role Specific

1. When selecting data centers or cloud providers for hosting application services, require evidence that business-critical equipment is located in low-risk areas, away from environmental hazards.

2. Ensure that application servers and storage devices are not placed near windows, external walls, or ground floors where they may be exposed to environmental threats.

3. Conduct periodic audits of equipment locations to verify ongoing compliance with environmental risk avoidance policies and update risk mitigation strategies as needed.

[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 Application Providers (AP)

1. Application Providers should monitor metrics related to infrastructure (self-hosted or third party) and services supporting AI-enabled applications, including service availability, access anomalies, and configuration integrity of application hosting environments.

2. Application providers should detect deviations from approved deployment configurations, insecure service states, and infrastructure conditions that could affect application performance or expose sensitive outputs.

3. Metrics should support both operational monitoring and incident investigation processes.

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 Application Providers (AP)

1. Application Providers should implement continuity strategies to maintain availability of AI-enabled applications, including redundant application deployments, load balancing, and recovery procedures for dependent AI services.

2. Ensure that application architectures can tolerate infrastructure outages and that AI components can reconnect or recover after service interruptions.

3. Disaster recovery and business continuity plans should be aligned with service availability objectives and customer expectations.

4. Application Providers should periodically (at least annually) validate recovery procedures through testing or simulated failure scenarios.

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 Application Providers (AP)

Primary Responsibility: Securing data at the application level and ensuring compliance with user data privacy.

1. Implement application-level data security controls, including encryption, masking, and secure storage.

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

3. Enforce privacy-by-design principles in application development.

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

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

[All Actors]

1. To include establishing below policies and procedures (in line with all relevant legal requirements and standards):

   • a. Data Governance Framework: Establish roles, responsibilities, and processes for managing data across AI lifecycle.

   • b. Data Stewardship Policy: Designate data stewards to oversee the quality, integrity, and compliance of data.

   • c. Data Minimization: AI systems should access only the minimal amount of data necessary to perform their functions, avoiding the storage or use of customer prompts and completions for model retraining.

   • d. Data Cataloging: Maintain an updated catalog of all data used by AI systems, including storage locations and access details.

   • e. Data Residency: Offer data residency options to comply with regional data privacy regulations, allowing customers to store their data within specific geographic locations.

   • f. Data Access Controls: Implement strict access controls to ensure that only authorized users can access sensitive data used in AI systems.

   • g. Data Lifecycle Management: Define policies to address the AI data lifecycle, including generation, collection, storage and management, processing (data cleaning, transformation, annotation and labeling, integration, and validation), and disposal after a governance-defined period of inactivity.

   • h. Data Quality Policy: Ensure data integrity, accuracy, and completeness. Regularly audit and clean data to maintain high standards, for example in line with ISO/IEC 5259, ISO 25012 and ISO 8000

   • i. Transparency and Accountability Policy: Promote transparency in data practices and ensure accountability through regular reporting and audits.

DSP-02: Secure Disposal

Control Specification

Apply industry accepted methods for the secure disposal of data from storage media such that data is not recoverable by any forensic means.

Shared Implementation Guidelines

[All Actors]

1. Dispose of cached inference results and log files the actor retains using approved secure-deletion methods.

2. Purge any user sessions, logs and outputs once the defined retention period expires for data the actor stores or processes.

3. Ensure business- or user-data deletion aligns with compliance obligations for the systems the actor controls.

4. Enable and execute secure-wipe / cryptographic-erasure lifecycle policies.

[Shared among: MP, CSP, OSP]

1. Delete training/validation data and embeddings post-use or repurpose for models the actor trains or fine-tunes.

Implementation Guidelines for Application Providers (AP)

1. Implement application-level secure delete features (overwrite memory, scrub user storage).

2. Schedule deletion jobs for inactive user data or logs beyond retention limits.

3. For client-side applications, enable data scrubbing options (e.g., app uninstall data wipe).

4. Audit third-party plugins or SDKs to confirm secure disposal compliance.

[All Actors]

1. Dispose of cached inference results and log files the actor retains using approved secure-deletion methods.

2. Purge any user sessions, logs and outputs once the defined retention period expires for data the actor stores or processes.

3. Ensure business- or user-data deletion aligns with compliance obligations for the systems the actor controls.

4. Enable and execute secure-wipe / cryptographic-erasure lifecycle policies.

DSP-03: Data Inventory

Control Specification

Create and maintain a data inventory, at least for any sensitive, regulated and personal data. Review and update the inventory at least annually, or upon significant changes.

Shared Implementation Guidelines

[All Actors]

1. Inventory data moving between services or cached within the environment the actor controls.

2. Classify and track prompt / response data tied to users that the actor stores or processes.

3. Inventory customer data used in AI workflows that the actor handles.

4. Enable classification, discovery and tagging at the storage level.

[Shared among: MP, OSP, CSP]

1. Maintain metadata & lineage for training / test / fine-tuning data.

Implementation Guidelines for Application Providers (AP)

1. Ensure in-app data tracking mechanisms to identify sensitive user information.

2. Provide user consent management capabilities for data collection and processing.

3. Implement data retention and deletion policies in accordance with regulations.

[All Actors]

1. Inventory data moving between services or cached within the environment the actor controls.

2. Classify and track prompt / response data tied to users that the actor stores or processes.

3. Inventory customer data used in AI workflows that the actor handles.

4. Enable classification, discovery and tagging at the storage level.

DSP-04: Data Classification

Control Specification

Classify data according to its type, criticality and sensitivity level.

Shared Implementation Guidelines

[All Actors]

1. Define and apply a data-classification scheme to every data object the actor stores or processes.

2. Attach and preserve classification metadata on data objects and flows and ensure that metadata follows the data through its lifecycle.

3. Apply appropriate protection controls, according to the assigned classification.

4. Maintain a classification register and review it at least annually or after material change, updating controls when data sensitivity/criticality or regulatory scope changes.

[Shared among : MP, OSP, CSP]

1. Classify and maintain lineage for all training, test and fine-tuning datasets and model artifacts.

Implementation Guidelines for Application Providers (AP)

1. Implement in-app data classification mechanisms (e.g., user-provided data, logs, transactions).

2. Enforce role-based access control (RBAC) for classified data.

3. Use tagging and metadata to manage data sensitivity.

4. Provide mechanisms for user consent and privacy settings.

[All Actors]

1. Define and apply a data-classification scheme to every data object the actor stores or processes.

2. Attach and preserve classification metadata on data objects and flows and ensure that metadata follows the data through its lifecycle.

3. Apply appropriate protection controls, according to the assigned classification.

4. Maintain a classification register and review it at least annually or after material change, updating controls when data sensitivity/criticality or regulatory scope changes.

DSP-05: Data Flow Documentation

Control Specification

Create data flow documentation to identify what data is processed, stored or transmitted where. Review data flow documentation at defined intervals, at least annually, and upon significant changes.

Shared Implementation Guidelines

[All Actors]

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

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

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

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

[Shared among: MP, OSP, CSP]

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

Implementation Guidelines for Application Providers (AP)

1. Document how data flows within the application, including user interactions, processing, and storage.

2. Ensure privacy policies align with documented data flow processes.

3. Use encryption and access controls based on data movement risks.

4. Update documentation with each new application feature or data processing change.

[All Actors]

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

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

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

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

DSP-06: Data Ownership and Stewardship

Control Specification

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

Shared Implementation Guidelines

[All Actors]

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

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

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

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

[Shared among: MP, OSP, CSP]

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

Implementation Guidelines for Application Providers (AP)

1. Define ownership policies for user-generated and application-processed data.

2. Implement mechanisms for users to manage their data ownership rights (e.g., consent management, data deletion requests).

3. Maintain data processing agreements with stakeholders managing sensitive data.

4. Conduct regular security audits to validate data ownership policies.

[All Actors]

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

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

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

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

DSP-07: Data Protection by Design and Default

Control Specification

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

Shared Implementation Guidelines

[All Actors]

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

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

3. Document residual risks and mitigation plans.

[Shared among: MP, OSP, CSP]

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

Implementation Guidelines for Application Providers (AP)

1. Develop secure-by-design AI applications with strong authentication and data protection.

2. Implement secure software development lifecycle (SDLC) with DevSecOps integration.

3. Enforce data minimization, access control, and secure storage mechanisms.

4. Continuously monitor for security incidents and apply updates accordingly.

[All Actors]

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

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

3. Document residual risks and mitigation plans.

DSP-08: Data Privacy by Design and Default

Control Specification

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

Shared Implementation Guidelines

[All Actors]

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

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

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

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

[Shared among: MP, OSP, CSP]

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

Implementation Guidelines for Application Providers (AP)

1. Implement privacy-by-design principles in application development, ensuring user data protection from collection to deletion.

2. Provide privacy-friendly user settings by default (e.g., opt-in data sharing, minimal data retention policies).

3. Integrate consent management mechanisms for user-controlled privacy settings.

4. Conduct privacy impact assessments (PIAs) for new application features.

[All Actors]

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

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

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

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

DSP-09: Data Protection Impact Assessment

Control Specification

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

Shared Implementation Guidelines

[All Actors]

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

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

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

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

[Shared among: AP, AIC, OSP]

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

Implementation Guidelines for Application Providers (AP)

1. Perform DPIAs for AI applications handling end-user personal data.

2. Implement privacy-by-design principles to mitigate identified risks.

[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 Application Providers (AP)

1. Implement secure coding practices and client-side encryption when collecting sensitive data.

2. Ensure secure APIs with CSP/OSP/MP using mutual TLS and signed tokens (e.g., JWT).

3. Maintain robust privacy notices and consent capture mechanisms.

4. Apply user data masking and access logging for admin tools.

5. Establish clear DPA and International Data Transfer Agreement.

[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 Application Providers (AP)

1. Define the scope, purpose, and required anonymization or masking level for any approved non-production use of production personal data.

2. Provide UI/UX interfaces for submitting DSRs (access, correction, deletion).

3. Authenticate requesters securely and confirm authorization before processing.

4. Log and escalate DSRs to downstream partners (OSP, MP, CSP) as needed.

5. Maintain dashboards or APIs to track and manage DSR fulfillment timelines.

6. 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 Application Providers (AP)

1. Clearly present privacy policies and purpose declarations at data-collection points - for example, for PHI, include HIPAA-specific notices such as the Minimum Necessary Rule.

2. Implement consent management platforms (CMPs) to track user authorization for data use.

3. Enforce data segmentation by purpose — avoid mixing data collected for different intents.

4. Enable audit logging and provide APIs to downstream partners for real-time purpose validation

[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: 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 Application Providers (AP)

1. Handle user consent mechanisms transparently before transferring personal data.

2. Log data processing activities and sub-processing events.

3. Align app features with privacy-by-design principles.

4. Offer users control over data retention and sharing settings.

[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 Application Providers (AP)

1. Inform users if any third-party services integrated with the application will access personal/sensitive data.

2. Use in-app disclosures, consent banners, and policy updates to notify users.

3. Provide settings that allow users to approve or deny data sharing with specific sub-processors.

4. Maintain audit logs of consent and disclosure acknowledgments.

[All Actors]

1. Disclose to data owners or customers every sub-processor that will access personal or sensitive data before processing begins, and promptly update the disclosure when a sub-processor is added, removed, or changes scope.

2. Maintain detailed logs or registers of all sub-processor engagements - including purpose, data categories accessed, approval / consent status, and effective dates - for audit or regulatory review.

3. Provide mechanisms to obtain, record, and honour explicit consent or approval (e-g., in-app settings, contract clauses, service-catalog workflows) wherever law or contract demands it.

4. Share relevant privacy-and-security documentation for each sub-processor (DPIAs, technical controls, certifications, access protocols) with customers, regulators, or internal stakeholders on request.

5. Perform risk-based due-diligence and embed contractual clauses that bind sub-processors to the same data-protection and disclosure obligations the actor has accepted.

DSP-15: Limitation of Production Data Use

Control Specification

Obtain authorization from data owners, and manage associated risk before replicating or using production data in non-production environments.

Shared Implementation Guidelines

[Applicable to all service providers]

1. Establish a policy to specify procedures for secure handling, sanitization, anonymization, and compliance with regulations when using or replicating production data.

2. Conduct risk assessments to identify risks associated with data use.

3. Define and enforce physical and logical boundaries to keep production data secure.

4. Establish and implement policies and procedures for secure development and managing changes.

5. Implement segregation of duties and enforce least privilege access to production environments only after authorization from data owner.

6. Implement principle of least privilege and authorized access to datasets, models, and other sensitive information.

7. Implement security measures to secure datacenters.

8. Provide regular training on security, privacy, and secure coding practices.

9. Implement timely termination and management of employee access.

10. Monitor assets, enforce secure configurations, and manage vulnerabilities on infrastructure and applications processing and storing production data.

11. Enable logs and continuously monitor system access for anomalies.

12. Replicate only the necessary data to minimize potential risks.

13. Anonymize or pseudonymize data to protect privacy and reduce the risk of exposing sensitive information.

14. Implement security measures such as encryption, and secure data transfer protocols.

15. Ensure data replication complies with relevant data protection laws and regulations, such as GDPR.

16. Maintain detailed records of the data replication process and perform periodic audits to ensure compliance.

17. Establish process to inform relevant stakeholders about the data replication process, including its purpose and scope.

18. Detect and remove or remediate sensitive or poisoned data before using it for training.

19. Implement mechanisms to ensure the integrity of data, models, and code used in AI development and deployment.

20. Implement the process of obtaining authorization from data owner before using the data for non-production purposes.

Implementation Guidelines for Application Providers (AP)

[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 Application Providers (AP)

[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 Application Providers (AP)

[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 Application Providers (AP)

[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 Application Providers (AP)

[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 Application Providers (AP)

[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 Application Providers (AP)

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 Application Providers (AP)

1. Document business use cases for PET implementation when accessing data models.

2. Integrate with selected PETs in application design.

3. Monitor application-level privacy metrics.

[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 Application Providers (AP)

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 version control for all datasets used in training pipelines.

3. Implement role based access control mechanisms and establish approval workflows for data updates.

4. Implement anomaly detection algorithms to identify abnormal patterns in training, fine-tuning, or augmentation datasets, to identify unauthorized modifications or data quality issues.

5. Perform data integrity checks for datasets 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 Application Providers (AP)

1. Implement data-generation practices that ensure the data collected for AI training is directly relevant to the specific problem the AI model is designed to solve.

2. Establish data collection practices that prioritize relevance, collecting only user data related to the task and avoiding irrelevant inputs that may degrade model performance.

3. Implement methods to ensure data collection captures a broad range of user behaviors, edge cases, and outliers, preventing the model from overfitting to common scenarios and improving generalization.

4. Establish a feedback loop with Orchestrated Service Provider and Model Provider to report mismatch between real world performance and training assumptions.

[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 Application Providers (AP)

[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 Application Providers (AP)

[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 Application Providers (AP)

1. Map application-module risk levels to policy obligations (e.g., stronger review cadence for user-facing generative features).

2. Ensure release playbooks are updated whenever a policy change affects deployment steps.

[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 Application Providers (AP)

1. Require multi-party approval for exceptions that affect production user data or export large datasets; ensure logs capture every override action.

[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 Application Providers (AP)

1. Apply secure coding standards to AI-powered application features, including input validation and output filtering.

2. Integrate the security program with application lifecycle management for AI components.

3. Include model endpoint security, secure API design, and runtime anomaly detection in the application security checklist.

4. Regularly conduct penetration tests and secure code reviews, including AI-specific logic paths.

5. Protect application telemetry and audit data used for AI feedback loops and drift detection.

[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 Application Providers (AP)

1. Assign feature owners accountable for downstream impact of model updates on application logic and user experience.

2. Define roles for testing / rollout management (e.g., A/B or canary) and for accepting AI-related business risk.

3. Include UX and accessibility stakeholders in decisions affecting explainability and transparency to end users.

[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 Application Providers (AP)

1. Map application-level behaviors (e.g., AI-driven decisions, data handling) to relevant end-user regulations.

2. Ensure UX, explainability, and feedback channels meet fairness and accountability obligations.

3. Design app-level controls for opt-out, consent, and model transparency.

4. Log and version AI-driven UI behavior in regulated features (e.g., credit decisions, medical advice).

5. Maintain change control documentation to support regulatory reporting.

[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 Application Providers (AP)

1. Monitor SIGs focused on AI UX, AI ethics, and end-user interaction risks.

2. Adopt best practices from peer-reviewed groups focused on explainability and user trust.

3. Engage with accessibility and AI inclusion working groups.

4. Adjust application policies based on SIG-driven frameworks or open-source reference designs.

5. Participate in security disclosure or vulnerability coordination groups relevant to AI apps.

[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 Application Providers (AP)

1. Present users with clear notices and terms aligned with the AUP before enabling AI features.

2. Restrict application behavior based on known AUP edge cases (e.g., impersonation, misinformation).

3. Provide users with feedback channels to report inappropriate or unexpected AI behavior.

4. Use runtime controls to prevent high-risk or ambiguous interactions from reaching AI endpoints.

5. Log AUP-relevant activity for post-deployment review and compliance tracking.

[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 Application Providers (AP)

1. Document risks posed by AI-driven decisions on end-users, including personalization, recommendations, or predictive outputs.

2. Assess how UX and UI could amplify or reduce AI risks (e.g., automation bias, lack of transparency).

3. Include impact of AI-driven features in product release documentation.

4. Flag user-facing scenarios requiring disclaimers or explainability prompts.

5. Review impact across demographic or accessibility contexts.

[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 Application Providers (AP)

1. Ensure front-end implementation does not introduce or amplify biases in AI decision paths.

2. Perform UX studies on how AI outputs are perceived across demographic groups.

3. Test variations in display formats or personalization features for fairness disparities.

4. Support UI/UX prompts for human override or appeals on biased decisions.

5. Log user interactions to identify fairness issues at the application level.

[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 Application Providers (AP)

1. Submit product features using AI that affect autonomy, decision rights, or emotional manipulation to the ethics committee.

2. Demonstrate that alternative designs were considered and trade-offs justified.

3. Present plans for user consent, override, or appeal mechanisms.

4. Document A/B test outcomes related to ethical risks.

5. Work with ethics reviewers to adjust deployment thresholds or feature exposure levels.

[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 Application Providers (AP)

1. Surface explanations to users in a format suitable for the application (e.g., text, charts, tooltips).

2. Test whether end users understand and trust AI explanations.

3. Provide user feedback channels for explanation usefulness or errors.

4. Log explanation interactions to improve future UI/UX.

5. Ensure updates to models or decision logic don’t remove previously provided explanations.

[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 Application Providers (AP)

1. Disclose when AI is involved in decision-making or personalization.

2. Include a “Why am I seeing this?” feature in AI-powered outputs.

3. Explain key input factors contributing to decisions or recommendations.

4. Offer transparency overlays or tooltips for AI-driven UI elements.

5. Include disclaimers for probabilistic, evolving, or experimental models.

[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 Application Providers (AP)

1. Provide user interfaces that facilitate human review, feedback, or approval for AI-generated outcomes in critical application workflows.

2. Clearly indicate AI-generated recommendations versus human-generated content to end-users, supporting informed decisions.

3. Log all manual overrides and human interventions, along with justifications, to support transparency and accountability.

4. Enable role-based access for human reviewers to assess or halt AI processes when downstream risk is detected.

5. Incorporate user feedback mechanisms to continuously refine how AI outcomes are supervised and adjusted.

[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 Application Providers (AP)

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 and responsible AI.

3. Controlled Access: Grant access to critical AI systems (e.g., model endpoints, training data, admin consoles) only after successful completion of background checks. 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.

[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 Application Providers (AP)

[Application Provider (AP)]

1. AI Feature Usage: Enforce acceptable use guidelines for user-facing AI features, ensuring data inputs/outputs and interactions meet organizational and regulatory standards.

2. User Data Protection: Incorporate privacy and security controls into AI features that handle personal or sensitive user data, aligning with defined acceptable use parameters.

[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 Application Providers (AP)

[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 Application Providers (AP)

[Application Provider (AP)]

1. Secure Integration Points: Require secure tunnels (VPN/SSL) for remote access to AI-driven application features, ensuring data flows and APIs remain protected from unauthorized interception.

2. Local Storage Restrictions: Prevent developers from storing sensitive application-level AI data on personal or uncontrolled devices; restrict critical logs or user data to secure cloud-based storage systems.

[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 Application Providers (AP)

[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 Application Providers (AP)

[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 Application Providers (AP)

[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 Application Providers (AP)

[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 Application Providers (AP)

[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 Application Providers (AP)

[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 Application Providers (AP)

[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 Application Providers (AP)

[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 Application Providers (AP)

[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 Application Providers (AP)

[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 Application Providers (AP)

[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 Application Providers (AP)

[AP] The application provider is responsible for IAM policies surrounding AI use, including:

1. Privileged AI User Controls: Establish specialized role-based access for administrators managing AI use. Require periodic recertification of privileged access rights.

2. Separate roles for access to different application components.

3. Access control for any model storage or application-to-model interactions.

[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 Application Providers (AP)

[AP] The AP is responsible for establishing strong authentication credential management policies for access to any AI services in the application, for the internal authentication of OSPs/MPs to the application, and for authentication of the AICs or end users using the application.

[All Actors] Responsible for establishing strong authentication credential management policies and procedures that include:

1. Authentication Standards: Establish requirements for password complexity, length, history, and expiration.

2. Brute-force Attack Prevention: Use brute-force attack prevention mechanisms based on rate limiting and progressive delays (e.g., account lockout after a specified number of failed login attempts).

3. Credential Protection: Use credential protection using strong storage and in transit encryption, utilizing secure hashing algorithms with regular updates and salting, and conducting periodic assessments and updates of encryption practices aligned with industry standards.

4. Credential management tools: Leverage credential management tools (e.g., hardware security modules or encrypted credential vaults) to store and protect passwords and keys.

5. Credential Rotation: Define and enforce credential rotation requirements for all identities within AI development and operations environments, taking into account specialized accounts such as service accounts used by AI frameworks.

6. Password Reset: Define a secure password reset process to prevent unauthorized access in case of forgotten passwords.

7. Credential Recovery: Define a secure process for credential recovery that includes verification steps to prevent unauthorized access.

8. Multi-Factor Authentication (MFA): Use multi-factor authentication to add an extra layer of security in addition to passwords.

9. Approval: Establish an approval process for any changes or modifications to the IAM policy and procedures, including a documented record.

10. Maintenance and Reviews: Conduct reviews on credential policies and procedures documentation at least annually to ensure alignment with evolving security landscape, regulations, and risks.

11. Short-Lived Credentials: Prioritize using short-lived secrets and automatic rotation of credentials where possible to reduce management overhead and minimize impact of leaked credentials.

12. Policy Communication: Ensure credential policies are clearly documented and effectively communicated to all relevant stakeholders.

IAM-03: Identity Inventory

Control Specification

Manage, store, and regularly review the inventory of identities, and monitor their level of access.

Shared Implementation Guidelines

[All Actors] Responsible for maintaining a comprehensive inventory of all identities and their level of access

1. Include human users, machine identities, service accounts, API keys, and AI identities.

2. Identity Management System: Where appropriate, a centralized identity management platform should be implemented that consolidates identities’ data from various applications and services.

3. Identity Classification: Identities should be categorized and classified based on their roles, purpose, and sensitivity and in correlation of the resources they access. Include mapping of any inheritance relationships between identities, indirect access paths, and nested group memberships.

4. Access Level Mapping: Maintain mapping between identities and their level of access (RBAC/ABAC), documenting specific permissions, roles, and resource access scopes for each identity. Regularly review these mappings for accuracy.

5. Identity Discovery and Inventory: Automated tools should be utilized to continuously scan the environment and discover all existing identities in real-time.

6. Identity Creation Monitoring: Implement alerting mechanisms to notify security teams when new identities are created or when existing identities receive permission changes, especially for privileged access, to detect potential privilege escalation attempts.

7. Threat Intelligence Integration: Leverage threat intelligence sources to identify potential identity-based threats to proactively address emerging risks.

8. Inventory Access: Identity information should be stored in a secure location and access restricted to authorized personnel.

9. System/AI Identity Ownership: Each system, service, or AI account should be assigned a designated owner to maintain accountability, facilitate future management, and mitigate security risks associated with unmanaged accounts.

10. Inventory Reviews and Updates: Review the inventory to ensure accuracy and completeness and identify any anomalies, on a periodic basis or after any system changes or changes to identities and their level of access.

Implementation Guidelines for Application Providers (AP)

[AP]

1. The Application Provider is responsible for inventorying identities including:

   • Developer identities with access to AI integration points

   • Service accounts connecting applications to AI models

   • API keys and authentication tokens for model access

   • Administrative accounts that can modify AI functionality.

[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 Application Providers (AP)

[AP]

1. The Application Provider is responsible for implementing SoD by

   • SoD between AI application development and approval for production

   • SoD between prompt engineering and application deployment

   • Multi-party approval for changes to AI functionality

[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 Application Providers (AP)

[Application Provider]

1. The Application Provider is responsible for implementing PoLP by:

   • Limiting Model Provider API credential access to only those who manage model integration

   • Restricting prompt template modification to designated prompt engineers

   • Restricting application code access only to developers working on the specific component

   • Creating environment-specific permissions (dev/test/production) for AI integration components

   • Establishing read-only roles for monitoring and quality assurance

   • Using temporary access provisioning for application configuration changes

[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 Application Providers (AP)

1. Grant application access based on job function, with differentiated roles for admins, users, and support staff.

2. Integrate access provisioning with centralized identity providers (e.g., SAML, OIDC) for consistent identity lifecycle management.

3. Implement automated checks to ensure access grants are scoped to least privilege.

4. Document provisioning rules for application modules or features tied to different risk levels.

[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 Application Providers (AP)

1. Suspend or downgrade application and API tokens at once when users are flagged inactive or terminated.

2. Cascade revocation to every integrated module (plug-ins, third-party SDKs) and integration that relied on the original credentials.

[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 Application Providers (AP)

1. Integrate access review tasks into security operations or compliance workflows.

2. Flag discrepancies between assigned access and documented roles or responsibilities.

[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 Application Providers (AP)

1. Implement tiered access within the application for support engineers, developers, and administrators.

2. Ensure that debug-level access is not available to the same personnel responsible for deployment.

3. Require multi-party approval for sensitive changes like policy overrides or data exports.

[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 Application Providers (AP)

[AP]

1. Document agent-based access to Privileged Roles in a similar manner to users.

2. Perform audits and access certification on AI systems with access to privileged roles and permissions.

[All Actors]

1. Implement time bound, purpose driven access to allow timebound access provisioning. Examples could include “Just-In-Time”(JIT), and “Zero Standing Privileges” (ZSP). This can be achieved by temporary provisioning of permissions to the user, temporary assignment of user to a group with the required permissions or temporary impersonation of an account with the required permissions.

2. Implement an approval process for provisioning sensitive privileges.

3. Create an auditing procedure to review activation and activity of privileged roles on a regular basis.

4. Regularly review and certify individuals with the ability to provision privileged credentials.

5. Privileges allocated should be limited by a session duration and revoked following the established time-duration leaving no standing access (Zero Standing Privileges).

[AP, AIC]

1. Document agent-based access to Privileged Roles in a similar manner to users.

2. Perform audits and access certification on AI systems with access to privileged roles and permissions.

IAM-11: Service Customers’ Approval for Agreed Privileged Access Roles

Control Specification

Define, implement and evaluate processes and procedures for service customers to participate, where applicable, in the granting of access for agreed, high risk (as defined by the organizational risk assessment) privileged access roles.

Shared Implementation Guidelines

[All Actors excluding AIC]

1. Inventory high-risk privileged access/roles (such as access to customer data) and/or actions and their relevant AIC approver.

2. Define an access request workflow, including the request initiation method, AIC notification and AIC approval method.

3. Send a notification to the AIC when high-risk privileged access has been activated.

4. Log all actions related to the process (approval, provisioning/de-provisioning, etc) in an audit log visible to the AIC.

5. Ensure the purpose for privileged access utilization is communicated to the AIC in addition to the details of the permission set.

6. Ensure access is time-bound aligning with business needs. For example, privileges (entitlements) should be should be clearly defined and implemented via JIT or Zero Standing Privilege (ZSP) mechanisms and support session duration limits.

[AP, OSP, AIC]

1. Ensure there are mechanisms in place for approval and/or notification from agent-based systems requesting and utilizing privileged access and roles.

Implementation Guidelines for Application Providers (AP)

1. Ensure there are mechanisms in place for approval and/or notification from agent-based systems requesting and utilizing privileged access and roles.

2. 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. Access to databases

   • ii. Change user access and permissions

   • iii. Change application security and privacy settings

   • iv. Export application logs.

[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 Application Providers (AP)

[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 Application Providers (AP)

[AP]

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

   • i. User management

   • ii. Application logs

   • iii. Application settings and features.

[Shared with the OSP]

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 Application Providers (AP)

[AP]

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 Application Providers (AP)

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, and manage application settings.

3. Ensure the application allows for configuration of granular authorization mechanism (such as resource, permission [read, write, update, etc]).

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

   • i. User Management

   • ii. Application settings

   • iii. Application security settings

[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 Application Providers (AP)

[AP]

1. Implement approval workflows that have data owners and stewards approve access application components, features and actions such as access to certain models or Agent tools.

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

3. 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 Application Providers (AP)

[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 Application Providers (AP)

[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 Application Providers (AP)

1. Mandate standardized APIs (e.g., REST) for interaction between applications and AI services.

2. Define policies for data formats in requests/responses.

3. Establish guidelines for building portable applications using AI components.

[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 Application Providers (AP)

1. Ensure APIs allow client applications to retrieve data generated/processed by the AI service within that application’s context (subject to authorization).

2. Provide APIs to manage application-specific settings related to the AI service.

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

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 Application Providers (AP)

1. Mandate HTTPS for all communication between applications and AI services (API calls).

2. Use secure protocols for any direct bulk data upload/download related to the AI service.

[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 Application Providers (AP)

1. Contracts address retrieval of application-specific data processed/generated by AI service, custom configs, fine-tuned models.

2. Define data formats and retention periods 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 Application Providers (AP)

1. Establish infrastructure security policies for securing AI-driven applications, including API security, runtime protection, and secure coding practices.

2. Implement secure deployment pipelines with automated security testing for AI-based application environments.

3. Define procedures to assess the impact of infrastructure vulnerabilities on AI service availability and integrity.

[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 Application Providers (AP)

1. Establish capacity planning for AI-driven applications.

2. Optimize AI service calls to prevent excessive infrastructure load.

3. Implement failover strategies.

[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 Application Providers (AP)

1. Secure AI feature communications through end-to-end encryption.

2. Implement network segmentation for AI-driven applications.

3. Enforce security best practices for AI-powered APIs.

[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 Application Providers (AP)

1. Harden application servers against OS-based threats.

2. Ensure AI model runtime environments (e.g., Python environments, GPU/TPU containers, AI-serving frameworks such as TensorFlow Serving, TorchServe, ONNX Runtime) are securely configured according to industry benchmarks, e.g., CIS.

3. Integrate AI-specific security controls into Continuous Integration/Continuous Deployment (CI/CD) pipelines for model deployment.

[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 Application Providers (AP)

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

[All Actors]

1. Environment Segmentation: Establish strict separation of production and non-production networks. Implement access controls to restrict movement between environments.

2. Data Segregation and sanitization (e.g., masking, tokenization, anonymization, or other appropriate methods, according to NIST SP 800-88 Guidelines for media sanitization): Prohibit use of production data in non-production environments unless properly sanitized.

3. Enforce encryption for sensitive data used in lower environments.

4. Access Control and Least Privilege: Implement role-based access control (RBAC) for environment-specific access. Enforce approval processes for data migration across environments.

5. Access policies should include on-demand approval. All access and permissions should be revoked outside the allowed (approved) session duration with Zero Standing Privileges (ZSP).

I&S-06: Segmentation and Segregation

Control Specification

Design, develop, deploy and configure applications and infrastructures such that service customer (tenant) access is appropriately segmented and segregated, monitored and restricted.

Shared Implementation Guidelines

[All Actors]

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

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

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

1. Network and Access Segmentation: Segment internal networks and tenant boundaries at the infrastructure or service level to enforce isolation between service customers (tenants).

2. Implement network and platform controls (e.g., VLANs, virtualization, subnets, ACLs, service isolation mechanisms) to enforce tenant separation and isolate workloads and environments.

3. Continuously monitor tenant interactions and cross-tenant access patterns through logging and anomaly detection mechanisms (e.g. SIEMs, behavioral analytics, or ML-based threat detection, etc.) to detect misuse, unauthorized access, lateral movement, or data leakage between tenants.

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

Implementation Guidelines for Application Providers (AP)

[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 Application Providers (AP)

1. Secure application data and configurations during cloud migration.

2. Implement authentication controls for cloud-based service transfers.

3. Use key management solutions to secure encryption keys.

[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 Application Providers (AP)

1. Document network flows for AI-powered applications.

2. Implement API security documentation for secure application interactions.

3. Define access control measures for high-risk network zones.

[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 Application Providers (AP)

1. Define security baselines for AI-powered application communications.

2. Monitor application traffic for suspicious patterns.

3. Implement security controls for protecting AI APIs from attacks.

[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 Application Providers (AP)

1. Define policies for logging interactions with various components, including model input/output handling, API calls, data preprocessing, and data transformations.

2. Ensure policies include logging requirements for unauthorized access attempts, model performance, and feedback loop adjustments.

3. Continuously assess and improve policies to adapt to evolving application architectures and integrations.

[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 Application Providers (AP)

1. Protect logs generated by interfaces, APIs, and processing components by implementing fine-grained access controls.

2. Ensure encryption of logs stored locally, in transit, or in cloud environments.

3. Continuously monitor logging mechanisms for unauthorized access attempts.

[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 Application Providers (AP)

1. Monitor application interactions, including data exchanges, unauthorized API calls, schema violations or data integrity errors.

2. Implement alerts for anomalies related to data transformations and unauthorized data access.

[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 Application Providers (AP)

1. Enforce fine-grained access on API, UI and inference-request logs; encrypt at rest in local or cloud storage.

2. Run automated audits to spot burst traffic, adversarial input sequences or abnormal data-flow patterns and trigger alerts.

3. Track configuration and code changes related to AI components in the same immutable log store.

4. Integrate logging solutions compatible with AI model deployment platforms (e.g., TensorFlow Serving, TorchServe) for enhanced logging granularity.

[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 Application Providers (AP)

1. Monitor logs for unexpected interactions and attempts to manipulate data or abnormal sequences.

2. Review monitoring systems for continued coverage, effectiveness and compatibility with AI/ML/GenAI frameworks.

3. Log unusual patterns in API interactions, input/output processing, and data transformation layers.

[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 Application Providers (AP)

1. Include time-sync checks in application-health probes; block or flag deployments if drift exceeds threshold.

2. Provide application layer components that normalise client-supplied timestamps to the canonical time zone.

[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 Application Providers (AP)

1. Define logging scope for application interactions, including client/API interactions, data flows (input/output transformations), processing and errors.

2. Continuously assess logging coverage whenever new AI-powered modules are introduced and to adapt to emerging threats.

3. Capture logs related to data preprocessing, feature extraction, and model inference requests.

[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 Application Providers (AP)

1. Define sanitization requirements for AI application-specific data types in logs, including LLM prompts and responses, embedding vectors, fine-tuning datasets, and AI model decision metadata that may contain or encode sensitive information.

2. Implement sanitization in application code at logging points, ensuring user prompts, model responses, and AI feature interactions are sanitized before writing log entries.

3. Configure API gateways and application frameworks to sanitize request/response data containing sensitive information in AI service API logs.

4. Test sanitization effectiveness across AI application scenarios, including user prompts with PII, model responses containing sensitive content, API requests with authentication credentials, and AI feature interactions with confidential data.

5. Validate that sanitization does not create unacceptable application performance degradation or log processing latency through performance impact assessments.

6. Review and update sanitization rules when deploying new AI features, model integrations, or user interface enhancements that may introduce new sensitive data types.

[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 Application Providers (AP)

1. Record AI feature usage and user interactions at the application layer (request parameters, results, timestamps).

2. Offer dashboards or aggregated alerts for swift detection and remediation of security or performance issues.

[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 Application Providers (AP)

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 Application Providers (AP)

[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 Application Providers (AP)

[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 Application Providers (AP)

[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 Application Providers (AP)

[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 Application Providers (AP)

[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 Application Providers (AP)

[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 Application Providers (AP)

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 Application Providers (AP)

[Application Provider (AP)]

1. Determine scanner integration points:

   • a. Acquisition of any pre-trained models: If foundation models are coming into the organization from model hubs or other third party sources, they should be scanned before use.

   • b. Before deployment: Upon loading from a model registry before deployment, models should be scanned before use in production environments to ensure no attacks were introduced if the registry could have been compromised.

   • c. Exchange of models between organizations/departments: If models change hands between different organizations or groups within an organization they should be scanned to exclude introduction of attacks from the source or during the transfer process.

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

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 Application Providers (AP)

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

MDS-04: Model Documentation Requirements

Control Specification

Establish and implement baseline requirements for Model documentation.

Shared Implementation Guidelines

Not Applicable

Implementation Guidelines for Application Providers (AP)

1. Document any applied guardrails or input/output filtering.

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 Application Providers (AP)

[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 Application Providers (AP)

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

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 Application Providers (AP)

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 Application Providers (AP)

[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 Application Providers (AP)

[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 Application Providers (AP)

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

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 Application Providers (AP)

[Application Provider (AP)]

1) Transparent Communication: Any model performance failure or degradation from the contractual obligation, should be transparently conveyed to the user and addressed in the next model training.

[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 Application Providers (AP)

[Application Provider (AP)]

1. Threat Modeling: Identify potential threats and vulnerabilities specific to open weight models.

2. Trustworthiness Assessment of the Model Source: Evaluate the reliability and trustworthiness of the model’s source by verifying its origin, reviewing its documentation, and assessing the integrity of its parameters and training data. This includes validating security assurances provided by the model provider, checking for transparency in model lineage, and ensuring compliance with industry standards and security best practices.

3. Adversarial Testing: Conduct automated penetration testing using adversarial attack tools to identify and exploit potential model vulnerabilities, assessing its exposure to security risks and overall robustness. The evaluation should be performed based on predefined risk thresholds aligned with the organization’s risk appetite, ensuring that identified threats are measured and mitigated accordingly.

4. Static and Dynamic Analysis: Perform both static analysis (examining the model’s code and weights without executing it) with Vulnerability Scanner, SAST and SCA tools, and dynamic analysis (observing the model’s behavior during execution) in isolated environments (e.g. Sandbox) to uncover vulnerabilities.

5. Vulnerability Analysis and Remediation Actions Identification: Assess identified vulnerabilities based on severity, likelihood, and exploitability, prioritizing remediation efforts accordingly. Implement mitigation strategies such as security patches, access controls, or model retraining, ensuring alignment with organizational security policies and compliance standards.

[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 Application Providers (AP)

[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 Application Providers (AP)

1. Define and document policies for detecting and responding to model failures, including performance degradation, unexpected behavior, or system crashes.

2. Ensure application logs capture relevant telemetry for detecting AI/ML-related security anomalies.

3. Implement automated alerting when applications interact with compromised model endpoints.

4. Establish user-facing incident disclosure procedures (e.g., for output leakage or unauthorized decisions).

5. Establish a structured escalation and response plan tied to defined failure severity levels to minimize operational impact.

[All Actors]

1. Establish a unified AI Security Policy Framework encompassing data security, access control, incident response, change management, logging and monitoring, vulnerability management, and responsible AI use.

2. Align AI-related policies with industry frameworks such as ISO/IEC 27001, NIST SP 800-53, CSA CCM, and EU AI Act governance requirements.

3. Maintain a centralized and version-controlled repository of security policies applicable to AI lifecycle stages (e.g., data ingestion, model training, model inference, decommissioning).

4. Conduct annual reviews of policies to ensure continued relevance with emerging AI risks, technological changes, and regulatory updates.

5. Ensure policy accessibility and enforce policy awareness across all relevant internal teams, including development, operations, compliance, and security.

SEF-02: Service Management Policy and Procedures

Control Specification

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

Shared Implementation Guidelines

[All Actors]

1. Define a Service Management Policy that addresses secure, reliable, and compliant service operations across the AI/ML lifecycle.

2. Document lifecycle processes including deployment, scaling, deprecation, and emergency patching of AI systems.

3. Embed security, privacy, and resilience considerations into operational workflows.

4. Ensure the policy includes business continuity expectations during service disruptions related to AI components.

Implementation Guidelines for Application Providers (AP)

1. Implement lifecycle management for AI-integrated features within applications.

2. Monitor dependencies on AI model endpoints and ensure failover capabilities are in place.

3. Align frontend features with backend model lifecycle events (e.g., deprecation notices).

[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 Application Providers (AP)

1. Plan for application-side controls to mitigate downstream effects of compromised model behavior.

2. Design interfaces that can gracefully handle model unavailability during incident response actions.

3. Enable user visibility into system degradations or risks (e.g., response deferrals or increased HITL).

[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 Application Providers (AP)

1. Conduct testing exercises that simulate AI model failures or abnormal behavior within applications, such as degraded model performance, unexpected outputs, or service disruptions.

2. Validate that application monitoring is in place and alerting mechanisms detect and log model failures or anomalous behavior during testing scenarios.

3. Test escalation procedures to ensure incidents involving AI model failures are correctly classified and routed to the appropriate operational or security response teams.

4. Implement a policy-driven rollback mechanism and verify that application-level containment and recovery mechanisms, such as feature disablement, fallback logic, or model rollback procedures, operate effectively during incident simulations.

5. Review outcomes of testing exercises (at planned intervals or upon significant changes) to identify gaps in detection, response coordination, or recovery procedures and update application incident response playbooks accordingly (including newly observed failure types and lessons learned from past incidents.).

[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 Application Providers (AP)

1. Track detection and containment timelines for incidents arising from AI integration in applications.

2. Monitor performance of escalation paths when user-facing outputs indicate model failure or hallucinations.

[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 Application Providers (AP)

1. Filter front-end anomalies that may indicate deeper model or API issues, such as increased user complaints or failed model invocations.

2. Provide contextual metadata (e.g., model version) to aid backend investigation.

[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 Application Providers (AP)

1. Distinguish between frontend issues (e.g., bad UX due to model response) and backend integrity issues.

2. Assign severity based on user population impacted and type of error generated.

3. Analyze application logs and user interaction data to determine how the incident affected system behavior, service availability, or user outcomes.

[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 Application Providers (AP)

1. Report incidents where AI-generated outputs led to user harm, misinformation, or privacy breaches.

2. Notify users and customers about recovery steps and user-specific impact, including verified rollback confirmations, the specific versioning history used for recovery, and a precise timeline of exposure within all stakeholder disclosures to establish the window of risk.

3. Communicate any breaches in the CI/CD or training pipelines that could have compromised model provenance or introduced insecure, tampered, or “poisoned” model versions into the production environment.

[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 Application Providers (AP)

1. Capture incident records for security events at the application layer, including prompt injection attempts, unauthorized access to AI features or API endpoints, and attempts to exfiltrate data through manipulated model interactions.

2. Enrich incident records with contextual metadata (e.g., model version, user session context, API call parameters) to support upstream forensic investigation and root cause analysis by MP or OSP teams.

[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 Application Providers (AP)

1. Include DevSecOps, product, and customer support representatives in contact rosters.

2. Ensure support engineers have direct access to AI pipeline owners when relevant.

[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 Application Providers (AP)

Role Specific:

1. Establish integration-layer SCRM policies for: Multi-supplier security coordination and requirement enforcement, End-to-end data flow security across MP, OSP, and CSP components, API security and integration point management standards.

2. Develop application-specific SCRM procedures including: Vendor security assessment criteria for integrated AI components, Cross-supplier incident response and escalation protocols, Unified security monitoring across the solution stack.

3. Create supply chain coordination policies covering: Security requirement flow-down to all component providers, Evidence aggregation from multiple suppliers for customer transparency, Change management synchronization across the integrated system.

[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 Application Providers (AP)

Role Specific:

1. Establish integration-layer SSRM policies covering: Multi-supplier security coordination and requirement enforcement, End-to-end data flow security across MP, OSP, and CSP components, API security and integration point management standards.

2. Document application-specific SSRM procedures for: Vendor security assessment and compliance verification, Cross-component incident response and escalation protocols, Unified security monitoring across the integrated solution stack.

3. Develop customer responsibility definition policies covering shared security responsibility matrices, customer configuration requirements, user training obligations, and ongoing compliance monitoring procedures for AI Customer organizations.

4. Create application security governance procedures including secure development lifecycle policies, customer data protection requirements, privacy compliance protocols, and regulatory adherence procedures across multiple customer jurisdictions.

[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 Application Providers (AP)

Role Specific:

1. Implement SSRM throughout application delivery supply chain including secure customer onboarding procedures, end-user data protection requirements, and customer-facing security configuration protocols for all application operations and customer interactions.

2. Document application-level SSRM processes covering customer data handling workflows, user authentication procedures, privacy protection mechanisms, and customer support security protocols across the entire application delivery platform.

3. Implement integration-layer risk management by: Assessing risks arising from component interdependencies, Managing API security and data exchange vulnerabilities, Addressing system-wide security incident response coordination.

4. Manage end-to-end supply chain SSRM consolidation through comprehensive integration of upstream provider security (MPs, OSPs, CSPs) with application-layer controls, ensuring seamless security coverage from model to end-user.

[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 Application Providers (AP)

Role Specific:

1. Provide supply chain transparency documentation detailing: SSRM implementation across all integrated suppliers (MP models, OSP services, CSP infrastructure), Vendor security requirement enforcement and validation processes, Compliance evidence aggregation from multiple providers.

2. Create customer responsibility documentation that clearly delineate AP security responsibilities (application security, data protection, upstream coordination) versus customer responsibilities (user training, policy compliance, usage monitoring, incident reporting).

3. Establish customer security communication channels for ongoing SSRM guidance delivery, including security updates affecting customer operations, regulatory changes impacting customer compliance, and evolving best practices for secure AI application usage.

[All Actors]

1. Develop clear and comprehensive SSRM guidance resources that explain how the SSRM framework applies to your products/services and how those requirements extend across your upstream and downstream supply chain.

2. Communicate your SSRM responsibilities to customers by outlining which security controls you implement and how they protect customer data, as opposed to which controls remain within the customer’s responsibility domain.

3. Provide transparency into supply‑chain SSRM applicability by documenting how SSRM requirements flow down to your own suppliers, partners, and third‑party service providers, including any inherited or shared controls.

4. Ensure customers have easy access to SSRM guidance through documentation portals, customer support channels, technical repositories, or service onboarding materials.

5. Maintain and update SSRM guidance regularly to reflect changes in your services, supply‑chain partners, regulatory obligations, or security practices that may alter SSRM applicability for your customers.

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 Application Providers (AP)

Role Specific:

1. Assign specific ownership for integration-layer SSRM controls to roles including: Supply Chain Integration Owner: Responsible for MP, OSP, and CSP security coordination, End-to-End Security Owner: Responsible for cross-component data flow and API security, Vendor Compliance Owner: Responsible for enforcing security requirements across all suppliers

2. Establish clear ownership boundaries between component security (MP models, OSP services, CSP infrastructure) and integrated system security to prevent coverage gaps.

3. Define escalation paths for cross-component security issues that ensure coordinated response when incidents span multiple suppliers (e.g., MP model vulnerability affecting AP application).

4. Establish customer data protection control ownership between privacy teams for regulatory compliance, security teams for data handling controls, and engineering teams for application-level data protection implementation.

[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 Application Providers (AP)

Role Specific:

1. Review and validate Application Assurance Reports to ensure accurate representation of end-to-end supply chain security status, customer security responsibilities, and application-level controls before delivery to AI Customers.

2. Review upstream supply chain documentation consolidation ensuring accurate compilation of Model Security Manifests, Service Assurance Documentation, and infrastructure attestations into comprehensive customer-facing security evidence.

3. Ensure customer onboarding documentation accurately reflects current security setup requirements, user training materials, compliance configuration guidance, and ongoing support procedures for AI Customer organizations

4. Validate application integration documentation including upstream AI service integrations, API security implementations, data flow security controls, and customer data protection measures throughout the application stack.

[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 Application Providers (AP)

Role Specific:

1. Implement integration-layer security controls for: API security and endpoint protection between components, Data flow encryption between MP, OSP, and CSP services, Access management for the integrated AI application.

2. Operate customer data protection controls covering data encryption at rest and in transit, customer data segregation, privacy controls, and secure data handling throughout the application lifecycle.

3. Audit application integration security controls including regular assessment of upstream AI service integrations (MPs, OSPs), API security implementations, and end-to-end data flow protection effectiveness.

4. Maintain Application Assurance Report processes ensuring comprehensive documentation of implemented security controls, regular updates reflecting application changes, and consolidated evidence from entire upstream supply chain.

5. Implement customer configuration security controls covering secure default settings, customer security responsibility guidance, configuration validation procedures, and ongoing compliance monitoring of customer implementations.

6. Operate application incident response controls including customer notification procedures, application-level security monitoring, customer support security protocols, and coordinated response with upstream providers.

[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 Application Providers (AP)

Role Specific:

1. Maintain comprehensive inventory of upstream AI service relationships including Model Providers, OSPs, direct AI APIs, and integrated AI services with integration details, performance baselines, and dependency classifications.

2. Document cloud hosting and infrastructure relationships covering application hosting providers, CDN services, database providers, application monitoring tools, and backup services with configuration details and service dependencies.

3. Catalog customer and end-user relationships including AI Customer organizations, enterprise clients, individual subscribers, and reseller partners with usage agreements, support obligations, and data handling commitments.

4. Inventory application development and support dependencies documenting third-party development tools, security scanners, testing platforms, analytics services, and customer support platforms with vendor information and integration scope.

5. Maintain customer-facing service relationships including payment processors, identity providers, customer support services, compliance auditors, and legal service providers supporting application operations.

6. Document application ecosystem partnerships covering integration partners, marketplace relationships, third-party plugin providers, and customer onboarding service providers with partnership terms and mutual dependencies.

[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 Application Providers (AP)

Role Specific:

1. Track application-level BOMs for AI services including SDKs, feature toggles, and model endpoints.

2. Document third-party UI libraries or feedback mechanisms tied to AI feature sets.

3. Use BOMs to assess the downstream impact of updating models or integrations.

4. Include vulnerability scanning outputs tied to BOM entries.

5. Support export of BOM metadata for customer audits or platform reviews.

[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 Application Providers (AP)

Role Specific:

1. Assess model integration risks covering API security vulnerabilities, model performance degradation, model drift detection failures, and upstream service dependencies.

2. Evaluate customer-facing risks including end-user data exposure, privacy regulation violations, customer configuration errors, and user authentication system failures.

3. Monitor regulatory compliance risks across multiple customer jurisdictions including data residency violations, changing privacy laws, and customer-specific compliance requirements.

4. Input sanitization & Output validation: Validate inputs before sending them to the model (length, format, anomaly detection, adversarial input filters). Apply sanity checks, thresholding, and monitoring to detect unexpected or adversarially manipulated outputs.

[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 Application Providers (AP)

Role Specific:

1. Define integrated system scope and characteristics that encompass the complete AI solution, including: How MP models, OSP services, and AP code integrate, End-to-end data flows across the entire system, Performance and reliability expectations for the integrated solution, etc.

2. Include end-to-end security requirements that coordinate across all components: Security responsibility matrix covering AP, MP, OSP, and CSP layers, Incident escalation paths from component providers to AP to AIC, Coordinated logging and monitoring across the entire stack, etc.

3. Establish integrated change management protocols addressing: Dependency mapping between component updates (e.g. MP model changes to AP integration changes), Coordinated release schedules across the supply chain, Impact assessment for changes at any layer on the overall system, etc.

4. Define system-wide interoperability requirements ensuring: API compatibility between all integrated components, Data format consistency across the processing pipeline, Performance SLAs that account for all dependent services, etc.

5. Include supply chain transparency provisions requiring: Disclosure of key subcontractors (MPs, OSPs) to AICs, Notification processes for changes in underlying providers, Access to compliance evidence from critical suppliers, etc.

6. Address integrated data privacy across the pipeline covering: Data handling responsibilities at each processing stage, Cross-border transfer implications for the complete solution, Data lifecycle management from ingestion to final output, etc.

[All Actors]

1. Develop standardized contract templates that include all required STA-10 provisions as baseline requirements for all supply chain agreements. Incorporate all required provisions into service agreements including scope definition, service characteristics, geographic locations, and business relationship terms for all supply chain partnerships.

2. Include comprehensive requirements in all service agreements, specifically referencing SSRM compliance obligations, required information security standards, and needed controls, along with other key terms such as service scope, change management, monitoring, incident response, audit rights, termination, interoperability, data privacy, and operational resilience.

3. Maintain a repository of negotiated contract clauses for each STA-10 requirement to ensure consistency and leverage best practices across all agreements. Establish logging and monitoring requirements in agreements specifying data collection obligations, retention periods, access rights, and reporting frequencies.

4. Implement a process to update standard contractual terms when SSRM requirements, security standards, or regulatory obligations change. Define change management processes in contractual terms including notification procedures, approval workflows, impact assessments, and rollback provisions for service modifications.

5. Define approval workflows that require security and legal stakeholders to confirm STA-10 compliance before contracts are executed.

6. Define service termination procedures including data return/destruction, transition assistance, and post-termination obligations.

STA-12: Supply Chain Agreement Review

Control Specification

Review supply chain agreements at least annually, or upon significant changes.

Shared Implementation Guidelines

[All Actors]

1. Establish annual review schedules for all supply chain agreements, contracts, and service level agreements with vendors, suppliers, and partners involved in AI system delivery

2. Define review triggers for agreement updates including significant business changes, regulatory updates, security incidents, vendor changes, or technology modifications

3. Evaluate agreement adequacy by assessing whether current contractual terms address evolving security requirements, data protection needs, and operational dependencies

4. Review contractual obligations including security commitments, liability terms, data handling requirements, incident notification procedures, and termination clauses

5. Update agreements based on review findings, incorporating new security requirements, regulatory changes, lessons learned from incidents, and evolving business needs

6. Document review outcomes including identified gaps, required updates, renegotiation priorities, and timelines for agreement modifications

7. Coordinate cross-functional reviews involving legal, security, procurement, and technical teams to ensure comprehensive agreement evaluation.

Implementation Guidelines for Application Providers (AP)

Role Specific:

1. Review end-user license agreements and terms of service with AI Customers to ensure Application Assurance Report delivery obligations, customer security configuration responsibilities, and usage limitation terms remain appropriate.

2. Evaluate application hosting and CDN agreements for application-specific requirements such as geographic distribution terms, user data handling provisions, and application performance guarantees.

3. Assess upstream integration agreements with OSPs and Model Providers to verify consolidated service delivery terms, liability flow-through provisions, and end-customer support obligations are adequate.

4. Review customer data processing agreements to ensure compliance with evolving privacy regulations, data residency requirements, and customer consent management obligations.

5. Update customer-facing agreement terms based on reviews to reflect changes in application capabilities, new regulatory requirements, or shifts in customer usage patterns and compliance needs.

[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 Application Providers (AP)

Role Specific:

1. Conduct annual internal assessments of application development processes, user interface security controls, and integration configurations to verify conformance with SSRM standards and application security policies.

2. Evaluate effectiveness of application security practices including user authentication systems, data handling procedures, AI model integration controls, and customer data protection measures across the application stack.

3. Assess compliance with contractual obligations to upstream providers (MPs, OSPs, CSPs) and downstream customers (AICs) regarding application security, privacy commitments, and service level agreements.

4. Review application delivery governance including software development lifecycle processes, security testing procedures, deployment controls, and customer onboarding security across the entire application ecosystem.

5. Validate service level agreement performance with upstream providers (model and service suppliers) and downstream customers (AI Customer organizations) to ensure contractual application performance and security commitments are being met.

6. Document assessment outcomes in Application Assurance Reports and compliance documentation, identifying gaps in application security practices and establishing improvement plans for the application platform.

7. Assess end-to-end compliance integration by reviewing how effectively the entire upstream supply chain security posture (MP, OSP, CSP) is consolidated and presented to AI Customers through application-level controls.

8. Evaluate customer security configuration effectiveness by assessing how well customer-configurable security features are implemented and whether customers are successfully meeting their security responsibilities.

[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 Application Providers (AP)

Role Specific:

1. Establish comprehensive compliance policies for Model Providers, OSPs, cloud hosting services, third-party APIs, application infrastructure providers, CDN services, and monitoring tools covering information security, data confidentiality, access control, privacy protection, audit requirements, personnel policies, and service level standards.

2. Flow Down Customer Requirements to Suppliers. For example, if the AI Customer (AIC) has specific compliance needs (e.g., HIPAA, GDPR), ensure these are formally flowed down through amended agreements to the relevant MPs and OSPs. The AP is responsible for ensuring the entire chain beneath them can support the customer’s requirements.

3. Maintain a Centralized Contractual Compliance Ledger. A master inventory that links: Customer Contracts (and their specific security requirements), Supplier Contracts (and their flowed-down obligations), Evidence Artifacts (SOC 2 reports, Manifests, Assurance Packs). This ledger could be the single source of truth for demonstrating compliance during audits or vendor reviews.

4. Monitor service provider compliance through application performance monitoring, security incident tracking, user access audits, and periodic compliance reporting from all suppliers involved in application delivery.

[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 Application Providers (AP)

Role Specific:

1. Establish a formal set of security and compliance requirements that all suppliers (Model Providers, OSPs) must meet. This becomes the baseline for all contracts and assessments. Clearly define the “rules of the road” for suppliers, including required certifications (e.g., SOC 2), vulnerability disclosure SLAs, and breach notification timelines.

2. Perform rigorous security assessments of all new Model Providers and OSPs before integration. This must include: Review of their compliance reports (SOC 2, etc.), Evaluation of their security documentation (e.g., their “Model Security Manifest” or “OSP Assurance Pack”), Technical architecture reviews for critical partners.

3. Collect, validate, and manage the assurance evidence from all key suppliers:

   • From MP: The Model Security Manifest (SBOM, Model Card, robustness evidence).

   • From OSP: The OSP Assurance Pack (compliance reports, data handling procedures).

   • From CSP: Infrastructure compliance reports (SOC 3, ISO certs).

4. Synthesize the evidence from your suppliers with your own security posture (your SOC 2, pentest results) into a single, coherent Application Assurance Report. This report provides the AIC with a holistic view of the application’s security without needing to assess every supplier themselves.

5. Implement Continuous Monitoring of the Supply Chain: Periodically re-assess suppliers (e.g., upon major version releases, annually). Monitor suppliers for security incidents and newly disclosed vulnerabilities that affect their components integrated into your application. Have a process to quickly take action (e.g., patch, rollback) if a supplier is compromised or found to be non-compliant.

6. Create and maintain a master SBOM for the entire application. This SBOM must not only list your first-party code but also integrate the SBOMs of your suppliers, providing a complete bill of materials from the application UI down to the foundational model and its dependencies.

[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 Application Providers (AP)

Role Specific:

1. Train internal teams including application developers, software engineers, product managers, DevOps staff, and customer support personnel on SSRM policies and supply chain security risks.

2. Provide ongoing security awareness training for all roles involved in integrating AI models into applications, managing user interfaces, handling customer data, and maintaining application infrastructure.

3. Require contractual commitments from third-party vendors (AI model providers, OSPs, cloud hosting services, third-party APIs, monitoring tools) to maintain SSRM-compliant training for personnel who access or handle AP systems and data.

4. Verify vendor training compliance through security assessments, documentation reviews, and periodic audits of supplier security practices.

5. Coordinate with upstream providers (model providers, OSPs) to ensure consistent SSRM training requirements flow through the supply chain to end-user applications.

[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 Application Providers (AP)

1. Run SAST/DAST on application code and UI layers; integrate results into the shared tracking system.

2. Enforce purpose-segmented environments so exploits in one feature set cannot pivot to others.

3. Provide real-time vulnerability-status APIs to downstream integrators and customers.

[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 Application Providers (AP)

1. Integrate runtime malware protection at the application and server layers; quarantine or block suspicious binaries or payloads.

2. Validate user-uploaded content and API inputs to prevent malicious code injection (e.g., prompt injection, SQLi).

3. Run SAST/DAST combined with software-composition analysis to detect vulnerable or malicious open-source components.

[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 Application Providers (AP)

1. Identify vulnerabilities across applications, APIs, integrations, and AI-enabled components using automated scanning, code analysis, 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 Application Providers (AP)

1. Scope threat models to orchestrated infrastructure threats (e.g., container escapes, network misconfigurations, insecure service mesh).

2. Analyze threats targeting user input / output channels (prompt injection, etc.) and ensure output moderation controls align with the threat model.

[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 Application Providers (AP)

[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 Application Providers (AP)

[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 Application Providers (AP)

[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 Application Providers (AP)

[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 Application Providers (AP)

1.Prioritize vulnerabilities in applications, APIs, integrations, and AI-enabled components based on exploitability, user impact, and business risk.

[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 Application Providers (AP)

1. Prioritize inference-time threats (e.g., prompt injection, adversarial examples).

2. Implement monitoring for malicious usage patterns (e.g., repeated token abuse, unusual queries).

3. Use RASP (Runtime Application Self-Protection) techniques to harden model endpoints.

4. Integrate risk prioritization with DevSecOps pipelines for continuous testing and patching.

[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 Application Providers (AP)

1. Execute regression and security tests (e.g., prompt-injection, input-validation flows) to ensure AI-driven features still behave as expected after remediation.

[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 Application Providers (AP)

[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 Application Providers (AP)

1. Integrate UI-level guardrails (consent prompts, content-safety checks) and ensure that user-facing features honour model-confidence thresholds and human-in-the-loop (HITL) escalation paths.

[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 Application Providers (AP)

1. Endpoint Configuration: Implement endpoint policies for development and testing workstations, defining configuration baselines (encryption, secure configurations) and acceptable use criteria.

2. Device Tracking: Maintain an inventory of all developer and QA devices, ensuring each device meets security and compatibility standards before accessing code repositories or test environments.

3. Component Approval: Curate and enforce an approved set of development frameworks, libraries, and third party services, using peer reviews.

4. Pipeline Integration: Integrate endpoint compliance checks into the CI/CD pipeline to validate device posture (patch level, security software status) as a prerequisite for code commits and deployments.

[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 Application Providers (AP)

1. Establish a list of approved development frameworks, libraries, third-party APIs, and software utilities that developers may use when building or integrating the AI features into the application.

2. Govern end-user device software by specifying which application stores or download sources are permitted if distributing client-side AI applications (e.g. only official app stores for mobile app distribution).

3. Regularly update the approved software/services list to accommodate new tools after security evaluation, and communicate any changes to the development team.

4. Use technical controls or peer reviews to ensure that only approved services and components are utilized in the application environment, preventing the introduction of unvetted software that could compromise data.

[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 Application Providers (AP)

1. Document the OS and hardware requirements for the AI application (and any client components) and share this information with AIC to incorporate into the overall compatibility guidelines.

2. Test the AI application and its components against new endpoint configurations (e.g., upcoming OS releases or major patches) in a staging environment prior to AIC rolling those updates out widely.

3. Collaborate with AIC to resolve any discovered compatibility issues (by updating the application or adjusting configurations) and update the application’s technical requirements documentation to reflect any changes.

[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 Application Providers (AP)

1. Keep an accurate inventory of all devices under the AP’s control that access or store the AI solution’s data (including developer laptops, test devices, production servers, etc.).

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 updates to the AIC on the AP’s device inventory or integrate with the AIC’s asset management system so that AP endpoints are accounted for in the unified inventory.

4. Utilize automated discovery or monitoring tools (in coordination with AIC) within the application provider’s environment to detect any devices that are not yet registered, and promptly register or remove unauthorized/unknown.

[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 Application Providers (AP)

1. Ensure all AP-controlled endpoints (development workstations, administrative consoles, application servers, etc.) are subject to the AIC’s UEM profiles and receive the appropriate security baseline configurations.

2. Configure and maintain AP devices according to the required baseline — installing all mandated patches and security software, and applying configuration settings (such as host firewall rules or encryption) as outlined by AIC policy.

3. Continuously monitor the compliance of application provider devices using the UEM or equivalent tooling, and immediately remediate any non-compliance (e.g., if a security update is missed or a policy is violated, fix it or isolate the device).

4. Report compliance status and incidents to the AIC during regular check-ins, including details of any non-compliant devices and the remediation actions taken, to maintain transparency and accountability for AP device security.

[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 Application Providers (AP)

1. Require all application provider team devices (developer PCs, QA/test machines, etc.) to have a screen lock that engages after a short period of user inactivity, protecting any sensitive application code or AI integration data on those endpoints.

2. Utilize mobile device or endpoint management policies to push company-approved lock screen configurations to every device in the development environment, including enforcing use of a password/PIN or biometric for unlock and a timeout threshold aligned with corporate security standards.

3. Make automatic locking part of the secure development workflow: for instance, configure code repository access or other development resources to only be available from devices reporting an active screen-lock policy, thereby blocking devices that aren’t policy-compliant.

4. Emphasize good security habits by instructing developers and testers to lock screens manually when leaving their stations, even briefly, ensuring that the technical control (auto-lock) is complemented by user vigilance.

[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 Application Providers (AP)

1. Manage any updates or configuration changes to application provider endpoints through the company’s change control process. Treat developer workstations and test devices similar to servers: updates for OS, development software, or security tools should be scheduled and approved, not applied arbitrarily by end users.

2. Require development team participation in change reviews for tools they use. For example, if IT wants to upgrade the code editor or apply an OS patch that might affect the development environment, include senior developers in the change advisory discussion to assess potential impacts on ongoing AI application projects before approval.

3. Synchronize endpoint changes with development cycles. Aim to apply routine patches or updates between sprints or during less critical periods of the release cycle so that developers are less likely to be interrupted by reboots or unforeseen side-effects of a change. Communicate these timings clearly so developers can save work and prepare for any downtime.

4. Keep detailed records of changes on development endpoints. In the event a new software update causes a bug in the AI application, the team should be able to consult the change log to see if a recent change on developer machines could be the root cause. This record should include what change was made, who authorized it, when it was applied, and confirmation that it completed successfully.

[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 Application Providers (AP)

1. Enforce storage encryption on all application provider endpoints that may contain application source code, AI service integration logic, or any sensitive test data. A developer’s laptop or a QA tester’s device should never store such information in plaintext on disk.

2. Verify that mobile devices or tablets used for developing or demonstrating the AI-powered application are encrypted. Modern mobile OSes encrypt by default when a passcode is set; ensure that policy is in place so no one operates a test phone without a PIN (thereby enforcing encryption).

3. Use configuration management or scripts in build pipelines to ensure that any local development or staging environment has encrypted storage. For instance, if a Docker container or VM is used on a developer machine for testing, ensure the host machine’s drive is encrypted, or use encrypted containers for any sensitive data volumes.

4. In the event that an application provider device is decommissioned or repurposed, follow a secure wipe process (which encryption simplifies by allowing crypto-erase). The encryption keys for that device can be destroyed or the drive fully wiped, guaranteeing that no residual data can be recovered by unauthorized parties.

[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 Application Providers (AP)

1. Require that every device in the application provider environment has an approved anti-malware solution installed and running, from developers’ laptops to staging servers. The solution should provide both on-access scanning (scanning files as they are opened or modified) and regular full-disk scans.

2. Make anti-malware part of the baseline developer machine image. When setting up a new development PC, include the anti-malware agent in the default software package, pre-configured with the organization’s policies. This baseline should be kept updated so any rebuilt or new machine starts off protected without gaps.

3. Monitor compliance continuously. Use the UEM or anti-malware management console to track endpoints that haven’t reported a scan recently or that might have missing updates. If a developer temporarily disables their anti-malware for troubleshooting, the system should alert IT/security so they can follow up and ensure it’s re-enabled quickly.

4. Educate the development team on recognizing and responding to malware warnings. Developers might occasionally encounter false positives (their custom code might be flagged by heuristics), but they should know never to just ignore or disable the protection. Instead, there should be a process to analyze the file in question, adjust the anti-malware rules if it’s a false alarm, or thank the system for catching a real threat if it is one. This keeps a security-first mindset even in fast-paced development work.

[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 Application Providers (AP)

1. Ensure application provider endpoints all have their software firewalls enabled and configured with a baseline rule set. A developer’s workstation, for example, typically does not need to accept any unsolicited inbound connections, so that should be blocked. Outbound can be more open, but should still be subject to monitoring or restrictions (e.g., perhaps only allow outbound web traffic through a proxy that filters connections).

2. If developers run local services for testing (like local web servers or databases on their machine), guide them to bind those services only to localhost or the necessary interface, and use the firewall to block external access. This way, if they forget to shut down a test service, it isn’t open to the entire office network or internet.

3. Use automation to enforce firewall settings: the UEM can push a standard config and regularly re-check it. If a developer has disabled their firewall for debugging an issue, have the system auto-enable it after a short time or at least alert IT so that it isn’t left off inadvertently.

4. Provide documentation or training for the dev team on how to request firewall exceptions properly. This ensures if someone genuinely needs to open a port for a business reason (e.g., collaboration on a new tool), they know the process to get a vetted rule added rather than trying to bypass security. Emphasize that the firewall is there to protect their work and the company, so it’s in everyone’s interest to keep it on and strict.

[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 Application Providers (AP)

1. Use DLP solutions on application provider endpoints to prevent source code, embedded AI models, or customer data within the application from leaking. Tag or classify sensitive project files (like the AI module source code or configuration files containing API endpoints) so that the DLP agent recognizes them and disallows moving those files to unauthorized cloud drives, personal email, or external devices.

2. Implement endpoint rules that stop users from using unauthorized file-sharing tools. For example, if a developer tries to upload a file to a personal Dropbox or Google Drive, the DLP agent can either block it or encrypt it such that it’s unreadable outside the company environment. This encourages the use of approved collaboration tools where DLP controls are in place.

3. Combine DLP with endpoint management to enforce safe handling of test data. If the AI application team uses production-like data for testing, DLP should ensure such data doesn’t get saved or transferred to local drives in plaintext. Policies might allow it only in certain directories or require it be deleted after use, with DLP alerting if it’s not.

4. Provide periodic training to the development and support teams about DLP policies and why they exist. When people understand that “we block copying this data to personal devices because it could contain user PII or proprietary algorithms,” they are more likely to comply and not find workarounds. Also, encourage them to report to security if they feel a DLP rule is too hindering so it can be fine-tuned rather than ignored.

[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 Application Providers (AP)

1. Enroll all devices used by the application provider team in remote location tracking via the organization’s UEM. This is particularly important for devices that often travel (developers taking laptops home, devices used in client demos, etc.), as these are at higher risk of loss or theft.

2. Use device location information to aid in asset management. For example, keep an eye on where critical devices are; if a device that should be in the office safe (like a tablet used for AI demo at conferences) shows up as active and in a different city when no demo is scheduled, that could signal unauthorized use or that it wasn’t properly secured.

3. Incorporate a procedure to quickly respond to location data. If a developer reports a laptop stolen from a car, the IT team should immediately obtain its last known coordinates via the UEM and provide that information to the developer and authorities. Possibly, they should also remotely lock or wipe the device depending on circumstances, but the first step is knowing where it went.

4. Respect privacy and legal boundaries when tracking devices. If AP employees use dual-use devices (personal and work), consider using MDM features that allow location tracking only when a device is marked as lost (user-initiated) rather than continuous tracking. Always inform employees of the tracking capability during device provisioning to get their buy-in and avoid surprises if it’s used during a loss incident.

[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 Application Providers (AP)

1. Use remote wipe for any device that holds AI application data or code when it goes missing or is retired from use. For example, if a developer’s laptop that has source code is lost, initiating a wipe protects the intellectual property. If a QA tablet with test customer data is being reassigned, wipe it to scrub any residual data before the next person uses it.

2. Plan the remote wipe as a step in the employee off-boarding checklist. When someone leaves the company, especially from the development or DevOps team, ensure that any device not returned (or personal device that had company data) receives a wipe command. This is in addition to reclaiming accounts and changing passwords; it provides an extra layer of assurance that no project data lingers in their possession.

3. Implement confirmation and communication around remote wipes. For example, if an employee reports a lost device and IT initiates a wipe, let the employee know once the wipe is confirmed so they don’t keep looking for the device or so they understand any corporate data on it is no longer accessible. This also helps them realize personal data might be gone too if it was a full wipe, which is important for transparency.

4. After wiping an endpoint, update your asset inventory and any relevant credentials. Mark the device as wiped in asset records and, if it’s not expected to be recovered, as decommissioned. Also, consider that device untrusted forevermore — if it’s found later, treat it like a new device (clean OS install, fresh enrollment) before use. If the device had certificates or SSH keys, ensure those are revoked or will no longer be accepted by systems, in case someone did image the device before the wipe.

[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 Application Providers (AP)

1. When using third-party developers or service providers in the application’s ecosystem, ensure their endpoints are secured to your standards. Write down a checklist (anti-malware, updates, no unauthorized software, etc.) and have them sign off that they meet this checklist before you grant them access to code repositories or shared development environments.

2. Use collaborative development platforms that allow fine-grained control. Instead of directly giving a contractor VPN access to your network where your code resides, use something like a cloud code repository (Git) with mandatory 2FA and IP restrictions, or a cloud IDE, so that a lot of the work is done in a contained environment. This way, even if their laptop is a bit insecure, your code mostly stays in your controlled cloud environment and isn’t fully downloaded to their disk.

3. Segment third-party contributions and data. For instance, have a separate branch or project space for external developers so you can easily revoke access without affecting internal work, and you can monitor that space more closely. Also, maybe limit their ability to download large datasets or sensitive customer info to their devices, if they need test data, give them sanitized or dummy data to work with whenever possible.

4. Conduct post-engagement audits. Once a third-party development project is finished, audit the code and data access logs to ensure they didn’t pull more information than necessary. If any anomalies, investigate immediately. Also, verify that all access for their accounts have been removed and request return or deletion certification of any confidential data that may have been on their devices, as per the contract.

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