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 Model Providers (MP)

Policy Scope

1. Audit and assurance policies covering AI model development lifecycle, including training data selection, model architecture design, training processes, model validation, testing, and model governance activities.

[Applicable to all providers]

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

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

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

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

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

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

A&A-02: Independent Assessments

Control Specification

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

Shared Implementation Guidelines

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

[All Providers: MP, AP, OSP]

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

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

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

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

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

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

Implementation Guidelines for Model Providers (MP)

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 Model Providers (MP)

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

1. Focus assessments on model development risks, including training data quality, bias, model robustness, and ethical compliance.

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

[All Providers: MP, AP, OSP]

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

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

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

A&A-04: Requirements Compliance

Control Specification

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

Shared Implementation Guidelines

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

[All Providers: MP, OSP, AP]

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

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

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

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

Implementation Guidelines for Model Providers (MP)

[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 Model Providers (MP)

[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 Model Providers (MP)

[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 Model Providers (MP)

[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 Model Providers (MP)

1. Model Baseline Security Definition: define baseline security requirements for the model development lifecycle, covering data collection, preprocessing, model training, validation, and testing.

2. Data security baselines: specify requirements for data security, including access controls, data integrity checks, and privacy-preserving techniques (e.g., anonymization, differential privacy) to ensure protection against unauthorized access, tampering, and privacy breaches.

3. Secure model design baselines: establish baseline requirements for secure model design, including architectural security considerations, robustness against adversarial attacks, and bias mitigation to mitigate risks associated with model vulnerabilities and biases.

4. Model Development Baseline and Documentation: document the baseline in a version-controlled repository and maintain it as a living document to serve as a reference for model development teams and facilitate audits.

5. Communication with OSP and AP: communicate the model security baseline to the OSP and AP to ensure downstream alignment.

6. Define baseline security requirements for the model development lifecycle, including data security and secure model design.

7. Document model development baselines.

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

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

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

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

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

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

AIS-03: Application Security Metrics

Control Specification

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

Shared Implementation Guidelines

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

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

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

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

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

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

Implementation Guidelines for Model Providers (MP)

1. Model-specific metrics: establish model-specific security metrics, such as model accuracy, robustness against adversarial attacks, fairness, and privacy preservation to provide insights into the security and performance of AI models.

2. Automated testing and validation: implement automated model testing and validation processes to continuously measure model performance against acceptable thresholds.

3. Acceptable thresholds: define acceptable thresholds for each metric based on business requirements and industry benchmarks to determine if models meet security and performance requirements.

4. Continuous monitoring: monitor model metrics throughout the development lifecycle and report any deviations or vulnerabilities to ensure early detection and mitigation of model vulnerabilities.

5. Regular review and update: regularly review and update model security metrics to align with evolving threats and best practices.

6. Define model-specific security metrics (e.g., robustness, fairness, privacy).

[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 Model Providers (MP)

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

1. Define and document a secure SDLC process that incorporates security requirements into all phases of model development.

2. Conduct regular security training for model development teams to ensure awareness and adherence to secure coding practices and relevant AI-specific industry standards.

3. Vulnerability Management: Perform static code analysis, vulnerability scanning, and manual code reviews to identify and remediate security issues early in the development process. Continuously scan for and remediate vulnerabilities in code, infrastructure, and third-party components (refer to TVM domain).

4. Secure Coding Practices: Implement secure coding practices, such as input validation, error handling, and least privilege access, throughout the model development lifecycle.

5. Security Testing: Conduct thorough security testing, including adversarial testing and penetration testing, before releasing models for deployment.

6. Secure Deployment and Configuration Management: Implement practices to ensure that AI models are deployed and configured in a secure manner. Automated tools should be used to enforce consistent configurations and monitor for deviations from security policies in CI/CD pipelines.

   • a. Deploy models via secure containerization or virtualization and ensure secure deployment pipelines with appropriate approval gates

   • b. Ensure encryption of data in transit and at rest for model artifacts, training datasets, and inference data

   • c. Leverage identity and access management solutions to safeguard AI endpoints and model APIs

[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 Model Providers (MP)

1. Develop and maintain a comprehensive suite of automated security tests specifically designed for AI models to ensures thorough coverage of AI model security aspects.

2. Implement tests to cover a wide range of security aspects in order identify and mitigate specific AI risks, including adversarial attacks, bias, fairness, privacy, and robustness. Include tests for vulnerabilities specific to synthetic data (e.g., poisoning, privacy leakage) and multi-agent coordination failures. Conduct red-team assessments simulating adversarial use of synthetic data or complex agent interactions that could bypass traditional controls.

3. Integrate automated security testing into the continuous integration and continuous delivery (CI/CD) pipeline for model development for early detection of security issues.

4. Establish clear acceptance criteria and thresholds for security tests, and automatically block the deployment of models that fail to meet these criteria to ensure only secure models are deployed to production.

5. Regularly review and update the automated security tests to keep pace with emerging threats and new testing techniques to ensure effectiveness against evolving threats and techniques.

[All Actors]

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

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

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

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

AIS-06: Secure Application Deployment

Control Specification

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

Shared Implementation Guidelines

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

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

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

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

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

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

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

Implementation Guidelines for Model Providers (MP)

Policy Scope: Secure deployment strategies for AI model training and inference pipelines, including automated deployment of model artifacts, secure API endpoints, and validation of runtime environments. Policies should ensure secure handling of model dependencies, protection against supply chain attacks, and compliance with AI-specific security standards (e.g., OWASP LLM Top 10). Automate model validation and deployment using MLOps tools to ensure consistency and security.

[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 Model Providers (MP)

Policy Scope: Remediation processes for vulnerabilities in AI model development and deployment pipelines, including model training environments, APIs, and inference systems. Policies should address secure handling of model dependencies, mitigation of injection attacks or data leakage risks, and validation of fixes for model-specific vulnerabilities. Automate vulnerability detection and remediation using MLOps tools and integrate with AI-specific security frameworks (e.g., OWASP LLM Top 10).

[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 Model Providers (MP)

Policy Scope:

API security policies cover APIs used in AI model development and delivery (e.g., training pipelines, inference endpoints). Address secure management for model APIs, authorization for accessing models, and regular testing to prevent injection attacks or model theft. Ensure protection of training data and output integrity via API controls.

[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 Model Providers (MP)

Policy Scope: Input validation policies covering the development and deployment of AI models, including validation of training data, model inputs, and API requests. Policies should address protection against adversarial inputs (e.g., data poisoning, model inversion attacks), failure patterns (e.g., biased datasets), and unwanted behavior (e.g., unintended model outputs). Incorporate AI-specific validation techniques, such as adversarial robustness testing, and align with frameworks like OWASP LLM Top 10.

[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 Model Providers (MP)

Policy Scope: Output validation policies covering AI model outputs, including predictions, inferences, and API responses. Policies should address protection against adversarial outputs (e.g., manipulated predictions, model evasion), failure patterns (e.g., biased or incorrect outputs), and unwanted behavior (e.g., harmful or non-compliant outputs). Incorporate AI-specific validation techniques, such as output robustness testing and fairness checks, and align with frameworks like OWASP LLM Top 10.

[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 Model Providers (MP)

1. Isolate training and fine-tuning environments; restrict outbound traffic and enforce signed-artifact requirements to stop tampering with model weights.

[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 Model Providers (MP)

Policy Scope:

Model development policies cover the creation and training of AI models, including scripts for data preprocessing, training pipelines, and model evaluation. Ensure version control for model code and datasets, mandatory code reviews for training algorithms, and static and dynamic code analysis to detect vulnerabilities (e.g., insecure dependencies) within the SDLC.

[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 Model Providers (MP)

Policy Scope:

Sandboxing policies cover tools and plugins used in AI model development (e.g., data preprocessing tools, training plugins). Implement isolated environments (e.g., sandboxed Jupyter notebooks, containerized training jobs) to prevent interactions with critical data stores or systems and limit lateral movement within model pipelines.

[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 Model Providers (MP)

Policy Scope:

Cache security policies cover cache systems used during LLM development and inference (e.g., token caches, model weights in memory). Implement encryption for cached model data, strict access controls for training/inference processes, and mechanisms to avoid retention of sensitive inputs/outputs in fast memory, mitigating risks of data leaks or 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 Model Providers (MP)

Policy Scope:

Input distinction policies cover AI models directly (e.g., LLMs, generative models). Implement border strings (e.g., [USER], [SYSTEM]) and data marking (e.g., metadata tags for training data) within model input pipelines. Use standard templates for prompts to ensure models distinguish and prioritize instructions correctly, reducing risks of injection or misinterpretation.

[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 Model Providers (MP)

[Policy Scope] The Model Provider should define and uphold a comprehensive framework addressing continuity and robustness measures surrounding AI model lifecycle activities. This consists of following sub tasks-:

• Develop structured protocols around lifecycle protection, including model training, storage, and access control.

• Create traceable records covering methodologies, model versions, and key operational parameters and backup training data as applicable.

• Secure formal validation from oversight groups to ensure readiness and alignment with risk tolerances.

• Share guidance and dependencies with downstream parties involved in deployment and integration.

• Implement reliable workflows and support mechanisms to guard against training disruptions which may include backup of training data, if applicable.

• Conduct regular audits and performance trials to verify robustness under different stress conditions.

• Adjust frameworks and plans periodically or when architectural or environmental shifts arise.

• Designing resilience protocols aligned with the unique risks associated with model training, validation, deployment, and version control.

• Recording and gaining internal consent for all continuity blueprints related to AI model operations.

• Sharing resilience expectations with stakeholders and ecosystem partners.

• Implementing safeguards to minimize service disruption and model degradation.

• Periodically gauging effectiveness of recovery strategies and making necessary enhancements.

• Revisiting preparedness and incident handling approaches at least once every twelve months or following material shifts in model architecture or threat landscape.

[ 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 Model Providers (MP)

Policy Scope:

1. Analyze dependencies on specialized computing resources and proprietary frameworks.

2. Examine resilience of model serving infrastructure against various disruption scenarios.

3. Create inventory of model families categorized by business criticality and usage.

4. Document complete training workflows including data sources and processing steps.

5. Assess risks to training datasets including corruption, unavailability, or compromise.

6. Determine acceptable performance degradation thresholds during disruptions.

7. Document downstream impact when model quality or availability is compromised.

[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 Model Providers (MP)

[Policy Scope]

• Maintain consistent inference capabilities despite infrastructure challenges where a DR scenario is being played.

• Preserve intellectual property embedded in model architecture and parameters.

• Enable rapid restoration of stable model which are lightweight model variants when issues emerges.

• Ensure training capability persistence and partial operation capabilities for critical model families.

• Create immutable snapshots of trained models with complete parameter sets

[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 Model Providers (MP)

[Policy Scope]

• Document all model families with criticality ratings.

• Identify recovery time objectives for each model category.

• Implement comprehensive version control for model architectures and parameters.

• Create secure repositories for training datasets with appropriate redundancy.

• Document hyperparameter configurations and training methodologies.

• Develop lightweight variants for operation during resource constraints.

• Conduct regular exercises simulating training environment disruptions

• Validate successful restoration of inference capabilities

• Test model performance under degraded infrastructure conditions

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

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 Model Providers (MP)

{Policy Scope]

• Create living knowledge bases preserving training methodologies and dataset characteristics.

• Document model architecture decisions with rationale and alternatives considered.

• Maintain comprehensive version histories for production models with performance metrics.

• Preserve hyperparameter configurations enabling recreation if catastrophically lost.

• Document clear restoration workflows with verification checkpoints.

• Document fallback models suitable for emergency deployment with resource requirements for emergency retraining scenarios.

[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 Model Providers (MP)

[Policy Scope]

• Training Pipeline Disruption: Simulate failures in data processing workflows by deliberately restrict access to training environments during scheduled tests.

• Model Degradation Events: Introduce synthetic anomalies to test monitoring and detection capabilities. Practice detecting and responding to performance decline.

• Version Rollback Drill: Test rapid deployment of previous stable releases, record the time the complete restoration process for baseline versions.

• Knowledge Transfer Challenge: Validate documentation when key staff are unavailable by assigning recovery tasks to secondary team members to validate knowledge sharing.

[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 Model Providers (MP)

[Policy Scope]

1. Key Stakeholders Matrix:

   • Internal Teams: Engineering, research, quality assurance, and executive leadership.

   • Direct Customers: Orchestration providers and application developers.

   • Ecosystem Partners: Cloud infrastructure providers and specialized hardware vendors.

   • Regulatory Bodies: When incidents affect compliance obligations.

2. Communication Framework:

   • Develop tiered alert templates based on model performance degradation severity

   • Create technical explanation frameworks translating complex issues for different audiences

   • Configure automated monitoring alerts with appropriate distribution rules

   • Create documentation portal for centralized status information access

   • Develop visualization standards for performance impact reporting

   • Create progressive update formats for extended recovery periods

3.Testing and Maintenance:

• Conduct communication simulations periodically, involving downstream partners. Timing can be adjusted as per the org.

• Review and refine notification templates based on recipient feedback.

• Validate emergency channel effectiveness through no-notice activation 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 Model Providers (MP)

[Policy Scope]

1.Critical Assets Protection Strategy:

• Implement comprehensive preservation of model weights with point-in-time recovery capabilities.

• Establish secure repositories for training datasets with immutable snapshot functionality.

• Create versioned archives of model architectures and hyperparameter configurations.

• Maintain secure backups of preprocessing pipelines and feature engineering workflows.

1. Core Development Preservation:

   • Deploy automated daily snapshots of research environments with code repositories.

   • Create secure off-site archival for proprietary algorithms and novel approaches

2. Production Model Safeguards:

   • Establish versioned backup system capturing deployed model states.

   • Create automated verification comparing backup integrity against originals.

   • Implement metadata tagging system tracking model lineage and dependencies.

3. Recovery Readiness:

   • Develop validated restoration procedures with performance verification steps.

   • Create isolated testing environments for backup validation.

[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 Model Providers (MP)

[Policy Scope]

1. Response Structure:

   • Establish a multi-disciplinary team including ML engineers, data scientists, and infrastructure specialists.

   • Designate technical leads authorized to make critical model deployment decisions.

   • Create clear escalation paths for incidents affecting multiple model families.

   • Develop role cards detailing specific responsibilities during different scenarios.

2. Incident Classification:

   • Implement tiered incident levels based on performance degradation severity.

   • Create assessment rubrics for determining model integrity impacts.

   • Establish activation criteria for emergency rollback procedures.

3. Response Phase:

   • Deploy pre-approved fallback models for critical functions.

   • Implement progressive restoration based on service priority.

   • Activate alternative training resources when primary infrastructure affected.

   • Execute data integrity verification before resuming normal operations.

4. Post-Incident Activities:

   • Conduct and document comprehensive analysis of model behavior during incident.

   • Implement identified resilience improvements.

   • Update response procedures based on effectiveness assessment.

   • Document lessons learned for knowledge preservation.

[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 Model Providers (MP)

[Policy Scope]

1. Create scenarios targeting unique challenges of model degradation and corruption.

2. Develop simulation approaches for unexpected inference behavior and data drift.

3. Establish exercise progression building from focused discussions to hands-on activities.

4. Design specialized drills testing model rollback procedures and verification protocols.

5. Conduct isolated testing of model switching procedures in staging environments.

6. Conduct surprise exercises testing readiness for unexpected model behavior.

7. Execute verification drills confirming model performance after emergency deployment.

[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 Model Providers (MP)

[Policy Scope]

1. Identify key computational resources supporting training pipelines and inference serving.

2. Evaluate specialized hardware components requiring backup provisions.

3. Assess dataset storage systems needing protection against unavailability.

4. Determine development environment redundancy requirements for continuity.

5. Implement distributed storage for training datasets with geographic separation.

6. Create standby GPU/TPU clusters with appropriate capacity for priority workloads.

7. Create geographically distributed model hosting with synchronization.

8. Establish monitoring triggering automatic activation of standby resources.

[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 Model Providers (MP)

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

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

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

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

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

[Shared between the MP and AP]

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

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

CCC-02: Quality Testing

Control Specification

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

Shared Implementation Guidelines

[All Actors]

1. Define quality assurance standards for changes, including minimum thresholds for code quality, test coverage, and acceptable vulnerability levels.

2. Document standardized testing strategies for unit, integration, regression, and user acceptance testing before promoting changes.

3. Mandate security testing (e.g., static code analysis, vulnerability scanning) as part of the change control lifecycle.

4. Leverage automated testing frameworks and continuous integration pipelines to validate changes efficiently and consistently.

5. Ensure all testing activities and results are logged and traceable as part of change documentation.

Implementation Guidelines for Model Providers (MP)

1. Establish testing procedures for all model-related changes, including validation of outputs, bias checks, and regression against known benchmarks.

2. Integrate automated testing into the ML lifecycle (e.g., model quality gates, reproducibility checks, inference validation).

3. Maintain detailed documentation of test inputs, expected behaviors, and validation results for model updates.

4. Enforce thresholds for acceptable accuracy, precision, or fairness metrics before approving model promotion.

[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 Model Providers (MP)

1. Perform pre-deployment risk assessments for model updates (e.g., accuracy degradation, fairness regressions, inference cost spikes).

2. Define model rollback plans and validate them before rollout.

3. Assign model stewards or responsible ML engineers to oversee response actions in case of post-deployment risk indicators.

[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 Model Providers (MP)

1. Define baseline environments for AI model training and inference, including pre-approved frameworks, dependencies, data access scopes, logging levels and compute configurations.

2. Ensure baseline includes data access controls, logging defaults, and hardware-specific guardrails (e.g., GPU quotas, sandboxing).

3. Require sign-off from ML, security, and compliance teams before promoting new or updated model environments to production.

4. Link each approved change to dataset lineage for traceability.

[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 Model Providers (MP)

1. Submit model updates (e.g., new parameters, retrained weights, feature changes) through a formal change control workflow.

2. Include validation reports, benchmark comparisons, and rollback mechanisms with each change request.

3. Maintain a log of model changes tied to data versions, hyperparameter sets, and associated audit artifacts.

[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 Model Providers (MP)

1. Establish a formal process for reviewing and approving all model-related changes, including retraining, fine-tuning, architecture updates, or dependency modifications.

2. Require change submissions to include version details, performance benchmarks, dataset lineage, and a risk assessment.

3. Validate model behavior against predefined evaluation criteria such as accuracy, fairness, robustness, latency, and resource usage.

4. Maintain functional baselines consisting of representative prompts or inputs and their expected outputs. Ensure updated models are tested against these baselines to detect regressions, inconsistencies, or unintended shifts in behavior.

5. Document and analyze deviations from functional baselines. Escalate significant variations for further review before approval, particularly for production-facing or regulated use cases.

6. Ensure all model changes undergo peer review, approval by designated model stewards, and are logged in a change control register with timestamps and approver details.

[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 Model Providers (MP)

1. Track model-specific baselines (accuracy, bias, latency, drift metrics) and alert when thresholds are breached.

2. Provide tooling to restore or retrain models automatically after confirmed deviation.

3. Include adversarial-input and data-quality detectors in the alert set.

[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 Model Providers (MP)

1. Allow emergency rollback / retraining of models that exhibit bias, drift or security exploitation; document model-specific compensating controls.

2. Route exception requests and record impact on model cards and deployment manifests.

[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 Model Providers (MP)

1. Capture a rollback point for each model change, including model artifacts, pre/post-performance metrics, and environment specifications.

2. Implement tooling to restore previous model versions with minimal downtime, ensuring audit traceability for each rollback.

3. Validate restored models against functional and compliance benchmarks before re-exposing them to users or production systems.

[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 Model Providers (MP)

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 Model Providers (MP)

Role Specific

1. Designate specific roles for managing encryption of training data, model weights, and inference outputs, ensuring distinct accountability for each asset class within the ML pipeline.

2. Integrate encryption role definitions into ML platform governance, including role-based controls over access to fine-tuning data, checkpoint storage, and key repositories.

3. Conduct periodic validation of model-related cryptographic responsibilities through cross-functional reviews involving security, data science, and engineering stakeholders.

[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 Model Providers (MP)

Role Specific

1. Embed encryption validation into model packaging workflows, ensuring exported model artifacts (e.g., weights, tokenizer files) are encrypted according to policy before distribution or deployment.

2. Implement access-controlled, encrypted storage for training datasets and logs, with role-based restrictions on decryption during preprocessing or model analysis stages.

3. Conduct periodic reviews of inference service configurations to confirm compliance with encryption policies for both output data and telemetry captured during real-time execution.

[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 Model Providers (MP)

Role Specific

1. Integrate algorithm validation steps into model packaging workflows to ensure only approved cryptographic libraries are embedded in serialized models and deployment artifacts.

2. Maintain a machine learning-specific encryption algorithm register that links permitted algorithms to distinct phases of the model lifecycle, such as training, versioning, distribution, and inference.

3. Periodically assess open-source ML libraries and toolkits for compliance with encryption policies, flagging or replacing components that include deprecated or uncertified cryptographic implementations.

[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 Model Providers (MP)

Role Specific

1. Integrate encryption change management into ML pipeline orchestration by tagging model versions with associated encryption configurations and tracking updates during training and deployment.

2. Maintain a secure registry of approved cryptographic modules and key management tools used across model development stages, updating it in sync with algorithm or policy changes.

3. Conduct technical reviews of encryption-impacting changes with both MLOps and data privacy leads to validate that updates do not weaken protections for proprietary or sensitive model data.

[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 Model Providers (MP)

Role Specific

1. Develop a structured evaluation matrix to assess the trade-offs between cryptographic strength and model performance during proposed encryption changes.

2. Involve data privacy, security, and research teams in pre-implementation reviews to ensure that proposed cryptographic updates align with risk tolerance and technical feasibility.

3. Track encryption-related incidents or performance regressions post-change to validate whether cost-benefit forecasts held true and inform future policy adjustments.

[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 Model Providers (MP)

Role Specific

1. Integrate encryption risk considerations into ML pipeline reviews by assessing model artifacts for exposure risk during data ingestion, training, and distribution.

2. Maintain an encryption risk matrix that aligns cryptographic protections to model sensitivity levels (e.g., proprietary, regulated, public), ensuring tailored controls are applied.

3. Use runtime policy enforcement and anomaly detection to monitor access to encrypted model data, triggering alerts when potential misuse or misconfiguration is detected.

[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 Model Providers (MP)

Role Specific

1. Configure model-serving platforms to support AIC-managed encryption keys through CSP-integrated mechanisms such as envelope encryption or key alias resolution for inference data.

2. Implement safeguards in model output pipelines to ensure telemetry, logs, and predictions are encrypted using AIC-held keys where applicable, especially in multi-tenant model serving environments.

3. Conduct platform validation exercises to confirm key usage attribution and that cryptographic boundaries align with customer-managed key expectations defined by CSP controls.

[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 Model Providers (MP)

Role Specific

1. Integrate encryption and key management audits into ML pipeline checkpoints to verify compliance at key stages such as model packaging, storage, and API exposure.

2. Develop and maintain audit dashboards that track key lifecycle events and cryptographic control coverage for training data, inference outputs, and encrypted logs.

3. Conduct post-deployment cryptographic audits after changes to model architecture, serving infrastructure, or data handling policies to confirm continued alignment with approved encryption standards.

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

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

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

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

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

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

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

CEK-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 Model Providers (MP)

Role Specific

1. Configure model-serving and training platforms to exclusively use certified cryptographic libraries for key generation tasks related to securing model weights, checkpoints, and inference outputs.

2. Perform code and container inspections to ensure embedded key generation logic meets required entropy strength and algorithm standards defined in approved policies.

3. Automate compliance checks within ML pipelines to flag unauthorized key generation practices or fallback to insecure random number generation during model lifecycle events.

[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 Model Providers (MP)

Role Specific

1. Configure model-serving and training environments to generate and assign unique keys for distinct tasks such as encrypting training datasets, securing inference responses, and isolating model artifacts.

2. Tag each cryptographic key with a defined usage scope and enforce key separation through access policies embedded in ML pipeline orchestration and deployment scripts.

3. Review telemetry and audit logs regularly to detect cross-purpose key usage and initiate remediation procedures when key assignments violate defined purpose boundaries.

[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 Model Providers (MP)

Role Specific

1. Configure model training and inference infrastructure to enforce cryptoperiods for keys protecting datasets, model weights, and logs, with dynamic triggers based on model sensitivity or access pattern anomalies.

2. Implement automated rotation and re-encryption procedures within ML pipelines to ensure secure rollover of keys without interrupting training continuity or inference service availability.

3. Maintain a versioned inventory of rotated keys and associated model artifacts, enabling rollback or investigation in case of integrity issues or 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-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 Model Providers (MP)

Role Specific

1. Embed automated revocation checks into model pipeline workflows to ensure compromised or deprecated keys are invalidated prior to retraining, packaging, or deployment.

2. Configure access control systems to immediately block access to model-related resources upon key revocation, including storage buckets, registries, and telemetry endpoints.

3. Maintain version-controlled key maps tied to specific model artifacts, enabling secure rekeying and rollback without exposing previously encrypted data.

[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 Model Providers (MP)

Role Specific

1. Establish automated procedures for secure deletion of model-related keys stored in development environments, training clusters, or containers once model versions are retired.

2. Configure revocation protocols for HSM-resident keys protecting model weights or inference endpoints, ensuring that revocation aligns with model deprecation or regulatory sunset timelines.

3. Retain destruction evidence artifacts in a centralized audit repository, including timestamps, affected model components, and validation checks, to support compliance and risk assurance reviews.

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

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

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

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

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

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

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

CEK-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 Model Providers (MP)

Role Specific

1. Integrate key generation into model pipeline tooling with default disabled status, ensuring that keys remain non-operational during storage, bundling, or containerization phases.

2. Establish multi-party approval checkpoints during model deployment that verify key activation readiness and log authorization decisions before enabling inference or data access.

3. Audit key activation trails across all model environments to confirm that cryptographic keys used for training, output protection, or telemetry remain inactive until explicitly authorized.

[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 Model Providers (MP)

Role Specific

1. Configure model management tools to automatically suspend keys associated with compromised models or data during investigation, ensuring no unauthorized access occurs during downtime.

2. Implement an authorization process for reactivating suspended keys, requiring risk assessment, security approval, and verification before keys are re-enabled for model inference or training.

3. Track and log all key suspension and reactivation events, associating each with an impact analysis report to support auditability and regulatory compliance.

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

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

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

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

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

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

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

CEK-17: Key Deactivation

Control Specification

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

Shared Implementation Guidelines

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

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

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

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

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

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

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

Implementation Guidelines for Model Providers (MP)

Role Specific

1. Configure model storage services and inference environments to automatically decommission expired keys, ensuring that expired keys tied to model weights or data are securely deactivated.

2. Enforce cryptoperiod-based deactivation policies through automated key management solutions that validate expiration conditions before allowing any model-related service to access the associated keys.

3. Maintain audit logs that track expired key deactivation events, ensuring they capture the affected model components, the deactivation reason, and any service impacts for compliance verification.

[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 Model Providers (MP)

Role Specific

1. Archive model training and inference keys along with associated model metadata (e.g., training epoch, architecture hash, deployment tag) to support forensic traceability and rollback validation in regulated environments.

2. Restrict access to archived keys to model governance personnel and compliance staff via RBAC-integrated vaults, ensuring keys are not accessible by runtime inference systems or MLOps workflows.

3. Schedule semi-annual audits of the key archival repository to verify alignment with model lifecycle retention policies and document any exception-based access to archived keys for authorized validation or compliance requests.

[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 Model Providers (MP)

Role Specific

1. Implement decryption-only access control for compromised model keys, ensuring they are only used in secure environments for decrypting model weights, training data, or inference outputs, and preventing them from being used for encryption operations in any context.

2. Audit compromised key usage by conducting regular technical reviews and encryption control validations to ensure that the decryption of protected data is performed in line with compliance requirements, and that no unauthorized re-encryption occurs.

3. Ensure clear communication with MLOps, research teams, and security personnel about the restrictions and proper use of compromised keys, documenting all instances of decryption for transparency and compliance with internal governance and legal 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-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 Model Providers (MP)

Role Specific

1. Balance operational disruption and data leakage risks by evaluating the need for key recovery in the context of model training, inference, and data protection, ensuring recovery actions are carefully considered for both business continuity and intellectual property protection.

2. Ensure compliance by approving recovery mechanisms for model-related keys that are aligned with internal risk assessments, governance processes, and regulatory requirements, with documentation of recovery plans and a clear understanding of intellectual property protection needs.

3. Implement recovery safeguards to control access to model-related keys, ensuring that only authorized personnel can initiate recovery actions, and that all recovery events are logged, traceable, and assessed to prevent unauthorized exposure of model data.

[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 Model Providers (MP)

Role Specific

1. Track key material changes by ensuring that model-related keys such as those protecting training data, model weights, and inference outputs are tracked through their lifecycle, including key generation, activation, rotation, suspension, and revocation.

2. Implement monitoring mechanisms by ensuring model environments (training systems, repositories, and API pipelines) are integrated with systems that track and log key status changes, enabling clear visibility into key lifecycle events.

3. Audit key inventories by conducting regular internal audits and technical reviews to verify that key inventories are accurate, discrepancies are addressed promptly, and key lifecycle events (e.g., suspension or rotation) are reported in accordance with legal and regulatory requirements.

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

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

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

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

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

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

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

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 Model Providers (MP)

1. Model Providers should ensure that physical and environmental security policies address facilities where model training, tuning, validation, and storage of model artifacts occur.

2. Policies should cover protection of training data, model weights, and supporting infrastructure, including secure access controls, environmental safeguards, and monitoring.

3. Model Providers should validate that third-party facilities hosting model development environments meet equivalent physical and environmental security standards.

[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 Model Providers (MP)

Role Specific

1. Providers should ensure that they have robust and clearly documented processes for the secure disposal of equipment that is used outside their physical premises, including devices that handle model development, data processing, or inference tasks. These include but not limited to the procedures listed for the CSP. If using third party datacenter vendors, ensure they have these procedures in place.

2. Provider should have an established secure chain of custody for decommissioned equipment with documented handoffs.

3. Implement of data sanitization procedures following in line with NIST SP 800-88 Guidelines.

4. Maintain contractual arrangements with certified disposal vendors who can provide certificates of destruction.

[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 Model Providers (MP)

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. Apply cryptographic protection for models in transit with key management separation and having a multi-step/party approval workflow which requires technical and security stakeholders to authorize such transfers.

[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 Model Providers (MP)

Role Specific

1. Establish dedicated zones for sensitive model development with tiered access controls such as Biometric verification for rooms housing training infrastructure which are under constant surveillance and also environment monitoring to prevent model degradation.

2. Maintain visitor logs with purpose documentation for anyone accessing model development areas and implement “clean desk” practices for areas with model architecture documentation.

[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 Model Providers (MP)

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 specialized tamper-evident containers for physical transport of training data media.

3. Use dedicated and verified transfer services with end-to-end tracking for model transfer media.

4. Establish chain-of-custody documentation for any physical media.

[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 Model Providers (MP)

Role Specific

1. Providers should classify the different types of assets that perform tasks such as data processing , inference based on the risk of data that might affect the organization if exposed

2, Document each model’s purpose, data requirements, and performance characteristics.

1. Create a model registry with version control, documenting model lineage and training datasets.

2. Classify models by sensitivity and business impact and appropriate access controls are applied based on classification

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

4. Implement Physical protection standards for transfer of media.

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

[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 Model Providers (MP)

Role Specific

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

2. Create a comprehensive registry of all AI models including version history, training parameters, and performance metrics. Along with mapping of physical and virtual resources dedicated to model training and serving.

3. Maintain detailed catalogs of all training, validation, and test datasets, and track dataset transformations and preprocessing steps.

[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 Model Providers (MP)

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 access control for model development areas with multi-factor authentication.

3. Create an isolated secure room for storing model weights and sensitive training datasets.

4. Install tamper-evident seals on server racks containing model training infrastructure.

5. Design visitor management workflows with temporary access credentials and mandatory escorts.

[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 Model Providers (MP)

Role Specific

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

2. Implement TPM (Trusted Platform Module) or hardware security modules for all training infrastructure which also include mTLS authentication between model serving endpoints and approved clients. Deploy continuous attestation services to verify hardware integrity and automated revocation for compromised equipment.

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

4. Providers should have hardware identity foundations with trusted platform modules and unique fingerprinting across infrastructure, which combined with authentication mechanism, such as mutual TLS, certificate-based validation, and hardware-bound access controls. Providers should establish continuous attestation services and anomaly detection while protecting infrastructure through secure boot capabilities and hardware roots of trust.

[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 Model Providers (MP)

Role Specific

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

2. Establish graduated security perimeters with increasing restrictions as personnel approach model training environments. Authenticate using multi-factor methods (biometric plus badge) at transition points.

3. Require pre-approved clearance for all non-employee visitors with designated escorts throughout their stay. Log all interactions with sensitive systems.

[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 Model Providers (MP)

Role Specific Providers should implement and maintain surveillance around model related tasks and their hosting in data centres that perform tasks related to data processing, inference etc .

[All Actors except AIC,AP,OSP]

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

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

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

DCS-12: Adverse Event Response Training

Control Specification

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

Shared Implementation Guidelines

[All Actors except AIC]

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

Implementation Guidelines for Model Providers (MP)

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 Model Providers (MP)

Role Specific

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

2. Maintain minimum a foot separation between power and data cables. Implement redundant power pathways with automatic failover

[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 Model Providers (MP)

Role Specific

1. Before deploying or upgrading AI model training hardware, assess the data center’s environmental controls to ensure compatibility with the hardware’s operational requirements, including cooling and humidity management.

2. Maintain logs of environmental conditions (temperature, humidity) during model training and inference operations. Use this data to correlate hardware performance and failure rates with environmental factors, and to inform future hardware procurement and placement decisions.

[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 Model Providers (MP)

Role Specific

1. Restrict access to critical utility services (e.g., power, cooling, network, backup generators) supporting AI model training and inference environments. Ensure only authorized personnel can modify or interact with these utilities.

[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 Model Providers (MP)

Role Specific

1. Conduct regular assessments to identify environmental risks (e.g., flooding, fire, seismic activity, extreme temperatures) at all sites housing AI model training and inference hardware.

2. Ensure that GPUs, TPUs, and other business-critical AI hardware are installed in data centers or rooms that are not located in basements, near water sources, or in areas with known environmental hazards.

[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 Model Providers (MP)

1. Model Providers should establish and monitor infrastructure metrics related to environments used for model training, tuning, validation, and storage of model artifacts.

2. Metrics should include platform health, storage reliability, access events, and configuration integrity of systems supporting model pipelines.

3. Providers should monitor for deviations from approved training and inference environments, unauthorized infrastructure changes, and security baseline drift that could affect model integrity or availability.

4. Metrics should inform incident response and operational decision-making related to model lifecycle management.

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 Model Providers (MP)

1. Model Providers should ensure that infrastructure supporting model training, tuning, and inference is designed for resilience, including redundant compute resources, resilient storage systems, and protected model artifact repositories.

2. Model providers should implement recovery strategies for model pipelines, including the ability to resume interrupted training jobs and restore model states without data corruption.

3. Continuity planning should address dependencies on orchestration platforms, cloud infrastructure, and specialized hardware such as GPUs or accelerators.

4. Model providers should periodically test recovery procedures and validate, address gaps, so that disruptions do not compromise model integrity or availability.

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 Model Providers (MP)

Primary Responsibility: Data security during model training, fine-tuning, and inference.

1. Define policies for data used in model training, including data anonymization and secure storage.

2. Implement differential privacy techniques to protect sensitive data used in training.

3. Ensure compliance with legal and ethical data usage standards for AI models.

4. Maintain documentation on data lineage, provenance, and handling practices.

5. Monitor model outputs for potential privacy violations, ensuring no sensitive data leakage.

6.Data Preparation Policy: Ensure AI models are built on high-quality, reliable data. This should include defining the AI project’s goals, determining specific data requirements, identifying data sources (such as online sources, sensors, databases, or user-generated content), and acquiring data from these sources using methods like web scraping, surveys, and APIs to ensure relevance and reliability.

[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 Model Providers (MP)

1. Use cryptographic erasure of datasets or training checkpoints stored in cloud-native services.

2. Maintain audit trails of deleted datasets and model checkpoints.

3. Upon data-subject request, securely delete affected data and update associated models or re-train where feasible.

4. Apply media-wiping tools (e.g., srm, shred) on local training environments when de-commissioned.

[All Actors]

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

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

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

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

[Shared among: MP, CSP, OSP]

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

DSP-03: Data Inventory

Control Specification

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

Shared Implementation Guidelines

[All Actors]

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

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

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

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

[Shared among: MP, OSP, CSP]

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

Implementation Guidelines for Model Providers (MP)

1. Maintain a metadata inventory of data used for model training, including sensitive attributes.

2. Ensure data anonymisation and de-identification where necessary.

3. Provide mechanisms for model explainability to track usage of sensitive data.

4. Implement access control for datasets used in training models.

[All Actors]

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

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

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

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

[Shared among: MP, OSP, CSP]

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

DSP-04: Data Classification

Control Specification

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

Shared Implementation Guidelines

[All Actors]

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

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

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

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

[Shared among : MP, OSP, CSP]

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

Implementation Guidelines for Model Providers (MP)

1. Classify training datasets based on sensitivity levels, and criticality levels (e.g., public, confidential, personal data).

2. Implement differential-privacy techniques to protect sensitive data.

3. Ensure secure storage and access controls for training datasets.

4. Track data lineage to ensure proper governance of sensitive data.

[All Actors]

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

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

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

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

[Shared among : MP, OSP, CSP]

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

DSP-05: Data Flow Documentation

Control Specification

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

Shared Implementation Guidelines

[All Actors]

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

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

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

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

[Shared among: MP, OSP, CSP]

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

Implementation Guidelines for Model Providers (MP)

1. Document data flow from ingestion to model training and inference.

2. Maintain records of training dataset locations, access policies and model outputs.

3. Ensure data-lineage tracking and version control of datasets.

4. Review and update documentation when datasets or processing locations 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.

[Shared among: MP, OSP, CSP]

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

DSP-06: Data Ownership and Stewardship

Control Specification

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

Shared Implementation Guidelines

[All Actors]

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

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

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

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

[Shared among: MP, OSP, CSP]

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

Implementation Guidelines for Model Providers (MP)

1. Maintain records of training and inference datasets containing personal or sensitive data.

2. Define policies on dataset governance, ownership, and usage rights.

3. Implement traceability mechanisms to track data origins and transformations.

4. Conduct periodic assessments to ensure compliance with data stewardship 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.

[Shared among: MP, OSP, CSP]

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

DSP-07: Data Protection by Design and Default

Control Specification

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

Shared Implementation Guidelines

[All Actors]

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

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

3. Document residual risks and mitigation plans.

[Shared among: MP, OSP, CSP]

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

Implementation Guidelines for Model Providers (MP)

1. Apply secure AI development lifecycle practices, including threat modeling and secure coding.

2. Implement privacy-preserving AI techniques (e.g., differential privacy, federated learning).

3. Regularly test AI models for adversarial attacks and vulnerabilities.

4. Ensure secure data handling in model training and inference.

[All Actors]

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

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

3. Document residual risks and mitigation plans.

[Shared among: MP, OSP, CSP]

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

DSP-08: Data Privacy by Design and Default

Control Specification

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

Shared Implementation Guidelines

[All Actors]

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

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

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

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

[Shared among: MP, OSP, CSP]

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

Implementation Guidelines for Model Providers (MP)

1. Perform a privacy-risk assessment for each model release, checking for re-identification and unintended memorisation of personal data.

2. Publish a model-card or comparable artefact that documents data sources, privacy controls applied, residual risks, and data-subject rights mechanisms.

3. Offer customer-configurable privacy settings (e.g., differential-privacy noise budgets, logging level, data-retention period) and enforce them at run-time.

4. Implement continuous monitoring that scans model outputs for potential leakage of sensitive data and triggers remediation or unlearning when detected.

5. Implement privacy-preserving ML technologies to protect sensitive training data.

[All Actors]

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

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

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

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

[Shared among: MP, OSP, CSP]

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

DSP-09: Data Protection Impact Assessment

Control Specification

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

Shared Implementation Guidelines

[All Actors]

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

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

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

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

[Shared among: AP, AIC, OSP]

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

Implementation Guidelines for Model Providers (MP)

1. Embed DPIA findings in each model’s documentation (e.g., model cards), including residual-risk ratings and approved mitigations.

2. Implement privacy-preserving techniques (differential privacy, federated learning, data minimisation) whenever the DPIA shows elevated re-identification, bias, or adversarial risk.

3. Document the data lifecycle for training and inference stages.

4. Ensure compliance with data protection regulations such as GDPR, CCPA, and ISO 27701.

[All Actors]

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

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

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

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

DSP-10: Sensitive Data Transfer

Control Specification

Define, implement and evaluate processes, procedures and technical measures that ensure any transfer of personal or sensitive data is protected from unauthorized access and only processed within scope as permitted by the respective laws and regulations.

Shared Implementation Guidelines

[All Actors]

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

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

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

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

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

Implementation Guidelines for Model Providers (MP)

1. Apply data minimisation and anonymisation techniques before model training.

2. Enforce strict access controls for model input / output handling.

3. Validate data-processing practices against privacy laws (e.g., GDPR, HIPAA).

4. Ensure model-training environments comply with encryption and data-access auditability.

[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 Model Providers (MP)

1. Implement machine-unlearning techniques or data-exclusion/filtering strategies to support deletion requests.

2. Maintain logs and traceability of training datasets to identify personal data when a DSR is triggered.

3. Provide mechanisms to mask or modify user data embedded in prompt or inference results.

4. Review all DSR requests for potential model retraining or fine-tuning implications.

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

[All Actors]

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

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

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

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

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

DSP-12: Limitation of Purpose in Personal Data Processing

Control Specification

Define, implement and evaluate processes, procedures and technical measures to ensure that personal data is processed according to any applicable laws and regulations and for the purposes declared to the data subject.

Shared Implementation Guidelines

[All Actors]

1. Provide legal accountability and governance enforcement.

2. Maintain data-processing agreements (DPAs) or equivalent contracts with third-party processors for any personal data the actor shares, ensuring it is handled strictly for the declared purposes and in line with applicable laws.

[Shared among: CSP, AP, OSP]

1. Apply technical controls for lawful data location and access.

[Shared among: MP, AIC, OSP]

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

[Shared among: OSP, CSP, AP]

1. Restrict processing paths through policy-driven routing.

[Shared among: AP, AIC, OSP]

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

Implementation Guidelines for Model Providers (MP)

1. Maintain records of data sources and declared processing purposes (Data Processing Records per GDPR Article 30).

2. Validate datasets against declared intent; apply access and use restrictions accordingly.

3. Enforce strict separation of datasets used for different purposes (e.g., via project or tenancy isolation).

4. Use transparency mechanisms (like model cards or training data lineage) to demonstrate compliance.

[All Actors]

1. Provide legal accountability and governance enforcement.

2. Maintain data-processing agreements (DPAs) or equivalent contracts with third-party processors for any personal data the actor shares, ensuring it is handled strictly for the declared purposes and in line with applicable laws.

[Shared among: MP, AIC, OSP]

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

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 Model Providers (MP)

1. Maintain policies ensuring personal data used in training is pseudonymized or anonymized where possible.

2. Document all sub-processing entities involved in model training and evaluation.

3. Define contractual data protection clauses with all downstream processors.

4. Perform privacy impact assessments (PIAs) for any data ingestion or sharing.

[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 Model Providers (MP)

1. Disclose any sub-processors involved in model training or inference that require access to personal data.

2. Maintain detailed logs and disclosure records tied to specific data use cases.

3. Build mechanisms for explicit consent/acknowledgment from data owners before sub-processors are engaged.

4. Share privacy documentation (e.g., DPIAs, access protocols) with downstream users.

[All Actors]

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

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

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

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

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

[Shared among: MP, OSP, CSP]

1. Implement telemetry and visibility tooling (dashboards, access logs) to track real-time data-access events by sub-processors across model-training, orchestration, or infrastructure layers the actor operates, and surface those records for audit.

DSP-15: Limitation of Production Data Use

Control Specification

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

Shared Implementation Guidelines

[Applicable to all service providers]

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

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

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

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

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

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

7. Implement security measures to secure datacenters.

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

9. Implement timely termination and management of employee access.

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

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

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

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

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

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

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

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

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

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

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

Implementation Guidelines for Model Providers (MP)

[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 Model Providers (MP)

[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 Model Providers (MP)

[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 Model Providers (MP)

[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 Model Providers (MP)

[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 Model Providers (MP)

[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 Model Providers (MP)

[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 Model Providers (MP)

[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 Model Providers (MP)

1. Implement a process to document dataset changes and maintain documentations such as change log to include descriptions of changes, including source updates, pre-processing steps, intended use and approval status.

2. Implement a process to conduct periodic audits on a datasets.

3. Establish a qualification and training framework to verify that personnel responsible for data annotation possess adequate domain knowledge and have completed task-specific training to support label accuracy, consistency, and contextual relevance.

4. Implement anomaly detection into the training pipeline to catch outliers and potential data poisoning.

5. Implement checksum or hash validations and integrity checks throughout the data lifecycle.

6. Implement role based access controls and audit logging on all training data repositories.

[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 Model Providers (MP)

1. Implement processes to select the training dataset specifically to reflect real-world scenarios the AI model will encounter, to generate a dataset that aligns with the intended use of the AI model.

   • a. g. Implement a feedback loop to assess AI model outputs, adjust data relevance, and maintain consistency with the model’s goals and real-world expectations.

2. Implement strategies to prevent overfitting by covering a wide variety of cases and is not overly repetitive, fostering data differentiation. e.g. Implement data governance frameworks to assess and validate the relevance and representativeness of input data.

3. Establish regular reviews of data sources to guarantee the quality, consistency, and representativeness of the dataset.

4. Establish ongoing monitoring of model performance and adapt the dataset over time, incorporating new use cases and data to maintain model relevance. e.g. Establish a continuous review process to monitor and update the dataset, reflecting real-world changes, new patterns, and emerging trends.

5. Document data sources and justification for their use to demonstrate compliance with the regulation( EU AI act).

[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 Model Providers (MP)

[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 Model Providers (MP)

[Model Provider]

1. Establish a formal AI Risk Management Framework: Develop and maintain a documented process that identifies, evaluates, and addresses AI-specific risks (e.g., data bias, model drift, unintended outcomes) within your enterprise risk management program.

2. Define AI Governance Roles: Assign clear responsibilities for AI model oversight, validation, and incident response. Ensure senior leadership sponsorship and accountability for risk treatment decisions.

3. Adopt Ethical and Compliance Standards: Integrate ethical frameworks, data privacy rules, and relevant AI regulations into the risk assessment and mitigation processes.

4. Implement Automated Monitoring: Continuously monitor AI models for performance issues and anomalies, triggering defined remediation steps when risk thresholds are exceeded.

5. Enforce Robust Documentation: Document model development, deployment, updates, and decommissioning protocols in the AI risk management policies to ensure transparency and traceability.

6. Periodic Review and Testing: Perform regular risk assessments and stress tests on AI models, updating mitigation controls, policies, and procedures accordingly.

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 Model Providers (MP)

1. Embed AI-specific governance topics (data-quality thresholds, model-registry controls, fairness metrics) into the annual review checklist.

2. Configure model-performance or data-drift monitoring so that, when thresholds are breached, an alert or automatically generated ticket, initiates a policy-review workflow.

[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 Model Providers (MP)

1. Include AI-specific risks (bias, model drift, etc.) in the exception risk assessment.

2. Define rapid-prototype and emergency-patch paths with dual approval and short expiry.

[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 Model Providers (MP)

1. Integrate model lifecycle security into the organization’s InfoSec program, covering development, validation, deployment, and retirement phases.

2. Conduct threat modeling for AI use cases and implement controls to prevent model inversion, evasion, or prompt injection attacks.

3. Use secure development pipelines with signed model artifacts and access control enforcement.

4. Maintain logs for model access, edits, and deployments for traceability.

5. Align testing requirements with AI model validation, including robustness and fairness assessments.

[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 Model Providers (MP)

1. Assign model owners responsible for training-data validation, performance monitoring, explainability artefacts and deployment approvals.

2. Define escalation paths for bias detection, model degradation or unexpected behaviour in production.

3. Clarify approval authority for exceptions, retraining decisions and model retirement; require dual sign-off for critical changes.

[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 Model Providers (MP)

1. Review data usage, model explainability, and output handling requirements from applicable regulations.

2. Document how each model version complies with data protection, bias mitigation, and safety-related provisions.

3. Maintain a regulatory traceability matrix linking model development practices to external compliance obligations.

4. Include regulatory risk evaluations in model impact assessments.

5. Coordinate with legal/compliance to interpret edge-case or novel regulatory requirements for AI systems.

[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 Model Providers (MP)

1. Participate in AI model governance and explainability working groups.

2. Contribute to open research on bias mitigation, interpretability, and robustness.

3. Monitor updates to AI auditing and certification proposals from global regulatory bodies.

4. Incorporate learnings from SIGs into internal model risk management policies.

5. Establish feedback loops between engineering and GRC teams to translate external recommendations into practice.

[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 Model Providers (MP)

1. Embed AUP enforcement logic in model inputs, outputs, or usage gating systems.

2. Log and review interactions that may breach policy thresholds or ethical guidelines.

3. Align model deployment practices with documented AUP enforcement criteria.

4. Provide metadata to downstream systems to support content filtering or usage flagging.

5. Document model limitations and ensure AUP alignment in model cards or datasheets.

[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 Model Providers (MP)

1. Perform AI impact assessments as part of model development lifecycle, including fairness, robustness, and explainability risks.

2. Document potential downstream misuse and include mitigations in model cards or technical documentation.

3. Evaluate dataset bias and assess impact on demographic groups.

4. Collaborate with legal and risk teams to assess implications of model deployment.

5. Maintain versioned impact assessments tied to model versions.

[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 Model Providers (MP)

1. Perform fairness testing on training and validation datasets, and document the distributions and assumptions.

2. Apply fairness metrics like demographic parity, equalized odds, and false positive rate balance where applicable.

3. Include fairness evaluation in model testing and promotion criteria.

4. Track fairness metrics across retraining cycles and model updates.

5. Document known limitations and intended use to prevent out-of-scope deployment.

[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 Model Providers (MP)

1. Bring proposed model use cases, data sources, and deployment plans to the ethics committee for review.

2. Document risks identified and mitigations required by the committee.

3. Maintain a changelog of decisions related to fairness, explainability, and social impact.

4. Ensure ML practitioners are trained on the ethics review process.

5. Escalate novel modeling techniques or sensitive data usage for prior approval.

[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 Model Providers (MP)

1. Design models with post-hoc or intrinsic interpretability based on expected exposure.

2. Provide model-level explanations as part of validation and deployment packages.

3. Document assumptions and known edge cases that affect interpretability.

4. Evaluate trade-offs between accuracy and explainability for each model class.

5. Ensure model metadata includes explainability method selection and rationale.

[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 Model Providers (MP)

1. Publish model cards with performance metrics, training data summaries, evaluation methods, and limitations.

2. Disclose potential risks such as demographic biases, security weaknesses, or edge-case failure modes.

3. Track disclosures over time and version them with model artifacts.

4. Work with compliance teams to ensure disclosure meets regulatory expectations.

5. Provide disclaimers on intended use and known restrictions.

[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 Model Providers (MP)

1. Integrate human-in-the-loop (HITL) processes during model training and validation to review model assumptions, data labeling, and output interpretation.

2. Document checkpoints where human intervention is required before advancing models to the next lifecycle phase (e.g., pre-deployment).

3. Provide explainability tools to enable human reviewers to understand model decisions and intervene in cases of anomalies or ethical concerns.

4. Implement workflows for manual approval of model updates that impact high-risk decisions (e.g., financial scoring, hiring).

5. Establish a formal review committee to approve AI models prior to production deployment in regulated or high-impact domains.

[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 Model Providers (MP)

1. Third-Party Checks: Require equivalent background checks for third-party specialists or contractors contributing to model development.

[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 Model Providers (MP)

[Model Provider (MP)]

1. Policy Scope: Apply acceptable use policies to model creation, training data management, and algorithmic development. Address ethical and legal considerations in model design.

2. Internal/Third-Party Alignment: Ensure third-party contributors to model development adhere to the same acceptable use guidelines, including proper data handling and compliance measures.

[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 Model Providers (MP)

[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 Model Providers (MP)

[Model Provider (MP)]

1. Remote AI Development Environments: Host model training and experimentation in secure, cloud-based environments. Enforce encryption in transit and at rest, and require robust authentication for remote model developers.

2. Model Confidentiality Controls: Use strict role-based permissions and MFA to protect AI models, code repositories, and related intellectual property. Document and communicate proper handling procedures for all remote collaborators.

[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 Model Providers (MP)

[Model Provider (MP)]

1. Model Ownership Preservation: Require terminated personnel to certify that they no longer possess local copies of provider-owned assets or any proprietary training logs.

[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 Model Providers (MP)

[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 Model Providers (MP)

[Model Provider (MP)]

1. Model Access Agreements: Integrate model-specific confidentiality clauses into standard employee agreements. Require developers and data scientists to acknowledge proprietary architecture and algorithm protections before contributing code or accessing model artifacts.

2. Version-Controlled Model Policies: Publish model handling guidelines (including data processing limitations, IP constraints) in a dedicated repository. Update these policies as models evolve and ensure staff acceptance is recorded.

[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 Model Providers (MP)

[Model Provider (MP)]

1. Proprietary Model Protection: Insert provisions within employment agreements to protect model architectures, training algorithms, and related IP, ensuring staff understand confidentiality and ownership terms.

2. Model Security Requirements: Require employees to maintain the integrity of model repositories, emphasizing secure credential management and compliance with established governance policies.

[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 Model Providers (MP)

[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 Model Providers (MP)

[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 Model Providers (MP)

[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 Model Providers (MP)

[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 Model Providers (MP)

[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 Model Providers (MP)

[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 Model Providers (MP)

[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 Model Providers (MP)

[MP] The model provider is responsible for IAM policies surrounding model training data, model development environments, and model storage, including

1. IAM in Model Artifact Handling: Use identity verification processes to enforce limited access to model files and training data. Keep an auditable record of users interacting with model artifacts, including purpose, duration, and scope of access.

2. Separate roles for AI data ingestion, model development, and model deployment.

[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 Model Providers (MP)

[MP] The MP is responsible for establishing strong authentication credential management policies for accessing ML training pipelines, training data, and model storage.

[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 Model Providers (MP)

[MP]

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

   • Identities with access to model training data and environments, including developers and data scientists

   • Service accounts used for model deployment

   • Third-party identities with access to model APIs

   • Identities with access to model storage.

[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 Model Providers (MP)

[MP]

1. The Model Provider is responsible for implementing SoD by

   • SoD between model development and approval for production

   • SoD between training data preparation and model evaluation

   • SoD between access to training data and access to trained model weights

   • Multi-party approval for critical model modifications

[All Actors] Best practices for implementation of Separation of Duties (SoD) include:

1. SoD Role Management and Access:

   • i. A centralized role management system should be implemented to oversee and maintain role permissions

   • ii. Roles overlapping in responsibilities should be minimized to enhance SoD

   • iii. Roles should be created with specific permissions for different functions within the AI system, avoiding assigning a single identity with excessive privileges that could enable unauthorized actions (e.g., critical functions, such as authorization, approval, and execution, should be separated among different identities)

   • iv. Access levels should be segregated to restrict roles and their access to specific portions of the AI system

   • a. For high-risk or critical activities, such as approving transactions or making modifications to sensitive data, a multi-level approval process should be implemented (i.e., multiple individuals from different roles approve an action) separating approval for role assignment and provisioning, role reviews, role changes monitoring, policy exception management, violations reporting, and SoD controls monitoring.

IAM-05: Least Privilege

Control Specification

Employ the least privilege principle when implementing information system access.

Shared Implementation Guidelines

[All Actors] Best Practices for implementing the Principle of Least Privilege (PoLP) include:

1. LP Infrastructure: The AI system’s infrastructure should be designed and configured with PoLP in mind by limiting the privileges of identities to the bare minimum required for their operation.

2. LP Roles and Permissions: Specific actions, data, and resources each role is required to access to perform their duties should be identified in order to determine the appropriate level of access based for each role/identity (RBAC should be utilized to enforce access control permissions).

3. Permission Change Management: Establish a process for requesting, approving, implementing, and documenting permission changes, to prevent undue privilege escalation. Require justification for changes and maintain an audit log.

4. LP Access of Administrative Accounts:

   • i. Administrative accounts (e.g., root or administrator accounts) should have the most restrictive access that is limited to specific tasks and environments, and ensured that they are only used when absolutely necessary

   • ii. MFA should be enforced for all administrative accounts and any other high-risk access points

5. Sensitive Data Access Limitation: Access to sensitive data should be restricted to the minimum number of identities required to accomplish their job function.

6. Unused Privileges Revocation: Identities access privileges should be proactively reviewed on a regular basis in order to revoke unused or excessive permissions to maintain the PoLP and reduce the attack surface.

7. LP Access Reviews:

   • i. Access privileges should be regularly reviewed and assessed to ensure they align with the current job/function requirements, to identify any unnecessary or excessive access and make adjustments accordingly

   • ii. Automated tools should be implemented to continuously monitor and evaluate the effectiveness of PoLP throughout the AI system

8. Temporary Access Grants: Where possible, temporary access grants with automatic expiration should be used so that persistent access to a resource stays limited to the minimum needed.

9. Comprehensive Access Logging: Log any access to resources including explicit purpose for access, in order to inform which roles need persistent access.

Implementation Guidelines for Model Providers (MP)

[MP]

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

   • Granting developers access only to specific model components they’re actively working on

   • Limiting training environment access to only personnel directly involved in model training

   • Implementing fine-grained permissions for training data access, training operations, and deployment activities

   • Creating time-limited privileges for model development

   • Creating read-only roles for visibility into model deployment but without modification rights

[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 Model Providers (MP)

1. Implement role-based access control (RBAC) for developers, data scientists, and ML engineers accessing training data, models, and tools.

2. Ensure model repositories, training pipelines, and deployment systems have controlled access tied to organizational roles.

3. Automate access provisioning for model environments with approval checkpoints for sensitive operations (e.g., production deployments).

4. Maintain an access matrix mapping roles to specific ML lifecycle stages to prevent overprovisioning.

[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 Model Providers (MP)

1. Immediately remove access to model-training, model-registry and deployment systems when personnel leave or change project roles.

2. Ensure CI/CD pipelines invalidate cached credentials and signed artefact permissions for departing users.

[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 Model Providers (MP)

1. Review access to model registries, feature stores, training datasets, and deployment environments.

2. Flag and remediate persistent privileged access beyond required roles (e.g., long-standing root access).

3. Cross-check entitlements against active project timelines to prevent lingering access after model hand-off.

[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 Model Providers (MP)

1. Separate access for data scientists, MLOps engineers, and platform administrators in the AI/ML lifecycle.

2. Prevent the same individual from training, validating, and deploying models without independent oversight.

3. Require dual control for changes to production pipelines involving sensitive or regulated data.

[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 Model Providers (MP)

[MP]

1. Ensure access to training data is time-limited and subject to data owner approval.

[All Actors]

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

2. Implement an approval process for provisioning sensitive privileges.

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

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

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

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

Control Specification

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

Shared Implementation Guidelines

[All Actors excluding AIC]

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

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

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

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

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

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

[AP, OSP, AIC]

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

Implementation Guidelines for Model Providers (MP)

[MP]

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

   • i. Model debugging and training tools

   • ii. exporting/migration of models containing customer information from the authorized environment

   • iii. performing activities such as model distillation

   • iv. deployment or modification of models running in production.

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

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 Model Providers (MP)

[MP]

1. Ensure that model versions & variants are given unique identifiers to ensure they are identifiable when used in Agent-Based systems.

2. Provided mechanisms and procedures to provide downstream consumers with model identifier information to be integrated with their unique ID mechanisms.

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

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 Model Providers (MP)

[MP]

1. Integrate SSO and ensure MFA is required to access sensitive information such as

   • i. Raw Training data

   • ii. Accessing Models or debugging tools that may expose sensitive information iii: ML/AIOps platforms (such as CI/CD, and Model Repositories).

[ALL Actors - AICM - CSP]

1. Authentication Management:

   • i. A centralized authentication system that can manage identities, authentication credentials, and access control permissions across all AI service components should be implemented

   • ii. Users that require privileged access (e.g.,administrators and IT staff) should be identified to establish stricter authentication measures

   • iii. Specific authentication factors and technical measures should be defined and implemented for each access level, including MF A for privileged identities and sensitive data access

2. MFA Usage Scope:

   • i. Sensitive Data Access: Strong authentication should be enforced at all user accounts, requiring a combination of something the user: Knows (such as a password); Has (such as a mobile device or token); Is (such as biometrics); MFA for all users should be enabled, including non-privileged users who access sensitive data.

   • ii. Administrative Access: MFA should be enforced for all administrative access (e.g., access to management consoles, AI lifecycle components, and other critical AI infrastructure elements). If MFA cannot be implemented in a particular situation, the risk should be formally registered

   • iii. Third-Party Access: MFA should be enforced for third-party access, such as through APIs or AI services, to protect against unauthorized access by external entities.

3. Second Factor Authentication: Second factor authentication should be leveraged in addition to passwords to add an extra layer of security by requiring a second factor of:

   • i. Time-Based One-Time Passwords (TOTPs) to allow users to generate temporary codes via email or a smartphone app synchronized with an authentication server.

   • ii. Hardware tokens or USB keys that generate unique codes for authentication.

4. Passwordless Authentication: Passwordless authentication solutions should be implemented that replace traditional passwords with secure alternatives such as phishing-resistant MFA and FIDO2-compliant security keys or biometrics.

5. Authentication Credentials Protection: All authentication credentials should be transmitted through secure channels (e.g., TLS/HTTPS) and never stored in plaintext but rendered unreadable in storage on all system components using strong cryptography.

6. Authentication Credentials Change Approval: Requests to change or modify authentication credentials (i.e., performing password resets, provisioning new tokens, generating new keys) should be approved only after verification of the user’s identity.

7. Continuous User Authentication (CUA): CUA should be leveraged as a method of maintaining user authentication throughout their session, requiring periodic reauthentication to ensure that the user is still authorized and has not been compromised.

8. Single Sign-On (SSO): SSO should be implemented for accessing multiple services and applications with a single login credential to simplify the authentication process for users.

9. Digital Certificates: Digital certificates should be utilized for authentication and authorization purposes, especially for system identities.

10. CRL and OCSP Checks: Certificate Revocation Lists (CRLs) and Online Certificate Status Protocol (OCSP) checks should be implemented to verify the validity and revocation status of digital certificates.

11. Certificate Lifecycle: The lifecycle of digital certificates should be securely managed including issuance, renewal, and revocation.

12. Certificate Storage: Digital certificates should be stored securely, using encryption and access control mechanisms.

13. Authentication Usage Monitoring:

    • i. All authentication mechanisms and enabled features should be properly installed, configured, and authentication logs monitored for the desired and expected results.

    • ii. MFA, credentials, and digital certificate usage patterns should be continuously monitored and reviewed to proactively identify potential vulnerabilities or compromises.

[All Actors]

1. Implement risk-based authentication controls that evaluate host and user risk (examples: IP reputation and requesting device posture).

2. Enforce the use of phish-resistant MFA (Hardware Key, Certificate Based) for high-risk systems where possible.

3. Provide self-service MFA enrollment for AI service users, supporting FIDO2 security keys, TOTP apps, biometrics, and more.

IAM-14: Credentials Management

Control Specification

Define, implement and evaluate processes, procedures and technical measures for the secure management of authentication credentials, including passwords.

Shared Implementation Guidelines

1. Define and enforce authentication credential policies that align with industry standards (e.g., NIST SP 800-63, ISO/IEC 27001), including minimum length, complexity, expiration, and reuse limits.

2. Implement strong hashing algorithms (e.g., bcrypt, Argon2) and salting practices to securely store authentication credentials.

3. Prohibit credential sharing, hardcoding in codebases, or storing credentials in plain text across all AI and infrastructure components.

4. Require multi-factor authentication (MFA) for all privileged and sensitive access accounts.

5. Implement privileged access tools such as credential vaults that securely store, rotate, and manage credentials. These tools should support automatic password generation, credential expiry, and access logging.

6. Conduct regular credential audits to detect weak, default, or compromised credentials across environments.

7. Enforce secure credential reset and recovery processes, including identity verification and logging of all reset activities.

8. Use secrets management tools to securely handle credentials in code, pipelines, or deployment configurations.

9. Educate users and administrators on secure credential hygiene as part of access management training.

Implementation Guidelines for Model Providers (MP)

[MP]

1. Use tools to scan for secrets and credentials, redacting or masking information in training data and request logs if possible.

2. Avoid training models on data with secrets and credentials to avoid unintentional disclosure during model runtime.

3. Ensure that developers are trained on secure credential handling policies and procedures.

[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 Model Providers (MP)

[MP]

1. Ensure only authorized actors can access, modify, train, manage, or deploy specific AI models, training datasets, and other MLOps infrastructure, based on defined roles.

2. When applicable develop and implement a process for the AIC to approve and review access to training data.

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

   • i. Training data

   • ii. AI experiment configuration and data

   • iii. CI/CD pipelines

[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 Model Providers (MP)

[MP]

1. Implement process to track the categorization, classification and ownership for all data used to train model.

2. Implement tools and processes to allow data owner to authorize which roles can access models trained on there data.

3. Implement role based access control in ML/AIOps tools and pipeline to ensure only authorized user have access to information.

4. Implement procedures and tools to track data lineage of training data and its use training models, ensure models are classified based on the information they are trained on.

[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 Model Providers (MP)

[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 Model Providers (MP)

[All Actors]

1. Inventory Agent tools and categorize them based:

   • i. Risk of accessible resource and the operations it can perform on those resources

   • ii. Sensitivity and Criticality of resources

   • iii. Establish stakeholder and tool owners

2. Implement access control mechanism that authorize the agent-based system and/or authorize the user interacting with the agent-based system.

3. Implement policies and workflows to ensure users and not given access to information or privileged outside of the role requirements.

IPY: Interoperability & Portability

IPY-01: Interoperability and Portability Policy and Procedures

Control Specification

Establish, document, approve, communicate, apply, evaluate and maintain policies and procedures for interoperability and portability including requirements for: a. Communications between application interfaces b. Information processing interoperability c. Application development portability d. Information/Data exchange, usage, portability, integrity, and persistence Review and update the policies and procedures at least annually or upon significant changes.

Shared Implementation Guidelines

[All Actors]

1. Define Policy Scope: a) Establish clear policies covering interoperability (API communication, info processing) & portability (app dev, data exchange/usage/integrity/persistence). b) Define/Align with standards for data formats, APIs & protocols.

2. Policy Governance & Review: a) Prepare RACI matrix to define clear responsibilities among different stakeholders. b) Define annual review process (tech, standards, regulations, business needs).

3. Training & Awareness: a) Train personnel on policies/standards.

4. Standardization & Documentation: a) Define specific standards used. b) Provide tools/SDKs/procedures for standard interaction/data transfer. c) Maintain documentation on interfaces, schemas, protocols, procedures. d) Implement version control & communicate changes.

Implementation Guidelines for Model Providers (MP)

1. Establish policies for using standardized data formats (e.g., CSV, JSON Lines, Parquet) for training/validation datasets.

2. Promote interoperable model serialization formats (e.g., ONNX, PMML).

3. Define standards for model metadata.

4. The model provider shall implement and utilize AIOps tools, repositories, and registries to enforce defined standards for machine learning workflows and data formats, thereby supporting interoperability and portability.

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

5. 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 Model Providers (MP)

1. Provide APIs for AI service customers to retrieve their submitted training/validation data, generated model artifacts (if applicable per contract), model metadata, and experiment logs associated with their usage.

[All Actors]

1. API Design & Provision: a) Develop/maintain robust, documented APIs for AI service customer (AIC) data retrieval. b) Ensure APIs cover relevant AIC data scopes. c) Follow API design best practices. d) Follow applicable industry standards for interoperability.

2. Security & Access Control: a) Implement secure authentication/authorization for AI service customer specific data access. b) Ensure data segregation.

3. Performance & Reliability: a) Design for performance/scalability. b) Monitor availability/latency/errors. c) Implement rate limiting.

4. Documentation & Support: a) Provide comprehensive, current API documentation. b) Offer support channels. c) Communicate API changes/versioning proactively.

IPY-03: Secure Interoperability and Portability Management

Control Specification

Implement cryptographically secure network protocols for the management, import and export of data, according to industry standards.

Shared Implementation Guidelines

[All Actors]

1. Protocol Enforcement: a) Mandate current, strong, secure protocols (TLS 1.2+, HTTPS, SFTP, SSH) for all data management/import/export interfaces. b) Disable insecure protocols.

2. Cryptographic Methods: a) Use strong encryption/key lengths for data in transit. b) Implement robust key management. c) Regularly update crypto suites.

3. Data Integrity: a) Implement mechanisms to verify data integrity during transfer (e.g., checksums).

4. Secure Tooling & Endpoints: a) Ensure provided tools/SDKs/endpoints use secure protocols. b) Secure management interfaces (web consoles, APIs) with HTTPS/strong authentication.

Implementation Guidelines for Model Providers (MP)

1. Ensure secure protocols (HTTPS, SFTP) are used for upload/download of datasets, model files, configurations.

[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 Model Providers (MP)

1. Contracts specify if/how trained models, weights, metadata, AI service customer provided datasets, experiment logs can be retrieved.

2. Define model/data format (e.g., ONNX, native format, CSV) and retrieval period 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 Model Providers (MP)

1. Establish policies for securing AI model training environments, including isolation of compute environments, sensitive data, encryption of model weights, and infrastructure resilience.

2. Implement virtualization security best practices to protect against model extraction or poisoning attacks.

3. Ensure access control mechanisms limit least privileged infrastructure-level access to only authorized personnel managing AI training environments.

[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 Model Providers (MP)

1. Develop AI model training-specific resource planning, including GPU/TPU allocation and storage needs.

2. Implement workload scheduling and resource optimization.

3. Ensure redundancy in AI training infrastructure.

[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 Model Providers (MP)

1. Define secure network access policies for AI model training and testing environments.

2. Implement isolation measures to protect training data from unauthorized access.

3. Apply security controls for remote access to model development environments.

[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 Model Providers (MP)

1. Harden AI model training environments against OS-level vulnerabilities.

2. Ensure hypervisor security to prevent unauthorized access to AI workloads.

3. Implement automated compliance checks against provisioned AI training environments to ensure enforcement of secure baselines across infrastructure control planes.

[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 Model Providers (MP)

[All Actors]

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

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

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

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

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

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

1. Define strict boundaries between AI model training, testing, and production environments.

2. Enforce segmentation policies to prevent cross-environment data leakage.

3. Implement monitoring tools to detect unauthorized movements between environments.

I&S-06: Segmentation and Segregation

Control Specification

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

Shared Implementation Guidelines

[All Actors]

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

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

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

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

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

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

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

Implementation Guidelines for Model Providers (MP)

[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 Model Providers (MP)

1. Define security controls for AI model transfers between cloud platforms.

2. Use encryption and authentication measures to protect AI training datasets.

3. Implement access logging for all AI model migrations.

[All Actors]

1. Define Secure Migration Standards.

2. Establish encryption policies for data migration based on NIST and CIS guidelines.

3. Ensure that all cloud migrations follow an approved security framework.

4. Approved Secure Protocols.

5. Use only industry-standard encrypted channels such as TLS 1.2+, IPSec, and SSH.

6. Implement end-to-end encryption for sensitive data transfers.

7. Access Control and Monitoring.

8. Ensure only authorized personnel can initiate migration processes.

9. Implement logging and monitoring mechanisms to track migration activities.

I&S-08: Network Architecture Documentation

Control Specification

Identify and document high-risk environments based on data sensitivity, threat exposure, and business impact.

Shared Implementation Guidelines

[All Actors]

1. Define High-Risk Environments.

2. Establish criteria to classify environments as high-risk.

3. Include data sensitivity, criticality, and regulatory impact in classification. It is recommended the BIA help to identify the critical business functions with high business impact risk.

4. Network Documentation Framework.

5. Maintain up-to-date network topology diagrams.

6. Document segmentation strategies and security zones.

7. Review and Update Documentation.

8. Perform periodic audits to validate network architecture documentation.

9. Ensure updates align with infrastructure changes and emerging threats.

Implementation Guidelines for Model Providers (MP)

1. Document AI training and inference network environments.

2. Define secure data flow diagrams for AI model communication.

3. Implement network segmentation for AI training clusters.

[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 Model Providers (MP)

1. Define security controls for protecting AI training infrastructure.

2. Implement AI-driven anomaly detection for network threats.

3. Monitor API traffic for suspicious activities.

[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 Model Providers (MP)

1. Develop comprehensive logging and monitoring policies covering training, deployment, inference, and continuous monitoring stages.

2. Ensure policies specify what events to log, including access attempts, system interactions, model updates, performance metrics, and security anomalies.

3. Define processes for logging model lifecycle events such as training sessions, versioning, drift detection, and adversarial attack detection.

4. Review and update policies annually or after significant changes in architecture or operational processes.

[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 Model Providers (MP)

1. Implement secure storage mechanisms ensuring logs are encrypted at rest and in transit.

2. Define retention policies based on data sensitivity, compliance requirements, and operational needs.

3. Regularly review protection mechanisms to address new threats and verify log integrity.

[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 Model Providers (MP)

1. Continuously monitor model specific events, including training data access, inference patterns, model-version changes, adversarial input flags and performance drift.

2. Define alert thresholds for security incidents such as unauthorized access, performance degradation, and model drift.

3. Log and correlate model events with underlying infrastructure alerts to aid root-cause analysis.

[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 Model Providers (MP)

1. Grant log access only to approved engineers and researchers; capture interactions with model weights, training datasets and inference APIs, including failed attempts.

2. Integrate compatible logging frameworks (e.g., TensorFlow, PyTorch) so model-specific events are audited without performance impact.

3. Re-evaluate access rules whenever project roles change or a model enters/ exits production.

[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 Model Providers (MP)

1. Monitor training, inference and model-update events for unusual data inputs, adversarial patterns, performance drift or unauthorised registry access.

2. Use compatible framework (e.g., TensorFlow, PyTorch) to capture detailed model behaviour without affecting latency.

3. Escalate model-specific anomalies to data-science and security teams for joint triage.

[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 Model Providers (MP)

1. Ensure training, inference, and deployment logs have consistent timestamps for correlation and auditability.

2. Regularly validate time synchronization to prevent drift and discrepancies; trigger re-sync before checkpointing model artefacts.

3. Document time synchronization settings and dependencies in ML pipeline templates.

[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 Model Providers (MP)

1. Log training sessions, model version changes, inference requests, adversarial input detections and drift metrics; include reference to model ID and dataset lineage.

2. Establish logging guidelines for AI-specific artifacts such as model weights, training datasets, and inference outputs.

3. Revisit the scope whenever a new training pipeline, data source or deployment pattern is introduced.

[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 Model Providers (MP)

1. Define sanitization requirements for model-specific sensitive data, including customer prompts/queries, model inference responses, fine-tuning training data, embedding vectors, model evaluation datasets, and model performance metrics revealing customer identity or usage patterns.

2. Implement customer isolation in sanitized logs to ensure one customer’s prompts, responses, or fine-tuning data cannot be exposed in another customer’s logs or used for model improvement without consent.

3. Configure inference API logging, training pipeline logging, and model serving platforms to sanitize customer prompts, responses, and training data before log persistence or telemetry collection.

4. Establish policies and technical controls preventing use of unsanitized customer log data (prompts, responses, fine-tuning data) for model improvement, research, or analytics without explicit customer consent.

5. Test sanitization effectiveness across model service scenarios, including inference requests with PII, fine-tuning jobs with confidential data, and embedding generation with personal information.

6. Review and update sanitization rules when deploying new model capabilities, AI regulatory changes, or identified privacy risks such as model inversion or training data extraction attacks.

[All Actors]

1. Define and document categories of sensitive data requiring sanitization in logs, including PII, credentials, API keys, session tokens, and confidential business data, as well as AI-specific data: user prompts, model responses, embedding vectors, fine-tuning datasets, model decision metadata, etc. Align this with applicable privacy regulations (GDPR, CCPA, HIPAA, PCI-DSS, EU AI Act) and customer contractual obligations.

2. Implement automated detection mechanisms to identify sensitive data patterns in logs before persistence, using techniques such as regular expressions, pattern matching, data classification tags, named entity recognition (NER), or data loss prevention (DLP) tools.

3. Apply appropriate sanitization techniques (redaction, scrubbing, tokenization, hashing, encryption) to each sensitive data category, with clear justification for technique selection based on retention requirements, investigation needs, and regulatory compliance.

4. Implement sanitization at appropriate pipeline stages (application logging libraries, log collection agents, centralized logging platforms, API gateways) to ensure sensitive data is sanitized before storage, transmission, or third-party sharing.

5. Test sanitization effectiveness regularly using synthetic sensitive data injection scenarios, automated validation, and periodic manual log reviews to detect sanitization bypasses or failures.

6. Establish incident response procedures for sanitization failures, including escalation paths, log quarantine procedures, notification requirements, and remediation timelines.

7. Implement strict access controls and audit trails for any systems storing unsanitized logs or tokenization reversal mappings, with privileged access management and complete logging of all access to sensitive data.

8. Review and update sensitive data categories and sanitization rules annually or when architecture, regulations, threat intelligence, or service features change, and maintain version-controlled documentation.

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 Model Providers (MP)

1. Capture detailed logs of model development activities (training operations, hyperparameter adjustments, code changes).

2. Share pertinent logs (e.g., model versioning, deployment timestamps) with consumers under agreed-upon protocols.

[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 Model Providers (MP)

1. Model Governance Verification: Collaborate with consumers to verify model updates and version changes through secured audit records. Provide documented procedures for log handling and analysis to ensure alignment with consumer requirements.

2. 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 Model Providers (MP)

[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 Model Providers (MP)

[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 Model Providers (MP)

[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 Model Providers (MP)

[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 Model Providers (MP)

1. Provide configurable logging options and security controls (encryption, authentication) for consumer integration.

[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 Model Providers (MP)

[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 Model Providers (MP)

Role Specific:

1. Identification of Trusted Code Sources or Repositories: Clearly define and maintain an updated list of trusted code sources and repositories.

2. Code Review and Security Testing: Establish regular code reviews focused on security vulnerabilities in the training pipeline code. Use automated tools (e.g., static application security testing (SAST), dynamic application security testing (DAST), interactive application security testing (IAST)) to identify issues based on frameworks like OWASP, CSA, NIST, MITRE, MIT.

3. Access Control: Limit access to the training pipeline code repository based on roles and responsibilities. Implement multi-factor authentication (MFA) and use least privilege principles to restrict who can view, modify, or deploy the code, according to IAM controls.

4. Dependency Management: Regularly update dependencies with SCA tools for vulnerability detection.

5. Secure Coding Training: Train developers on secure coding for AI and ML pipelines.

6. Pipeline Segmentation: Segment the pipeline and apply stage-specific security controls.

7. Audits and Updates: Conduct regular audits and update controls as needed.

8. Incident Response: Maintain a response plan for pipeline-related incidents.

9. Definition of Structured Procedures and Responsibilities: Establish well-documented procedures covering operational and technical aspects, including vulnerability thresholds, risk acceptance levels, roles, and responsibilities.

[Shared Responsibilities (Applicable to MP, CSP)]

1. Configuration Management: Secure configurations and credentials with a secrets management tool.

2. Logging and Monitoring: Implement logging, monitoring, and SIEM integration for activity detection.

MDS-02: Model Artifact Scanning

Control Specification

Define, implement, and evaluate policies, procedures, and technical measures for the scanning of model artifacts for vulnerabilities and attacks, at each step of the service lifecycle and at each hand over point. Regularly review and update policies, procedures and technical measures to address model artifact scanning.

Shared Implementation Guidelines

[Shared Responsibilities (Applicable to MP, AP)]

1. Determine which scanners will be used: Periodically conduct research for which attacks have been proven detectable in model files. Ensure that the scanners used are up to date on these attacks and tested for accuracy.

2. Periodic checks: According to risk, deployed models in production should be scanned periodically, especially if running inference on user data.

3. Documentation: Keep logs of model scan results including scan configuration, model identifier, timestamp, stage of service lifecycle, and results. Collect overall metrics from these logs such as issue detection rate and any errors encountered.

4. Resolution Processes: Determine a response plan for any issues found. For critical issues, this should be immediate model quarantine, stopping it in the development cycle or removing it from production, and launching an investigation. For lower severity issues, this may involve limiting the model deployment scope until the issues are investigated. Applications relying on compromised models can be rolled back to a previous model version determined to have a clean scan.

Implementation Guidelines for Model Providers (MP)

1. Determine scanner integration points: After training/fine-tuning, models should be scanned after the training process to make sure nothing in the training data or environment introduced attacks. This also provides a record of a clean state before storage in a model registry.

[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 Model Providers (MP)

Role Specific:

1. Elaborate the standard model card document with essential details about the model to be implemented.

2. Evaluation and Maintenance: Model cards and the associated models should be periodically reviewed, based on risk. Model performance should be measured against metrics documented in the model card to prevent against drift and poisoning. Model cards should be constantly updated based on operational feedback.

[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 Model Providers (MP)

1) Model Description:

• State clear intended use cases and purpose

• Define target users and application purpose

• List key features and capabilities

• Specify any known limitations or constraints

2) Example Input:

• Provide representative input samples

• Include multiple formats if applicable

• Document expected input schema

• Note any input restrictions or requirements, particularly for model failure

3) Example Output:

• Show corresponding outputs for example inputs based on input samples

• Include success and error cases, indicating whether evaluated internally or using an external benchmark

• Document output format specifications

• List possible response types

4) Ownership:

• List primary maintainers/team

• Specify responsible organization

• Include contact information

• Define access and usage rights and follow the OSI nomenclature for license naming

5) Source Information:

• Provide source URL for third-party models or name the team and team members for internal models

• Document original model name/identifier

• Include licensing information and follow the OSI nomenclature for license naming

• List any dependencies and also make it clear if cross-license dependencies exist

6) Creation Date:

• Record initial development date

• Note deployment date

• Track major update timestamps and hash values of the model

• Document review/maintenance schedule

7) Evaluation Data:

• Describe evaluation datasets used

• Document performance metrics

• Include benchmark results, stating clearly if internal or external benchmarks were used

• Note any biases or limitations identified, particularly related to Responsible AI violations

8) Version Control:

• Use semantic versioning (MAJOR.MINOR.PATCH)

• Record current version number

• Document compatibility requirements

• Track model iterations

• Highlight any changes related to the license agreement

9) Change Log:

• Maintain chronological list of changes

• Include version numbers

• Describe modifications made also adding timestamps for all updates

• Note impact of changes

10) Training Data Schema:

• Document data structure

• Define field types and formats

• List required vs optional fields

• Include data validation rules

11) Ethical Considerations:

• Document potential biases in training data and model outputs.

• Specify fairness and bias mitigation strategies applied.

• Define the model’s intended use, limitations, and potential societal impact.

12) Privacy and Security Concerns:

• Document privacy concerns related to the dataset used for model training, ensuring compliance with standard regulations, detailing the methods applied for anonymization, pseudonymization, or data minimization, and specifying whether differential privacy, federated learning, or other privacy-enhancing technologies are implemented to prevent unauthorized data exposure.

• Identify known security vulnerabilities related to the model’s design or deployment. .

• Discuss the potential for adversarial attacks that could exploit security weaknesses.

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 Model Providers (MP)

[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 Model Providers (MP)

1. Proactive Research on Adversarial Threats: Conduct continuous research and study of known tactics, techniques, and procedures (TTPs) used by major threat actors. This can be achieved through reference frameworks (e.g., MITRE ATLAS) or specialized Cyber Threat Intelligence sources in the AI domain.

2. Identify Possible Attack Vectors: List all potential attack vectors, such as input perturbation, model inversion, data poisoning, etc. For a comprehensive reference, organizations can consult the NIST AI 100-2, which outlines various adversarial attack types.

3. Conduct Testing for Model Specific Vulnerabilities: Perform, automatically and/or manually, both white-box and black-box testing using established adversarial attack techniques. These tests should evaluate the model’s robustness against perturbations, edge cases, and other forms of attacks. Additionally, assess data pipelines to detect any vulnerabilities to poisoning.

[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 Model Providers (MP)

[Model Provider (MP)]

1. Define and enforce appropriate system prompts to guide model behavior and to enhance the overall robustness.

2. Evaluate models regularly against known adversarial attack techniques, updating risk assessments and mitigation strategies in accordance with MDS-06.

3. Implement both forward and backward alignment techniques to ensure model consistency and reduce susceptibility to attacks.

Additional mitigation techniques to enhance a model robustness may include:

1. Strength the model by augmenting training data with adversarial examples to improve resilience against adversarial inputs.

2. Apply differential privacy techniques to safeguard against model inversion attacks and protect sensitive data.

3. Conduct adversarial testing & stress testing to evaluate model robustness against attacks.

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 Model Providers (MP)

[Model Provider (MP)]

1. Anytime changes are made to the model, a new checkpoint, containing both the checksum and the version, should be generated (e.g. model version pinning, etc.).

2. Checkpoints should be documented securely, i.e. via immutable log for audits and further reviews.

3. If cryptographic keys are used, standard key rotation and access policies should be established and followed, as per section CEK.

[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 Model Providers (MP)

[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 Model Providers (MP)

[Model Provider (MP)]

1. Identify key performance metrics that are critical to operations (e.g. Model Entropy, Statistical Drift Metrics, Performance-Based Monitoring, Feature Distribution Monitoring, Embedding and Representation Drift Detection, etc.).

2. Implement, when needed, corrective actions that may include: i) Fine-tuning the model with updated data. ii) Expanding or updating the training dataset to reflect new trends. iii) Retraining the model to adapt to changes in data patterns. iv) Adjusting model parameters or algorithms to improve performance under current conditions.

[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 Model Providers (MP)

[Shared Responsibilities (Applicable to ALL actors)]

1. Define service-level agreements (SLAs) or objectives (SLOs) that include metrics reflecting overall model performance and reliability.

MDS-12: Open Model Risk Assessment

Control Specification

Establish a process to evaluate risk associated with open models. Periodically review these risk factors, and implement a process to monitor and mitigate any determined vulnerabilities.

Shared Implementation Guidelines

[Shared Responsibilities (OSP, AP, AIC)]

1. Continuous Monitoring and Updating: Regularly monitor the model for new vulnerabilities and update it accordingly.

2. Community and Peer Review: Eventually engage with the broader AI community for peer reviews and feedback.

Implementation Guidelines for Model Providers (MP)

Not Applicable

MDS-13: Secure Model Format

Control Specification

Adopt secure model formats and processes for AI model serialization where applicable.

Shared Implementation Guidelines

[Shared Responsibilities (OSP-AP)]

1. Verify compliance of models with secure formats before loading them into production systems.

2. Apply security controls to models before deployment, ensuring they do not contain malicious code or deserialization vulnerabilities.

Implementation Guidelines for Model Providers (MP)

[Model Provider (MP)]

1. Adopt Secure formats (e.g. SafeTensor) for the serialization of model files.

2. Implement procedures to ensure model security during serialization and deserialization.

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 Model Providers (MP)

1. Define incident categories related to AI models, including unauthorized access, model theft, and data poisoning.

2. Establish procedures for isolating compromised models and capturing forensic evidence.

3. Train AI teams to identify abnormal model behavior indicative of compromise.

[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 Model Providers (MP)

1. Define and implement a security policy specifically for model development, covering secure coding practices, threat modeling, data handling, and model storage.

2. Establish a policy that mandates the logging of all model changes (e.g., architecture updates, parameter tuning, retraining) to ensure traceability in case of a security incident or breach.

3. Develop a policy for incorporating security checkpoints into the model development lifecycle, including peer review, automated scanning, and approval processes.

4. Maintain a version-controlled policy document that outlines procedures for handling model-related security incidents, including rollback and notification protocols.

5. Enforce policies that require validating the security impact of model updates before release into production environments.

[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 Model Providers (MP)

1. Establish procedures to roll back and quarantine models that show signs of compromise or malfunction (e.g. producing harmful or unintended outputs, etc.)

2. Define protocols for investigating adversarial inputs or compromised training datasets.

3. Identify risks from shadow AI deployments or unauthorized model copies.

[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 Model Providers (MP)

1. Conduct periodic simulations of incidents affecting AI models, such as adversarial input attacks, compromised training datasets, or unintended model behavior.

2. Validate operational readiness to respond to model-related incidents, including procedures for model rollback, retraining, patching, or temporary suspension of affected models.

3. Track and evaluate incident response performance metrics for model-related events, such as mean time to detect (MTTD) and mean time to respond (MTTR), to support continuous improvement of response processes.

[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 Model Providers (MP)

1. Monitor incident response metrics specific to AI model misuse, adversarial attacks, or unauthorized modifications.

2. Track time taken to isolate and recover compromised models.

[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 Model Providers (MP)

1. Classify AI-specific events such as model drift, training data poisoning, or abnormal inference behavior.

2. Establish automated alerting for anomalous output patterns or prompt injection indicators.

[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 Model Providers (MP)

1. Use severity levels to guide decisions on model rollback, retraining, or sandboxing.

2. Differentiate incidents affecting production vs. experimental models.

3. Analyze model behavior, inputs, outputs, tool calls, and training data lineage to identify potential causes of anomalous outputs, model manipulation, or model drift.

[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 Model Providers (MP)

1. Promptly notify customers and regulatory bodies of incidents involving model intellectual property (IP) theft, adversarial manipulation, or unauthorized alterations to model behavior that impact safety or reliability, within defined timelines.

2. Provide forensic evidence showing extent of compromise and mitigation status, including impacted parameters or data subsets, alongside a verified status report of containment and mitigation efforts.

[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 Model Providers (MP)

1. Maintain incident records for events specific to model development and operation, including training data poisoning, adversarial input exploitation, model theft or extraction attempts, unauthorized model access or tampering, and safety guardrail violations.

2. Track and document incidents related to model integrity failures such as unexpected drift, bias amplification, anomalous output patterns, and training pipeline compromises. Document findings as part of the incident record to support downstream root cause analysis by other 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).

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 Model Providers (MP)

1. Maintain contacts for model security owners, responsible ML engineers, and legal response teams.

2. Share escalation contacts with customers in case of critical model security events.

[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 Model Providers (MP)

1. Vet the provenance of training data (e.g., public datasets, licensed corpora) and document sourcing.

2. Use cryptographic verification and checksums for imported models or data.

3. Maintain an inventory of dependencies (e.g., Python packages, AI frameworks).

4. Conduct supply chain mapping of open-source and third-party components.

5. Integrate policies into model development lifecycle.

[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 Model Providers (MP)

Role Specific:

1. Establish model-specific SSRM policies covering: Data provenance and training data security requirements, Model development and training environment security, Model deployment and serving security procedures.

2. Document MP-specific SSRM procedures for: Model integrity verification and digital signing, Training data validation and quality assurance, Third-party library and dependency security review.

3. Develop approval workflows for: Model security policy changes and updates, Data supplier security requirement modifications, Training infrastructure security enhancements.

4. Establish model lifecycle governance policies covering model versioning procedures, security update protocols, end-of-life procedures, and customer notification requirements for model changes.

[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 Model Providers (MP)

Role Specific:

1. Implement SSRM throughout model development supply chain including secure data sourcing procedures, training infrastructure security requirements, and research collaboration security protocols for all model development activities.

2. Document model development SSRM processes covering training data lineage tracking, model versioning security, intellectual property protection measures, and secure model artifact management throughout the development lifecycle. Document model supply chain dependencies including: Data source security assessments and compliance evidence, Model training environment security configurations, Third-party library and dependency security reviews.

3. Implement model-specific risk management by: Assessing risks related to training data quality and poisoning, Managing model integrity and version control security, Addressing model extraction and inversion attack vectors.

4. Manage the model deployment supply chain through: Secure model distribution and access controls, API security for model serving infrastructure, Monitoring for model performance drift and security issues.

[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 Model Providers (MP)

Role Specific:

1. Develop Model Security Manifests that explain SSRM implementation throughout the model development lifecycle, including data sourcing security, training environment controls, and model validation procedures for Application Provider customers.

2. Provide model-specific SSRM guidance detailing how customers should securely integrate, deploy, and monitor models, including usage limitations, security configuration requirements, and ongoing model maintenance responsibilities.

3. Document data provider SSRM compliance in customer guidance, explaining how upstream data sourcing security requirements flow through to model reliability and customer risk management.

4. Create model licensing and usage guidance that clearly delineates MP security responsibilities (model development, validation, delivery) versus customer responsibilities (integration security, usage monitoring, incident response).

5. Establish model support communication channels for ongoing SSRM guidance delivery, including security updates, vulnerability notifications, and evolving best practices for secure model deployment.

[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 Model Providers (MP)

Role Specific:

1. Establish model distribution control ownership between model operations teams for secure delivery, legal teams for licensing compliance, and customer success teams for downstream support obligations.

2. Define escalation paths for model-specific security issues that ensure rapid response to threats like model inversion, extraction, or poisoning attacks.

3. Assign ownership of model development SSRM controls to data science teams, ML engineers, and model validation specialists responsible for training data security, model development lifecycle, and model artifact protection.

[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 Model Providers (MP)

Role Specific:

1. Review and validate Model Security Manifests to ensure accuracy of model development processes, training data sources, security controls, and performance baselines before delivery to Application Providers.

2. Validate documentation of data provider relationships including data licensing agreements, quality assessments, provenance records, and supplier security evaluations for all training data sources.

3. Review model development lifecycle documentation covering secure coding practices, model validation procedures, adversarial testing results, and bias evaluation reports for accuracy and completeness.

4. Ensure data supply chain documentation is current and complete, covering: Data licensing and usage rights agreements, Data preprocessing and anonymization procedures, Third-party data provider compliance evidence.

5. Ensure model distribution documentation accurately reflects current licensing terms, usage restrictions, integration requirements, and support obligations for downstream customers.

[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 Model Providers (MP)

Role Specific:

1. Implement model development security controls including secure coding practices for model training pipelines, data preprocessing validation, model artifact protection, and secure model versioning throughout the development lifecycle.

2. Operate model training environment controls covering secure data ingestion processes, training infrastructure access controls, model experimentation security, and intellectual property protection during collaborative development.

3. Audit model security and quality controls including regular assessment of data sourcing compliance, model bias evaluation procedures, adversarial robustness testing, and model performance validation against security baselines.

4. Maintain Model Security Manifest processes ensuring accurate documentation of implemented security controls, regular updates reflecting control changes, and proper handover procedures to downstream Application Providers.

5. Implement data provider oversight controls covering supplier security assessments, data quality verification procedures, data lineage tracking, and contractual compliance monitoring for all training data sources.

6. Operate model distribution security controls including secure model packaging, digital signing procedures, access control for model repositories, and monitoring of downstream model usage compliance.

[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 Model Providers (MP)

Role Based:

1. Maintain comprehensive inventory of data suppliers including training data providers, labeling services, data brokers, and research data sources with detailed relationship documentation.

2. Document cloud infrastructure relationships covering compute providers, storage services, GPU/TPU vendors, and model training platform dependencies with service scope and risk classifications.

3. Catalog research and development partnerships including academic collaborations, joint venture partners, model co-development relationships, and intellectual property sharing agreements.

4. Inventory downstream customer relationships documenting Application Providers, direct model licensees, and distribution partners with usage terms and support obligations.

5. Maintain technical dependency inventory of third-party libraries, frameworks, pre-trained model components, and development tools with version tracking and supplier information.

6. Document vendor and supplier relationships including facilities providers, security services, compliance auditors, and specialized AI service providers supporting model development

[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 Model Providers (MP)

Role Specific:

1. Document all model components, training datasets, and external libraries used to build or fine-tune AI models.

2. Include dependency versions and license types in each BOM entry.

3. Track updates to training corpora and flag data with known risks (e.g., bias, copyright).

4. Link BOM artifacts to model registries or deployment manifests.

5. Use BOMs to inform model retirement, revalidation, or retraining triggers.

[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 Model Providers (MP)

Role Specific:

1. Develop contingency plans for critical data source loss, training infrastructure failures, and model IP protection breaches that could impact model development and delivery timelines.

2. Dataset validation: Vet training data sources for poisoning attempts, use data provenance tracking, etc

3. Monitor downstream model distribution risks including unauthorized model copying, misuse beyond intended applications, model reverse engineering, and licensing violation by Application Providers

4. Continuous retraining/patching: Establish a lifecycle for patching vulnerabilities and retraining against new attack types.

[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 Model Providers (MP)

Role Specific:

1. Define model-specific scope and characteristics in agreements, including: Model architecture, capabilities, and limitations, Intended use cases and prohibited applications, Training methodology and data sources, Performance specifications and accuracy metrics, etc.

2. Include AI-specific security requirements beyond standard SSRM, such as: Protection of model weights from theft or unauthorized access, Security testing requirements for model APIs and endpoints, Procedures for handling model inversion or extraction attempts, Integrity verification for model updates and patches, etc.

3. Establish model change management protocols that address: Retraining, fine-tuning, or architecture modifications, Version control and compatibility guarantees, Notification procedures for model updates affecting performance, Rollback procedures for problematic model versions, etc. Define model versioning and lifecycle terms in customer agreements including model update notification procedures, backward compatibility commitments, and end-of-life transition support.

4. Define model-specific incident management procedures covering: Response to model degradation or drift, Handling of adversarial attacks or prompt injection, Communication protocols for model failure scenarios, Remediation steps for biased or harmful outputs, etc.

5. Include intellectual property and licensing terms specific to AI models: Usage rights for model outputs and derivatives, Restrictions on model reverse engineering, Data ownership and model weight protection, Attribution requirements for model usage, etc.

6. Address AI-specific interoperability requirements such as: API compatibility and integration standards, Model format and framework requirements, Data schema and preprocessing specifications, Performance benchmarking and testing protocols, 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 Model Providers (MP)

Role Specific:

1. Review model-specific agreement terms including data licensing restrictions, intellectual property rights, model usage limitations, and downstream distribution rights with data providers and research partners.

2. Evaluate agreements with cloud compute providers for model training-specific requirements such as GPU/TPU availability, data residency constraints, and model artifact security during training processes.

3. Assess downstream licensing agreements with Application Providers to ensure Model Security Manifest delivery obligations, support commitments, and model update notification requirements remain appropriate.

4. Review data provider agreements for evolving data quality standards, labeling accuracy requirements, and data provenance documentation that impacts model development.

5. Update model distribution terms based on agreement reviews to reflect new AI regulations, model security standards, or changes in intended model usage patterns.

[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 Model Providers (MP)

Role Specific:

1. Conduct annual internal assessments of model development processes, data handling procedures, and security controls to verify conformance with SSRM standards and internal policies.

2. Evaluate effectiveness of model security practices including data sourcing policies, training environment controls, model validation procedures, and secure development lifecycle implementation.

3. Assess compliance with contractual obligations to data providers, cloud services, and downstream customers regarding model security and data handling commitments.

4. Review model development governance including change control processes, quality assurance procedures, and security review effectiveness across the model lifecycle.

5. Document assessment outcomes in Model Security Manifests and compliance reports, identifying gaps in model development security practices and establishing improvement plans.

6. Validate service level agreement performance with suppliers (data providers, cloud services) and customers (Application Providers) to ensure contractual security commitments are being met.

[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 Model Providers (MP)

Role Specific:

1. Establish comprehensive compliance policies for data providers, labeling services, cloud infrastructure providers, research partners, and compute services covering information security, data confidentiality, access control, privacy protection, audit requirements, and personnel vetting standards.

2. Mandate Compliance in Upstream Contracts. Integrate your security requirements standard into all contracts and agreements with data vendors and Cloud Service Providers (CSPs). Specifically include clauses that require them to:

   • Comply with data licensing and copyright laws.

   • Provide evidence of their security posture (e.g., SOC 2 reports, ISO 27001 certifications, etc.).

   • Notify you of any security incidents that could impact the integrity or confidentiality of your models or training data.

3. Flow Down AP Requirements to Your Suppliers. When an Application Provider imposes specific security requirements on the MP, the MP needs to ensure contracts with their suppliers include flow-down clauses that pass these same obligations to them. This creates a seamless chain of compliance.

4. Document compliance status in Model Security Manifests and maintain compliance records for handover to downstream Application Providers, ensuring transparency of supply chain compliance posture.

5. Monitor service provider compliance through data quality audits, security incident tracking, access control reviews, and periodic compliance reporting from all suppliers involved in model development.

[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 Model Providers (MP)

Role Specific:

1. Conduct periodic governance reviews of data providers, labeling services, cloud infrastructure providers, and research partners to assess their IT governance policies and change management procedures.

2. Evaluate partner governance maturity including their data handling policies, model development oversight, and security governance frameworks.

3. Require governance evidence from suppliers including policy documentation, audit reports, and compliance attestations relevant to model development and training.

4. Prepare Model Security Manifest documenting your own governance practices, security controls, and supply chain governance status for handover to Application Providers.

5. Verify ongoing governance alignment through regular reviews, ensuring partners maintain governance standards throughout the model development lifecycle.

6. Document governance review outcomes and integrate findings into vendor risk management and model security documentation.

[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 Model Providers (MP)

Role Specific:

1. Ensure that AI model developers, service providers, and cloud platform operators are trained on SSRM policies and best practices for managing supply chain security risks.

2. Provide ongoing security awareness training for all roles involved in the development, deployment, and maintenance of AI models, applications, and cloud services.

3. Work with third-party vendors to ensure they are trained on SSRM compliance requirements and understand their role in securing the supply chain.

[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 Model Providers (MP)

1. Monitor model artefacts, training data pipelines and inference binaries for new CVEs and supply-chain weaknesses.

2. Apply threat-intelligence feeds specific to AI/ML frameworks and toolchains.

3. Track remedial actions through the central system and publish model-security advisories to downstream users.

[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 Model Providers (MP)

1. Scan source code, model artefacts and training datasets for embedded malware, poisoned dependencies or malicious prompts before every build.

2. Verify third-party ML libraries and model weights with signatures or cryptographic checksums; block or quarantine artifacts that fail verification in production pipelines and generate warnings in lower environments.

3. Isolate training and fine-tuning environments.

[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 Model Providers (MP)

1. Identify vulnerabilities in AI/ML frameworks, model-serving runtimes, training pipelines, and dependencies using automated scanning and monitoring of CVEs, vendor advisories, and threat intelligence.

2. Assess and prioritize vulnerabilities based on severity and impact to model functionality and security.

3. Track identified vulnerabilities through resolution and ensure coverage across model artefacts and supporting components.

[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 Model Providers (MP)

1. Scope threat models to model-level and training-environment attacks (e.g., poisoning, inversion, membership inference).

2. Perform threat modelling specific to model architectures and training pipelines; include attacks on prompt integrity, gradient leakage and model-weight tampering.

3. Share relevant model-specific threat-intel updates with downstream integrators.

[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 Model Providers (MP)

1. Continuously monitor model repositories and build pipelines for newly disclosed CVEs in ML frameworks; surface findings to downstream integrators.

[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 Model Providers (MP)

1. Generate SBOMs for ML frameworks, libraries and model-weight files; publish them with each model release so downstream actors can track vulnerable dependencies.

[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 Model Providers (MP)

[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 Model Providers (MP)

[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 Model Providers (MP)

1. Prioritize vulnerabilities affecting models, ML frameworks, training pipelines, and dependencies based on severity, exploitability, and impact to model integrity, accuracy, and performance.

[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 Model Providers (MP)

1. Conduct threat modeling on training pipelines to detect data poisoning, model theft, or evasion risks.

2. Prioritize threats related to: Model inversion, Membership inference, Intellectual property theft.

3. Implement integrity controls: model watermarking, differential privacy, secure model update pipelines.

4. Provide documentation on threat exposure assumptions to downstream consumers (Application and Orchestrated Service Providers).

[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 Model Providers (MP)

1. Re-run accuracy, bias and adversarial-resilience tests after patching AI/ML models or model weights; update model cards with verification results.

[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 Model Providers (MP)

1. Include signature and behaviour-based scans of model artefacts and training data repositories; publish metric outcomes in model-security reports for downstream users.

[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 Model Providers (MP)

1. Build model-level guardrails (prompt filtering, output redaction, adversarial-prompt detection) into training and inference pipelines and expose configuration options to downstream users.

[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 Model Providers (MP)

1. Publish and maintain vendor managed VM/container images with full disk encryption, enforced latest OS patches, and pre installed EDR/anti malware agents (e.g., Microsoft Defender for Linux on Azure).

2. Provide a “Model Dev Endpoint Baseline” playbook specifying: disabled root/administrator login; mandatory TLS only communication; secret rotation schedules; and CIS benchmarked configuration settings.

3. Require ingestion of audit logs (e.g., AWS CloudTrail, Azure Monitor) from MP owned endpoints into a SIEM or logging service, with sample reference CloudWatch/Azure Sentinel queries.

4. Issue guidelines for customer managed developer machines: e.g., enforce disk encryption, quarterly patch cycles, and EDR coverage via CSP UEM (Azure Arc, AWS Systems Manager).

[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 Model Providers (MP)

1. Maintain a vetted list of approved software applications, development tools, and cloud services that model developers are permitted to use on model-development devices.

2. Require that only these approved services and app sources (e.g. trusted repositories or libraries) are used when accessing or storing training data and models, preventing unverified software from introduction.

3. Regularly review and update the approved list to include new necessary tools and remove disallowed or obsolete ones, documenting any changes.

4. Enforce the approval list via technical controls (such as software whitelisting or admin restrictions) on model development endpoints to block installation or use of unapproved applications.

[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 Model Providers (MP)

1. Define and communicate the minimum hardware specifications, operating system versions, and required software dependencies for endpoints used in model development or hosting, so that these requirements can be included in the compatibility matrix.

2. Participate in testing new endpoint configurations (such as OS upgrades, patches, or security agent updates) in a controlled setting before wider deployment, to verify that all model-related tools (ML frameworks, libraries, etc.) remain compatible.

3. Notify the AIC promptly of any compatibility issues or special configuration needs for model software (e.g., drivers, libraries) so that the AIC can update compatibility requirements and plan remediations or workarounds in advance.

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 Model Providers (MP)

1. Maintain an up-to-date inventory of all MP-owned devices (workstations, servers, etc.) that store or can access the AIC’s data.

2. Maintain logs for changes made within inventory when a new asset is added or removed. Establish a process of reviewing the inventory of endpoints within centralized UEM /CMDB (Configuration Management Database) to keep the inventory updated and remove inactive endpoints.

3. Share relevant details of the MP’s endpoint inventory with the AIC as appropriate, enabling those devices to be reflected in the AIC’s centralized asset register (subject to confidentiality agreements).

4. Notify the AIC immediately when new endpoints are introduced or when existing ones are decommissioned in the MP environment if those endpoints have access to AIC data, so the central inventory remains accurate.

[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 Model Providers (MP)

1. Enroll all relevant MP devices in the agreed endpoint management program or ensure they are subject to equivalent security controls, so that they receive the required patches, configurations, and software updates.

2. Apply the AIC-defined security baseline on model provider endpoints — this includes installing required security software (antivirus/EDR), applying critical patches promptly, and configuring system settings as specified by the baseline.

3. Monitor the compliance status of MP’s endpoints (patch levels, security agent status, configuration compliance) and immediately address any deviations or UEM alerts (e.g., if a device falls out of compliance, take it out of service or remediate it).

4. Provide regular compliance reports or attestations to the AIC confirming that MP endpoints remain in adherence with the required security controls, and work with AIC on any exceptions or remediation plans for non-compliant devices.

[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 Model Providers (MP)

1. Configure all model development and training endpoints (developer laptops, lab workstations, etc.) to automatically lock the screen after a brief idle interval and require secure re-authentication (password/biometric) to regain access.

2. Use group policies or device management tools to set a firm inactivity timeout (such as 5 minutes) on model provider devices and restrict users from changing or disabling this setting.

3. Include server or cloud-based development environments in the policy: ensure that if model engineers use cloud VMs or remote desktops for development, those sessions also auto-lock or log out when idle to protect sensitive data and code.

4. Perform routine checks (via UEM compliance reports or login audits) to verify all MP team devices adhere to the auto-lock policy and address any cases of non-compliance with immediate configuration updates or user coaching.

[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 Model Providers (MP)

1. Establish a rigorous change management procedure for all model provider endpoint modifications. Model development devices should only receive OS upgrades, security patches, or new software installations in accordance with an approved change schedule or emergency patch process.

2. Use a ticketing system or change request form for tracking endpoint changes. For example, if a data scientist needs a new software library installed on their workstation, they must submit a request that is reviewed for security and compatibility, then scheduled for deployment by IT support.

3. Test significant changes in a controlled environment before wide rollout. If updating the operating system or applying a major patch on multiple model development machines, first apply it on a test machine or a small pilot group to ensure it doesn’t break AI model training tools or environments.

4. Document all changes applied to MP endpoints and keep records accessible. This includes noting the date of patch installations, versions of software changed, configuration changes (like registry or policy updates), and having an approval signature or record for each. This log will help in troubleshooting issues (by correlating problems with recent changes) and in security audits.

[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 Model Providers (MP)

[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 Model Providers (MP)

1. Deploy anti-malware software on all model provider endpoints and ensure it is active at all times. Each model developer’s computer, any servers hosting training data, and even test machines used for model tuning should have an anti-malware agent that provides real-time protection and regular system scanning.

2. Set anti-malware policies specifically tailored to the development environment: for example, allow the agent to scan code repositories, data sets, and model files for known malicious content (ensuring that nothing like a poisoned data file or malicious script is introduced). At the same time, whitelist known safe development tools to avoid unnecessary performance overhead, balancing security with productivity.

3. Keep the anti-malware agents updated and monitor their status via the UEM console. If any developer device hasn’t checked in with an updated signature file or shows the anti-malware service is disabled, trigger an immediate remediation — such as forcing an update, re-enabling the service, or instructing the user to reboot — and don’t allow that device network access to sensitive resources until it’s protected.

4. Incorporate malware response into the MP’s incident response plan. Ensure that if malware is detected on a model development machine, the procedures include isolating that machine from the network, investigating the scope (did it access source code or data?), and cleansing it before it’s allowed back. Also consider requiring a review of how the malware got in (e.g., an unpatched vulnerability, or downloading software outside the approved list) and address that root cause to prevent future incidents.

[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 Model Providers (MP)

1. Configure OS firewalls on all model development endpoints to restrict network traffic. For instance, developer laptops should block all inbound connections by default (except perhaps remote management from IT) and limit outbound communications to known corporate services. This can prevent malware on an endpoint from calling out or an attacker from connecting in.

2. Create specific firewall rules to protect sensitive model data in transit. If certain development servers or databases are only supposed to be contacted by model developer workstations, use host firewall rules on both ends to enforce that relationship (whitelist the IP ranges or hostnames that can communicate).

3. Manage firewall configurations centrally so that model developers cannot turn off their firewall or create exceptions on a whim. If a developer needs to run a local service (e.g., a Jupyter notebook server for model training) and open a port for it, have a process where IT/security evaluates that need and pushes a temporary rule or instructs them on how to safely allow it without exposing it broadly.

4. Include firewall status checks in device compliance monitoring. Any MP device found with its firewall disabled or with unauthorized rule changes (like a broad “allow all” rule) should be immediately flagged. The response could be automated – e.g., the UEM re-applies the correct firewall policy at next check-in – and the incident should be recorded, with follow-up to understand why it occurred.

[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 Model Providers (MP)

1. Deploy endpoint DLP agents on all devices used by the model provider team to detect and prevent unauthorized transfer of sensitive AI assets. Define sensitive data categories such as “Model Training Data”, “Proprietary Model Files”, and “API Keys/Secrets” so the DLP system knows to flag these if someone attempts to move or copy them improperly.

2. Create rules to govern common data egress channels: for example, block or alert on attempts to copy files to USB drives, burn to CDs (if applicable), or upload via web browsers from model development machines unless explicitly authorized for that device/user. This ensures that large datasets or model files can’t be siphoned off without oversight.

3. Integrate DLP with email and messaging on MP endpoints. If a data scientist tries to email out a dataset or share model code via personal email or unauthorized messaging apps, the DLP should catch keywords or fingerprints of that data and prevent the action or warn the user and log the event.

4. Conduct regular reviews of DLP incident logs in the MP environment. If, for example, the DLP reports frequent blocked attempts for a particular user or team (even if accidental), investigate those patterns. It could indicate either insufficient training (they might not realize certain actions are against policy) or an insider threat that merits closer attention.

[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 Model Providers (MP)

1. Require all portable devices used by the model provider team (including laptops that are taken off-site and any tablets or smartphones used for work purposes) to enroll in the company’s device tracking program. This ensures that if, say, a data scientist’s laptop with training data is stolen, the security team can attempt to locate it via GPS or network triangulation.

2. Use geo-location proactively to enforce policy: for example, if model data is extremely sensitive and supposed to only be accessed within certain physical premises (like a secure lab), configure the devices or software to alert if they are powered on or used outside of approved locations. This could be implemented via geo-fencing rules in the UEM (e.g., flag if device connects from outside the city or country unexpectedly).

3. Ensure the model provider’s IT team can remotely activate an “Find Device” mode that not only fetches location but possibly displays a notification on the device (“This device is being tracked by [Company] due to security concerns”) or locks the device after sending its coordinates. This both aids recovery and deters whoever possesses it from continuing to use it.

4. Develop privacy guidelines and get user consent for geo-location tracking on employee devices if required by law or regulation. Be transparent with staff that their work devices have tracking enabled for security and clarify that personal location will only be accessed under defined circumstances (like device loss or suspected theft), to maintain trust and comply with privacy laws.

[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 Model Providers (MP)

1. Equip all model provider devices with company-managed remote wipe functionality. Laptops, phones, or tablets that contain model information should be managed such that, upon a single command from the management console, they will erase all sensitive data or reset to factory defaults.

2. Develop a clear criterion for when to execute a remote wipe. For instance, if a device is reported stolen, or if an employee with access to sensitive AI assets is terminated under adverse conditions (e.g., for misconduct), a remote wipe should be initiated immediately upon loss report or termination. Conversely, if a device is just misplaced in the office, maybe try geo-location first (UEM-12) and reserve wipe if it can’t be found.

3. Use selective wipe for BYOD or personal devices if those are allowed. The MP might allow some team members to use personal devices under strict conditions. In those cases, configure “work profiles” so that a remote wipe will only delete company apps and data (like email, proprietary files, and cached VPN credentials) without touching personal photos or apps, to respect privacy while still securing corporate material.

4. After performing a remote wipe, assess the need for further action. For example, if a wiped device contained extremely sensitive model data, consider that data potentially compromised unless you have high confidence in encryption and the wipe’s speed. In such cases, you might roll additional mitigations: change any passwords that were stored on it, inform affected project stakeholders, and monitor for any signs of that data appearing where it shouldn’t (in case the thief accessed it before wipe). o Implement crypto-shredding by destroying the device’s media encryption key through your centralized key management service; this renders all on-disk ciphertext irrecoverable and accelerates the remote-wipe process without full overwrites.

[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 Model Providers (MP)

1. Include in any contract or NDA with outside collaborators (e.g., external AI researchers, data labeling firms, consultants working on the model) a section detailing security requirements for their devices. For example: “Contractor agrees that any device used to access [Company] data will have full disk encryption, current antivirus, and will not be shared with unauthorized individuals.” This sets the expectation and gives you recourse if they are found non-compliant.

2. Prefer to issue managed equipment to third parties when possible. If a consulting team is coming on board for a six-month project to help with model development, consider giving them company-configured laptops that are already secured and monitored rather than letting them use their own. Retrieve these devices at project end.

3. Limit third-party access to only what’s necessary and only from approved devices/locations. Use methods like whitelisting the IP addresses or device identifiers for contractors so that even if credentials were stolen, they can’t be used from an unrecognized device. If a contractor should only work from their office, block login attempts from other countries or unusual times as an extra layer of security.

4. Conduct exit processes for third parties similar to employees. When a contract ends or a third-party user no longer needs access, immediately revoke their accounts, certificates, and any tokens. If they were using a personal device with cached company data (and it’s allowed by policy), ask them to certify (in writing or by showing proof) that all company data has been deleted and no access persists on their side. In some cases, you might even perform a remote wipe of company-provided devices or containers on their device (leveraging the MDM if they were enrolled under a BYOD container system).

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