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.

Auditing Guidelines for AI Customers (AIC)

1. Confirm that audit requirements for vendors are stated in procurement policies and contracts.

2. Validate if the assurance policy clearly maps cloud provider responsibilities (e.g., shared responsibility model).

3. Check if policies include regular verification of where AI data resides in the cloud and whether it complies with jurisdictional laws.

4. Check Internal Usage Monitoring: examine procedures for auditing how employees interact with cloud-hosted AI tools (e.g., usage logs, session monitoring).

5. Verify an Annual Review Process: examine whether internal reviews or third-party assessments triggered updates to the assurance policies, at least, in the past 12 months.

6. Confirm Follow-up Controls: examine whether processes exist to monitor, track, and close audit findings, ensuring corrective actions are implemented and documented.

A&A-02: Independent Assessments

Control Specification

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

Auditing Guidelines for AI Customers (AIC)

Objective: Ensure that customers conduct or commission independent audits of their own usage of AI systems, including how they manage third-party risks, internal configurations, and responsible AI use.

1. Confirm that the organization do not solely rely on provider audits. Assess whether independent assessments cover AI-specific controls such as MLOps pipelines, application of the shared responsibility model, and customer-side configurations of AI services.

2. Examine documented policies and procedures that define how independent assessments of AI operations are scheduled and conducted, ensuring alignment with applicable standards and regulatory requirements.

3. Verify that the organization maintains and periodically reviews a comprehensive list of applicable standards and regulations, confirming that these guide the scope of audits/assessments covering infrastructure security, data protection, and responsible AI use.

4. Confirm that assessments are conducted independently, with governance oversight (e.g., by a Board committee or equivalent governance body) to ensure that those managing AI systems do not influence or control the assessment process.

5. Ensure that an independent assessment is conducted at least annually and that documented evidence demonstrates that AI operations, including third-party services and internal practices, are included in the scope at regular intervals.

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.

Auditing Guidelines for AI Customers (AIC)

1. Review the AIC’s documented AI governance policies and confirm that they include risk-based audit planning for how AI services are used.

2. Examine audit schedules and verify they reflect the risk level of AI use cases (e.g., mission-critical, experimental). Confirm that risk-based planning includes due diligence and risk assessment of upstream providers (e.g., model providers, application providers).

3. Review internal assessments for residual risks, such as limitations or potential misuse of the AI service by the AIC, or risks not fully mitigated by providers.

4. Ensure that third-party risk management processes feed into the scope and priorities of the AIC’s risk-based audit planning.

5. Interview relevant teams to assess how the AIC maintains assurance over time, particularly in response to upstream provider changes, model updates, or retraining.

A&A-04: Requirements Compliance

Control Specification

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

Auditing Guidelines for AI Customers (AIC)

1. Determine what laws apply to their sectoral use of AI (e.g., HIPAA, FINRA, SEC rules).

2. Review Procurement Contracts: Do contracts with AI vendors include legal compliance clauses? Are liability terms clear?

3. Verify Compliance Mechanisms: Confirm internal reviews and data protection impact assessments were performed.

4. Examine Internal Policies: Review how customers ensure responsible AI use (e.g., acceptable use policies, downstream impact reviews).

5. Ensure there is a process for reporting and remediating legal noncompliance or violations.

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.

Auditing Guidelines for AI Customers (AIC)

1. Evaluate Audit Planning: Are audits conducted periodically based on AI service criticality? Ensure the audit management process aligns with relevant auditing standards and includes internal usage reviews, provider due diligence, and procurement alignment with risk.

2. Inspect Vendor Assurance Practices: How are third-party providers audited or assessed by the customer? Monitor controls around configuration, user training, ethical use, and incident logging.

3. Check Evidence of Training and Policy Compliance: Are internal policies reviewed and enforced through audits?

4. Review Post-Audit Activities: Ensure that internal findings result in clear remediation plans and timelines.

5. Verify Feedback Loop: Check if past reports influence future audits or change requests to the provider.

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.

Auditing Guidelines for AI Customers (AIC)

1. Audit Vendor Remediation Follow-up: Are vendors required to demonstrate issue resolution with supporting evidence? Establish there is a formal policy or playbook for corrective action.

2. Check Internal Caps for AI Use: Are there internal controls for adjusting use policies, retraining users, or updating ethical guidance?

3. Assess Stakeholder Communication: Are legal, compliance, and technical stakeholders included in remediation planning?

4. Review Risk Acceptance Records: When remediation is deferred, is a formal risk acceptance process in place?

5. Inspect Feedback Loops: Are AI service adjustments and user retraining incorporated based on past findings?

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.

Auditing Guidelines for AI Customers (AIC)

1. Verify Adopted Provider Policies: Are provider security policies reviewed and integrated into internal governance?

2. Check Usage Guidance: Is there internal documentation guiding safe API usage, credential storage, and client configuration?

3. Examine Audit Trails: Are logs of usage and access to provider APIs collected, centralized, and reviewed?

4. Annual Policy Review: Inspect customer-side review of application access policies, especially after platform expansions or role changes.

5. Review Security Incidents: Review records of any API abuse, credential leakage, or interface-based attacks and how policies were updated in response.

6. Assess Provider-Customer Policy Alignment: For SaaS AI platforms, ensure customer policies integrate provider guidelines and shared responsibility models.

AIS-02: Application Security Baseline Requirements

Control Specification

Establish, document and maintain baseline requirements for securing applications.

Auditing Guidelines for AI Customers (AIC)

1. Verify that AI applications are classified based on risk factors, including purpose, data sensitivity, business impact, and security risk, and ensure alignment with the provider’s recommended security baseline.

2. Assess whether the customer’s AI security baseline aligns with the provider’s recommended secure configuration and that all customer-level security responsibilities (e.g., user permissions, data governance) are documented and enforced.

3. Determine whether IAM policies enforce least-privilege principles, prevent unauthorized access, and include mechanisms for periodic access reviews.

4. Examine configuration and change management procedures to confirm that AI-related updates are tracked and evaluated for security impact, ensuring continued compliance with baseline requirements.

5. Confirm that AI applications behave as intended under secure conditions, and that interfaces enforce expected security behaviors (e.g., input validation, secure error messages, predictable access controls).

6. Verify that periodic reviews of application security baselines are conducted, deviations are logged, and corrective actions are documented.

7. Determine whether third-party AI models and external data sources are assessed for security compliance and whether equivalent baseline security requirements are enforced before integration.

8. Review and analyze compliance documentation to ensure AI security practices adhere to regulatory and industry standards (e.g., GDPR, CCPA, NIST AI RMF, EU AI Act), and verify that periodic regulatory assessments are conducted.

AIS-03: Application Security Metrics

Control Specification

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

Auditing Guidelines for AI Customers (AIC)

1. Verify metrics are defined for AI service usage (e.g., LLM API call volume, latency, error codes).

2. Check whether metrics relate to third-party risk (e.g., vendor SLA breaches, delayed patching, non-compliant behavior).

3. Review metrics around user interaction with AI tools, especially those embedded in business workflows.

4. Confirm that metrics inform risk acceptance, access provisioning, or vendor evaluation 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.

Auditing Guidelines for AI Customers (AIC)

1. Interview product/security leads to determine whether they develop AI-integrated apps or just consume APIs. Which AI services or SDKs do they use (e.g., LLMs, chatbots, AI plugins)? Who manages configuration, prompting, and deployment?

2. Review SDLC Documentation: Ask for any SDLC policy or process that governs how AI services or integrations are built and maintained. Check that the SDLC covers design, integration, testing, and deployment stages, defines roles and responsibilities, and that it has been approved by management.

3. Assess Risk-Specific Practices: Look for guidance in the SDLC related to API integrations, prompt management, and secrets. Are AI SDKs/API calls validated before use? Are prompts sanitized, version-controlled, and tested? Are API keys or tokens stored securely and access-controlled?

4. Check Security Testing Activities: Confirm if AIC performs prompt injection or misuse testing, performs basic penetration tests or misuse simulations, and keeps evidence of activities like test reports, validation checklists, or scripts.

5. Review Deployment and Runtime Controls: Verify that the deployment of AI-related code follows secure practices including the use of CI/CD pipelines, secrets management (e.g., environment variables, vaults), and access control for deploying or changing configurations.

6. Inspect Real-World Examples: Request samples such as prompt templates, AI configuration scripts, Git logs, code snippets showing secure coding or review comments, and change management tickets related to AI services.

7. Evaluate Vendor and Third-Party Risk Controls: Check how the AIC handles risk from vendors. Do contracts require secure SDLC practices from providers? Is there a process for reviewing changes from vendors (e.g., model version updates)? Are fallbacks or rollback procedures in place?

8. Confirm Oversight and Continuous Improvement: Ask about governance. Are there regular reviews of the AI integration SDLC? Are there logs of incidents, deviations, or lessons learned? Are regulatory obligations (e.g., GDPR, AI Act) considered?

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.

Auditing Guidelines for AI Customers (AIC)

1. Verify that security validation of AI-integrated applications and third-party AI/ML components and APIs are in place.

2. Verify that periodic and risk-based tests are being done regularly, and that they include AI/ML-specific use and abuse cases, as well as adversarial scenarios.

3. Verify that the detected issues are remediated and result in necessary updates. For example, updates in the provider’s infrastructure and security/protection mechanisms.

4. Verify that the security testing of the provider evolves with AI/ML system and infrastructure changes, and that those changes align with applicable compliance requirements.

AIS-06: Secure Application Deployment

Control Specification

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

Auditing Guidelines for AI Customers (AIC)

1. Review AI Integration Deployment Governance: Request deployment policies that cover SaaS/third-party API use, LLM integration, and cloud-based inference. Check if there’s a central review board or AI oversight group involved in AI-use approvals and examine whether deployment of AI-powered features (e.g., fraud alerts, LLM workflows) is gated through formal change/release processes.

2. Assess Internal SDLC or CI/CD Integration for AI-Enabled Systems: Inspect whether the organization’s CI/CD pipelines or infrastructure automation tools include secure configurations (e.g., feature flag management for AI functionality, prompt configuration, token storage). Evaluate whether deployment steps check the following: API tokens are encrypted, AI service URLs are whitelisted, and model versioning or behavior is documented.

3. Evaluate Controls for AI Configuration and Secrets Handling: Review how AI configurations (e.g., prompts, API credentials, fine-tuning parameters) are stored, versioned, and rotated. Confirm that deployment automation tools use secrets managers (e.g., AWS Secrets Manager, Azure Key Vault) rather than hardcoding tokens or prompts.

4. Verify Deployment Oversight for Shadow AI and Non-Production Use: Inspect whether there’s a process to detect and control shadow deployments of AI services (e.g., unapproved SaaS AI tools), and confirm that the deployment policy applies to internal bots, no-code integrations, or plug-ins using generative AI.

5. Check Evidence of Secure Change Management for AI-Enhanced Features: Review change tickets related to AI feature rollouts and confirm they include the following: security review, business owner sign-off, monitoring setup (e.g., anomalous LLM responses). Ask for rollback plans or sandbox testing records for AI functionality.

6. Assess Automation and Standardization Maturity: Verify use of automated configuration tools (e.g., Ansible, Terraform, CI/CD pipelines) for deploying AI-enriched apps, and confirm that deployment environments are templated, version-controlled, and subject to compliance scans.

AIS-07: Application Vulnerability Remediation

Control Specification

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

Auditing Guidelines for AI Customers (AIC)

1. Assess Oversight of AI-Integrated Applications: Confirm that AI-enabled apps (chatbots, LLM APIs) undergo security reviews.

2. Verify Patch Management for Internal Deployments: AICs often deploy AI apps on-premises or in their own cloud. Inspect ticketing systems or endpoint management tools for patch cycles.

3. Check Vendor Risk Management and Remediation Tracking: Request records of vendor advisories and internal response measures.

4. Inspect Guardrails for Third-Party Plugins or LLM Tools: Vulnerable third-party extensions can bypass controls. Verify that plugins or AI tools require internal security vetting before deployment.

5. Review Automated Alerts for AI Tool Vulnerabilities: AICs should be notified of vulnerabilities in AI services they rely on. Check if security platforms (e.g., SIEM) ingest threat intelligence related to AI tooling.

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.

Auditing Guidelines for AI Customers (AIC)

1. Verify that measures and processes exist to secure APIs, and ensure that they address mechanisms to adhere to best practice for key management and authorization and assessment of risks related to API supply chain (e.g., software composition analysis, vulnerability reports).

2. Verify that the processes and measures are reviewed at least annually and after significant system change.

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.

Auditing Guidelines for AI Customers (AIC)

1. Verify that the AIC has explicit policies and controls implemented to address and validate adversarial AI inputs specific to their use-case scenarios. Ensure documentation includes a clear scope, roles, and defined threat mitigation actions.

2. Evaluate the practical implementation of input validation mechanisms by AIC, which need to be tailored to their AI application’s exposure and common threat scenarios, including linguistic, coding, token-based, and multimodal attacks.

3. Ensure that the AIC regularly conducts AI Red Teaming exercised with are focused on validating input validation controls against current and emerging adversarial input scenarios specific to their AI applications and business context.

4. Verify that the findings documented in the Red Teaming reports are translated by the AIC into continuous improvements of their AI-specific input validation controls.

5. Confirm that the AIC monitors input validation effectiveness through clearly defined metrics relevant to adversarial AI input risks. Those metrics need to be checked and updated regularly.

6. Ensure that AI input validation controls are periodically reviewed and timely updated to address threat evolution and the AI-specific Red Team feedback.

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.

Auditing Guidelines for AI Customers (AIC)

1. Confirm that the AIC maintains specific policies and controls tailored to validate AI-generated outputs against insecure or adversarial behaviors relevant to their specific use-cases. Ensure that scope, roles, and remediation actions are clearly documented.

2. Ensure that the AIC has implemented output validation mechanisms that are aligned with their AI application risks and that they cover both insecure output handling and excessive agency scenarios.

3. Ensure that the AIC regularly conducts AI Red Teaming exercises that evaluate and aim to improve the output validation effectiveness against insecure outputs, excessive agency threats, and adversarial output scenarios specific to their business context.

4. Ensure that the AIC translates the findings of these AI Red Team exercises into ongoing improvements of AI-specific output validation controls for addressing identified insecure or adversarial outputs risks.

5. Confirm that the AIC actively monitors the output validation effectiveness through regularly updated metrics that are designed to detect risks from insecure or adversarial AI outputs.

6. Ensure that AI output controls are regularly reviewed and updated when needed to ensure protection against new AI security threats and address the findings of the AI Red Teaming exercises.

AIS-11: Agents Security Boundaries

Control Specification

Establish security boundaries for agents.

Auditing Guidelines for AI Customers (AIC)

1. Policy on Agent Use: Verify that the AIC’s acceptable use policy formally addresses the use of agent‑based AI solutions and that the policy is communicated to all relevant personnel.

2. Confirm that employees receive training to understand the capabilities, limitations, and potential risks of AI agents prior to their use.

3. Review the AIC’s documented process for approving specific agent‑enabled tools or features, ensuring that approvals are based on documented risk assessments.

4. Check that the AIC monitors internal use of agent‑enabled tools to detect policy violations, inappropriate actions, or unexpected behaviors.

5. Evaluate whether the AIC’s vendor management process requires providers to supply clear documentation of agentic features and the controls they implement.

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.

Auditing Guidelines for AI Customers (AIC)

1. Provider Assurance Validation: Verify that procedures are in place for the AIC to request and review assurance documentation from Model Providers (MPs), Orchestrated Service Providers (OSPs), and Application Providers (APs) regarding their development practices. Ensure these procedures are documented and consistently applied.

2. Documentation Review: Examine received assurance evidence from providers, confirming that it covers version control, code reviews, and static analysis practices for externally sourced models or applications. Verify that the AIC maintains clear documentation of which model versions are deployed in production environments.

3. Risk Assessment: Confirm that the AIC performs impact assessments and maintains documentation of the process. Evaluate the effectiveness of the AIC’s risk assessment process for evaluating the rigor of external model development. Verify that the AIC maintains an internal risk register or decision matrix to assess and record risks associated with each external model or application.

4. Integration Controls: Check that the AIC integrates only models and applications that have been vetted and that assurance artifacts (e.g., review reports, approvals) are logged prior to deployment or use.

5. Evidence Review: Confirm the existence of model onboarding review logs, supplier assurance records, and security and risk memos or documented approvals prior to integration into production.

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.

Auditing Guidelines for AI Customers (AIC)

Focus: The AI Application Provider has implemented effective sandboxing techniques to execute AI tools and plugins in isolated environments, preventing unintended interactions with critical systems or data and limiting the possibility of lateral movement.

1. Inquiry with Control Owners

   1. Interview security architects, DevOps leads, and application engineers responsible for implementing sandboxing for AI applications. Obtain and review the organization’s sandboxing policies and implementation standards, including sandboxing architecture documentation for AI tools and plugins, isolation policies for sandboxed environments, permission models and privilege restrictions, plugin/extension verification and approval processes, third-party integration security requirements, and data isolation and access control policies. Verify the existence of documented security requirements for user-provided input handling within sandboxes, generated content validation before release from sandbox, plugin access to host application resources, third-party integration authentication and authorization, and data flow restrictions between sandboxed and trusted environments.

   2. Review Sandboxing Technical Implementation: Examine documentation describing containerization or virtualization technologies used for isolation, resource limitation mechanisms (CPU, memory, network, storage), time constraints and execution timeout, network access restrictions and egress controls, API access limitations from sandboxed environments, file system isolation and access controls, inter-process communication restrictions, and monitoring and logging implementation for sandbox activities.

   3. Assess Sandbox Escape Prevention: Review mechanisms preventing sandbox escape, including input validation and sanitization at sandbox boundaries, output validation before release from sandbox, permission elevation prevention controls, memory isolation enforcement, just-in-time compilation restrictions, browser security model implementation (for web-based AI applications), system call filtering and restriction, and container security hardening measures.

   4. Evaluate Plugin/Extension Management: Review procedures for plugin/extension security, including plugin approval and verification process, static and dynamic security analysis of plugins, code signing requirements for approved plugins, version control and update validation, plugin permissions model and least privilege enforcement, plugin API access control mechanisms, and behavioral monitoring of plugins in production.

2. Obtaining and Verifying the Population of Records

   1. Define the Complete Population of AI Tools and Plugins: Obtain a comprehensive inventory of AI tools and plugins available in the application, third-party integrations with access to AI features, custom plugin frameworks or extension systems, API endpoints exposed to plugins or extensions, features allowing user-provided code execution, AI agents with system access capabilities, code generation or execution features, content generation capabilities with external system interaction, and data processing capabilities operating on user or system data.

   2. Verify Population Completeness: Cross-reference the inventory against application feature documentation, plugin/extension marketplaces or directories, API documentation and developer resources, user permission models referencing plugins, integration partnership agreements, plugin developer registration records, security assessment reports, architecture diagrams showing integration points, and data flow diagrams indicating trust boundaries.

   3. Categorize AI Tools and Plugins by Risk Level: Segment the population based on access to sensitive user data, system privilege requirements, network connectivity needs, external API dependencies, user customization capabilities, content generation scope, scale of deployment and usage, and potential impact of compromise.

3. Inspection of Evidence

   1. Sandbox Implementation Review: Select a representative sample of AI tools and plugins based on risk levels for each sampled component. Verify the implementation of: isolation mechanisms (containerization implementation (e.g., Docker, containerd), virtual machine isolation where appropriate, serverless function isolation techniques, process isolation and namespace separation, memory isolation enforcement, browser sandbox implementation for web applications); resource limitations (CPU usage constraints, memory allocation limits, network bandwidth restrictions, storage capacity controls, execution time limits, API rate limiting); and access controls (network access restrictions, file system access limitations, API access controls based on least privilege, data access limitations and tokenization, environment variable restrictions, secrets access prevention).

   2. Security Boundary Testing: Review evidence of security testing, including penetration testing reports for sandbox boundaries, fuzzing test results for sandbox interfaces, static code analysis of sandbox implementation, dynamic testing of isolation effectiveness, privilege escalation attempt documentation, lateral movement testing results, API boundary security assessments, and plugin security assessment documentation.

   3. Sandbox Monitoring and Alerting: Verify implementation of activity logging within sandboxed environments, resource usage monitoring and anomaly detection, behavioral analysis of plugin activities, alerting on potential sandbox escape attempts, integration with security monitoring systems, audit logging of privilege use within sandboxes, and automated response to suspicious activities.

   4. Data Protection within Sandboxes: Assess controls for data protection such as data minimization practices (providing only necessary data), data tokenization or anonymization before sandbox access, prevention of unauthorized data exfiltration, temporary data removal after processing, sensitive data detection and special handling, data flow controls between security domains, and encryption of data at rest and in transit.

   5. Plugin Verification and Management: Examine the implementation of plugin code review and approval processes, automated security scanning for plugins, runtime verification of plugin integrity plugin digital signature verification, secure update mechanisms for plugins, plugin permission management interfaces and revocation capabilities for compromised plugins.

   6. Security Incident Response: Review documentation and evidence of sandbox-specific incident response procedures, sandbox escape scenario playbooks, previous incident investigations involving sandboxes, sandbox compromise containment procedures, plugin deactivation and quarantine capabilities and emergency response testing for sandbox failures.

   7. Documentation and Developer Guidance: Verify the existence and adequacy of developer documentation for sandbox security requirements, plugin development security guidelines, API security documentation, secure integration patterns documentation, security testing requirements for plugin developers, and security review checklist for new integrations.

4. Evaluation and Reporting

   1. Sandbox Effectiveness Assessment: Evaluate how well sandbox implementations prevent unauthorized access to system resources, isolate potentially dangerous operations, restrict plugin and tool capabilities appropriately, maintain performance with security controls, adapt to emerging threats, and balance security with usability.

   2. Isolation Strategy Assessment: Assess the effectiveness of isolation strategies, appropriateness of isolation technique for risk level, defense-in-depth implementation, consistency across different AI features, coverage of all integration points, alignment with industry best practices, and evolution based on threat intelligence.

   3. Documentation and Process Adequacy: Evaluate the quality of sandbox-related documentation, clarity of security requirements for developers, completeness of implementation guidelines, definition of security boundaries, regular updates to reflect new threats, and integration with overall security architecture.

   4. Continuous Improvement Mechanisms: Evaluate processes for improving sandbox security, regular security testing and assessment, incorporation of lessons learned from incidents, adaptation to new plugin requirements, enhancement based on threat intelligence, security architecture review frequency, and integration of emerging sandbox technologies.

AIS-14: AI Cache Protection

Control Specification

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

Auditing Guidelines for AI Customers (AIC)

Focus: Securely managing caching within their end-user applications, considering both performance and the sensitivity of cached data related to user interactions.

1. Inquiry with Control Owners: Inquire about caching mechanisms used within the GenAI application (e.g., caching of generated content, user preferences, API responses), understand the security measures implemented for these caches (e.g., access controls, encryption, invalidation, avoiding retention of sensitive information), discuss how user-specific data in the cache is protected, inquire about monitoring and logging of cache activity within the application, understand incident response procedures for cache-related security issues in the application, and inquire about cache clearing procedures, especially related to user data and model updates.

2. Obtaining and Verifying the Population of Records: Define documentation on the application’s caching mechanisms, security features, and data handling policies, and verify the completeness and accuracy of these records.

3. Inspection of Evidence

   1. Documentation Review: Verify documentation of the application’s caching mechanisms and security policies.

   2. Access Control Verification: Confirm access controls to application caches, ensuring user data is protected.

   3. Credential Protection: Verify the handling of any credentials potentially stored in application caches.

   4. Cache Poisoning and Side-Channel Attacks (Application Level): Review application-level defenses against these attacks.

   5. Protection Implementation: Inspect configurations for encryption and invalidation within the application’s caching. Verify measures to avoid retaining sensitive information.

   6. Incident Response: Evaluate incident response procedures for cache-related security issues in the application.

   7. Monitoring: Ensure monitoring of cache activity within the application.

   8. Periodic Review: Verify periodic reviews of the application’s cache security measures.

   9. Cache Clearing Procedures: Verify procedures for cache clearing within the application, especially for user data and model updates.

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

Auditing Guidelines for AI Customers (AIC)

Focus: The focus for AI Customer (AIC) is on the inherent capabilities of AIC to build their own GenAI or Predictive AI models and solutions, as well as the guidance they provide to their downstream users.

1. Inquiry with Control Owners: Inquire with individuals or teams responsible for the design, implementation, and maintenance of the AI system’s prompt handling mechanisms and security controls. Obtain documentation outlining the prompt differentiation strategy and implementation details. Understand how user input is received, processed, and integrated with system prompts. Discuss any training or guidelines provided to developers and users regarding secure prompting practices.

2. Obtaining and Verifying the Population of Records: Clearly define what constitutes the “population of records.” This could include: a log of all prompts processed by the AI system within a specific timeframe, a repository of defined system prompts, and internal test cases designed to evaluate prompt differentiation. Perform procedures to verify the completeness and accuracy of the obtained population.

3. Control Requirements: For a representative sample, verify compliance with the following:

   1. Test for Explicit Labeling (Instruction Keys/Tags): Examine prompts for the consistent use of distinct, structured tokens or formats to label user input and system instructions. Verify that the labeling is applied correctly across different types of prompts and interfaces.

   2. Test for Input Encoding/Escaping: Examine how user input is processed and integrated into prompts. Verify that user input is properly escaped or encoded to prevent it from being interpreted as control characters or instructions. Constructing prompts server-side allows for sanitization and filtering of user inputs before they are combined into the final prompt.

   3. Test for Contextual Separation (API): Examine the API request and response structures. Review API documentation and implementation details to confirm this separation.

   4. Test for Delimiter Usage: Examine prompts for the consistent and effective use of special characters or strings to clearly separate different parts of the prompt (e.g., system instructions, user input, data).

   5. Test for Model’s Resistance to Instruction Overriding (if applicable): Analyze the model’s responses to test prompts designed to override system instructions within the user input. Verify if the model correctly rejects or ignores the overriding attempts, as per the documented or implemented fine-tuning/instruction strategy.

   6. Review Visual/UI Differentiation (if applicable): Verify if there are clear visual distinctions between areas for user input and any displayed system guidance or context.

   7. Review Formal Grammar Parsing (if applicable): Verify if the system enforces the grammar and how it handles prompts that do not conform.

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.

Auditing Guidelines for AI Customers (AIC)

1. Confirm existence of BCPs for: business disruption caused by upstream AI provider outages, manual or fallback procedures (e.g., re-routing, disabling features, user notification).

2. Check contracts/SLA terms that address provider-side continuity guarantees and internal communication protocols for AI system failure scenarios.

3. Review the last time the BCP was tested (e.g., simulated AI service interruption) and whether lessons learned from previous provider disruptions have been incorporated.

4. Verify that all policies and procedures are formally reviewed at least annually or upon significant changes, with updates documented through version history and approvals, and communicated to relevant stakeholders.

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.

Auditing Guidelines for AI Customers (AIC)

1. Evaluate Consumption Risk Analysis Confirm assessments cover: AI API downtime, Model accuracy degradation, Delayed updates or policy changes by providers.

2. Check Vendor Dependency Mapping: Ensure impact analyses include business impact from specific vendors or models.

3. Review Resilience Measures: Assess whether alternative providers, cached responses, or non-AI fallbacks are included in the resilience plan.

4. Key Evidence: Vendor risk assessments, business continuity fallback documents, supplier RTO impact summaries.

BCR-03: Business Continuity Strategy

Control Specification

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

Auditing Guidelines for AI Customers (AIC)

1. Verify that business continuity planning addresses availability of AI services that support mission-critical operations.

2. Confirm contractual SLAs with APs/OSPs include provisions for continuity and incident communication.

3. Ensure contingency procedures are in place for AI output dependency (e.g., decision-support tools).

4. Check customer-owned data integrations have fallback modes to prevent service lock-in.

5. Validate that AIC reviews third-party AI continuity strategies annually to assess business impact.

6. Ensure participation in business continuity tabletop exercises when AI is part of the supply chain.

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.

Auditing Guidelines for AI Customers (AIC)

1. Confirm the AIC maintains a BCP that addresses AI service disruption impacts on dependent business functions.

2. Verify procedures are documented for failover to alternate AI models or human-in-the-loop processes.

3. Check for business process continuity documentation for mission-critical services relying on AI output.

4. Ensure plans are in place to manage downstream impact from AI application or orchestration layer disruptions.

5. Validate periodic tabletop exercises or assessments of AI-related business continuity scenarios.

6. Confirm inclusion of AI provider contact points and SLAs in the AIC’s escalation matrix and BCP updates.

7. Ensure the BCP is updated after onboarding or decommissioning major AI capabilities.

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.

Auditing Guidelines for AI Customers (AIC)

1. Confirm the AIC maintains business continuity and operational resilience plan & documentation outlining dependencies on external AI services and critical models.

2. Verify documentation includes fallback procedures or manual overrides for AI-dependent decision systems.

3. Check that SLA documents, escalation matrices, and AI provider contacts are included and maintained.

4. Ensure documentation references BCP inputs from all AI suppliers and orchestrated pipelines the AIC depends on.

5. Validate documentation covering business impact analyses for AI service disruptions.

6. Confirm that continuity documentation is reviewed at least annually or after onboarding new AI services.

7. Check for internal guides on how to continue essential business operations during extended AI service outages.

BCR-06: Business Continuity Exercises

Control Specification

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

Auditing Guidelines for AI Customers (AIC)

1. Examine the plans for business continuity and operational resilience tests with reference to their intended outputs.

2. Examine the schedules of such tests and their periodicity.

3. Evaluate if the plans are tested upon significant changes or at least annually.

4. Verify that exercise scenarios include AI service unavailability, degraded performance, and procedures for maintaining critical business functions during AI service disruptions.

5. Review exercise results to confirm testing of alternative procedures, manual workarounds, or fallback systems that can maintain business operations when AI services are unavailable.

6. Assess whether exercises included verification of staff readiness through role-playing or simulation activities to confirm knowledge of continuity procedures.

7. Verify that communication plans and escalation procedures with AI service providers were tested during exercises.

8. Examine evidence that exercises validated the integrity and availability of locally cached data, downloaded models, or other resources needed during service disruptions.

9. Confirm that business leadership reviewed exercise results and identified gaps in continuity capabilities that were addressed through documented improvement plans.

BCR-07: Communication

Control Specification

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

Auditing Guidelines for AI Customers (AIC)

1. Examine the business continuity and operational resilience plans for determining stakeholders.

