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

1. Verify that policies are defined for each cloud environment in use (e.g., public cloud, private cloud, hybrid) and tailored to the deployed AI capabilities.

2. Confirm that audit procedures are embedded in DevOps or MLOps pipelines (e.g., pre-deployment security scans, model versioning logs).

3. Check if cloud-native logging provided by the cloud platform in use (e.g., AWS CloudTrail, Azure Monitor) is formally documented and utilized in policy.

4. Validate that AI-enabled features and components are explicitly included in routine penetration testing and security control audits.

5. Confirm updates are based on app stack changes, new AI functionalities, and cloud provider shifts (e.g., new services or configurations).

A&A-02: Independent Assessments

Control Specification

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

Auditing Guidelines for Application Providers (AP)

Objective: Ensure that the user-facing and back-end components of AI applications hosted on cloud platforms are reviewed independently, including aspects like data processing, API integration, and front-end behavior.

1. Obtain Assurance Reports (e.g., SOC 2, ISO 27001, CSA STAR): Check if AI-specific risks were part of the scope.

2. Verify Audit Trail for Cloud Resources: Validate that application hosting environments (e.g., AWS, GCP, Azure) have undergone separate cloud security audits.

3. Check Standards Alignment: Are assessments mapped to NIST SP 800-53, ISO 27017 (cloud), or CSA CCM?

4. Inspect Shadow Review Practices: Look for records of red teaming or penetration testing done by independent specialists.

5. Validate Annual Review Cadence: Ensure application-level controls are subject to independent audits at least once every 12 months.

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

1. Inspect AI component integration plans and risk assessments and the risk-based audit plan/policy to confirm AI-enabled application features and third-party dependencies are in scope and scheduled/covered commensurate with risk.

2. Evaluate whether risk-based decisions lead to appropriately scoped independent audit/assurance assessments for higher-risk application areas/components.

3. Verify independent audit/assurance evidence and results, including supporting testing for functionality, performance, and security.

4. Verify that significant changes or emerging risks trigger new or updated independent assessments (or scope updates).

5. Determine whether AI feature integrations into applications are audited for risk exposure (e.g., explainability gaps, integration bugs, misuse).

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

1. Map Legal/Contractual Obligations (e.g., GDPR, CCPA, accessibility laws (WCAG), licensing terms of underlying models): Examine the process used to identify relevant standards, regulations, legal, contractual, and technical requirements applicable to the audit scope.

2. Check Privacy/Security Certifications: Look for ISO 27001, SOC2, or security posture alignment. Determine if the organization maintains and reviews a list of relevant standards, regulations, legal/contractual, and statutory requirements (including AI-specific regulations that must be met).

3. Review SLAs/Contracts: Identify whether contractual obligations specify compliance with standards or specific laws.

4. Audit Testing Records: For user-facing systems, inspect whether accessibility and usability testing was conducted under legal guidance.

5. Determine if the audit plan is informed by the list of the organization’s requirements.

6. Assess Incident Handling: Determine how legal violations (e.g., IP infringement or data misuse) are identified and resolved.

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

1. Inspect Audit Charter and Scope: Is AI functionality explicitly included in scope? The audit management process should align with relevant auditing standards and focus on AI feature integration, API usage, interface security, and data handling.

2. Check Planning Documentation: Are AI components audited during release cycles or through separate security audits?

3. Verify Control Coverage: Confirm inclusion of user interface controls, input/output validation, and privacy impact assessments.

4. Assess Findings Lifecycle: Track how issues are triaged, assigned, remediated, and validated.

5. Analyze Report Reusability: Are past audits referenced in new planning or lessons learned?

6. Evaluate if audits address privacy-by-design, access control, and change management.

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

1. Review the remediation process and confirm that issues are addressed according to criticality through appropriate measures (e.g., patches, code updates, configuration changes, or policy adjustments), and that fixes are verified post-deployment. Verify that remediation actions are prioritized and tracked based on assessed risk levels.

2. Inspect documentation trails to confirm that each finding is tied to a documented remediation plan with timestamps, status, assigned owner, and completion evidence.

3. Evaluate whether proposed fixes are reviewed and approved through formal workflows, such as DevSecOps reviews or change advisory boards.

4. Evaluate whether applied fixes comprehensively address the identified issues, including security, privacy, and user transparency concerns.

5. Examine whether remediation progress is regularly tracked and communicated to relevant stakeholders using dashboards, reports, or equivalent mechanisms, and that such updates are documented.

6. Review how lessons learned from remediation activities are used to improve development pipelines, policies, and team awareness, reducing recurrence of similar issues over time.

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

1. Examine Policy Depth: Does the application security policy cover front end (UI), back end (APIs), and AI-specific behaviors.

2. Review audit trails of past updates to security procedures, especially after new feature releases or integration of new models.

3. Check whether regular scans (e.g., DAST, SAST) and patching procedures are documented and followed.

4. Verify Secure Development Practices: Verify the existence of secure coding guidelines and evidence that SDLC policies are enforced (e.g., input validation, sanitization).

5. Evidence of Periodic Review: Verify whether the policy is periodically reviewed or updated (e.g., logs, version history, modification date).

6. Evidence of Review Under Special Circumstances: Inspect whether it is reviewed or updated after significant system changes occur that could impact risk exposure (e.g., change control board minutes, service ticket, management review minutes).

AIS-02: Application Security Baseline Requirements

Control Specification

Establish, document and maintain baseline requirements for securing applications.

Auditing Guidelines for Application Providers (AP)

1. Verify that documented security baselines exist for all AI application types (e.g., prompt-based apps, agents, plugins, generative interfaces) and that they are tailored to architecture, functionality, and risk level.

2. Determine whether applications are classified using criteria such as data sensitivity, business impact, AI-specific architecture, and regulatory exposure, and whether the security baseline adapts to classification levels.

3. Assess whether security baselines effectively address key AI-specific risks (e.g., prompt injection, insecure plugin interfaces, weak access control) and are aligned with legal, regulatory, and industry frameworks (e.g., GDPR, NIST AI RMF, OWASP AI Top 10). Include consideration for supply chain and dependency risks.

4. Examine system configurations, secure defaults, and third-party integration settings to confirm that security baselines are actively enforced, including secure API handling, IAM controls, and vulnerability management workflows.

5. Verify that baselines are reviewed at least annually or upon significant system changes. Confirm that updates reflect evolving threats, regulatory shifts, and learnings from prior incidents or assessments. Confirm that control effectiveness is revalidated accordingly.

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

1. Confirm metrics for AI application features, such as prompt rejection rates, plugin misuse attempts, or rate-limited inputs.

2. Verify tracking of front end/API security controls (e.g., authentication failures, invalid prompt inputs, XSS filters triggered).

3. Evaluate use of user behavior metrics to detect abuse or unintended feature usage.

4. Review how security metrics impact deployment decisions or UI feature adjustments.

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

1. Understand the Application Scope: Interview engineering and security leads to clarify: What kinds of AI applications are being developed (e.g., prompt-based, agentic, plugin-enabled)? What is their architectural model (e.g., browser-based, mobile, serverless)? What AI models or APIs are integrated (e.g., internal models, third-party LLMs)?

2. Review and Verify the SDLC Policy: Obtain the documented Software Development Lifecycle (SDLC). Confirm that it is formally approved and version-controlled; covers all phases of requirements, design, development, testing, deployment, operations; defines security responsibilities (e.g., secure design leads, AppSec reviewers); and includes AI-specific governance practices where applicable.

3. Assess the content of the SDLC:

   • a. Threat Modeling: Verify that the SDLC requires threat modeling for AI-specific risks, such as: prompt injection, model misuse or chaining attacks, data leakage through output responses.

   • b. Secure Coding and Prompt Engineering: Confirm standards exist for: secure prompt construction, input validation for user-generated prompts, defense against prompt-based attack vectors.

   • c. Open Source and Third-Party Code Management: Check for OSS licensing compliance, vulnerability scanning (e.g., SCA tools like Snyk, Black Duck), procedures for evaluating AI SDKs and plugins.

   • d. Vulnerability Management: Review whether code scanning (SAST/DAST) is integrated, tickets are tracked and resolved within SLA, AI-specific vulnerabilities (e.g., insecure LLM usage) are logged and addressed.

   • e. Security Testing: Confirm regular testing activities, such as adversarial prompt testing, penetration testing (manual or tool-assisted), red team simulations targeting AI flows.

   • f. Secure Deployment: Validate use of CI/CD pipelines with integrated security gates, secrets and tokens stored securely (e.g., vault, KMS), IaC templates for environment provisioning.

   • g. Key and Secret Management: Confirm controls around: token generation, rotation, and revocation, role-based access to secrets, audit trails for access/use of sensitive deployment credentials.

4. Validate Compliance with Best Practices: Compare practices against (e.g., OWASP AI/LLM Top 10, NIST AI RMF, ISO/IEC 27034, CSA CCM v4.0.1) Check if there’s alignment with industry norms and whether exceptions are documented.

5. Review Evidence of Implementation: Ask for sample artifacts, such as secure prompt templates or prompt logic, Git commits with security annotations, SBOMs and SCA reports, deployment scripts or IaC configurations, security test reports (e.g., adversarial test logs). Ask for evidence of SDLC in action: Completed threat models (e.g., STRIDE or PASTA), issue tracking tickets for discovered vulnerabilities, change approvals for AI-related releases, access control logs and code review workflows.

6. Inspect Monitoring and Feedback Loops: Confirm mechanisms exist to measure SDLC effectiveness: metrics for secure code coverage, failed security gates in CI/CD, incidents linked to coding or deployment failures. Review whether lessons from: security incidents or testing results are used to refine the SDLC.

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

1. Verify that an AI-specific security testing strategy exists that covers application logic, AI components (e.g., LLMs, ML models, training data), APIs, and user interactions.

2. Verify that continuous and automated AI/ML security testing is integrated into CI/CD pipelines and infrastructure change management.

3. Confirm that security tests cover AI/ML-specific threat scenarios, such as prompt injection, data exfiltration through model output, and misuse simulation.

4. Verify that test results are tracked.

5. Ensure that the detected issues are remediated and result in security control improvements.

6. Ensure alignment with relevant AI security standards (e.g., OWASP LLM Top 10, NIST AI RMF) and that the AI/ML security testing are periodically reviewed.

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

1. Review SDLC and Deployment Standards: Analyze written policies and check for stage gating (dev > test > prod), role-based approvals, and secure defaults.

2. Evaluate CI/CD Pipeline Security: Inspect pipelines for build-time security checks (e.g., SAST/DAST), dependency pinning, and image signing.

3. Check Runtime Configuration Management: Configurations (e.g., LLM endpoint URLs, tokens, prompt injection guards) must be secure and consistent. Review how configurations are passed (e.g., through environment variables, through secrets managers) and confirm access restrictions.

4. Examine Deployment Strategies (e.g., Canary, Blue/Green): Deployment strategies mitigate risk during new AI feature rollouts. Ask for recent deployment examples, metrics from canary runs, and rollback test results.

5. Audit Logging and Monitoring Setup: Check that setup ensures traceability of issues linked to AI components in production. Check for logs tagged with deployment version, LLM invocation tracking, and error monitoring (e.g., Sentry, Prometheus).

AIS-07: Application Vulnerability Remediation

Control Specification

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

Auditing Guidelines for Application Providers (AP)

1. Verify Secure Coding Standards and Developer Training: Review policies requiring OWASP-aligned practices and developer security training.

2. Evaluate Vulnerability Scanning in Build Pipelines: Application codebases should be automatically scanned for known issues. Inspect integration of SAST/DAST tools (e.g., SonarQube, Veracode) in Git pipelines.

3. Confirm Prompt Injection and LLM-Specific Attack Handling (e.g., for prompt injection, prompt chaining): Review test cases or guardrails applied to prompts and generated content.

4. Assess Patch Management for Frontend/Backend Components as patching should be quick, traceable, and testable. Request patch timelines and rollback plans for previous releases.

5. Audit Automation of Remediation Decisions: Check tools like Renovate, and auto-merge policies for low-risk patches.

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

1. Verify that measures and processes exist to secure APIs.

2. Assess the processes for adequacy and relevance by checking to ensure the processes include the following: secure user authentication, API key management, key mitigations against API abuse or DDoS (e.g., authentication, authorization, rate limiting, WAF), and safeguards against client-side attacks (e.g., XSS, CSRF, prompt injection).

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

1. Verify that the AP has detailed processes and controls for input validation specifically tailored to detect and mitigate AI-specific adversarial input scenarios, such as linguistic logic manipulations, coding injections, adversarial tokens, multimodal, multilingual and so on. Confirm that the documentation provides clarity and is comprehensive.

2. Verify the technical input validation solutions against AI-specific threats, such as linguistic manipulations, logic attacks, coding injections, adversarial tokens, multimodal and multilingual attacks, and so on. Confirm that the input validation solutions are regularly updated to cover the evolving AI threat landscape.

3. Confirm that AI-specific Red Teaming assessments are periodically performed and that they reflect adversarial techniques targeting AI applications, including complex, multilingual, multimodal, and token-level manipulations.

4. Verify that the Red Teaming reports account for comprehensive identification and documentation, and ensure that improvements address newly discovered issues and AI-specific input validation controls.

5. Verify the effectiveness of the input validation monitoring control and that the effectiveness is reviewed regularly.

6. Ensure that validation controls are periodically reviewed for addressing evolved AI threats and issues discovered by the Red Teaming exercises.

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

1. Verify that the AP has defined and implemented processes and technical controls for validating AI-generated outputs for protecting against risks such as insecure output handling, excessive agency behaviors, and adversarial outputs. Ensure that comprehensive and clear documentation for it exists.

2. Verify that technical output validation measures are in place that are designed to detect unsafe outputs and cover OWASP insecure output handling scenarios (e.g., injection, XSS) for protecting against excessive agency (i.e., autonomous harmful actions) and adversarially manipulated content.

3. Confirm that AI-specific Red Teaming exercises are conducted regularly and that these are targeting unsafe AI outputs, insecure output handling risks (as described by OWASP), excessive agency exploits, and adversarial output scenarios.

4. Review Red Teaming findings and ensure identified risks from unsafe, insecure, or adversarial outputs are documented and translated into process or technical improvements to strengthen the output validation.

5. Monitor the effectiveness of the output validation control. Ensure that metrics targeting unsafe and adversarial AI outputs are defined and regularly reviewed.

6. Ensure that output controls are regularly reviewed and updated when needed to better protect 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 Application Providers (AP)

1. Verify that agent roles, authorized actions, and accessible APIs are formally defined, documented, approved, and communicated as part of the AP’s security policies. Request a list of agent roles, the APIs they can call, and the actions they are authorized to perform within the application context.

2. Verify technical enforcement of agent boundaries (e.g., through containerization, API proxy filters, or equivalent isolation mechanisms) to ensure agents cannot exceed their intended environment.

3. Review prompt hardening and input validation techniques (e.g., static tokens, escape character filters, context-limiting) to prevent agents from being reprogrammed or misused through user inputs.

4. Inspect monitoring and audit logs for unauthorized actions, unapproved tool invocations, or behavior drift, and confirm that violations trigger investigation.

5. Evaluate whether user override mechanisms or step-wise confirmations are implemented for agent actions in sensitive domains.

6. Assess whether monitoring results and detected violations are reviewed and incorporated into updates to boundary definitions and controls.

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

1. Version Control Validation: Confirm that version control is implemented for all client and server‑side code integrating AI models, and ensure that changes are properly tracked and managed.

2. Code Review for Model Interfaces: Verify that peer reviews are conducted for code interfacing with AI models (e.g., APIs, SDKs), ensuring that secure API calls to Model Providers (MPs) or Orchestrated Service Providers (OSPs) are enforced. Review evidence of code review logs, comments, and approvals to confirm consistent implementation.

3. Static Code Analysis: Assess whether static code analysis tools are used to detect vulnerabilities in model integration logic (e.g., input/output sanitization, error handling), and review findings and follow‑up actions.

4. SDLC Alignment: Confirm that version control, code reviews, and static analysis practices are defined and referenced within the AP’s SDLC documentation (AIS‑04) and that they are integrated into testing and deployment phases of the development pipeline.

5. Evidence Review: Examine a representative sample of integration tickets, code review records, API interaction code versions, and static analysis logs to validate consistent application of SCM controls in practice.

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

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. Engage with 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 requirements based on risk classification; resource limitation 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. Technical Implementation Review

   1. Sandboxing Implementation Review: Examine technical documentation to verify the design and enforcement of sandboxing controls, specifically: containerization or virtualization technologies used for isolation; resource limitation mechanisms (e.g., CPU, memory, network, storage); time constraints and execution timeouts; 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.

   2. Sandbox Escape Prevention Mechanisms: Assess controls 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 (JIT) compilation restrictions; browser security model implementation (for web-based AI applications); system call filtering and restriction; and container security hardening measures.

   3. Plugin/Extension Security Management: Review the procedures in place for securing plugins and extensions, 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.

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

4. 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, and 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: 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.

AIS-14: AI Cache Protection

Control Specification

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

Auditing Guidelines for Application Providers (AP)

Focus: The AI Application Provider has implemented effective security measures to protect caches in their generative AI applications, ensuring both performance optimization and protection of sensitive user data, generated content, and model interactions.

1. Inquiry with Control Owners

   1. Interview Application Development and Security Leadership: Interview product managers, application architects, and security engineers responsible for AI application development and cache implementation. Obtain and review the organization’s caching strategy and security policies covering prompt history caching, generated content storage, embedding caches, model response caching, and user preference storage. Verify documented security requirements exist for cache access controls, encryption of cached content, cache invalidation strategies, and handling of sensitive user information in cached data.

   2. Review Caching Implementation Details: Examine documentation describing the technical implementation of caching within the AI application, including client-side caching, server-side response caching, distributed cache services, content delivery networks, and database query caching. Assess how user-specific cached content is isolated, how session data is protected, and how model integration responses are securely cached across different application components.

   3. Assess Cache Data Privacy Controls: Review mechanisms implementing privacy for cached user interactions and AI-generated content, including user identification in cached data, personal information handling, data retention limits in caches, consent-based caching, and right-to-be-forgotten implementation in cache systems. Evaluate how conversation history, prompt templates, and personalized model responses are secured within application caches.

   4. Evaluate Cache Management and Security Monitoring: Review procedures for cache lifecycle management, including invalidation triggers upon model updates, user profile changes, content policy updates, and security incident response. Assess monitoring systems for cache access patterns, anomaly detection, unauthorized access attempts, and indicators of cache poisoning or manipulation of AI application data stores.

2. Obtaining and Verifying the Population of Records

   1. Define the Complete Population of Cache Components: Obtain a a comprehensive inventory of caching mechanisms within the AI application, including browser-based caches, CDN caching layers, API response caches, prompt history stores, embedding caches, generated content caches, user preference caches, and model response optimization caches. Include caching services, libraries, infrastructure components, and database caching layers used throughout the application stack.

   2. Verify Population Completeness: Cross-reference the cache inventory against application architecture documentation, dependency lists, infrastructure configurations, API specifications, and data flow diagrams. Ensure the inventory aligns with performance optimization strategies, application monitoring metrics, scalability documentation, and user data handling processes to confirm completeness of cache component identification.

   3. Categorize Cache Components by Risk Level: Segment the cache component population based on sensitivity of data cached, user specificity, persistence duration, cache location (client-side vs. server-side), accessibility to third parties, volume of data stored, and potential impact if compromised. This risk-based categorization should guide the depth and frequency of security assessment for each caching component.

3. Inspection of Evidence

   1. Cache Implementation Security Review: Select a representative sample of application caching mechanisms based on risk levels and verify the implementation of security controls, data protection measures, and access restrictions. Examine cache configurations in CDNs, memory stores, browser storage, and database layers. Verify encryption of sensitive cached content, implementation of cache partitioning between users, and access control enforcement for cached AI interactions.

   2. Cache Data Protection Assessment: Review evidence of data protection measures for cached content, including encryption of cached user interactions, anonymization of user identifiers in shared caches, secure handling of embedded credentials, and proper scoping of cached content to authorized sessions. Evaluate how generated content is protected from unauthorized access, how embedding caches maintain user data boundaries, and how prompt history is secured within the application.

   3. Cache Invalidation and Refresh Controls: Verify implementation of cache invalidation mechanisms triggered by content updates, model version changes, user preference modifications, security policy updates, and potential security incidents. Assess cache expiration policies, time-to-live settings appropriate to content sensitivity, forced refresh mechanisms, and version-tagged cache entries that prevent serving stale AI-generated content.

   4. Cache Access Controls and Monitoring: Assess controls for cache access including authentication requirements for accessing personalized caches, authorization verification before serving cached content, session validation for cached interactions, and tenant isolation in multi-user environments. Evaluate monitoring systems for cache access patterns, detection of unusual retrieval behaviors, and audit logging of sensitive cache operations.

   5. Protection Against Cache-Specific Attacks: Examine the implementation of protections against cache poisoning, injection of malicious content into caches, side-channel attacks using cache timing, and cross-user data leakage. Assess input validation before caching, output sanitization of cached content, protection against cache probing attacks, and defense mechanisms for shared cache environments.

   6. Cache Security Incident Response: Review documentation and evidence of cache-related security incident procedures, data exposure response playbooks, and user notification processes. Evaluate how potentially compromised caches are identified, how cached content can be selectively purged, and how security incidents involving caches are investigated. Assess recovery procedures and post-incident security enhancement processes for application caching.

   7. Compliance and Privacy Considerations: Verify the adequacy of cache compliance controls for user data privacy regulations, content retention policies, data subject rights implementation, and geographic data storage requirements. Evaluate how right-to-be-forgotten requests are propagated to caches, how data residency requirements are maintained for distributed caches, and how user consent is respected in caching strategies.