2. Determine if the organization has identified stakeholders.

3. Examine the procedures for communication with identified stakeholders.

4. Verify that a communications plan exists. The plan should include up-to-date contacts, clear roles and responsibilities, a period for updates, and escalation procedures.

5. Verify establishing communication channels with AI service providers, confirming they enable the AIC to receive timely status updates and provide necessary information during disruptions.

6. Review evidence that the AIC has identified and documented which business processes and units depend on specific AI services to ensure targeted communications during disruptions.

7. Assess the AIC’s procedures for escalating critical communication needs with service providers when standard channels are insufficient.

8. Verify that internal stakeholders know communication procedures during AI service disruptions and understand their roles in information dissemination.

9. Review records from past service disruptions or exercises to confirm effective internal communication about AI service status and the activation of alternative procedures when needed.

10. Confirm that the AIC maintains current contact information for key personnel at service providers and regularly validates these communication pathways.

BCR-08: Backup

Control Specification

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

Auditing Guidelines for AI Customers (AIC)

1. Examine the data classification policy for identifying data that requires a backup.

2. Examine the requirements for the security of such backups.

3. Evaluate the effectiveness of the backup and restore.

4. Determine if backup and restore procedures are tested periodically.

5. Examine if the backup and restore procedures accomplish the organization’s SLAs.

6. Evaluate the testing backup restorations, ensuring recovery time objectives (RTO) and recovery point objectives (RPO) are met.

7. Verify implementation of backup systems for business-critical AI configurations, custom integrations, and AI-generated insights used in decision-making processes.

8. Assess backup strategies for maintaining consistency between AI systems and internal business systems, particularly for workflows with bidirectional data flows.

9. Review procedures for classifying and protecting sensitive business data in backups according to data governance requirements and regulatory obligations.

10. Examine documentation and test results demonstrating successful restoration of business data and AI configurations, including verification that business processes function properly after recovery.

11. Verify that backup and recovery procedures are incorporated into business continuity plans addressing AI service disruptions.

12. Assess backup retention policies to confirm alignment with business needs, compliance requirements, and contractual obligations related to AI-processed data.

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.

Auditing Guidelines for AI Customers (AIC)

1. Examine the disaster recovery plan and procedures for adequacy, approval, communication, and effectiveness as applicable to a disaster response plan.

2. Examine the disaster recovery plan and procedures for evidence of review upon significant changes or at least annually.

3. Determine if the disaster recovery plan has periodic updates and ensure that all personnel are regularly trained on it.

4. Verify that the plan has received formal approval from business leadership responsible for operations dependent on AI services, with evidence of review and sign-off.

5. Assess the identification of critical business functions dependent on AI services and define alternative procedures for maintaining operations during service disruptions.

6. Review documentation of data backup and recovery procedures for business information processed through AI systems.

7. Verify that the plan includes escalation and communication procedures with AI service providers during service availability disasters.

8. Examine evidence that the disaster response plan has been communicated to all relevant business units and personnel dependent on AI services, including training records.

9. Review records of business continuity tests conducted within the past 12 months, confirming they validated the effectiveness of alternative procedures during AI service disruptions.

10. Verify that the plan is reviewed and updated at least annually and after significant changes to business processes or AI service usage, with documented change history.

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.

Auditing Guidelines for AI Customers (AIC)

1. Determine if the organization has identified local emergency authorities contacts and, if possible, has included them in the disaster recovery plan exercise.

2. Examine the organization’s policies for planning and scheduling disaster response exercises and, if possible, involving local emergency authorities.

3. Evaluate if plans are tested upon significant changes or at least annually.

4. Determine if the organization has a feedback mechanism post-exercise to ensure lessons learned are incorporated into future exercises.

5. Verify that exercises tested alternative procedures for critical business functions that depend on AI services.

6. Review exercise documentation to confirm that business impact metrics were measured and evaluated to assess the effectiveness of continuity procedures.

7. Assess whether exercises tested communication procedures with AI service providers during simulated disruptions, including escalation processes.

8. Verify that exercises included scenarios for accessing and utilizing backed-up business data when primary AI systems are unavailable.

9. Confirm that relevant business units and personnel participated in exercises, demonstrating knowledge of their roles during AI service disruptions.

10. Review documentation of lessons learned from exercises and verify that identified weaknesses in business continuity capabilities resulted in documented improvement plans with clear ownership and timelines.

11. Verify that additional exercises were conducted following significant changes to business processes or how AI services are utilized within the organization.

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.

Auditing Guidelines for AI Customers (AIC)

1. Determine if the organization has documentation about the AI provider’s equipment redundancy and the impact of this documentation on the risk assessment of third-party providers.

2. Verify that contracts and service level agreements with AI providers include commitments to equipment redundancy meeting industry standards appropriate to the criticality of the services.

3. Review implementation of local caching or offline processing capabilities that maintain limited functionality when remote AI services are unavailable due to equipment failures.

4. Assess business continuity plans to confirm they address scenarios where primary equipment supporting AI services fails and identify alternative procedures.

5. Verify testing of business processes using alternative access methods or redundant service endpoints provided by AI service providers.

6. Examine the redundancy of endpoint devices or systems that integrate with AI services, where applicable to critical business operations.

7. Review procedures for validating service provider redundancy claims, such as requesting documentation of redundancy architectures or third-party certifications.

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.

Auditing Guidelines for AI Customers (AIC)

1. Conduct interviews with personnel responsible for documenting, maintaining, and communicating organizational change management policies, procedures, and standards (the Policies).

2. Inspecting Records and Documents: Obtain and review the change management Policies to ensure they are adequate for the organization to manage risks associated with applying changes to organizational assets. Verify that the Policies define the personnel or roles responsible for their dissemination, identify an official accountable for managing the Policies, specify the frequency of reviews and updates (annually), and outline events that necessitate policy updates.

3. Verify that the Policies are disseminated, are reviewed and updated at least annually or upon significant changes, are approved, and are communicated to relevant stakeholders.

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.

Auditing Guidelines for AI Customers (AIC)

Applicable only if AI customer has ability to perform some changes to the AI application components configurations, orchestration configurations, or model adjustments such as fine-tuning, RAG solutions, etc.

1. Inquiring with Control Owners Conduct interviews with the control owner(s) and/or review supporting process documentation to understand the change management process, including steps for recording changes, baselining configurations, approvals, testing, and releases.

2. Obtaining and Verifying the Population of Records: Collect the population of change records from relevant systems, and confirm the accuracy and completeness of the population by identifying and resolving any missing or inconsistent data.

3. Inspecting Records and Documents: Select a representative sample or perform full-population testing using automated tools when possible, and verify that the selected changes were properly recorded, tested, approved, and released in accordance with established baselines, testing, and release standards. Consider evaluation of appropriateness of change request documentation, appropriate approval workflows, adequate testing requirements, implementation planning, and post-implementation verification.

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.

Auditing Guidelines for AI Customers (AIC)

1. Inquiring with Control Owners: Interview the AIC’s change management process owners and review supporting documentation to understand how changes are managed across: applications, infrastructure, orchestration layers, and AI/ML artifacts across Internally operated and third-party managed systems. Focus on the presence and quality of documented processes for submitting change requests, conducting risk assessments, obtaining approvals, performing testing, planning implementations, and conducting post-deployment verifications. Clarify the AIC’s use of supporting systems and tools such as change management platforms (e.g., ServiceNow, Jira Service Management), configuration management databases (CMDBs), version control systems (e.g., GitHub, GitLab, Azure DevOps), automated testing, and CI/CD tools for validating system and model changes.

2. Inspecting Records and Verifying Implementation: Select a representative sample of change events drawn from systems like change tracking platforms, version control repositories, CI/CD pipeline execution logs, and AI/ML model registries (if applicable). For each sampled change, verify the presence of proper documentation, approvals, risk analysis, and testing evidence. Confirm that required controls were applied across environments managed by the AIC or external providers. Assess whether configuration management and testing tools were properly used to enforce governance policies.

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.

Auditing Guidelines for AI Customers (AIC)

1. Inquiring with Control Owners

   1. Interview people responsible for promoting changes to various environments to understand how access restrictions are implemented for adding, removing, updating, and managing changes to applications, models, infrastructure, systems, or system components (the Assets). Review access control matrices and change management policies to confirm formal documentation of authorization requirements across all asset categories.

2. Obtaining and Verifying the Population of Records

   1. Obtain the complete population of Assets under review and validate completeness of the population by reviewing scripts used to generate the data, reconciling with system inventories, configuration management databases, and other independent records.

3. Inspecting Records and Documents

   1. Select a representative sample of the Assets and obtain a complete list of user accounts that have ability to make changes such as additions, removal, update, or management of the Assets in various environments. Validate completeness of the user access list by reviewing scripts used to generate the data.

   2. Verify that access to make changes to selected Assets is properly restricted by examining access control lists, reviewing privileged account management records, analyzing CI/CD pipeline deployment configurations, and testing that unauthorized personnel cannot make changes to the Assets.

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.

Auditing Guidelines for AI Customers (AIC)

1. Inquiring with Control Owners: Interview the contract management team to understand how change provisions are incorporated into SLAs between AICs and CSPs. Discuss with legal/compliance personnel how they ensure SLAs contain explicit language limiting changes to authorized requests. Inquire about the process for updating or modifying SLA change provisions.

2. Obtaining and Verifying the Population of Records: Obtain a complete list of all active SLAs between the CSPs and AICs during the audit period. Confirm completeness, for example, by cross-referencing the SLA list against customer records in the contract management system.

3. Inspecting Records and Documents: Select a representative sample of SLA documents based on defined risk factors. For each sampled SLA, verify it contains specific provisions limiting changes to explicitly authorized requests. Confirm each SLA clearly defines what constitutes an “authorized request” and the approval process. Verify SLAs specify the scope of changes that require explicit authorization.

4. Review SLA Review and Acceptance Process: Interview procurement and legal teams about change clause reviews.

5. Validate Tracking of SLA Changes or Amendments: AICs should monitor if CSPs alter terms unilaterally. Check if contract lifecycle tools include version history and alerts.

6. Inspect Incident Records Involving Unauthorized Changes: AICs should be able to identify SLA breaches. Sample incident logs or escalation tickets relating to unplanned service changes.

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.

Auditing Guidelines for AI Customers (AIC)

1. Verify documentation defines what constitutes a baseline for the AIC’s AI-enabled applications and AI usage configurations (as applicable), including: AI service/vendor/model version references, prompt templates/system instructions (if centrally managed), access/roles, integrations/data connectors, guardrails/content filtering settings, logging/monitoring settings, and deployment/environment configuration items under customer control. Identify what is “in baseline” vs “out of scope.”

2. Confirm a change process exists and is followed for all relevant authorized baseline changes (request - approval - version control/config management where used - testing/validation - production rollout), including segregation/authorization for high-impact changes (access, connectors, guardrails/policy settings).

3. Select a sample of recent and/or higher-risk baseline changes (e.g., new AI service enablement, connector added/changed, prompt template/system instruction update, access entitlement change, guardrail/logging setting change) and verify end-to-end traceability: approved change record, linked configuration/artifact change, evidence of validation/testing as applicable, and implementation consistent with the approved change.

4. Review controls protecting the integrity of baselined items (e.g., access controls, approval workflows, change tracking/audit logs) to prevent unauthorized modifications to customer-controlled AI configurations and artifacts.

5. Confirm baselines are reviewed/updated at least annually and upon significant changes, including vendor/service changes that impact the customer’s configuration or risk posture (e.g., material model/service updates, deprecations, default behavior changes, security advisories), with evidence of review and resulting updates where applicable.

CCC-07: Detection of Baseline Deviation

Control Specification

Implement detection measures with proactive notification in case of changes deviating from the established baseline.

Auditing Guidelines for AI Customers (AIC)

1. Inquiry with Control Owners

   1. Interview monitoring and operations personnel responsible for detecting changes to end-user AI applications. Obtain and review the organization’s monitoring strategies, alert thresholds, and notification workflows for: foundation model integration behavior changes, prompt template performance variations, content generation quality fluctuations, user interface interaction anomalies, customer experience degradation, and safety mechanism effectiveness. Verify the existence of documented detection mechanisms for: AI-generated content quality drift, prompt effectiveness degradation, user feedback patterns indicating issues, response accuracy or relevance shifts, safety filter bypass attempts, and performance changes affecting user experience. Identify monitoring tools used for: content quality evaluation and comparisons, user satisfaction and engagement tracking, A/B testing and feature flagging systems, end-user feedback collection and analysis, safety and moderation effectiveness monitoring, and user interaction pattern analysis.

   2. Review Notification and Response Procedures: Examine documentation describing notification pathways when user-facing issues are detected. Understand escalation procedures based on user impact severity. Verify integration between detection systems and customer support processes. Assess emergency response capabilities for high-visibility AI application failures. Review response playbooks for different types of AI application issues: content quality degradation, safety mechanism failures, hallucination rate increases, performance or latency problems, user accessibility impacts, and factual accuracy problems.

2. Obtaining and Verifying the Population of Records

   1. Define the complete population of monitoring records by inventorying monitoring systems for end-user AI applications, including content quality evaluation systems, user feedback collection mechanisms, prompt performance tracking tools, foundation model integration monitoring, safety filter and content moderation effectiveness trackers, user experience and satisfaction measurement systems, application performance and reliability monitoring, A/B testing and feature flag impact analysis, and automated content sampling and evaluation.

   2. Verify completeness of the population by cross-referencing monitoring coverage against the inventory of AI applications components, assessing completeness of alerting rules for enterprise customer impact scenarios, or verify that monitoring covers all deployment environments (dev, staging, production).

3. Inspection of Evidence

   1. Monitoring System Verification: Verify that monitoring systems are configured to detect deviations in the following categories. For Content Generation Quality: output relevance to user inputs, content coherence and consistency measures, factual accuracy or hallucination rates, stylistic consistency with application standards, adherence to brand voice and guidelines, and response diversity and creativity metrics. For User Experience Metrics: session abandonment rates during AI interactions, time-to-completion for AI-assisted tasks, repeat query patterns indicating confusion, user feedback sentiment and trends, feature usage patterns and engagement, and accessibility compliance for AI interactions. For Safety and Compliance: content policy violation detection rates, harmful or toxic output incidents, PII handling and privacy compliance, industry-specific compliance requirements, bias or fairness metrics for AI outputs, and safety filter effectiveness across diverse inputs. For Technical Performance: response time and latency for AI features, API call success rates to foundation models, error rates in content generation workflows, resource utilization affecting user experience, mobile vs. desktop performance disparities, and regional or geographic performance variations.

   2. Alert Configuration Assessment: Examine alert configuration to verify: user-impact based alert prioritization, differentiated thresholds for premium vs. standard tiers, business hours vs. off-hours notification routing, integration with customer support ticketing, clear issue reproduction steps in alerts, sample content or user interactions in alert context, and correlation with recent application changes or deployments.

   3. Sample-Based Testing of Detection Capabilities: Select a representative sample of AI application features and perform controlled tests: simulate degraded content quality responses, introduce edge case inputs challenging safety filters, create prompts known to trigger hallucinations, test across different devices and platforms, and simulate user confusion patterns. Verify that monitoring systems: accurately detect the simulated issues, generate appropriate alerts with correct user impact assessment, include relevant content samples for analysis, trigger within timeframes that limit user exposure, and follow defined notification workflows based on severity.

   4. Alert Notification Workflow Verification: Trace the notification path for different types of AI application issues: initial detection and enrichment with examples, routing to appropriate teams (product, engineering, trust and safety), escalation for high-visibility or widespread issues, communication templates for customer-facing updates, integration with status pages or customer notifications, collaboration workflows between teams for complex issues, and executive notification for significant brand impact issues.

   5. Response Effectiveness Evaluation: Review historical AI application incidents to evaluate: time to detect user-impacting issues, quality of supporting evidence for diagnosis, response time to acknowledge problems, effectiveness of mitigations (e.g., feature flags, rollbacks), customer communication quality and transparency, resolution time for different issue categories, and documentation of lessons learned.

   6. Automated Remediation Assessment: Verify implementation of automated remediation for common issues: automatic feature flag toggles for problematic AI features, graceful degradation to simpler AI capabilities, fallback to previous model versions or prompts, dynamic content filtering threshold adjustments, automatic routing to human review for edge cases, and progressive rollback of affected user cohorts.

   7. Integration with End-User Feedback: Assess how detection systems incorporate user feedback: integration of in-app feedback mechanisms, correlation of support tickets with detected issues, social media sentiment monitoring for product mentions, app store review analysis for AI-related complaints, automated categorization of user-reported issues, and feedback-triggered threshold adjustments.

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.

Auditing Guidelines for AI Customers (AIC)

1. Inquiry with Control Owners

   1. Understand Exception Management Practices: Interview AI application leadership, product managers, and engineering teams responsible for exception handling in custom AI-powered applications. Obtain and review exception management policies, including: emergency prompt template modifications, critical AI feature disablement procedures, expedited model integration changes, emergency content safety filter adjustments, urgent user experience degradation responses, and documentation requirements and post-exception reviews. Verify the existence of documented criteria that define: what qualifies as an AI application emergency, thresholds for critical content or behavior issues, safety or ethical risks requiring immediate changes, and authority levels for approving different exception types.

   2. Review Exception Process Documentation: Examine how the AIC manages AI exceptions via: defined exception request workflows and templates, approval requirements based on type and end-user impact, risk assessment steps for exception justification, temporary approval timeframes and revalidation steps, documentation standards for emergency actions, and post-implementation validation and exception reporting mechanisms.

   3. Assess Emergency Response Procedures: Review documented response plans for scenarios such as: foundation model failure or integration issues, AI output quality deterioration or hallucination spikes, content safety filtering malfunctions, prompt degradation or behavior drift, public relations or data privacy emergencies involving AI, and user experience failures requiring immediate remediation.

   4. Evaluate Governance Structures: Assess exception governance structures including: exception approval authorities and escalation protocols, emergency response team designations and rotations, exception review boards and reporting charters, alignment with GRC-04 and enterprise risk frameworks, and executive oversight and audit trail visibility.

2. Define and Verify Exception Records

   1. Identify and Cross-Check Exception Inventory: Obtain a full inventory of AI application exception records (e.g., model updates, emergency prompt changes, feature disablements, content filter patches). Cross-reference with: AI monitoring alerts and feedback trend spikes, support tickets, escalation records, and end-user communications, incident post-mortems and status page updates, risk acceptance logs and governance reports. Ensure completeness, consistency, and traceability.

3. Exception Sample Selection and Testing

   1. Select Representative Sample: Choose a diverse set of exceptions across: types (prompts, filters, model integrations, UI changes), AI capabilities (generation, summarization, reasoning, safety), impact severity (high, medium, low), time periods and business functions, and authorities involved in approval.

   2. Validate Exception Management Lifecycle: For each sampled exception, verify the following. Justification: documented urgency or special conditions, evidence from user complaints or system metrics, risk assessment and alternative analysis, fit against exception criteria. Approval: approved by proper stakeholders or retroactively authorized, approval scope and limitations (e.g., tenant, duration) clearly defined, justification and conditions recorded. Implementation: executed as per approved scope, additional monitoring deployed, stakeholder and user communications issued, temporary measures clearly flagged. Closure and Follow-up: timely closure when no longer needed, quality or behavioral validation tests completed, lessons learned captured in post-mortem, return to standard processes confirmed, process improvements proposed or initiated.

4. Exception Tracking, Governance, and Continuous Improvement

   1. Assess Tracking and Oversight Mechanisms: Confirm centralized tracking of all exceptions and expirations, regular reporting to AI governance and risk management bodies, executive oversight of major exceptions, trend and pattern analysis across AI application components, identification of recurring weaknesses or AI failure modes.

   2. Evaluate Governance and Improvement Processes: Assess the AIC’s capacity for recognizing systemic exception patterns, refining exception criteria based on past incidents, reducing exception frequency through design and engineering updates, calibrating emergency response protocols by scenario type, integrating post-incident insights into architecture and governance.

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.

Auditing Guidelines for AI Customers (AIC)

1. Inquiry with Control Owners

   1. Interview application development managers, DevOps teams, and release engineers responsible for the change management and rollback processes. Obtain and review the organization’s rollback policies and procedures, including: criteria for initiating rollbacks, rollback decision authority matrix, emergency rollback procedures, planned rollback testing requirements, post-rollback validation protocols, and rollback process documentation requirements. Verify the existence of documented criteria for what constitutes: AI application errors requiring rollback, security concerns warranting immediate rollback, performance degradation thresholds triggering rollback, and user experience impact levels necessitating rollback.

   2. Review Rollback Process Documentation: Examine documentation describing rollback planning requirements for all AI application changes. Technical rollback mechanisms for different application components include: prompt template versioning and rollback, model integration configuration rollback, user interface component restoration, content safety filter configuration rollback, feature flag rollback capabilities, post-rollback validation procedures, user communication templates for rollback scenarios, rollback time objectives for different severity levels, and verification requirements after rollback completion.

   3. Assess Known Good State Management: Review procedures for establishing and validating known good states: definition of “known good state” for AI application components, baseline performance and behavior documentation requirements, state validation procedures before releasing changes, state capture mechanisms (backups, snapshots, configuration archiving), version tagging and labeling standards for known good states, and environmental parity checks between staging and production.

   4. Evaluate Deployment Architecture: Assess how the deployment architecture supports rollback capabilities: blue/green deployment implementation, canary release mechanisms, infrastructure-as-code versioning, database schema and data migration rollback capabilities, configuration version control integration, containerization and immutable infrastructure approaches, and model version pinning capabilities.

2. Inspection of Evidence

   1. Rollback Strategy Documentation Review: Verify comprehensive rollback strategy documentation, including: Component-Specific Rollback Approaches (prompt template rollback mechanisms, model integration version rollback, user interface component rollback, safety filter configuration rollback, embedding and vector database rollback, and infrastructure configuration rollback); Rollback Decision Process (defined error thresholds triggering automatic rollback, security concern escalation paths, user impact assessment methodology, decision authority and approval workflow, decision documentation requirements); Rollback Execution Process (step-by-step rollback procedures for each component, required validations during rollback process, parallel systems maintenance during rollback, dependency management during rollback, database consistency maintenance, order of operations for complex rollbacks); Post-Rollback Activities (validation of application functionality after rollback, user notification procedures, root cause analysis requirements, metrics collection for rollback effectiveness, documentation and knowledge capture).

   2. Tools and Technical Implementation Assessment: Evaluate tools and technical implementations supporting rollback, including: version control system usage and configuration, feature flag implementation and management, automated deployment pipeline rollback capabilities, database backup and restore mechanisms, configuration management system versioning, container image versioning and repository management, AI model registry version management, and prompt template version control implementation.

   3. Sample-Based Testing of Rollback Capabilities: Select a representative sample of AI application components and verify: Rollback Planning (documentation of rollback plans for recent changes, identification of known good state reference points, dependent systems and components consideration, data migration rollback procedures where applicable, time and resource estimates for rollback execution); Rollback Testing (evidence of regular rollback capability testing, test results documentation and issue tracking, simulation exercises for critical components, integration of rollback testing in release certification, measurement of rollback completion times); Known Good State Verification (validation procedures for known good states, performance benchmarking of baseline states, security assessment of baseline configurations, documentation of acceptable behavior parameters, archiving of known good state artifacts).

   4. Previous Rollback Execution Review: For a sample of previously executed rollbacks, verify: Rollback Trigger Assessment (clear documentation of issues triggering rollback, alignment with defined rollback criteria, decision authority involvement per policy, appropriate urgency classification); Rollback Execution Documentation (step-by-step execution records, timing of rollback activities, issues encountered during rollback, verification activities performed, communication to users and stakeholders); Post-Rollback Activities (application functionality verification, performance assessment after rollback, user impact analysis, root cause identification for original issue, preventative measures implementation).

   5. Automated Monitoring and Rollback Integration: Assess the integration between monitoring systems and rollback processes: automated detection of application issues, alert thresholds aligned with rollback criteria, integration between monitoring and deployment systems, automated rollback triggers for severe issues, approval workflow automation for human-in-the-loop decisions, and monitoring of rollback process execution.

   6. Training and Exercise Programs: Evaluate training and exercise programs for rollback readiness: rollback procedure training for relevant teams, regular simulation exercises, lessons learned documentation and incorporation, cross-team collaboration in rollback scenarios, on-call response training for rollback execution, and new team member onboarding for rollback responsibilities.

3. Evaluation and Reporting

   1. Rollback Capability Effectiveness Assessment: Evaluate how well rollback processes: meet defined time objectives for different severity levels, successfully restore application functionality, minimize user impact during rollback execution, address all AI application components comprehensively, integrate with broader incident management, and balance automated and manual decision-making.

   2. Known Good State Management Assessment: Assess the effectiveness of known good state management: clarity of known good state definition, validation thoroughness for baseline states, accessibility of known good state artifacts, frequency of known good state documentation, and integration with release certification process.

   3. Rollback Process Documentation Quality: Evaluate the quality of rollback process documentation: clarity and completeness of procedures, component-specific technical details, decision-making guidance, accessibility during incidents, currency and maintenance of documentation, and alignment with actual technical capabilities.

   4. Continuous Improvement Mechanisms: Evaluate processes for improving rollback capabilities: regular review of rollback effectiveness metrics, incorporation of lessons learned from exercises and incidents, technical capability enhancement for faster rollbacks, process refinement based on execution experience, adjustment of decision criteria based on observed outcomes, and evolution of known good state standards.

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.

Auditing Guidelines for AI Customers (AIC)

1. Policy Examination: Verify that the AIC’s Cryptography, Encryption, and Key Management (CEK) policy exists and addresses the planning, delivery, and support of cryptographic functions in the context of AI adoption and integration. Confirm that the policy covers data shared with AI providers, such as prompts, payloads, and completions; the generation, rotation, and destruction of keys in customer-managed environments; standards for encryption algorithms and key storage; and the use of role-based access control for CEK operations supporting AI workloads.

2. Governance: Confirm that the CEK policy is formally approved by senior management and that approval is recorded through a recognized governance mechanism such as a policy register or executive authorization. Verify that the policy is owned by a designated individual or function and that it is reviewed and updated at least annually or in response to material changes. Relevant triggers may include adoption of a new AI service or vendor, changes in cloud hosting architecture, or shifts in legal or contractual requirements related to encryption, key usage, or data residency.

3. Communication: Review documentation showing that the CEK policy has been communicated to internal stakeholders including solution architects, application integrators, data protection officers, and compliance teams. Acceptable evidence includes internal memos, acknowledgement records, training logs, or onboarding checklists.

4. Implementation Validation: Validate that the policy is being followed by examining encryption settings in cloud service provider platforms or AI gateways, usage logs for customer-managed key services, implementation of tokenization or obfuscation controls in API workflows, and enforcement of data-at-rest protections for logs and outputs generated from AI interactions.

5. Role Assignment: Review the policy and supporting documentation to confirm that responsibilities are clearly assigned for tasks such as API encryption oversight, cloud key management system (KMS) administration, and vendor risk assessment related to encryption and access control. Confirm that these roles are associated with named individuals or support functions within the AIC’s security and IT structure.

6. Training and Awareness: Inspect relevant records, such as training attendance logs, security awareness materials, or AI onboarding guides to confirm that personnel involved in AI-related cryptographic operations have received training on the CEK policy and its application.

7. Compliance Monitoring: Evaluate whether the AIC monitors CEK policy compliance by reviewing implemented alerting mechanisms for potential data exposure, third-party audit reports or vendor certifications, and internal reviews of encryption logs and key access for AI integrations.

8. Upstream and Downstream Dependencies: Review how the AIC ensures that CEK controls are upheld by upstream providers such as OSPs or MPs and retained internally within their own systems. Confirm that the CEK policy includes provisions for validating vendor encryption guarantees or that it documents unaddressed risks and defines compensating internal controls where external guarantees are lacking.

CEK-02: CEK Roles and Responsibilities

Control Specification

Define and implement cryptographic, encryption and key management roles and responsibilities.

Auditing Guidelines for AI Customers (AIC)

1. Verify that AIC roles and responsibilities are defined in formal policies and procedures for cryptographic, encryption, and key management operations (e.g., key creation, rotation, approval, exception handling).

2. Confirm that AI-specific responsibilities are defined in alignment with the AIC’s role (e.g., securing prompts, managing encrypted API traffic, overseeing AI provider integrations) and that role assignments are documented and maintained.

3. Review documentation to confirm that responsibilities are mapped to appropriate internal roles (e.g., IT security, cloud operations, compliance).

4. Validate that AI integration responsibilities (e.g., API token handling, and provider encryption assurance) are assigned to personnel overseeing AI vendor relationships.

5. Verify that segregation of duties exists between key management functions and those responsible for AI service configuration or vendor access.

6. Confirm that training is provided to staff involved in operations and AI-related encryption tasks.

7. Verify that role assignments are reviewed at least annually or upon changes in provider relationships, regulatory requirements, or AI service scope.

8. Confirm that governance bodies or risk owners oversee roles and review alignment with organizational and AI-related risk exposure.

9. Validate that continuity plans are in place and designate backup personnel for functions, including AI data handling and integration support.

10. Verify that responsibilities include reviewing and confirming the encryption posture of upstream AI providers (e.g., APs, OSPs, MPs) and documenting any gaps or compensating controls.

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.

Auditing Guidelines for AI Customers (AIC)

1. Verify that AIC encryption is implemented for sensitive customer-controlled data at rest, including logs, application output, and AI-related data stores, using approved algorithms.

2. Verify that encryption is enforced for data in transit across internal networks and when integrating with external AI providers through APIs or gateways.

3. Confirm that the organization defines which types of data require encryption, including regulated, sensitive, and AI-generated or AI-consumed content.

4. Review the data classification scheme and confirm that encryption controls are mapped to each sensitivity level, especially for AI-related data (e.g., prompts, completions).

5. Validate that cryptographic libraries used in enterprise systems and AI integrations are certified to approved standards (e.g., FIPS 140-2/3).

6. Verify that encryption keys are managed using centralized key management systems under the AIC’s control, with access controls, audit logging, and lifecycle enforcement.

7. Confirm that encryption configurations are hardened across internal systems and third-party AI integrations (e.g., strong ciphers, no fallback to plaintext).

8. Verify that exceptions to encryption requirements, including from AI providers, are documented, reviewed, approved, and mitigated through compensating controls (e.g., tokenization, proxy encryption).

9. Confirm that encryption enforcement is monitored through logging and alerting, including detection of unencrypted traffic or insecure provider connections.