4. Evaluation and Reporting

   1. Cache Security Effectiveness Assessment: Evaluate how well cache security implementations protect user data and AI interactions while maintaining application performance. Assess the balance between caching for performance optimization and appropriate security controls based on data sensitivity. Evaluate the effectiveness of defenses against unauthorized access, data leakage between users, and cache-targeted attacks.

   2. Cache Protection Strategy Assessment: Assess the effectiveness of cache protection strategies based on deployment architecture, user interaction patterns, content sensitivity, and application scaling requirements. Evaluate whether security controls are proportionate to the risks of each cache type and whether defense-in-depth is implemented for the most sensitive cached content.

   3. Documentation and Process Adequacy: Evaluate the quality of cache-related security documentation, including clarity of caching architecture, completeness of security controls, cache data lifecycle management, and incident response procedures. Assess whether documentation is maintained as application caching strategies evolve to support new AI capabilities and performance requirements.

   4. Continuous Improvement Mechanisms: Evaluate processes for improving cache security through regular security testing, incorporation of lessons learned from incidents, adaptation to new caching technologies, security architecture reviews, and vulnerability management. Assess whether the organization demonstrates a commitment to continuously enhancing cache protection as application usage scales and new attack vectors emerge.

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

Focus: The AI Application Provider has implemented effective mechanisms enabling their AI models to clearly distinguish user-provided input instructions from data and system instructions, protecting against prompt injection and ensuring consistent application behavior.

1. Inquiry with Control Owners

   1. Interview product managers, UX designers, and application engineers responsible for AI feature implementation and prompt engineering. Obtain and review the organization’s prompt construction architecture, including: system prompt design and management strategies, user input handling frameworks, prompt template implementation, instruction separation techniques, input validation pipelines, security measures against prompt manipulation. Verify documented design patterns exist for clearly delineating user content from system instructions through technical mechanisms such as special tokens, structural formatting, or framework-specific separation techniques.

   2. Review Prompt Construction Implementation: Examine documentation describing the application’s prompt engineering approach, including server-side prompt assembly architecture, client-side user input constraints, instruction boundary enforcement mechanisms, prompt sanitization and validation workflows, system instruction protection techniques, visual and structural demarcation between user and system content, and assess how prompt templates are designed, stored, and combined with user inputs while maintaining clear boundaries between instruction types.

   3. Assess Input Validation and Sanitization: Review mechanisms implementing input validation for AI interactions, including special character and delimiter handling, pattern matching for instruction-like content, input length and format validation, context preservation techniques, character encoding normalization, and role-based input restrictions. Evaluate how the application prevents user inputs from being interpreted as system-level instructions or manipulating the underlying model behavior.

   4. Evaluate User Interface Design: Review how the application’s user interface supports instruction separation through: visual differentiation of input fields, clear labeling of user content areas, contextual guidance for appropriate inputs, input field constraints and validation, preview mechanisms showing processed input, and feedback indicators for input acceptance.

2. Obtaining and Verifying the Population of Records

   1. Define the Complete Population of AI Features: Obtain a comprehensive inventory of application features using AI models, including content generation tools, chatbot interfaces, code assistance features, creative tools with AI components, document analysis capabilities, AI-powered search and retrieval functions, data analysis with AI assistance, and language translation features.

   2. Verify Population Completeness: Cross-reference the AI feature inventory against product documentation and marketing materials, feature roadmaps and release notes, application codebase structure, API endpoints interfacing with AI models, user interface components for AI interaction, back-end services constructing prompts, customer support knowledge bases, and ensuring the inventory covers all application components where user inputs are incorporated into AI model prompts.

   3. Categorize AI Features by Risk Level: Segment the AI features based on level of user input freedom, complexity of instruction sets, sensitivity of generated content, user authentication requirements, enterprise vs. consumer usage, integration with other systems, volume of usage and user base size. This risk-based categorization should guide assessment depth for each AI feature.

3. Inspection of Evidence

   1. Prompt Construction Implementation Review: Select a representative sample of AI features based on risk levels and verify explicit boundary implementation, examine how the application establishes clear boundaries between user inputs and system instructions through techniques such as specific delimiter tokens surrounding user content, named parameter structures for user inputs, JSON or XML formatting for structured separation, framework-specific separation mechanisms (e.g., ChatML format), role-based message structures (system/user/assistant), and system instruction protection. Verify that system instructions are stored separately from user input processing, combined with user inputs only at prompt creation time, never exposed to users in raw form, protected from modification through application logic, and versioned and managed through controlled processes. Review input validation implementation by confirming robust validation of user inputs including: removal or escaping of potential instruction markers, detection of attempts to inject system commands, handling of edge cases like delimiter-like content, normalization of inputs before prompt construction, and contextual validation based on input purpose.

   2. Frontend-Backend Boundary Assessment: Review how the application maintains separation between user interface and prompt construction. For Server-Side Prompt Construction, verify that complete prompts are assembled server-side where: user inputs are received as discrete parameters, system instructions are injected from secure sources, final prompt construction occurs in controlled environments, and no client-side exposure of full prompt templates exists. For Input Field Design Analysis, examine user interface components to confirm: clear visual distinction of user input areas, appropriate input constraints based on context, validation feedback for potentially problematic inputs, and guidance that reinforces input/instruction separation.

   3. Security Testing for Separation Effectiveness: Perform targeted testing of instruction separation mechanisms. For Boundary Testing, attempt to bypass instruction separation through: injecting delimiter sequences in user inputs, providing instruction-like content in data fields, manipulating input encoding to bypass filters, using special characters or escape sequences, and submitting unusually formatted or structured content. For Model Response Analysis, evaluate model outputs to verify: consistent adherence to system instructions regardless of user input, proper handling of edge cases without instruction confusion, resistance to attempts to override system constraints, and appropriate behavior when receiving ambiguous inputs.

   4. Documentation and Training Assessment: Review supporting materials for proper instruction handling. For Developer Documentation, verify existence and quality of: prompt engineering guidelines, input validation requirements, instruction separation best practices, security considerations for AI features, template management procedures. For User Guidance Implementation, assess how the application guides users to provide appropriate inputs through: clear labeling of input fields, example inputs demonstrating proper format, contextual help explaining input purpose, feedback when inputs may be problematic.

   5. Framework and Library Integration: Evaluate the application’s use of AI frameworks that support instruction separation. For Framework Utilization, verify proper implementation of framework-specific features like: OpenAI’s message role separation (system/user/assistant), Anthropic’s Human/Assistant format, HuggingFace’s instruction formatting, and other model-specific instruction separation conventions. For Library Security Assessment, review AI integration libraries for secure defaults for instruction handling, proper implementation of model-specific formats, regular updates to address known vulnerabilities, and appropriate error handling for boundary violations.

4. Evaluation and Reporting

   1. Separation Effectiveness Assessment: Evaluate how well the implementation maintains clear boundaries between input types, prevents user content from being interpreted as instructions, ensures consistent model behavior across varied inputs, balances security controls with user experience, and addresses model-specific instruction handling requirements.

   2. Architectural Strategy Assessment: Assess the effectiveness of the overall approach based on appropriateness for the application’s use cases, defense-in-depth implementation against prompt injection, consistency across different AI features, alignment with industry best practices, and evolution to address emerging prompt manipulation techniques.

   3. Documentation and Process Adequacy: Evaluate the quality of instruction separation documentation, including clarity of prompt engineering guidelines, the completeness of security controls, template management procedures, and ongoing validation processes.

   4. Continuous Improvement Mechanisms: Evaluate processes for enhancing instruction separation through regular security testing of boundary mechanisms, monitoring for unusual model behavior, adaptation to new prompt injection techniques, integration of enhanced separation mechanisms, and knowledge sharing across development teams.

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

1. Review BCM scope: Web/mobile app uptime requirements, continuity of secure API calls to AI services, user-facing failure-handling procedures.

2. Request evidence of documented fallback workflows (e.g., user warnings, degraded services), backups, and redeployment procedures for application components.

3. Assess the last tabletop test simulating application outages and coordination procedures with Model Providers and orchestrators for incident impact assessment.

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

1. Assess the Scope of the Impact Analysis: Confirm inclusion of AI-specific disruptions: prompt injection leading to brand/reputational damage, latency spikes or hallucinations impacting critical functionality, dependency risks from upstream AI APIs.

2. Review Integration Dependencies: Ensure BIA includes downstream and upstream service dependencies (e.g., LLMs, data services).

3. Verify Documentation and Review Triggers: BIA/risk registers are updated after new features added, model or API version updates occur, or changes in user access volumes or geographies.

4. Inspect Supporting Documentation: Threat matrices, incident impact analyses, fallback plan documentation.

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

1. Verify that the business continuity strategy includes contingency planning for AI-driven service interruptions.

2. Confirm detailed mapping of critical application components and their dependencies, including third-party integrations.

3. Check for established fallback procedures for application layer outages affecting end-users.

4. Ensure incident impact assessments include risks from AI model behaviors.

5. Validate coordination mechanisms with OSP and MP during continuity planning exercises.

6. Confirm regular testing of AI application failover strategies under simulated disruption conditions.

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

1. Confirm a documented and approved Business Continuity Plan (BCP) exists, aligned with the operational resilience strategy specific to AI applications.

2. Verify that the BCP includes scenarios involving model inference unavailability, UI/API degradation, and dependency outages (e.g., ML pipelines, orchestration).

3. Check procedures for restoring user-facing services and integrations (e.g., dashboards, APIs, third-party tools) following disruptions.

4. Confirm contingency plans for critical AI-based services with SLAs (e.g., autonomous decision engines, fraud detection).

5. Validate periodic simulation or tabletop exercises testing BCP effectiveness in recovering AI-based services.

6. Ensure the BCP includes escalation paths, roles, and fallback responsibilities for cross-functional teams.

7. Check for documented change management updates to the BCP after major AI application or cloud infrastructure changes.

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

1. Confirm that the AP maintains a centralized repository of business continuity and operational resilience plan relevant to AI applications, APIs, and user interfaces.

2. Verify that architecture diagrams, data flow charts, and dependency maps related to application continuity are clearly documented and up to date.

3. Check that documentation includes recovery procedures for front-end services and APIs that rely on AI services.

4. Ensure third-party dependency documentation (e.g., ML inference APIs, orchestration tools) is collected and linked to continuity plans.

5. Validate that access to documentation is restricted to authorized personnel and reviewed at least annually.

6. Confirm documentation includes previous incident reports, lessons learned, and remediation updates related to business continuity.

7. Check if documentation updates are integrated into onboarding and incident response playbooks for DevOps and SRE teams.

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

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 application-specific failure modes, dependency service outages, data access issues, and user experience during degraded operations.

5. Review exercise results to confirm that recovery procedures for application components were successfully tested and that application functionality and user experience were validated after recovery.

6. Assess whether exercises included testing of application degradation modes, fallback mechanisms, and offline capabilities where applicable.

7. Verify that exercises tested the application’s ability to handle API failures or performance degradation from back-end AI services.

8. Examine evidence that user notification mechanisms and service status communications were tested during exercises.

9. Confirm that exercise results, including user experience metrics during recovery, were reviewed by application management and that improvement actions were tracked to completion.

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

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 the implementation of user-facing communication mechanisms such as status pages, in-app notifications, email alerts, or social media updates for service disruptions.

6. Review evidence of communication templates prepared for different service disruption scenarios, ensuring they provide clear, non-technical explanations appropriate for end-users.

7. Assess the AP’s procedures for obtaining accurate recovery information from upstream providers and translating it into meaningful user updates.

8. Verify that customer support teams are trained on communication protocols during service disruptions and can access current service status information.

9. Review records from past service incidents or exercises to confirm timely, clear communication with users and appropriate management of expectations regarding resolution timeframes.

10. Confirm that the AP has established procedures to verify communication effectiveness with users during disruptions, such as monitoring support ticket volumes or feedback channels.

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

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 application-level backup mechanisms through configuration reviews and system logs, confirming coverage of both system components and user-generated content.

8. Assess backup strategies for maintaining application state consistency, particularly for distributed applications with user-facing components and back-end AI integrations.

9. Review procedures for protecting user data confidentiality in backups, including data anonymization or pseudonymization where appropriate.

10. Examine documentation and test results demonstrating successful application restoration, including verification that user data integrity and application functionality are maintained after recovery.

11. Verify that backup validation includes testing AI service integration points to ensure restored applications can successfully interact with model providers and orchestration services.

12. Assess backup retention and deletion procedures to confirm alignment with data governance requirements and user data privacy policies.

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

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

2. Examine the policy 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, with evidence of review and sign-off, from leadership responsible for application development and operations.

5. Assess the defined recovery strategies for different application components based on criticality to end-user functionality.

6. Review documentation of user communication procedures during disasters, confirming plans for transparent status updates and expected resolution timeframes.

7. Verify that the plan includes procedures for operating in degraded modes when full back-end AI services are unavailable, including clearly defined fallback capabilities.

8. Examine evidence that the disaster response plan has been communicated to all relevant application development, operations, and support personnel, including training records.

9. Review records of application recovery tests conducted within the past 12 months, confirming they included validation of the user experience after recovery.

10. Verify that the plan is reviewed and updated at least annually and after significant application changes or new AI service dependencies 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 Application Providers (AP)

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 the recovery of different application components and features based on their criticality to end-user functionality.

6. Review exercise documentation to confirm that user experience and application functionality were validated after completing recovery procedures.

7. Assess whether exercises tested user communication procedures during outages, including status notifications and expected resolution timeframes.

8. Verify that exercises included scenarios for operating applications in degraded modes when complete back-end AI services are unavailable.

9. Confirm that exercises included coordination with back-end service providers to simulate realistic recovery sequences and dependencies.

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

11. Verify that additional exercises were conducted following significant application changes, new feature additions, or modifications to back-end service dependencies.

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

1. Examine the process to identify business-critical equipment and any redundant equipment.

2. Examine the process to identify applicable industry standards.

3. Evaluate if the redundant business-critical equipment is independently located at a reasonable distance.

4. Verify that redundant application equipment is deployed across separate environments following relevant industry standards and application availability requirements.

5. Review the implementation of load balancing and traffic distribution mechanisms that direct user requests across redundant application instances.

6. Assess database redundancy and replication configurations that maintain application data consistency across redundant storage systems.

7. Verify the redundancy of authentication services and user management systems that support application access.

8. Examine automated scaling and resilience capabilities that provision additional application resources during peak demand or equipment failures.

9. Review records of application functionality tests across redundant environments, confirming a consistent user experience when primary equipment is unavailable.

10. Verify that the AP has validated the redundancy of the underlying infrastructure and platform services on which applications depend, rather than directly managed equipment.

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

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

1. Verify the AP maintains a formal process for approving and testing AI application changes, aligned with secure software development practices. Confirm governance includes clear roles, responsibilities, and sign-off procedures (e.g., product, legal, security, ethics).

2. Select a representative sample of AI-related releases (e.g., major features, prompt updates, model integrations). For each, confirm: testing covered content quality, bias/fairness, edge cases, and failover behavior; stakeholders (e.g., product, QA, legal, security) approved changes before release; and monitoring and rollback mechanisms were in place post-deployment.

3. Review evidence such as test plans, feedback logs, release notes, prompt templates, model configs, and change logs. Confirm version control is applied to AI-specific artifacts: prompt libraries, UI behavior, content moderation filters, and model integrations.

4. Verify that: updates were released through controlled mechanisms (e.g., feature flags, progressive rollout), A/B testing or canary testing was used to validate new AI functionality, systems are in place for prompt injection prevention, model latency handling, graceful degradation, and human review or fallback is in place for high-risk AI outputs.

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

1. Inquiring with Control Owners: Conduct interviews with change management process owners and review supporting documentation to understand how the organization manages changes to technology assets including applications, systems, infrastructure, configurations, and AI/ML artifacts. Examine documented procedures for change request submission, risk assessment, approval workflows, testing requirements, implementation planning, and post-implementation verification across both internally managed and outsourced technology assets. The technology context of this control would encompass enterprise IT change management systems like ServiceNow, Jira Service Management, or BMC Remedy that track, approve, and document technology changes, configuration management databases (CMDBs), and tools that maintain asset inventories across hybrid infrastructure, version control systems like GitHub, GitLab, or Azure DevOps that manage code and configuration changes, API management platforms that govern changes to service interfaces, and automated testing frameworks that validate changes before deployment.

2. Inspecting Records and Documents: Evaluate AI-specific tools used for prompt management and version control, AI-generated content quality assessment, user satisfaction measurement for AI features, AI model performance monitoring in production, and progressive rollout of AI capabilities. Inspect a representative sample of change records from enterprise change management systems (e.g., ServiceNow, Jira), version control repositories, CI/CD pipeline logs, and AI/ML model registries to verify implementation of appropriate controls. Verify that configuration management databases, automated testing frameworks, cloud infrastructure management tools, and API management platforms are properly utilized to enforce change management procedures regardless of whether assets are managed internally or by external service providers.

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

1. Inquiring with Control Owners

   1. Interview Application Development Management and Product Owners, and Review AI-Specific Access Control Documentation: Interview AI application development teams and product owners, and examine formal documentation to understand authorization requirements. For Access Control and Role-Based Permissions: Access control frameworks for modifying AI-specific components including prompt template libraries, foundation model integration configurations, content filtering and safety mechanisms, and AI feature orchestration; Role-based access for foundation model provider credentials management, prompt template and engineering modifications, fine-tuning dataset management, content moderation rule adjustments, and AI-specific feature flag management; Authorization requirements for AI capability configuration changes, vector database and embedding modifications, and AI performance parameter tuning; Separation of duties between prompt engineering vs. application code development, model integration vs. user interface development, content safety vs. feature development, and AI performance optimization vs. general application development. For AI Feature Development and Integration: User interface components for AI interactions and user experience modifications for AI interactions; New AI capabilities and integrations with foundation model version upgrades; Prompt engineering workflows and optimizations. For Approval Workflows and Governance: Approval workflows for new AI capabilities, foundation model version upgrades, prompt engineering optimizations, content filtering adjustments, and user experience modifications; Governance processes including responsible AI review requirements, content safety impact assessments, performance and cost validation, and user experience testing for AI features; Compliance and legal review triggers.

   2. Review Change Management Documentation: Examine documentation describing: Application Change Management Policies (AI-specific change categories and approval requirements, emergency change procedures for AI components, foundation model version update policies, prompt template version control requirements, testing standards for AI feature changes), Deployment Pipeline Controls (approval gates for AI feature deployments, validation checks for prompt templates, model integration testing requirements, progressive deployment for AI features, monitoring requirements for new AI capabilities), and Feature Flag Management (AI feature progressive rollout policies, emergency kill switch implementations, A/B testing frameworks for AI features, user cohort targeting for AI capabilities, feature flag access controls and audit procedures).

2. Obtaining and Verifying the Population of Records: Obtain a complete inventory of AI applications, including end-user-facing AI tools such as content creation and chatbots, SaaS solutions with embedded AI capabilities, internal tools leveraging generative AI, mobile applications with AI features, browser extensions and plugins with AI functionality, API services providing AI capabilities, and embedded AI features within larger application platforms. Validate completeness, for example, by reviewing application inventories, code repositories, deployment logs, and so on.

3. Inspecting Records and Documents: Select a representative sample of AI applications and obtain the complete list of developers, administrators, and automated systems with rights to deploy application changes or modify AI integrations. Verify that access to change applications is properly restricted by examining repository access controls, reviewing CI/CD pipeline permissions, and confirming that application changes follow proper approval workflows before reaching production environments.

   1. Select Representative Sample: Choose a balanced sample of AI applications based on: different AI capabilities (e.g., content generation, code assistance), various foundation model integrations, range of user bases and industries served, different maturity levels and release frequencies, mix of internal and customer-facing applications, varying risk categorizations, and different deployment platforms (web, mobile, desktop).

   2. Obtain Access Control Information: For each sampled AI applications, collect the complete list of personnel and systems with change capabilities: Development Personnel (prompt engineers, AI/ML engineers, front-end developers for AI interfaces, back-end developers for AI integration, content safety specialists, DevOps engineers for AI infrastructure), Administrative Personnel (product managers for AI features, release managers, AI safety officers, quality assurance testers for AI, customer support with configuration access), and Automated Systems (CI/CD pipelines for AI components, feature flag management systems, A/B testing frameworks, automated performance optimization systems, content filtering update mechanisms).

   3. Validate Access List Completeness: Verify the completeness of access lists through: reviewing script logic for access report generation, cross-referencing with identity management systems, comparing against role definition repositories, validating against authentication logs, reconciling with customer subscription records, and examining API gateway access configurations.

   4. Verify Access Restrictions and AI-Specific Access Controls: For each sampled AI application, confirm that access to change AI components is properly restricted. For Repository and Code Controls: Branch protection for AI component repositories with code review requirements for prompt templates; Access limitations for model integration code and commit signing requirements for sensitive AI components; Access to vector storage (e.g., embeddings database for RAG) and repository access audit logs. For CI/CD Pipeline and Deployment Controls: Approval requirements for AI feature deployments with separation of duties in deployment workflows; Environment promotion controls for AI features and pipeline access restrictions; Deployment approval audit trails. For Feature Flag and Configuration Controls: Access restrictions for AI feature flag modifications with approval workflows for enabling AI features; Audit logging for feature flag changes and emergency disable capabilities with access controls; Feature flag change history tracking. For Foundation Model Integration: API key and credential management with model version pinning changes; Parameter configuration modifications and usage quota with cost control adjustments. For Prompt Engineering: Prompt template version control and few-shot example management; System instruction modifications and prompt testing with validation workflows. For Vector/Embeddings Storage for RAG: Access controls for vector database modifications and embeddings management; Content ingestion and retrieval pipeline access restrictions. For Content Safety: Content filtering rule modifications and safety threshold adjustments; Blocklist/allowlist management and content moderation workflow changes. For AI Feature Orchestration: Workflow definition changes and integration sequence modifications; Error handling and fallback adjustments with service composition changes. For Approval Workflow Validation: Required approvals obtained for AI changes with responsible AI reviews for appropriate changes; Performance testing approvals for model changes and compliance review documentation where required; Emergency change procedures and approvals.

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

1. Inquiring with Control Owners

   1. Conduct interviews with personnel responsible for managing AI application updates and customer deployment changes to understand authorization processes for modifying AI-powered features in customer environments. Verify their understanding of controls that prevent unauthorized changes to application functionality, UI modifications, or AI model behavior that directly impact customer workflows and user experiences.

2. Inspecting Records and Documents

   1. Review AI Application Deployment Change Policies: Evaluate policies governing updates to AI features, prompt handling logic, user interface modifications, and model behavior changes that affect customer environments.

   2. Inspect Customer SaaS Contracts or Terms of Service: Look for restrictions on automatic AI feature updates, changes to model outputs, user interface modifications, or alterations to AI-driven automation workflows.

   3. Assess Customer Rollback or Feature Toggle Mechanisms: Customers should be able to reject, defer, or disable AI feature updates. Review versioning support, feature flags, or customer control panels for such overrides.

   4. Verify AI Feature Change Authorization Processes: Examine documented procedures requiring explicit customer consent before implementing changes to AI functionality, model behavior, or application features that directly impact customer operations.

   5. Review Customer Notification Documentation: Validate that customers receive adequate notice and authorization requests before AI application changes that affect their user experience or business processes.

   6. Examine SLA Compliance for AI Service Modifications: Confirm that AI application changes remain within agreed service level parameters and customer-authorized functional scope.

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

1. Inquiry with Control Owners: Interview key personnel responsible for AI application change management to understand policies, baseline definitions, version control strategies, tools used for managing AI components such as models, embeddings, prompts, code, configurations, and supporting infrastructure.

2. Obtaining and Verifying the Population of Records: Define the complete population of records for testing, including: inventory of AI applications and their business functions, model configurations and integration points, input processing artifacts (e.g., prompts, feature definitions, embeddings), training, fine-tuning, and evaluation datasets, application code repositories and dependencies, user interface elements specific to AI interactions, deployment configurations across environments, performance monitoring and logging configurations, and testing configurations for model or application variations. b) Perform procedures to verify the completeness and accuracy of the obtained population.

3. Inspection of Evidence: a) AI Application Baseline Scope Definition: Verify that clear documentation exists defining what constitutes a baseline for AI components. For Model Components: model provider/architecture and version, model parameters and configuration, training or fine-tuning parameters, input and output specifications. For Application Components: input processing (e.g., prompts, feature processing), output processing and formatting, error handling and fallback mechanisms, user interaction patterns. For Governance Components: content/output filtering configurations, guardrails and safety mechanisms, bias mitigation approaches. For Performance Benchmarks: quality metrics (e.g., accuracy, consistency, relevance), operational metrics (e.g., latency, throughput), user satisfaction metrics. b) AI Application Management Tool Assessment: Examine the implementation and usage of AI asset inventory tools (e.g., CMDB), version control for code and model inputs (e.g., Git, specialized tools), model management tools (e.g., registries, experiment tracking), data and input management (e.g., feature stores, prompt libraries), quality assurance tools (e.g., model evaluation, testing frameworks), deployment and infrastructure tools. c) AI Application Sample-Based Verification: Select a representative sample of AI applications and verify: baseline establishment documentation for each component, version control implementation for all key components, change history completeness across multiple releases, approval documentation for AI component changes, testing and validation of changes before deployment, performance impact assessments after changes. d) Baseline Effectiveness Assessment: Evaluate how well baselines prevent unintended behavior changes, baseline coverage completeness, granularity appropriateness, incident response to model/data changes, and testing procedures effectiveness. e) AI Application Baseline Integrity Controls: Review controls protecting baseline integrity: access controls to AI component repositories, approval workflows for model and application, hash-based integrity verification for artifacts. f) AI Environment and Dependency Baselines: Verify environment baseline management through: library and API version control, environment variables and configurations, dependency management for AI frameworks, containerization of AI components, infrastructure-as-code for AI deployment, feature flags for controlling AI capabilities. g) Integration Between AI Baseline Systems: Assess how different baseline management systems are integrated: connections between repositories and deployment systems, integration between model changes and application updates, synchronization between data assets and model deployments, coordination of AI changes across multiple applications, management of cross-application dependencies.

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

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. 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; 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, accessibility compliance for AI interactions; 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, safety filter effectiveness across diverse inputs; 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, 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, 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, simulate user confusion patterns, and test in multiple languages where supported. 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 Application Providers (AP)

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. 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; 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, accessibility compliance for AI interactions; 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, safety filter effectiveness across diverse inputs; 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, 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, 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, simulate user confusion patterns, and test in multiple languages where supported. 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 acknowledged 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-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 Application Providers (AP)

1. Inquiry with Control Owners

   1. Interview Application Development Teams and Review Rollback Policies: Interview application development managers, DevOps teams, and release engineers responsible for change management and rollback processes, and obtain organizational 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, while verifying documented criteria for 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 and Known Good State Management: For Process Documentation, examine documentation describing rollback planning requirements for all AI application changes, technical rollback mechanisms for different application components including prompt template versioning and rollback, model integration configuration rollback, user interface component restoration, content safety filter configuration rollback, and feature flag rollback capabilities, along with post-rollback validation procedures, user communication templates for rollback scenarios, rollback time objectives for different severity levels, and verification requirements after rollback completion. For Known Good State Procedures, review procedures for establishing and validating known good states including 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.

   3. Evaluate Deployment Architecture: Assess how the deployment architecture supports rollback capabilities through 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, 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 Application Providers (AP)

1. Policy Examination: Verify that the AP’s Cryptography, Encryption, and Key Management (CEK) policy exists and addresses the planning, delivery, and support of cryptographic functions across the application lifecycle. Confirm that the policy includes coverage of data exchanged with large language models (LLMs), such as prompts and completions; the generation, rotation, and destruction of cryptographic keys; standards for encryption algorithms and storage mechanisms; and the use of role-based access control for CEK operations.

2. Governance: Confirm that the CEK policy is formally approved by senior management and that approval is documented through mechanisms such as a policy register, executive memo, or governance committee minutes. Verify that policy ownership is clearly assigned and that the policy is reviewed and updated at least annually or following significant changes such as integration with new LLM providers, modifications to the application architecture or hosting environment, or updates to regulatory or compliance requirements.

3. Communication: Review records showing the CEK policy has been distributed to all relevant stakeholders, such as developers, DevOps, infrastructure engineers, and risk/compliance teams. Evidence may include attestation logs, internal training records, or system acknowledgment receipts.

4. Implementation Validation: Validate that the policy is applied in practice by inspecting encryption configurations in application settings, key management system usage logs, prompt and completion logging practices, and protections for data-at-rest and data-in-transit within the application.

5. Role Assignment: Review the policy and related documentation to confirm that specific roles are assigned for key responsibilities, including key creation and destruction, encryption configuration and review, and access approval and exception handling. Confirm that these responsibilities are clearly mapped to named positions or groups within the AP’s organizational structure.

6. Training and Awareness: Inspect training schedules, attendance logs, or onboarding materials to confirm that relevant personnel have been trained on the CEK policy and its practical application.

7. Compliance Monitoring: Evaluate whether the AP actively monitors compliance with its CEK policy through automated alerting (e.g., unauthorized key use), periodic audits or reviews, and log analysis correlated with access control systems.

8. Upstream and Downstream Dependencies: Review how the AP accounts for upstream dependencies, such as relying on cryptographic assurances from Orchestrated Service Providers (OSP) or Model Providers (MP). Confirm that the CEK policy either includes contract clauses or due diligence steps to validate upstream encryption guarantees, or identifies residual risks and outlines mitigation steps within the AP’s own environment.

CEK-02: CEK Roles and Responsibilities

Control Specification

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

Auditing Guidelines for Application Providers (AP)

1. Verify that AP roles and responsibilities are defined in formal policies and procedures for cryptographic, encryption, and key management operations (e.g., key generation, encryption configuration, access control, incident response).

2. Confirm that AI-specific responsibilities are defined in alignment with the AP’s role (e.g., securing data exchanged with LLMs, managing encrypted AI outputs, handling API-level encryption keys) and that role assignments are documented and maintained.

3. Review documentation to confirm that responsibilities are mapped to specific roles or teams (e.g., DevOps, security, application engineering).

4. Validate that responsibilities related to AI integration are mapped to appropriate roles (e.g., ML engineers, product security, platform owners).

5. Verify that segregation of duties is enforced between key management, encryption configuration, and AI service access.

6. Confirm that personnel with responsibilities are trained on key lifecycle processes, encryption requirements, and AI-specific security concerns.

7. Verify that role assignments are reviewed at least annually or upon major architectural, organizational, or regulatory changes.

8. Confirm that governance structures (e.g., security committees) oversee role implementation and evaluate role effectiveness and coverage.

9. Validate that continuity plans exist and that backup personnel are trained and assigned for key cryptographic responsibilities.

10. Verify that responsibilities include coordination with upstream providers (e.g., OSPs, MPs) and downstream consumers (e.g., AICs) to ensure encryption practices are aligned across the application lifecycle.

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

1. Verify that AP encryption is implemented for all sensitive data at rest using approved cryptographic algorithms (e.g., AES-256).

2. Verify that encryption is enforced for all data in transit using secure transport protocols (e.g., TLS 1.2 or higher).

3. Confirm that data types requiring encryption are clearly defined and documented based on risk and classification.

4. Review data classification and confirm that encryption requirements are mapped to high-sensitivity data categories.

5. Validate that cryptographic libraries used are certified to approved standards (e.g., FIPS 140-2/3).

6. Verify that encryption keys are managed using centralized key management systems with logging, role-based access, and lifecycle controls.

7. Confirm that encryption configurations are hardened (e.g., secure cipher suites, deprecated protocols disabled) and validated regularly.

8. Verify that any exceptions to encryption requirements are documented, risk-assessed, formally approved, and include compensating controls.

9. Confirm that monitoring is in place to detect unencrypted data flows, failed encryption events, and unauthorized decryption attempts.

10. Verify that AI-related data (e.g., prompts, completions, model outputs) is included in encryption scope and protected both at rest and in transit.

11. Validate that encryption keys used in AI integrations (e.g., API tokens, gateway traffic) are subject to the same lifecycle and monitoring controls.

12. Review upstream and downstream encryption responsibilities to ensure consistency across AI model providers and application consumers.

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

1. Verify that the AP maintains documented standards for approved encryption algorithms, mapped to data classification levels (e.g., confidential, sensitive, regulated) and aligned with current cryptographic best practices (e.g., NIST, ISO).

2. Confirm that selected algorithms meet industry-recognized standards (e.g., AES-256, RSA-2048, ECC) and are suitable for protecting application-level data, including AI interactions such as prompts, outputs, and logs.

3. Review whether algorithm choices are periodically evaluated for strength, obsolescence, or known vulnerabilities, and replaced if they no longer meet minimum cryptographic requirements.

4. Validate that algorithm selection considers operational usability factors such as performance impact, compatibility with libraries and platforms, and developer implementation constraints.

5. Confirm that cryptographic algorithm usage is consistently implemented across all components of the application (e.g., data at rest, data in transit, and data in memory when feasible).

6. Verify that encryption algorithms are integrated with key management systems and access controls to enforce proper scope, isolation, and usage policies.

7. Review whether cryptographic practices are subject to governance oversight, including periodic review by a security steering group or cryptography standards body.

8. Confirm that the AP ensures algorithms used by third-party tools, libraries, or service providers embedded in the application stack also meet minimum encryption standards.

9. Validate that findings from vulnerability scans, penetration tests, or regulatory assessments related to algorithm strength are addressed and feed into the algorithm lifecycle process.

10. Verify that the AP considers upstream and downstream algorithm dependencies, ensuring that integration with providers (e.g., OSPs, MPs) and customer environments (e.g., AICs) supports compatible and appropriate cryptographic methods.

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

1. Verify that the AP maintains a formal, documented change management procedure specific to cryptographic, encryption, and key management systems, including related policies and operational practices.

2. Confirm that the procedure accommodates changes from both internal sources (e.g., algorithm upgrades, architectural changes) and external sources (e.g., provider updates, regulatory mandates).

3. Review whether proposed CEK-related changes are logged and submitted through a standard review workflow (e.g., change control board or security architecture review).

4. Verify that designated roles and responsibilities are defined for reviewing, approving, and authorizing CEK-related changes, including representation from security, architecture, compliance, and engineering teams.

5. Confirm that each approved CEK change includes an implementation plan with timelines, testing requirements, and rollback or fallback procedures.

6. Review whether CEK changes are communicated clearly to affected internal teams (e.g., DevOps, app developers) and external stakeholders (e.g., AICs, customers, integration partners).

7. Validate that version control is maintained for cryptographic configurations, policy documents, and key management tooling impacted by each change.

8. Verify that post-change validation is conducted to confirm the change was applied as intended, with no adverse impact on encryption scope, data protection, or compliance requirements.

9. Confirm that CEK change records include evidence of testing, approvals, communications, and contingency plans, and are retained for audit and assurance purposes.

10. Review whether CEK-related changes are assessed for upstream and downstream impact, including the effect on external encryption guarantees (e.g., MP/OSP) and downstream expectations from customers (e.g., AICs).

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

1. Verify that the AP maintains a documented process for managing changes to CEK-related systems, including policy updates, cryptographic algorithm changes, key management tooling, and configuration changes.

2. Confirm that proposed CEK changes are evaluated through formal change review workflows (e.g., change advisory boards or architecture review committees) prior to implementation.

3. Review whether each proposed change includes a cost-benefit analysis that weighs security improvements, compliance outcomes, and operational complexity or resource demands.

4. Validate that change documentation includes an assessment of residual risk, with justification for risk acceptance or compensating controls where full mitigation is not feasible.

5. Confirm that the AP assesses downstream impacts of CEK changes, particularly in shared application environments, data flows involving external services, and customer encryption expectations.

6. Verify that stakeholders from relevant teams (e.g., DevOps, platform security, legal, compliance, customer success) are engaged in CEK change planning and approval.

7. Review whether version control, rollback procedures, and change logs are maintained for all cryptographic system modifications.

8. Validate that implemented CEK changes are monitored post-deployment to assess for unexpected behavior, performance degradation, or failure to meet intended benefits.

9. Confirm that lessons learned from prior CEK changes (e.g., failed upgrades, cost overruns, missed regulatory alignment) are captured and integrated into future decision frameworks.

10. Verify that CEK changes involving upstream dependencies (e.g., MP model encryption changes) or downstream consumers (e.g., AIC BYOK flows) are tracked, reviewed, and communicated appropriately.

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

1. Verify that the AP has a documented encryption and key management (CEK) risk management program that aligns with organizational risk management standards and includes CEK-specific provisions.

2. Confirm that CEK-related risks are identified and contextualized based on data sensitivity, application architecture, cloud environments, and AI-related data flows (e.g., prompts, completions, logs).

3. Review the risk assessment methodology used to evaluate CEK risks, including how likelihood and impact are determined and how often assessments are conducted (e.g., annually, per major change).

4. Verify that the AP maintains a CEK risk register or equivalent artifact that includes identified risks, their treatment strategies, responsible owners, and timelines.

5. Confirm that risk treatment strategies are documented and include mitigation (e.g., stronger algorithms), risk transfer (e.g., insurance), or acceptance with rationale and approvals.

6. Validate that residual CEK risks are reviewed by a designated governance body (e.g., risk committee, security steering group) and updated when new threats or exposures emerge.

7. Review whether CEK risks are monitored through ongoing controls such as encryption posture scans, key usage anomaly detection, and compliance reporting.

8. Confirm that feedback from incidents, audit findings, or control failures is used to update the CEK risk management program and feed into policy or architectural decisions.

9. Verify that CEK-related risks specific to AI system integration (e.g., inference leakage, encrypted prompt logging, shared model access) are captured and treated within the risk program.

10. Validate that the CEK risk management program accounts for upstream dependencies (e.g., model provider key handling, orchestrated service encryption) and downstream obligations (e.g., customer data protection, AIC key expectations), with evidence of review and alignment.

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

1. Verify that the AP provides encryption key management models (e.g., BYOK, CMK) that allow the AIC to generate, rotate, revoke, and delete their own cryptographic keys when using the application.

2. Confirm that the AP ensures AIC-provided or tenant-scoped keys are exclusively used to protect that AIC’s data (e.g., prompts, outputs, logs) and that shared keys or default encryption are not applied in multi-tenant environments involving AIC data.

3. Validate that the AP provides key usage and access logging for AIC-managed keys and that this information is made available to the AIC through audit logs, dashboards, or APIs.

4. Confirm that the AP provides service-level agreements or platform service terms that define the AIC’s rights to supply, rotate, revoke, or monitor key usage related to their data in the application.

5. Verify that the AP assigns responsibilities for supporting and maintaining AIC-managed key capabilities to designated internal teams (e.g., platform engineering, customer security operations).

6. Confirm that the AP defines exception handling procedures for cases where AIC-managed keys cannot be supported (e.g., legacy systems, partial integration), including documentation, compensating controls, or roadmap plans.

7. Validate that the AP allows the AIC to test key control mechanisms before activating sensitive or production-level AI workloads, including verification of prompt encryption, runtime isolation, and logging protections.

8. Verify that the AP’s support for AIC-managed key control is subject to periodic review by CEK governance, security architecture, or customer trust committees, to reflect changing security and platform requirements.

9. Confirm that the AP enforces downstream AIC key control requirements, including delegated management, key isolation, and full accountability for cryptographic operations within the application.

10. Validate that the AP periodically reviews upstream dependencies (e.g., cloud KMS, crypto libraries, orchestration tools) to ensure they continue to support secure and auditable AIC key control configurations.

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

1. Verify that the AP 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 also triggered after material changes to cryptographic infrastructure, key lifecycle processes, or application architecture.

3. Review the audit schedule and scope to ensure it includes key systems, components, and environments responsible for enforcing encryption and managing keys.

4. Validate that audits assess compliance with internal CEK policies and external standards (e.g., NIST, ISO), including algorithm use, access controls, and key handling procedures.

5. Verify that CEK audits are performed independently from operational teams managing encryption or key services.

6. Confirm that audit results are documented, formally reviewed, and followed by remediation actions where control gaps or nonconformities are identified.

7. Review whether audit findings and known CEK risks are communicated to internal stakeholders (e.g., security leadership, risk, compliance, development).

8. Verify that automated monitoring tools are implemented where feasible to enable continuous or near-real-time auditing of CEK systems and events.

9. Confirm that encryption and key management controls supporting AI workflows (e.g., prompt protection, LLM integrations) are included in the audit scope.

10. Validate that CEK audit procedures are periodically reviewed and updated to reflect cryptographic standards, risk posture, regulatory obligations, and dependencies on upstream CEK controls (e.g., OSP, MP) and obligations to downstream consumers (e.g., AIC).

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

1. Verify that the AP uses approved, standards-based cryptographic libraries (e.g., FIPS 140-2/3 certified) to generate encryption keys within the application environment, including for securing AI-related workflows such as prompt encryption, result storage, and secure API traffic.

2. Confirm that key generation processes specify algorithm type and strength (e.g., RSA-2048, AES-256).

3. Validate that cryptographic random number generators (RNGs) used in key generation are secure and comply with recognized standards (e.g., NIST SP 800-90A).

4. Verify that key generation procedures are automated and integrated into a secure and auditable environment (e.g., KMS, HSM, CI/CD pipeline).

5. Review access controls and permissions associated with key generation to ensure only authorized personnel or systems can initiate the process.

6. Confirm that AI-related keys (e.g., for encrypting prompts, for completions, or for model outputs) follow the same generation standards and tooling.

7. Verify that keys are not hardcoded or embedded in application source code or AI integration layers.

8. Review logging and audit trail mechanisms that capture key generation events, including timestamp, source system, and outcome.

9. Confirm that test environments use separate keys and RNGs, distinct from production systems.

10. Validate that key generation procedures are reviewed periodically to reflect changes in orchestration tools, cryptographic standards, service-layer risks, and encryption dependencies with upstream model providers and downstream application consumers.

CEK-11: Key Purpose

Control Specification

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

Auditing Guidelines for Application Providers (AP)

1. Verify that the AP assigns cryptographic keys and secrets (e.g., private keys, API tokens, service credentials) to a unique purpose (e.g., encryption, signing, authentication) and that purpose separation is enforced in key management systems, secret management tools, application configurations, and usage policies.

2. Confirm that documentation exists mapping each key to its intended purpose and that the mapping is reviewed periodically for accuracy and relevance.

3. Verify that technical and procedural controls prevent the reuse of a single key for multiple cryptographic functions.

4. Review configurations to ensure each key is used only for its designated purpose.

5. Confirm that access controls and role-based permissions align with the intended use of each key and prevent unintended or unauthorized operations.

6. Validate that keys used for AI-related features (e.g., prompt encryption, output signing) are provisioned and segregated according to their specific function.

7. Review whether key metadata includes attributes indicating key purpose and that this metadata is enforced and audited within key management systems.

8. Confirm that CI/CD or application deployment processes enforce key separation policies and reject configurations where multi-purpose key use is detected.

9. Verify that key usage logs are reviewed to detect any anomalies or violations of defined key purposes.

10. Confirm that any key shared with downstream consumers is scoped only to its intended function and cannot be reused in other contexts.

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

1. Verify that the AP rotates cryptographic keys in accordance with defined cryptoperiods, considering the risk of information disclosure and legal or regulatory requirements relevant to application-layer and AI-related data protection.

2. Confirm that key rotation policies and procedures are documented and reviewed periodically to reflect changes in cryptographic standards, risk models, and legal or regulatory requirements.

3. Verify that key rotation is implemented through automated processes where possible, and that manual rotations follow defined and approved workflows.

4. Review key management system configurations to ensure keys are automatically or programmatically rotated in accordance with the defined cryptoperiods.

5. Confirm that access controls are in place to prevent unauthorized initiation or bypassing of key rotation events.

6. Validate that keys used for AI-related processes (e.g., encrypting prompts, model interaction, output protection) follow the same cryptoperiod and rotation policies as other critical keys.

7. Review logs to confirm that key rotation events are recorded, including timestamps, triggering mechanisms, and affected systems or services.

8. Confirm that rotated keys are properly propagated to all dependent components and services without exposing key material or introducing service downtime.

9. Verify that old or replaced keys are securely archived or destroyed in accordance with retention and compliance requirements.

10. Confirm that upstream and downstream parties involved in encrypted data exchange are notified of key rotation events when relevant and that key transitions maintain interoperability and data confidentiality.

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

1. Verify that the AP defines key revocation criteria, including early revocation in cases of compromise, system decommissioning, or personnel changes and that these criteria are documented and enforced.