10. Verify that data shared with AI services (e.g., user prompts, payloads) is encrypted before transmission and protected during storage and post-processing.

11. Validate that encryption keys used for securing AI API traffic and encrypted payloads are governed under the AIC’s internal CEK controls.

12. Review vendor management records to confirm that encryption expectations are included in AI provider agreements and validated during onboarding and periodic risk reviews.

CEK-04: Encryption Algorithm

Control Specification

Utilize encryption algorithms following industry standards for protecting data, based on the data classification and associated risks.

Auditing Guidelines for AI Customers (AIC)

1. Verify that the AIC maintains a documented standard for approved encryption algorithms mapped to internal data classification levels and relevant regulatory or contractual obligations (e.g., PII, financial records, proprietary models).

2. Confirm that encryption algorithms used for securing AI-related data (e.g., prompts, completions, embeddings, model access credentials) align with industry best practices and organizational standards (e.g., AES-256, RSA-2048, TLS 1.2+).

3. Review whether algorithm suitability is assessed periodically to identify deprecated algorithms or known vulnerabilities and that updates are implemented as needed.

4. Validate that algorithm selection considers usability factors including compatibility with existing IT infrastructure, cloud service providers, and deployed AI applications.

5. Confirm that encryption is enforced across data at rest and in transit in AIC-controlled environments, especially where sensitive data is exchanged with external AI providers.

6. Verify that AIC-managed encryption is integrated with key management systems and subject to access control policies ensuring proper key usage and isolation.

7. Review whether encryption standards are reviewed and approved by security or risk governance structures, with regular alignment to external standards (e.g., NIST, ENISA).

8. Confirm that third-party services and AI vendors used by the AIC are required, through contract or due diligence, to use algorithms that meet AIC’s minimum encryption criteria.

9. Validate that findings from penetration tests, audits, or supplier risk assessments related to encryption algorithm use are tracked and resolved within the CEK governance program.

10. Verify that the AIC evaluates encryption algorithm compatibility with upstream providers (e.g., AP, OSP, MP) and ensures alignment with internal systems and downstream use of AI-generated data.

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.

Auditing Guidelines for AI Customers (AIC)

1. Verify that the AIC maintains a documented change management procedure for cryptographic, encryption, and key management changes across enterprise and cloud-integrated environments.

2. Confirm that the procedure includes changes triggered by internal drivers (e.g., new application rollouts, BYOK implementation) and external sources (e.g., CSP upgrades, regulatory shifts, provider policy changes).

3. Review whether CEK-related changes are submitted through a centralized change control process with appropriate visibility and traceability.

4. Verify that roles and responsibilities are assigned for reviewing and approving CEK changes, including representation from security, IT operations, privacy, legal, and risk management functions.

5. Confirm that CEK change implementation plans are developed with supporting documentation, testing procedures, rollback/fallback plans, and review milestones.

6. Review how CEK changes are communicated to affected internal business units, technology teams, and external parties (e.g., third-party AI vendors, managed service providers).

7. Validate that version control is applied to CEK policies, system configurations, and encryption-related integrations with external providers.

8. Verify that post-implementation validation activities (e.g., system tests, access control checks, audit log reviews) confirm the change’s effectiveness and detect unintended impact.

9. Confirm that CEK change records are retained and include documentation of risk evaluations, approvals, testing results, communication logs, and rollback strategies.

10. Review whether CEK change management processes include assessment of upstream provider cryptographic changes (e.g., AP/OSP/MP modifications) and downstream obligations to internal consumers or regulated data environments.

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.

Auditing Guidelines for AI Customers (AIC)

1. Verify that the AIC maintains a documented process for managing changes related to encryption and key management across its enterprise systems and cloud-based AI integrations.

2. Confirm that CEK-related changes (e.g., BYOK rollout, encryption protocol updates, KMS reconfiguration) are reviewed through a formal governance or change control process prior to deployment.

3. Review whether each change is supported by a cost-benefit analysis, weighing compliance benefits (e.g., regulatory alignment), operational costs, performance impact, and provider compatibility.

4. Validate that the AIC evaluates and documents residual risks introduced by the change (e.g., delayed rollout, partial key control, dependency gaps) with risk owner and mitigation plan.

5. Confirm that changes are reviewed for downstream impact on internal applications, business units, or customers that rely on the AIC’s encrypted AI data flows or key management practices.

6. Verify that relevant stakeholders (e.g., IT security, compliance, architecture, and line-of-business leaders) participate in CEK change review and approval.

7. Review whether rollback mechanisms, version control, and clear documentation are in place for all CEK-related changes, particularly when affecting AI gateways or cloud infrastructure.

8. Validate that CEK changes are monitored post-implementation, with tracking of unintended consequences such as service interruptions, key misconfiguration, or integration failures.

9. Confirm that feedback from prior CEK change efforts is collected and integrated into future planning cycles to improve impact analysis and coordination with providers.

10. Verify that the AIC evaluates upstream changes made by providers (e.g., AP, OSP, MP) that may affect encryption coverage or key control and incorporates those upstream changes into its risk and change management processes.

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.

Auditing Guidelines for AI Customers (AIC)

1. Verify that the AIC has a documented CEK risk management program covering encryption and key management risks within its enterprise systems and its use of external AI services.

2. Confirm that CEK risks are contextualized based on data types shared with AI providers (e.g., prompts, user inputs, model outputs), usage of cloud environments, and integration with external APIs or gateways.

3. Review the risk assessment methodology used to evaluate CEK risks, including criteria such as data criticality, regulatory exposure (e.g., GDPR, HIPAA), and provider architecture.

4. Verify that CEK-related risks are tracked in a risk register or governance system and include treatment plans, risk owners, and timelines for mitigation or acceptance.

5. Confirm that CEK treatment strategies include technical measures (e.g., BYOK/HYOK), contractual clauses, or compensating controls (e.g., data minimization, prompt sanitization).

6. Validate that residual risks, including those inherited from upstream providers, are periodically reviewed by security, legal, or risk governance teams and reassessed when significant system or vendor changes occur.

7. Review how CEK risks are monitored across systems through automated tooling (e.g., encryption posture dashboards, audit logs) and reviewed for anomalies or drift.

8. Confirm that findings from internal audits, vendor assessments, or AI incidents (e.g., data leakage, model misuse) are integrated into the CEK risk management lifecycle.

9. Verify that CEK risks tied to AI usage, such as insufficient encryption of AI-generated outputs, lack of control over prompt storage, or improper key usage, are captured and addressed.

10. Validate that the CEK risk program includes ongoing review of upstream encryption and key management practices of external providers (e.g., APs, OSPs, MPs) and that downstream obligations to internal business units or users are also considered and documented.

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.

Auditing Guidelines for AI Customers (AIC)

1. Verify that the AIC utilizes available encryption key management features (e.g., BYOK, customer-controlled KMS) provided by upstream service providers and enforces internal policies for key lifecycle management.

2. Confirm that the AIC has the option to use Bring Your Own Key (BYOK), Hold Your Own Key (HYOK), or a similar model for controlling encryption keys used in AI service interactions.

3. Review provider documentation to ensure the key management solution supports key generation, import, rotation, and revocation under AIC control.

4. Validate that keys used to protect AIC data (e.g., prompts, completions, embeddings, stored results) are logically segregated and traceable to AIC-controlled key identifiers.

5. Verify that the AIC has direct or delegated access to encryption key lifecycle management functions, including policy enforcement and audit logging.

6. Confirm that cryptographic operations performed using AIC-managed keys are recorded and auditable through provider-side or AIC-side logging mechanisms.

7. Review whether the AIC can define and enforce key usage policies (e.g., geographic restrictions, expiration, usage scope) through the CSP interface or provider APIs.

8. Verify that key access is restricted to authorized AIC personnel and that provider access to AIC-managed keys is either blocked or tightly scoped and logged.

9. Validate that there is a process to test and confirm AIC key control functionality before sensitive workloads are deployed to production.

10. Confirm that the AIC periodically reviews and validates upstream provider support for AIC-controlled key management and that any limitations or risks related to key control delegation are documented, monitored, and addressed.

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

Auditing Guidelines for AI Customers (AIC)

1. Verify that the AIC encryption and key management systems, policies, and processes are audited at a frequency that reflects the associated risk exposure preferably continuously but at least annually and after any security event.

2. Confirm that audits are triggered after adopting new AI services, modifying encryption configurations, or integrating additional third-party providers.

3. Review the scope to ensure audits cover key management, encryption configuration, and integration with external AI services.

4. Validate that audit procedures assess adherence to internal policies and provider requirements related to algorithm strength, key lifecycle, and data protection.

5. Verify that audits are performed independently of business or technical teams responsible for managing vendor relationships or AI integrations.

6. Confirm that audit findings are documented and that resulting actions are implemented to address CEK-related control weaknesses or gaps.

7. Review whether CEK risks and audit outcomes are reported to governance, legal, compliance, and vendor risk management teams.

8. Verify that audit logs and automated CEK monitoring tools are in place to support timely identification of anomalies, exposure, or misconfigurations.

9. Confirm that encryption of data shared with or received from AI providers (e.g., prompts, completions, model responses) is within the audit scope.

10. Validate that CEK audit procedures are updated regularly to reflect changes in legal and regulatory obligations, business risk, and the encryption posture of external AI providers (e.g., AP, OSP, MP).

CEK-10: Key Generation

Control Specification

Generate Cryptographic keys using industry accepted cryptographic libraries specifying the algorithm strength and the random number generator used.

Auditing Guidelines for AI Customers (AIC)

1. Verify that the AIC uses approved, standards-based cryptographic libraries (e.g., FIPS 140-2/3 certified) to generate encryption keys in enterprise or cloud environments for protecting AI data exchanges, including prompts, completions, embeddings, and internal model usage.

2. Confirm that algorithm type and strength are documented for all keys protecting sensitive or regulated data exchanged with AI providers.

3. Validate that cryptographic random number generators (RNGs) used for key generation meet industry standards (e.g., NIST SP 800-90A).

4. Verify that key generation is integrated into secure enterprise systems (e.g., cloud KMS, HSM, key vaults), with automation where appropriate.

5. Review access controls and confirm that only authorized personnel or systems can initiate key generation.

6. Confirm that encryption keys used to secure AI-related data (e.g., prompts, completions, embedding vectors, API traffic) are generated through approved processes.

7. Verify that no encryption keys are hardcoded in AI integration scripts, configuration files, or cloud workloads.

8. Review logging and auditing of key generation events, ensuring traceability of key origin, usage purpose, and associated AI service or data flow.

9. Confirm that keys used in test environments or development platforms are logically and cryptographically segregated from those used in production AI workflows.

10. Validate that key generation procedures are reviewed and updated based on cryptographic standards, business risk, and encryption assurances expected from or provided to external AI service providers.

CEK-11: Key Purpose

Control Specification

Manage cryptographic secret and private keys that are provisioned for a unique purpose.

Auditing Guidelines for AI Customers (AIC)

1. Verify that the AIC assigns cryptographic keys and secrets (e.g., API keys, access tokens, private credentials) to a unique purpose and that separation is enforced in internal systems, key vaults, and external provider configurations.

2. Confirm that documentation exists defining the intended purpose of each key used in customer-managed environments and that this documentation is periodically reviewed for accuracy.

3. Verify that controls are in place to prevent a single key from being reused for multiple cryptographic functions (e.g., signing and decryption).

4. Review enterprise key management settings or integrations (e.g., BYOK, KMS) to ensure keys are applied only to their designated workloads and not reused across business units or AI use cases.

5. Confirm that access to each key is limited to personnel or systems with roles that align to the key’s purpose, such as integration developers or data governance teams.

6. Validate that keys used for AI integration (e.g., LLM API requests, encrypted input/output payloads) are provisioned with clear, function-specific boundaries.

7. Review whether key inventory systems or registries include metadata identifying each key’s purpose and whether this metadata is enforced through configuration or policy.

8. Confirm that DevOps or IT automation pipelines enforce policies that prevent unintended reuse or misapplication of key material during AI service integration or rollout.

9. Verify that key usage logs are monitored for inappropriate use of keys outside their intended purpose and that alerts are configured for policy violations.

10. Confirm that keys exchanged with upstream providers (e.g., API tokens, encryption credentials) or used in downstream applications (e.g., customer-facing interfaces) are scoped to specific use cases and not reused for unrelated operations.

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.

Auditing Guidelines for AI Customers (AIC)

1. Verify that the AIC rotates cryptographic keys in accordance with defined cryptoperiods, considering the risk of information disclosure and legal or regulatory requirements across AI service consumption and enterprise integration environments.

2. Confirm that key rotation procedures are documented and reviewed periodically to reflect changes in organizational risk posture, data sensitivity, and regulatory obligations.

3. Verify that key rotation is implemented through secure, automated processes (e.g., cloud KMS, infrastructure automation) or follows an approved manual process with audit trails.

4. Review systems and applications that use cryptographic keys to ensure keys are rotated at defined intervals, and that rotation schedules are enforced through technical controls.

5. Confirm that access to rotate keys is restricted to authorized personnel or services and that rotation activities are subject to approval workflows or policy enforcement.

6. Validate that keys used for AI-related functions (e.g., prompt encryption, API gateway authentication, encrypted outputs) are rotated according to defined policies and not reused beyond their cryptoperiod.

7. Review key rotation logs to ensure events are captured with user or system identity, timestamp, and reason for rotation (e.g., scheduled, incident response).

8. Confirm that systems consuming rotated keys are updated reliably and securely to avoid disruptions or insecure fallback behaviors.

9. Verify that retired keys are archived or destroyed securely, with handling aligned to data classification policies and retention requirements.

10. Confirm that key rotation involving upstream AI providers (e.g., model APIs) or downstream applications (e.g., business workflows) is coordinated to maintain continuity and confidentiality during transitions.

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.

Auditing Guidelines for AI Customers (AIC)

1. Verify that the AIC defines, implements, and evaluates processes, procedures, and technical measures to revoke cryptographic keys prior to the end of their cryptoperiod, including in cases of vendor offboarding, key compromise, or service retirement, consistent with legal, contractual, and regulatory obligations, service integrations, prompt handling, and customer-managed encryption layers.

2. Confirm that key revocation procedures are documented, communicated to relevant stakeholders, and reviewed periodically in light of changes to legal, contractual, or operational requirements.

3. Verify that key revocation actions are performed through secure, auditable mechanisms such as cloud KMS, enterprise secrets managers, or policy-driven automation tools.

4. Review enterprise and cloud configurations to ensure revoked keys are removed from active workloads, internal integrations, AI pipelines, and historical configurations.

5. Confirm that revocation permissions are assigned only to designated security or platform roles and that such actions require approval or dual control for high-impact environments.

6. Validate that keys used in AI workflows (e.g., securing prompts, decrypting completions, authenticating LLM APIs) are subject to the same revocation procedures and removed from all relevant systems when no longer valid.

7. Review revocation event logs to verify completeness, accuracy, and alignment with policy (e.g., initiator, time, affected services).

8. Confirm that applications and services that relied on a revoked key have either transitioned to a new key or been blocked from further operation until rotation is completed.

9. Verify that revoked keys are either securely archived (if required for audit/legal reasons) or destroyed, with handling appropriate to the key classification and applicable compliance frameworks.

10. Confirm that revocation of keys tied to upstream AI providers (e.g., for secure API sessions, for encrypted data exchange) is coordinated with the provider to maintain secure operations and prevent exposure.

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.

Auditing Guidelines for AI Customers (AIC)

1. Verify that the AIC defines, implements, and evaluates processes, procedures, and technical measures to destroy cryptographic keys stored outside a secure environment and to revoke keys managed through cloud key services or provider-managed HSMs when they are no longer needed, including those used in AI service integrations, prompt handling, and customer-managed encryption layers.

2. Verify that the AIC has a documented policy and process for the secure deletion of cryptographic keys and associated data once they are no longer needed, ensuring compliance with legal, regulatory, and contractual requirements for key and data destruction, especially for customer-managed encryption keys, prompt protection, and API traffic encryption.

3. Confirm that criteria for key destruction or revocation include personnel offboarding, vendor relationship termination, key compromise, or the retirement of associated services or systems.

4. Verify that secure destruction methods are used for keys stored in software environments (e.g., encrypted file systems, cloud secrets managers), and that execution is traceable and documented.

5. Review application, cloud, and AI integration environments to confirm that keys are not left in memory, configuration files, or logs after deactivation or revocation.

6. Confirm that keys managed in HSMs or cloud KMS platforms are securely revoked using access-controlled and auditable procedures once they are no longer required.

7. Validate that keys used for AI-related functions (e.g., encrypted prompts, secure API tokens, model decryption) are revoked when AI services are retired, changed, or re-integrated.

8. Review audit trails or destruction logs to confirm that each revocation or destruction event includes key metadata, initiator, timestamp, and method of disposal.

9. Confirm that key destruction is embedded into decommissioning workflows for systems, applications, or cloud services to prevent residual key exposure.

10. Verify that the organization’s key destruction and revocation practices comply with legal and regulatory requirements, especially for cross-border data or customer data used in AI contexts.

11. Confirm that any coordination with upstream providers or downstream business units related to shared key removal is performed to prevent integration errors or security gaps.

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.

Auditing Guidelines for AI Customers (AIC)

1. Verify that the AIC defines processes, procedures, and technical measures to generate cryptographic keys in a pre-activated state, where keys are not authorized for use until explicitly approved.

2. Confirm that pre-activated keys are securely stored and logically separated from active key inventories until explicitly activated (e.g., in enterprise KMS, AI integration layers, or customer-controlled environments).

3. Review the AIC’s approval process for key activation and verify that it includes documented criteria, workflow approvals, or automated controls prior to use.

4. Validate that access to key activation functions is restricted to designated personnel or trusted systems, and that separation of duties is enforced where appropriate.

5. Confirm that the AIC applies consistent activation controls across enterprise systems and integrations with AI services or external APIs.

6. Review key activation audit logs and ensure they include relevant information such as activation initiator, reason, date/time, and target system or integration.

7. Verify that any applicable legal, regulatory, or contractual obligations (e.g., data residency, encryption governance) are reflected in AIC key activation procedures.

8. Confirm that policies exist to handle expiration or removal of pre-activated keys that are not authorized for use within defined timeframes.

9. Verify that AI-specific cryptographic keys (e.g., for prompt encryption, completion delivery, or secure AI-to-AI communications) are subject to pre-activation controls and approval workflows.

10. Review whether the AIC’s activation strategy accounts for provider-side key lifecycle events and coordinates with upstream activation expectations from OSPs or MPs.

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.

Auditing Guidelines for AI Customers (AIC)

1. Verify that the AIC defines processes, procedures, and technical measures to monitor, review, and approve cryptographic key transitions to and from suspension, including keys used in AI service integrations, prompt protection, and customer-managed encryption systems.

2. Confirm that the AIC defines valid criteria for suspending cryptographic keys, including policy violations, security anomalies, temporary operational pauses, and other risk-based triggers relevant to internal AI integrations and customer-controlled encryption layers.

3. Review whether the AIC documents a formal workflow or approval process for initiating or reversing key suspension events.

4. Validate that suspended keys are restricted from active use while remaining available for potential reactivation through secured procedures.

5. Verify that only authorized personnel or automation tools can initiate or reverse key suspension, and that separation of duties is applied where feasible.

6. Review whether monitoring tools or cloud-native alerts are configured to detect unauthorized or suspicious key suspension activities.

7. Verify that audit logs are maintained for key suspension actions, including who initiated them, which keys were affected, and the associated rationale and timing.

8. Confirm that the AIC’s procedures for suspending and reactivating keys incorporate legal, contractual, and regulatory requirements related to data protection, availability, or auditability.

9. Validate that AI-related encryption keys — such as those used in securing input/output between AIC systems and provider APIs — are also governed by the same suspension policies.

10. Review whether the AIC coordinates with upstream service providers (e.g., APs, OSPs, MPs) when suspended keys could affect operational AI services or inter-system encryption dependencies.

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.

Auditing Guidelines for AI Customers (AIC)

1. Verify that the AIC defines, implements, and evaluates processes, procedures, and technical measures to deactivate cryptographic keys at the time of their expiration date, including provisions for legal and regulatory requirements (e.g., keys used in prompt protection, customer-controlled KMS, or API traffic encryption).

2. Confirm that expiration dates are assigned to all customer-managed keys and recorded in enterprise or cloud-native key lifecycle management platforms.

3. Review whether automated expiration-based deactivation mechanisms are configured for keys used in securing AI data flows, integrations, or workloads.

4. Validate that deactivated keys are excluded from active usage in application pipelines, API tokens, and data encryption layers.

5. Confirm that the AIC restricts access to expired keys and logically separates them from currently active key inventories.

6. Review audit trail records for deactivation events, verifying inclusion of timestamp, system, affected services, and rationale for expiration.

7. Verify that expired keys are either retained securely for compliance or retired and destroyed in accordance with retention and risk policies.

8. Confirm that legal and regulatory requirements—such as data residency, industry encryption standards, or audit readiness—are reflected in key deactivation procedures.

9. Validate that keys used in AI service interactions (e.g., prompt protection, encrypted responses) are subject to the same expiration and deactivation controls.

10. Review whether the AIC coordinates with APs, OSPs, or MPs to ensure that deactivated keys do not disrupt upstream encryption dependencies or AI service continuity.

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.

Auditing Guidelines for AI Customers (AIC)

1. Verify that the AIC defines, implements, and evaluates processes, procedures, and technical measures to manage archived cryptographic keys in a secure repository requiring least privilege access, including provisions for legal and regulatory requirements (e.g., customer-retained keys used in AI integrations or encrypted response logging).

2. Confirm that archived keys are stored in secure repositories (e.g., KMS, HSM) with tightly scoped access policies, and retrieval is gated by approval workflows and access logging.

3. Review whether the AIC enforces least privilege access to archived keys, ensuring that only authorized personnel with a documented business justification can retrieve or manage them.

4. Validate that access to archived keys follows an approval process and is logged, with audit trails retained and reviewed regularly.

5. Confirm that archived keys are functionally segregated from active keys and are not available for encryption, decryption, or signing operations.

6. Review whether the AIC defines key retention schedules for archived keys based on applicable regulatory, legal, and contractual obligations.

7. Verify that the AIC periodically reviews archived key inventories to determine whether continued retention is necessary or poses risk.

8. Confirm that technical controls are implemented to prevent unauthorized recovery or replication of archived cryptographic keys.

9. Validate that keys used in AI integrations (e.g., encrypted prompts, AI response data) are archived when rotated or decommissioned, in alignment with retention and risk policies.

10. Review whether the AIC coordinates with APs, OSPs, and MPs to identify dependencies on archived keys and document any shared retention responsibilities or risks.

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.

Auditing Guidelines for AI Customers (AIC)

1. Verify that the AIC defines, implements, and evaluates processes, procedures, and technical measures for handling compromised cryptographic keys, including provisions for legal and regulatory requirements.

2. Verify that the AIC’s incident response plan includes documented steps for handling compromised keys, ensuring that the keys are restricted to decryption, securely revoked, and that they cannot be reused for encryption. Confirm that the AIC’s incident response procedures comply with relevant legal and regulatory requirements for key management in the event of a compromise.

3. Confirm that the AIC restricts use of compromised keys to decrypt-only operations under controlled circumstances (e.g., decrypting AI service inputs or archived completions), and explicitly prohibits further encryption with such keys unless formally approved.

4. Review how the AIC identifies, flags, or categorizes compromised keys within its own key lifecycle management processes or third-party key management platforms.

5. Validate that compromised keys are removed from normal operations and retained in a secured, segregated environment for decrypt-only usage.

6. Confirm that access to compromised keys is limited to personnel with explicit authorization, and that such access is reviewed and approved in advance.

7. Review logging mechanisms capturing when and how compromised keys are accessed, and ensure monitoring includes detection of unauthorized usage attempts.

8. Verify that all decrypt-only activities involving compromised keys are documented, justified, and retained for audit review, particularly where these apply to AI data flows (e.g., previously encrypted prompts, completions, or embeddings).

9. Confirm that the AIC’s practices align with applicable legal, regulatory, or contractual obligations concerning the handling of compromised keys and sensitive AI-related data.

10. Validate that no AI-facing encryption mechanisms (e.g., API gateway encryption, data tokenization layers) continue using compromised keys for new encryption operations.

11. Review whether the AIC coordinates with its upstream providers (e.g., APs, OSPs, MPs) to ensure that compromised key risks are contained and that any inherited keys are rotated or revoked appropriately.

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.

Auditing Guidelines for AI Customers (AIC)

1. Verify that the AIC defines, implements, and evaluates processes, procedures, and technical measures to assess the tradeoff between operational continuity and the risk of key exposure in the event of keying material loss, including provisions for legal and regulatory requirements.

2. Confirm that the AIC conducts periodic risk assessments that evaluate key recovery scenarios across enterprise and AI consumption environments (e.g., BYOK/HYOK keys, prompt encryption keys, data access secrets) and considers the risk to internal operations and trust in provider-managed cryptographic systems.

3. Review whether the AIC classifies key types (e.g., customer-managed encryption keys, API token secrets, prompt encryption keys) and evaluates recovery needs for each in business continuity plans.

4. Validate that secure key backup processes are implemented, including encryption-at-rest and access restrictions for stored key materials.

5. Confirm that key recovery procedures are tested periodically to ensure recoverability without exposing AI-related or business-sensitive data.

6. Review approval workflows for initiating key recovery, including designated approvers, documentation requirements, and access traceability.

7. Verify that systems used for key recovery are protected by strong access controls, logging, and segregation of duties.

8. Confirm that the AIC incorporates key recovery and data risk scenarios into broader business continuity and disaster recovery planning, including compliance with relevant regulations.

9. Validate that AI-specific use cases (e.g., encrypted prompt history, results caching, model embeddings) are factored into recovery planning and protected against unauthorized access during restoration.

10. Review whether the AIC engages with upstream providers (APs, OSPs, MPs) to understand the recovery guarantees, responsibilities, and residual risks tied to externally managed cryptographic keys.

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.

Auditing Guidelines for AI Customers (AIC)

1. Verify that the AIC defines, implements, and evaluates processes, procedures, and technical measures to ensure the key management system can track and report all cryptographic materials and changes in key status.

2. Confirm that the AIC’s key management system maintains a complete and up-to-date inventory of all cryptographic keys and materials in scope, including key attributes (e.g., type, status, owner, lifecycle stage, algorithm) and usage context.

3. Review whether the AIC includes key attributes in inventory records, such as purpose, algorithm, data classification, ownership, cryptoperiod, and associated systems.

4. Validate that the inventory distinguishes between keys under AIC control and those managed by upstream providers (e.g., APs, OSPs), and documents contractual boundaries.

5. Confirm that access to the key inventory system is restricted to authorized personnel and protected by role-based access controls and audit trails.

6. Review archival and retention policies for historical key records, ensuring they meet internal governance standards and applicable legal and regulatory requirements.

7. Verify that the inventory includes AI-specific keying materials, such as those used for securing prompts, completions, embeddings, or inference-related data.

8. Confirm that inventory records are continuously monitored for anomalies (e.g., keys not rotated, missing metadata, unauthorized key changes).

9. Validate that the AIC performs regular reviews of the key inventory to ensure accuracy, completeness, and relevance to the systems in use.

10. Review whether the AIC receives, maintains, or reconciles inventory information from upstream providers when customer-managed keys interface with external AI services.

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.

Auditing Guidelines for AI Customers (AIC)

1. Verify that the AI Customer has physical and environmental security policies covering all customer‑managed facilities used to support AI system integration or operational activities.

2. Confirm that evidence shows restricted access to AI‑integrated systems and periodic (at least annually or upon significant changes) review of the relevant physical and environmental security policies.

3. Verify that the AI Customer reviews the provider’s physical security assurance documentation and maintains defined escalation procedures for service disruptions.

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.

Auditing Guidelines for AI Customers (AIC)

1. Verify the AIC’s vendor risk management policy requires its AI providers to attest to using CSPs with certified media and equipment disposal processes.

2. Review service agreements for clauses that address the secure deletion of customer data upon service termination.

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.

Auditing Guidelines for AI Customers (AIC)

1. Verify that the AIC’s data handling policy requires explicit authorization for transferring sensitive data to any third-party AI service or external location.

2. Review contracts with providers to ensure they are required to seek authorization before relocating customer data.

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.

Auditing Guidelines for AI Customers (AIC)

1. Verify the AIC’s third-party risk management policy includes requirements for their AI providers to attest to having secure work environments for their personnel.

2. Review the AIC’s internal physical security policies for their own office locations.

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.

Auditing Guidelines for AI Customers (AIC)

1. Verify the AIC’s vendor management process requires that any AI provider handling physical media containing customer data must have a secure transport policy.

2. Review service agreements for clauses pertaining to the secure handling of physical media.

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.

Auditing Guidelines for AI Customers (AIC)

1. Verify the AIC classifies the data it inputs into AI services according to its internal data classification policy.

2. Confirm that the AI service itself is classified as a critical business asset, and that appropriate risk management is applied.

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.

Auditing Guidelines for AI Customers (AIC)

1. Verify the AIC maintains an inventory of all procured AI services, including provider details, contract terms, and the business owner.

2. Confirm this inventory is used for vendor risk management and is reviewed at least annually.

DCS-08: Controlled Physical Access Points

Control Specification

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

Auditing Guidelines for AI Customers (AIC)

1. Verify that the AIC’s procurement and vendor assessment policies require providers (AP, OSP, MP) to use CSPs with certified physical security controls.

2. Review contracts to ensure providers are obligated to disclose the physical regions where customer data is processed and stored.

DCS-09: Equipment Identification

Control Specification

Use equipment identification as a method for connection authentication.

Auditing Guidelines for AI Customers (AIC)

1. Verify that the AIC’s security policy requires device posture checks for endpoints accessing the AI service.

2. Confirm that access to the AI service can be restricted to only company-managed and identified devices, where technically feasible and supported by the provider.

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.

Auditing Guidelines for AI Customers (AIC)

1. Verify the AIC’s vendor risk program requires that its AI providers use data centers with certified physical access controls.

2. Review evidence (e.g., provider security questionnaires) that the AIC has verified this requirement.

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.

Auditing Guidelines for AI Customers (AIC)

1. Verify the AIC’s procurement policy requires that AI providers host their services in facilities with industry-standard surveillance systems.

2. Check provider contracts or security documentation for attestations regarding physical surveillance.

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.

Auditing Guidelines for AI Customers (AIC)

1. Verify that the AIC requires its AI service providers to use CSPs that train their data center staff on adverse event response.