2. Confirm that procedures exist to revoke keys across all systems in a timely and secure manner and that they are reviewed periodically to account for changes in application architecture, risk profile, or compliance obligations.

3. Verify that automated or manual revocation workflows are in place and supported by tooling such as KMS policies, certificate management systems, or secrets rotation infrastructure.

4. Review application and platform configurations to ensure revoked keys are immediately removed from memory, caches, config files, or storage systems to prevent misuse.

5. Confirm that access to initiate key revocation is limited to authorized personnel and that revocation actions require approval or logging to prevent accidental or unauthorized execution.

6. Validate that keys used for AI-specific functions (e.g., encrypted prompt handling, model API secrets, output validation keys) are subject to the same revocation triggers and that such keys are removed from all AI-integrated systems when revoked.

7. Review audit logs to confirm that revocation events are recorded with timestamps, responsible identities, and downstream impact, if applicable.

8. Confirm that application services consuming revoked keys are notified or updated automatically to prevent errors, security gaps, or fallback to default insecure configurations.

9. Verify that revoked keys are archived or destroyed in accordance with regulatory, contractual, and organizational data retention policies.

10. Confirm that key revocation events affecting upstream (e.g., model providers) or downstream (e.g., AI customers) are communicated and coordinated to ensure continued service integrity and prevent data 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 Application Providers (AP)

1. Verify that the AP defines, implements, and evaluates processes, procedures, and technical measures to destroy cryptographic keys stored outside a secure environment and to revoke keys stored in Hardware Security Modules (HSMs) when they are no longer needed, including those used in application-layer encryption, logging, or local key storage practices.

2. Verify that the AP has a documented data/key deletion policy in place, ensuring that keys and sensitive data are completely and securely deleted from all systems and backups when they are no longer needed, in accordance with legal, regulatory, and contractual obligations.

3. Confirm that key destruction and revocation criteria are documented, such as key expiration, data deletion, application retirement, or contract termination.

4. Verify that destruction methods for software-stored keys meet recognized standards (e.g., NIST SP 800-88, cryptographic erasure) and are supported by approved tooling or automation.

5. Review technical controls ensuring that keys stored outside secure environments (e.g., in application config files, local storage, or cache) are identified and securely deleted.

6. Confirm that HSM- or KMS-stored keys are revoked using secure, logged mechanisms when they are no longer in use or valid, and that the revocation renders the key irrecoverable.

7. Validate that AI-related key material (e.g., prompt encryption keys, output protection keys, AI token signing keys) is destroyed or revoked when the associated application components are retired or re-architected.

8. Review audit logs and system events for key destruction and revocation, and confirm that they include key ID, destruction method, responsible party, and timestamp.

9. Confirm that key destruction is included in the secure decommissioning processes for applications, services, or environments, and enforced through automation or security review gates.

10. Verify that key destruction and revocation practices align with applicable legal, regulatory, and contractual requirements, including cross-border data protection mandates.

11. Confirm that downstream consumers or upstream providers are notified, where applicable, when a shared or federated key is destroyed or revoked to avoid service disruptions or exposure.

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

1. Verify that the AP 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., within application-layer encryption services and AI integration points).

3. Review the AP’s authorization procedures and verify that a formal approval process is required before key activation.

4. Validate that the AP uses access controls, multi-party approvals, or workflow gating mechanisms to ensure that only authorized personnel can activate cryptographic keys.

5. Confirm that the AP enforces key activation policies consistently across application environments, including development, staging, and production.

6. Review logs of key activation events and verify that they include timestamp, user or system identity, approval references, and key identifiers.

7. Verify that legal and regulatory requirements related to cryptographic key activation (e.g., financial controls, export compliance, regional data protection laws) are incorporated into the AP’s procedures.

8. Confirm that pre-activated keys are subject to timeout, expiration, or revalidation policies if not activated within a defined window.

9. Verify that keys used for AI-related features (e.g., encrypted prompts, API calls to model providers) are also subject to pre-activation policies prior to use in AI workflows.

10. Confirm that the AP’s key activation lifecycle accounts for upstream cryptographic dependencies (e.g., from OSPs or MPs) and downstream coordination with AICs where activation state affects service delivery.

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

1. Verify that the AP defines processes, procedures, and technical measures to monitor, review, and approve cryptographic key transitions to and from suspension, including keys used in application-level encryption and development pipelines.

2. Confirm that the AP defines valid criteria for suspending cryptographic keys, including policy violations, security anomalies, temporary operational pauses, and other risk-based triggers relevant to application-layer encryption and AI workflows (e.g., encrypted prompts, model API keys).

3. Review documentation showing that key suspension events follow a formal change control or approval workflow, including appropriate authorizations.

4. Validate that suspended keys are logically disabled from encryption or decryption operations while retaining integrity for potential reactivation.

5. Verify that the AP enforces access controls that restrict who can suspend or resume cryptographic keys, and ensure segregation of duties is maintained.

6. Review monitoring and alerting mechanisms to detect unauthorized or anomalous key suspension events.

7. Verify that key suspension and reactivation logs are retained and auditable, capturing event metadata such as timestamp, initiator, affected systems, and reason for action.

8. Confirm that policies and procedures for key suspension incorporate applicable legal, regulatory, and contractual obligations (e.g., availability guarantees, incident response, data retention).

9. Validate that AI-related keys (e.g., used for encrypted prompts, model output delivery, or AI API access) are subject to the same suspension governance as other application keys.

10. Review whether the AP’s suspension procedures account for upstream dependencies (e.g., MP/OSP-issued keys) and downstream impact to AIC integrations or service delivery.

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

1. Verify that the AP 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 application-layer encryption or AI prompt protection).

2. Confirm that expiration dates are assigned to all relevant keys and tracked in centralized key management systems or application-integrated lifecycle repositories.

3. Review whether the AP’s key lifecycle policies enforce automatic deactivation of expired keys through system-enforced expiration rules.

4. Validate that keys scheduled for deactivation are flagged and isolated from production systems or workflows in advance of the expiration event.

5. Confirm that the AP enforces access restrictions on deactivated keys to prevent unauthorized or inadvertent reuse.

6. Review audit logs and system events associated with key deactivation to ensure that the deactivation timestamp, reason, and affected systems are captured.

7. Verify that expired keys are either archived securely (if required for audit or compliance) or transitioned to destruction or revocation procedures based on the AP’s retention policies.

8. Confirm that legal and regulatory requirements (e.g., financial services recordkeeping, export control compliance) are reflected in the AP’s key expiration and deactivation processes.

9. Validate that AI-related keys (e.g., those used for encrypting prompts, completions, or API tokens) are included in the AP’s deactivation policy and not reused beyond their cryptoperiod.

10. Review whether the AP coordinates with upstream providers (e.g., OSP, MP) and downstream consumers (e.g., AIC) to ensure deactivation does not disrupt dependent services or integrations.

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

1. Verify that the AP 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., application-layer key retirement or long-term auditability of AI prompt encryption keys).

2. Confirm that archived keys are stored in encrypted repositories and logically separated from active keys, with access restricted to approved roles under documented approval workflows.

3. Review whether the AP’s archival system applies least privilege principles by limiting access to only those roles with a justified operational or compliance need.

4. Validate that access to archived keys is governed by approval workflows, and that access attempts are logged and reviewed.

5. Confirm that archived keys are logically separated from active keys and cannot be used to perform encryption or decryption operations.

6. Review lifecycle documentation to ensure that archived keys are subject to retention schedules aligned with regulatory, legal, and contractual requirements.

7. Verify that the AP’s archival procedures include periodic review of archived key inventories to assess continued necessity and risk.

8. Confirm that technical controls prevent unauthorized recovery or export of archived keys from the repository.

9. Validate that archived AI-related keys (e.g., prompt history protection, encrypted model outputs) are also included in the AP’s archival management practices.

10. Review whether the AP coordinates with upstream providers (e.g., OSP, MP) and downstream consumers (e.g., AIC) to ensure archived key dependencies are identified and accounted for in long-term key retention planning.

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

1. Verify that the AP 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 AP’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 AP’s incident response procedures comply with relevant legal and regulatory requirements for key management in the event of a compromise.

3. Confirm that the AP restricts use of compromised keys to decrypt-only operations under controlled circumstances (e.g., for encrypted application logs, retired tokens), and explicitly prohibits further encryption with such keys unless formally approved.

4. Review how the AP identifies and marks keys as compromised within key management systems or metadata configurations.

5. Validate that compromised keys are segregated from active keys and are only accessible for decrypting previously encrypted data, under restricted conditions.

6. Confirm that access to compromised keys is restricted based on least privilege and requires elevated approval for any usage.

7. Review logging and monitoring mechanisms that track when, how, and by whom compromised keys are accessed or used.

8. Verify that AP maintains records of all decrypt-only activities performed using compromised keys, including business justification and audit trails.

9. Confirm that legal and regulatory requirements are addressed in the AP’s handling of compromised keys, especially for regulated industries or customer-specific compliance.

10. Validate that AI-specific use cases involving compromised keys (e.g., decrypting stored prompts, completions, or model inputs) are covered by the same restrictions and safeguards.

11. Review whether the AP coordinates with upstream (e.g., OSPs or MPs) and downstream (e.g., AICs) entities to notify, contain, and mitigate risks resulting from the compromise of any shared or inherited key.

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

1. Verify that the AP 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 AP conducts periodic risk assessments that evaluate key recovery scenarios across application-layer environments (e.g., app secrets, encryption keys, AI API tokens) and considers the impact of recovery failure or compromise on application availability and AI service integrations.

3. Review whether the AP’s key recovery planning addresses different classes of keys (e.g., session keys, data encryption keys, application secrets) and their role in supporting service availability.

4. Validate that key recovery procedures include provisions for securely backing up keying material, protecting against unauthorized access, and maintaining compliance with data residency and regulatory requirements.

5. Confirm that recovery mechanisms are tested at regular intervals to evaluate their effectiveness in restoring application functionality without exposing sensitive data.

6. Review approval workflows for initiating key recovery, including escalation protocols, access logging, and multi-party control (e.g., split knowledge, quorum-based recovery).

7. Verify that access to recovery systems and stored key backups is governed by strict access controls, least privilege, and tamper-evident protections.

8. Confirm that the AP documents and maintains business impact analyses and risk treatment strategies related to key loss scenarios in its broader cryptographic risk management program.

9. Validate that AI-related keying material (e.g., keys protecting prompts, completions, or AI-generated content) is included in recovery planning and assessed for confidentiality and integrity risk if recovered.

10. Review whether the AP coordinates with upstream providers (e.g., OSPs or MPs) and downstream consumers (e.g., AICs) to ensure key recovery responsibilities and dependencies are clearly understood and managed across the cryptographic trust chain.

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

1. Verify that the AP 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 AP’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 key attributes such as type, owner, purpose, cryptoperiod, algorithm, and current status are consistently recorded and updated.

4. Validate that changes to key status (e.g., activation, deactivation, compromise, suspension) are automatically logged and made available for review and audit.

5. Confirm that role-based access controls are enforced on the key inventory system to ensure only authorized personnel can modify or query records.

6. Review retention policies and archival procedures for key metadata to ensure alignment with internal governance, customer requirements, and regulatory mandates.

7. Verify that the inventory system includes keys used in AI integrations (e.g., for encrypting prompts, completions, API traffic, and inference outputs).

8. Confirm that the AP uses monitoring or alerting mechanisms to detect abnormal key lifecycle events, such as premature destruction or unexpected usage.

9. Validate that inventory records are included in regular audits or internal reviews to detect gaps, inconsistencies, or outdated key entries.

10. Review whether the AP coordinates with upstream OSPs or MPs and downstream AICs to track shared or inherited keys, ensuring status changes are reflected across interdependent systems.

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

1. Verify that the Application Provider has formally documented physical and environmental security policies covering facilities that host AI‑enabled applications or supporting services.

2. Verify that evidence shows these policies have been approved by management, communicated to relevant personnel, and reviewed at least annually or upon significant changes.

3. Verify that, when infrastructure is outsourced, physical security requirements are defined for hosting providers and supported with appropriate assurance documentation.

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

1. Verify the AP’s asset management policy includes procedures for the secure decommissioning of virtual assets (e.g., VMs, containers) and storage volumes in their cloud environment.

2. Confirm that contracts with CSPs include clauses requiring secure data and media disposal in accordance with standards like NIST SP 800-88.

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

1. Verify the AP’s data governance policy includes authorization procedures for transferring application data between cloud regions or to a different CSP.

2. Confirm that such transfers are logged and require approval from a designated data owner or steward.

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

1. Verify the AP’s security policy requires that development and operations are performed in a secure working environment (physical or remote).

2. Confirm that due diligence is performed on the physical security of any colocation or third-party facilities used, in addition to the primary CSP.

DCS-05: Secure Media Transportation Policy and Procedures

Control Specification

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

Auditing Guidelines for Application Providers (AP)

1. Verify the AP’s policy requires any physical media containing source code, credentials, or user data to be encrypted and transported securely with chain-of-custody documentation.

2. Assess this control as not applicable if the AP operates entirely in the cloud with no physical media use.

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

1. Verify the AP classifies its logical assets, including application code repositories, databases, APIs, and containers, based on data sensitivity and business criticality.

2. Confirm that access controls and other security measures are applied according to this classification.

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

1. Verify the AP maintains a secure inventory of its logical assets, such as code repositories, container images, and deployed application instances.

2. Confirm the inventory is updated automatically as part of the CI/CD pipeline and reconciled regularly.

DCS-08: Controlled Physical Access Points

Control Specification

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

Auditing Guidelines for Application Providers (AP)

1. Verify that the AP has reviewed the CSP’s third-party audit reports (e.g., SOC 2 Type 2, ISO 27001) for evidence of physical access controls at the data centers hosting the application.

2. Confirm that service agreements with the CSP specify their responsibility for physical security.

DCS-09: Equipment Identification

Control Specification

Use equipment identification as a method for connection authentication.

Auditing Guidelines for Application Providers (AP)

1. Verify that the AP uses logical equipment identification, such as workload identities (e.g., SPIFFE/SPIRE) or service accounts, to authenticate connections between microservices or application components.

2. Confirm that device identity is a factor in the AP’s zero-trust access policies.

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

1. Verify the AP reviews and relies on the CSP’s physical access control audits (e.g., SOC 2 reports) to ensure the data centers hosting their application are secure.

2. Confirm the AP’s internal policies restrict access to their own secure development and office environments.

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

1. Verify that the AP’s due diligence process includes confirming that their CSP implements and maintains surveillance systems at all data centers hosting the application.

2. Review the CSP’s SOC 2 report or other audits for evidence of surveillance system controls.

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

1. Verify the AP relies on the CSP’s attestation for this control.

2. Confirm that the AP’s own incident response plan includes procedures for responding to infrastructure-level events reported by their CSP.

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

1. Verify that the AP’s due diligence includes reviewing their CSP’s controls for cabling security.

2. Confirm that the CSP’s audit reports (e.g., SOC 2) cover the physical protection of network and power infrastructure within the data center.

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

1. Verify the AP has reviewed its CSP’s attestations regarding data center environmental controls (e.g., through SOC 2 or ISO 27001 reports).

2. Confirm that the AP’s business continuity plan accounts for potential service disruptions due to environmental failures at the CSP.

DCS-15: Secure Utilities

Control Specification

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

Auditing Guidelines for Application Providers (AP)

1. Verify the AP’s due diligence process includes a review of their CSP’s controls for utility services (power, cooling).

2. Confirm that the AP’s business continuity and disaster recovery (BC/DR) plan considers the impact of a utility failure at their primary CSP region.

DCS-16: Equipment Location

Control Specification

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

Auditing Guidelines for Application Providers (AP)

1. Verify the AP has a policy for selecting cloud regions that considers environmental risks (e.g., floods, earthquakes).

2. Confirm that the AP’s disaster recovery strategy includes deploying the application across multiple, geographically dispersed availability zones or 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 Application Providers (AP)

1. Verify that the AP monitors availability and performance metrics for infrastructure supporting AI-enabled applications.

2. Confirm that security-relevant indicators (e.g., access anomalies, service disruptions, configuration deviations) are tracked and reviewed.

3. Verify that thresholds and alerting mechanisms are defined and integrated into operational response procedures.

4. Where infrastructure is outsourced, confirm that the AP reviews hosting provider service health and security reports.

DCS-18: Datacenter Operations Resilience

Control Specification

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

Auditing Guidelines for Application Providers (AP)

1. Verify that the AP has implemented continuity and recovery mechanisms for AI-enabled applications, including redundancy and backup strategies.

2. Confirm that recovery procedures are documented and tested periodically.

3. Verify that application architectures support restoration of AI-dependent services following infrastructure disruptions.

4. Confirm that incident records demonstrate successful recovery from outages or failures.

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

1. Create and examine the AP’s policy and procedures related to data security and privacy.

2. Determine if a framework exists and ensure that the AP monitors the regulatory and legislative environment for changes applicable to the AP’s data security and privacy policy and procedures. Confirm whether the AP 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 AP’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 AP complies with current legislation and regulations.

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

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

1. Examine the AP’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 AP’s data privacy and security policy. Establish whether the AP 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. Examine how the application manages secure disposal in third-party integrations, plugins, or data export scenarios.

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

1. Examine the AP’s procedures and technical requirements for the population and management of its data inventory. Establish that this process and key controls comply with the AP’s data privacy and security policy. Establish whether the AP 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 AP’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.

DSP-04: Data Classification

Control Specification

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

Auditing Guidelines for Application Providers (AP)

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

2. Establish if the AP’s data classification matrix is aligned with the AP’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 AP’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.

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

1. Examine the AP’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 AP’s data privacy and security policy. Establish whether the AP 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.

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

1. Examine the AP’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 AP’s data privacy and security policy. Establish whether the AP has documented the roles and responsibilities for this process.

2. Establish that the AP 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 AP maintains a source of record for data owners and the records for which they are responsible.

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

1. Examine whether the AP’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 AP has documented the roles and responsibilities involved.

3. Review the AP’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.

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

1. Examine whether the AP’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 AP’s culture and whether practices reflect privacy by design and industry best practices.

2. Examine whether the AP’s governance framework, documents, controls, and metrics satisfy the AP, and if its sub-processors comply with this requirement. Establish whether the organization has AP 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 organization. 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 AP limits data collection to the minimum necessary for the identified purposes.

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

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

9. Verify that the AP 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 AP 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 AP does not retain data for longer than necessary for the purposes for which it was processed.

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

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

14. Examine application design documentation to verify that privacy by design principles are incorporated from inception, with privacy controls embedded in architecture, data flows, and user interfaces.

15. Verify that user-facing privacy settings default to the most privacy-protective options, requiring explicit user action to enable data sharing or reduce privacy protections.

16. Review implementation of data minimization in application features, confirming that only necessary personal data is collected, processed, and stored by default.

17. Assess the application’s consent management mechanisms, verifying they provide clear, granular choices and respect user preferences consistently across all features by default.

18. Verify that the application includes intuitive privacy management interfaces allowing users to access, update, and delete their personal information easily.

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

1. Examine procedures related to DPIA risk assessment and determine whether, once a requirement has been established, the AP 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 AP’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 AP.

4. Establish whether the AP 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. Review whether DPIAs evaluate AI-specific privacy risks such as user inference, profile building, and inadvertent personal data collection.

11. Assess whether DPIAs consider the application’s integration with third-party AI models and services, including inherited privacy risks.

12. Verify that privacy-by-design controls documented in DPIAs are implemented in the application.

13. Examine whether DPIA findings are incorporated into application feature development and privacy control implementation.

14. Confirm that DPIAs are updated when application functionality changes or new privacy risks are identified.

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

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

2. Establish whether the AP 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 AP’s policy, procedures, and controls. Confirm that all relevant evidence was formally documented.

4. Obtain a sample of the technical measures implemented by the AP to determine if those measures adhere to the AP’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 that third-party application integrations maintain appropriate data transfer protections.

10. Review application security testing practices focused on data transfer vulnerabilities.

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

1. Examine whether the AP’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 AP 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 AP’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 processes for authenticating data subject identity before fulfilling privacy rights requests.

6. Review procedures for tracking requests from submission through fulfillment, including status updates to data subjects.

7. Assess how the application integrates with back-end systems to ensure comprehensive fulfillment of requests.

8. Verify that privacy notices inform users about how to exercise their data subject rights.

9. Examine audit trails documenting all request-handling activities.

10. Review testing procedures that validate the effectiveness of data subject request handling.

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

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

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

3. Review the AP’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 AP’s processes that inform data subjects why it requests this data and what it will be used for. Confirm that any AP 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. Evaluate processes to ensure third-party application integrations adhere to purpose limitations.

10. Verify mechanisms for tracking and enforcing purpose limitations throughout the application data lifecycle.

11. Review testing procedures that validate purpose limitation controls.

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

1. Examine the AP’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 AP 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 AP’s data privacy and security policy.

4. Examine the AP’s contractual requirements for subprocessor compliance, reporting, and non-compliance sanctions and the AP’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. Review privacy impact assessment processes before engaging new sub-processors.

10. Examine procedures for responding to data subject rights requests that may involve sub-processors.

11. Assess monitoring controls that verify sub-processor compliance with contractual obligations and regulatory requirements.

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

(Primary Organization: Application Provider (AP) Relevant Stakeholders: Sub-processors (e.g., OSPs, MPs, CSPs), Customers (AICs))

1. Examine the AP’s documented policy and procedures for disclosing sub-processor access to personal or sensitive data prior to processing. Verify that the policy assigns clear roles and responsibilities for managing and communicating these disclosures. Check that the AP monitors regulatory and contractual obligations to ensure the policy remains current and compliant.

2. Test Implementation Through Sample Data Flows: Select a sample of data transfers to sub-processors and: Verify the disclosures occurred prior to processing, Check that controls and reporting comply with the AP’s data privacy and security policy, Confirm that records include details of the disclosed PII (what, when, to whom, by whom, and under what authority).

3. Review Customer Notification and Legal Request Handling: Confirm the AP has documented procedures to: Notify customers promptly of legally binding requests for their PII, Reject non-legally binding requests unless the customer consents, Ensure notification timing and method meet contractual and regulatory expectations.