2. Check contracts for clauses requiring providers to notify the AIC of physical security incidents that could impact service or data.

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.

Auditing Guidelines for AI Customers (AIC)

1. Verify the AIC’s vendor risk policy requires that their AI providers use data centers with certified cabling security and infrastructure protection.

2. Review provider security documentation for information on physical infrastructure 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.

Auditing Guidelines for AI Customers (AIC)

1. Verify the AIC’s vendor management process includes checking that their AI providers use data centers with industry-standard environmental control systems.

2. Review contracts for SLAs related to service availability, which indirectly covers resilience to environmental issues.

DCS-15: Secure Utilities

Control Specification

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

Auditing Guidelines for AI Customers (AIC)

1. Verify the AIC’s vendor risk assessment process includes evaluating the utility redundancy and resilience of their AI service providers.

2. Check for uptime SLAs in service agreements, which should be backed by the provider’s secure utility infrastructure.

DCS-16: Equipment Location

Control Specification

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

Auditing Guidelines for AI Customers (AIC)

1. Verify the AIC’s vendor due diligence process assesses the geographic resilience of their AI service providers.

2. Review contracts for commitments from providers regarding data and service availability across different geographic regions.

DCS-17: Datacenter Metrics

Control Specification

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

Auditing Guidelines for AI Customers (AIC)

1. Verify that the AIC monitors service availability and performance indicators affecting AI-dependent business processes.

2. Confirm that provider-supplied service health and incident notifications are reviewed.

3. Verify that escalation and response procedures are defined for service disruptions.

4. Where customer-managed systems support AI integration, confirm monitoring of system availability and configuration state.

DCS-18: Datacenter Operations Resilience

Control Specification

Define, implement and evaluate processes, procedures and technical measures to ensure continuous operations.

Auditing Guidelines for AI Customers (AIC)

1. Verify that the AIC has continuity plans for business processes dependent on AI services.

2. Confirm that provider recovery commitments and escalation procedures are documented and understood.

3. Verify that contingency workflows exist for prolonged service disruptions.

4. Where customer-managed systems support AI integrations, confirm that backup and recovery controls are implemented and tested.

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.

Auditing Guidelines for AI Customers (AIC)

1. Examine the AIC’s policy and procedures related to data security and privacy.

2. Determine if a framework exists to ensure that the organization monitors the regulatory and legislative environment for changes applicable to the AIC’s data security and privacy policy and procedures. Confirm whether the organization has documented the roles and responsibilities that support its policy management.

3. Confirm whether the data security and privacy policy addresses the requirement that the organization’s data is used only for authorized purposes and in compliance with legislation and regulation.

4. Examine if the security and privacy policy and procedures are reviewed and updated annually.

5. Examine documentation to determine if the function responsible for data security and privacy compliance reviews the information to determine whether the organization complies with current legislation and regulations.

6. Determine if the AIC has a process for approving and communicating the classification, protection, preparation, and handling of data throughout its lifecycle.

7. Verify that the AIC has established due diligence procedures for evaluating service provider data handling practices and documented evidence of their compliance, including documented reviews of vendors’ SOC2, ISO 27001, or similar attestations, and evidence of contractual agreements (SLAs, DPAs) enforcing compliance.

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.

Auditing Guidelines for AI Customers (AIC)

1. Examine the AIC’s procedures and technical requirements related to the secure disposal of data from storage media. Establish that this process and key controls comply with the AIC’s data privacy and security policy. Establish whether the AIC has documented the roles and responsibilities for this process.

2. Select a sample of disposal requests (if available) and assess whether they have followed the process through to completion. Confirm that all evidence was formally documented and recorded.

3. Examine measure(s) that evaluate(s) this process and determine if the measure(s) address(es) implementation of the process/control requirement(s) as stipulated.

4. Obtain and examine supporting documentation maintained as evidence of these metrics to determine if the office or individual responsible reviews the information and if identified issues were investigated and corrected. Examine related records to determine if the individual or office conducted any follow-ups on the deviations to verify they were corrected as intended.

5. Verify that industry-accepted methods for secure data disposal are defined and implemented, ensuring data is not recoverable by any forensic means.

6. Verify that data disposal techniques include secure deletion, overwriting, and physical destruction of storage media.

7. Verify compliance with relevant data protection laws and organizational policies throughout the data disposal process.

8. Verify the effectiveness of technical measures such as certified data wiping tools and secure destruction methods.

9. Verify that contracts and agreements with all providers (MP, OSP, AP, CSP) include specific requirements for secure data disposal that align with industry standards and regulatory requirements.

10. Review evidence of due diligence in assessing providers’ data disposal capabilities before engagement and periodic compliance verification.

11. Assess internal procedures for securely disposing of AI-related data under the AIC’s direct control, including proper methods for different media types and data categories.

12. Verify that the AIC maintains an inventory of data assets that tracks disposal requirements, schedules, and completion status.

13. Examine how disposal requirements are communicated to relevant stakeholders and how the AIC validates that all parties have performed disposal correctly.

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.

Auditing Guidelines for AI Customers (AIC)

1. Examine the AIC’s procedures and technical requirements for the population and management of its data inventory. Establish that this process and key controls comply with the AIC’s data privacy and security policy. Establish whether the AIC has documented the roles and responsibilities for this process.

2. Select a sample of entries to ensure they have been recorded correctly on the inventory. The sample must include a proportion of sensitive and personal data entries.

3. Assess whether data inventory management meets the AIC’s expectations from the defined procedures and technical requirements.

4. Examine measure(s) that evaluate(s) this process and determine if the measure(s) address(es) implementation of the process/control requirement(s) as stipulated.

5. Verify that a comprehensive data inventory is created, including all sensitive and personal data.

6. Verify that data sources, types, usage, and ownership are identified and documented.

7. Verify that the data inventory is maintained and updated regularly to reflect changes in data assets and processing activities.

8. Verify compliance with relevant data protection laws (e.g., GDPR, CCPA) and organizational policies throughout the data inventory process.

9. Review processes for maintaining a complete view of data across the AI supply chain, including mechanisms to incorporate provider-supplied inventory information.

DSP-04: Data Classification

Control Specification

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

Auditing Guidelines for AI Customers (AIC)

1. Examine the AIC’s policy, procedures, and technical requirements for classifying data. Establish that this process and key controls comply with the AIC’s data privacy and security policy. Establish whether the AIC has documented the roles and responsibilities for this process.

2. Establish if the AIC’s data classification matrix is aligned with the AIC’s data classification requirements in terms of data type, criticality and sensitivity level.

3. Select a sample of data to confirm that each item has been classified appropriately.

4. Examine the measure(s) that evaluate this process and determine if they address the implementation of the process/control requirement(s) as stipulated. Verify that technical measures such as labeling, tagging, and access controls are used to enforce data classification.

5. Verify that data classification criteria are based on the AIC’s specific needs and regulatory requirements.

6. Verify that data classification processes include regular reviews and updates to reflect data types, criticality and sensitivity levels changes.

7. Verify that controls and handling requirements are clearly defined for each classification level and consistently implemented across the AI system lifecycle.

8. Review procedures for resolving classification conflicts or ambiguities, particularly at organizational boundaries or between classification schemes.

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.

Auditing Guidelines for AI Customers (AIC)

1. Examine the AIC’s procedures and technical requirements for data flow documentation, and ensure that a review is carried out at least annually and after any change. Establish that this process and key controls comply with the AIC’s data privacy and security policy. Establish whether the AIC has documented the roles and responsibilities for this process.

2. Select a sample of documents to check that they have been completed to the correct specifications and reviewed.

3. Review whether data flow documentation includes an assessment of the accuracy, completeness, timeliness, and sustainability of the data (flow).

4. Identify if data flow documentation includes how data is processed, stored, and transmitted.

5. Verify that data flow documentation is reviewed at defined intervals, at least annually, and after any significant changes to the data processing environment.

6. Verify compliance with relevant data protection laws and organizational policies throughout the data flow documentation process.

7. Verify that documentation identifies what data is processed, stored, or transmitted at each stage of the AI system lifecycle, with particular attention to sensitive or regulated data types.

8. Review how the documentation integrates provider-specific data flow information into a cohesive view that enables tracing data from collection through processing, analysis, and eventual disposition.

9. Assess whether documentation identifies organizational boundaries and handoff points where data moves between different entities or jurisdictions.

10. Verify that documentation is reviewed at defined intervals (at least annually) and updated whenever changes occur to internal systems, provider relationships, or data processing activities.

11. Examine specific examples of documentation updates following significant changes, such as new providers, modified data uses, or system architecture revisions, confirming that updates accurately reflect the current environment.

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.

Auditing Guidelines for AI Customers (AIC)

1. Examine the AIC’s personal and sensitive data ownership and stewardship process. Determine if the documentation defines roles and responsibilities. Establish that this process and key controls comply with the AIC’s data privacy and security policy. Establish whether the AIC has documented the roles and responsibilities for this process.

2. Establish that the AIC maintains a source(s) of record of data owners and stewards and the records for which they are responsible. This must include personal and sensitive data.

3. In the absence of a documented procedure, interview the control owner(s) responsible for key staff involved in the process and/or other relevant stakeholders impacted by the process/control requirement(s) and determine if the requirement(s) is/are understood. Evidence may be provided by observing individuals, systems, and/or processes associated with data management to determine if the process requirements are generally understood and implemented consistently.

4. Examine if the documentation is reviewed on an annual basis.

5. Verify that a data responsibility matrix detailing data types, associated obligations, and responsible persons or roles has been created.

6. Verify that the AIC maintains a source of record for data owners and the records for which they are responsible.

7. Verify that documentation defines enterprise data governance roles, including data owners, stewards, custodians, and privacy officers, with clear delineation of responsibilities for each role.

8. Review how responsibility transfers are documented when data moves between internal teams or to external providers, ensuring continuous accountability throughout the data lifecycle.

9. Assess whether documentation addresses ownership and stewardship requirements in contracts and agreements with all service providers, including specific responsibilities assigned to each provider.

10. Verify that documentation includes validation procedures to ensure providers fulfill their documented stewardship responsibilities for personal and sensitive data.

11. Confirm that comprehensive ownership and stewardship documentation is reviewed at least annually and updated when organizational structures, provider relationships, or data processing activities change.

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.

Auditing Guidelines for AI Customers (AIC)

1. Examine whether the AIC’s policy, standards, and procedures create a framework that fosters a culture and expectation of data protection by design and default.

2. Establish whether the AIC has documented the roles and responsibilities involved.

3. Review the AIC’s data breaches log, security incidents log, and project change failure records for examples of this requirement not being followed correctly. Further, confirm that action plans were identified and carried out.

4. Verify that security controls are embedded at every stage of the system development lifecycle.

5. Verify the effectiveness of technical measures such as secure coding practices, encryption, and access controls.

6. Verify that regular assessments and audits are conducted to evaluate the effectiveness of security measures and identify potential risks.

7. Verify that all processes, procedures, and technical measures related to security by design are thoroughly documented and regularly updated to reflect changes in industry best practices and regulations.

8. Examine enterprise security architecture to verify that security-by-design principles are incorporated into overarching AI strategy and governance, establishing security requirements before system development begins.

9. Verify that procurement and vendor selection processes include security-by-design criteria, requiring evidence that providers have incorporated security from inception rather than as an add-on.

10. Review the internal systems development methodology and confirm that it includes defining security requirements, threat modeling, security architecture reviews, and security testing throughout the development lifecycle.

11. Assess the AIC’s security standards and best practices documentation, verifying its comprehensive guidance for security-by-design implementation across the AI ecosystem.

12. Evaluate how security considerations are incorporated into business processes involving AI systems, including security reviews of process designs and implementation of security controls in process workflows.

13. Verify that the organization has established a governance framework that emphasizes and enforces security-by-design principles across all AI initiatives and provider relationships.

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.

Auditing Guidelines for AI Customers (AIC)

1. Examine whether the AIC’s policy, standards, and procedures create a framework that fosters a culture and expectation of privacy by design. Determine whether this content addresses the directive of the AIC’s culture and whether practices reflect privacy by design and industry best practices.

2. Examine whether the AIC’s governance framework, documents, controls, and metrics satisfy the AIC, and if its sub-processors comply with this requirement. Establish whether the AIC has documented the roles and responsibilities involved.

3. Obtain and examine supporting documentation maintained as evidence of these metrics to determine if the office or individual responsible reviews the information, and if identified issues were investigated and remediated appropriately.

4. Obtain evidence of the systems’ privacy settings and the laws and regulations that apply to the AIC. Determine if the configurations are implemented as defined by the applicable laws and regulations.

5. Verify that processes, systems, and applications used for the collection and processing (including use, disclosure, retention, transmission, and disposal) are limited to what is necessary for the identified purpose.

6. Verify that the AIC limits data collection to the minimum necessary for the identified purposes.

7. Verify that the AIC limits the data processing to what is accurate, adequate, relevant, and necessary for the identified purposes.

8. Verify that the AIC defines and documents data minimization objectives and uses mechanisms (such as de-identification) to meet those objectives.

9. Verify that the AIC either deletes or renders data in a form that does not permit identification when it no longer requires access to identifiable forms of data unless there is a legal requirement or business justification to retain it in identifiable form.

10. Verify that the AIC ensures that temporary files created during data processing are deleted (e.g., erased or destroyed) following documented procedures within a specified, documented time frame.

11. Verify that the AIC does not retain data for longer than necessary for the purposes for which it was processed.

12. Verify that the AIC follows documented policies, procedures, and/or mechanisms when disposing of data.

13. Verify that the AIC subjects data (e.g., sent to another organization) over a data-transmission network to appropriate controls to ensure data reaches its intended destination.

14. Verify that procurement and vendor selection processes include privacy assessment by design implementation and privacy-protective defaults as mandatory evaluation criteria.

15. Review how the AIC defines default privacy configurations for AI systems, confirming they align with applicable laws and regulations and reflect the most privacy-protective settings appropriate for intended use cases.

16. Assess how privacy impact assessments are integrated into design processes, verifying they are conducted early enough to influence design decisions and identify privacy risks before implementation.

17. Verify that the AIC maintains current knowledge of privacy regulations across relevant jurisdictions and translates regulatory requirements into specific default configuration standards for AI systems.

18. Examine how the AIC validates that both internal systems and external providers implement privacy by design principles and configure privacy-protective defaults following established requirements.

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.

Auditing Guidelines for AI Customers (AIC)

1. Examine procedures related to DPIA risk assessment and determine whether, once a requirement has been established, the AIC identifies and grades the associated risks, reports, and prioritizes the remediation of risks and non-compliance activities.

2. Examine whether the DPIA process and templates align with the AIC’s risk methodology and taxonomy.

3. Determine if the risks’ origin, nature, particularity, and severity are evaluated according to the applicable laws, regulations, and industry best practices for the AIC.

4. Establish whether the AIC has documented the roles and responsibilities for this process.

5. Select a sample of DPIAs and examine evidence to confirm that each assessment was performed to identify associated risks. Further, verify that any action plans were determined and carried out appropriately. Confirm that all relevant evidence was formally documented.

6. Verify that AI systems used in PII processing are included in the DPIA evaluation process.

7. Verify identification and assessment of risks specific to AI systems, such as bias, transparency, and accountability.

8. Verify that the DPIA includes evaluating profiling based on AI systems’ data.

9. Verify that records inform the DPIA process for AI systems and are kept up-to-date.

10. Assess whether the AIC verifies upstream providers (MP, OSP, AP) have conducted appropriate DPIAs for their components.

11. Verify that the AIC maintains documentation of all DPIAs, including those inherited from providers.

12. Examine whether DPIA findings are incorporated into contractual requirements with providers and internal risk management processes.

13. Confirm that DPIAs are updated when the AI system’s purpose, scope, context, or processing operations change significantly.

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.

Auditing Guidelines for AI Customers (AIC)

1. Examine the AIC’s procedures and technical requirements for securing and legally transferring personal and sensitive data. Establish that this process and key controls comply with the AIC’s data privacy and security policy.

2. Establish whether the AIC has documented the roles and responsibilities for this process.

3. Select a range of personal and sensitive data transfers to confirm that each transfer adhered to the AIC’s policy, procedures, and controls. Confirm that all relevant evidence was formally documented.

4. Obtain a sample of the technical measures implemented by the AIC to determine if those measures adhere to the AIC’s data privacy and security policy.

5. Verify that data transfers are protected from unauthorized access using encryption, secure communication channels, and access controls.

6. Verify compliance with relevant data protection laws (e.g., GDPR, CCPA) and organizational policies throughout the data transfer and processing activities.

7. Verify that regular assessments and audits are conducted to evaluate the effectiveness of data transfer and processing measures and identify potential risks.

8. Verify that all processes, procedures, and technical measures related to data transfer and processing are thoroughly documented and regularly updated to reflect changes in laws and regulations.

9. Verify contractual requirements with all providers explicitly address data transfer protections and limitations.

10. Review data transfer compliance documentation for all applicable regulations relevant to the AIC’s jurisdictions.

11. Assess oversight mechanisms for monitoring sensitive data transfers across organizational and provider boundaries.

12. Evaluate the completeness of the sensitive data transfer inventory and associated risk assessments.

13. Verify validation processes that confirm data transfer protections are functioning as intended.

14. Review incident response procedures specifically addressing sensitive data transfer breaches.

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.

Auditing Guidelines for AI Customers (AIC)

1. Examine whether the AIC’s policy and procedures related to data privacy address the requirement that authorized users must be able to access, modify, or delete personal data, and whether it is handled according to the applicable laws and regulations.

2. Establish whether the AIC has processes to manage and respond to data access requests from data subjects and whether it has documented the roles and responsibilities for this process.

3. Select a range of data changes to confirm that only authorized users can access, modify, and delete personal data successfully. Select a sample of data access requests to establish that these were completed correctly following the AIC’s processes. Confirm that all relevant evidence was formally documented.

4. Verify that data subjects are informed about their rights and the procedures to exercise them.

5. Verify that contracts with all providers explicitly address obligations for fulfilling data subject rights.

6. Review coordination processes for managing multiple provider and component requests.

7. Assess documentation maintained for all request handling, including evidence of fulfillment.

8. Verify compliance with applicable laws and regulatory timeframes for responding to requests.

9. Examine how the AIC addresses technically challenging aspects of data subject rights in AI systems.

10. Review how the effectiveness of data subject rights fulfillment is validated across the entire implementation.

11. Assess staff training on handling data subject requests.

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.

Auditing Guidelines for AI Customers (AIC)

1. Examine whether the AIC’s policy and procedures related to data privacy address the requirement that data the AIC is responsible for is processed lawfully and used only for the purposes stated to data subjects.

2. Establish whether the AIC has documented the roles and responsibilities for this process.

3. Review the AIC’s data breaches and confirm that action plans were identified and carried out appropriately. Confirm that all supporting evidence was formally documented.

4. Review the AIC’s processes that inform data subjects why it requests this data and what it will be used for. Confirm that any AIC documentation (including web page content) is subject to formal periodic review for relevance and compliance with legislation and regulation.

5. Review the technical measures implemented to ensure that personal data is processed according to applicable laws and regulations.

6. Verify that the purposes for processing personal data are declared and documented to the data subject.

7. Verify the effectiveness of technical measures such as encryption, access controls, and data anonymization used during data processing.

8. Verify that all processes, procedures, and technical measures related to data processing are thoroughly documented and regularly updated to reflect changes in laws and regulations.

9. Verify that contracts with all providers explicitly document purpose limitations for personal data.

10. Review documentation of legal bases for processing mapped to specific declared purposes.

11. Assess oversight mechanisms for verifying ongoing adherence to declared purposes across the AI implementation.

12. Evaluate processes for conducting purpose compatibility assessments before expanding data use.

13. Verify procedures for ensuring that processing purposes declared to data subjects remain accurate and complete.

14. Review audit processes that regularly validate actual processing against declared purposes.

15. Assess documentation of purpose limitation safeguards in data protection impact assessments.

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.

Auditing Guidelines for AI Customers (AIC)

1. Examine the AIC’s contractual terms, procedures, roles, responsibilities, documents, and technical measures for transferring personal data and sensitive data to subprocessors and how subprocessors are to treat this data.

2. Establish whether the AIC has documented the roles and responsibilities for this process.

3. Select a sample of data transfers to subprocessors to establish that the controls and reporting of the subprocessors comply with the AIC’s data privacy and security policy.

4. Examine the AIC’s contractual requirements for subprocessor compliance, reporting, and non-compliance sanctions and the AIC’s right to audit. Establish subprocessors’ processes, controls, and metrics to comply with the organization’s requirements.

5. Verify that contracts with suppliers and sub-processors include clauses that comply with applicable laws and regulations regarding the transfer and sub-processing of personal data.

6. Verify the effectiveness of technical measures such as encryption, secure communication channels, and data masking used during data transfer and sub-processing.

7. Verify that regular assessments and audits are conducted to evaluate the effectiveness of data transfer and sub-processing measures and identify potential risks.

8. Verify that all processes, procedures, and technical measures related to data transfer and sub-processing are thoroughly documented and regularly updated to reflect changes in laws and regulations.

9. Verify the existence and comprehensiveness of the AIC’s sub-processor inventory covering all providers in their AI supply chain.

10. Review the due diligence process for evaluating providers’ sub-processor management practices before engagement.

11. Verify that the AIC has established clear procedures for reviewing and approving changes to sub-processors proposed by their service providers.

12. Examine evidence of regular compliance verification of providers’ sub-processing activities against regulatory requirements and organizational policies.

13. Review the AIC’s documented processes for responding to data subject rights requests that involve sub-processors throughout their supply chain.

14. Assess the AIC’s data protection impact assessments for high-risk processing activities that involve sub-processors.

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.

Auditing Guidelines for AI Customers (AIC)

1. Policies, Roles, and Contracts: Examine the AIC’s documented policies, procedures, and contractual requirements to ensure that upstream providers and the AIC’s own subcontractors disclose all sub-processors before processing begins. Verify that roles and responsibilities for managing these disclosures and approvals are documented and assigned. Review contracts with third parties to confirm they: include provisions for handling PII legally and ethically, require equivalent privacy/security standards, mandate disclosure of subcontractors, and enforce data minimization principles limiting disclosure to the minimum necessary.

2. Sample-Based Validation: Select a sample of data transfers to providers/subcontractors and validate that disclosures were made before processing and records align with the AIC’s policies.

3. Disclosure Records and Record-Keeping: Verify the existence and maintenance of a master inventory of all sub-processors throughout the AIC’s AI supply chain, detailing what personal/sensitive data each accesses and for what purpose. Check that records of disclosures include: what was disclosed, when, to whom, under what authority, and approvals or objections recorded. Ensure disclosures are documented as having occurred before processing began.

4. Customer Notification and Legal Requests: Confirm the AIC has a documented process to: notify customers/data subjects of any legally binding disclosure requests, reject non-legally binding requests unless the customer consents, assess and respond to scenarios where disclosed sub-processors present unacceptable risk or compliance concerns, and ensure notifications are timely and consistent with applicable legal constraints.

5. Oversight of Upstream Provider Disclosures: Review due diligence procedures for evaluating upstream providers’ sub-processor disclosure practices before engagement. Assess the AIC’s process for reviewing and approving or objecting to providers’ sub-processors. Examine how the AIC incorporates upstream sub-processor information into its own privacy notices and disclosures to data subjects.

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.

Auditing Guidelines for AI Customers (AIC)

1. Verify that organizational policies define procedures and technical safeguards for replicating production data into dev, test, or evaluation environments involving GenAI.

2. Verify if formal approval processes exist and are followed before using production data in model evaluation, pilot programs, or vendor testing.

3. Verify if data used in non-production AI workloads is anonymized, obfuscated, and protected according to internal security and privacy standards.

4. Verify if deviations from internal policies (e.g., vendor exceptions, proof-of-concept waivers) are reviewed and approved.

5. Verify if procedures for managing production data across environments are updated regularly to reflect legal, compliance, and organizational policy changes.

6. Verify if training and awareness programs are in place for employees and stakeholders working with GenAI tools to understand risks and handling requirements for production data.

DSP-16: Data Retention and Deletion

Control Specification

Data retention, archiving and deletion is managed in accordance with business requirements, applicable laws and regulations.

Auditing Guidelines for AI Customers (AIC)

1. Verify if enterprise policies and procedures define retention, archiving, and deletion practices for AI-related and non-AI data, including governance responsibilities.

2. Verify if all internal data sources, ownership, and data retention periods are documented in line with laws and internal risk management frameworks.

3. Verify if data under AI processing (e.g., training, inferencing) is retained or deleted as defined by internal retention schedules.

4. Verify if contractual agreements with cloud vendors, model providers, or SaaS AI solutions include data retention clauses.

5. Verify if production data used in AI workflows is deleted using secure, verifiable deletion processes after its lifecycle ends.

6. Verify if user/system actions related to retention and deletion are logged, monitored, and reviewed by internal audit or compliance teams.

7. Verify if sensitive business or personal data is protected during its retention period with strong access controls and encryption.

8. Verify if data retention procedures are regularly reviewed in light of regulatory, legal, or operational changes.

9. Verify if AI data policies explicitly cover model inputs, outputs, training logs, and prompt history.

10. Verify if AI deployment configurations avoid unnecessary retention of PII or sensitive business data.

11. Verify if data used in model training or application prompts is anonymized or de-identified.

12. Verify if access to AI-related datasets and logs is governed by role-based policies and monitoring.

13. Verify if processes exist for timely, secure deletion of AI data used for experimentation or testing.

14. Verify if periodic audits are conducted to ensure end-to-end compliance with AI data retention policies.

DSP-17: Sensitive Data Protection

Control Specification

Define and implement, processes, procedures and technical measures to protect sensitive data throughout its lifecycle.

Auditing Guidelines for AI Customers (AIC)

1. Verify whether the organization’s internal policies on AI usage include data privacy guidelines for managing sensitive data consumed by GenAI systems, including vendor solutions and internal pilots.

2. Verify whether roles and responsibilities for managing data privacy risks in AI procurement, integration, and usage are clearly assigned (e.g., IT, legal, compliance).

3. Verify that data classification and handling policies account for data sent to or processed by third-party AI tools; check adherence to contractual and legal obligations; validate audits of tools; interview responsible staff; and confirm that controls are reviewed periodically.

4. Verify that controls are in place across the lifecycle of data shared with GenAI vendors or used in internal GenAI deployments, from input to storage and retention.

5. Verify whether the organization has documented incidents where GenAI tools may have exposed sensitive data, and whether follow-up actions were taken and logged.

6. Verify that enterprise AI risk management practices include evaluations of vendor AI tools for bias, explainability, and privacy risks before deployment.

7. Verify that incident management procedures for GenAI tools include privacy incident reporting, escalation, and follow-up with vendors or internal teams.

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.

Auditing Guidelines for AI Customers (AIC)

1. Verify if enterprise policies define how law enforcement requests for personal data, including that processed by AI, will be handled.

2. Verify if these procedures align with the organization’s broader privacy, security, and legal compliance policies.

3. Verify if roles and responsibilities for receiving, escalating, and responding to law enforcement disclosures are defined.

4. Verify if legal or compliance teams use secure communication and approval channels for disclosure processes.

5. Verify that requests, decisions, approvals, and external communications are all formally recorded.

6. Verify that the organization meets applicable legal and contractual timelines for disclosure responses.

7. Verify if procedures for law enforcement requests are regularly reviewed to reflect regulatory and operational updates.

8. Verify if employee training includes how to recognize and respond to legal data requests, especially in AI workflows.

9. Verify if logs are maintained for tracking law enforcement requests and the data provided in response.

10. Verify if the enterprise has processes for flagging and correcting unauthorized or inappropriate disclosures.

11. Verify if AI-related disclosures (e.g., generated outputs or inference data) are addressed explicitly in legal request handling.

12. Verify if technical controls restrict internal and external access to AI-generated data under legal review.

13. Verify if internal audits or compliance teams monitor and verify the handling of AI-related law enforcement requests.

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.

Auditing Guidelines for AI Customers (AIC)

1. Verify organizational policies and procedures define physical storage requirements and ethical use standards for data processed by AI tools and services they consume.

2. Verify documentation of roles and responsibilities for managing AI system data storage and ethical compliance within the customer organization.

3. Verify policies ensure compliance with regional data residency and jurisdictional requirements related to AI data storage and processing.

4. Verify maintenance of reliable records for physical storage locations of data processed by AI vendors and internal AI systems, including traceability.

5. Verify accuracy and completeness of these records in accordance with policy requirements.

6. Verify that the customers’ and suppliers’ obligations regarding AI data storage systems are clearly documented.

7. Verify that AI tools and services used by the customer comply with organizational ethical standards and data storage policies.

8. Verify monitoring and auditing procedures exist to ensure ongoing compliance of AI data storage with privacy, security, and ethical requirements.

9. Verify risk management strategies address bias mitigation, transparency, and other ethical considerations relevant to AI data storage and processing.

10. Verify that incident response processes are in place for AI data storage and processing issues, including vendor coordination, reporting, investigation, and remediation.

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

Auditing Guidelines for AI Customers (AIC)

1. Verify that all external and internal data sources used in AI deployments are identified and documented, including type and purpose.

2. Verify that lineage records show how data moves through the AI lifecycle within the organization.

3. Verify that data dictionaries exist for enterprise datasets used in AI, including field definitions and relationships.

4. Verify that provenance records are maintained for any data transformation, enrichment, or synthetic data generation performed.

5. Verify that access and modification of AI-related data are tracked by automated monitoring systems.

6. Verify that methods (e.g., data quality checks, audit logs) are implemented to ensure data integrity throughout AI pipelines.

7. Verify that the organization has strategies for managing the scale, privacy risk, and complexity of AI training and inference data.

8. Verify that data management practices follow applicable legal and contractual obligations (e.g., data minimization, retention).

9. Verify that access controls and encryption are enforced on AI data used by internal teams and third-party tools.

10. Verify that retention policies are applied to AI data and that deletion is performed securely and promptly.

11. Verify that staff are trained on managing AI-related data in line with data governance, privacy, and security requirements.

12. Verify that metadata (e.g., timestamps, data source IDs) showing origin and handling of AI data can be produced when needed.

13. Verify that versioning is applied to datasets, model configurations, and inference logs.

14. Verify that a documented, auditable process exists for disclosing AI-related data to legal authorities or regulators when required.

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.

Auditing Guidelines for AI Customers (AIC)

1. Verify that data sources provided to or used in AI systems are validated to prevent malicious or poisoned data from entering the AI environment.

2. Verify that data quality assurance processes are implemented to identify and remove corrupted or suspicious data before it is consumed by AI systems.

3. Verify that automated monitoring tools are deployed to detect unusual or anomalous data patterns that may indicate poisoning attempts.

4. Verify that organizations adopt training or mitigation techniques to improve resilience to poisoned data in AI consumption scenarios.

5. Verify that access controls prevent unauthorized modification or insertion of data used in AI tools or services.

6. Verify that data encryption is in place to protect sensitive data from unauthorized access or tampering throughout the AI data lifecycle.

7. Verify that monitoring systems are configured to detect tampering or poisoning attempts on data used by AI tools.

8. Verify that incident response plans cover data poisoning threats, including detection, reporting, and remediation steps relevant to the customer environment.

9. Verify that employees using or managing AI tools are trained to recognize potential data poisoning threats.

10. Verify that automated tools are leveraged to continuously monitor data integrity and identify anomalies in data consumed or produced by AI systems.

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.

Auditing Guidelines for AI Customers (AIC)

1. Verify business use cases before the configuration and implementation of PETs such as differential privacy and federated learning for training data are clearly defined and documented.

2. Verify continuous monitoring and evaluation of PETs to keep them effective and to address risks.

3. Verify PETs comply to privacy standards and regulations.

4. Verify metrics and KPIs are defined, monitored and reported to measure PET effectiveness.

5. Verify employees and contractors are trained on how to use and monitor PETs.

6. Verify PETs are updated with the latest security patches.

7. Verify if logs from PETs are reviewed and monitored to identify unusual activities or breaches.

8. Verify periodic independent third-party penetration testing are performed to review and assess PETs for potential vulnerabilities.1.

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.

Auditing Guidelines for AI Customers (AIC)

1. Verify that all data sources used by the customer’s AI systems or consumed from vendors are identified and traceable.

2. Verify that logging and tracking systems capture any changes or updates to data used in AI services.

3. Verify that automated monitoring tools are used to continuously check data integrity and detect anomalies in customer data.

4. Verify that access controls restrict unauthorized modifications to data within the customer environment.

5. Verify that sensitive data handled or stored by the customer is encrypted to protect against unauthorized access.

6. Verify that version control mechanisms track changes to datasets and AI models used or deployed by the customer.

7. Verify that employees are trained on best practices for data integrity and handling in the context of AI systems.

8. Verify that procedures exist for identifying and addressing data integrity issues encountered by the customer.

DSP-24: Data Differentiation and Relevance

Control Specification

Ensure training-data differentiation and relevance to the intended use of the AI Model.

Auditing Guidelines for AI Customers (AIC)

1. Verify if clear and accessible information about AI systems they consume is provided to customers and relevant stakeholders.

2. Verify if AI solutions used by customers comply with applicable privacy regulations and governance standards.

3. Verify if customers gather feedback from diverse stakeholders and use it to improve their AI deployments.

4. Verify customers adhere to data governance policies and relevant privacy regulations in their AI use.

5. Verify customers have mechanisms to protect sensitive data and maintain data integrity in AI use.

6. Verify customers monitor AI system performance and relevance, collecting feedback to address issues and improve usage.

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.

Auditing Guidelines for AI Customers (AIC)

1. Examine whether the organization has established a comprehensive strategy for information governance that includes leadership sponsorship and addresses the responsible adoption, oversight, and use of AI systems. Assess whether internal policies, standards, and procedures reflect ethical guidelines, regulatory requirements, and expectations for managing third-party or vendor-provided AI services.

2. Confirm that policies, standards, and procedures are reviewed and updated at least annually, with documented evidence of the review process, leadership approval, and modifications made in response to evolving AI-related governance requirements, regulatory changes, or vendor AI service modifications.

3. Verify that governance policies require reviewing vendor-provided evidence of compliance with applicable requirements (e.g., user consent management, identity safeguards) before adopting or integrating AI services.

4. Confirm that policy updates include responsibilities for monitoring vendor compliance with governance requirements (e.g., data protection, transparency, consent handling), and that evidence of these reviews is maintained in customer governance records.

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.

Auditing Guidelines for AI Customers (AIC)

1. Program Examination

   • a. Verify that a formal, documented AI Risk Management (AIRM) program exists and has been approved by executive leadership.

   • b. Confirm that the AIRM program includes defined roles and responsibilities for managing risks related to the selection, integration, and use of external or third-party AI services, including those acquired through cloud-based platforms.

2. Program Content Assessment

   • a. Verify that the AIRM program includes procedures for identifying, evaluating, assigning ownership of, treating, and accepting risks related to vendor-provided AI systems, including data privacy, model transparency, and operational risks introduced by third-party providers.

   • b. Confirm whether the AIRM framework includes documented consideration of risks such as vendor model misuse, lack of explainability, data residency issues, service disruptions, or over-reliance on black-box models. If not, assess whether a rationale and alternative mitigation strategy exist.

   • c. Confirm that the AIRM program includes the identification and assessment of risks introduced through reliance on cloud-based AI service providers, especially those involving sensitive or regulated data.

   • d. Verify that risk ownership for externally sourced AI services is clearly defined, including roles responsible for evaluating and managing third-party oversight, vendor risk management, and incident response related to AI usage.

3. Program Alignment Evaluation

   • a. Evaluate whether the AIRM program aligns with the organization’s broader AI governance framework and enterprise risk strategy for externally-sourced and vendor-integrated AI technologies.

   • b. Regulatory and Standards Alignment: Confirm whether the AIRM program includes controls for meeting legal, regulatory, or contractual obligations associated with the use of third-party AI adoption, including those related to data protection, model usage transparency, and ethical considerations.

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.

Auditing Guidelines for AI Customers (AIC)

1. Policy Examination

   • a. Verify that the organization maintains a documented inventory of internal policies and procedures relevant to the adoption, integration, and oversight of third-party AI services, including those supported by cloud-based infrastructure.

   • b. Confirm that the organization has identified which policies are “relevant” to AI system use of vendor-provided AI systems, including those covering procurement, vendor risk management, data handling, and responsible AI use.

2. Policy Assessment

   • a. Verify that relevant policies and procedures are reviewed at least annually, with evidence of documented approvals, version tracking, and formal review schedules.

   • b. Confirm that policy reviews are conducted by accountable stakeholders (e.g., vendor management, legal, compliance, or IT governance) and that updates are governed by formal review procedures.

3. Review Process Evaluation

   • a. Determine whether the organization has criteria for identifying “substantial changes” that require interim policy reviews (e.g., onboarding of a new AI vendor, updated contract terms, or changes to regulatory obligations).

   • b. Verify that the organization has a documented process for initiating reviews of affected policies and procedures following such substantial changes.

4. Implementation Validation

   • a. Review policy review logs or approval records to confirm that AI usage–related policies (e.g., acceptable use, data privacy, and vendor oversight) are being reviewed on at least an annual basis.

   • b. Examine recent changes in third-party AI vendor relationships, integrations, or legal requirements and validate that the organization conducted timely reviews of the associated policies.

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.

Auditing Guidelines for AI Customers (AIC)

1. Policy Examination

   • a. Verify that a formal, documented exception process exists for deviations from internal policies governing the acquisition, use, integration, or oversight of third-party AI services and associated cloud-based technologies.

   • b. Confirm that the exception process is formally included in or referenced by the organization’s governance program, policy management procedures, or risk frameworks specific to third-party AI adoption, vendor oversight, or ethical/responsible AI use.

2. Policy Assessment

   • a. Verify that the exception process includes required elements such as rationale for the exception, approval roles, expiration or review timelines, and documentation standards.

   • b. Confirm that the process applies to all policy deviations, including those that may involve adoption of unapproved AI tools, bypassing responsible AI review requirements, skipping vendor onboarding steps, or modifying contractual terms related to AI usage.

   • c. Assess whether approved exceptions are shared with responsible stakeholders (e.g., vendor management, legal, procurement, security) and logged in a central exception tracking system.

3. Review Process Evaluation

   • a. Determine whether the organization has controls in place to flag or prevent unauthorized deviations from third-party AI service governance processes, such as vendor onboarding workflows, integration risk assessments, or responsible AI approval gates.

   • b. Confirm that a responsible oversight function (e.g., risk committee, vendor governance group, or AI usage board) periodically reviews exceptions granted under this process.

4. Implementation Validation

   • a. Review a sample of approved exceptions related to third-party AI service policies or cloud integration requirements and validate compliance with approval, justification, and expiration protocols. Examples may included accelerated vendor onboarding, bypassed explainability assessments, or modified data usage terms.

   • b. Examine a sample of recent third-party AI vendor changes, usage deviations, or integration decisions and verify that the exception process was followed where required.

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.

Auditing Guidelines for AI Customers (AIC)

1. Program Documentation and Scope: Verify that the organization maintains a documented Information Security Program that addresses its overall technology and data security risks. Where the organization consumes external AI services or models (e.g., through APIs, platforms, or cloud integrations), confirm that the program reflects those AI-related risks and includes coverage of applicable AICM domains (e.g., Data Protection, Third-Party Risk, Infrastructure).

2. Coverage of Third-Party and AI Consumption Risks: Assess whether the security program includes controls for areas relevant to AI consumption, such as secure vendor onboarding, access management, data usage governance, and third-party service risk evaluation. Confirm that responsibilities for securing AI-related services are clearly defined and assigned to appropriate roles (e.g., IT security, procurement, risk management), and that oversight structures are in place. Ensure the program aligns with internal policies and any applicable regulatory, contractual, or cloud provider requirements related to AI service usage.

3. Domain Relevance and Organizational Coverage: Determine whether the organization has evaluated which AICM domains are relevant to its role as an AI consumer and integrated those domains into its security program. Confirm that security controls are applied across relevant business and technical functions (e.g., vendor management, legal, IT operations), rather than being siloed in a single team.

4. Implementation and Evidence Validation: Review internal documentation, such as risk assessments, training records, audit logs, or internal compliance reports, to validate that the Information Security Program is actively implemented across the AICM domains in scope. Select a sample of relevant domains (e.g., Vendor Risk, Data Privacy, Access Management) and confirm that corresponding controls are documented, implemented, and operating effectively.

GRC-06: Governance Responsibility Model

Control Specification

Define and document roles and responsibilities for planning, implementing, operating, assessing, and improving governance programs.

Auditing Guidelines for AI Customers (AIC)

1. Policy Examination

   • a. Verify that roles and responsibilities related to the governance of AI consumption, including third-party AI use, vendor onboarding, integration, and compliance oversight are formally defined in organizational documentation.

   • b. Confirm that these responsibilities span all stages of the governance lifecycle (planning, implementation, operation, assessment, and improvement),as they relate to procurement, use, and monitoring of external AI service use.

2. Policy Assessment

   • a. Assess whether responsibilities for managing AI-related vendor risk, usage monitoring, and contractual compliance are clearly assigned and documented, with defined accountability for key governance checkpoints.

   • b. Confirm that the documented roles span across relevant stakeholders, such as procurement, legal, IT security, compliance, and the business units using AI capabilities, and that coordination mechanisms are in place.

3. Program Evaluation

   • a. Determine whether governance responsibilities are reflected in operational practices such as vendor selection, onboarding processes, service usage reviews, and contract updates, including controls related to third-party risk assessments.

   • b. Verify that assigned roles include clear escalation paths and are tied into broader risk or compliance oversight functions that monitor AI usage across the organization, especially where sensitive data, decision-making, or regulatory exposure is involved.

4. Implementation Validation

   • a. Review records such as meeting minutes, vendor review documentation, issue logs, or internal assurance results (e.g., audit reports, compliance reviews) to validate that responsibilities are being carried out.

   • b. Select a governance-related function (e.g., exception handling for AI use, third-party compliance tracking) and confirm that the role responsible for oversight is performing its duties as defined, with traceable outcomes and documented decisions.

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.

Auditing Guidelines for AI Customers (AIC)

1. Policy Examination

   • a. Requirements Inventory: Verify that the organization maintains a documented inventory of regulatory, contractual, and legal obligations related to the acquisition, integration, and use of third-party AI systems and cloud-based services.

   • b. Source Identification: Confirm that the inventory includes applicable sources such as vendor contracts, data processing agreements, privacy regulations, industry compliance standards, and internal AI usage policies.

2. Policy Assessment

   • a. Review and Update Process: Assess whether the requirements inventory is reviewed and updated periodically or when material business or regulatory changes occur, and whether a responsible function (e.g., compliance, legal, vendor management) is designated.

   • b. Usage Scope Relevance: Confirm that documented requirements reflect the organization’s AI usage profile, such as regional deployment, customer-specific obligations, and industry-specific mandates.

3. Program Evaluation

   • a. Requirements Integration: Determine whether listed requirements are considered in key decision-making processes, such as vendor selection, procurement reviews, service integration design, and internal risk assessments.

   • b. Governance Visibility: Confirm that stakeholders across compliance, procurement, security, and business units reference the documented requirements in their workflows or decision approvals.

4. Implementation Validation

   • a. Evidence of Use: Review artifacts such as vendor review documentation, internal AI usage checklists, or contract templates to confirm that listed requirements are referenced in decision-making or governance workflows.

   • b. Sample Requirements Validation: Select a sample of obligations (e.g., contractual transparency terms, customer-driven compliance expectations) and verify that supporting records show these were factored into onboarding or oversight processes.

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.

Auditing Guidelines for AI Customers (AIC)

1. Policy Examination Engagement Strategy: Verify whether the organization has a policy, guideline, or governance expectation that promotes awareness and engagement with external groups relevant to third-party AI usage, procurement, cloud compliance, or AI governance. Defined Purpose: Confirm that the purpose of such engagement is documented and reflects the organization’s reliance on external AI systems and services (e.g., vendor transparency, regulatory trends, compliance alignment).

2. Policy Assessment Group Relevance: Assess whether the organization participates in or monitors groups relevant to AI consumers (e.g., data privacy alliances, third-party risk councils, AI compliance networks, or regulatory briefings). Responsibility Assignment: Verify that responsibility for participation is assigned to appropriate functions (e.g., vendor risk, legal, IT governance, procurement), and that it is documented in governance roles or meeting records.

3. Program Evaluation Engagement Mechanism: Determine whether a process exists to identify, evaluate, or prioritize external organizations or groups based on relevance to the organization’s AI vendor landscape and cloud service dependencies. Information Flow: Confirm that insights gained from external collaboration (e.g., legal updates, AI standards development, vendor risk practices) are shared internally and used to inform governance or procurement decisions.

4. Implementation Validation Evidence of Participation: Review records such as industry newsletter subscriptions, meeting attendance, vendor briefing notes, or compliance meeting minutes to confirm engagement with relevant external groups. Sample Group Validation: Select a sample of groups (e.g., cloud compliance forums, privacy roundtables, CSA AI initiatives) and verify that their relevance is aligned with the AIC’s role and that engagement supports internal governance objectives.

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.

Auditing Guidelines for AI Customers (AIC)

1. Examine the AI Acceptable Use Policy for adequacy, currency, and communication to relevant interested parties, including cloud service customers.

2. Verify that the AI Acceptable Use Policy identifies the applicable cloud services subject to these guidelines.

3. Verify that the AI Acceptable Use Policy clearly defines the acceptable and prohibited use of the cloud services, with respect to AI systems and AI use cases (i.e. prohibiting unacceptable AI use cases within the service)

4. Verify, through interviews or otherwise, that the policy is communicated to interested parties, and acknowledged as applicable.

5. Examine policy for evidence of review by policy owner or committee at least annually.

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.

Auditing Guidelines for AI Customers (AIC)

1. Verify that the model provider, OSP’s, AIC have a documented AIIA process and assess its alignment with your organization’s risk tolerance and regulatory obligations.

2. Verify that there is an evaluation criteria to choose a model provider, OSP or AIC based on the organizations requirements.

3. Verify the model evaluation criteria and scoring mechanism tailored to the organization’s risk dimensions such as ethical, societal, legal, operational, and security.

4. Assess how the impact assessment methodology evaluates differential impacts across various downstream applications with in the organization.

5. Verify the process to identify various stakeholders (both internal and external) and how they communicate and engage stakeholders to communicate impact assessment process, evaluation procedures, impact/risk scores and most importantly how they collect and incorporate their feedback.

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.

Auditing Guidelines for AI Customers (AIC)

1. Policy-Based Evaluation: Verify that assessments of data, models, and algorithms for bias and fairness are documented and aligned with the organization’s AI fairness policy and applicable regulatory obligations.

2. Diverse Data Representation: Ensure that training and evaluation datasets reflect the diversity dimensions (e.g., demographic, geographic, socioeconomic) defined in the organization’s fairness and bias policy.

3. Fairness-Aware Model Training: Verify that model development includes fairness constraints or mitigation techniques as required by internal policy or external standards.

4. Bias Detection and Mitigation Tools: Confirm the availability and use of validated tools, metrics, and procedures for detecting, measuring, and mitigating bias throughout the AI lifecycle.

5. Ongoing Monitoring and Reporting: Ensure there is a regular process for bias re-evaluation, mitigation, and transparent reporting—ideally documented through model cards or equivalent artifacts accessible to internal stakeholders.

GRC-12: Ethics Committee

Control Specification

Establish an ethics committee to review AI applications, ensuring alignment with ethical standards and organizational values.

Auditing Guidelines for AI Customers (AIC)

1. Verify that customer has a ethics committee consists of a diverse set of stakeholders needs to be involved AI application lifecycle.

2. Verify the committee roles and responsibilities are clearly defined and documented.

3. Verify that customer has clear understanding of their role and have knowledge to contribute/guide towards Ethical AI Applications.

4. Verify that there established standards for decision making and approving AI applications

GRC-13: Explainability Requirement

Control Specification

Establish, document, and communicate the degree of explainability needed for the AI Services.

Auditing Guidelines for AI Customers (AIC)

1. Verify that the AI customer has clearly articulated explainability requirements, informed by applicable compliance, regulatory, or ethical obligations.

2. Verify that the priority of explainability is defined and aligned with these requirements, considering the potential consequences of errors.

3. Verify that regular and structured stakeholder communication is in place to ensure explainability practices are effectively conveyed to both internal and external stakeholders.

4. Verify that there is a documented process for choosing the right partner based on explainability criteria defined in the explainability requirements.

5. Verify that the AI customer is transparent about its explainability practices and their customers are informed and understand how decisions are made.

GRC-14: Explainability Evaluation

Control Specification

Evaluate, document, and communicate the degree of explainability of the AI Services, including possible limitations and exceptions.

Auditing Guidelines for AI Customers (AIC)

1. Verify that customer specific explainability requirements are defined and aligned with domain-specific compliance, regulatory, and ethical obligations.

2. Verify that there are formalized processes to evaluate the explainability of third-party or in-house AI services before deployment.

3. Verify that any limitations (e.g., black-box models) and exceptions (e.g., human-in-the-loop, low risk outputs) are assessed, documented, and understood by stakeholders.

4. Ensure that the degree of explainability is captured( e.g., model cards) in risk assessments and system documentation for each AI system deployed.

5. Verify that explanation outputs are validated with end users (e.g., case workers, analysts) for clarity and interpretability.

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.

Auditing Guidelines for AI Customers (AIC)

1. Verify that the AI Consumer (AIC) has defined processes, procedures, and technical measures to ensure that AI systems are designed and developed in such a way that human operators can oversee their functioning and intended performance. Ensure that the processes are documented in detail, covering scope, objectives, roles and responsibilities.

2. Examine the above-mentioned processes, procedures, and technical measures to confirm their compliance with relevant regulatory requirements and industry best practices.

3. Examine whether the above-mentioned processes, procedures, and technical measures adopt a risk-based approach.

4. Confirm that the above-mentioned processes, procedures, and technical measures are concretely and appropriately implemented by responsible parties.

5. Inspect whether the above-mentioned processes, procedures, and technical measures are monitored against sets of efficacy and efficiency metrics / indicators.

6. Inspect whether the above-mentioned processes, procedures, and technical measures are periodically reviewed and updated by responsible parties.

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.

Auditing Guidelines for AI Customers (AIC)

1. Internal Policy Documentation and Approval: Verify that the AIC has a documented, approved background screening policy for its own employees, contractors, and third parties, proportionate to role risk and data sensitivity.

2. Defined Criteria: Verify that the policy defines consistent screening criteria: criminal history, employment history, education, professional licenses, and (if relevant) credit checks.

3. Transparency and Consent: Verify the policy is clearly communicated to applicants and written consent is obtained, respecting fairness and privacy laws.

4. Use of Providers: Verify that the AIC uses reputable, compliant background check providers for its own staff.

5. Handling Adverse Findings: Verify that the AIC defines fair processes for addressing adverse findings, allowing candidates to respond or appeal.

6. Data Privacy and Security: Verify personal data collected through background checks is secured and handled in compliance with applicable privacy regulations.

7. Review and Update: Verify that the policy is reviewed and updated at least annually or after significant legal/regulatory changes.

8. Vendor Oversight: Verify that the AIC’s vendor risk management policy requires its AI service providers (AP, MP, OSP) to attest to having a background screening process for their personnel in sensitive roles. Check service agreements, contracts, or security questionnaires for clauses requiring such attestations.

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.

Auditing Guidelines for AI Customers (AIC)

1. Policy Establishment and Documentation: Verify that the AIC has established and formally documented an internal Acceptable Use Policy (AUP) that governs employee and contractor use of procured AI services (e.g., SaaS‑hosted AI applications), and associated organizational IT resources used to access such services.

2. Policy Communication and Acknowledgement: Confirm that the AUP is communicated to all relevant personnel, and that acknowledgements (e.g., signed forms, system confirmations) are documented and retained.

3. Content of the AUP: Verify that the AUP explicitly includes prohibitions against entering or exposing sensitive company data, personally identifiable information (PII), or confidential business information into AI services unless explicitly authorized and secured; misusing the AI service in ways that violate corporate policies, SLAs, or regulatory obligations; general organizational expectations: ensuring responsible, ethical, and compliant use of external AI services; and consequences for violations: documented and communicated disciplinary or remedial actions.

4. Monitoring and Enforcement: Verify that the AIC has implemented monitoring or spot‑check mechanisms to detect inappropriate use of AI services (where feasible and compliant with privacy obligations). Ensure that documented procedures exist for investigating and addressing detected violations.

5. Periodic Review and Maintenance: Confirm that the AUP is reviewed at least annually, or after significant changes in service terms, data privacy laws, or business priorities. Verify that reviews and updates are documented and retained.

6. Feedback and Continuous Improvement: Check whether feedback from users, audit findings, or incidents is incorporated into AUP updates to improve clarity and effectiveness.

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.

Auditing Guidelines for AI Customers (AIC)

1. Verify the AIC has an internal clean desk policy to protect sensitive business information, including any data that may be used with or generated by the AI service.

2. Check that the policy is communicated to all employees with access to the AI tool.

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.

Auditing Guidelines for AI Customers (AIC)

1. Verify the AIC has a remote work policy that governs how employees can access and use the AI service from outside the corporate network.

2. Confirm the policy addresses data handling and prohibits the storage of sensitive AI-generated outputs on personal or insecure devices.

3. Verify if the Remote and Home Working Policy and associated procedures are reviewed and updated at least annually or upon significant changes in legal or regulatory requirements, information security or operational risk, business or workforce model, technology controls, or assurance and audit expectations.

HRS-05: Asset returns

Control Specification

Establish and document procedures for the return of organization-owned assets by terminated employees, contractors and third parties.

Auditing Guidelines for AI Customers (AIC)

1. Verify the AIC has an offboarding process that includes revoking a terminated employee’s (contractors’ and third parties’) access to the third-party AI service.

2. Confirm the process includes procedures for transferring ownership of any AI-related projects or data created by the departing employee/contractor.

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.

Auditing Guidelines for AI Customers (AIC)

1. Verify the AIC’s process for employment changes includes revoking access to the AI service and any internal systems that integrate with it.

2. Confirm that responsibilities for any AI-related outputs or configurations are formally transferred from the departing employee to a new owner.

HRS-07: Employment Agreement Process

Control Specification

Employees sign the employee agreement prior to being granted access to organizational information systems, resources and assets.

Auditing Guidelines for AI Customers (AIC)

1. Verify the AIC requires its own employees to sign employment agreements that include clauses on the acceptable and confidential use of company resources, which extends to third-party AI services.

2. Confirm this is part of the standard onboarding process for all employees.

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.

Auditing Guidelines for AI Customers (AIC)

1. Review the AIC’s standard employment agreement to confirm it includes clauses requiring employees to adhere to all corporate security and data privacy policies, including those governing the use of third-party software and AI services.

2. Check for specific language on protecting company information when using such tools.

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.

Auditing Guidelines for AI Customers (AIC)

1. Verify the AIC’s internal policies clearly define employee responsibilities when using AI tools, including accountability for the inputs they provide and the outputs they use in business decisions.

2. Confirm that roles like “AI Champion” or “AI System Owner” are formally defined, if they exist.

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.

Auditing Guidelines for AI Customers (AIC)

1. Evaluate whether the AI Customer has clearly defined and documented its non-disclosure and confidentiality requirements, with specific focus on protecting sensitive business data, proprietary algorithms, and AI usage patterns shared with providers; ensuring confidentiality of customer and user data processed or exposed through AI services; and managing third-party AI provider access, including contractual obligations, data handling terms, and integration safeguards.

2. Confirm that these non-disclosure and confidentiality agreements are reviewed at scheduled intervals, ensuring they align with internal governance policies and applicable regulatory requirements, adapt to changes in AI service usage, provider relationships, and risk landscape,and are updated and re-approved as necessary to maintain compliance and data protection.

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.

Auditing Guidelines for AI Customers (AIC)

1. Verify the AIC’s security awareness program includes training on the safe and responsible use of third-party AI tools.

2. Confirm the training covers what data is permissible to enter into AI systems and how to identify and report suspicious or biased AI outputs.

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.

Auditing Guidelines for AI Customers (AIC)

1. Confirm that personnel who interact with or manage AI systems (e.g., through configuration, oversight, or integration) receive security and responsible AI training for example, business analysts configuring AI outputs in customer-facing apps must complete training on data privacy and model output handling.

2. Check for documented training policies and access-role mappings, such as policies requiring product owners and IT administrators to complete annual compliance and security refreshers before managing AI integrations.

3. Verify that training is completed and regularly updated to reflect evolving AI usage risks, for instance may include topics like bias in third-party models, prompt injection risks, and responsible use of generative outputs.

4. Ensure training is tailored to specific roles (e.g., product managers, data stewards, IT staff). For example, product teams learning about ethical AI use and IT teams focusing on secure API and data flow management.

5. Interview staff to confirm awareness of responsibilities and recent updates. For example, ask a product manager how they validate AI-generated content and whether they’re aware of the latest internal AI usage guidelines.

6. Review how updates are communicated, such as through internal newsletters, compliance briefings, or AI governance updates that highlight changes in vendor model usage policies and internal risk controls.

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.

Auditing Guidelines for AI Customers (AIC)

1. Review how the AI Customer (AIC) identifies and updates applicable AI-related legal, statutory, and regulatory obligations (e.g., ISO 42001, EU AI Act, U.S. state-level AI laws).

2. Collect evidence of documented processes for compliance tracking, legal reviews, and involvement of relevant stakeholders (e.g., procurement, legal, risk, IT).

3. Interview staff (e.g., business owners, AI product users, compliance officers) to confirm awareness of their responsibilities in using AI systems responsibly.

4. Check for role-specific training, signed acknowledgments, and ongoing compliance communications related to AI usage and oversight.

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.

Auditing Guidelines for AI Customers (AIC)

1. Verify the AI Customer has an approved AI training policy aligned with its use of third-party AI tools in business operations (e.g., covering responsible use of AI for decision-making, content generation, or analytics).

2. Review that the training program defines role-specific paths (e.g., marketing on ethical content use, HR on fair AI-assisted hiring, analysts on interpreting AI outputs responsibly).

3. Ensure training is accessible and delivered through onboarding, internal portals, or department-specific sessions.

4. Review participation records to confirm employees using or managing AI tools receive training relevant to their roles.

5. Evaluate effectiveness through feedback or assessments, and confirm updates are made following incidents, vendor changes, or audits.

6. Confirm training content is regularly updated to reflect new AI tools, regulatory changes, or evolving internal use cases.

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.

Auditing Guidelines for AI Customers (AIC)

1. Confirm the AI Customer (AIC) has a documented Acceptable Use Policy (AUP) for third-party AI tools, approved by internal governance (e.g., prohibiting use of AI APIs for unauthorized profiling or automated decisions without human oversight).

2. Ensure the AUP is accessible and clearly defines acceptable use across business functions (e.g., marketing should not use generative AI for fake testimonials, HR should avoid AI-driven hiring without fairness checks).

3. Verify the policy is communicated through onboarding, training, and documentation (e.g., analysts and IT teams trained on prompt safety, data privacy, and responsible interpretation of AI outputs).

4. Assess enforcement mechanisms like access controls, usage monitoring, and incident reporting (e.g., detecting unauthorized tool access or improper data inputs, with consistent handling of violations).