4. Evaluate Sub-processor Management and Contracts: Verify that agreements with sub-processors: Require equivalent privacy and security standards as those the AP follows, Specify how PII must be handled, protected, and disclosed, Include data minimization principles (only the minimum necessary PII is disclosed). Confirm the AP discloses its use of sub-processors in customer contracts and maintains up-to-date records of these disclosures. Check that new or changed sub-processors are communicated to customers in advance, in line with contractual obligations.

5. Incorporate Upstream Disclosures: Review how the AP collects and incorporates sub-processor disclosure information from its upstream providers (e.g., MPs, OSPs) and makes it available to customers when relevant.

6. Verify Evidence of Timeliness: Review logs and records to confirm that disclosures of sub-processor data access consistently occur before processing begins.

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

1. Verify that the procedures and technical requirements for using production user data (e.g., end-user inputs, content, or metadata) in staging or testing environments are defined.

2. Verify if explicit approvals are obtained before replicating production user data in test environments for debugging or feature development.

3. Verify if any production-like data is anonymized, obfuscated, and securely deployed in development or QA environments.

4. Verify if exceptions to data replication or handling standards in non-production environments are formally approved.

5. Verify if procedures for data management are reviewed regularly and updated to address new compliance requirements and platform changes.

6. Verify if employees, including developers and testers, are trained on secure and compliant handling of production-like data in non-production contexts.

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

1. Verify if the organization has defined policies and procedures governing retention, archiving, and deletion of user-generated data and application logs, with clear roles and responsibilities.

2. Verify if different categories of application data (e.g., user input, system logs) and their retention periods are defined in line with regulations and customer contracts.

3. Verify if application logs and user content are retained and archived according to documented schedules.

4. Verify if agreements with third-party vendors or integration partners include data retention and deletion requirements.

5. Verify if data is deleted from the application back end after its retention period using secure deletion practices.

6. Verify if data deletion and archiving actions are logged, monitored, and regularly reviewed by authorized personnel.

7. Verify if security measures are in place to protect retained data from breaches or unauthorized access.

8. Verify if data retention policies are periodically reviewed to address legal updates or changes in business services.

9. Verify if data retention policies include specific provisions for content processed by or generated using GenAI features.

10. Verify if AI application features are architected to avoid storing unnecessary sensitive data.

11. Verify if input data for AI features (e.g., prompts) is anonymized or de-identified where feasible.

12. Verify if access to user data and AI interaction history is restricted to authorized personnel.

13. Verify if a process is in place to delete user data associated with AI functions after its defined retention period.

14. Verify if audit logs and monitoring systems are in place to track adherence to AI data lifecycle 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 Application Providers (AP)

1. Verify whether the organization’s data privacy policy includes specific guidance for handling sensitive user data processed by GenAI applications across its lifecycle (e.g., input, processing, output, and retention).

2. Verify whether roles and responsibilities for ensuring privacy in AI-powered applications are clearly assigned (e.g., product teams, data privacy officers, engineers).

3. Verify that data classification aligns with how the application ingests and outputs sensitive data; ensure safeguards (e.g., encryption, PII redaction) are in place; validate regulatory compliance (e.g., GDPR, HIPAA); inspect logs, privacy notices, and system designs; and ensure procedures are regularly reviewed.

4. Verify that mechanisms exist to protect sensitive user data throughout the GenAI application lifecycle, including prompt processing, API interactions, and user output delivery.

5. Verify whether past data privacy breaches or misuse of user data in AI-powered applications were identified, investigated, and remediated with evidence of corrective actions.

6. Verify whether the organization’s AI risk framework includes controls to prevent privacy violations, reduce model bias, and maintain transparency in user-facing decisions.

7. Verify that incident response processes are defined for GenAI-related privacy events, including user complaints, model misuse, or output containing sensitive data.

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

1. Verify if procedures are defined to manage law enforcement requests for access to user content, prompts, or AI-generated outputs.

2. Verify if such procedures are compliant with applicable privacy policies and applicable security frameworks (e.g., GDPR, CCPA).

3. Verify if roles and responsibilities are assigned for responding to and approving disclosures to authorities.

4. Verify if secure and authorized channels are used for managing disclosure notifications.

5. Verify that actions and decisions related to the disclosure of user data or generated content are documented in a traceable manner.

6. Verify that disclosures are communicated to law enforcement and users (where applicable) within mandated timeframes.

7. Verify if procedures are periodically reviewed to reflect new laws or AI feature updates.

8. Verify if employees receive training on how to identify, respond to, and escalate disclosure requests.

9. Verify if a tracking system is in place for managing the lifecycle of law enforcement requests and their resolution.

10. Verify if internal audit or compliance teams monitor non-compliance or exceptions in the disclosure process.

11. Verify if policies specifically address AI-generated content or system interactions in the context of disclosure.

12. Verify if technical safeguards restrict unauthorized access to generated outputs during the disclosure process.

13. Verify if logs and audits are maintained to ensure transparency and compliance in AI data disclosures.

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

1. Verify policies, procedures, and technical requirements cover the physical storage of user data and generated content, as well as ethical considerations in AI-powered data processing and storage.

2. Verify that roles and responsibilities for managing application data storage and AI system governance are well documented.

3. Verify that data storage and processing policies specify compliance with regional data residency laws relevant to user data handled by AI applications.

4. Verify that the organization maintains accurate, up-to-date records of physical storage locations for user data and AI-generated content, enabling data lineage tracking.

5. Verify that these records are maintained consistently and accurately in accordance with policies.

6. Verify that supplier and vendor obligations related to AI system data storage are clearly defined and documented.

7. Verify that the AI components involved in data storage and processing conform to organizational ethical and regulatory standards.

8. Verify monitoring and auditing procedures are implemented to ensure ongoing compliance of AI data storage with ethical and legal standards.

9. Verify that risk management plans include controls to mitigate bias and enhance transparency related to AI-driven data storage and processing activities.

10. Verify that incident response procedures address AI application-related data storage incidents, including clear reporting, investigation, and remediation workflows.

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

1. Verify that all data sources (including prompt data, user inputs, and retrieved knowledge base content) are clearly documented.

2. Verify that lineage documentation shows how data flows through the application pipeline.

3. Verify that a data dictionary defines application-specific data elements, formats, and relationships (e.g., user profiles, prompt history).

4. Verify that provenance records include logs of content generation processes, including versions and parameters used.

5. Verify that monitoring systems track access to and changes in data feeding the AI application.

6. Verify that integrity tracking is in place for critical application data, including inputs and outputs.

7. Verify that privacy, scalability, and complexity challenges (e.g., long context windows, retrieval augmentation) are addressed with documented procedures.

8. Verify compliance with relevant laws (e.g., GDPR, ePrivacy) concerning user inputs, model-generated content, and stored data.

9. Verify that encryption and role-based access controls are applied to application data.

10. Verify that AI application data is retained according to policy and securely deleted at the end of the lifecycle.

11. Verify that staff and developers receive training on responsible handling of input, output, and auxiliary data used in AI applications.

12. Verify that metadata (e.g., timestamps, processing logs) related to data origin and AI pipeline processing can be retrieved for audit.

13. Verify that version control exists for key datasets (e.g., context documents) and AI application configurations.

14. Verify that procedures for disclosing data to external parties (e.g., regulators or customers) are documented and comply with legal obligations.

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

1. Verify that the data sources used by GenAI applications (e.g., user inputs, content repositories) are validated to prevent injection of malicious or poisoned data.

2. Verify that data quality controls are in place to detect and filter corrupted or suspicious input data before processing by AI models.

3. Verify that automated monitoring systems identify unusual input or output patterns that may indicate data poisoning or adversarial attacks.

4. Verify that mitigation techniques (e.g., input sanitization, adversarial filtering) are used to make the application robust against poisoned data.

5. Verify that access controls restrict unauthorized changes to datasets used by the application for customization or fine-tuning.

6. Verify encryption protects stored data and input/output streams against unauthorized access and tampering.

7. Verify that monitoring is implemented to detect data poisoning attempts or suspicious anomalies during data ingestion and processing.

8. Verify incident response plans address data poisoning threats relevant to the application context, including detection, user notification, and remediation.

9. Verify that employees and support teams are trained to recognize signs of data poisoning attacks on the application.

10. Verify the use of automated monitoring tools to continuously check data integrity and identify anomalies in real-time application data flows.

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

1. Verify that PETs integrated into applications (e.g., to anonymize user data or control output leakage) are based on clearly documented business use cases.

2. Verify that PET-enabled features in applications are continuously monitored to detect degradation in performance or privacy guarantees.

3. Verify that PETs used in application logic (e.g., output redaction, user-level differential privacy) comply with applicable privacy regulations.

4. Verify that effectiveness metrics (e.g., reduction in reidentification risk, false positives in filtering) are defined and reported.

5. Verify that developers and product teams are trained on configuring and maintaining PETs within the application context.

6. Verify that all PET-related components (libraries, middleware) are up to date with the latest security patches.

7. Verify that logs and telemetry from PET modules are reviewed to detect potential misuse, privacy leakage, or failures.

8. Verify that the PETs embedded in the application undergo periodic external testing or privacy red-teaming.

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

1. Verify that all data sources used by the application, including user inputs and content repositories, are clearly identified and traceable.

2. Verify that systems log any changes or updates to datasets used by the application.

3. Verify that automated monitoring tools continuously check data integrity and flag anomalies in application data.

4. Verify that access controls restrict unauthorized modification of data handled by the application.

5. Verify that sensitive user and generated data is encrypted to prevent unauthorized access or tampering.

6. Verify that version control mechanisms track changes to application data and AI models used.

7. Verify that employees are trained on data handling best practices and integrity principles specific to the application context.

8. Verify that procedures exist to detect, report, and remediate data integrity issues within the application.

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

1. Verify if clear and accessible information about the AI system’s functioning is provided to relevant stakeholders (internal teams, regulators, users).

2. Verify if continuous monitoring and improvement tools are implemented to regularly test and refine the AI application based on performance metrics.

3. Verify if the AI application complies with applicable privacy regulations and is updated to reflect evolving AI governance and compliance standards.

4. Verify if the application provider gathers feedback from diverse stakeholders on the AI system’s impact and relevance, using this feedback to drive adjustments and improvements.

5. Verify that data governance policies are strictly adhered to and relevant privacy regulations (e.g., GDPR, CCPA) are complied with during application operation.

6. Verify that mechanisms are in place to protect sensitive information and maintain data integrity within the application.

7. Verify if continuous monitoring tools track the performance and relevance of the application’s AI models and data, and if feedback is collected and used for improvements.

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

1. Examine whether the organization has established a comprehensive strategy for information governance, ensuring application provider-specific AI responsibilities, such as embedded AI features, model interaction, or user-facing behavior. Confirm that leadership sponsorship is documented, and that policies, standards, and procedures are formally approved, communicated, and applied.

2. Confirm that policies, standards, and procedures are reviewed and updated at least annually, or upon significant changes with documented evidence of the review process, leadership approval, and updates made in response to evolving AI-enabled application features, platform or API changes, or relevant external governance expectations.

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

1. Program Examination: Verify that a formal, documented AI Risk Management (AIRM) program exists and that it has been approved by executive leadership. Confirm that the AIRM program is maintained under formal governance with assigned roles and responsibilities specific to AI risks associated with application development, deployment, and use (e.g., AI-based logic, user interaction, embedded models).

2. Program Content Assessment: Verify that the AIRM program includes documented procedures for the identification, evaluation, ownership, treatment, and acceptance of AI-related risks across the lifecycle of AI-enabled applications. Assess whether the AIRM framework explicitly considers risks unique to AI systems (e.g., biased outputs, unintended model behavior, lack of transparency in decision login). If not, determine whether a documented rationale and alternative risk mitigation approach exist. Confirm that the AIRM program includes policies for identifying and managing risks arising from the use of third-party or cloud-hosted AI services integrated into the application. Verify that AI risk ownership is assigned to appropriate roles (e.g., application developers, product owners, and technical leads) and that escalation paths are defined for unresolved or accepted risks.

3. Program Alignment Evaluation: Evaluate whether the AIRM program aligns with the organization’s AI governance strategy and internal risk management expectations for application development. Confirm that the AIRM program incorporates applicable legal, regulatory, and standards-based requirements related to application-level AI usage and data privacy (e.g., fairness in decisioning, explainability, user consent).

4. Implementation Validation: Validate the actual implementation of the AIRM program by reviewing supporting evidence such as application-specific AI risk registers, risk assessments, or monitoring reports. Inspect a sample of documented risk treatment or acceptance decisions related to AI-enabled applications to assess traceability, rationale, and leadership review or approval.

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

1. Policy Examination

   • a. Verify that the organization maintains a documented inventory or catalog of policies and associated procedures relevant to AI application development, deployment, model integration, and use of supporting of cloud services.

   • b. Confirm that the organization has defined how it determines which policies are “relevant” to evolving AI application development risks, such as changes in functionality, embedded AI logic, or external API dependencies.

2. Policy Assessment

   • a. Verify that policies and procedures are reviewed at least annually and that this process is supported by version tracking, timestamps, and approval history.

   • b. Confirm that policy reviews are performed by application owners or governance leads and approved through formal governance channels (e.g., policy committees, risk officers).

3. Review Process Evaluation

   • a. Determine whether the organization has defined what constitutes a “substantial change” (e.g., rollout of a new AI feature, integration with third-party APIs, or changes to customer data flows).

   • b. Verify that there is a formal process for initiating policy reviews in response to substantial changes, even if they occur outside of the standard review cycle.

4. Implementation Validation

   • a. Inspect records of recent policy reviews to confirm that the annual review cycle is being followed and that AI application-related policies reflect the current development and deployment practices.

   • b. Examine recent AI-related application changes (e.g., new chatbot functionality, fraud detection features) and validate that related policies and procedures were reviewed and updated accordingly.

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

1. Policy Examination: Verify that a formal, documented process exists for requesting, reviewing, approving, and tracking exceptions to organizational policies governing AI system development, deployment, and integration practice and confirm that the exception process is incorporated into the organization’s broader governance program, including references in policy manuals, AI lifecycle governance documents, or risk frameworks.

2. Policy Assessment: Verify that the exception process includes clear criteria for evaluation, approval authority, documentation requirements, and expiration timelines, confirm that the process applies to all deviations from established AI-related policies, such as those covering data sourcing, model risk mitigation, algorithmic transparency, or responsible use, and assess whether approved exceptions are logged in a central repository and shared with relevant teams (e.g., model developers, compliance, legal) to ensure alignment with enterprise risk posture.

3. Review Process Evaluation: Determine whether there are mechanisms in place to ensure that deviations from policy are not allowed without formally approved exceptions. This may include code check-ins, deployment/configuration gates, approval workflows, automated policy checks, issues tracking protocols, or quality assurance checkpoints. Confirm that exception activity is periodically reviewed by governance stakeholders (e.g., AI governance board, risk committee, or policy council).

4. Implementation Validation: Review a sample of approved exceptions related to application-level AI functionality, integration, deployment or security controls to validate that they were approved in accordance with the documented process and contain justification, expiration dates, and reviewer sign-off, and inspect a sample of recent policy deviations related to AI application development or deployment (e.g., skipped explainability documentation, unauthorized configuration changes, bypassed integration steps) to verify that exceptions were formally documented and approved when 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 Application Providers (AP)

1. Program Existence and Scope: Verify that the organization maintains a formal, documented Information Security Program that governs the protection of its systems, applications, infrastructure, and data. Where AI technologies are developed or deployed, confirm that the program identifies and addresses relevant security considerations aligned with applicable AICM domains (e.g., Data Protection, Model Lifecycle, Infrastructure). Ensure the program reflects both general IT and AI-specific risks, if present.

2. Policy Coverage and Governance: Assess whether the Information Security Program includes clearly defined policies that address the organization’s security responsibilities, including areas such as secure development practices, access management, data security, and incident response. Where AI applications are in use, evaluate whether the program explicitly accounts for relevant risks (e.g., model integrity, training data governance, privacy implications). Confirm that governance structures are in place to oversee implementation, with assigned roles and responsibilities for security management.

3. Cross-Functional Applicability and Domain Mapping: Determine whether the organization has mapped its Information Security Program to applicable AICM domains based on its business role and risk profile. Confirm that relevant controls are operationalized across teams responsible for application development and lifecycle management—spanning engineering, DevOps, information security, product, and compliance. The program should demonstrate awareness of both standard cybersecurity principles and AI-related security where applicable.

4. Evidence of Operational Implementation: Review documentation and artifacts—such as risk assessments, policy deployment logs, training records, or internal audit results—to verify the practical implementation of the Information Security Program. Select a representative sample of program areas aligned to in-scope AICM domains (e.g., Data Security, Secure Development, Third-Party Risk) and confirm that controls and procedures are both documented and active. Evaluate consistency of enforcement and traceability of responsibilities.

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

1. Policy Examination: Verify that roles and responsibilities related to the AI governance program are formally defined in organizational documentation (e.g., governance charters, policy manuals, program documentation) and that these roles reflect responsibilities relevant to AI application design, development, and deployment. Confirm that the defined responsibilities cover all key phases of the governance lifecycle—planning, implementation, operation, assessment, and continuous improvement—as they apply to AI application development and use.

2. Policy Assessment: Assess whether assigned roles clearly identify accountable individuals or teams and define what authority or decision rights they hold in the context of AI model integration, testing, and release governance. Confirm that the governance roles align with the organization’s structure for application development, deployment, and oversight, including cross-functional coordination among technical and non-technical stakeholders.

3. Program Evaluation: Determine whether the governance program responsibilities are reflected in operational practices (e.g., task assignments, meeting records, project plans), especially for activities such as model validation, bias review, and performance monitoring. Verify that roles include escalation paths and review checkpoints to address governance-related issues during the AI application lifecycle, such as exceptions to model risk standards or incidents involving AI output.

4. Implementation Validation: Review documentation such as meeting minutes, governance workflows, decision logs, or internal assurance results (e.g., audits, compliance reviews, or team assessments) to confirm assigned roles are being actively fulfilled in the execution of AI-related governance tasks. Select a sample governance function (e.g., model monitoring, data access approvals) and confirm that documented role responsibilities are reflected in practice.

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

1. Policy Examination

   • a. Verify that the organization maintains a documented inventory of applicable standards, regulations, and legal or contractual obligations related to the development and use of AI-powered applications and services.

   • b. Confirm that the organization considers multiple sources (e.g., industry-specific regulations, regional data protection laws, contractual AI use clauses, internal policies) when identifying applicable requirements, including those affecting application functionality, explainability, and end-user impact.

2. Policy Assessment

   • a. Assess whether the documented requirements are reviewed and updated on a defined cadence (e.g., annually or upon regulatory/significant change) and whether responsibility for tracking updates is clearly assigned compliance, legal, or AI risk owners.

   • b. Confirm that the documented requirements are scoped to reflect the organization’s AI application footprint, including regional operations, customer base, target markets, and service offerings.

3. Program Evaluation

   • a. Determine whether identified obligations are incorporated into internal controls, development standards, and risk assessment procedures relevant to AI application design, deployment, and monitoring.

   • b. Confirm that governance stakeholders (e.g., compliance, legal, product management) have visibility into the list of applicable requirements and use it in risk-based decision-making and product lifecycle oversight.

4. Implementation Validation

   • a. Review supporting documentation (e.g., risk assessments, contract templates, design review checklists, or compliance review records) to confirm that the documented obligations are referenced or embedded in relevant AI development and deployment processes.

   • b. Select a sample of documented requirements (e.g., regional AI laws, customer-specific AI clauses) and verify that there is evidence of consideration, interpretation, or alignment within applicable procedures or documentation.

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

1. Policy Examination Engagement Strategy: Verify whether the organization has a documented strategy, policy, or stated objective encouraging participation in relevant external groups focused on AI application development, security, compliance, or innovation. Confirm that the purpose of external engagement is defined (e.g., to monitor emerging risks, contribute to standards, or access industry guidance), particularly for cloud-hosted or AI-driven applications.

2. Policy Assessment Group Relevance: Assess whether identified groups or entities are relevant to the organization’s AI application context (e.g., cloud security alliances, AI developer communities, regulatory advisory boards). Responsibility Assignment: Verify that individuals or roles responsible for external engagement are assigned and documented, and that participation aligns with internal governance functions (e.g., product, InfoSec, risk).

3. Program Evaluation Engagement Mechanism: Determine whether the organization has a structured process for selecting, tracking, or evaluating its participation in external forums, and whether this process is supported by leadership or governance committees. Information Flow: Confirm that insights or takeaways from external involvement are shared internally with relevant teams and used to inform application development, security, or compliance practices.

4. Implementation Validation Evidence of Participation: Review documentation such as meeting notes, event attendance, working group membership, or collaboration artifacts to validate active engagement with relevant external entities. Sample Group Validation: Select a sample of identified external groups (e.g., CSA, OWASP AI/ML project, AI cloud infrastructure alliances) and verify that engagement aligns with the stated business context and application provider responsibilities.

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

1. Examine the AI Acceptable Use Policy for adequacy, currency, and communication to relevant interested parties and users.

2. Verify that the AI Acceptable Use Policy identifies the applicable AI applications and users subject to these guidelines.

3. Verify that the AI Acceptable Use Policy clearly defines the intended uses of the AI application, specifying what constitutes acceptable and prohibited use cases as applicable

4. Verify, through interviews or otherwise, that the policy is communicated to users and/or internal personnel 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 Application Providers (AP)

1. Verify that an approved AI Impact assessment process exists. The process should include how the methodology/criteria evaluates AI systems on a regular basis as per company’s policy.

2. Verify that the evaluation process is integrated with the AI system lifecycle (e.g., design, development, deployment and monitoring phases).

3. Verify the evaluation criteria and scoring mechanism exists across all the dimensions such as ethical, societal, legal, operational, and security.

4. Assess how the impact assessment methodology evaluates differential impacts across various customer segments or usage patterns within the multi-tenant service environment.

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

1. Bias and Fairness Policy: Confirm a documented policy exists for assessing and mitigating bias in end-user applications, aligned with Responsible AI principles and relevant regulations.