5. Check that the policy is reviewed and updated regularly (e.g., when adopting new AI tools for customer service or analytics, or in response to 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.

Auditing Guidelines for AI Customers (AIC)

1. Confirm that the customer organization has received and acknowledged the IAM policy applicable to their use of AI systems.

2. Verify that customer access (e.g., through portals or APIs) is scoped and controlled as per the IAM policy.

3. Check whether customers have agreed to access control terms and responsibilities in contract or service agreements.

4. Ensure IAM policy violations involving customer users are logged, communicated, and remediated per defined protocols.

5. Validate customer-facing support teams are trained to escalate IAM policy concerns or change requests.

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.

Auditing Guidelines for AI Customers (AIC)

1. Verify the AI Customer (AIC) has established, documented, approved, and communicated policies governing authentication credentials for access to AI systems, dashboards, and integrations, and confirm annual or event-driven review.

2. Confirm credential policies define password standards and extend to token-based, federated, or API-based authentication mechanisms where applicable.

3. Verify MFA is enforced for privileged or sensitive access to AI systems and data.

4. Confirm credential lifecycle management procedures exist for issuance, modification, revocation, and periodic review of user and service credentials.

5. Verify alignment with provider credential requirements under the Shared Responsibility Model.

6. Confirm monitoring and periodic evaluation of authentication controls to detect unauthorized access or credential misuse.

IAM-03: Identity Inventory

Control Specification

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

Auditing Guidelines for AI Customers (AIC)

1. Validate that all users within the AI customer’s environment are properly registered and tracked.

2. Confirm processes to synchronize internal identity inventories with cloud/third-party identity systems.

3. Verify tracking of federated or delegated identities used to consume AI services.

4. Check that inventory includes metadata such as assigned AI model scopes, usage thresholds, and access levels.

5. Review whether the identity list is audited when onboarding or decommissioning AI services.

IAM-04: Separation of Duties

Control Specification

Employ the separation of duties principle when implementing information system access.

Auditing Guidelines for AI Customers (AIC)

1. Ensure customer has visibility into roles defined by providers and understands SoD enforcement.

2. Validate any customer-managed roles do not violate defined SoD policies.

3. Confirm SoD responsibilities are clearly documented in contractual SLAs.

4. Review mechanisms for reporting potential SoD conflicts to providers.

IAM-05: Least Privilege

Control Specification

Employ the least privilege principle when implementing information system access.

Auditing Guidelines for AI Customers (AIC)

1. Review customer-defined roles to ensure they request access only for necessary components.

2. Confirm visibility into provider-enforced privileges granted to customer environments.

3. Check if customer can audit access logs for roles they define or manage.

4. Ensure access provisioning requests by customer are evaluated against least privilege policy.

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.

Auditing Guidelines for AI Customers (AIC)

1. Validate requests made by customers for new access are justified and documented.

2. Confirm customer access is provisioned based on contractual agreements.

3. Ensure revocation timelines are aligned with SLA commitments post-termination or role change.

4. Review logs of user provisioning initiated by or for the customer.

IAM-07: Access Changes and Revocation

Control Specification

De-provision or modify identity access in a timely manner.

Auditing Guidelines for AI Customers (AIC)

1. Confirm clear procedures exist for revoking access to customer accounts or personnel.

2. Check whether customer-initiated revocation requests are honored within agreed SLAs.

3. Validate customer has visibility into revocation audit logs.

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.

Auditing Guidelines for AI Customers (AIC)

1. Verify that end-user access to AI features is reviewed periodically based on license level or SLA.

2. Confirm access rights of AI integration APIs are audited.

3. Ensure system administrators review delegated rights to third-party consultants or users.

4. Check compliance with contractually defined access scopes.

5. Review logs showing evidence of revoked or modified user access.

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.

Auditing Guidelines for AI Customers (AIC)

1. Verify that end-users and AI administrators have distinct roles and permissions.

2. Confirm support staff cannot access privileged customer data or AI decisions.

3. Check audit logs for unauthorized access attempts or privilege misuse.

4. Ensure delegation of access rights is limited and auditable.

5. Review access control mechanisms applied in user portals and dashboards.

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.

Auditing Guidelines for AI Customers (AIC)

1. Confirm customer admin accounts follow documented privileged role governance procedures.

2. Validate that role assignments and changes require explicit customer-side approval.

3. Ensure privileged operations (e.g., AI model retraining, audit log access, or override of automated decisions) are logged and monitored continuously.

4. Review the scope of elevated access granted to third-party consultants or system integrators.

5. Verify controls are in place to prevent unauthorized accumulation of privileged roles.

6. Check that temporary privileged access (e.g., for troubleshooting) is time-bound and automatically revoked.

7. Ensure that access to AI system controls (e.g., decision override modules) is limited to individuals with a justified business need.

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.

Auditing Guidelines for AI Customers (AIC)

1. Verify visibility into role definitions and associated approvals for customer-assigned roles.

2. Confirm participation in role assignment approvals for high-impact environments (e.g. production AI systems) is formally documented and retained as evidence.

3. Ensure customer access to audit trails of role authorizations.

4. Confirm periodic assessments of customer-facing role privileges.

5. Check documentation of shared responsibilities regarding role assignments.

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.

Auditing Guidelines for AI Customers (AIC)

1. Verify unique identifiers exist for all customer users accessing the AI service.

2. Confirm that customer-submitted actions (e.g., model feedback, reporting) are attributable.

3. Ensure role-based access is linked to individual identifiers.

4. Validate account reviews are periodically performed to remove unused or duplicate identifiers.

5. Confirm external identities (e.g., third-party contractors) are separately tracked.

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.

Auditing Guidelines for AI Customers (AIC)

1. Confirm that all users accessing AI dashboards or APIs authenticate through MFA.

2. Verify policy mandates secure authentication for integration of AI outputs into customer systems.

3. Check that user provisioning workflows enforce identity verification before access is granted.

4. Validate authentication logs are reviewed regularly for signs of compromise or unauthorized use.

5. Ensure strong authentication is applied consistently across federated and internal user groups.

IAM-14: Credentials Management

Control Specification

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

Auditing Guidelines for AI Customers (AIC)

1. Verify secure management of secrets used to integrate with external AI models or APIs.

2. Ensure strong internal password policies govern access to AI results and dashboards.

3. Check that secrets used in orchestration pipelines are rotated at a defined minimum frequency or based on documented risk-based rotation schedules.

4. Validate secure access to third-party credentials used to invoke AI services.

5. Check audit trails for unauthorized password or secret use.

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.

Auditing Guidelines for AI Customers (AIC)

1. Confirm that AI output access is authorized based on role, department, or sensitivity level.

2. Validate controls restrict user access to only permitted AI models and predictions.

3. Check enforcement of business rules governing authorized usage of AI decisions.

4. Ensure downstream access to AI-generated data is audited and aligned with data-sharing agreements.

5. Verify policy-driven restrictions on sensitive AI use cases (e.g., financial approvals).

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.

Auditing Guidelines for AI Customers (AIC)

1. Confirm access controls are enforced on model outputs, dashboards, and results shared with business users.

2. Check that AIC personnel with access to sensitive inference results (e.g., risk scores) are vetted and approved.

3. Ensure defined roles align with regulatory obligations (e.g., HIPAA or GDPR “minimum necessary” principles).

4. Validate periodic audits to ensure role drift or privilege creep has not occurred.

5. Review process to onboard new users or teams with access to analytical output.

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.

Auditing Guidelines for AI Customers (AIC)

1. Confirm visibility into when and why outputs are modified (e.g., flagged anomalies or overrides).

2. Validate signed approvals for business-specific changes to AI model results.

3. Ensure AIC-side applications consuming model results log unmodified vs. modified outputs distinctly.

4. Check change impact assessments are conducted when enabling output overrides for critical use cases.

5. Confirm user training includes awareness of when outputs might be subject to conditional override.

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.

Auditing Guidelines for AI Customers (AIC)

1. Confirm AI models deployed internally respect the consent preferences configured for customer users.

2. Check AIC policies support re-mapping or decoupling identity upon user request.

3. Validate mechanisms for users to access AI activity logs tied to their identity.

4. Ensure responsible teams audit and review identity mapping accuracy regularly.

5. Confirm anonymization processes are applied post-consent revocation or data withdrawal.

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.

Auditing Guidelines for AI Customers (AIC)

1. Verify the existence of documented policies and procedures addressing interoperability and portability ensuring it contains communications between application interfaces, information processing interoperability, application development portability.

2. Confirm that the policies and procedures have received appropriate approval from relevant authority within the AIC’s organization.

3. Examine evidence of a regular review and update cycle, ensuring the policies and procedures are evaluated and updated.

4. Verify the Application Provider’s due diligence process for ensuring that upstream providers implement controls related to interoperability and portability.

5. Verify that the policies are effectively communicated to relevant stakeholders, including internal personnel and any external partners or service customers impacted by these controls.

6. Verify that the review and update of the interoperability and portability policies and procedures occur at least annually, and that evidence of review (e.g., change logs, approvals) is retained.

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.

Auditing Guidelines for AI Customers (AIC)

1. Verify whether comprehensive documentation for the application interfaces (APIs) is available, up-to-date, and accessible to relevant parties and contains information related to technical details for integration, data retrieval processes, and usage instructions.

2. Ensure that the APIs cover all necessary functionalities required by AI service customers to retrieve their data fully.

3. Verify that there are adequate security controls in place for accessing and using the APIs, including but not limited to authentication, authorization, and encryption.

4. Verify that the policy governing API availability and usage is reviewed and updated on a periodic basis by the respective owner.

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.

Auditing Guidelines for AI Customers (AIC)

1. Examine the adequacy of the policy to ensure to if they contain comprehensive details regarding the implementation of cryptographically secure network protocols within the AIC environment.

2. Review that the Interoperability and Portability Policy has been updated regularly to adapt to evolving industry standards and emerging threats.

3. Review that the communication channels are adequate to communicate about the policy to all relevant parties involved.

4. Examine the mechanisms used for the monitoring and enforcement of the policy. Ensure that there are clear procedures for detecting and addressing non-compliance.

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

Auditing Guidelines for AI Customers (AIC)

1. Review the contractual agreements to ensure service customers know their rights and obligations maintaining data security and availability during transitions.

2. Verify if data format specifications are defined in the contracts which ensure service customers can transfer and seamless use data with portability.

3. Examine data deletion period that ensures service customers can plan for data migration or deletion in line with regulations.

4. Verify there is an annual review in place to review data portability provisions.

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.

Auditing Guidelines for AI Customers (AIC)

1. Examine AI Customer (AIC) policies and procedures that defines the scope, objectives, roles, and responsibilities for security, privacy, and relevant compliance concerns.

2. Verify the Policies and Procedures ensure third-party (e.g., OSP, AP, CSP) reviews and controls are place and considered in the MP procedures.

3. Verify that policies and procedures are documented and approved from senior management or governing authority and update versioning.

4. Determine that approved policies and procedures are communicated to all relevant internal and external parties, ensuring they read, understand, and fulfill their roles and responsibilities.

5. Verify policies and procedure are effectively applied in daily operations and evaluated continuously for operational effectiveness and compliance.

6. Verify that security policies and procedures are regularly reviewed and updated to address emerging threats, vulnerabilities, and evolving business needs, ensuring clear documentation of changes and approvals exists.

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.

Auditing Guidelines for AI Customers (AIC)

1. Examine AI consumption and capacity planning documentation to verify alignment with business objectives and workload demands.

2. Verify that AI consumption and capacity planning documents are reviewed and approved by senior management or governance authorities.

3. Determine AI performance monitoring and optimization processes are in place to track and address capacity constraints.

4. Verify AI consumption patterns are reviewed annually to assess efficiency, identify potential resource bottlenecks, and optimize the performance.

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.

Auditing Guidelines for AI Customers (AIC)

1. Examine AI adoption network policies to ensure alignment with business and ethical requirements.Examine AI-related network security policies to ensure they define approved connectivity, access restrictions, and encryption requirements for AI services.

2. Verify identity-based network access controls restricting connectivity to AI services to only authorized users, applications, and systems.

3. Determine access controls and encryption mechanisms securing communication between applications, services, and AI decision systems, ensuring only authorized entities can interact with AI services.

4. Determine network security measures implemented to prevent unauthorized access, tampering, or injection via AI service communication interfaces.

5. Verify continuous monitoring and logging of network interactions with AI services to detect unauthorized or anomalous activity.

6. Verify AI usage policy and procedures reviewed regularly, at least annually, to align with evolving threats, regulations, and business needs, ensuring record-keeping of changes and approvals.

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.

Auditing Guidelines for AI Customers (AIC)

1. Examine documented policies and OS hardening baselines to ensure they align with AI deployment requirements and industry best practices.

2. Determine if appropriate system hardening measures are implemented for AI workloads (e.g., OWASP top 10 for LLM, CIS benchmarks for systems).

3. Verify regular security assessments and compliance checks against hardening baselines, ensuring prompt remediation of identified risks.

4. Verify an annual review of hardening configurations for AI system, ensuring results are documented, reviewed, and approved.

5. Verify if continuous monitoring and threat intelligence mechanisms are in place to update hardening procedures against emerging security threats and approved by authorities.

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.

Auditing Guidelines for AI Customers (AIC)

1. Examine AI Customer (AIC) policies and procedures ensuring separation of production and non-production AI environments to reduce the risk of sensitive production data being used in non-production environments.

2. Verify role-based and least-privilege access controls enforce separation between production and non-production model environments, restricting production access to authorized personnel only.

3. Verify production data is not used in non-production environments unless sanitized or otherwise protected before any authorized use.

4. Verify formal change management and deployment processes governing movement between non-production and production environments, including documented approvals.

5. Verify monitoring and logging across environments to detect unauthorized access, data movement, or configuration changes, and confirm logs are securely maintained and reviewed.

6. Confirm segregation and production data protection controls are periodically reviewed and updated to address emerging risks, compliance requirements, and business changes.

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.

Auditing Guidelines for AI Customers (AIC)

1. Review documented policies and procedures to confirm that service customer (tenant) segmentation and segregation have been identified within consumed AI services (e.g., application, orchestration, or cloud layers), including which providers are responsible for enforcing those controls.

2. Determine whether the adequacy of provider-implemented tenant isolation has been assessed (e.g., through contracts, SOC reports, attestations, or technical documentation) relative to the sensitivity and criticality of AI use cases.

3. Verify that third-party risk management or vendor oversight processes incorporate tenant isolation considerations when onboarding or materially changing AI services.

4. Review processes for monitoring and responding to provider-reported incidents or changes that could impact tenant isolation (e.g., cross-tenant exposure events, architecture changes, service model changes).

5. Verify that reliance on provider segmentation controls is periodically reassessed, with documented triggers and outcomes when the environment materially changes (e.g., changes in AI usage patterns, data sensitivity, or regulatory expectations).

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.

Auditing Guidelines for AI Customers (AIC)

1. Verify the AI Customer (AIC) documented migration procedures explicitly require secure, encrypted communication channels.

2. Confirm encryption mechanisms adhere to current security standards, ensuring AI consumer interactions, suppliers, and stakeholder expectations are covered.

3. Check records documenting secure migration processes.

4. Ensure risk assessments conducted before migrating sensitive data to cloud environments.

5. Validate compliance checks post-migration to confirm the security and integrity of data.

6. Confirm clearly defined roles and responsibilities for migration activities.

7. Verify documented incident response plans for issues arising during cloud migration.

I&S-08: Network Architecture Documentation

Control Specification

Identify and document high-risk environments based on data sensitivity, threat exposure, and business impact.

Auditing Guidelines for AI Customers (AIC)

1. Verify the AI Customer has comprehensive documentation identifying and detailing high-risk environments based on data sensitivity, threat exposure, and business impact.

2. Confirm regular updates and reviews of network architecture documentation. (e.g., risk assessment, privacy impact assessments, crown jewel identification, threat models).

3. Check availability and accessibility of architecture documentation to authorized personnel.

4. Ensure documentation aligns with current network configurations and practices.

5. Validate documented processes for identifying and managing changes to network architecture.

6. Confirm training provided to responsible personnel for maintaining accurate documentation.

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.

Auditing Guidelines for AI Customers (AIC)

1. Verify the AI Customer (AIC) documented procedures clearly define network defense mechanisms.

2. Confirm regular implementation and evaluation of defense strategies (e.g., Access controls, encryption, logging, firewalls, IDS/IPS).

3. Check routine testing of defense mechanisms for effectiveness against current threats.

4. Ensure monitoring and logging effectively capture events relevant to network defense.

5. Validate timely response and mitigation processes for detected threats.

6. Confirm clear accountability and documented roles for network defense management.

7. Verify regular training sessions on network defense practices provided to security teams.

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.

Auditing Guidelines for AI Customers (AIC)

1. Conduct interviews with personnel responsible for documenting, maintaining, and communicating organizational logging and monitoring policies, procedures, and standards (the Policies).

2. Inspecting Records and Documents: Obtain and review the Policies to ensure they are adequate for the organization to manage risks associated with logging and monitoring. Verify that the Policies define the personnel or roles responsible for their dissemination, identify an official accountable for managing the Policies, specify the frequency of reviews and updates (annually), and outline events that necessitate policy updates. Review the Policies by performing the following verification steps:

   1. Verify that customer-specific logs, including API usage and model response behavior, are accessible and auditable.

   2. Ensure customer participation is enabled in defining the scope of logged events, especially for sensitive data.

   3. Confirm logs are reviewed to validate model decisions when AI is used in critical decision-making.

   4. Check that logs are integrated into the customer’s security operations center (SOC) or SIEM system.

   5. Validate the ability to generate forensic artifacts from logs in case of model output disputes.

   6. Confirm that customers are informed of log retention policies and have the option to request extended retention.

   7. Ensure that alerts based on customer-defined logging policies are actively monitored and acted upon.

3. Verify that the Policies are communicated, reviewed and updated at least annually or upon significant changes, are approved, and communicated to relevant stakeholders.

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.

Auditing Guidelines for AI Customers (AIC)

1. Inquiring with Control Owners

   1. Conduct interviews with personnel responsible for defining, implementing, and evaluating audit log security and retention processes for AI applications to understand their roles in protecting application-level logs and user interaction data. Verify their understanding of technical measures implemented to ensure audit logs from AI-powered features, user sessions, and model inference requests remain secure and are retained according to organizational requirements.

2. Inspecting Records and Documents

   1. Verify that application logs capturing AI model interactions, user inputs, and system responses are stored in write-once or append-only formats where feasible.

   2. Confirm that logs containing sensitive user data and AI model outputs are protected using encryption at rest and in transit.

   3. Ensure access to AI application logs is restricted to authorized personnel only, with RBAC or IAM controls preventing unauthorized access to user interaction data.

   4. Validate mechanisms to detect and alert on unauthorized access attempts or changes to logs containing AI application usage patterns.

   5. Check that AI application log protection is periodically tested through internal audits, including validation of user privacy controls.

   6. Confirm that log retention for AI application data aligns with privacy regulations, compliance requirements, and business policy requirements.

   7. Verify that controls are in place to prevent end-users and application-layer components from tampering with audit logs.

   8. Review documented processes and procedures for AI application audit log security, including user consent and data handling procedures.

   9. Validate that backup and recovery procedures exist for AI application audit logs to ensure availability during incident response.

   10. Confirm that log disposal procedures are secure and documented for AI application logs when retention periods expire, including proper data sanitization.

   11. Confirm that logs provided to or generated by the customer environment are access-controlled and immutable.

   12. Validate that customers have documented processes for secure log storage and retention.

   13. Check whether logs used to validate AI outcomes or model behaviors are protected from tampering.

   14. Ensure that customer staff with log access are assigned through documented authorization procedures.

   15. Verify the presence of alerts for any suspicious access to protected logs.

LOG-03: Security Monitoring and Alerting

Control Specification

Identify and monitor security-related events within applications, the underlying infrastructure. Define and implement a system to generate alerts to responsible stakeholders based on such events and corresponding metrics.

Auditing Guidelines for AI Customers (AIC)

1. Inquiring with Control Owners: Conduct interviews with personnel responsible for identifying, monitoring, and alerting on security-related events within AI applications and integrated AI services. Determine how security events are defined and classified, how alert thresholds or metrics are established, and how alert notifications are routed to responsible stakeholders for incidents involving unauthorized or malicious use of AI-enabled features, data exposure, or compromise of AI application integrity (e.g., unauthorized modification of AI-enabled functionality, configurations, or integrated model components).

2. Inspecting Records and Documents

   1. Verify documented procedures define security-related events to be monitored within AI applications, user interactions, and integrated AI services.

   2. Verify monitoring mechanisms are implemented to detect defined security-related events across AI applications and integrated components supporting AI consumption (e.g., API endpoints, model integration layers, and application interfaces), including events such as prompt injection attempts, unauthorized feature access, abnormal usage patterns indicative of malicious activity, or data exfiltration via AI outputs.

   3. Review logs or monitoring outputs to determine whether defined security events are captured and retained in accordance with monitoring procedures.

   4. Verify alerting mechanisms are configured and generate notifications when defined security event thresholds or metrics are met.

   5. Verify that alert notifications are directed to appropriate responsible stakeholders.

   6. Review evidence that monitoring configurations and alert thresholds are periodically reassessed and updated as AI usage patterns or threat conditions change.

LOG-04: Audit Logs Access and Accountability

Control Specification

Restrict audit log access to authorized identities and maintain records of that access.

Auditing Guidelines for AI Customers (AIC)

1. Inquiring with Control Owners

   1. Conduct interviews with personnel responsible for managing AI application audit log access controls and maintaining access records to understand their authorization processes for accessing user interaction logs, AI model usage logs, and application security events. Verify their understanding of access restriction mechanisms and record-keeping requirements for all AI application audit log access activities.

2. Inspecting Records and Documents

   1. Verify access to AI application-generated audit logs (including user interactions, AI model requests/responses, and application security events) is restricted to authorized personnel.

   2. Ensure AI application logging access is role-based and mapped to least privilege principles, preventing unauthorized access to sensitive user data and AI usage patterns.

   3. Confirm all AI application log access events are themselves logged with timestamps, actor IDs, and specific data accessed.

   4. Check for formal review processes of AI application log access permissions, including regular access recertification.

   5. Validate AI application developers and support teams are not granted persistent access to production user logs without approval and business justification.

   6. Review incident records for unauthorized access to AI application audit logs and follow-up actions taken.

   7. Confirm procedures are in place to revoke AI application log access upon role changes or terminations.

   8. Examine documented access control policies and procedures for AI application audit log systems, including user privacy protections.

   9. Validate that AI application access records are retained according to privacy regulations and organizational policies.

   10. Review monitoring and alerting mechanisms for unauthorized or suspicious AI application audit log access attempts.

   11. Verify internal access to logs containing AI interaction or consumption data is approved and documented.

   12. Confirm controls are in place to track and log access to AI service logs within the organization.

   13. Validate logs are stored in locations with restricted access based on role or project affiliation.

   14. Review access reports to confirm data analysts, operators, and developers follow access protocols.

   15. Check escalation protocols are defined for unauthorized log access attempts.

   16. Review segregation of duties policies to prevent unauthorized modification, deletion, or tampering of audit logs.

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.

Auditing Guidelines for AI Customers (AIC)

1. Inquiring with Control Owners: Conduct interviews with personnel responsible for monitoring AI application security audit logs to understand how anomalous user activity and suspicious AI usage patterns are identified, how baseline application behavior is defined, and how detected anomalies are reviewed and acted upon in a timely manner.

2. Inspecting Records and Documents

   1. Verify security audit logs are generated and monitored for AI application components, including user authentication, model request/response activity, API usage, and application security events.

   2. Verify correlation rules or detection mechanisms are implemented to identify suspicious or anomalous activity that deviates from defined baseline or expected AI application behavior.

   3. Review documentation defining baseline AI application usage patterns and criteria used to classify activity as anomalous.

   4. Review monitoring outputs or dashboards to determine whether detected anomalies are logged and tracked.

   5. Verify a documented process exists for reviewing detected anomalies and taking appropriate and timely action.

   6. Inspect evidence that detected anomalies are reviewed and that appropriate and timely actions are taken and documented in accordance with the defined process.

   7. Review evidence that anomaly detection thresholds or correlation rules are periodically reassessed and updated as AI application usage patterns or threat conditions change.

LOG-06: Clock Synchronization

Control Specification

Use a reliable time source across all relevant information processing systems.

Auditing Guidelines for AI Customers (AIC)

1. Inquiring with Control Owners

   1. Conduct interviews with personnel responsible for managing time synchronization across AI application systems to understand their implementation of reliable time sources for user session tracking, AI model request logging, and application monitoring. Verify their understanding of time synchronization requirements for AI application components, user interaction timestamps, and procedures for maintaining accurate time records across SaaS deployment environments.

2. Inspecting Records and Documents

   1. Confirm AI application systems handling user interactions and model requests use a centralized time source.

   2. Verify implementation of Network Time Protocol (NTP) or equivalent time synchronization protocols across AI application infrastructure.

   3. Check synchronization logs to validate accurate timestamping across AI application components, user sessions, and model inference requests.

   4. Assess whether unsynchronized AI application systems trigger alerts or errors that could affect user experience or audit trails.

   5. Verify clock drift thresholds are defined and monitored for AI application servers and database systems.

   6. Confirm the accuracy of timestamps in AI application logs critical for user behavior analysis and security investigations.

   7. Validate incident response records for AI application issues reference consistent timestamps across user sessions and system events.

   8. Examine documentation of reliable time source configuration for AI application deployment environments and backup time synchronization mechanisms.

   9. Review time synchronization policies covering AI application systems, user interface components, and integrated AI model services.

   10. Validate that time source reliability is monitored for AI applications and backup time sources are available to maintain service continuity.

   11. Verify systems integrating with AI services maintain synchronized clocks with service providers.

   12. Confirm audit logs generated internally align with provider timestamps for traceability.

   13. Review SLA clauses ensuring synchronized event correlation across platforms.

   14. Assess logging systems for time-based inconsistencies during validation or audit.

   15. Ensure IT operations teams receive alerts for clock drift exceeding acceptable limits.

   16. Validate documentation that time sync procedures are aligned with cloud standards.

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.

Auditing Guidelines for AI Customers (AIC)

1. Inquiring with Control Owners

   1. Conduct interviews with personnel responsible for establishing, documenting, and implementing logging scope for AI application events and user interaction metadata to understand their process for defining which AI-powered feature events should be logged and their procedures for annual reviews. Verify their understanding of AI-specific threat environment changes that trigger scope updates and their implementation of documented logging requirements across AI application components and user interfaces.

2. Inspecting Records and Documents

   1. Confirm documentation specifies which AI application events must be logged (e.g., user authentication, AI model requests/responses, prompt injections, content policy violations).

   2. Validate inclusion of both success and failure events in the AI application logging scope, including successful AI interactions and failed model requests.

   3. Ensure regular reviews of AI application logging scope to capture evolving AI security threats such as prompt injection techniques and model abuse patterns.

   4. Check scope alignment with privacy regulations, AI ethics guidelines, and customer contractual obligations for AI services.

   5. Assess procedures for adjusting logging scope when deploying new AI features, model integrations, or user interface enhancements.

   6. Confirm stakeholder approval for the defined AI application logging scope, including input from AI ethics teams and data protection officers.

   7. Verify logs reflect real-world AI application events as specified in scope documents, including user interactions and AI model behaviors.

   8. Examine evidence of annual AI application logging scope reviews and documentation of any scope updates driven by new AI threats or regulatory changes.

   9. Review procedures for monitoring and responding to AI threat environment changes that may require logging scope adjustments for emerging attack vectors.

   10. Validate that implementation of AI application logging scope requirements is consistently applied across all AI-powered features, user interfaces, and integrated model services.

   11. Confirm the defined scope for capturing logs from AI solution usage and integrations.

   12. Validate logging of access events to customer-controlled interfaces.

   13. Ensure documentation captures system-generated logs relevant to AI model interactions.

   14. Assess whether business-specific events (e.g., data export, sensitive queries) are logged.

   15. Confirm scope documents are reviewed when new AI features are adopted.

   16. Validate third-party tools used by the customer align with the logging scope.

   17. Confirm that changes to the defined logging scope are documented with version history, formal approvals, and traceability to relevant regulatory requirements or compliance obligations.

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.

Auditing Guidelines for AI Customers (AIC)

1. Inquiring with Control Owners: Conduct interviews with personnel responsible for defining, implementing, and evaluating the technical measures that allow service customers to detect, and scrub, or tokenize sensitive data from applicable, and scoped, AI logs, which helps customers prevent unauthorized exposure, as per applicable laws and regulations. Verify their understanding of this customer responsibility, and its applicability for the AI components for the product or service provided.

2. Review product or service baseline, or agreement to verify that customer can opt-in for this responsibility, and based on the regulations that are applicable.

3. Verify that automated safeguards are in place according to the technical measures defined for the product or service, and based on the regulations that are applicable.

   1. Review the product or service description.

   2. Review the product or service customer agreement.

   3. Review the product or service customer baseline.

4. For those customers that opt-in, examine logs of the scoped product or services to verify only allowed information exists within logs. Due to the fact that company policy may not allow a review of this nature, especially logs that are customer or partially-customer controlled, policy should be cited, and this step skipped. Additionally, it is possible to review the logs of a test environment if one is available.

LOG-09: Log Records

Control Specification

Generate audit records containing relevant security information.

Auditing Guidelines for AI Customers (AIC)

1. Inquiring with Control Owners

   1. Conduct interviews with personnel responsible for generating audit records containing relevant AI application security information to understand their processes for capturing, formatting, and maintaining security-related audit data across AI-powered features and user interactions. Verify their understanding of what constitutes relevant AI security information and their procedures for ensuring audit records contain sufficient detail for AI-specific security investigations, user privacy protection, and compliance requirements.

2. Inspecting Records and Documents

   1. Verify AI application logs capture event type, timestamp, actor, and source for all AI-powered interactions and user sessions.

   2. Confirm logs include identifiers for correlating user actions across AI features, model requests, and application components.

   3. Ensure structured formats (e.g., JSON, syslog) are used for consistency across AI application logging systems.

   4. Check completeness of AI application log records by sampling user interaction trails and AI model request/response cycles.

   5. Validate that custom AI events are logged where relevant (e.g., prompt injection attempts, content policy violations, model abuse detection).

   6. Review AI application audit logs for evidence of tampering or missing entries related to user interactions and AI model usage.

   7. Examine AI application audit records to ensure they contain relevant security information such as user authentication to AI features, AI model access attempts, prompt injection detection, and content filtering events.

   8. Validate that AI application audit records include sufficient contextual information to support AI security investigations, user behavior analysis, and AI ethics compliance.

   9. Confirm that AI application audit record generation covers all security-relevant events across AI-powered features, user interfaces, and integrated AI model services.

   10. Review AI application audit record retention and storage mechanisms to ensure AI security information remains available for privacy regulation compliance and user protection timeframes.

   11. Confirm logs reflect access to AI interfaces and data operations.

   12. Ensure user activities and data transformations are logged.

   13. Validate logs capture service consumption metrics and key decision triggers.

   14. Review the use of centralized log aggregation tools.

   15. Check completeness of logs when auditing incident responses.

   16. Ensure audit trails support investigation of access violations or system changes.

LOG-10: Audit Records Protection

Control Specification

Protect audit records from unauthorized access, modification, and deletion.

Auditing Guidelines for AI Customers (AIC)

1. Inquiring with Control Owners

   1. Conduct interviews with personnel responsible for protecting AI environment audit records from unauthorized access, modification, and deletion. Verify their understanding of security controls, access restrictions, monitoring procedures, and incident response processes related to audit records.

2. Inspecting Records and Documents

   1. Verify access controls enforce least-privilege and role-based restrictions for AI environment audit records.

   2. Verify audit records are protected against unauthorized modification or deletion through tamper-resistant or immutable storage mechanisms.

   3. Review documentation demonstrating encryption of audit records at rest and during transmission.

   4. Verify audit records are segregated from operational data and protected independently.

   5. Review audit trails documenting access to audit record storage locations.

   6. Verify monitoring and alerting mechanisms detect unauthorized access, modification, or deletion attempts involving audit records.

   7. Examine backup and recovery procedures ensuring protection extends to archived audit records.

   8. Verify periodic testing and review of audit record protection controls.

   9. Review incident response procedures addressing compromise or suspected compromise of audit records.

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.

Auditing Guidelines for AI Customers (AIC)

1. Inquiring with Control Owners

   1. Conduct interviews with personnel responsible for establishing and maintaining monitoring and internal reporting capabilities over cryptographic, encryption, and key management operations for AI applications to understand their oversight processes for user data protection and AI model security. Verify their understanding of monitoring controls for encryption of user interactions, internal reporting mechanisms for AI application cryptographic operations, and procedures for maintaining ongoing oversight of key management for user data and AI model protection.

2. Inspecting Records and Documents

   1. Confirm monitoring mechanisms are in place to detect encryption failures or unauthorized decryption attempts for AI application user data and model communications.

   2. Verify reports are generated on the use of encryption in AI application data transmission, user data storage, and AI model request/response protection.

   3. Review documentation on how cryptographic keys are handled, rotated, and monitored for AI application user data protection and model security.

   4. Validate that AI application teams receive alerts for deviations in encryption policy adherence affecting user privacy and AI model integrity.

   5. Check integration with central SIEM tools for real-time visibility into AI application cryptographic operations and user data protection events.

   6. Ensure audit logs capture AI application encryption-related events like certificate expiration, invalid key use, or user data encryption failures.

   7. Confirm documentation of encryption algorithms and configurations in use for AI application user data, model communications, and session management.

   8. Examine internal reporting processes for communicating AI application cryptographic and key management findings to privacy officers and AI security stakeholders.

   9. Review periodic assessment and reporting schedules for AI application cryptographic policy compliance and user data protection effectiveness.

   10. Validate that monitoring and reporting capabilities cover all aspects of AI application cryptographic operations including user privacy protection, model security, and regulatory compliance.

   11. Confirm visibility into vendor reports on encryption usage and cryptographic operations.

   12. Review monitoring dashboards or periodic reports detailing the security of AI-related data flows.

   13. Validate vendor usage of encryption aligns with contractual or regulatory expectations.

   14. Ensure alerts or incident reports are shared for any failures in key protection or encryption enforcement.

   15. Check that internal governance includes review of encryption monitoring practices in AI environments.

   16. Confirm awareness and involvement in assessments of cryptographic control effectiveness.

LOG-12: Transaction/Activity Logging

Control Specification

Log and monitor key lifecycle management events to enable auditing and reporting on usage of cryptographic keys.

Auditing Guidelines for AI Customers (AIC)

1. Inquiring with Control Owners

   1. Conduct interviews with personnel responsible for logging and monitoring key lifecycle management events for AI applications to understand their processes for capturing, analyzing, and reporting on cryptographic key usage for user data protection and AI model security. Verify their understanding of key lifecycle event logging requirements for AI application operations, monitoring procedures for encryption keys protecting user interactions, and reporting capabilities that enable auditing and compliance oversight of cryptographic key management activities in AI-powered features.

2. Inspecting Records and Documents

   1. Verify that cryptographic key usage for AI application user data encryption, session management, and AI model communication is logged by the application.

   2. Confirm logs include timestamped records of key creation, use, rotation, and destruction for AI application encryption, user data protection, and model security operations.

   3. Ensure visibility into key usage by different AI application components, user interface services, and integrated AI model systems.

   4. Validate alerts are generated on suspicious or unauthorized key operations affecting AI application security or user data protection.

   5. Check alignment with internal policy for lifecycle monitoring of keys used within AI applications for user privacy and model integrity protection.

   6. Review SIEM or monitoring tool integrations that centralize and analyze AI application key-related activities and user data protection events.

   7. Confirm audit trails exist for every critical key management operation supporting AI application functionality and user data security.

   8. Examine reporting capabilities and procedures for generating AI application key lifecycle management reports to support privacy compliance and security auditing requirements.

   9. Review log retention policies and practices to ensure AI application key lifecycle event records are maintained for regulatory compliance and user protection timeframes.

   10. Validate that key lifecycle monitoring covers all AI application cryptographic operations including user session encryption, AI model communication security, and data backup protection activities.

   11. Confirm vendor transparency regarding transaction logging for encryption key usage.

   12. Review access logs for customer-managed keys used in hosted services.

   13. Validate key usage reports are periodically shared by the vendor, if applicable.

   14. Ensure incident notification procedures are in place for unauthorized key access.

   15. Verify audit logs demonstrate tenant-specific isolation of key usage data.

   16. Confirm involvement in periodic audits to validate key lifecycle logging by providers.

LOG-13: Access Control Logs

Control Specification

Monitor and log physical access using an auditable access control system.

Auditing Guidelines for AI Customers (AIC)

1. Inquiring with Control Owners

   1. Conduct interviews with personnel responsible for monitoring and logging physical access using auditable access control systems for AI application infrastructure to understand their processes for tracking, recording, and reviewing physical access to facilities hosting AI applications and user data. Verify their understanding of access control system monitoring capabilities for AI application environments, logging procedures for physical access to data centers and development facilities, and audit trail requirements that ensure all physical access activities affecting AI application security and user data protection are properly documented and reviewable.

2. Inspecting Records and Documents

   1. Verify physical access control systems are in place for all AI application environments, including production SaaS infrastructure, development, test, and staging environments.

   2. Check logging mechanisms capture physical access timestamps, user identity, and location for AI application infrastructure facilities and data centers.

   3. Confirm physical access logs are retained in accordance with data governance and privacy regulation requirements for AI application operations.

   4. Validate alerts are generated for unauthorized or after-hours physical access to AI application infrastructure and user data storage facilities.

   5. Review role-based access controls to ensure only authorized personnel can retrieve physical access logs for AI application environments.

   6. Confirm periodic audits assess physical access adherence across all AI application environments and user data protection facilities.

   7. Examine whether physical access logs are integrated into centralized SIEM systems for correlation with AI application security events.

   8. Verify encryption is applied to stored physical access logs for AI application facilities.

   9. Review monitoring procedures and capabilities of the physical access control system to ensure real-time visibility into physical access events affecting AI application infrastructure.

   10. Validate that the access control system provides comprehensive audit trails with tamper-evident logging for all physical access activities in AI application facilities.

   11. Examine backup and recovery procedures for AI application physical access control system logs to ensure continuity of audit capabilities for user data protection compliance.

   12. Confirm internal physical access control policies enforce log collection for AI deployment zones.

   13. Verify procedures are in place to regularly review physical access logs of staff managing AI workloads.

   14. Validate segregation of duty across those logging and those reviewing physical access logs.

   15. Check physical access reviews include AI staging and validation servers.

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.

Auditing Guidelines for AI Customers (AIC)

1. Inquiring with Control Owners

   1. Conduct interviews with personnel responsible for defining, implementing, and evaluating processes for reporting AI application monitoring system anomalies and failures to understand their procedures for detecting, classifying, and immediately notifying accountable parties of AI service issues affecting user experience and data protection. Verify their understanding of technical measures for AI application anomaly detection, notification workflows for different AI service failure types, and evaluation processes that ensure AI application monitoring system reliability and timely escalation to responsible stakeholders including AI ethics teams and customer success managers.

2. Inspecting Records and Documents

   1. Verify AI application systems are configured to detect logging anomalies such as dropped user interaction events, AI model response failures, or data format corruption affecting user privacy and service quality.

   2. Check processes are in place for classifying AI application failure severity and identifying responsible owners including AI development teams, data protection officers, and customer support.

   3. Validate AI application failures trigger alert workflows in ticketing or incident response platforms with appropriate escalation to AI ethics teams and user privacy stakeholders.

   4. Ensure fallback mechanisms exist when primary AI application logging systems fail, including backup user interaction tracking and AI model monitoring capabilities.

   5. Confirm logs of AI application failure events are themselves collected and analyzed to understand impact on user experience and AI service quality.

   6. Check that post-incident reviews incorporate root cause analysis for AI application failures with focus on user impact and AI model performance degradation.

   7. Verify metrics are defined to track detection and resolution of AI application anomalies including user experience impact and AI service availability measures.

   8. Examine immediate notification procedures for AI application monitoring failures to ensure accountable parties including AI product managers and customer success teams receive timely alerts.

   9. Review evaluation processes for assessing the effectiveness of AI application anomaly reporting and failure notification procedures in maintaining user trust and service quality.

   10. Validate that technical measures include automated escalation mechanisms for AI application monitoring failures when initial notifications are not acknowledged by responsible AI service teams.

   11. Confirm monitoring detects anomalies in data pipelines, inference results, and logging gaps.

   12. Verify role-based escalation paths for different anomaly categories.

   13. Validate incident management platforms are integrated with log anomaly data sources.

   14. Ensure business owners are looped into high-risk failure notifications.

   15. Check evidence of regular testing of anomaly detection logic.

   16. Review whether anomaly response timelines meet SLAs.

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.

Auditing Guidelines for AI Customers (AIC)

1. Inquiring with Control Owners

   1. Conduct interviews with personnel responsible for logging and monitoring all input events (content and metadata) to AI applications to understand their processes for capturing, storing, and analyzing user input data for auditing user interactions and reporting on AI feature usage. Verify their understanding of input event logging requirements for AI-powered applications, monitoring procedures for user behavior patterns and AI model interactions, and reporting capabilities that enable comprehensive auditing of AI application usage and user privacy compliance.

2. Inspecting Records and Documents

   1. Confirm input logging covers all AI application endpoints including user interfaces, mobile apps, web platforms, API integrations, and third-party service connections.

   2. Verify logs capture user identity, session information, request source, timestamp, AI feature used, and input payload structure for AI application interactions.

   3. Check that logging does not capture sensitive user PII unless explicitly required for AI functionality and properly protected under privacy regulations.

   4. Validate logging covers both direct user inputs to AI features and indirect inputs processed through application workflows and integrated services.

   5. Confirm that AI application logs are used to detect prompt injection, content policy violations, or malformed requests affecting user safety.

   6. Review retention settings to ensure AI application input logs are stored in alignment with privacy regulations and user consent requirements.

   7. Ensure AI application input logs feed into usage analytics dashboards for product improvement and user experience monitoring.

   8. Verify access to AI application input logs is role-restricted to authorized personnel and fully auditable for privacy compliance.

   9. Examine monitoring capabilities to ensure real-time visibility into AI application usage patterns, user engagement trends, and feature adoption metrics.

   10. Validate that metadata logging includes comprehensive user context such as session details, application state, AI model parameters, and user preferences.

   11. Review reporting mechanisms to confirm they provide adequate audit trails for AI application governance, user privacy compliance, and product analytics.

   12. Verify internal logging captures user-submitted prompts, documents, or inputs to AI models.

   13. Ensure metadata such as user role, system of origin, and intended use is captured.

   14. Confirm review procedures exist for validating whether unauthorized input types are blocked.

   15. Validate segregation of logs between business units using the same AI system.

   16. Ensure logs are reviewed as part of post-deployment validation or red-teaming.

   17. Confirm logs contribute to compliance reports and access audits.

   18. Check secure storage and deletion policies for input logs containing sensitive business content.

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.

Auditing Guidelines for AI Customers (AIC)

1. Inquiring with Control Owners

   1. Conduct interviews with personnel responsible for logging and monitoring all output events (content and metadata) from AI applications to understand their processes for capturing, storing, and analyzing AI-generated content delivered to users for auditing application behavior and reporting on AI feature usage patterns. Verify their understanding of output event logging requirements for AI-powered applications, monitoring procedures for AI response quality and user safety, and reporting capabilities that enable comprehensive auditing of AI application outputs and user experience analytics.

2. Inspecting Records and Documents

   1. Verify logs capture AI outputs returned to users through application interfaces or integrated downstream systems.

   2. Check logs include confidence scores, AI model version, timestamp, user ID, and application context for AI-generated content.

   3. Ensure auditability of AI application outputs that were overridden, rejected, or modified by content filters or human review.

   4. Validate logs help detect hallucinations, policy violations, offensive content, or anomalous AI responses affecting user experience.

   5. Confirm AI application outputs are categorized by risk level and content type for review prioritization and user safety.

   6. Ensure AI application output logs are used to train downstream content filters, safety mechanisms, or post-processing systems.

   7. Verify access to AI application output logs is restricted to authorized personnel and properly encrypted for user privacy protection.

   8. Confirm AI application output monitoring feeds into usage trend analytics for product improvement and user engagement insights.

   9. Examine reporting mechanisms for AI application outputs to ensure they provide comprehensive audit trails for user safety compliance and product governance oversight.

   10. Validate that metadata logging includes complete user context such as session details, application features used, personalization settings, and content classification details.

   11. Review AI application output log retention policies to ensure compliance with privacy regulations and enable long-term auditing of AI behavior and user interaction patterns.

   12. Verify internal systems capture AI output logs from all integrated services.

   13. Check logs include business context (e.g., use case ID, department, user group).

   14. Ensure monitoring tracks inconsistencies or changes in output behavior.

   15. Validate logs support review of responses used in customer-facing workflows.

   16. Confirm tamper-proof storage for logs tied to regulatory outputs (e.g., credit decisions).

   17. Ensure outputs triggering actions (e.g., alerts, decisions) are traceable through logs.

   18. Verify that unauthorized modifications to outputs are detected and flagged.

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.

Auditing Guidelines for AI Customers (AIC)

Training Pipeline Security: Not Directly Applicable (primary responsibility is due diligence).

Due Diligence: Review contracts/SLAs for security clauses. Assess provider security (review certifications, audit reports) from the AP, OSP, and MP (as applicable), specifically addressing training pipeline security. Consider questionnaires/assessments if needed.

1. Audit documentation of a plan by the AIC for the periodic review of the provider. If the rare case exists where the AIC is directly involved in training or fine-tuning, then review their internal policies, procedures, and implementation, similarly to the approach used for the AP when involved in those activities.

2. To validate vendor security assurances, require documented evidence such as certifications, audits, or third-party assessments rather than self-attestation.

3. Review adversarial testing reports to ensure they cover relevant attack vectors, use recognized methods, and document mitigation of vulnerabilities.

4. Demand transparent model change logs that record version updates, data or architecture changes, reasons for updates, and associated risks. These requirements should be built into procurement, contracts, and ongoing vendor management to maintain continuous oversight.

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.

Auditing Guidelines for AI Customers (AIC)

1. Examine documented AIC processes/procedures for ensuring providers (AP, OSP, MP) have adequate model artifact scanning.

2. Audit due diligence performance.

3. Review contracts/SLAs.

4. Assess provider security certifications/audit reports (specifically for model artifact scanning evidence).

5. Consider questionnaires/assessments if needed.

6. Audit for documentation of a plan by the AIC for the periodic review of the provider.

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.

Auditing Guidelines for AI Customers (AIC)

1. Review the AIC’s processes for requesting and receiving model documentation (e.g., Model Cards) from the Application Provider (AP) or other relevant providers in the supply chain.

2. Assess how the AIC utilizes the information within received model documentation for its risk assessment, compliance checks, and understanding of the AI service’s capabilities and limitations.

3. Audit the due diligence performed by the AIC on the AP regarding the provision, completeness, and perceived accuracy of the model documentation.

4. Check whether the AIC appropriately maintains received model documentation for its records and usage context, as appropriate.

MDS-04: Model Documentation Requirements

Control Specification

Establish and implement baseline requirements for Model documentation.

Auditing Guidelines for AI Customers (AIC)

1. Review service agreements that ensure adherence to established security baseline in supply chain agreement, as they have limited and/or indirect control within the environment and to maintain the appropriate controls within this specific environment.

2. Evaluate whether the organization confirms appropriate security and legal standards are implemented to establish and document standards and assess compliance.

3. Inspect what steps were made to document standards with technical and governance standards used by leadership and team personnel.

4. Check the system in use to ensure that regulatory and industry-accepted standards are in place.

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.

Auditing Guidelines for AI Customers (AIC)

1. Review SLAs with the Application Provider.

2. Audit that the AI Systems and tools used within the processes for validation with any and all components and artifacts.

3. Evaluate if there has been communication that states security measures are in place, and access is restricted.

4. Review compliance and internal policies that ensures data integrity for model implementation and data use to assess if the organization is following data governance.

MDS-06: Adversarial Attack Analysis

Control Specification

Define, implement, and evaluate processes and technical measures to assess adversarial threats specific to each AI model.

Auditing Guidelines for AI Customers (AIC)

1. Examine documented processes for analyzing adversarial threats specific to application implementations of AI models.

2. Verify identification of application-specific attack vectors, including user input manipulation, context exploitation, and prompt engineering attacks.

3. For APs that fine-tune models: Review methodologies for evaluating threats related to fine-tuning processes or application-specific model customizations.

4. Assess the threat prioritization framework, confirming that attack vectors are ranked based on application architecture and user interaction patterns.

5. Verify implementation of monitoring systems for detecting application-level attack indicators.

6. Review testing procedures for application-specific defenses against prioritized threats.

7. Examine coordination processes with upstream providers on shared threat mitigations.

8. Verify mechanisms for communicating relevant threat information to end users.

9. Review processes for updating threat assessments when application features change or new attack techniques emerge.

10. Assess how adversarial threat assessments influence security controls implemented in applications.

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.

Auditing Guidelines for AI Customers (AIC)

1. Examine the AP’s implementation of application-level protections that complement model hardening measures.

2. Verify input sanitization and validation controls that protect against adversarial inputs targeting model vulnerabilities.

3. Assess output filtering mechanisms that prevent exploitation of model outputs.

4. Review testing procedures for application interfaces that verify resistance to adversarial attacks.

5. Confirm documentation of how application-level protections integrate with and enhance underlying model hardening measures from upstream providers.

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.

Auditing Guidelines for AI Customers (AIC)

1. Examine procedures for verifying the integrity of models or orchestrated services received from upstream providers.

2. Verify implementation of integrity checks before deploying models in applications.

3. Assess the application-level mechanisms for ongoing integrity verification during operation.

4. Review documentation of integrity verification results and frequency.

5. Confirm procedures for responding to integrity check failures, including appropriate escalation and remediation steps.

6. Verify that integrity checks are performed at least annually and after any model update or change.

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.

Auditing Guidelines for AI Customers (AIC)

1. Examine procedures for verifying signatures of models or services received from upstream providers.

2. Verify implementation of signature verification before model deployment in applications.

3. Assess application-level mechanisms for verifying signatures when models are loaded during operation.

4. Review documentation of signature verification results and frequency.

5. Confirm procedures for responding to signature verification failures, including appropriate incident response steps.

6. Verify security controls for any application-specific signing keys if extending the provenance chain.

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.

Auditing Guidelines for AI Customers (AIC)

1. Examine application-specific monitoring implemented to track model performance within the application context.

2. Verify that user interaction patterns are captured and correlated with model performance.

3. Assess implementation of custom metrics relevant to application-specific performance concerns.

4. Review integration of monitoring with application incident response processes.

5. Confirm that monitoring insights are made available to AI Customers using the application.

6. Verify processes for escalating detected anomalies to upstream providers when necessary.

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.

Auditing Guidelines for AI Customers (AIC)

1. Examine implementation of application integration with redundant model services.

2. Verify application-level redundancy features such as multi-model routing or result aggregation.

3. Assess fallback mechanisms that handle model failures gracefully from the user perspective.

4. Review application testing under various model failure scenarios.

5. Confirm that the application design accounts for potential variations in responses when using redundant models.

6. Verify that application monitoring can detect and report model failures to trigger redundancy mechanisms.

7. Examine documentation of application behavior during failover events.

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.

Auditing Guidelines for AI Customers (AIC)

1. Examine risk evaluation procedures for incorporating open weight models into applications.

2. Verify implementation of application-level protections against potential exploits targeting open weights.

3. Review alignment of application usage with security guidelines provided by the MP or OSP.

4. Assess monitoring mechanisms for detecting indications of weight exploitation within the application context.

5. Confirm documentation of secure integration practices specific to open weight models.

6. Verify testing procedures that validate application security when using open weight models.

MDS-13: Secure Model Format

Control Specification

Adopt secure model formats and processes for AI model serialization where applicable.

Auditing Guidelines for AI Customers (AIC)

1. Examine implementation of secure practices when loading serialized models.

2. Verify that appropriate validation and sanitization are performed when handling serialized model data.

3. Assess adherence to security guidelines provided by MPs and OSPs regarding safe handling of serialized models.

4. Review testing procedures for serialization-related vulnerabilities in the application context.

5. Confirm documentation of serialization formats supported by the application and their security implications.

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.

Auditing Guidelines for AI Customers (AIC)

1. Verify the AI Customer (AIC) has a documented and approved security incident management policy, aligned with recognized industry standards such as NIST SP 800-61 or ISO/IEC 27035.

2. Ensure the AI Customer (AIC) has procedures for E-Discovery and Forensics for AI data and use.

3. Confirm that roles and responsibilities for incident detection, reporting, escalation, and resolution are clearly defined and documented.

4. Check that procedures cover the full incident lifecycle, including initial reporting, triage, escalation criteria, containment, eradication, recovery, and post-incident review.

5. Ensure that the policy and procedures are communicated effectively to all internal and external stakeholders, including third-party service providers, where applicable.

6. Verify that the incident management policy and related procedures are reviewed and updated periodically, or following major incidents, organizational changes, or regulatory updates.

7. Confirm that regular training is provided to incident response teams, with materials updated based on emerging threats and lessons learned.

8. Validate that incident response drills or tabletop exercises are conducted regularly, with documentation of scenarios, participants, outcomes, and improvement actions.

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.

Auditing Guidelines for AI Customers (AIC)

1. Confirm the AP has documented policies and procedures to ensure timely response of incidents.

2. Verify timely management expectations have been established and are based on business needs (e.g., regulations, business needs, contracts, incident severity level, ability to respond to customer demands).

3. Review dependencies (e.g., MP, AP, OSP) and partners which could impact the ability of the AIC to respond to the planned timelines.

4. Confirm regular audits of service management effectiveness and timely response to incidents.

5. Validate audit findings and lessons learned are addressed.

6. Verify documented training provided for service management procedures.

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.

Auditing Guidelines for AI Customers (AIC)

1. Verify the AIC has incident response plans clearly documented and approved.

2. Confirm incident response plans cover critical scenarios for executing model in the customer context comprehensively.

3. Check plans define specific roles and escalation procedures.

4. Verify the incident response plan includes a documented communication strategy for notifying internal stakeholders, impacted service providers (e.g., APs, MPs, CSPs), and business-critical functions that rely on AI services.

5. Ensure regular reviews and updates of incident response documentation.

6. Confirm testing and drills of incident response plans performed periodically.

7. Verify documented corrective actions following response plan testing.

SEF-04: Incident Response Testing

Control Specification

Exercise the incident response plans at planned intervals or upon significant changes.

Auditing Guidelines for AI Customers (AIC)

1. Confirm the AIC conducts incident response exercises at planned intervals or in response to major changes in AI service usage, system architecture, or threat posture.

2. Verify documentation of exercises includes scope, participants, simulated impact, and mitigation effectiveness.

3. Check how improvements are logged, prioritized, and integrated into updated procedures.

4. Ensure involvement of internal stakeholders (e.g., security, IT, risk, and AI governance) in exercise execution.

5. Validate exercise scenarios consider service disruptions, unexpected AI behavior, or third-party compromise.

6. Confirm that documented outputs from exercises are reviewed during risk and compliance oversight sessions.

SEF-05: Incident Response Metrics

Control Specification

Establish, monitor and report information security incident metrics.

Auditing Guidelines for AI Customers (AIC)

1. Verify AIC has documented metrics for evaluating incident response effectiveness.

2. Confirm metrics align with AI parameters, organizational goals and industry best practices (e.g., percentage of incidents detected internally vs. externally).

3. Check regular collection, analysis, and reporting of response metrics.

4. Ensure documentation of actions taken based on metrics analysis.

5. Confirm clear accountability for monitoring incident response metrics.

SEF-06: Event Triage Processes

Control Specification

Define, implement and evaluate processes, procedures and technical measures supporting business processes to triage security-related events.

Auditing Guidelines for AI Customers (AIC)

1. Verify IAC documented triage procedures clearly define event categorization and prioritization.

2. Confirm triage processes efficiently differentiate between critical and non-critical events.

3. Confirm design supports information collection to support triage (e.g., user interactions, use model use, and data flow logs).

4. Understand triage models from suppliers and partners (e.g., OSP, CSP, MP, AP).

5. Check regular training provided on event triage methods for the context the operation of the model.

6. Ensure continuous improvement through periodic review and update of triage processes.

7. Confirm clear accountability assigned for triaging security events.

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.

Auditing Guidelines for AI Customers (AIC)

1. Verify incident response categories for AI Customer (AIC) and severity levels clearly documented (e.g., consider impacts such as data leak, regulatory non-compliance, technical and financial impact).

2. Confirm well-defined roles and escalation pathways during incident response, including technical measures such as data recovery, backups, containment actions, employee notification in case of data leakage, and regulatory reporting requirements.

3. Verify role interdependencies across supply chain for AI Customer (e.g., AP, MP, OSP, and CSP).

4. Check documented incident response timelines and service level agreements (SLAs).

5. Ensure regular reviews of incident response activities and outcomes.

6. Verify clear accountability documented for incident handling.

7. Confirm training provided to relevant stakeholders on incident response processes.

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.

Auditing Guidelines for AI Customers (AIC)

1. Verify the AI Customer has documented policies clearly specify requirements for breach notification.

2. Confirm procedures comply with applicable legal and regulatory requirements.

3. Confirm the notification procedure provides essential information (e.g., customer information impacted, business services impacted).

4. Ensure regular testing of breach notification procedures.

5. Ensure impacted parties are informed of breaches within defined SLA and appropriate actions are taken to reduce the impact of the breach.

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.

Auditing Guidelines for AI Customers (AIC)

1. Verify the AI Customer (AIC) has documented policies that clearly specify requirements for collecting, classifying, storing, protecting and retaining incident records related to the use, configuration and application of AI systems.

2. Verify the policies define clear trigger conditions for when security incidents must be recorded, including incidents arising from unauthorized data inputs or policy violations.

3. Confirm the AIC maintains a secure incident record repository with appropriate access controls, encryption (in transit and at rest) and audit logging to prevent unauthorized access, modification or deletion.

4. Determine whether the AIC conducts periodic reviews of incident records to identify recurring patterns, root causes and systemic vulnerabilities (e.g. improper use of AI outputs, insufficient human oversight, configuration errors, inadequate access controls or failure to enforce usage policies) and whether the review cadence and review process are formally documented.

5. Confirm corrective actions identified through incident record analysis are documented, tracked, implemented and verified for effectiveness in addressing the identified issues.

6. Ensure records of reviews and corrective actions are retained and available for audit.

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.

Auditing Guidelines for AI Customers (AIC)

1. Verify documented procedures for AI Customer (AIC) to meet regulatory responsibilities and maintain points of contact.

2. Verify procedures for review of dependencies, with OSP, MP, AP and CSP for which would impact Application Providers ability to meet its regulatory contact obligations (e.g., GDPR, NIS2, ISO 27001, NIST 800-61).

3. Confirm regular updates and validation of points of contact.

4. Check records clearly document responsibility for points of contact maintenance.

5. Ensure immediate updates to contact information upon role changes.

6. Confirm periodic audits validating the accuracy and availability of contacts.

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.

Auditing Guidelines for AI Customers (AIC)

1. Verify AI vendors (e.g., LLM hosts, prompt tools, CSPs) are in scope.

2. Confirm formal governance and documented update cadence.

3. Interview IT/security teams; check awareness docs or LMS.

4. Review actual supplier assessments (CSA CAIQ, ISO/SOC reports, security scorecards).

5. Assess how suppliers are prioritized (e.g., critical vs. commodity, data access levels).

6. Check that the policy was reviewed within the last 12 months or post-major vendor change.

7. Confirm policy alignment with applicable regulatory obligations and recognized best practices.

8. Verify that monitoring, KPIs, or internal audits are in place to assess the ongoing effectiveness of the vendor risk management processes.

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.

Auditing Guidelines for AI Customers (AIC)

1. Examine the AIC’s SCM/SSRM policies and procedures for adequacy, formal approval, communication, and effectiveness in addressing third‑party risks and shared responsibilities.

2. Verify that SSRM policies are clearly defined and tailored to the services used and relevant third parties.

3. Confirm that SSRM policies comply with applicable regulatory requirements, industry best practices, and internal risk tolerance.

4. Check for evidence of formal approval of SSRM policies and procedures by authorized management.

5. Ensure that SSRM policies have been communicated clearly to internal stakeholders, with defined roles and no ambiguity or conflicts in shared responsibilities.

6. Monitor implementation of SSRM policies and procedures in daily operations.

7. Verify that metrics and indicators are monitored to evaluate the effectiveness of SSRM policies.

8. Confirm that SSRM policies are reviewed and updated at least annually or upon significant changes in technology, providers, or threat landscape.

9. Verify that the AIC has a documented process for reviewing and formally accepting the SSRM documentation from its AI service providers (AP, OSP, MP, CSP) as part of its vendor risk management.

10. Confirm that the AIC has documented and operationalized its own responsibilities under the SSRM — including secure configuration, user and access management, and monitoring of its use of the service.

STA-03: SSRM Supply Chain

Control Specification

Apply, document, implement and manage the SSRM throughout the supply chain.

Auditing Guidelines for AI Customers (AIC)

1. Ensure the AI customer obtains and examines SSRM documentation from all relevant providers (e.g., CSPs, model vendors, OSP, application providers), confirming that shared responsibilities are clearly outlined in contracts and onboarding materials.

2. Determine how the AI customer monitors and addresses inherited responsibilities, such as securing data in cloud environments, managing access to AI services, and aligning with provider-specific security controls.

3. Review the responsibility matrix provided by vendors, verifying that it clearly delineates roles across the supply chain including CSPs, orchestration layers, model developers, and internal teams to support accountability and informed risk management.

STA-04: SSRM Guidance

Control Specification

Provide SSRM Guidance to the service customers detailing information about the SSRM applicability throughout the supply chain.

Auditing Guidelines for AI Customers (AIC)

1. Ensure the AI service customer (AIC) has a process to actively reviews SSRM guidance provided by cloud, model, orchestration, and application providers, to understand their responsibilities across the full AI service stack.

2. Evaluate provider documentation, trust centers, or support materials to identify specific service customer responsibilities such as securing data, managing access controls, configuring services, and monitoring usage to ensure proper implementation of shared security practices.

3. Verify that the AIC has formally received SSRM guidance from all key providers and has stored it in an accessible, version-controlled location.

4. Assess how the AIC has aligned its internal controls, policies, and procedures with the received SSRM guidance to ensure clarity in its own security responsibilities.

5. Confirm that the SSRM guidance has been reviewed by the appropriate governance, security, or architecture teams, and that any unclear areas have prompted follow-up inquiries or clarification requests.

6. Review documentation of any feedback, escalations, or risk assessments conducted in response to received SSRM guidance.

STA-05: SSRM Control Ownership

Control Specification

Delineate the shared ownership and applicability of all CSA AICM controls according to the SSRM.

Auditing Guidelines for AI Customers (AIC)

1. Confirm the AIC has a process to review control ownership documentation from its providers (e.g., CAIQ, responsibility matrix), ensuring clarity on what is inherited or shared.

2. Confirm the AIC has documented its own responsibilities for controls it owns, especially in domains like GRC (Governance, Risk, Compliance) and HRS (Human Resources Security).

STA-06: SSRM Documentation Review

Control Specification

Review and validate the SSRM documentation.

Auditing Guidelines for AI Customers (AIC)

1. Confirm the AIC (Application Integrator/Customer) has a process to regularly review SSRM documentation from its providers (e.g., CSPs, APs, OSPs, MPs), ensuring shared responsibilities are clearly understood and current by updating its own matrix to reflect customer-owned responsibilities such as user access management, data classification, and compliance oversight.

2. Verify these reviews are conducted at least annually or when major service changes occur (e.g., onboarding a new SaaS provider, changes in data residency), ensuring the SSRM reflects updated responsibilities and control ownership.

STA-07: SSRM Control Implementation

Control Specification

Implement, operate, and audit or assess the portions of the SSRM which the organization is responsible for.

Auditing Guidelines for AI Customers (AIC)

1. Verify through testing and evidence review that the AIC is implementing its responsibilities, such as correctly configuring user access, securely managing API keys, and training its employees on acceptable use.

2. Review the AIC’s internal configuration standards and audit logs.

STA-08: Supply Chain Inventory

Control Specification

Develop and maintain an inventory of all supply chain relationships.

Auditing Guidelines for AI Customers (AIC)

1. Confirm that AIC has a process to review if each service provider maintains a centralized and current inventory of all third-party relationships that support the delivery of AI-related services, and perform periodic review and updates.

2. Verify that all relevant service relationships such as those involving data sources, infrastructure, model providers, APIs, and platform components are clearly documented and traceable.

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.

Auditing Guidelines for AI Customers (AIC)

1. Ensure the AI customer (AIC) mandates that providers maintain a documented SBoM process, with regular reviews triggered by infrastructure, application, or security changes.

2. Analyze provider SBoMs to confirm they define all critical components, including APIs, service or model versions, scaling mechanisms, dependencies, security controls, and risk classifications with relevant metadata.

3. Validate that SBoMs include both infrastructure and AI-specific elements, such as compute environments, networking, model endpoints, training pipelines, and monitoring systems.

4. Confirm that SBoMs are securely stored and accessible to authorized customer stakeholders, including security, compliance, and integration teams.

5. Monitor the frequency and accuracy of SBoM updates, ensuring customers receive timely impact assessments covering performance, availability, and security.

6. Review how SBoM information is communicated to the customer, including capabilities (e.g., supported features, model behavior, latency, input/output formats), SLAs, limitations, and integration protocols, with transparent security disclosures.

STA-10: Supply Chain Risk Management

Control Specification

Periodically review risk factors associated with supply chain relationships.

Auditing Guidelines for AI Customers (AIC)

1. Verify the AI Customer requires service providers to conduct regular supply chain risk assessments at least annually or upon significant changes addressing key areas such as operational stability, security, regulatory compliance, and reputational impact (e.g., onboarding a new model vendor or adapting to new AI regulations).

2. Confirm that the AI Customer reviews and retains supplier risk documentation, incorporating metrics like SLA adherence, incident logs, and audit outcomes (e.g., repeated service disruptions or data handling violations), with input from relevant internal teams.

3. Verify that the AI Customer enforces timely mitigation of identified risks such as updating contracts, increasing oversight, or replacing vendors and ensures all actions are documented and auditable, especially when risks affect AI system performance or compliance obligations.

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

Auditing Guidelines for AI Customers (AIC)

1. Ensure that service providers have processes to incorporate key provisions such as service scope, SSRM-aligned security, change management, monitoring, incident response, audit rights, termination, interoperability, data privacy, and operational resilience into their agreements with supply chain partners.

2. Confirm that the AI customer regularly reviews and validates that service providers are implementing and maintaining these contractual provisions effectively through audits, performance reviews, or compliance assessments.

STA-12: Supply Chain Agreement Review

Control Specification

Review supply chain agreements at least annually, or upon significant changes.

Auditing Guidelines for AI Customers (AIC)

1. Confirm that the AI Customer reviews supply chain agreements with key partners at least annually, or upon significant changes in services, risk, or regulatory requirements.

2. Confirm that the AI Customer has a process to determine that service provider regularly review their key supply chain partners at least annually or when significant changes occur in services, risk, or regulations.

3. Verify that review outcomes are documented and that identified risks or gaps are addressed through updated contracts, mitigation actions, or vendor reassessments, with oversight from governance or risk teams.

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.

Auditing Guidelines for AI Customers (AIC)

1. Confirm the AI Customer has a recurring process to audit supply chain partners, covering data usage (e.g., consent, anonymization), model performance (e.g., accuracy, drift), cloud infrastructure (e.g., encryption, access controls), and integration (e.g., API reliability, update handling).

2. Review audit records for issues such as biased training data, lack of explainability, unauthorized data sharing, or SLA breaches. Ensure corrective actions like model retraining, access revocation, or contract updates are documented and resolved.

3. Ensure findings are reviewed by internal teams (e.g., legal, IT security, procurement) and used to refine vendor selection, contract terms (e.g., audit rights, data ownership), and ongoing oversight.

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.

Auditing Guidelines for AI Customers (AIC)

1. Determine whether the Service Provider have defined and implemented a process for including security, compliance, and governance requirements into contracts with its supply chain partners, including those involved in AI infrastructure, model hosting, data processing, and third-party integrations.

2. Confirm that these requirements are clearly documented in contracts with relevant third parties. This should include specific provisions for protecting training and inference data, ensuring model integrity, meeting regulatory obligations (such as AI-specific laws or data residency requirements), and maintaining service availability and incident response capabilities.

3. Examine whether the service provider has granted AIC the contractual right to audit or assess its supply chain partners when necessary for verifying compliance with controls related to sensitive data handling, AI model performance, ethical use, and the continuity of AI services.

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.

Auditing Guidelines for AI Customers (AIC)

1. Examine whether service provider such as CSP, OSP, MP, AP have defined and implemented a process for reviewing the governance practices of their respective supply chain partners, including third-party infrastructure providers, data vendors, AI model developers, and service integrators that may impact AIC’s AI systems and data environments.

2. Evaluate whether service providers such as CSP, OSP, MP, or AP conduct these reviews at least annually, or upon significant changes, and maintain documented evidence that the reviews are performed in accordance with their internal policies and communicated to the AIC when applicable.

STA-16: Supply Chain Data Security Assessment

Control Specification

Define and implement a process for conducting risk-based security assessments of the supply chain.

Auditing Guidelines for AI Customers (AIC)

1. Verify that AIC has a structured process for governing security assessments of supply chain partners, covering cloud infrastructure and AI-specific components (e.g., data pipelines, model training, inference systems), aligned with customer expectations.

2. Assess whether AIC’s service providers have formal processes to identify and manage third-party risks, including data providers, cloud platforms, and AI service integrators.

3. Confirm that service providers document procedures for identifying and mitigating risks from external entities handling sensitive data, hosting AI models, or supporting critical AI infrastructure.

4. Evaluate whether service providers conduct regular supply chain security assessments per internal policies, addressing data integrity, model security, and cloud infrastructure risks, aligned with responsible AI practices.

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.

Auditing Guidelines for AI Customers (AIC)

1. Verify that the AIC has established and documented TVM policies and procedures defining scope, objectives, roles, and responsibilities.

2. Inspect whether the policies are compliant with regulatory requirements, industry best practices, and relevant threat scenarios.

3. Verify formal approval of the policies by authorized management.

4. Verify communication of the policies to all relevant stakeholders and their understanding.

5. Confirm that the policies are applied in daily operations.

6. Verify that metrics are established and monitored to evaluate effectiveness and identify areas for improvement.

7. Inspect evidence that the policies are reviewed and updated at least annually or upon significant changes.

8. Verify that the TVM policy includes procedures for managing vulnerabilities in internal systems that integrate with external AI services.

9. Confirm that the policy includes a process for receiving, assessing, and acting on vulnerability notifications from AI service providers.

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.

Auditing Guidelines for AI Customers (AIC)

1. Verify that the AI Consumer (AIC) has established and documented policies and procedures in the domain of Malware Protection that, by defining organizational and technical measures to prevent, detect, examine and remove malicious codes from systems, aim at leading efforts to protect the latter against malware attacks. Ensure that the policies are documented in detail, covering scope, objectives, roles and responsibilities.

2. Inspect whether the above-mentioned policies and procedures are compliant with relevant regulatory requirements, industry best practices and the specific threat scenarios to which the organization is potentially exposed.

3. Verify that the above-mentioned policies and procedures have been formally approved by authorized parties (e.g., management sign-off).

4. Verify that the above-mentioned policies and procedures (in both their original and subsequent versions) have been adequately communicated by authorized parties to all relevant stakeholders and that their content has been thoroughly comprehended by them.

5. Confirm that the policy is concretely and appropriately applied by involved parties in their day-to-day operations.

6. Verify that metrics and Key Performance Indicators (KPIs) have been established and are continuously monitored to evaluate the effectiveness of the above-mentioned policies and procedures and identify possible improvement areas.

7. Inspect whether the above-mentioned policies and procedures are periodically reviewed and updated (at least annually) by responsible parties.

8. Verify the AIC has an internal policy to protect its endpoints and systems from malware, which is critical for the secure consumption of any AI service.

9. Confirm the policy includes awareness training for employees to avoid phishing attacks that could lead to malware infections.

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.

Auditing Guidelines for AI Customers (AIC)

1. Verify that vulnerability detection measures (e.g., scanning, agent-based monitoring) are implemented across all organizationally managed assets, and that scans or detection activities occur at least monthly.

2. Inspect whether the above-mentioned policies, procedures and technical measures are compliant with relevant regulatory requirements and industry best practices.

3. Confirm that the above-mentioned policies, procedures and technical measures are concretely and appropriately applied by involved parties in their day-to-day operations.

4. Inspect whether the above-mentioned policies, procedures and technical measures are monitored against sets of efficacy and efficiency metrics / indicators.

5. Inspect whether the above-mentioned policies, procedures and technical measures are periodically reviewed and updated by responsible parties.

6. Verify the AIC’s process for applying patches to its own systems that interact with the AI service.

7. Confirm the process for responding to emergency patch notifications from their AI providers.

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.

Auditing Guidelines for AI Customers (AIC)

1. Verify that the AI Consumer (AIC) has defined processes, procedures, and technical measures to systematically identify threats to which AI systems and models are potentially exposed. Ensure that the processes are documented in detail, covering scope, objectives, roles and responsibilities.

2. Verify that processes, procedures, and technical measures are in place to systematically assess threats to AI systems and models previously identified.

3. Inspect whether the above-mentioned processes, procedures, and technical measures of threat analysis are compliant with relevant regulatory requirements and industry best practices.

4. Verify that countermeasures against identified threats are timely defined, prioritized, accordingly applied, monitored, reviewed and updated by relevant parties.

5. Inspect whether the above-mentioned processes, procedures, and technical measures of threat analysis are monitored against sets of efficacy and efficiency metrics / indicators.

6. Inspect whether the above-mentioned processes, procedures, and technical measures of threat analysis are periodically reviewed and updated by responsible parties.

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.

Auditing Guidelines for AI Customers (AIC)

1. Verify that the AI Consumer (AIC) has defined processes, procedures, and technical measures to update tools implemented to detect vulnerabilities, threat signatures and indicators of compromise within the security perimeter at least weekly. Ensure that the processes are documented in detail, covering scope, objectives, roles and responsibilities.

2. Verify that the above-mentioned processes, procedures, and technical measures are compliant with relevant regulatory requirements and industry best practices.

3. Confirm that the above-mentioned processes, procedures, and technical measures are concretely and appropriately applied by involved parties in their day-to-day operations.

4. Inspect whether the above-mentioned processes, procedures, and technical measures are monitored against sets of industry-standard efficacy and efficiency metrics / indicators.

5. Inspect whether the above-mentioned policies, procedures, and technical measures are periodically reviewed and updated by responsible parties.

6. Verify the AIC’s internal security operations include the frequent updating of detection tools like anti-malware, IDS/IPS, and SIEM rules.

7. Confirm the AIC consumes threat intelligence to stay aware of new threats related to their AI providers.

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.

Auditing Guidelines for AI Customers (AIC)

1. Verify that the AI Consumer (AIC) has defined processes, procedures, and technical measures to identify and implement updates for applications that use third party or open source libraries, in order to mitigate risks of compromise associated with the exploitation of vulnerabilities within such libraries. Ensure that the processes are documented in detail, covering scope, objectives, roles and responsibilities.

2. Examine the above-mentioned processes, procedures, and technical measures to confirm their compliance with the organization’s vulnerability management policy, as well as with relevant regulatory requirements and industry best practices.

3. Confirm that the above-mentioned processes, procedures, and technical measures are concretely and appropriately applied by involved parties in their day-to-day operations.

4. Inspect whether the above-mentioned processes, procedures, and technical measures are monitored against sets of efficacy and efficiency metrics / indicators.

5. Inspect whether the above-mentioned processes, procedures, and technical measures are periodically reviewed and updated by responsible parties.

6. Verify the AIC has a process for managing vulnerabilities in the external libraries of its own applications that integrate with the AI service through an SDK.

7. Confirm the AIC’s vendor management process includes asking providers about their management of open-source vulnerabilities.

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.

Auditing Guidelines for AI Customers (AIC)

1. Verify that the AIC has defined and documented processes, procedures, and technical measures for periodic penetration testing by independent third parties. Documentation must include scope, objectives, roles, and responsibilities.

2. Examine whether these processes comply with regulatory requirements and industry best practices.

3. Inspect alignment of the processes with relevant threat scenarios, including risks arising from integrated AI services.

4. Confirm that these processes are implemented and adhered to.

5. Verify that evidence from penetration testing activities is reviewed and translated into concrete remediation actions.

6. Inspect whether metrics and indicators are monitored to evaluate the efficacy and efficiency of the penetration testing program.

7. Inspect evidence that the processes are reviewed and updated at least annually or upon significant changes.

8. Verify that the AIC’s security program includes periodic penetration tests of how the AI service has been configured and integrated into the AIC’s business environment.

9. Confirm that the AIC has a defined process for reviewing summaries of penetration test reports from its key AI providers as part of its vendor risk management program.

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.

Auditing Guidelines for AI Customers (AIC)

1. Verify that the AI Consumer (AIC) has defined processes, procedures, and technical measures to periodically (at least monthly) detect vulnerabilities on assets managed by the organization. Ensure that the processes are documented in detail, covering scope, objectives, roles and responsibilities.

2. Examine the above-mentioned processes, procedures, and technical measures to confirm their compliance with relevant regulatory requirements and industry best practices.

3. Confirm that the above-mentioned processes, procedures, and technical measures are concretely and appropriately implemented.

4. Inspect whether the above-mentioned processes, procedures, and technical measures are monitored against sets of efficacy and efficiency metrics / indicators.

5. Inspect whether the above-mentioned processes, procedures, and technical measures are periodically reviewed and updated by responsible parties.

TVM-09: Vulnerability Prioritization

Control Specification

Use a risk-based method for effective prioritization of vulnerability remediation using an industry recognized framework.

Auditing Guidelines for AI Customers (AIC)

1. Verify that the AI Consumer (AIC) systematically adopts a method to support efforts in effectively and efficiently prioritizing remediations to vulnerabilities identified within the security perimeter.

2. Examine the above-mentioned method to verify that it adopts of a risk-based approach.

3. Examine the above-mentioned method to verify its compliance with industry recognized standards and frameworks.

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.

Auditing Guidelines for AI Customers (AIC)

1. Confirm assessment of AI service threats against business impact (e.g., SLA failure, misuse).

2. Evaluate customer-side risk assessment tools and documentation.

3. Check whether customer incident response plans include cloud AI threat vectors.

4. Review controls on input/output monitoring, especially for sensitive prompts/data.

5. Assess how threat alerts from CSPs or providers are prioritized and acted upon.

6. Review security training materials for business users on threat response procedures.

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.

Auditing Guidelines for AI Customers (AIC)

1. Verify that the AI Consumer (AIC) has defined a process to systematically document both the vulnerabilities identified within the security perimeter and the activities implemented to remediate them.

2. Examine the above-mentioned process to verify that it includes a notification phase to relevant stakeholders.

3. Confirm that the above-mentioned process is communicated and thoroughly comprehended by relevant parties.

4. Confirm that the above-mentioned process is concretely and appropriately implemented by responsible parties.

5. Inspect whether the above-mentioned process is monitored against sets of efficacy and efficiency metrics / indicators.

6. Inspect whether the above-mentioned process is periodically reviewed and updated by responsible parties.

TVM-12: Vulnerability Management Metrics

Control Specification

Establish, monitor and report metrics for vulnerability identification and remediation at defined intervals.

Auditing Guidelines for AI Customers (AIC)

1. Verify that the AI Consumer (AIC) has defined metrics and indicators for vulnerability identification and remediation at defined intervals.

2. Inspect whether the above-mentioned metrics and indicators are concretely and continuously monitored.

3. Inspect whether the above-mentioned metrics and indicators are periodically reviewed and updated by responsible parties.

4. Inspect whether the evidence emerged during the monitoring of the above-mentioned metrics and indicators is documented in appropriate executive and technical reports.

5. Inspect whether the above-mentioned reports are timely shared and actively discussed with all relevant parties to support decision making.

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.

Auditing Guidelines for AI Customers (AIC)

1. Verify that the AI Consumer (AIC) has defined processes, procedures, and technical measures to apply guardrails to the AI system. Ensure that the processes are documented in detail, covering scope, objectives, roles and responsibilities.

2. Examine whether the above-mentioned processes, procedures, and technical measures are compliant with relevant regulatory requirements and industry best practices.

3. Confirm that the above-mentioned processes, procedures, and technical measures are concretely and appropriately implemented.

4. Inspect whether the above-mentioned processes, procedures, and technical measures are monitored against sets of efficacy and efficiency metrics / indicators.

5. Inspect whether the above-mentioned processes, procedures, and technical measures are periodically reviewed and updated by responsible parties.

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.

Auditing Guidelines for AI Customers (AIC)

1. Verify that the AIC has established and documented endpoint device management policies and procedures, covering scope, objectives, roles, responsibilities, and measures to secure, monitor, and manage endpoints.

2. Inspect whether these policies are compliant with relevant regulatory requirements, industry best practices, and the specific threat scenarios the AIC is exposed to.

3. Verify formal approval by authorized management.

4. Ensure the policies are effectively communicated to all stakeholders and understood.

5. Confirm they are applied consistently in day‑to‑day operations.

6. Verify monitoring of effectiveness through metrics and indicators.

7. Inspect evidence of periodic review and update of policies (at least annually or after major system or vendor changes).

8. Confirm the endpoint policy explicitly applies to all employee devices (corporate and BYOD) that access or interact with AI services.

9. Verify evidence of communication and employee awareness training on endpoint security policy.

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.

Auditing Guidelines for AI Customers (AIC)

1. Verify that the AI Consumer (AIC) has defined processes, procedures, and technical measures to identify and implement updates for applications that used by the endpoints, in order to mitigate risks of accessing unapproved services and it’s sources when interacting with AI platforms. Ensure that the processes are documented in detail, covering scope, objectives, roles and responsibilities.

2. Examine the above-mentioned processes, procedures, and technical measures to confirm their compliance with the organization’s relevant regulatory requirements and industry best practices.

3. Confirm that the above-mentioned processes, procedures, and technical measures are concretely and appropriately applied by involved parties in their day-to-day operations.

4. Inspect whether the above-mentioned processes, procedures, and technical measures are monitored against sets of efficacy and efficiency metrics / indicators.

5. Inspect whether the above-mentioned processes, procedures, and technical measures are periodically reviewed and updated by responsible parties.

UEM-03: Compatibility

Control Specification

Define and implement a process for the validation of the endpoint device’s compatibility with operating systems and applications.

Auditing Guidelines for AI Customers (AIC)

1. Verify the AI Customer has a documented endpoint compatibility policy, covering planning, rollout, operation, and retirement of AI applications across corporate and BYOD devices.

2. Confirm that the policy integrates technical compatibility and security, including device inventories, OS/hardware matrices, secure configuration guidelines, and alignment with threat modeling, vulnerability management, and secure deployment practices.

3. Ensure the policy incorporates periodic compatibility testing and outlines responsibilities, regulatory constraints (e.g., privacy, AI-specific laws), and required audit mechanisms.

4. Review implementation through operational documentation, including test logs, secure configuration baselines, support tickets, security testing evidence, and records of periodic audits or updates.

5. Verify that the compatibility policy is enforced and monitored and that employees and administrators are aware of device-specific AI constraints, supported platforms, and security implications of misaligned configurations.

UEM-04: Endpoint Inventory

Control Specification

Maintain an inventory of all endpoints used to store, access and process company data.

Auditing Guidelines for AI Customers (AIC)

1. Verify that the AI Customer has a documented Endpoint Inventory Policy covering all lifecycle phases of endpoint devices, including identification, classification, monitoring, and decommissioning, with formal governance approval.

2. Inspect whether the policy includes criteria for endpoint categorization, defines update schedules and triggers, addresses regulatory and compliance requirements, and includes a process for periodic reconciliation between the inventory and actual devices.

3. Evaluate whether the inventory processes support risk assessment, AI deployment planning, and resource management, and ensure regulatory compliance for all endpoint types.

4. Review implementation evidence such as inventory reports, audit records, decommissioning logs, configuration documentation, and compliance reports.

5. Confirm the use of asset management tools and systems for accurate and timely inventory maintenance, and verify periodic audits and updates are conducted effectively.

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.

Auditing Guidelines for AI Customers (AIC)

1. Verify that the AI Customer has a documented Endpoint Management Policy covering the full endpoint lifecycle, from provisioning through decommissioning, including governance approval and role assignments.

2. Inspect whether the policy defines AI-specific configurations, patching requirements, remote management capabilities, and compliance with relevant regulations.

3. Confirm the policy integrates with incident response plans and includes mechanisms for regular reviews of endpoint usage, performance, and security posture.

4. Review operational evidence such as endpoint configuration records, patch logs, monitoring reports, incident response documents, and compliance reports.

5. Verify that management platforms and tools are in place to maintain visibility, automate patching, receive threat intelligence, and enforce policy consistently across AI-enabled endpoints.

UEM-06: Automatic Lock Screen

Control Specification

Configure all relevant interactive-use endpoints to require an automatic lock screen.

Auditing Guidelines for AI Customers (AIC)

1. Verify that the AI Customer has a documented Automatic Lock Screen Policy covering all key aspects of lock screen management, including approval, governance, and defined responsibilities.

2. Inspect whether the policy specifies acceptable inactivity periods, secure unlock methods, special handling for AI-related background processes, regulatory references, and exception management procedures.

3. Confirm that the policy mandates periodic reviews of lock screen settings and balances security with operational needs across endpoint types.

4. Review operational evidence such as device configurations, audit reports, compliance documentation, and monitoring tool logs.

5. Verify that lock screen configurations are enforced through management tools and are compatible with varied endpoint categories, including devices with limited user interaction.

UEM-07: Operating Systems

Control Specification

Manage changes to endpoint operating systems, patch levels, and/or applications through the company’s change management processes.

Auditing Guidelines for AI Customers (AIC)

1. Verify that the AIC has a documented Change Management Policy for all employee and BYOD devices running AI tools, covering OS version selection and patch management.

2. Inspect the policy to confirm it defines governance, assigned responsibilities, approval workflows, and a regular review cadence.

3. Confirm the policy enforces OS hardening standards, vulnerability scanning, and emergency‑patch procedures for AI‑enabled endpoints.

4. Verify that the policy requires testing OS updates against AI applications to prevent functional disruptions.

5. Review implementation evidence (device inventories, patch deployment logs, vulnerability scan reports, user‑support tickets, and audit records) to ensure policy compliance.

UEM-08: Storage Encryption

Control Specification

Protect information from unauthorized disclosure on managed endpoint devices with storage encryption.

Auditing Guidelines for AI Customers (AIC)

1. Verify that the AIC has a documented Storage Encryption Policy, approved by management, with defined roles, responsibilities, and regular review cycles.

2. Inspect whether the policy specifies approved encryption algorithms (e.g., AES‑256), key lifecycle management methods (HSMs or cloud KMS), exemptions criteria, and reference to GDPR/HIPAA/PCI‑DSS.

3. Confirm the policy mandates encryption of all AI‑related data at rest on corporate and BYOD devices, and prohibits storage of sensitive AI outputs on unencrypted endpoints.

4. Verify that the policy requires automated tools for key distribution, rotation, revocation, and routine compliance checks (encryption status, key logs) throughout device onboarding and offboarding.

5. Review evidence (device compliance reports, key‑management logs, baseline configuration profiles, audit records, and incident‑response procedures) to validate policy enforcement.

UEM-09: Anti-Malware Detection and Prevention

Control Specification

Configure managed endpoints with anti-malware detection and prevention technology and services.

Auditing Guidelines for AI Customers (AIC)

1. Verify that the AIC has a documented Anti‑Malware Detection and Prevention Policy, approved by management, with defined roles, responsibilities, and review schedule.

2. Inspect the policy to confirm it mandates anti‑malware deployment on all corporate and BYOD devices, baseline protections (real‑time scans, signature updates), whitelisting/blacklisting, and secure default configurations.

3. Confirm the policy specifies response actions upon detection (isolation, forensic analysis, system restoration) and references relevant regulatory standards (e.g., PCI‑DSS, HIPAA).

4. Verify the policy integrates with AI monitoring systems to ensure timely quarantining of malware without disrupting critical AI services.

5. Review implementation evidence (deployment reports, system logs, compliance dashboards, detection alerts, incident‑response records, and audit/test outcomes) to validate enforcement.

UEM-10: Software Firewall

Control Specification

Configure managed endpoints with properly configured software firewalls.

Auditing Guidelines for AI Customers (AIC)

1. Verify that the AIC has a documented Software Firewall Policy, approved by management, defining scope, roles, and a review schedule.

2. Inspect the policy to confirm it requires host‑based firewalls on all corporate and BYOD devices, with default‑deny and only AI‑related ports opened by exception.

3. Confirm the policy mandates firewall event logging and integration of those logs into central security monitoring.

4. Verify that the policy includes processes for firewall software patching and formal approval of changes to rule‑sets.

5. Review implementation evidence (device compliance reports, configuration snapshots, change‑management logs, log‑aggregation dashboards, and audit results) to validate enforcement.

UEM-11: Data Loss Prevention

Control Specification

Configure managed endpoints with Data Loss Prevention (DLP) technologies and rules in accordance with a risk assessment.

Auditing Guidelines for AI Customers (AIC)

1. Verify that the AIC has a documented DLP Policy, approved by management, defining scope, roles, and review schedule.

2. Inspect the policy to confirm it mandates DLP controls on all corporate and BYOD devices handling AI data, with classification‑based rules and integration into endpoint management.

3. Confirm the policy specifies detection methods (real‑time scanning, contextual analysis), response actions (block, encrypt, alert), and exception workflows for research or collaboration.

4. Verify that the policy references applicable data‑protection laws and industry standards and requires regular audits and rule fine‑tuning.

5. Review implementation evidence (endpoint compliance reports, rule‑set inventories, alert dashboards, incident/escalation records, and periodic audit outcomes) to validate enforcement.

UEM-12: Remote Locate

Control Specification

Enable remote geo-location capabilities for all managed mobile endpoints, according to all applicable laws and regulations.

Auditing Guidelines for AI Customers (AIC)

1. Verify that the AI Customer has a documented Remote Locate Policy, formally approved and covering key aspects of remote locate management, roles, and responsibilities.

2. Inspect whether the policy defines authorization processes, privacy safeguards, AI-specific automated tracking scenarios, data retention rules, and incident response integration for lost devices.

3. Confirm the policy mandates periodic audits of remote locate actions and balances asset protection with privacy and regulatory compliance.

4. Review implementation evidence such as remote locate logs, approval workflows, privacy documentation, technical configuration reports, and incident response records.

5. Verify that the organization uses secure tools to track devices across various platforms and ensures encryption and authentication for all location-related operations.

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.

Auditing Guidelines for AI Customers (AIC)

1. Verify that the AI Customer has a documented Remote Wipe Policy, approved under formal governance, defining scope, roles, and responsibilities.

2. Inspect whether the policy mandates strict, multi-factor approval for wipes, aligns actions with data classification, addresses privacy regulations, defines technical wipe limitations, integrates with incident response, and requires periodic audits.

3. Confirm that the policy covers all applicable operating systems and device types, including AI-related environments, with encrypted and authenticated wipe execution.

4. Review implementation evidence such as remote wipe logs, approval workflows, technical configurations, and integration with incident response documentation.

5. Verify that remote wipe tools are securely managed and that staff are trained to execute and audit wipe actions effectively.

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.

Auditing Guidelines for AI Customers (AIC)

1. Verify that the AI Customer has a documented Third-Party Endpoint Security Policy or Agreement, approved under formal governance, defining clear roles and responsibilities.

2. Inspect whether the policy mandates vendor risk assessments, requires contractual endpoint security measures, enforces continuous monitoring and compliance reporting, mandates prompt incident reporting, defines offboarding processes, and references applicable regulations.

3. Confirm that the policy includes risk-based segmentation and access controls and requires security measures equivalent to internal standards for AI-related data handling.

4. Review implementation evidence such as vendor contracts, risk assessments, compliance dashboards, incident reports, offboarding records, and certifications.

5. Verify the effectiveness of third-party endpoint security by reviewing audit documentation, monitoring evidence, and vendor attestations of compliance with security standards.