2. Representative User Contexts: Ensure training and fine-tuning consider diverse user demographics, languages, and contexts relevant to the application’s global reach.

3. Fairness in Output Behavior: Verify that models are evaluated and adjusted to reduce biased or harmful outputs across different use cases and user interactions.

4. Real-Time Monitoring and Safeguards: Confirm mechanisms exist to detect, log, and respond to bias-related issues in real-time usage.

5. Transparency to Users: Ensure that limitations, fairness considerations, and usage guidelines are clearly communicated to users (e.g., through system cards, help docs).

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

1. Verify that AP has an ethics committee consists of a diverse set of stakeholders needs to be involved AI application lifecycle.

2. Verify the AP roles and responsibilities are clearly defined and documented.

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

1. Verify that the Application Provider 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 selecting algorithms based on explainability criteria defined in the explainability requirements.

5. Verify that the Application Provider is transparent about its explainability practices and that 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 Application Providers (AP)

1. Verify that explainability requirements are defined based on the regulatory needs, ethical considerations and compliance requirements

2. Verify there is a processes and frameworks how to evaluate the AI services

3. Verify that limitations (e.g.: partial explainability due the nature of the algorithm) and exceptions (e.g.: consequence of error is negligible) are clearly identified, documented and communicated to the stakeholders

4. Ensure that the degree of explainability is evaluated and documented for each AI service integrated into the application.

5. Verify that the explanations are interpretable by non-technical user friendly

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

1. Verify that the Application Provider (AP) 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 throughout their entire lifecycle. 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 over the entire AI systems’ lifecyle (from the design and market placement to the maintenance/upgrade and decommission phases).

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

1. Policy Documentation and Approval: Verify that the AP has a documented, approved background verification policy covering employees, contractors, and third parties, proportional to access level and risk.

2. Defined Criteria: Verify that the policy defines consistent screening criteria: criminal history, employment history, education, professional licenses, credit checks (if relevant).

3. Transparency and Consent: Verify that the policy is communicated to applicants clearly and that written consent is obtained, following applicable privacy and fairness laws.

4. Use of Providers: Verify that the AP uses reputable, compliant third‑party providers (where applicable) for background checks.

5. Handling Adverse Findings: Verify that the policy defines fair processes for addressing adverse findings, allowing applicants to respond or appeal.

6. Data Privacy and Security: Verify that personal data from background checks is securely stored, protected, and handled in compliance with data protection laws.

7. Verify that the policy is reviewed and updated at least annually, or upon significant changes to risk, law or assurance expectations.

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

1. Policy Establishment and Documentation: Verify that the AP has established and formally documented an Acceptable Use Policy (AUP) that governs the use of organizational assets, including networks, devices, software, cloud environments, and data, and development environments, code repositories, and production systems.

2. Policy Communication and Acknowledgement: Verify that the AUP is communicated to all relevant personnel. Ensure that personnel acknowledgments (e.g., signed forms, system confirmations) are captured and retained as evidence of awareness.

3. Content of the AUP: Confirm the AUP clearly defines: Acceptable and prohibited activities (e.g., no illegal activities, no harassment, no unauthorized access) as well as specific guidance for use of development environments, code repositories, production environments, installation of software and use of personal devices (BYOD); remote work, social media, and internet usage; and protection of sensitive information and compliance with security/privacy obligations and consequences for violations.

4. Monitoring and Enforcement: Verify that methods for monitoring compliance (e.g., system logs, alerts) are defined and implemented to detect potential violations. Confirm that the policy defines and communicates consequences for non‑compliance.

5. Periodic Review and Maintenance: Verify that the AUP is reviewed at least annually and updated as necessary based on organizational, regulatory, or risk changes. Confirm that records of reviews and updates are maintained.

6. Feedback and Continuous Improvement: Check that feedback from employees or audit findings is collected and analyzed to improve the policy over time.

7. Awareness and Culture Check: Conduct a sample of employee interviews to assess their awareness of the AUP, especially regarding acceptable use of development and production environments.

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

1. Ensure application provider has a documented policy prohibiting display of confidential application-related data (e.g., user data, API keys, logs, model outputs) in unattended workspaces.

2. Confirm the policy is approved by relevant stakeholders (e.g., security, compliance, product leads) and version-controlled.

3. Verify the policy is communicated to all staff involved in app development, deployment, and support (e.g., engineers, QA, DevOps).

4. Check enforcement through screen lock policies, session timeouts, and workspace monitoring.

5. Review incident logs for any breaches involving unattended exposure of sensitive data.

6. Ensure the policy is reviewed and updated annually to reflect changes in app architecture, data handling practices, or regulations.

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

1. Verify the AP has a remote work policy that requires the use of VPNs, multi-factor authentication, and company-managed devices for accessing development and production environments.

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

1. Verify the AP has a documented offboarding procedure that includes the return of all company-owned assets, such as laptops and development hardware.

2. Check that the procedure is integrated with the access revocation process to ensure terminated employees, contractors and third parties, cannot access company systems.

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

1. Verify the AP’s HR and IT policies clearly define the process for changes in employment, including immediate revocation of access to source code, user databases, and deployment pipelines upon termination.

2. Confirm that HR, IT, and the employee’s manager have clearly defined responsibilities in the offboarding process.

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

1. Verify the AP’s onboarding process requires all new hires to sign an employment agreement, which includes confidentiality and IP clauses, before being granted access to code repositories or development systems.

2. Review a sample of new hire records to confirm this.

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

1. Review the AP’s standard employment agreement to ensure it includes clauses requiring adherence to the company’s information security policies, data handling standards, and secure coding practices.

2. Confirm the agreement specifies that any IP developed belongs to the company.

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

1. Verify that job descriptions for the AP’s technical staff (e.g., developers, DevOps) clearly outline their responsibilities for application security, secure coding, and protecting user data.

2. Review the AP’s security and privacy policy to verify it defines security and privacy responsibilities for all roles.

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

1. Assess whether the AI Application Provider (AP) has formally identified and documented its non-disclosure and confidentiality requirements, specifically addressing: protection of proprietary AI models, training data, and prompts; confidential handling of customer data and intellectual property; third-party access controls and contractual obligations.

2. Determine whether the non-disclosure/confidentiality agreements are reviewed at planned interval ensuring alignment with organizational policies and regulatory obligations, and that updates are made in response to changes in technology, threat landscape, or business operations.

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

1. Verify the AP provides security awareness training that includes modules on secure coding practices, common application vulnerabilities (e.g., OWASP Top 10), and the specific risks of AI (e.g., prompt injection).

2. Review training completion records.

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

1. Confirm that personnel with access to sensitive application data (e.g., user inputs, model outputs, usage logs, embedded prompts) receive security training, for example, product engineers handling user-facing AI features must complete secure data handling and privacy training.

2. Check for documented training policies and access-role mappings, such as policies requiring front-end developers and back-end engineers to complete annual security refreshers before accessing production environments.

3. Verify that training is completed and regularly updated to reflect evolving AI application risks for instance may include topics like prompt injection, misuse of generative outputs, and user data leakage.

4. Ensure training is tailored to specific roles (e.g., application developers, product managers, QA testers), such as developers receiving secure coding training, while product managers focus on responsible AI use and user consent practices.

5. Interview staff to confirm awareness of responsibilities and recent updates. For example, ask a QA tester how they handle test data containing sensitive prompts and whether they’re aware of the latest data retention policy.

6. Review how updates are communicated, such as through internal alerts, product team briefings, or monthly compliance newsletters that highlight changes in application security and AI usage policies.

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

1. Review how the Application Provider (AP) identifies and updates applicable AI-related legal, statutory, and regulatory obligations (e.g., ISO 42001, EU AI Act, state-level bias audit laws).

2. Collect evidence of documented processes, legal reviews, and stakeholder involvement (e.g., compliance, legal, AI governance).

3. Interview relevant staff (e.g., ML engineers, product managers) to confirm awareness of their responsibilities under these obligations.

4. Check for role-specific training, signed acknowledgments, and ongoing compliance communications.

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

1. Confirm that the application provider (AP) has an approved AI training policy aligned with its product development, deployment, and support practices (e.g., covering responsible use of generative AI in customer-facing applications).

2. Review documentation to ensure the training program defines role-specific learning paths (e.g., developers on safe model integration, product managers on ethical feature design, support teams on handling AI-generated outputs).

3. Ensure training materials are accessible and communicated through onboarding, internal portals, or team-specific sessions across the provider’s organization.

4. Assess implementation by checking participation records and verifying that personnel across engineering, product, and customer teams receive training relevant to their AI-related responsibilities.

5. Evaluate effectiveness using assessments, feedback, or performance metrics, and confirm that the provider updates training based on incidents, customer feedback, or audit findings.

6. Check that training content is regularly updated to reflect new AI features, regulatory changes, or shifts in customer use cases relevant to the provider’s offerings.

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

1. Confirm the Application provider has a documented Acceptable Use Policy (AUP) for AI, approved by governance bodies and aligned with legal and ethical standards (e.g., prohibiting use of generative AI to create fake reviews or manipulated product images).

2. Ensure the AUP is accessible to all staff (e.g., developers, product teams, support) and clearly defines acceptable and prohibited uses (e.g., restricting unvetted third-party models in production or requiring human oversight for AI-generated support responses).

3. Verify the policy is communicated through onboarding, training, and regular updates (e.g., training product managers on responsible AI design, briefing sales teams on accurate representation of AI capabilities).

4. Review enforcement mechanisms such as monitoring tools, incident logs, and disciplinary actions (e.g., tracking unauthorized model fine-tuning or prompt-based data leakage and ensuring consistent response to violations).

5. Check that the policy is reviewed and updated regularly, with changes reflected in training (e.g., after new AI regulations or the launch of new AI-powered features).

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

1. Confirm that a formal IAM policy governs end-user identity and access within deployed applications.

2. Verify that application-level roles, privileges, and user management workflows are defined in the policy.

3. Ensure the policy addresses federated identity integrations (e.g., SSO, OAuth) and related access controls.

4. Check logs and evidence of policy communication to product managers, app developers, and customer-facing engineers.

5. Validate regular audits and updates to the IAM policy in response to new application features or risk assessments.

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

1. Verify the Application Provider (AP) has established, documented, approved, and communicated policies and procedures governing the management of authentication credentials, including passwords, tokens, API keys, and service accounts, and confirm they are reviewed at least annually or upon significant changes.

2. Confirm the policy defines credential complexity, strength requirements, secure storage methods (e.g., hashing, encryption), and transmission protections.

3. Verify enforcement of multi-factor authentication (MFA) for privileged and administrative access, and confirm support for risk-based or conditional authentication controls where applicable.

4. Confirm controls exist for credential lifecycle management, including issuance, rotation, revocation, expiration, and prevention of credential reuse.

5. Verify non-human credentials (e.g., service accounts, CI/CD tokens, API keys) are uniquely assigned, securely stored, and periodically reviewed.

6. Confirm monitoring, logging, and periodic audits are conducted to evaluate credential policy compliance and detect unauthorized or anomalous authentication activity.

IAM-03: Identity Inventory

Control Specification

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

Auditing Guidelines for Application Providers (AP)

1. Verify that a documented inventory of identities is maintained, accurate, and regularly updated, including human and non-human accounts.

2. Confirm that the identity inventory includes essential attributes, such as role assignments, account status (e.g., active, inactive, orphaned), and associated access levels.

3. Ensure that periodic reviews of the identity inventory are conducted, including verification of account ownership, role appropriateness, and access level validation.

4. Check for the use of automated tools or systems to maintain the identity inventory, including reconciliation with authoritative sources (e.g., HR, directory services).

5. Confirm that accountability is formally assigned for ownership and management of the identity inventory.

6. Verify that documented procedures exist to identify and remediate discrepancies, such as orphaned accounts, unauthorized access, or misaligned roles.

IAM-04: Separation of Duties

Control Specification

Employ the separation of duties principle when implementing information system access.

Auditing Guidelines for Application Providers (AP)

1. Verify that a documented policy exists outlining separation of duties (SoD) requirements, including objectives, scope, and governance expectations.

2. Confirm that roles and responsibilities are clearly defined and assigned to prevent conflicts of interest, especially for critical functions (e.g., access provisioning vs. approval).

3. Verify that separation of duties is enforced through role-based access control (RBAC) or equivalent mechanisms, including automated controls where applicable.

4. Ensure periodic audits are conducted to validate effective enforcement of SoD, and that violations or policy exceptions are formally documented and addressed.

5. Confirm that procedures exist for managing and approving exceptions to the SoD policy, including justification, risk acceptance, and expiration.

IAM-05: Least Privilege

Control Specification

Employ the least privilege principle when implementing information system access.

Auditing Guidelines for Application Providers (AP)

1. Verify that documented policies are in place specifying adherence to the principle of least privilege, including defined responsibilities for role and access governance.

2. Confirm that privileges are assigned based strictly on job responsibilities, and that these assignments are periodically reviewed and adjusted to eliminate excessive or outdated permissions.

3. Verify that privileged activities are logged and monitored, and that any anomalies or suspicious activity are escalated according to documented procedures.

4. Ensure procedures exist to investigate and remediate violations of least privilege policies, including timelines, responsible roles, and incident resolution steps.

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

1. Verify that documented procedures exist for user access provisioning, including requirements for request initiation, approval, and recordkeeping.

2. Confirm that access is provisioned based on documented role definitions and IAM policy, ensuring accuracy, least privilege, and alignment with business needs.

3. Ensure that provisioning is performed in a timely manner, and that records reflect approval timestamps and assignment accuracy.

4. Verify that provisioning activities are logged and auditable, with clear accountability and traceability for each provisioning action.

5. If automation is used, confirm that systems securely handle provisioning tasks, including input validation, approval routing, and integration with identity sources.

6. Confirm that roles and responsibilities for provisioning are clearly assigned, including accountability for review and exception handling.

IAM-07: Access Changes and Revocation

Control Specification

De-provision or modify identity access in a timely manner.

Auditing Guidelines for Application Providers (AP)

1. Verify that documented procedures exist for user access changes and revocation, including role changes, terminations, and access reassignments.

2. Confirm that access revocation actions are executed promptly, particularly for sensitive or critical roles, and that any automated mechanisms securely support timely de-provisioning.

3. Ensure that records of access modifications and revocations are accurate and complete, reflecting approval, timing, and implementation details.

4. Verify that periodic reviews are conducted to validate the accuracy of access changes, and to ensure access rights remain aligned with current job responsibilities.

5. Confirm that audit trails and compliance follow-up mechanisms exist, including documented evidence of revocation actions and resolution of any discrepancies.

6. Verify that responsibilities for managing access modifications and revocations are clearly defined and assigned.

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

1. Verify that policies require periodic user access reviews, including defined frequency, scope, and responsible roles.

2. Confirm that documented evidence of completed access reviews exists, and that the review includes validation of user roles, entitlements, and justification.

3. Ensure that discrepancies identified during access reviews are documented and resolved, and that follow-up actions are completed in a timely manner.

4. Verify that responsibilities for conducting access reviews are formally assigned, and that escalation paths for unresolved issues are documented.

5. Confirm that audit trails are maintained for all access review activities, including reviewer identity, review outcomes, and remediation logs.

6. If automated tools are used, verify that they are configured to support periodic and risk-based access reviews effectively, including report generation and alerting.

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

1. Confirm that documented policies define the segregation of privileged and non-privileged roles, including explicit separation of access to data, cryptographic keys, and logging functions.

2. Verify that role definitions prevent privilege overlap, and that assignment criteria for privileged roles are clearly defined.

3. Check that procedures exist for securely assigning privileged roles, with supporting documentation and formal approval processes.

4. Verify that enforcement mechanisms are in place, including technical controls, monitoring, and alerting to detect segregation violations.

5. Confirm that remediation steps are documented and implemented, and that any violations are promptly resolved.

6. Ensure that periodic audits are conducted to validate compliance with privileged access segregation policies.

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

1. Verify that documented procedures exist for managing privileged roles, including assignment, tracking, and governance responsibilities.

2. Confirm that privileged roles are assigned through formal, recorded approvals, with justification and appropriate authorization based on job function.

3. Ensure that privileged role assignments are time-bound where applicable and that temporary elevated access is revoked automatically after the defined duration.

4. Verify that controls are in place to prevent the accumulation of multiple segregated privileged roles by a single individual, unless explicitly approved with documented risk acceptance.

5. Ensure continuous monitoring and logging of privileged role activities, including access to sensitive systems, data, or administrative functions.

6. Check that periodic audits are conducted specifically targeting privileged role usage, including review of necessity and appropriateness of assignments.

7. Confirm that accountability is clearly assigned and documented for privileged role management, including role ownership, approval authority, and audit responsibilities.

8. Ensure secure handling of privileged credentials, including use of password vaulting, session management, and access logging.

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

1. Verify that documented policies and procedures define governance of high-risk roles, including criteria for customer or external stakeholder participation where applicable. Specify how such participation is formally evidenced.

2. Ensure high-risk roles are clearly identified based on impact, privileges, and system sensitivity, including those affecting AI model integrity or critical outputs.

3. Check that documented procedures exist for involving customers (or their representatives) in the approval process for designated high-risk roles, especially in multi-tenant or service-oriented environments.

4. Confirm that the process includes periodic evaluation to assess the effectiveness of customer involvement and governance of high-risk roles.

5. Review records showing that role definitions, approvals, and external stakeholder involvement are reviewed and updated based on changes in threat landscape or service structure.

6. Ensure accountability is assigned for maintaining, monitoring, and updating the high-risk role governance process.

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

1. Verify that each user is assigned a unique identifier or that traceability mechanisms are in place to associate system activities with a specific individual.

2. Confirm that documented procedures exist for creating, assigning, and managing unique user identifiers, including system-generated IDs or federated identities.

3. Check that automated systems enforce uniqueness and prevent duplication of user identifiers.

4. Verify that periodic audits are conducted to validate the consistency, uniqueness, and traceability of user identifiers across systems.

5. Confirm that accountability for managing and maintaining user identifiers is clearly documented, including roles responsible for provisioning, deprovisioning, and reconciliation.

6. (Optional) If applicable, ensure that user identifiers are securely managed and protected, including appropriate access restrictions to identity data.

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

1. Confirm that documented policies mandate strong authentication mechanisms, including password complexity, multi-factor authentication (MFA), and device-level security measures.

2. Confirm that password creation follows strong policies, including minimum length, complexity, prevention of reuse, and enforcement of multi-factor authentication (MFA) for privileged or high-risk accounts. (Under modern security standards, omission of MFA weakens credential management control)

3. Ensure that system identities (e.g., service accounts, APIs, machine workloads) are authenticated using digital certificates, cryptographic keys, or other strong credentials.

4. Check that authentication methods comply with current best practices and industry standards (e.g., NIST SP 800-63, OWASP ASVS).

5. Confirm that technical controls are in place to enforce authentication requirements, such as conditional access, session timeouts, and login attempt limits.

6. Ensure regular audits are conducted to validate the effectiveness and adherence of authentication mechanisms.

7. Verify that documented procedures exist for credential recovery, reset, and revocation, including secure identity verification steps.

8. Review monitoring mechanisms that detect authentication anomalies, such as brute-force attempts, logins from unusual geolocations, or session hijacking indicators.

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

1. Verify that documented procedures exist for managing passwords throughout their lifecycle, including creation, distribution, usage, reset, storage, and revocation.

2. Confirm that password creation follows strong policies, including minimum length, complexity, prevention of reuse, and enforcement of multi-factor authentication (MFA) for privileged or high-risk accounts.

3. Ensure that passwords are stored securely using encryption or cryptographic hashing, and are never stored or transmitted in plaintext.

4. Verify that automated controls are in place to enforce password policies, such as expiration, lockout thresholds, and failed attempt limits.

5. Confirm that access to systems or tools managing password storage is restricted to authorized personnel only, with access logged and monitored.

6. Ensure that periodic reviews are conducted to validate that password management practices align with current organizational and industry standards.

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

1. Verify that authorization policies are defined and documented, specifying how access rights are granted, modified, and revoked within applications and services.

2. Confirm that access to systems and data is restricted based on defined user roles or attributes, and enforced using mechanisms such as role-based or attribute-based access control.

3. Ensure that systems log denied access attempts and unauthorized access requests, and that these logs are reviewed regularly to detect potential abuse or misconfiguration.

4. Check that changes to authorization rules or entitlements follow a documented approval process, with audit trails maintained.

5. Verify that periodic reviews of authorization assignments are conducted, and that access rights are adjusted in response to changes in roles, responsibilities, or business requirements.

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

1. Verify that documented policies and procedures enforce “need to know” access principles, covering data, system functions, model configurations, and other forms of knowledge or sensitive information related to AI systems.

2. Confirm that access to AI artifacts (e.g., training data, model weights, system prompts) is limited to users with a justifiable business requirement, and enforced through access control mechanisms.

3. Ensure that access permissions are defined, assigned, and reviewed based on role or responsibility, with restrictions applied to reduce exposure to non-relevant information or systems.

4. Check that access review procedures include knowledge-based assets, and that excess or outdated access is revoked in a timely manner.

5. Verify that access provisioning and revocation related to sensitive AI knowledge is logged and auditable, including requests, approvals, and changes.

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

1. Verify that policies and procedures exist to restrict model output modification, ensuring that only authorized individuals or systems can alter generated outputs or override system behavior.

2. Confirm that special authorization is required for any interventions that alter or influence AI model output, such as prompt injection handling, result overrides, or tampering with inference layers.

3. Ensure that roles permitted to perform output modification are clearly defined and assigned, and that these roles are subject to elevated oversight or approval.

4. Check that all output modifications, overrides, or interventions are logged, including identity of the actor, reason for intervention, and timestamp.

5. Verify that periodic audits are conducted to review the frequency and appropriateness of model output modifications, with evidence of management oversight.

6. Ensure that emergency or sensitive interventions are controlled through predefined procedures, and that the scope is limited to output-level actions rather than model retraining, access changes, or architectural updates.

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

1. Verify that documented policies and procedures exist for managing access to agent-based tools, including orchestration agents, automation bots, AI agents, and any autonomous systems capable of initiating actions.

2. Confirm that access to agent configuration, deployment, and execution is restricted to authorized personnel only, and that role-based access controls are enforced.

3. Ensure separation of duties is implemented, so that no single individual has full control over agent provisioning, credential management, and execution.

4. Verify that authentication credentials (e.g., API keys, tokens) used by agents are securely stored, rotated regularly, and access to them is monitored and restricted.

5. Confirm that all agent activities and access attempts are logged, and that logs are reviewed periodically to detect unauthorized or anomalous usage.

6. Check that any overrides, escalations, or emergency interventions involving agent tools follow documented approval procedures, with post-action reviews and audit trails maintained.

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

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 AP’s organization.

3. Examine the policy for evidence of review and updating by the policy owner or committee at least annually.

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.

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

1. Review available documentation to verify that the AP has clearly specified the application interface capabilities, endpoints, and usage guidelines.

2. Examine the documentation describing security measures implemented to protect the API, including but not limited to authentication, encryption, and rate limiting.

3. Verify that API security measures align with industry standards (e.g., OWASP).

4. Verify processes for onboarding service customers and facilitating their understanding of API usage.

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

1. Review the Interoperability and Portability Policy, procedures for coverage, relevancy and effective communication to relevant stakeholders.

2. Verify that the policy specifies the use of secure communication protocols (e.g., TLS 1.3, SFTP) and the supported cipher suites. Ensure that it also defines the types of data covered, such as user logs, model training data, and other sensitive information.

3. Verify the policy contains acceptable and non acceptable methods of data management including clearly specifying secure and insecure practices.

4. Verify, through interviews or documentation, that the policy is communicated to users and internal personnel and acknowledged by relevant parties.

5. Examine the policy for evidence of review and updating by the policy owner or committee at least annually.

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

1. Examine contractual obligations to include provisions for data accessibility post termination of the contract.

2. Review that the data portability provisions are comprehensive, relevant, and aligned with current legal, regulatory, and industry standards.

3. Ensure that the data portability provisions are operationalized effectively within the Application Provider’s infrastructure.

4. Confirm that the contractual provisions and their associated obligations are communicated to and understood by relevant internal as well as external parties.

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

1. Examine Application Provider’s (AP) policies and procedures that defines the scope, objectives, roles, and responsibilities for securing design, development and maintenance infrastructure and virtualization environments.

2. Verify the Policies and Procedures ensure third-party (e.g., MP, OSP, CSP) reviews and controls are place and considered in the AP 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 AP operational effectiveness and compliance.

6. Verify that security policies and procedures are regularly reviewed and updated to address emerging threats, vulnerabilities, evolving business needs, changes with third-party dependencies, 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 Application Providers (AP)

1. Examine the Application Provider’s capacity and resource planning document that explicitly addresses AI resource availability, quality, and capacity to meet business objectives and service level agreements. This should include scope, roles, responsibilities, and processes for forecasting, scaling and monitoring resources.

2. Verify capacity plans, performance forecasts, and scaling procedures are review and approve by senior management or governance authorities.

3. Verify performance metrics regularly, proactively identify potential capacity constraints, and verify compliance with agreed-upon service levels.

4. Verify performance planning procedures regularly review, at least annually and align with changing business demands, system performance metrics, emerging technologies, and evolving threats.

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

1. Examine network policies and procedures to ensure they are aligned with AI business requirements.

2. Verify network and logical segmentation mechanisms to ensure proper isolation between security zones, environments, services, and applications, including controls implemented at the application, service, and identity layers.

3. Determine access controls, protocols, and encryption to secure communication between environments, services, and applications, ensuring only authenticated, authorized connections are permitted.

4. Verify continuous monitoring of network communications and logging to detect and address unauthorized or unusual activities promptly.

5. Verify regular reviews, at least annually, with policy updates to align with AI business needs and evolving threats, ensuring structured 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 Application Providers (AP)

1. Examine Application Provider’s documented policies and hardening security baselines to ensure alignment with Application Provider (AP) business needs and industry best practices.

2. Determine if appropriate technical controls are in place to enforce and verify system hardening (e.g., for DevSecOps environments, CIS benchmarks for build servers).

3. Verify regular assessments conducted against established security baselines, ensuring promptly addressing any identified deviations or vulnerabilities.

4. Verify an annual review of hardening configurations for hosts, guest OS, and hypervisors, ensuring documented results are reviewed and approved by authorities.

5. Determine if emerging threats are monitored and hardening procedures are updated accordingly, ensuring all changes are systematically documented and approved.

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

1. Examine Application Provider (AP) policies and procedures ensuring separation of production and non-production 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 environments, restricting production access to authorized personnel only.

3. Verify documented procedures ensuring production data is not used in non-production environments unless sanitized or otherwise protected before any authorized use.

4. Verify formal change promotion processes between non-production and production environments prevent unauthorized data transfer and preserve environment separation, including documented approvals and integrity validation.

5. Verify monitoring and logging are implemented across all 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 evolving threats, regulatory requirements, and business needs.

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

1. Verify documented policies and procedures define how application-level segmentation and segregation enforce service customer (tenant) access boundaries.

2. Verify application-level controls (e.g., authorization logic, session handling, request routing) are implemented to prevent unauthorized cross-tenant access to application functions and data.

3. Verify identity and access management controls restrict user and service identities to their assigned service customer (tenant) context, consistent with least-privilege principles.

4. Verify whether segmentation controls are periodically tested or validated to confirm that service customer isolation cannot be bypassed through application workflows, APIs, or user interactions.

5. Confirm incident response procedures address failures of service customer (tenant) isolation at the application layer, including unauthorized cross-tenant access or data exposure.

6. Verify application logs and monitoring mechanisms are configured to detect and alert on unauthorized cross-tenant access attempts or anomalous activity spanning service customer boundaries.

7. Confirm relevant personnel receive training on application-level segmentation responsibilities, including risks associated with misconfigurations that could impact service customer isolation.

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

1. Verify the Application Provider (AP) documented migration procedures explicitly require secure, encrypted communication channels (e.g., encryption along the Application Development DevSecOps tool chain, data movement across environments).

2. Confirm encryption mechanisms adhere to current security standards.

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

1. Verify the Application Provider (AP) 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, Secure by Design, Secure by Default, Threat Modeling, Pen Testing).

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

1. Verify the Application Provider (AP) documented procedures clearly define network defense mechanisms.

2. Confirm regular implementation and evaluation of defense strategies (e.g., Monitoring on DevSecOps tool chains, Source Code Access Controls, signing compiled code, 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 Application Providers (AP)

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 logging policies are tailored to application-layer events and include details on authentication, authorization, and API access.

   2. Ensure logs are generated for key application events, such as input validation failures, output anomalies, and user access requests.

   3. Validate that logging and monitoring responsibilities are assigned to appropriate DevOps or application security personnel.

   4. Confirm that logs are securely transmitted to a centralized logging infrastructure without tampering.

   5. Check that logs are retained in compliance with documented policies and regulatory standards.

   6. Ensure the logging configuration is reviewed with each major application release or update.

   7. Validate that monitoring tools can alert on abnormal application behavior based on logs.

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

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.

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

1. Inquiring with Control Owners: Interview personnel responsible for identifying, monitoring, and alerting on security-related events within AI applications and integrated AI model 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 access, malicious manipulation of AI-enabled functionality, or data exposure.

2. Inspecting Records and Documents

   1. Verify documented procedures define security-related events to be monitored within AI applications, including user interactions, API usage, authentication events, and session activity.

   2. Verify monitoring mechanisms are implemented to detect defined security events across AI applications and integrated components (e.g., prompt injection attempts, unauthorized feature access, abnormal usage patterns indicative of malicious activity, adversarial inputs, 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. Determine whether monitoring covers security-relevant infrastructure supporting AI applications (e.g., model serving environments, API endpoints, data processing pipelines).

   7. Review evidence that monitoring configurations and alert thresholds are periodically reassessed and updated as application architecture 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 Application Providers (AP)

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, modification, and deletion events are logged with timestamps, actor IDs, and specific data accessed, and that audit logs are protected against unauthorized alteration.

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

1. Inquiring with Control Owners: Interview personnel responsible for monitoring AI application security audit logs to understand how anomalous or suspicious activity is identified, including how baseline usage patterns are defined and how deviations are detected. Determine how detected anomalies are reviewed and what process is followed to take timely and appropriate security actions.

2. Inspecting Records and Documents

   1. Verify security audit logs are generated and monitored for AI applications, including user authentication events, API usage, AI model requests and responses, and data access activity.

   2. Verify correlation rules or detection mechanisms are implemented to identify suspicious or anomalous activity that deviates from defined baseline or expected patterns.

   3. Review documentation defining baseline usage patterns and criteria used to classify activity as anomalous or suspicious.

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

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.

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

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. Confirm that changes to the defined logging scope are documented with version history, formal approvals, and traceability to relevant regulatory requirements or compliance obligations.

   11. Validate that implementation of AI application logging scope requirements is consistently applied across all AI-powered features, user interfaces, and integrated model services.

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

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

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.

LOG-10: Audit Records Protection

Control Specification

Protect audit records from unauthorized access, modification, and deletion.

Auditing Guidelines for Application Providers (AP)

1. Inquiring with Control Owners

   1. Conduct interviews with personnel responsible for protecting application 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 application 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 Application Providers (AP)

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.

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

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.

LOG-13: Access Control Logs

Control Specification

Monitor and log physical access using an auditable access control system.

Auditing Guidelines for Application Providers (AP)

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.

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

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.

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

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.

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

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.

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

Scenario 1: Consumption Only (No Training/Fine-Tuning):

Training Pipeline Security: Not Directly Applicable (responsibility with MP/OSP). Focus is on due diligence and secure integration.

Policy and Procedure Review: Review policies and procedures for the secure use and integration of the pre-trained model, covering input/output validation, access controls, secure configuration, and secure data handling.

Best Practices Adherence: Verify adherence to relevant security best practices (e.g., OWASP Top 10).

1. Implementation Verification: Review application code, audit API security measures, and assess the application for vulnerabilities, focusing on secure input/output handling, access controls, and configuration related to model integration.

2. Due Diligence: Audit that the AP performed due diligence on the MP and/or OSP regarding their training pipeline security (review contracts, SLAs, certifications, audit reports).

3. Regular Review and Update: Review documentation supporting regular policy reviews and updates.

Scenario 2: Fine-Tuning:

Training Pipeline Security (Fine-Tuning Portion): The AP has direct responsibility.

Policy and Procedure Review: Review documented processes and procedures for the entire fine-tuning pipeline, including data preprocessing, the fine-tuning process itself, integration of the fine-tuned model, and security of all related code. Ensure that these policies and procedures are formally approved.

Best Practices Adherence: Assess alignment with OWASP Top 10 and other relevant guidelines, specifically for the fine-tuning process.

1. Implementation Verification: Audit the implementation of fine-tuning security by reviewing the fine-tuning code and configurations, auditing the security of the data used for fine-tuning (including its source, storage, and access controls), assessing the security of the infrastructure used for fine-tuning, and verifying that appropriate security measures are in place to prevent data poisoning, model manipulation, or other relevant attacks.

2. Regular Review and Update: Review evidence of regular reviews and updates to the fine-tuning security measures.

3. Due Diligence (Base Model): Audit that the AP performed due diligence on the provider of the base model.

4. Data and Pre-trained Model Security (if applicable): Verify how datasets are being used and secured, and how any Pre-trained models leveraged are being used and secured.

Scenario 3: Full Training (Rare):

Follow the Model Provider guidelines.

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

Scenario 1: Consumption only, not model fine-tuning: Perform the following at least yearly or if new model is used.

1. Examine AP processes and procedures for verifying pre-trained model integrity and security upon initial integration and updates.

2. Confirm a trusted source for the model is used.

3. Validate digital signature or checksum verification (if provided).

4. Check for any AP-specific security scanning of the model before deployment.

5. Assess alignment with industry best practices.

6. Audit implementation through logs, configurations, and evidence of performed checks.

7. Examine documentation for regular policy reviews and updates.

Scenario 2: Fine-Tuning or Modifying the Model:

1. Examine documented processes and procedures for periodic model artifact scanning, covering all stages where the AP handles/modifies the model (data preparation, fine-tuning, integration).

2. Verify documented processes cover all stages.

3. Assess if the scanning frequency aligns with risk appetite and best practices.

4. Audit implementation of scanning processes.

5. Confirm the use of appropriate scanning tools.

6. Inspect scan configurations.

7. Examine scan reports.

8. Verify timely remediation of identified vulnerabilities.

9. Confirm a documented process for secure model hand-over.

10. Check for evidence of regular process, procedure, and tool reviews/updates.

Scenario 3: Full Training (Rare):

Follow the Model Provider guidelines.

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

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-04: Model Documentation Requirements

Control Specification

Establish and implement baseline requirements for Model documentation.

Auditing Guidelines for Application Providers (AP)

Applicability Considerations:

Scenario 1 (Consumption Only): While direct control creation may not be relevant, the AP should be able to verify and validate the template with the pre-trained model provided from the provider.

Scenario 2 (Fine-Tuning/Modification): The AP has direct influence, including validating all steps.

1. Review that the AP ensures and verifies that the format and parameters from the third-party meet requirements and documentation is maintained for validation that is complete.

2. Assess whether the requirements of all stakeholders are addressed and maintained, as part of a systematic plan, as defined by regulations or internal policies.

3. Audit the process used when validating the process that model development, deployment and/or code is checked to see that the models are built with a consistent model card using approved template.

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

Applicability Considerations: The level of AP’s direct responsibility varies depending on involvement in the model development lifecycle

Scenario 1 (Consumption Only): Due diligence.

Scenario 2 (Fine-Tuning/Modification): Responsibility for consistency of own changes. Perform the following at least yearly or any new model changes.

1. Review AP’s policy and procedures to support efforts used to perform periodic validation of the Model Card.

2. Verify the defined data, roles and responsibilities are being followed.

3. Evaluate and verify model changes during regular validation points are checked.

4. Assess how findings are recorded and what processes are in place.

5. Audit due diligence that all components are in action to the proper lifecycle stage.

If only consuming the existing Model Card, review if steps were taken to validate that that access to the Model Card is secure.

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

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. (For APs that fine-tune models: Review methodologies for evaluating threats related to fine-tuning processes or application-specific model customizations.)

3. Assess the threat prioritization framework, confirming that attack vectors are ranked based on application architecture and user interaction patterns.

4. Verify implementation of monitoring systems for detecting application-level attack indicators.

5. Review testing procedures for application-specific defenses against prioritized threats.

6. Examine coordination processes with upstream providers on shared threat mitigations.

7. Verify mechanisms for communicating relevant threat information to end-users.

8. Review processes for updating threat assessments when application features change or new attack techniques emerge.

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

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

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

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

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

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.

8. Clearly outlining the documented procedures for failure management and recovery.

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

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

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. For secure handling of different serialization formats for LLM models, focus on both integrity and confidentiality throughout the model lifecycle. Always verify the source of serialized model files and use cryptographic signatures to detect tampering. Avoid loading models from untrusted or unauthenticated sources, as serialized files may contain malicious payloads, especially if using formats like Python pickle (.pkl) or PyTorch’s .pt, which can execute arbitrary code. Use sandboxed environments or restricted deserialization methods where possible. Encrypt serialized models at rest and in transit using strong, up-to-date encryption protocols, and enforce strict access control to limit exposure. Logging and auditing all model load operations adds an additional layer of accountability in production systems.

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

1. Verify the Application Provider (AP) has documented and approved security incident management policy, aligned with recognized industry standards such as NIST SP 800-61, NIST AI.100 or ISO/IE1.C 27035.

2. Verify policies, and procedures include E-discovery and Forensics for Applications.

3. Confirm that roles and responsibilities for incident detection, reporting, escalation, and resolution are clearly defined and documented. Ensure coordination points are identified with other parties (e.g., such as OSP, MPs, AICs).

4. Confirm the Application Provider (AP) has procedures for e-discovery and forensics for application.

5. Check that procedures cover the full incident lifecycle, including initial reporting, triage, escalation criteria, containment, eradication, recovery, and post-incident review.

6. Ensure that the policy and procedures are communicated effectively to all internal and external stakeholders, including third-party service providers, where applicable.

7. Verify that the incident management policy and related procedures are reviewed and updated periodically, or following major incidents, organizational changes, or regulatory updates.

8. Confirm that regular training is provided to incident response teams, with materials updated based on emerging threats and lessons learned.

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

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, contracts, incident severity level, maintaining data across MLops lifecycle).

3. Review dependencies and partners (e.g., MP, OSP) which could impact the ability of the AP 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 Application Providers (AP)

1. Verify the Application Provider (AP) has incident response plans clearly documented and approved.

2. Confirm incident response plans cover critical scenarios and critical dependencies comprehensively (e.g., MP, OSP, CSP, AIC).

3. Check plans define specific roles, dependencies, and escalation procedures.

4. Verify the incident response plan includes a documented communication strategy for notifying internal departments, impacted service customers, and critical third-party relationships (e.g., OSPs, MPs, CSPs) in the event of a security incident.

5. Ensure regular reviews and updates of incident response documentation.

6. Confirm testing, table top exercises and drills of incident response plans performed periodically (e.g., engage supplier and partners).

7. Confirm validation of expectations from critical dependencies for suppliers and third parties to execute on plan.

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

1. Confirm the AP conducts planned exercises of incident response plans at defined intervals or when significant changes occur in the application, model, or supporting infrastructure.

2. Verify comprehensive documentation of each exercise, including scope, participants, outcomes, and lessons learned.

3. Check whether improvements identified during exercises are prioritized, assigned, and tracked through completion.

4. Ensure stakeholders involved in AI service delivery (e.g., DevOps, ML, security, legal) participate in exercises.

5. Validate that exercise scenarios include realistic, evolving threats such as model compromise or inference leakage.

6. Confirm that results from exercises are reviewed in governance forums and lead to updates of the response plan as needed.

SEF-05: Incident Response Metrics

Control Specification

Establish, monitor and report information security incident metrics.

Auditing Guidelines for Application Providers (AP)

1. Verify AP has documented metrics for evaluating incident response effectiveness.

2. Confirm metrics align with application objectives, organizational goals and industry best practices (e.g., Mean Time to Detect (MTTD), Mean Time to Respond (MTTR), Mean Time to Contain (MTTC), Mean Time to Recover (MTTR)).

3. Check regular collection, analysis, reporting and review of 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 Application Providers (AP)

1. Verify the Application Provider (AP) 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., MLops process, application and environmental logs).

4. Understand triage models from suppliers and partners (e.g., OSP, CSP, MP, AIC).

5. Check regular training provided on event triage methods and appropriate resources.

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

1. Verify incident response categories and severity levels clearly documented (e.g., consider failures in the application, data security, API security).

2. Verify well defined response procedures are determined, including automated responses where applicable (e.g., application monitoring and alerts; SIEM; SOAR; monitoring with alerts).

3. Confirm well-defined roles and escalation pathways during incident response.

4. Check documented incident response timelines and service level agreements (SLAs).

5. Ensure regular reviews of incident response activities and outcomes (e.g., coordination with MP, OSP, CSP, and AIC where applicable). Maintain documented records of reviews and outcomes, and document actions taken for any deviations observed.

6. Verify processes and procedures for incident handling are formally defined and tested at least annually or bi-annually.

7. Confirm training is provided to relevant stakeholders on incident response processes at a frequency defined in alignment with organizational policies.

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

1. Verify the Application Provider (AP) has documented policies clearly specify requirements for breach notification.

2. Confirm procedures comply with applicable legal and regulatory requirements.

3. Confirm the procedure covers essential information in notifications (e.g., application incident details).

4. Ensure regular testing of breach notification procedures.

5. Verify reporting of breaches to appropriate parties within defined SLA and confirm procedures are reviewed on a periodic basis to incorporate changes in laws and SLA requirements.

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

1. Verify the Application Provider (AP) has documented policies that clearly specify requirements for collecting, classifying, storing, protecting and retaining incident records specific to the AI application environment.

2. Verify the policies define clear trigger conditions for when a security incident must be recorded.

3. Confirm the AP maintains a secure incident record repository with appropriate access controls, encryption (transit and rest) and audit logging to prevent unauthorized access, modification or deletion.

4. Determine whether the AP conducts periodic reviews of incident records to identify recurring patterns, root causes, systemic vulnerabilities (e.g. prompt injection attacks, data exposure, application layer misconfigurations or access violations) and whether the review cadence and review process is 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 Application Providers (AP)

1. Verify documented procedures for Application Provider (AP) to meet regulatory responsibilities and maintain points of contact.

2. Verify procedures for review of dependencies with OSP, MP, AIC and CSP that would impact Application Provider’s ability to meet its regulatory contact obligations (e.g., ISO 27001).

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

1. Ensure the policy includes LLM APIs, SDKs, ML APIs, plug-ins, etc.

2. Check formal approval trail with dates and roles.

3. Inspect communication records or training for dev, product, and security teams.

4. Request examples of supplier vetting (e.g., plugin validation, API security checks).

5. Evaluate use of criteria like security posture, SLA, open-source review for dependencies.

6. Validate whether integrations or model stack changes trigger policy revisions.

7. Confirm the policy aligns with applicable regulations (e.g., GDPR, AI Act) and frameworks (e.g., NIST CSF, CSA CCM).

8. Check for performance metrics or periodic reviews that assess the effectiveness of the supply chain risk management practices.

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

1. Verify that the AP has established and documented policies and procedures defining organizational and technical measures aligned with the Shared Security Responsibility Model (SSRM), tailored to the application‑layer services and relevant third parties.

2. Verify that SSRM policies and procedures are compliant with applicable regulatory requirements and industry best practices.

3. Confirm formal approval of SSRM policies and procedures by authorized parties.

4. Verify that the SSRM policies and procedures have been communicated clearly to all stakeholders, with an emphasis on delineated responsibilities and no conflicting or overlapping assignments.

5. Confirm implementation of SSRM policies and procedures in daily operations by relevant stakeholders.

6. Assure that performance metrics and indicators are monitored to evaluate effectiveness and identify improvement areas.

7. Verify evidence of periodic review (at least annually) and updates to SSRM policies and procedures in response to changes in technology, threat landscape, or regulation.

8. Verify that the SSRM policy explicitly defines the AP’s responsibilities at the application layer, including controls such as input validation, API security, and user access management.

9. Review public‑facing documentation (e.g., trust center, terms of service) to confirm SSRM responsibilities are communicated transparently to customers and partners.

STA-03: SSRM Supply Chain

Control Specification

Apply, document, implement and manage the SSRM throughout the supply chain.

Auditing Guidelines for Application Providers (AP)

1. Verify that the AI application provider (AAP) publishes its SSRM in customer-facing materials, contracts, and documentation, clearly outlining shared responsibilities across the application stack.

2. Examine how the AAP implements and governs inherited responsibilities from upstream providers such as securing infrastructure from CSPs, maintaining orchestration integrity, and validating model behavior and integrates them into its operational and security practices.

3. Assess the clarity and completeness of the responsibility matrix, ensuring it maps roles and obligations across the supply chain including CSPs, orchestration providers, model developers, and customers for accountability and traceability.

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

1. Confirm the application provider delivers clear and accessible SSRM guidance to AI service customers (AICs), outlining shared responsibilities across the application, model, orchestration, and infrastructure layers.

2. Examine the AP’s public-facing resources such as documentation, help centers, or trust portals for detailed explanations of service customer responsibilities, including data protection, access control, configuration management, and integration security.

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

1. Confirm the AP has mapped all CSA AICM controls to its internal framework, identifying which are AP-owned, inherited (from CSP, MP, OSP), or customer-owned (AIC), with clear documentation and justification.

2. Review the mapping for accuracy and completeness using SSRM guidance, validate ownership assumptions, identify gaps, and ensure updates reflect current responsibilities.

STA-06: SSRM Documentation Review

Control Specification

Review and validate the SSRM documentation.

Auditing Guidelines for Application Providers (AP)

1. Confirm the Application Provider (AP) has a process to regularly review its own SSRM documentation and that of key suppliers (e.g., CSP), ensuring alignment and clarity on shared responsibilities.

2. Examine these reviews occur at least annually or when significant service changes happen (e.g., new cloud region, architecture updates, reflect changes in data residency and encryption responsibilities).

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

1. Verify through testing and evidence review that the AP is implementing the controls it is responsible for under the SSRM (e.g., application-level access controls, vulnerability management of its code).

2. Review the AP’s internal audit or compliance reports.

STA-08: Supply Chain Inventory

Control Specification

Develop and maintain an inventory of all supply chain relationships.

Auditing Guidelines for Application Providers (AP)

1. Assess whether the application provider (AP) maintains a centralized and up-to-date inventory of all third-party services and technologies involved in supporting the AI application lifecycle.

2. Confirm that all integrated service relationships including infrastructure, data sources, model providers, APIs, and platform components are documented.

3. Evaluate whether the inventory is subject to periodic review and validation to ensure its completeness, accuracy, and alignment with current operational and regulatory requirements.

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

1. Verify that the application provider (AP) maintains a documented SBoM process, with regular reviews triggered by updates to application architecture, dependencies, or security posture.

2. Review the SBoM for completeness, ensuring it includes APIs, application versions, runtime environments, third-party libraries, security controls, and risk classifications with relevant metadata.

3. Validate inclusion of both infrastructure and AI-specific components, such as back-end services, model integrations, inference endpoints, and telemetry or monitoring tools.

4. Inspect the security and access controls of the SBoM repository, confirming role-based access for authorized stakeholders, including cloud security teams, orchestration providers, and model developers.

5. Assess the timeliness and accuracy of SBoM updates, ensuring changes to application logic, integrations, or deployment environments are promptly reflected, with documented impact assessments reviewed by security teams.

6. Confirm that SBoM information is clearly communicated, including application capabilities (e.g., supported features, model behaviors, latency expectations, input/output formats), SLAs, limitations, and integration protocols, with validated security disclosures.

STA-10: Supply Chain Risk Management

Control Specification

Periodically review risk factors associated with supply chain relationships.

Auditing Guidelines for Application Providers (AP)

1. Confirm the AI Application Provider (AP) conducts supply chain risk reviews at least annually or after significant changes such as integrating a new model provider or updating a cloud deployment addressing risks related to operations, security, compliance, and reputation.

2. Ensure risk assessments are documented, regularly updated, and informed by indicators such as SLA breaches, incident reports, or audit findings e.g., recurring latency issues from a hosting provider or non-compliance with data handling standards while involving relevant internal teams.

3. Verify that identified risks result in mitigation actions such as updating service agreements, enhancing monitoring, or transitioning to alternate providers and that these actions are tracked and supported by audit-ready documentation, especially when risks affect model performance or regulatory 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 Application Providers (AP)

1. Review whether the AI application provider’s agreements with third-party partners clearly define essential terms, including service scope, security (with SSRM), change management, monitoring, incident response, audit rights, termination clauses, interoperability, data privacy, and operational resilience.

2. Evaluate whether the defined contractual terms are aligned with the AI application provider’s internal policies and risk management practices, and confirm that responsibilities are clearly understood and accepted by all third-party partners.

STA-12: Supply Chain Agreement Review

Control Specification

Review supply chain agreements at least annually, or upon significant changes.

Auditing Guidelines for Application Providers (AP)

1. Confirm the AI application provider (AP) reviews supply chain agreements with key supply chain partners, such as CSPs, MPs, and OSPs at least annually or after major changes in services, risk, or regulations.

2. Verify that the outcomes of these reviews are documented and that any identified gaps or risks are addressed through updated contractual terms, mitigation plans, or partner re-evaluations.

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

1. Establish that the Application Provider (AP) maintains a formal, recurring audit process to evaluate governance across AI systems, data management, cloud infrastructure, and application delivery pipelines (e.g., model deployment, API integrations).

2. Examine audit documentation for recorded issues, such as data handling gaps or model drift risks, and verify that corrective actions are tracked, implemented promptly, and aligned with applicable AI regulations, standards, and internal controls.

3. Confirm that audit outcomes are reported to relevant stakeholders and that a structured feedback loop exists to refine audit practices and enhance responsible AI operations over time.

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

1. Confirm that the Application Provider (AP) has a defined and implemented process for including security, compliance, and governance requirements into contracts with supply chain partners, including cloud service providers, AI model vendors, data suppliers, and third-party integrators.

2. Determine whether these contracts explicitly address areas such as data protection, application integrity, regulatory compliance, and service-level commitments, ensuring alignment with the AP’s risk management framework and operational standards.

3. Review whether the AP retains contractual rights to audit or assess its supply chain partners as needed, to verify adherence to agreed-upon controls and to manage risks related to sensitive data, application performance, and service continuity.

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

1. Ensure the AP has a defined process to review the governance practices of supply chain partners involved in data, AI, cloud, and service delivery, with clearly allocated responsibilities and requirements for partners to uphold equivalent AI ethics and data governance standards, including transparency and accountability.

2. Verify that these reviews are conducted at least annually, or upon significant changes, and documented, ensuring supplier practices align with the AP’s responsible AI commitments.

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

1. Confirm the AP has a formal process for assessing supply chain data security, covering AI components (e.g., model training environments, inference APIs) and cloud infrastructure (e.g., storage encryption, identity and access management).

2. Review how the AP identifies risks from third-party cloud providers, AI vendors, and data suppliers such as insecure data pipelines, unverified model sources, or lack of compliance with data residency laws.

3. Check for documented procedures to manage risks from external parties handling sensitive data or supporting AI workflows, including data labeling services, model hosting platforms, and integration partners.

4. Verify that regular security assessments are conducted and address risks in cloud data flows (e.g., data ingress/egress points), AI integration (e.g., third-party model APIs), and data lifecycle management (e.g., retention, deletion, and audit logging).

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

1. Policy Establishment and Documentation: Verify that the AP has established and documented policies and procedures for vulnerability and threat management, defining organizational and technical measures to identify, report, and prioritize remediation efforts. Ensure the policies clearly define scope, objectives, roles, and responsibilities.

2. Compliance and Context: Inspect whether the policies and procedures are aligned with applicable regulatory requirements, industry best practices, and relevant threat scenarios specific to the AP’s operations.

3. Approval: Verify that the policies and procedures have been formally reviewed and approved by authorized management.

4. Communication and Awareness: Verify that the policies and procedures have been communicated to all relevant stakeholders and that their content is understood.

5. Operational Application: Confirm that the policies are effectively implemented and applied in day‑to‑day operations by responsible parties.

6. Evaluation and Metrics: Verify that appropriate metrics and monitoring processes are in place to evaluate the effectiveness of the policies and identify areas for improvement.

7. Review and Update: Inspect evidence that the policies are reviewed and updated at least annually or after significant changes, with revisions documented.

8. Verify that the TVM policy explicitly covers the full application stack, including custom code, open‑source libraries, containers, and APIs.

9. Confirm that the policy mandates regular vulnerability scanning integrated into CI/CD (e.g., SAST, DAST, SCA).

10. Check that the policy defines a risk‑based process for prioritizing and remediating vulnerabilities (e.g., based on CVSS scores or similar).

11. Verify that policies and procedures include formalized mechanisms and dedicated communication channels for Vulnerability Disclosure activities.

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

1. Verify that the Application Provider (AP) 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 AP’s policy requires malware scanning of all build artifacts and third-party dependencies within the CI/CD pipeline.

9. Confirm the policy includes protections against malicious instructions being embedded in application code (e.g., through code reviews and static analysis).

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

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 AP has a documented vulnerability remediation schedule with defined SLAs based on severity (e.g., critical vulnerabilities patched within 15 days).

7. Confirm a process exists for emergency, out-of-band patching for zero-day vulnerabilities in the application.

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

1. Verify that the Application Provider (AP) 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 Application Providers (AP)

1. Verify that the Application Provider (AP) 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 AP’s process for updating signatures and rules in its security tools (e.g., WAF, SAST, DAST, SCA scanners) is automated and occurs frequently.

7. Confirm that custom detection rules for AI-specific attacks like prompt injection are reviewed and updated regularly.

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

1. Verify that the Application Provider (AP) 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 AP uses Software Composition Analysis (SCA) tools to create and maintain a Software Bill of Materials (SBOM) for its application.

7. Confirm there is an automated process within the CI/CD pipeline to scan for vulnerabilities in third-party and open-source libraries and block builds if critical vulnerabilities are found.

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

1. Verify that the AP has defined and documented processes, procedures, and technical measures for periodic penetration testing by independent third parties. Ensure documentation includes 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 the AP is exposed to (e.g., OWASP Top 10, AI‑specific threats).

4. Confirm that these processes are implemented appropriately and on schedule.

5. Verify that penetration testing results are reviewed, and findings are translated into concrete remediation actions.

6. Inspect whether metrics and KPIs are defined and monitored to evaluate the efficacy and efficiency of the penetration testing program.

7. Inspect evidence that the processes are periodically reviewed and updated by responsible parties.

8. Verify that the AP’s penetration tests include user‑facing applications and assess specific risks such as prompt injection, insecure direct object references in APIs, and common web application vulnerabilities.

9. Review the most recent penetration test report and track the remediation status of all identified findings, confirming closure or mitigation.

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

1. Verify that the Application Provider (AP) 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 Application Providers (AP)

1. Verify that the Application Provider (AP) 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 Application Providers (AP)

1. Validate threat modeling of inference endpoints (e.g., prompt injection, jailbreaks).

2. Review use of runtime monitoring and anomaly detection.

3. Confirm existence of prioritized API security risk register.

4. Evaluate threat detection automation and alert prioritization.

5. Review logs of mitigation actions (e.g., blocking, throttling, sanitization).

6. Check inclusion of AI-specific threat handling in incident response plans.

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

1. Verify that the Application Provider (AP) has defined a process to systematically document both the vulnerabilities identified within the security perimeter and the activities implemented to remediate them. Ensure that the process is documented in detail, covering scope, objectives, roles and responsibilities.

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

1. Verify that the Application Provider (AP) 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 Application Providers (AP)

1. Verify that the Application Provider (AP) 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 Application Providers (AP)

1. Verify that the AP has established and documented endpoint device management policies and procedures, including scope, objectives, roles, responsibilities, audit frequency, criteria, methodology, and remediation.

2. Confirm that these policies are compliant with relevant regulations, industry best practices, and appropriate to the threat scenarios the organization faces.

3. Verify formal approval by authorized management.

4. Ensure the policies are effectively communicated to all stakeholders and understood.

5. Confirm they are appropriately applied and enforced in daily operations.

6. Verify monitoring of effectiveness through metrics and performance indicators.

7. Check that policies are reviewed and updated at least annually or after significant system changes.

8. Review policy content to ensure it covers development, testing, and production endpoints (e.g., laptops, servers, cloud VMs).

9. Confirm specific controls for encryption, anti‑malware, patch management, access control, and endpoint monitoring.

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

1. Verify that the Application Provider (AP) has established and documented policies and procedures in the domain of endpoint device management that—by defining approved list of services, applications and sources of applications—aim at leading efforts to protect the endpoint devices apps are from validated source and secured. 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 gaps and improve the approved services policy.

7. Inspect whether the above-mentioned policies and procedures are periodically reviewed and updated (at least annually) 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 Application Providers (AP)

1. Verify that the Application Provider has established and documented a Device Compatibility Policy, defining scope, supported platforms, hardware architectures, testing requirements, and minimum device resources (CPU, RAM, storage, network).

2. Inspect whether the policy includes clear roles and responsibilities, governance approval, and a mechanism for periodic review and updates to account for OS/hardware evolution.

3. Confirm that the policy mandates standardized testing (e.g., functional, integration, performance benchmarks) across major endpoint classes (desktops, laptops, mobile, edge), with documentation of supported configurations and known limitations.

4. Verify actual implementation through artifacts such as compatibility matrices, test results, bug reports, release notes, and change management logs.

5. Ensure the compatibility policy is aligned with security and compliance requirements, and integrated with other operational controls (e.g., resource handling, graceful degradation, secure configuration).

UEM-04: Endpoint Inventory

Control Specification

Maintain an inventory of all endpoints used to store, access and process company data.

Auditing Guidelines for Application Providers (AP)

1. Verify that the Application Provider has established and documented an Endpoint Inventory Policy, defining scope, roles, responsibilities, and governance approval.

2. Inspect whether the policy includes criteria for categorizing endpoints based on their relationship to the application, defines update frequency or event-based triggers, and mandates collection of key attributes such as device type, OS, and resource usage.

3. Confirm that the policy requires periodic audits to reconcile the documented inventory with actual devices, and includes provisions for secure decommissioning or removal of sensitive data from retired devices.

4. Review implementation through evidence such as inventory reports, device classification records, audit logs, decommissioning procedures, and integration with endpoint management or security tools.

5. Verify that automated asset discovery tools are used to maintain an up-to-date inventory, with integration to security monitoring systems and compliance documentation.

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

1. Verify that the Application Provider has a documented Endpoint Management Policy, including scope, roles, responsibilities, governance approval, and key phases of endpoint management.

2. Inspect whether the policy covers the entire endpoint lifecycle, including procurement, configuration, updates, decommissioning, and application-specific security controls.

3. Confirm that the policy mandates standardized configurations, prompt patching, centralized endpoint management, and integration with incident response processes and regulatory requirements.

4. Review implementation evidence such as onboarding records, patch logs, monitoring dashboards, policy enforcement reports, and device retirement documentation.

5. Verify that endpoint management tools are in place to enforce consistent updates, detect exceptions, and handle offboarding securely.

UEM-06: Automatic Lock Screen

Control Specification

Configure all relevant interactive-use endpoints to require an automatic lock screen.

Auditing Guidelines for Application Providers (AP)

1. Verify that the Application Provider has a documented Automatic Lock Screen Policy, including governance approval, scope, and assigned roles and responsibilities.

2. Inspect whether the policy defines inactivity timeouts based on data sensitivity, specifies secure unlock methods, documents exception handling procedures, and references relevant compliance frameworks.

3. Confirm that the policy requires periodic audits and applies to all supported device platforms, with attention to operational continuity for background tasks.

4. Review implementation evidence such as device configuration records, compliance dashboards, exception logs, audit reports, and impact testing on application functionality.

5. Verify that endpoint management solutions or group policies enforce lock screen settings consistently across devices.

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

1. Verify that the AP has a documented Change Management Policy covering OS version selection, patching cadence (including emergency/zero‑day), and application compatibility requirements.

2. Inspect the policy to confirm it defines clear roles and responsibilities, formal approval, and a periodic review/update cycle.

3. Confirm the policy mandates OS hardening baselines (e.g., disabling services, secure boot, minimal installation) and references applicable regulations or industry standards.

4. Verify that the policy requires testing of OS patches/upgrades (functional, performance, security) in QA/staging before production deployment.

5. Review implementation artifacts (OS inventories, patch schedules/logs, vulnerability scan reports, change‑management tickets, and audit records) to ensure patches and upgrades follow the policy.

UEM-08: Storage Encryption

Control Specification

Protect information from unauthorized disclosure on managed endpoint devices with storage encryption.

Auditing Guidelines for Application Providers (AP)

1. Verify that the AP has a documented Storage Encryption Policy, formally approved, that defines scope, roles, responsibilities, and review cadence.

2. Inspect the policy to confirm it specifies cryptographic standards for data at rest, key generation/storage/rotation/retirement processes, allowable exemptions, and applicable data‑protection laws.

3. Confirm the policy mandates encryption of all application data stored locally on endpoints across Windows, macOS, Linux, iOS, Android, or other supported platforms.

4. Verify that the policy requires automated compliance checks (such as key rotation logs and endpoint encryption status) and integrates with endpoint management systems (e.g., Intune, Jamf).

5. Review implementation artifacts (device encryption status reports, key rotation logs, configuration baselines, exception documents, compliance/audit trails, and incident‑response procedures) to ensure 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 Application Providers (AP)

1. Verify that the AP has a documented Anti‑Malware Policy, formally approved, defining scope, roles, responsibilities, and review cadence.

2. Inspect the policy to confirm it mandates baseline protections such as real‑time scanning, routine full‑system scans, scheduled signature/engine updates, and advanced detection methods for novel threats.

3. Confirm the policy specifies response actions when malware is detected (e.g., quarantine, alerting, remediation) and references any applicable data‑protection regulations.

4. Verify the policy applies to all endpoint platforms running or accessing the application and requires integration with endpoint‑management tools (e.g., Intune, Jamf).

5. Review implementation artifacts (installation/configuration records, compliance dashboards, update logs, incident‑response documentation, exception records, and periodic test/audit results) to ensure enforcement.

UEM-10: Software Firewall

Control Specification

Configure managed endpoints with properly configured software firewalls.

Auditing Guidelines for Application Providers (AP)

1. Verify that the AP has a documented Software Firewall Policy, approved by governance, with defined scope, roles, responsibilities, and review cycle.

2. Inspect the policy to confirm it mandates approved baseline firewall configurations and default‑deny rules, and defines procedures for exceptions.

3. Confirm the policy requires logging of relevant firewall events and central aggregation of logs for correlation with other security data.

4. Verify that the policy enforces formal approvals for opening ports or protocols and includes patch and update processes for the firewall software itself.

5. Review implementation artifacts (baseline configuration files, rule change logs, log‑management dashboards, patch records, exception approvals, and periodic audit or penetration‑test reports) to ensure compliance.

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

1. Verify that the AP has a documented DLP Policy, formally approved, defining scope, roles, responsibilities, and review cadence.

2. Inspect the policy to confirm it mandates classification and labeling of application‑specific data, integration of classification into data models, and criteria for sensitive data detection.

3. Confirm the policy requires deployment of DLP agents or controls on all endpoints accessing or hosting application data, with rules for clipboard, removable media, email, and cloud uploads.

4. Verify that the policy specifies detection and response actions such as alerts, blocking, encryption, and documented approval processes for legitimate large data transfers or third‑party sharing, and references applicable regulations.

5. Review implementation artifacts (data classification artifacts, endpoint DLP configurations, alert/incident logs, exception approvals, secure transfer measures, and periodic audit reports) to ensure 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 Application Providers (AP)

1. Verify that the Application Provider has a documented Remote Locate Policy, formally approved and maintained, including defined scope, roles, and responsibilities.

2. Inspect whether the policy establishes approval processes for remote locate commands, protects user privacy, addresses application-triggered tracking, defines location data retention/deletion, and integrates with incident response plans.

3. Confirm the policy applies across relevant device types, mandates strong authentication for location requests, ensures secure transmission and storage of location data, and requires periodic audits of usage.

4. Review implementation evidence such as device management console settings, locate request logs, privacy documentation, and incident reports.

5. Verify that only authorized personnel can execute locate commands and that secure management platforms are in place for consistent and compliant tracking.

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

1. Verify that the Application Provider has a documented Remote Wipe Policy, approved under formal governance, defining scope, roles, and responsibilities.

2. Inspect whether the policy mandates strict or multi-layer approval for remote wipe commands, aligns wipe actions with data classification, addresses applicable regulations, clarifies technical wipe procedures, integrates with incident response, and requires routine audits of wipe logs.

3. Confirm the policy covers various devices, distinguishes between full and partial wipes, and requires secure authorization and communication channels for wipe commands.

4. Review implementation evidence such as authorization records, technical execution logs, compliance dashboards, incident response reports, and forensic documentation.

5. Verify that remote wipe actions are enforced through MDM, UEM, or equivalent tools and that access to wipe functionality is limited to authorized personnel.

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

1. Verify that the Application Provider has a documented Third-Party Endpoint Security Policy or Agreement, approved under formal governance, defining roles and responsibilities.

2. Inspect whether the policy mandates third-party security evaluations before access, requires specific contractual security controls (e.g., encryption, patching), enforces continuous monitoring, requires incident notifications, defines secure offboarding, references relevant regulations, and includes periodic audits.

3. Confirm that the policy applies network segmentation or zero-trust principles to limit vendor endpoint access and includes performance review mechanisms for third-party security.

4. Review implementation evidence such as vendor contracts, security monitoring logs, audit reports, and vendor compliance documentation.

5. Verify that vendors meet all security obligations through thorough validation of risk assessments, security clauses, monitoring reports, incident response records, offboarding procedures, certifications, and exception handling records.