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

1. Verify that orchestrated pipelines have standardized audit procedures that span across integrated components (e.g., model inference + API + logging layers).

2. Check for policies on isolating tenants in shared cloud environments and ensuring audit integrity for each client’s pipeline.

3. Evaluate how policy updates reflect changes in orchestration logic or underlying services (e.g., addition of a new AI model from a vendor).

4. Confirm that cloud audit logs, API gateway logs, and orchestration events are systematically collected and referenced in policy.

5. Determine the existence of a continuous review model, like a standing committee or automated mechanism (e.g., policy-as-code tooling), that regularly evaluates assurance policies.

6. Validate that AI-enabled features, integrated components, and orchestrated workflows are explicitly included in the scope of routine penetration testing and security control audits, covering both individual services and their interactions.

A&A-02: Independent Assessments

Control Specification

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

Auditing Guidelines for Orchestrated Service Providers (OSP)

Objective: Verify that complex, composed AI systems, where the orchestrator manages the integration of models, applications, and possibly data brokers, are assessed independently for systemic and inherited risks.

1. Assess End-to-End Coverage: Independent assessments must evaluate orchestrated workflows, data flows, dependency risks, and SLAs.

2. Validate Multi-Party Audit Inclusion: Check if assessments involved evaluation of connected third-party models and services.

3. Check for Cross-Standard Integration: Assess if the audit reconciled diverse standards (e.g., ISO 42001 + ISO 27017 + OWASP LLM Top 10).

4. Review Conflict-of-Interest Declarations: Ensure independence of assessors from any component vendor or internal DevOps teams.

5. Check Frequency and Evidence: Annual audits must include key orchestration changes and be evidenced through detailed reports.

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

1. Review whether independent audit and assurance activities are planned and scoped based on documented risk assessments, audit policies, and orchestration-specific risk factors, including risks arising from integrating multiple AI components and services.

2. Evaluate the governance framework used to oversee orchestration activities to determine whether it supports risk-based audit planning and timely adjustments to audit scope in response to significant changes or emerging risks.

3. Determine whether audit plans explicitly account for risks introduced by interactions across multiple actors (e.g., model providers, application providers), and whether independent audits include coverage of interoperability and end-to-end orchestration behavior commensurate with assessed risk.

4. Review whether logs, audit trails, and monitoring outputs from orchestration workflows are used to inform ongoing audit planning and trigger audit activities in response to material incidents, control failures, or emerging risk indicators.

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

1. Conduct Legal Harmonization Review: Check whether integrated models and apps have consistent licensing, IP, and privacy guarantees.

2. Verify SLA Mapping: Ensure contracts include language that carries upstream obligations downstream (e.g., subprocessors, sub-vendors).

3. Review Regulatory Assessments: Examine impact assessments, such as DPIAs or algorithmic impact assessments.

4. Check Continuous Monitoring: Audit the provider’s mechanisms to track ongoing compliance of orchestrated components (e.g., component version changes).

5. Trace Regulatory Responsibility: For end-user-facing features, verify which actor owns compliance (orchestrator provider or model/app provider).

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

1. Assess Coordination Mechanism: How are audits planned and executed across model/app integrations? The OSP must coordinate audits across multiple components and vendors, each with distinct risks and responsibilities, in accordance with relevant auditing standards.

2. Check Governance Layer: Does the provider establish audit handoffs and shared evidence management? Their audit management process must integrate multi-actor control inheritance, cross-domain assessments, and system-wide risk aggregation.

3. Review Systemic Risk Tracking: Evaluate how risks from orchestration complexity are included in the audit plan.

4. Examine Evidence Portability: Is audit evidence normalized and retained in a traceable format?

5. Audit Reporting Practices: Confirm that reports synthesize findings across actors and provide unified remediation tracking.

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

1. Verify that a centralized system or registry exists to track all audit findings and corrective actions across orchestrated service components, ensuring cross-functional visibility and coordination.

2. Assess whether documented escalation protocols exist to address systemic risks that cross vendor, partner, or component boundaries, including risks propagating through the orchestration chain.

3. Evaluate whether service-level agreements (SLAs) include defined remediation timelines, responsibilities, and enforcement mechanisms across all dependent actors.

4. Verify that remediation progress and status are regularly reported to internal and external stakeholders through executive summaries, dashboards, or equivalent briefings.

5. Confirm that evidence of remediation actions (e.g., logs, configurations before/after, change tickets) is retained to support verification, audits, and future retesting.

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

1. Policy Examination: Examine the organization’s AI application and interfaces security policy to confirm it exists and addresses appropriate planning, delivery, and support of the organization’s application security capabilities. Confirm it covers key areas such as impact assessments, model lifecycle management, data protection, logging, and secure API practices.

2. Evidence of Approval: Check for documented approvals (e.g., management sign-off, board minutes) and confirm the policy is reviewed at least every 12 months.

3. Evidence of Communication: Review evidence (e.g., attestation records, training attendance, internal memos) confirming stakeholders received instruction on the policy.

4. Implementation Validation: Verify the policy’s implementation by inspecting records, logs, or system configurations that show compliance in practice.

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

1. Verify that a documented security baseline exists for each AI model, application, and orchestration service.

2. Determine whether AI models and applications are classified based on risk factors, including purpose, data sensitivity, model complexity, and regulatory impact.

3. Assess whether the documented security baseline effectively mitigates AI-specific risks, such as adversarial attacks, model drift, API security vulnerabilities, and data leakage.

4. Evaluate whether the security baseline aligns with applicable legal, regulatory, and industry standards (e.g., GDPR, CCPA, NIST AI RMF, EU AI Act, OWASP AI Top 10).

5. Examine implementation records and system configurations to confirm that security baselines are enforced as specified.

6. Verify that the security baseline documentation undergoes periodic review and updates following major changes, emerging threats, or regulatory shifts.

7. Determine whether automated monitoring and alerting mechanisms are in place to detect deviations from security baselines.

8. Review and analyze a sample of security alerts and incident reports to assess the effectiveness of monitoring and response mechanisms.

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

1. Check for cross-service metrics (e.g., failure rate between orchestrated APIs, fallback trigger counts, dependency risk scores).

2. Verify metrics are tagged per actor or service component (e.g., model, plugin, orchestration module).

3. Evaluate processes for aggregating, deduplicating, and normalizing metrics.

4. Confirm how metrics support runtime policy enforcement and SLA adherence tracking.

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

1. Verify that the SDLC includes dependency mapping, version compatibility testing, and secure orchestration logic (e.g., API routing, policy-as-code enforcement). OSPs often coordinate services built by other actors—secure orchestration is essential.

2. Confirm that end-to-end threat modeling includes cross-service abuse paths, integration vulnerabilities, and fallback mechanism risks. Complex workflows introduce lateral risk—if one component is compromised, others can be affected.

3. Assess how SBOMs from integrated components are merged, validated, and scanned for aggregate vulnerability exposure.

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

1. Verify that a defined testing strategy for orchestrated AI workflows (e.g., pipelines, API integrations, third-party model handling) is in place.

2. Ensure that automated, continuous tests of the orchestration logic, model update mechanisms, and service dependencies are existing.

3. Verify that AI-specific threats, such as chaining attacks, misconfigurations, and data leaks through orchestration, are covered as part of the testing strategy.

4. Ensure that the detected issues are remediated and result in updates of the orchestration security.

5. Ensure a periodic review of the testing mechanisms and coverage, as AI/ML systems constantly evolve.

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

1. Assess Composite Deployment Plans: Orchestrated systems require coordination between multiple actors and services. Request system architecture diagrams and review orchestrator configurations (e.g., Airflow, Argo Workflows).

2. Review Dependency Validation and Version Control: Ensure upgrades don’t break interdependencies or introduce mismatched security postures. Inspect whether component versions are tracked and tested together prior to deployment.

3. Evaluate Centralized CI/CD Controls: Central pipelines should enforce checks across all integrated services. Audit how MP/AP-provided components are revalidated, and whether SBOMs and vulnerability scans are enforced end-to-end.

4. Check Policy Enforcement in Deployment Logic: Orchestration may need to enforce cross-component policies (e.g., data flow rules). Verify policy-as-code enforcement using tools like OPA/Gatekeeper during deploy builds.

5. Validate Failover and Rollback Capabilities: Simulate or review past incidents to confirm fallback mechanisms (e.g., model switching) function securely.

AIS-07: Application Vulnerability Remediation

Control Specification

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

Auditing Guidelines for Orchestrated Service Providers (OSP)

1. Map Vulnerability Inheritance Across Components: OSPs absorb risks from upstream actors (e.g., MPs, APs). Inspect component inventory, SBOM linkage, and dependency maps.

2. Check Aggregated Vulnerability Reporting: Correlate findings across services, and request centralized dashboards or risk scores from orchestration control planes.

3. Assess Policy-Based Remediation Triggers: Remediation should be conditional on component criticality. Verify use of policy-as-code to auto-prioritize critical CVEs.

4. Review Remediation SLAs and Playbooks: Sample evidence from security incidents involving integrated services.

5. Test Failover and Mitigation Capability: Validate automation that reroutes requests or disables risky components during remediation.

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

1. Verify that measures and processes exist to secure APIs, including: monitoring and alerting of orchestrated services, runtime protections, and key management and rotation of orchestrated services.

2. Verify that 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 Orchestrated Service Providers (OSP)

1. Verify that the OSP as procedures and technical measures in place which address AI-specific adversarial inputs and need to be aligned with current threats. Ensure that comprehensive documentation exists.

2. Verify robust detection and mitigation of adversarial AI inputs across interfaces and service orchestration points by examining technical input validation measures.

3. Confirm the OSP regularly conducts Red Teaming exercises which are focused on validating robustness against evolving AI adversarial input threats across their orchestration infrastructure and service delivery points.

4. Verify that the findings documented in the Red Teaming reports are translated into improvements for orchestration and integration points for adversarial AI input validation.

5. Ensure that continuous monitoring is in place. Verify the effectiveness metrics with regards to AI adversarial input validation within orchestration.

6. Verify that regular updates take place and that reviews are performed with regards to orchestration-level input validation controls which address evolving AI threats and Red Teaming outcomes.

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

1. Verify that the OSP maintains defined procedures and technical controls addressing AI-specific insecure outputs, including those arising from orchestration across multiple models or services. Verify that integration points and threat-specific documentation exists.

2. Verify the technical validation mechanisms at orchestration points to ensure their effectiveness against insecure AI-generated outputs. Verify that robust detection mechanisms across integrated services and models are in place.

3. Confirm that AI Red Teaming at the OSP level is regularly conducted to validate the robustness of orchestration and integration points against unsafe and adversarial AI-generated outputs.

4. Review AI Red Teaming findings and ensure that these are translated into process and technical improvements for orchestration points and integration-level output validation controls for a comprehensive protection against insecure and adversarial outputs.

5. Ensure continuous monitoring, and verify the effectiveness of the metrics used to validate insecure and adversarial outputs.

6. Verify that updates are regularly conducted, and ensure that the orchestration-level output validation controls are driven by insights from AI-specific threats and Red Teaming exercises.

AIS-11: Agents Security Boundaries

Control Specification

Establish security boundaries for agents.

Auditing Guidelines for Orchestrated Service Providers (OSP)

1. Verify that documented policies and procedures establish agent security boundaries, and confirm they are approved, communicated, and maintained.

2. Review central control mechanisms mapping agents to their authorized roles, accessible APIs, and allowed domains within the orchestrated environment.

3. Confirm that API tokens are scoped per agent, tool invocations are rate-limited, and agent chaining is governed by defined policies.

4. Check policies and enforcement mechanisms regulating inter-agent message passing and memory sharing to prevent lateral movement risks.

5. Verify that each agent operates in a secure, isolated execution environment (e.g., a function sandbox, container runtime, or equivalent mechanism).

6. Review incident response plans and simulate agent misbehavior scenarios to confirm the OSP can freeze, disable, or contain misbehaving agents.

7. Assess whether monitoring and incident response findings are periodically reviewed and incorporated into boundary policies 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 Orchestrated Service Providers (OSP)

1. Version Control for Orchestration Assets: Verify that version control is implemented for orchestration code, deployment configurations, automation scripts, and infrastructure‑as‑code (IaC) templates. Confirm that commit tracking and change history processes are enforced with evidence of traceability.

2. Code Review of Automation Scripts: Confirm that peer reviews are mandated and performed for scripts and templates managing model deployment, scaling, and orchestration. Inspect review artifacts, such as comments, approvals, and documented changes on infrastructure‑as‑code assets.

3. Static Analysis of Orchestration Logic: Verify that automated static analysis tools (e.g., kube‑linter, tfsec) are used to validate orchestration logic for misconfigurations and security risks. Review analysis outputs and confirm that identified issues are documented, tracked, and mitigated (e.g., tickets, follow‑up logs).

4. SDLC Integration: Ensure that orchestration source code management policies are formally embedded within the organization’s SDLC framework. Identify which lifecycle stages include mandatory checks (e.g., code review, static analysis) before moving orchestration changes to production.

5. Evidence Review: Review a representative sample of CI/CD pipeline security gates, change control tickets, and approval records for orchestration code updates.

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

Focus: The AI Orchestration Service Provider has implemented effective sandboxing techniques to execute AI workflows, model integrations, and customer-defined components in isolated environments, preventing unintended interactions with critical systems or data and limiting the possibility of lateral movement.

1. Inquiry with Control Owners

   1. Interview security architects, platform engineers, and integration specialists responsible for implementing sandboxing in AI orchestration services. Obtain and review the organization’s sandboxing policies and implementation standards, including: multi-tenant isolation architecture for orchestration platforms; sandboxing requirements for customer-provided code execution; model provider connector isolation requirements; agent execution environment security controls; security controls for workflow DAG execution; resource governance and limitations for orchestrated workflows; API gateway security and access control policies; and third-party model integration security requirements. Verify the existence of documented security requirements for: customer workflow isolation from platform infrastructure; model integration connector security boundaries; plugin and extension isolation within orchestration platforms; LLM agent execution containment; security gateway rule enforcement; data flow restrictions between customer workflows; and enterprise data access controls within orchestration pipelines.

   2. Review Sandboxing Technical Implementation: Examine documentation describing: service mesh implementation for request isolation; container orchestration for workflow component isolation; serverless function isolation for task execution; network microsegmentation between orchestration components; API gateway request validation and filtering; resource quotas and limitations for customer workloads; runtime security monitoring for orchestration engines; credentials isolation and secrets management; and cross-tenant access prevention mechanisms.

   3. Assess Integration Security and Isolation: Review mechanisms implementing security between components: model provider connector authentication isolation; connector credential storage and access controls; data transmission security between orchestration components; input validation at integration boundaries; response validation from model providers; pipeline component isolation and permission boundaries; data persistence isolation between workflows; and caching service isolation between customers.

   4. Evaluate Custom Code and Plugin Management: Review procedures for customer code execution security: custom code execution environment isolation; Python/JavaScript dependency isolation; code execution resource limitations; static analysis of customer-provided code; dynamic monitoring of custom code behavior; plugin security review and approval process; agent runtime containment strategies; and workflow DAG validation and security checking.

2. Obtaining and Verifying the Population of Records

   1. Define the Complete Population of Orchestration Components: Define the complete population of orchestration components by obtaining a comprehensive inventory of: workflow orchestration engines and execution environments; model provider integration connectors; custom code execution capabilities; agent frameworks and runtime environments; security gateway implementations; caching services and shared data stores; pipeline component types with execution privileges; inter-service communication channels; customer data processing components; API endpoints exposed to customer workflows; plugin frameworks and extension points; and integration points with enterprise systems.

   2. Verify Population Completeness: Cross-reference the inventory against: platform architecture documentation; API gateway configuration; service registry entries; network traffic flow diagrams; container orchestration deployment manifests; service mesh routing tables; customer capability documentation; integration partnership agreements; enterprise connector documentation; security domain boundary definitions; and data flow architecture diagrams.

   3. Categorize Components by Risk Level: Segment the population based on: access to customer data; execution of customer-provided code; authentication to external systems; multi-tenant vs. dedicated execution; pipeline criticality and data sensitivity; enterprise system access level; usage of third-party model providers; and resource consumption potential.

3. Inspection of Evidence

   1. Sandbox Implementation Review: Select a representative sample of orchestration components based on risk levels. For each sampled component, verify the implementation of: isolation mechanisms (Kubernetes namespace isolation, container security context restrictions, service mesh traffic policies, network policy enforcement, service account permission limitations, function-as-a-service isolation boundaries, virtual machine isolation where applicable, Python/JavaScript runtime sandboxing); resource limitations (Kubernetes resource quotas, CPU and memory limits, network bandwidth throttling, API rate limiting, execution time constraints, database connection pooling limits, storage capacity restrictions, worker node allocation limits); and access controls (service-to-service authentication, Zero Trust network policies, least privilege service accounts, API gateway authorization rules, RBAC for orchestration resources, secret access limitations, data access boundary enforcement, cross-tenant isolation controls).

   2. Integration Security Testing: Review evidence of security testing, including: penetration testing of service boundaries; multi-tenant isolation testing; API gateway security assessments; custom code execution containment testing; model provider connector security testing; agent runtime security evaluation; workflow DAG security validation; and data leakage testing between tenants.

   3. Runtime Monitoring and Security Controls: Verify implementation of: container runtime security monitoring; behavioral analysis of workflow execution; anomaly detection for orchestration patterns; resource usage monitoring and alerting; security gateway logging and monitoring; integration point activity auditing; custom code execution logging; and agent behavior monitoring.

   4. Data Protection within Orchestration Flows: Assess controls for data protection: data minimization in workflow steps; tokenization of sensitive data in transit; ephemeral storage for workflow state; access control enforcement for data stores; cross-tenant data access prevention; model input/output security controls; cache isolation between customers; and data lineage tracking and auditing.

   5. Custom Code and Plugin Security: Examine the implementation of: custom code execution sandboxing; dependency isolation and vulnerability scanning; plugin security review processes; code execution monitoring; function permission boundaries; Python/JavaScript runtime restrictions; package import limitations; and system call filtering, where applicable.

   6. Security Incident Response: Review documentation and evidence of: sandbox escape incident response procedures; tenant isolation breach playbooks; customer notification procedures; affected workflow identification capabilities; isolation procedures for compromised components; security incident investigation tooling; recovery procedures for orchestration environments; and post-incident security enhancements.

   7. Enterprise Integration Controls: Verify the existence and adequacy of: enterprise connector security requirements; authentication isolation for enterprise systems; data transmission security for enterprise data; workflow access control to enterprise resources; security reviews for enterprise integrations; pipeline component security for enterprise workflows; and documentation for secure enterprise integration patterns.

4. Evaluation and Reporting

   1. Sandbox Effectiveness Assessment: Evaluate how well sandbox implementations: prevent unauthorized access between customer workflows; isolate orchestration components appropriately; contain custom code execution securely; limit access to platform infrastructure; maintain appropriate resource allocation; and adapt to emerging orchestration threats.

   2. Isolation Strategy Assessment: Assess the effectiveness of isolation strategies: appropriateness of isolation for multi-tenant architecture; defense-in-depth across orchestration layers; consistency across different integration points; coverage of all execution environments; alignment with cloud-native security practices; and evolution based on orchestration threat models.

   3. Documentation and Process Adequacy: Evaluate the quality of sandbox-related documentation: clarity of security architecture for orchestration components; completeness of security controls for integrations; definition of security boundaries between workflows; security requirements for custom code execution; and enterprise integration security guidance.

   4. Continuous Improvement Mechanisms: Evaluate processes for improving sandbox security: regular security testing of orchestration boundaries; incorporation of lessons learned from incidents; adaptation to new integration requirements; security architecture review frequency; integration of emerging container and service mesh security; and customer security enhancement communication.

AIS-14: AI Cache Protection

Control Specification

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

Auditing Guidelines for Orchestrated Service Providers (OSP)

Focus: The AI Orchestration Service Provider has implemented effective security measures to protect caches in their integration platforms and orchestration services, ensuring both performance optimization and protection of sensitive enterprise data, model responses, and workflow states.

1. Inquiry with Control Owners

   1. Interview Orchestration Platform and Security Leadership: Interview platform architects, integration specialists, and security engineers responsible for orchestration service development and cache implementation. Obtain and review the organization’s caching strategy and security policies covering model response caching, workflow state persistence, vector embedding stores, API result caching, and integration endpoint response storage. Verify documented security requirements exist for multi-tenant cache isolation, enterprise data protection in cached content, cache access controls across customer environments, and handling of credentials or secrets in orchestration workflow caches.

   2. Review Caching Implementation Details: Examine documentation describing the technical implementation of caching within the orchestration platform, including distributed cache services, model response stores, vector database caches, workflow state persistence, and integration connector result caching. Assess how customer-specific cached content is isolated, how enterprise data boundaries are enforced, and how model integration responses are securely cached across different orchestration components and multi-tenant environments.

   3. Assess Multi-Tenant Cache Isolation: Review mechanisms implementing tenant isolation for cached workflow data and AI model interactions, including namespace separation, encryption with tenant-specific keys, access control enforcement, data partitioning strategies, and independent cache instances where appropriate. Evaluate how shared cache infrastructure is secured to prevent cross-tenant data leakage, particularly for high-volume, performance-critical orchestration components.

   4. Evaluate Cache Management for Orchestration Workflows: Review procedures for orchestration cache lifecycle management, including invalidation triggers based on model updates, workflow version changes, integration endpoint modifications, and security policy updates. Assess monitoring systems for cache utilization patterns, performance benchmarking, potential cross-tenant access attempts, and indicators of cache poisoning within the orchestration platform.

2. Obtaining and Verifying the Population of Records

   1. Define the Complete Population of Cache Components: Obtain a comprehensive inventory of caching mechanisms within the orchestration platform, including model response caches, vector stores, workflow state persistence, integration connector response caches, API gateway caches, result transformation caches, security policy caches, and credential/token caches. Include distributed caching services, in-memory stores, persistent cache databases, and cache sidecars used throughout the orchestration infrastructure.

   2. Verify Population Completeness: Cross-reference the cache inventory against platform architecture documentation, service mesh configurations, infrastructure deployment manifests, data flow diagrams, and performance optimization strategies. Ensure the inventory aligns with orchestration workflow documentation, model integration specifications, service-level agreement requirements, and enterprise data handling policies 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, multi-tenant usage patterns, cache persistence level, enterprise data exposure, workflow criticality, integration point complexity, cache size, and potential impact if compromised. This risk-based categorization should guide the depth and frequency of security assessment for each orchestration caching component.

3. Inspection of Evidence

   1. Cache Implementation Security Review: Select a representative sample of orchestration platform caching mechanisms based on risk levels and verify the implementation of security controls, tenant isolation measures, and access restrictions. Examine cache configurations in distributed stores, workflow state persistence, vector databases, and integration connectors. Verify encryption of sensitive enterprise data, implementation of namespace isolation between customers, and access control enforcement for cached orchestration artifacts.

   2. Tenant Isolation Assessment: Review evidence of tenant isolation measures for cached content, including namespace separation, tenant-specific encryption keys, access control enforcement at cache boundaries, and data partitioning strategies. Evaluate how enterprise workflow data is protected from unauthorized access by other tenants, how embedding vector stores maintain customer boundaries, and how model response caches enforce tenant isolation within the platform.

   3. Cache Invalidation and Consistency Controls: Verify implementation of cache invalidation mechanisms triggered by workflow updates, model version changes, integration endpoint modifications, security policy updates, and potential security incidents. Assess cache consistency strategies for distributed orchestration environments, version-tagged cache entries for workflow components, and coordination of cache refreshes across platform components to maintain consistent workflow behavior.

   4. Cache Access Controls and Monitoring: Assess controls for cache access including authentication requirements for accessing tenant-specific caches, authorization verification before serving cached content, service identity validation for inter-component cache access, and tenant context validation. Evaluate monitoring systems for cache access patterns, detection of cross-tenant access attempts, and audit logging of sensitive cache operations within the orchestration platform.

   5. Protection Against Cache-Specific Threats: Examine the implementation of protections against cache poisoning, injection of malicious content into orchestration caches, side-channel attacks through timing analysis, and cross-tenant data leakage. Assess input validation before caching integration results, output sanitization of cached content before workflow processing, protection against cache probing attacks, and defense mechanisms for shared cache infrastructure.

   6. Credential and Secret Protection in Caches: Review special protections for credential and secret handling within orchestration caches, including avoidance of credential caching where possible, secure encryption of temporarily cached authentication tokens, short expiration times for sensitive cached materials, and secure wiping of memory after credential usage. Assess how integration connector authentication is protected when responses or states are cached.

   7. Enterprise Compliance and Regulatory Considerations: Verify the adequacy of cache compliance controls for enterprise data regulations, cross-border data transfer restrictions, industry-specific compliance requirements, and customer contractual obligations. Evaluate how data residency requirements are maintained for distributed caches, how regulated data is handled in caching strategies, and how customer-specific compliance requirements are enforced in multi-tenant cache implementations.

4. Evaluation and Reporting

   1. Cache Security Effectiveness Assessment: Evaluate how well cache security implementations protect enterprise data and orchestration states while maintaining platform performance. Assess the balance between caching for orchestration efficiency and appropriate security controls based on multi-tenant risks. Evaluate the effectiveness of defenses against unauthorized access, data leakage between tenants, and cache-targeted attacks across the orchestration platform.

   2. Tenant Isolation Strategy Assessment: Assess the effectiveness of cache isolation strategies based on deployment architecture, enterprise workflow patterns, data sensitivity, and orchestration scaling requirements. Evaluate whether security controls provide appropriate isolation between tenants and whether defense-in-depth is implemented for the most sensitive cached orchestration components.

   3. Documentation and Process Adequacy: Evaluate the quality of cache-related security documentation, including clarity of caching architecture within the orchestration platform, completeness of security controls, cache data lifecycle management, and incident response procedures. Assess whether documentation is maintained as orchestration caching strategies evolve to support new integration patterns and enterprise 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 distributed caching technologies, security architecture reviews, and vulnerability management. Assess whether the organization demonstrates a commitment to continuously enhancing cache protection as orchestration service usage scales across enterprise customers 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 Orchestrated Service Providers (OSP)

Focus: The AI Orchestration Service Provider has implemented effective mechanisms enabling their integration platforms to clearly distinguish customer-provided inputs from orchestration instructions and system prompts, protecting against prompt injection and ensuring secure enterprise AI workflows.

1. Inquiry with Control Owners

   1. Interview platform architects, integration engineers, and security specialists responsible for orchestration framework development and prompt management. Obtain and review the organization’s orchestration architecture, including workflow definition security mechanisms, enterprise input handling frameworks, prompt template management systems, instruction boundary enforcement in pipelines, input validation across integration points, and multi-tenant instruction isolation approaches.Verify documented design patterns exist for clearly delineating customer data inputs from orchestration instructions through technical mechanisms such as pipeline isolation, structured parameter passing, or framework-specific separation methods across enterprise workflows.

   2. Review Orchestration Framework Implementation: Examine documentation describing the platform’s approach to managing instructions, including workflow DAG construction and validation, model provider connector security, agent execution instruction boundaries, pipeline component isolation mechanisms, instruction provenance tracking and enterprise data and instruction separation. Assess how orchestration templates are defined, validated, and executed while maintaining clear boundaries between customer data, enterprise business logic, and system instructions across multi-step workflows.

   3. Assess Integration Point Validation: Review mechanisms implementing input validation at orchestration integration points, including API gateway input filtering, pipeline parameter validation, cross-component instruction isolation, model provider credential separation, enterprise data flow verification and workflow sequence integrity checks. Evaluate how the orchestration platform prevents enterprise data or customer inputs from being interpreted as system-level instructions that could manipulate the underlying workflow behavior or model responses.

   4. Evaluate Security Gateway Design: Review how the platform’s security gateway supports instruction separation through request validation and transformation, input sanitization procedures, instruction boundary enforcement, authentication context preservation, parameter typing and validation and model provider-specific formatting.

2. Obtaining and Verifying the Population of Records

   1. Define the Complete Population of Orchestration Components: Obtain a comprehensive inventory of platform components handling instructions, including workflow orchestration engines, model provider connectors, agent runtime environments, pipeline component frameworks, security gateway implementations, prompt management systems, caching services, and integration plugins.

   2. Verify Population Completeness: Cross-reference the orchestration component inventory against platform architecture documentation, API specifications and connector catalogs, plugin directories and extension points, customer-facing service documentation, deployment configuration templates, integration capability matrices, and security boundary definitions. Ensure the inventory covers all platform components where enterprise data or user inputs are incorporated into model instructions or workflow definitions.

   3. Categorize Components by Risk Level: Segment the orchestration components based on exposure to external inputs, complexity of instruction handling, multi-tenant usage patterns, enterprise data processing scope, model provider integration complexity, authentication requirements and pipeline position (edge vs. internal). This risk-based categorization should guide assessment depth for each orchestration component.

3. Inspection of Evidence

   1. Instruction Handling Implementation Review: Select a representative sample of orchestration components based on risk levels and verify pipeline isolation implementation, examining how the platform establishes clear boundaries between customer data and orchestration instructions through techniques such as strict typing of pipeline parameters, structured workflow definition formats, object model separation for instructions vs. data serialization boundary controls, and input/instruction namespace isolation. For Workflow Instruction Protection, verify that orchestration instructions are defined in controlled template repositories, validated against schema definitions, protected from modification during execution,versioned and managed through controlled processes isolated from customer data processing. For Cross-Component Validation, confirm robust validation at component boundaries including type checking of inputs at integration points, schema validation of inter-component messages, detection of instruction-like patterns in data, contextual validation based on workflow position and authentication context preservation across steps.

   2. Architecture Boundary Assessment: Review how the platform maintains separation across architectural layers. For Workflow Definition Security, verify that workflow definitions are secured through access control on workflow templates, validation of workflow DAG structures, immutable execution paths once initiated, controlled environment for template execution, and clear separation of configuration from data. For Connector Implementation Analysis, examine model provider connectors to confirm proper formatting of provider-specific instructions, controlled injection of credentials, parameter validation before submission, response handling that preserves security context, appropriate error handling for boundary violations.

   3. Security Testing for Separation Effectiveness: Perform targeted testing of instruction separation mechanisms. For Boundary Testing, attempt to bypass instruction separation through injecting orchestration commands in data fields, manipulating pipeline parameters to affect control flow, inserting model instructions in data payloads, cross-component instruction leakage testing, and multi-step workflow manipulation attempts. For Multi-Tenant Isolation Testing, verify instruction isolation in multi-tenant scenarios: confirm tenant A cannot affect tenant B’s instructions, test namespace isolation between enterprises, verify cross-customer data and instruction boundaries, evaluate cached instruction security between tenants, test isolation during concurrent workflow execution.

   4. Documentation and Integration Assessment: Review supporting materials for enterprise integration. For Developer Documentation, verify existence and quality of workflow definition security guidelines, integration implementation requirements, input validation best practices, instruction separation patterns, and security considerations for custom components. For Enterprise Integration Guidance, assess how the platform guides enterprise customers through secure workflow template development, safe handling of sensitive enterprise data, proper integration of custom components, testing for instruction boundary violations, monitoring orchestration security.

   5. Model Provider Integration Security: Evaluate the platform’s integration with model providers for instruction separation. For Provider-Specific Formatting, verify proper implementation of model-specific formats, correct application of provider instruction formats, proper escaping of special characters, handling of provider-specific delimiters, version compatibility management, adaptation to provider format changes. For Credential and Context Isolation, review security of provider authentication, separation of authentication from data flows, protection of API keys and credentials, contextual binding of requests to tenants, session isolation between requests, and key rotation and management processes.

4. Evaluation and Reporting

   1. Separation Effectiveness Assessment: Evaluate how well the implementation maintains clear boundaries between instructions and data, prevents enterprise data from affecting orchestration logic, ensures consistent workflow behavior across varied inputs, isolates instructions between different enterprise customers, and addresses model-specific instruction handling requirements.

   2. Architectural Strategy Assessment: Assess the effectiveness of the overall approach based on defense-in-depth implementation across the platform, consistency across different integration components, scalability of security controls for enterprise workloads, alignment with industry best practices and evolution to address emerging orchestration threats.

   3. Documentation and Process Adequacy: Evaluate the quality of instruction separation documentation, including clarity of integration security requirements, completeness of component security controls, enterprise implementation guidelines, ongoing validation processes for custom integrations.

   4. Continuous Improvement Mechanisms: Evaluate processes for enhancing instruction separation through regular security testing of orchestration boundaries monitoring for unusual workflow behavior, adaptation to new instruction injection techniques, knowledge sharing across integration partners and security enhancement roadmap for orchestration components.

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

1. Ensure BCM policy addresses: Failure or disruption of orchestrated workflows, dynamic rerouting or service disabling strategies, availability of service discovery/configuration components.

2. Collect documentation on how component dependencies are mapped and monitored, along with cross-component failure response strategies.

3. Verify evidence of orchestration simulation tests and mechanisms to synchronize BCPs with upstream and downstream parties.

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

1. Verify Systemic Risk Evaluation: BIA must address multi-service chain failures, degraded fallback paths, and cascading latency/disruption risks.

2. Check for Federated Impact Mapping: Risk assessments should align with the weakest service or integration point. Review how these are modeled and mitigated.

3. Review Automation and Decision Logic: Inspect how AI-driven orchestration decisions (e.g., agent-based workflows) are risk-assessed for reliability or failure states.

4. Evidence to Inspect: Architecture impact analysis, risk transfer/ownership mapping, updated runbook dependencies.

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

1. Verify documented strategies addressing orchestration failures impacting distributed AI services.

2. Confirm cross-region or multi-cloud failover mechanisms are defined and periodically tested.

3. Ensure dependencies between orchestration platforms, application services, and AI model pipelines are explicitly captured.

4. Check the strategy includes workload migration playbooks during service disruptions.

5. Confirm collaboration agreements with APs and MPs for coordinated recovery.

6. Validate resource reservation protocols that support continuity under degraded modes of operation.

7. Ensure regular review of orchestration-level recovery time objectives (RTOs) and recovery point objectives (RPOs).

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

1. Verify a BCP exists that covers orchestration services (e.g., workflow engines, pipelines, job schedulers) supporting AI/ML lifecycle operations.

2. Confirm documentation includes recovery strategies for orchestrated workloads across multi-cloud or hybrid environments.

3. Check predefined alternate orchestration workflows are documented in case of service degradation or cloud failure.

4. Validate the plan includes fallback configurations for pipeline orchestration components (e.g., Airflow, Kubeflow).

5. Ensure notification procedures are in place to inform dependent stakeholders about orchestration recovery timelines.

6. Confirm disaster recovery objectives (RTO/RPO) for pipeline recovery are explicitly documented and reviewed.

7. Check version control of orchestration-related recovery documentation, with annual updates based on resilience assessments.

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

1. Verify that documentation exists for the orchestration platform’s continuity and operational resilience plan and recovery procedures (e.g., Airflow DAGs, ML pipelines).

2. Confirm documentation includes inter-service dependency mappings and failover configurations.

3. Check evidence of periodic review and version control of orchestration-specific continuity documentation.

4. Ensure procedures for restoring orchestration job metadata, states, and schedules are clearly documented.

5. Validate that documentation covers cloud-specific orchestration integrations (e.g., GCP Workflows, AWS Step Functions).

6. Confirm inclusion of support contact information and SLAs from third-party orchestrator vendors or plugins.

7. Ensure documentation is accessible to relevant engineering teams and updated after pipeline or infrastructure changes.

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

1. Examine the plans for business continuity and operational resilience tests regarding 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. Evaluate that the business continuity and operational resilience plans include specific tests for infrastructure, Docker, and Kubernetes environments.

5. Verify that exercise scenarios include failure modes that affect service orchestration, API availability, integration points, and end-to-end service delivery paths.

6. Review exercise results to confirm testing of automated failover mechanisms, load balancing between redundant components, and service scaling during disruption scenarios.

7. Assess whether exercises validated the integrity of service configurations and state data after executing recovery procedures.

8. Verify that exercises included coordinated testing with upstream (MP) and downstream (AP) partners to validate continuity across service boundaries and dependencies.

9. Examine evidence of exercises testing the orchestration service’s ability to handle degraded operation modes while maintaining core functionality.

10. Confirm that exercise results, including metrics on recovery objectives achievement, were reviewed by service management and that action plans were established to address identified weaknesses.

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

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

2. Determine if the organization has identified stakeholders and participants.

3. Examine the procedures for communication with identified stakeholders and participants.

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. Examine the documented communication procedures within the OSP’s business continuity plans, verifying they establish multi-directional communication pathways with upstream providers (PI, MP) and downstream consumers (AP, AIC).

6. Verify the implementation of service status notification systems that aggregate and communicate the status of integrated services across the AI supply chain.

7. Review evidence of the OSP’s capability to coordinate communications between multiple providers during complex incidents that span different services or components.

8. Assess the OSP’s procedures for translating technical disruption details from upstream providers into impact assessments and actionable information for downstream consumers.

9. Verify that documented escalation procedures exist for communication failures between different providers in the supply chain.

10. Review past incidents or exercise records to confirm that the OSP effectively coordinated communication flow and maintained consistent stakeholder messaging.

11. Confirm that the OSP maintains and regularly updates contact information for key personnel across all integrated services and dependent parties in the AI supply chain.

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

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

2. Examine the requirements for the security of such backups, including the confidentiality, integrity, and availability of the backup artifacts.

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 configuration management implementation and backup systems that maintain consistent backups of orchestration settings across distributed services and integration points.

8. Assess backup strategies for stateful services, confirming that transactional consistency is maintained across interconnected components during backup operations.

9. Review backup validation procedures that verify the integrity and compatibility of orchestration configurations and integration settings after backup completion.

10. Examine documentation and test results demonstrating successful restoration of orchestration services, including verification that service integrations function properly after recovery.

11. Verify that backup systems capture dependencies between services to ensure coordinated restoration of interconnected components in the correct sequence.

12. Assess the alignment of backup schedules with service update cycles and change management processes to ensure backups reflect current production configurations.

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

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

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

3. Determine if specific procedures are developed for virtualized environments running on Docker or Kubernetes.

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

5. Verify that the plan has received formal approval from leadership responsible for service orchestration, with evidence of review and sign-off.

6. Assess the defined service recovery sequence based on dependencies between components, confirming it enables coordinated restoration of integrated services.

7. Review documentation of orchestration configuration, backup, and recovery procedures, including service state management during recovery.

8. Verify that the plan includes coordination procedures with upstream providers (PI, MP) and downstream consumers (AP) to ensure synchronized recovery across the service chain.

9. Examine evidence that the disaster response plan has been communicated to all relevant orchestration service personnel, including training records.

10. Review records of end-to-end service recovery tests conducted within the past 12 months, confirming they validated successful restoration of integrated service functionality.

11. Verify that the plan is reviewed and updated at least annually and after significant changes to service architectures or integration patterns, 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 Orchestrated Service Providers (OSP)

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 sequence for interdependent services, confirming proper dependency management during restoration.

6. Review exercise documentation to confirm that end-to-end service functionality was validated after completing recovery procedures.

7. Assess whether exercises tested recovery from failure scenarios, including partial service disruptions, complete outages, or cascading failures across multiple services.

8. Verify that service configuration consistency was checked across recovery scenarios to ensure proper component integration after restoration.

9. Confirm that exercises included coordination with upstream providers (PI, MP) and downstream consumers (AP) to simulate realistic recovery sequences across the service chain.

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

11. Verify that additional exercises were conducted following significant changes to service architectures, integration patterns, or dependency relationships.

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

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 orchestration equipment is deployed across geographically separated locations following relevant industry standards and service level agreements.

5. Review the implementation of service registry and discovery mechanisms that enable dynamic routing to redundant service endpoints during equipment failures.

6. Assess the redundancy of integration servers and middleware components that connect various services in the AI supply chain.

7. Verify configuration management systems that ensure consistent service configurations across redundant orchestration environments.

8. Examine automated failover mechanisms for orchestration components, confirming they maintain service continuity without manual intervention.

9. Review records of cross-region service routing tests, verifying orchestration services can redirect traffic between redundant equipment without disrupting end-to-end functionality.

10. Verify monitoring systems that detect orchestration equipment failures and initiate appropriate failover procedures to redundant systems.

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

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

1. Interview Control Owners and Review Orchestration Documentation

   1. Deployment and Workflow Management: Understand orchestration workflow versioning, model integration procedures, prompt and connector update flows. Confirm change control and rollback procedures for orchestration components.

   2. Service Integration Architecture: Review documentation for: API versioning and integration points, authentication and authorization flows, data transformation pipelines and retry logic, routing and service discovery configurations.

   3. Technical Protocols for Core Services: Evaluate configurations and control strategies for: caching (e.g., invalidation, performance tuning), security gateway (access control, filtering, credential handling), agents (deployment, validation, monitoring), and monitoring (thresholds, dashboards, logs).

   4. Confirm: formal change approval workflows, risk assessment and change categorization procedures, documentation standards for service updates, SLA tracking and compliance, and use of baselines for reliability, performance, and integration.

2. Obtain Full List of Configuration and Service Changes

   1. Examine the change management system and ensure completeness by cross-referencing: audit logs, gateway traffic reports, and plugin deployment registries.

3. Inspect Records and Change Samples

   1. Sampling Strategy: Select a balanced mix of changes: deployments (e.g., IaC templates, containers), monitoring (e.g., alerts, dashboards), optimization (e.g., caching, performance tuning), security (e.g., gateways, filters), agents and plugins, and workflow template modifications.

   2. Validation of Testing and Deployment: testing and integration, end-to-end workflow tests, backward compatibility (across AI model versions), regression, error handling, schema validation, API/library compatibility and dependency validation, performance, latency/throughput benchmarks, resource profiling and load testing, cache efficiency, response times, scalability, deployment procedures, pre-deployment validation, progressive strategies (e.g., canary, blue-green), documentation of deployment and rollback steps, and customer notifications (where applicable).

   3. Confirm that approvals were obtained from service owners, security teams, operations and reliability engineering, customers or stakeholders (when applicable), and change advisory boards.

   4. Evaluate access controls and rate limits, input validation and sanitization, credential/secret management, logging and monitoring of security events, vulnerability assessments and standard alignment.

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

1. Inquiring with Control Owners: Conduct interviews with OSP change management owners and review documentation to understand how changes to technology assets, including infrastructure, orchestration components, configurations, and AI/ML artifacts, are managed. Examine defined processes for change submission and tracking, risk assessment and approval workflows, pre-deployment testing and staging, implementation planning and rollback readiness, and post-implementation verification. Review the organization’s usage of the following systems for managing technology changes, IT change management platforms (e.g., ServiceNow, Jira Service Management), configuration management databases (CMDBs), version control systems (e.g., GitHub, GitLab), CI/CD pipelines and DevOps automation, cloud infrastructure-as-code (IaC) platforms, and API management and testing frameworks.

2. Verifying Implementation Through Records and Tools: Select a representative sample of changes from enterprise change records (e.g., ServiceNow), version control commits and merge histories, CI/CD pipeline executions, ML model registries, or orchestration configuration updates. Verify that changes followed the documented approval and testing workflows, automated tools (e.g., CMDBs, IaC tools, CI/CD, API gateways) enforced governance controls, post-deployment checks and rollback mechanisms were applied, and both internally managed and outsourced components followed the same governance structure.

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

1. Inquiring with Control Owners

   1. Interview Platform Engineering Managers and review relevant documentation to understand the requirements. For Access Control Frameworks, review access control frameworks for modifying orchestration components including AI workflow definition and template libraries, model provider connector configurations, security gateway rules and policies, caching service configurations, agent deployment and runtime environments, and monitoring and observability settings. For Separation of Duties, review separation of duties between workflow design vs. connector development, security gateway administration vs. integration development, agent configuration vs. orchestration pipeline design, and infrastructure scaling vs. workflow optimization. For Role-Based Access Management, review role-based access for API gateway credential management, workflow template modifications, connector version updates, caching strategy adjustments, security policy configuration, and monitoring threshold management.

   2. Interview Integration Services Management: Meet with integration service managers and review relevant documentation to understand the requirements. For Approval Workflows, review approval workflows for new model provider integrations, security gateway rule updates, agent framework modifications, workflow template library changes, caching strategy optimizations, and monitoring dashboard and alert configurations. For Governance Processes, review governance processes including security impact assessments, performance and cost validation, customer compatibility testing, regulatory compliance reviews, and change notification requirements.

   3. Review Change Management Documentation: Examine documentation describing the following. For Orchestration Change Management Policies: component-specific change categories and approval requirements, emergency change procedures for critical services, connector version update policies, workflow template version control requirements, and testing standards for orchestration changes. For Deployment Pipeline Controls: approval gates for orchestration component releases, validation checks for integration connectors, compatibility testing requirements, progressive deployment for service changes, and monitoring requirements for new capabilities. For Service Configuration Management: progressive rollout policies for new features, emergency disablement procedures, A/B testing frameworks for optimizations, customer tenant targeting for feature rollouts, and configuration access controls and audit procedures.

   4. Assess Orchestration-Specific Access Control Documentation: Review formal documentation of authorization requirements for: model provider connector configurations, API gateway security rule modifications, caching service parameter adjustments, monitoring threshold configurations, agent deployment specifications, workflow template libraries, and plugin and integration component management.

2. Obtaining and Verifying the Population of Records

   1. Obtain a complete inventory of orchestration services, including AI workflow orchestration platforms, model integration connectors, security gateway services, caching and optimization tools, monitoring and observability solutions, deployment automation services, agent frameworks and environments, and integration plugins and extensions. Validate completeness by reconciling service inventory with configuration management systems, audit logs, access control databases, and so on.

3. Inspecting Records and Documents: Select a representative sample of orchestration services and obtain the complete list of users with privileges to modify workflows, deployment pipelines, change API configurations, or update service connections, and so on. Verify that access to orchestration services and tools is properly restricted by examining role-based access controls and user access rights, deployment pipeline run logs, service mesh configuration change logs, and so on.

   1. Select Representative Sample: Choose a balanced sample of orchestration services based on: different service types (e.g., workflows, connectors, gateways, agents), various integration capabilities, range of customer types and industries served, different maturity levels and change frequencies, mix of security and utility services, varying risk categorizations, and different deployment models (e.g., multi-tenant, dedicated).

   2. Obtain Access Control Information: For each sampled orchestration service, collect the complete list of personnel and systems with change capabilities: Development Personnel (workflow designers, connector engineers, security gateway administrators, caching service engineers, monitoring service developers, agent framework engineers, DevOps engineers for AI infrastructure), Administrative Personnel (service managers, release coordinators, security officers, quality assurance specialists, customer support with configuration access), and Automated Systems (CI/CD pipelines for service components, configuration management systems, performance optimization frameworks, gateway rule update mechanisms, monitoring configuration syncing systems).

   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 Orchestration-Specific Access Controls: For each sampled orchestration service, confirm that access to change components is properly restricted. For Repository and Code Controls: Branch protection for orchestration component repositories with code review requirements for connector code; Access limitations for security gateway configurations and commit signing requirements for sensitive components; Repository access audit logs for unauthorized attempts. For CI/CD Pipeline and Deployment Controls: Approval requirements for service deployments with separation of duties in deployment workflows; Environment promotion controls and pipeline access restrictions with authentication; Deployment approval audit trails for compliance. For Configuration Management Controls: Access restrictions for service configuration changes with approval workflows for configuration updates; Audit logging for configuration modifications and emergency rollback capabilities with access controls; Configuration change history for proper approval tracking. For Model Provider Connectors: API key and credential management with connector version control; Authentication mechanism changes and request/response transformation configuration. For Security Gateways: Rule modification permissions and rate limiting configuration access; Content filtering policy management and authentication requirement changes. For Caching Services: Cache invalidation control access and storage allocation configuration; Performance parameter modifications and cache strategy optimization changes. For Agent Frameworks: Agent deployment permissions and runtime environment configuration; Tool and capability management with agent behavior definition changes. For Workflow Orchestration: Workflow template library access and component connection permissions; Error handling configuration and state management modifications. For Approval Workflow Validation: Required approvals obtained for orchestration changes with security reviews for gateway and connector changes; Performance testing approvals for service optimizations 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 Orchestrated Service Providers (OSP)

1. Inquiring with Control Owners

   1. Conduct interviews with personnel responsible for managing orchestration platform changes and customer workflow modifications to understand authorization processes for altering AI pipeline configurations in customer environments. Verify their understanding of controls that prevent unauthorized changes to workflow orchestration, API gateways, or integration services that directly impact customer AI operations and data processing.

2. Inspecting Records and Documents

   1. Review Orchestration Platform Deployment Change Policies: Evaluate policies governing updates to AI workflow configurations, API gateway modifications, pipeline orchestration changes, and integration service adjustments that affect customer environments.

   2. Inspect Customer Platform Service Agreements: Look for restrictions on automatic platform updates, changes to workflow behavior, API gateway modifications, or alterations to orchestration logic and data processing flows.

   3. Assess Workflow Rollback or Configuration Control Mechanisms: Customers should be able to maintain specific orchestration configurations or reject workflow-impacting updates. Review configuration versioning, workflow templates, or customer-controlled orchestration settings.

   4. Verify Orchestration Change Authorization Processes: Examine documented procedures requiring explicit customer authorization before implementing changes to workflow orchestration, API configurations, or integration services that directly impact customer AI operations.

   5. Review Customer Platform Change Documentation: Validate that customers receive adequate notification and authorization requests before orchestration changes that affect their AI pipeline performance or data processing workflows.

   6. Examine SLA Compliance for Platform Service Modifications: Confirm that orchestration platform changes remain within agreed service level parameters and customer-authorized operational scope.

   7. Evaluate Change Control Framework Across Services: Changes to orchestrated flows can affect integrated tenant environments. Review governance policies for multi-actor updates and rollback dependencies.

   8. Review SLAs or Data Sharing Agreements: Customers may rely on orchestrated services that inherit risk from multiple upstream actors. Check contract terms limiting cascading changes without explicit tenant authorization.

   9. Validate Notification and Approval Workflow for Pipeline Updates: Customers should be able to authorize changes that affect outcome fidelity or compliance. Review evidence of change notification logs and opt-in flags.

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

1. Verify that sufficient documentation exists defining what constitutes a baseline for orchestration components, and confirm documented configuration baselines exist for orchestration platform configuration and integration controls (as applicable), e.g., workflow/DAG templates, model connectors/adapters and API/version mappings, routing/traffic management and caching configurations, security gateway rules/access policies, monitoring/alert thresholds, and deployment/IaC/container configurations, and define what is “in baseline” vs “out of scope.”

2. Confirm a change process exists and is followed for all relevant authorized baseline changes (request - approval - version control - testing/validation - deployment), including segregation/authorization controls for who can modify baseline items (especially routing, connectors, and gateway policies).

3. Select a sample of recent and/or higher-risk baseline changes and verify end-to-end traceability: approved change record, linked artifact/version in repository/config system, evidence of compatibility validation (e.g., connector/API version mapping) and security/performance validation as applicable, and deployment/config update consistent with the approved change.

4. Confirm baselines are reviewed/updated at least annually and upon significant changes (e.g., new orchestration capability/feature, connector/API version change, routing/security policy change, new integration with an external model provider, major platform/deployment change), with evidence of review and updates where applicable.

CCC-07: Detection of Baseline Deviation

Control Specification

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

Auditing Guidelines for Orchestrated Service Providers (OSP)

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

1. Inquiry with Control Owners

   1. Interview orchestration leadership and reliability teams to understand how exception management is implemented across AI orchestration services. Review documented policies and procedures covering: emergency connector/integration changes, workflow orchestration engine updates, security gateway rule changes, emergency cache configuration or patching, monitoring alert threshold adjustments, agent or pipeline failures, API integration disruptions, and multi-tenant isolation failures.

   2. Examine exception process documentation, including: criteria for what qualifies as an emergency or exception, exception request workflows and templates, approval levels based on risk and customer impact, temporary approval timeframes and conditions, documentation and justification requirements, post-implementation validation and closure, and exception tracking and reporting tools.

   3. Assess emergency response readiness, focusing on: response protocols for high-impact service components (e.g., model APIs, orchestration engines), response team structures and escalation paths, emergency on-call rotations, governance alignment with GRC-04, and risk management integration.

2. Define and Verify Population of Exception Records

   1. Obtain a complete inventory of orchestration service exceptions, including: emergency updates (e.g., connectors, security rules, engine patches), temporary feature disablements, retroactive approvals for emergency actions.

   2. Cross-reference inventory with: monitoring alert logs, emergency change tickets, support escalations and status page disruptions, post-incident reviews and risk registers. Objective: Ensure completeness, traceability, and alignment with change management records.

3. Exception Sample Selection and Testing

   1. Select a representative sample of exceptions across: component types (connectors, gateways, orchestration engines), impact levels (high, medium, low), time periods and approvers.

   2. For each sample, verify each of the following. Justification: clearly documented urgency or risk, risk assessments and customer impact, and evaluation of alternatives and alignment with exception criteria. Approval: authorized approvers involved, retroactive approval where applicable, and documented decisions with scope/temporal limitations. Implementation: implemented exactly as approved, additional monitoring and stakeholder communication applied, and scoped appropriately with temporary conditions respected. Closure and Follow-up: returned to standard process once no longer needed, post-exception validation completed, and lessons learned captured and documented.

4. Exception Tracking and Governance Oversight

   1. Assess tracking and reporting mechanisms, including: centralized repository with status and expiration tracking, exception trend analysis and recurring issue identification, reporting to governance bodies and risk teams, and integration with broader service reliability metrics.

   2. Evaluate exception governance structures: defined escalation paths and executive visibility, oversight committees and alignment with GRC-04, root-cause tracking, and systemic control improvements.

5. Continuous Improvement Mechanisms

   1. Review ongoing improvement efforts, such as: refining exception criteria based on operational experience, improving emergency response capabilities, enhancing architectural resilience to reduce emergency changes, and updating workflows based on lessons from past incidents.

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

1. Inquiry with Control Owners

   1. Interview Orchestration Teams and Review Rollback Policies: Interview orchestration platform engineers, integration specialists, and service reliability teams responsible for change management and rollback processes, and obtain organizational rollback policies and procedures including criteria for initiating orchestration service rollbacks, rollback decision authority matrix for different service components, emergency rollback procedures for critical orchestration failures, planned rollback testing requirements for orchestration changes, post-rollback validation protocols across integration points, and rollback process documentation requirements for enterprise customers, while verifying documented criteria for orchestration workflow failures requiring rollback, security gateway concerns warranting immediate rollback, integration point failures necessitating rollback, enterprise customer impact thresholds triggering rollback, and service performance degradation requiring intervention.

   2. Review Process Documentation and State Management: For Rollback Process Documentation, examine documentation describing rollback planning requirements for all orchestration service changes, technical rollback mechanisms for different orchestration components including model connector/integration rollback, workflow engine configuration rollback, security gateway rule rollback, caching service configuration restoration, monitoring system configuration rollback, and agent framework version rollback, along with multi-tenant impact assessment during rollback operations, enterprise customer communication protocols for rollback scenarios, service-level agreement considerations during rollbacks, and verification requirements across integration points after rollback. For Known Good State Management, review procedures for establishing and validating known good states including definition of “known good state” for orchestration components, baseline integration performance documentation requirements, service configuration version tagging and snapshot procedures, state validation across multiple integration points, state capture mechanisms for distributed orchestration components, version compatibility matrix maintenance for integration points, and environmental parity checks between staging and production.

   3. Evaluate Deployment Architecture: Assess how the deployment architecture supports rollback capabilities through service mesh implementation for traffic control, multi-version support for orchestration components, infrastructure-as-code versioning for orchestration environments, API gateway versioning and routing capabilities, configuration version control across distributed components, container orchestration rollback mechanisms, integration point version pinning capabilities, and distributed transaction consistency during rollbacks.

2. Inspection of Evidence

   1. Rollback Strategy Documentation Review: Verify comprehensive rollback strategy documentation, including: Component-Specific Rollback Approaches (model connector rollback mechanisms, workflow orchestration engine version rollback, security gateway configuration rollback, caching service state restoration, monitoring configuration rollback, agent deployment rollback, plugin and integration component rollback); Rollback Decision Process (defined error thresholds triggering automatic rollback, security breach containment considerations, enterprise customer impact assessment methodology, decision authority and approval workflow for different service tiers, multi-tenant impact consideration in decision-making); Rollback Execution Process (step-by-step rollback procedures for each orchestration component, required validations at integration points during rollback, dependency management across orchestration services, order of operations for complex multi-component rollbacks, customer workflow maintenance during rollback, parallel systems consistency management); Post-Rollback Activities (validation of end-to-end orchestration flows after rollback, enterprise customer notification procedures, integration point verification procedures, root cause analysis requirements, documentation and knowledge capture).

   2. Tools and Technical Implementation Assessment: Evaluate tools and technical implementations supporting rollback, including: distributed version control system usage, service registry and discovery mechanisms, container orchestration rollback capabilities, configuration management system versioning, API gateway versioning and routing, service mesh traffic control capabilities, workflow DAG version management, integration connector version control, and distributed monitoring during rollback operations.

   3. Sample-Based Testing of Rollback Capabilities: Select a representative sample of orchestration service components and verify: Rollback Planning (documentation of rollback plans for recent orchestration changes, identification of known good state reference points for integrations, dependency mapping across orchestration components, time and resource estimates for complex rollback scenarios, customer impact minimization strategies); Rollback Testing (evidence of regular rollback capability testing across components, integration point validation during test rollbacks, simulation exercises for multi-component rollbacks, enterprise customer workflow continuity testing during rollbacks, measurement of orchestration service recovery times); Known Good State Verification (validation procedures for integrated orchestration components, performance benchmarking of baseline integration states, security assessment of gateway and connector configurations, documentation of acceptable service performance parameters, archiving of known good state configuration artifacts).

   4. Previous Rollback Execution Review. For a sample of previously executed rollbacks, verify: Rollback Trigger Assessment (clear documentation of orchestration issues triggering rollback, alignment with defined service disruption criteria, enterprise customer impact assessment documentation, decision authority involvement per service tier policy); Rollback Execution Documentation (component-specific rollback execution records, integration point verification during rollback, issues encountered during multi-component rollback, timing of orchestration service restoration, communication to affected enterprise customers); Post-Rollback Activities (end-to-end orchestration flow verification, integration performance assessment, enterprise customer workflow validation, root cause identification for original orchestration issue, preventative measures implementation).

   5. Automated Monitoring and Rollback Integration: Assess the integration between monitoring systems and rollback processes: distributed system monitoring for orchestration components, integration point health checking, alert correlation across orchestration services, automated rollback triggers for critical integration failures, progressive rollback automation for multi-component services, and monitoring of cross-component consistency during rollback.

   6. Enterprise Customer Communication Procedures: Evaluate procedures for enterprise customer communication during rollbacks: proactive notification protocols based on service tier, status update frequency during rollback operations, expected impact and timeline communications, customer-specific workflow impact assessment, post-rollback validation confirmation, and root cause explanation and remediation planning.

3. Evaluation and Reporting

   1. Rollback Capability Effectiveness Assessment: Evaluate how well rollback processes: meet defined recovery time objectives for different service tiers, successfully restore orchestration service functionality, maintain integration point consistency, minimize enterprise customer workflow disruption, address all orchestration components comprehensively, balance automated and manual decision-making, and scale across multi-tenant environments.

   2. Known Good State Management Assessment: Assess the effectiveness of known good state management: consistency of state definition across integration components, validation thoroughness at integration boundaries, accessibility of configuration snapshots during incidents, frequency of integration testing for known good states, and compatibility matrix maintenance for connected services.

   3. Rollback Process Documentation Quality: Evaluate the quality of rollback process documentation: clarity of multi-component rollback procedures, integration-point-specific technical details, enterprise customer impact considerations, accessibility to on-call response teams, alignment with actual orchestration architecture, and regular updates following orchestration service changes.

   4. Continuous Improvement Mechanisms: Evaluate processes for improving rollback capabilities: regular review of orchestration service recovery metrics, incorporation of lessons learned from multi-component incidents, technical capability enhancement for faster integration recovery, process refinement based on enterprise customer feedback, architecture improvements to reduce rollback complexity, and evolution of known good state validation methods.

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

1. Policy Examination: Verify that the OSP’s Cryptography, Encryption, and Key Management (CEK) policy exists and addresses the planning, delivery, and support of cryptographic functions across orchestrated service components. Confirm that the policy includes encryption of data exchanged between orchestrated AI services and downstream systems, key generation, rotation, and destruction processes, enforcement of algorithm standards and secure key storage, and the use of role-based access controls across orchestration workflows.

2. Governance: Confirm that the CEK policy is formally approved by senior management and that such approval is documented through mechanisms like a policy register, executive communication, or governance committee minutes. Verify that a designated owner is assigned to maintain the policy and that it is reviewed and updated at least annually or after significant changes. These may include the integration of new AI services or orchestration platforms, migration to cloud-native service mesh architectures, or updates to legal, regulatory, or service-level agreement (SLA) requirements.

3. Communication: Review records showing that the CEK policy has been distributed to relevant stakeholders such as service engineers, DevOps personnel, platform security staff, and integration leads. Confirm communication through attestation logs, internal communications, or training acknowledgments.

4. Implementation Validation: Validate that the CEK policy is implemented in practice by examining encryption configurations in orchestration platforms, logs from key management systems tied to service pipelines, protections for inter-service data flows, and monitoring of encrypted communications between AI service components.

5. Role Assignment: Review documentation to confirm that specific CEK responsibilities are assigned for lifecycle operations across orchestration layers, such as key generation and rotation, access approval, exception management, and encryption enforcement. Confirm that these responsibilities are clearly mapped to named teams or service ownership functions within the OSP.

6. Training and Awareness: Inspect internal training records, onboarding documentation, or security awareness communications to confirm that personnel responsible for CEK operations across orchestrated services have been properly trained on the policy and its application.

7. Compliance Monitoring: Evaluate whether the OSP actively monitors compliance with its CEK policy through mechanisms such as automated detection of unencrypted data exchanges, periodic audits of orchestration-layer encryption controls, and reconciliation of service logs with key usage data.

8. Upstream and Downstream Dependencies: Review how the OSP accounts for upstream cryptographic dependencies on Model Providers (MPs) and downstream obligations toward Application Providers (APs) or AI Customers (AICs). Confirm that the CEK policy includes contractual assurances or validation mechanisms to support encryption standards across these relationships, or else documents residual risks and outlines mitigation steps within the orchestration layer.

CEK-02: CEK Roles and Responsibilities

Control Specification

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

Auditing Guidelines for Orchestrated Service Providers (OSP)

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

2. Confirm that AI-specific responsibilities are defined in alignment with the OSP’s role (e.g., securing orchestration pipelines involving LLMs, protecting model interaction points, managing encrypted service-to-service flows) and that role assignments are documented and maintained.

3. Review documentation to confirm that responsibilities are mapped to specific roles or teams (e.g., platform security, orchestration engineers, integration leads).

4. Validate that AI-related tasks are assigned to appropriate roles supporting service chaining, AI orchestration, and encrypted data routing.

5. Verify that segregation of duties is enforced between key administration and orchestration system control or AI flow management.

6. Confirm that training is provided to personnel responsible for operations, including encryption of orchestrated services and AI pipeline protections.

7. Verify that role assignments are reviewed at least annually or when changes occur in the orchestration stack, team structure, or regulatory landscape.

8. Confirm that governance bodies oversee role definitions and periodically assess role alignment with service and AI orchestration risks.

9. Validate that continuity plans are in place and that alternate personnel are designated and trained for responsibilities across the orchestration platform.

10. Verify that responsibilities include coordination with upstream providers (e.g., MPs) and downstream consumers (e.g., APs, AICs) to ensure encryption practices are aligned across orchestrated AI services.

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

1. Verify that OSP encryption is implemented for sensitive data at rest across orchestration storage systems (e.g., logs, config data, shared volumes) using approved algorithms.

2. Verify that encryption is enforced for data in transit across all internal and external orchestration communications using secure protocols (e.g., TLS 1.2+, mTLS).

3. Confirm that the types of data requiring encryption in orchestration workflows are clearly defined and documented.

4. Review the data classification scheme and confirm that encryption controls are mapped to high-sensitivity orchestration data.

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

6. Verify that encryption keys are managed through centralized key management systems with enforced key lifecycle, access controls, and logging.

7. Confirm that encryption configurations are hardened (e.g., no weak ciphers, no deprecated protocols) and are validated across orchestrated service pipelines.

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

9. Confirm that encryption-related monitoring is in place, including detection of unencrypted flows, failed encryption attempts, and orchestration-layer anomalies.

10. Verify that AI-related data flows within orchestration (e.g., model chaining, LLM calls) are encrypted both at rest and in transit.

11. Validate that encryption keys used in AI pipelines (e.g., token exchanges, inference payload protection) are governed by the same key management and auditing practices.

12. Review upstream and downstream encryption coordination with Model Providers, Application Providers, and AI Customers to ensure consistent enforcement across the orchestration environment.

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

1. Verify that the OSP maintains documented standards for approved encryption algorithms based on data classification and integration risk across orchestrated services and data flows.

2. Confirm that algorithms used for service-to-service encryption, orchestration pipelines, API relays, and data logging meet industry-recognized standards (e.g., AES-GCM, RSA, ECC, TLS 1.2+).

3. Review whether algorithm strength and relevance are assessed periodically and updated in response to known vulnerabilities, deprecation notices, or compliance changes.

4. Validate that performance, interoperability, and usability are considered when selecting encryption algorithms for dynamic orchestration layers (e.g., traffic routing, mesh encryption, LLM token exchange).

5. Confirm that algorithms are implemented consistently across services, including encryption of data in motion, at rest, and in shared memory buffers (where applicable).

6. Verify that key management services and orchestration policies enforce appropriate algorithm usage and ensure isolation of cryptographic operations across tenants or service domains.

7. Review whether encryption algorithm selection and changes are reviewed and approved by a designated governance or architecture function (e.g., security engineering council).

8. Confirm that the OSP verifies cryptographic standards in embedded or dependent orchestration components, such as third-party load balancers, service discovery mechanisms, or event buses.

9. Validate that test results, penetration tests, and vulnerability scans involving encryption algorithms are tracked and used to improve algorithm selection and retirement planning.

10. Verify that the OSP accounts for upstream algorithm requirements (e.g., MP APIs) and downstream expectations (e.g., AP or AIC encryption compatibility), ensuring consistency across the orchestration ecosystem.

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

1. Verify that the OSP maintains a documented change management procedure specific to CEK systems within its orchestration environment (e.g., inter-service encryption, token handling, KMS integrations).

2. Confirm that the procedure supports changes driven by internal factors (e.g., service redesign, scaling initiatives) and external drivers (e.g., vendor deprecations, regulatory shifts).

3. Review whether all CEK-related change requests are tracked through a centralized change management system and routed through security or platform governance processes.

4. Verify that roles responsible for reviewing, approving, and implementing CEK changes are defined and include key stakeholders such as security architects, platform leads, DevOps, and compliance.

5. Confirm that each CEK change includes an implementation plan with testing protocols, timeline, and defined rollback procedures across orchestrated service layers.

6. Review how CEK change details are communicated to affected internal service teams and external consumers (e.g., APs, AICs) that rely on consistent encryption guarantees or SLAs.

7. Validate that version tracking is maintained for encryption-related configurations and orchestration templates and that updates are traceable to specific change events.

8. Verify that post-implementation validation includes monitoring of service encryption behavior, performance metrics, and functional testing to detect regression.

9. Confirm that CEK change records include complete documentation of risk evaluation, testing results, approval evidence, and implementation notes, and confirm that they are archived for compliance purposes.

10. Review whether CEK change management includes assessment of upstream provider dependencies (e.g., MP cryptographic endpoints) and downstream consumers (e.g., APs and AICs), including compatibility and coordination efforts.

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

1. Verify that the OSP maintains a documented process for managing changes to CEK-related systems across orchestration platforms, service mesh encryption, and inter-service key management.

2. Confirm that changes to orchestration-layer encryption (e.g., TLS configs, KMS integration, token signing mechanisms) are reviewed and approved through a structured governance or architecture review process.

3. Review whether proposed CEK changes are supported by a documented cost-benefit analysis that considers security improvements, scalability, resource utilization, and service availability.

4. Validate that all changes include an assessment of residual risk, including any known limitations or temporary compensating controls required during phased rollouts.

5. Confirm that the downstream impact of CEK changes is assessed for each affected orchestration component and its consumers (e.g., APs, AICs), including changes in key scope, data flow behavior, or SLA performance.

6. Verify that stakeholders across orchestration, security engineering, DevOps, legal, and support are included in change planning and approval processes.

7. Review whether version tracking, rollback mechanisms, and change documentation are maintained for all CEK-related orchestration system updates.

8. Validate that CEK changes are monitored post-implementation to verify that intended benefits (e.g., improved data isolation, reduced latency, enhanced compliance) are achieved without adverse impact.

9. Confirm that past CEK change outcomes are reviewed and incorporated into future planning, especially where changes resulted in interoperability issues or unexpected costs.

10. Verify that changes affecting upstream services (e.g., MP-provided cryptographic endpoints) and downstream consumers (e.g., APs, AICs integrated into the orchestration environment) are documented, communicated, and validated for compatibility.

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

1. Verify that the OSP has a documented CEK risk management program aligned with enterprise risk frameworks and tailored to orchestrated services, data flows, and platform architecture.

2. Confirm that CEK risks are contextualized based on orchestration layers (e.g., API gateways, service mesh encryption, inter-service key exchanges) and the nature of data traversing those components.

3. Review the methodology for assessing CEK risks within orchestrated environments, including how integration complexity, exposure surfaces, and data criticality are factored into risk scoring.

4. Verify that a CEK risk register or tracking system is maintained, with entries tied to specific orchestration services, encryption mechanisms, and key lifecycle responsibilities.

5. Confirm that the OSP documents treatment plans for identified CEK risks, such as re-architecting flows to reduce key reuse, upgrading crypto libraries, or segmenting trust zones.

6. Validate that residual CEK risks in orchestration workflows are reviewed by security governance bodies, with reassessments triggered by architectural changes or incident findings.

7. Review whether CEK risks are continuously monitored through automated checks (e.g., TLS validation, key rotation monitoring, service dependency drift) and manual assessments.

8. Confirm that audit findings, integration failures, or customer-reported vulnerabilities are fed back into the CEK risk program and used to drive improvements to orchestration controls.

9. Verify that CEK risks specific to AI orchestration (e.g., model chaining, prompt relay across services, LLM proxy endpoints) are included in the risk register and evaluated for exposure and mitigation.

10. Validate that the CEK risk program incorporates upstream cryptographic dependencies (e.g., model provider key practices) and downstream obligations (e.g., AP/AIC data handling), ensuring CEK continuity and integrity across service boundaries.

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

1. Verify that the OSP provides mechanisms and configuration options that allow AICs to manage their own encryption keys across orchestrated AI services and integration layers.

2. Confirm that AIC-supplied or scoped keys are used exclusively to secure data flows, storage, or logging associated with that specific AIC. Ensure that key scopes do not cross customer boundaries.

3. Validate that all cryptographic operations (e.g., encryption of service-to-service communication, key wrapping, signing) involving AIC-managed keys are logged and can be monitored or audited.

4. Review whether SLAs, integration documentation, or customer agreements describe the AIC’s rights and capabilities to control keys, rotate them, and review key-related events.

5. Verify that responsibilities for enabling, enforcing, and maintaining AIC key control are clearly assigned to orchestration platform engineering, DevSecOps, or cryptographic services teams.

6. Confirm that exception handling procedures are defined for orchestration components that do not support AIC-managed keys, including customer notification, mitigation plans, or compensating controls.

7. Validate that the OSP supports secure, pre-production validation and testing for AIC key configurations prior to activating orchestrated AI data flows.

8. Verify that support for AIC key control is subject to periodic review by security governance, with documented updates reflecting cryptographic improvements, customer needs, and orchestration platform changes.

9. Confirm that the OSP enforces downstream AIC key control requirements, including scoped key use, multi-tenant isolation, and delegated cryptographic workflows tied to each customer.

10. Validate that the OSP periodically reviews and updates its upstream dependencies (e.g., service mesh crypto, cloud KMS, third-party integrations) to ensure they continue to support and enforce AIC-specific key management expectations.

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

1. Verify that the OSP 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 orchestration pipelines, cryptographic configurations, or service integrations involving encryption.

3. Review the audit scope to ensure it covers CEK components across the orchestration stack, including API gateways, service mesh encryption, and shared KMS integrations.

4. Validate that audits assess compliance with CEK standards and internal controls, including key lifecycle enforcement, inter-service encryption, and access restrictions.

5. Verify that CEK audits are conducted independently of orchestration operations or development teams managing AI or service interconnects.

6. Confirm that audit results are formally documented, reviewed by leadership, and tracked through remediation workflows when issues are identified.

7. Review whether audit findings related to CEK weaknesses are communicated to platform engineering, DevSecOps, compliance, and external integration partners.

8. Verify that continuous monitoring tools (e.g., orchestration-layer audit agents, key usage logs) support real-time or near-real-time visibility of CEK compliance.

9. Confirm that AI-related encryption and key management activities (e.g., securing model chaining or LLM data routing) are included in the audit scope.

10. Validate that CEK audit procedures are periodically reviewed and updated to reflect cryptographic standards, orchestration-layer risks, regulatory requirements, and dependencies with upstream providers (e.g., MPs) and downstream consumers (e.g., APs, AICs).

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

1. Verify that the OSP uses approved, standards-based cryptographic libraries (e.g., FIPS 140-2/3 certified) to generate encryption keys for orchestrated services, including service-to-service encryption, AI routing, and multi-tenant orchestration pipelines.

2. Confirm that the algorithm type and strength are explicitly defined for each key type used in service-to-service encryption or orchestration-layer security.

3. Validate that cryptographically secure RNGs are used for key generation, compliant with industry standards (e.g., NIST SP 800-90A).

4. Verify that key generation is integrated into secure service automation tools (e.g., IaC pipelines, container orchestration security layers).

5. Review access controls ensuring that only authorized personnel or automated systems can trigger key generation processes.

6. Confirm that keys supporting orchestrated AI flows (e.g., routing between LLMs, model chaining, encrypted API calls) follow the same generation standards.

7. Verify that no keys are hardcoded or stored in orchestration manifests, configuration scripts, or AI service descriptors.

8. Review logging of key generation events across orchestration systems, and confirm that logs are auditable and retained per policy.

9. Confirm that non-production environments use separate keys and secure RNGs distinct from production orchestration infrastructure.

10. Validate that key generation procedures are reviewed periodically to account for changes in orchestration tools, cryptographic libraries, or threat models.

CEK-11: Key Purpose

Control Specification

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

Auditing Guidelines for Orchestrated Service Providers (OSP)

1. Verify that the OSP assigns cryptographic keys and secrets (e.g., service mesh credentials, API tokens, orchestration keys) to a unique purpose and that purpose separation is enforced across orchestration layers, service registries, and infrastructure components.

2. Confirm that documentation exists mapping each key to its intended function across orchestrated services and that this mapping is reviewed periodically for accuracy.

3. Verify that technical and procedural controls prevent a single key from being reused for multiple cryptographic purposes across orchestration environments.

4. Review orchestration configurations to ensure keys are scoped to their designated workflows and not reused for unrelated services or components.

5. Confirm that access controls and orchestration-layer permissions limit key use to roles or services with defined operational needs.

6. Validate that keys supporting AI-specific orchestration (e.g., chaining LLMs, secure data handoff) are uniquely provisioned per use case and not shared across different integration points.

7. Review whether key metadata includes labels, tags, or annotations indicating key purpose and that this metadata is enforced in orchestration tooling or service registries.

8. Confirm that orchestration deployment processes (e.g., service meshes, containers, IaC) include checks to enforce key purpose constraints.

9. Verify that key usage is logged and monitored across orchestrated services and that violations of key purpose policies trigger alerts or reviews.

10. Confirm that any keys used to interact with upstream providers (e.g., model APIs) or downstream consumers (e.g., AICs) are scoped and managed according to their intended use only.

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

1. Verify that the OSP rotates cryptographic keys in accordance with defined cryptoperiods, considering the risk of information disclosure and legal or regulatory requirements affecting orchestrated services and AI integration flows.

2. Confirm that documented key rotation procedures exist and are reviewed regularly to incorporate updates to orchestration tooling, threat intelligence, and legal obligations.

3. Verify that orchestration-layer key rotation is implemented using automated tools or secure workflow pipelines and follows approved change control processes.

4. Review orchestration platform configurations to ensure key rotation schedules are enforced consistently across services and that overrides are logged and approved.

5. Confirm that access to initiate or modify key rotation schedules is restricted to authorized orchestration or security roles only.

6. Validate that keys used to protect AI orchestration flows (e.g., LLM chaining, inter-service APIs) are rotated on defined intervals and monitored for anomalies that might require early rotation.

7. Review logs or system events related to key rotation to verify completeness, accuracy, and alignment with cryptoperiod policies.

8. Confirm that rotated keys are distributed securely and promptly to all dependent services and microservices within the orchestrated environment.

9. Verify that retired or replaced keys are securely deleted or archived in accordance with regulatory or contractual requirements.

10. Confirm that any coordination with upstream (e.g., MP) or downstream (e.g., AIC) parties includes mechanisms to handle key updates without compromising service continuity or data protection.

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

1. Verify that the OSP defines, implements, and evaluates processes, procedures, and technical measures to revoke cryptographic keys prior to the end of their cryptoperiod, including when a key is compromised, a service is decommissioned, or an orchestration component is no longer authorized, and ensure that revocation criteria are documented and enforced across all relevant orchestration layers.

2. Confirm that documented key revocation workflows exist and are reviewed periodically to account for updates in orchestration platforms, legal and regulatory requirements, or evolving risk scenarios.

3. Verify that revocation of keys used in orchestration layers is enforced through automated or semi-automated mechanisms (e.g., IaC, secrets management, orchestration tooling) and follows change control processes.

4. Review orchestration system behavior to confirm that revoked keys are fully removed from active memory, configuration files, service descriptors, and caches.

5. Confirm that only designated orchestration or platform security roles can initiate key revocation actions and that all revocation attempts are logged and auditable.

6. Validate that keys supporting AI service orchestration (e.g., LLM handoff, secure chaining, tokenized pipelines) are revoked in coordination with the service graph and associated components.

7. Review logs of key revocation activities to verify completeness, timestamp accuracy, identity of the initiator, and downstream effects.

8. Confirm that orchestrated services that rely on revoked keys are updated or restarted using replacement keys and that service continuity and security are preserved.

9. Verify that revoked keys are securely deleted or archived per the organization’s key lifecycle policies, considering applicable retention, contractual, or regulatory requirements.

10. Confirm that key revocation events that affect upstream model providers or downstream consumers are communicated clearly and handled through interface-level key updates or coordination protocols.

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

1. Verify that the OSP 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 embedded in orchestration services, transient environments, or AI service connectors.

2. Verify that the OSP has a documented data/key deletion policy ensuring that cryptographic keys and associated data are securely deleted from all orchestration systems, backups, and transient environments when no longer needed, in line with legal, regulatory, and contractual obligations.

3. Confirm that key revocation and destruction criteria include service decommissioning, cryptoperiod expiration, compromised orchestration components, or regulatory data handling requirements.

4. Verify that technical measures are in place to perform cryptographic erasure or data sanitization for software-stored keys, and that destruction is logged and verifiable.

5. Review orchestration system and container infrastructure to confirm that transient key material (e.g., injected secrets, mounted keys) is not retained post-termination or restart.

6. Confirm that HSM- or KMS-managed keys are revoked securely when no longer in use, and that such revocation is permanent and auditable.

7. Validate that AI orchestration-related keys (e.g., inter-service chaining keys, encrypted pipeline tokens) are removed from memory, configs, and service descriptors once no longer needed.

8. Review audit trails for key destruction and revocation events, verifying entries include key identifiers, method of revocation, initiator identity, and event time.

9. Confirm that key destruction is embedded in orchestration workflows for service shutdown, container teardown, or ephemeral environment lifecycles.

10. Verify that destruction and revocation activities conform to legal and regulatory requirements for secure disposal of cryptographic assets and compliance with regional data protection laws.

11. Confirm that upstream or downstream dependencies impacted by key destruction (e.g., shared orchestration APIs, encrypted traffic paths) are coordinated with to avoid service impact or misconfiguration.

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

1. Verify that the OSP 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., across orchestrated services, service mesh layers, or pipeline encryption frameworks).

3. Review the OSP’s authorization procedures for key activation and validate that a formal approval process is required before keys are transitioned to active use.

4. Validate that the OSP uses access controls, multi-party workflows, or orchestration-layer policy checks to restrict and govern key activation operations.

5. Confirm that key activation rules are consistently enforced across orchestrated environments, including service mesh encryption, inter-service communication, and data pipeline flows.

6. Review audit logs for key activation events across orchestration platforms, and verify they capture key metadata, approving authority, timestamps, and affected systems or services.

7. Verify that legal, contractual, and regulatory requirements related to cryptographic key activation (e.g., industry certifications, SLA terms, data residency) are addressed in OSP key management processes.

8. Confirm that pre-activated keys are subject to expiration, timeout, or periodic revalidation policies to prevent indefinite dormancy or misuse.

9. Verify that key activation processes apply to keys used in orchestrated AI services (e.g., LLM chaining, model API key usage) and follow the same gating and approval mechanisms.

10. Review whether the OSP accounts for upstream key generation from MPs and downstream key activation dependencies with APs or AICs that rely on coordinated encryption functionality.

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

1. Verify that the OSP defines processes, procedures, and technical measures to monitor, review, and approve cryptographic key transitions to and from suspension, including keys used in orchestrated service communications and platform-level encryption.

2. Confirm that the OSP defines valid criteria for suspending cryptographic keys, including policy violations, security anomalies, temporary operational pauses, and other risk-based triggers relevant to orchestrated services and AI pipeline encryption (e.g., service mesh keys, LLM chaining tokens).

3. Review documentation showing that key suspension and reactivation events follow an OSP-managed change control or service governance workflow.

4. Validate that suspended keys are made inaccessible to live services but remain securely stored and trackable within orchestration infrastructure.

5. Verify that access to suspend or resume keys is restricted to authorized roles, and that separation of duties is enforced across operations, DevOps, and platform governance teams.

6. Review OSP monitoring tools and automation policies that generate alerts for unauthorized or unplanned key suspension events.

7. Verify that orchestration-layer audit logs capture full metadata for key suspension events, including initiating service or user, reason, and downstream service impact.

8. Confirm that key suspension procedures address applicable legal, contractual, and regulatory requirements (e.g., uptime SLAs, service continuity mandates, or regional encryption policies).

9. Validate that suspended keys used in orchestrated AI services (e.g., LLM chaining, API encryption, inference routing) are managed according to the same governance and approval standards.

10. Review whether the OSP accounts for upstream key status transitions from MPs and downstream coordination with APs and AICs that may depend on suspended or resumed keys.

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

1. Verify that the OSP 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 service mesh encryption or orchestrated AI flows).

2. Confirm that all keys used across orchestrated services are assigned expiration metadata and tracked through orchestration tooling or integrated key lifecycle systems.

3. Review whether automated deactivation mechanisms are configured within orchestration environments to enforce key expiry actions.

4. Validate that keys scheduled for deactivation are removed or blocked from service-to-service workflows and cannot be referenced by active orchestration components.

5. Confirm that access to deactivated keys is restricted and that they are logically separated from active key inventories.

6. Review deactivation audit logs to ensure that the orchestration platform captures key expiration events, including timestamp, affected services, and system triggers.

7. Verify that deactivated keys are archived, retired, or transitioned for destruction based on OSP retention policies and operational dependencies.

8. Confirm that legal, contractual, and regulatory requirements (e.g., uptime SLAs, encryption mandates) are integrated into key expiration and deactivation workflows.

9. Validate that keys used in orchestrated AI components (e.g., encrypted API connections, model chaining) are also subject to the same deactivation controls.

10. Review whether key deactivation procedures include coordination with upstream key issuers (e.g., MP) and downstream service consumers (e.g., APs, AICs) to prevent service disruption.

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

1. Verify that the OSP 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., keys used in orchestrated service-to-service encryption or AI integration layers).

2. Confirm that archived keys are maintained in hardened repositories with access restricted to orchestration security roles and subject to logged, workflow-based approval mechanisms.

3. Review whether least privilege access is enforced for archived key repositories, with access limited to roles responsible for orchestration security or compliance.

4. Validate that requests to access archived keys follow a documented approval process and that access events are logged and subject to periodic review.

5. Confirm that archived keys are disabled from active use in orchestration services and cannot be invoked by automated pipelines or APIs.

6. Review whether archived keys follow defined retention schedules that align with regulatory obligations and orchestration platform requirements.

7. Verify that the OSP performs regular audits of the archived key inventory to identify keys eligible for destruction or extended retention.

8. Confirm that controls are in place to prevent unauthorized extraction, restoration, or replication of archived keys.

9. Validate that orchestration-related AI keys (e.g., used for LLM routing, encrypted service interactions) are included in the OSP’s archival policy.

10. Review whether the OSP coordinates with upstream MP providers and downstream APs or AICs to address interdependencies tied to archived key usage or retention requirements.

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

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

3. Confirm that the OSP restricts use of compromised keys to decrypt-only operations under controlled circumstances (e.g., orchestration-layer encryption of prior pipeline states), and explicitly prohibits further encryption with such keys unless formally approved.

4. Review how the OSP tags, flags, or labels compromised keys in orchestration-layer key management systems or automation workflows.

5. Validate that compromised keys are isolated from active encryption pipelines and are only retained in secure storage for decrypt-only operations.

6. Confirm that access controls for compromised keys are highly restrictive and require multi-level approval prior to usage.

7. Review OSP audit logs, automation trails, or monitoring dashboards to track all uses of compromised keys, including service-specific context.

8. Verify that decrypt-only activities using compromised keys are recorded and mapped to orchestration functions, including the purpose and business justification.

9. Confirm that the OSP’s handling of compromised keys is aligned with legal, contractual, and SLA-based obligations, including any jurisdiction-specific requirements.

10. Validate that AI service integrations (e.g., model chaining, encrypted routing, prompt transformation) that previously used compromised keys are transitioned to new key materials and appropriately logged.

11. Review whether the OSP notifies and coordinates with upstream MPs and downstream APs or AICs regarding compromised key handling and usage restrictions.

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

1. Verify that the OSP 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 OSP conducts periodic risk assessments that evaluate key recovery scenarios across orchestrated services (e.g., service mesh encryption, inter-service tokens, AI pipeline keys) and considers the potential impact on orchestration flow continuity and AI service chaining.

3. Review whether the OSP’s key recovery plans address service-critical keys (e.g., pipeline signing keys, inter-service encryption keys, orchestration config secrets) and their impact on availability and integrity.

4. Validate that secure key backup procedures are implemented across the orchestration environment, and that backup keys are protected against unauthorized access, corruption, or loss.

5. Confirm that key recovery processes are tested regularly and reflect operational realities, including the ability to restore AI-driven orchestration services with minimal disruption.

6. Review recovery authorization workflows, including the use of split control, multi-approver validation, and secure recovery environments to reduce risk of compromise.

7. Verify that access to key backups and recovery tools is tightly restricted through least privilege, and that actions are logged, reviewed, and subject to regular audit.

8. Confirm that the OSP’s key recovery strategy is informed by its broader risk management framework, including continuity-of-service requirements, regulatory constraints, and incident response obligations.

9. Validate that AI-specific keying materials (e.g., keys for model chaining or encrypted orchestration routes) are included in the recovery plan and assessed for the implications of potential data exposure.

10. Review whether the OSP coordinates recovery-related responsibilities with upstream MPs and downstream APs or AICs, ensuring transparency and control alignment across cryptographic boundaries.

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

1. Verify that the OSP 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 OSP’s key management system maintains a complete and up-to-date inventory of all cryptographic keys and materials in scope, including key attributes (e.g., type, status, owner, lifecycle stage, algorithm) and usage context.

3. Review whether the inventory includes keys used for securing service-to-service communication, orchestration scripts, container encryption, and AI integration endpoints.

4. Validate that all status changes (e.g., key generation, activation, compromise, revocation, deactivation) are captured, timestamped, and logged automatically.

5. Confirm that access to inventory data is tightly controlled and restricted to authorized operations or security personnel through role-based permissions.

6. Review the archival and retention policies for historical key records, ensuring the OSP meets audit, contractual, and regulatory requirements.

7. Verify that alerting mechanisms are in place to notify appropriate teams of unexpected status changes or anomalies in key activity.

8. Confirm that inventory logs are integrated into centralized monitoring and analytics platforms to support operational visibility and security incident response.

9. Validate that periodic reviews of the key inventory are performed to ensure accuracy, completeness, and alignment with active orchestration components.

10. Review whether the OSP maintains inventory coordination with upstream MPs and downstream APs or AICs for shared or delegated key responsibilities.

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

1. Verify that physical and environmental security policies explicitly cover facilities supporting orchestration platforms and related infrastructure.

2. Verify that evidence demonstrates defined access control procedures, environmental protection measures, and periodic (at least annually or upon significant changes) review of the policies.

3. Verify that dependencies on external infrastructure providers are governed by documented physical security requirements.

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

1. Verify the OSP’s policy requires all integrated CSPs to follow secure equipment disposal procedures.

2. Review the OSP’s vendor due diligence process to confirm it assesses the disposal practices of its underlying infrastructure providers through their SOC 2 or ISO 27001 reports.

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

1. Verify the OSP has a policy for authorizing the transfer of orchestration configurations or multi-tenant data between different cloud environments.

2. Review change management records to ensure cross-region or cross-cloud data transfers are documented and approved.

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

1. Verify the OSP’s vendor management policy assesses the physical security of the facilities of all its critical suppliers and partners in the service chain.

2. Review the OSP’s own policies for maintaining a secure work environment for its personnel.

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

1. Verify the OSP’s policy requires any physical media containing orchestration configurations or sensitive tenant data to be encrypted during transport.

2. Review records of any physical media transfers to ensure compliance with chain-of-custody procedures.

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

1. Verify the OSP classifies its logical assets, such as orchestration templates, API gateways, and service configurations, based on their role in the service chain and the sensitivity of the data they handle.

2. Check that tenant environments are classified as high-risk assets.

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

1. Verify the OSP maintains an inventory of all orchestrated services, integrated components, and their versions.

2. Confirm this inventory is used to track dependencies and manage the security posture of the entire service chain.

DCS-08: Controlled Physical Access Points

Control Specification

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

Auditing Guidelines for Orchestrated Service Providers (OSP)

1. Verify that the OSP’s vendor risk management program includes a review of the physical security controls for all underlying CSPs used in the orchestrated service.

2. Check for evidence that the OSP assesses the physical location risks of its dependencies.

DCS-09: Equipment Identification

Control Specification

Use equipment identification as a method for connection authentication.

Auditing Guidelines for Orchestrated Service Providers (OSP)

1. Verify that the OSP uses workload identities or similar mechanisms to authenticate connections between different services in the orchestration chain.

2. Check that the orchestration platform enforces policies based on trusted equipment or service identity.

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

1. Verify the OSP’s due diligence process includes a review of the physical access controls for all CSPs and colocation facilities in its supply chain.

2. Check that the OSP obtains and reviews these providers’ attestations annually.

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

1. Verify the OSP’s vendor assurance program requires all underlying infrastructure providers to have surveillance systems in their data centers.

2. Confirm the OSP has a process to review evidence of these controls from its providers.

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

1. Verify the OSP’s vendor management process confirms that their underlying CSPs provide adverse event response training to their datacenter personnel.

2. Review the OSP’s incident response plan for procedures on how to react to physical security events at a provider facility.

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

1. Verify that the OSP’s vendor assurance program assesses the cabling security controls of all underlying infrastructure providers.

2. Review evidence that the OSP has evaluated this aspect of its providers’ physical security posture.

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

1. Verify the OSP’s vendor risk assessment includes a review of the environmental controls for all underlying infrastructure providers.

2. Check that the OSP has a business continuity plan that addresses provider outages caused by environmental system failures.

DCS-15: Secure Utilities

Control Specification

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

Auditing Guidelines for Orchestrated Service Providers (OSP)

1. Verify the OSP’s vendor assurance program evaluates the utility security and redundancy of all its infrastructure providers.

2. Review the OSP’s end-to-end BC/DR plan to confirm it addresses cascading failures originating from a provider utility outage.

DCS-16: Equipment Location

Control Specification

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

Auditing Guidelines for Orchestrated Service Providers (OSP)

1. Verify the OSP’s service architecture is designed for high availability and deployed across multiple geographic regions to mitigate environmental risks.

2. Review the OSP’s risk assessment of the physical locations of its various infrastructure providers.

DCS-17: Datacenter Metrics

Control Specification

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

Auditing Guidelines for Orchestrated Service Providers (OSP)

1. Verify that the OSP monitors health and availability of orchestration platforms and supporting infrastructure.

2. Confirm that access control events and configuration integrity indicators for orchestration components are tracked.

3. Verify that monitoring detects unauthorized changes or abnormal platform behavior.

4. Confirm that alerts and metrics are integrated into operational recovery and response workflows.

DCS-18: Datacenter Operations Resilience

Control Specification

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

Auditing Guidelines for Orchestrated Service Providers (OSP)

1. Verify that orchestration platforms implement automated recovery and failover mechanisms for workloads and control plane services.

2. Confirm that orchestration services can tolerate node failures and infrastructure outages without sustained service disruption.

3. Verify that recovery procedures are tested periodically and results are documented.

4. Confirm that dependencies on infrastructure providers are addressed in continuity planning.

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

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

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

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

7. Evaluate whether third-party security and privacy policies and procedures are considered in the organization’s data security and privacy practices.

8. Verify that documentation includes specific data handling procedures for service integration points, APIs, and cross-service data transfers.

9. Review evidence that policies address data classification inheritance and protection continuity across orchestrated service boundaries.

10. Assess the implementation of technical and procedural controls to maintain data protection, classification, and handling requirements throughout orchestrated workflows. Examples of technical controls (e.g., data tagging, API gateways enforcing headers, encryption at hand-off) and procedural controls (e.g., SLAs, DPA clauses).

11. Verify that service-level agreements with upstream and downstream partners include data protection requirements and compliance responsibilities.

12. Examine logs or records demonstrating that orchestration-related data handling policies are reviewed annually and updated based on service changes, regulations, or risk assessments. Logs should show not only reviews but also updates driven by new risks or regulations.

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

1. Examine the OSP’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 OSP’s data privacy and security policy. Establish whether the OSP 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. Determine if the OSP has controls to evaluate third parties’ secure data disposal methods from storage media.

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

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

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

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

10. Verify that disposal methods address the unique characteristics of orchestrated services, including data flows between components and potential data persistence across service boundaries.

11. Review evidence of implementation, including logs or other documentation that confirms proper data removal from all elements of the orchestration environment.

12. Assess coordination procedures with upstream and downstream providers to ensure complete data disposal across the service chain.

13. Verify that data disposal triggers (e.g., retention period expiration, service termination) are correctly implemented and monitored.

14. Examine how ephemeral data, pipeline artifacts, and configuration data that might contain sensitive information are securely disposed of.

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

1. Examine the OSP’s procedures and technical requirements for the population and management of its data inventory. Establish that this process and key controls comply with the OSP’s data privacy and security policy. Establish whether the OSP 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 OSP’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. Determine whether the OSP evaluates third-party data inventory practices and assigns each one an appropriate risk level.

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

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

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

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

10. Verify that the inventory maps data flows across orchestrated components, identifying where sensitive data enters, how it’s processed, where it’s stored (even temporarily), and where it exits the service chain.

11. Review processes for tracking data lineage and transformations as data moves through orchestrated workflows, ensuring sensitive data remains identified throughout processing.

12. Assess mechanisms for updating the inventory when new services are integrated or existing data flows are modified within the orchestration environment.

13. Verify that the inventory enables identification of all sensitive data processing activities for compliance documentation and data protection impact assessments.

14. Review evidence that the inventory is regularly validated through data flow analysis or monitoring to ensure it accurately reflects current orchestration patterns.

DSP-04: Data Classification

Control Specification

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

Auditing Guidelines for Orchestrated Service Providers (OSP)

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

2. Establish if the OSP’s data classification matrix is aligned with the OSP’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 OSP’s specific needs and regulatory requirements.

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

7. Identify how the OSP evaluates third-party data classification practices and if appropriate risk levels are assigned to each.

8. Examine mechanisms for preserving classification labels as data flows through orchestrated services, ensuring metadata persistence across service boundaries.

9. Verify that orchestration workflows enforce handling policies based on data classification levels, with different processing rules for different sensitivity categories.

10. Review how service integrations maintain classification context during data transfers between components, including any classification translation or mapping between systems.

11. Assess classification verification at orchestration entry points, confirming that data received from other parties includes proper classification metadata.

12. Verify that monitoring and logging across orchestrated services is classification-aware, with enhanced scrutiny for more sensitive data categories.

13. Review handling procedures for situations where classification metadata is missing or ambiguous within the orchestration flow.

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

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

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

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

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

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

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

7. Determine if the data flow documentation includes data processed, stored, or transmitted to or from third parties.

8. Verify that documentation identifies entry and exit points for data, transformation, or processing activities at each stage and temporary or persistent storage locations within the orchestration environment.

9. Review how the documentation accounts for different data types and formats as they move through the orchestration pipeline, including any conversions or enrichments during processing.

10. Assess whether documentation identifies service dependencies and potential failure points that could impact data flow integrity or completeness.

11. Verify that documentation is reviewed at defined intervals (at least annually) and updated whenever changes occur to service components, API interfaces, or orchestration workflows.

12. Examine specific examples of documentation updates following service changes, confirming that updates accurately reflect modifications to the orchestration environment.

DSP-06: Data Ownership and Stewardship

Control Specification

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

Auditing Guidelines for Orchestrated Service Providers (OSP)

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

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

7. Determine whether third-party data ownership and stewardship are considered in the organization’s process.

8. Verify that documentation clearly defines the roles responsible for data protection at each stage of orchestrated processing, including who is accountable for applying security controls and ensuring compliance requirements are met.

9. Review how data ownership and stewardship are maintained when data passes through third-party components within the orchestration chain, ensuring continuous responsibility documentation.

10. Assess whether documentation addresses temporary data custody during processing and how stewardship responsibilities apply to ephemeral data instances within the orchestration environment.

11. Verify that service level agreements or contracts document data ownership and retention by the original data owner even as data moves through orchestrated processes.

12. Confirm that ownership and stewardship documentation is reviewed annually and updated when orchestration components, service integrations, or processing workflows change.

DSP-07: Data Protection by Design and Default

Control Specification

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

Auditing Guidelines for Orchestrated Service Providers (OSP)

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

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

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

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

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

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

8. Examine the OSP’s policy, standards, and procedures, and determine if third-party data protection practices are considered.

9. Examine service design documentation to verify that security controls, including secure service integration patterns and API security, are incorporated into orchestration architecture from the initial design phases.

10. Verify that orchestrated services implement secure defaults, including encryption for data in transit between services, robust authentication and authorization, and secure error handling.

11. Review the API security architecture and confirm that it incorporates industry best practices such as input validation, rate limiting, authentication, and authorization for all service endpoints.

12. Assess how security is maintained during data transformations and handoffs between orchestrated components, ensuring protection controls persist throughout processing flows.

13. Evaluate how the OSP’s service integration design process addresses security considerations, including threat modeling, security requirements definition, and integration point security testing.

14. Verify that the orchestration environment includes built-in monitoring and logging to detect security events across service boundaries and throughout the process flow.

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

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

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

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

4. Obtain evidence of the systems’ privacy settings and the laws and regulations that apply to the OSP. 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 OSP limits data collection to the minimum necessary for the identified purposes.

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

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

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

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

13. Verify that the OSP 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 the OSP’s policy, standards, and procedures and determine if a culture and expectation of privacy by design for third-party providers is defined. Determine whether this content addresses the directive of the organization’s culture and whether practices reflect privacy by design and industry best practices.

15. Verify that orchestration workflows support privacy rights fulfillment (access, correction, deletion) across integrated services without requiring special configuration.

16. Examine how the OSP maintains awareness of and compliance with privacy regulations across different jurisdictions where orchestrated services may operate, ensuring default settings meet the most restrictive requirements.

DSP-09: Data Protection Impact Assessment

Control Specification

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

Auditing Guidelines for Orchestrated Service Providers (OSP)

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

4. Establish whether the organization 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. Determine if the DPIA includes third-party providers and how identified risks are remediated.

11. Verify that DPIAs assess privacy risks across the service orchestration chain, including data flows between integrated services.

12. Review whether DPIAs consider both the OSP’s direct processing activities and those of integrated third-party services.

DSP-10: Sensitive Data Transfer

Control Specification

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

Auditing Guidelines for Orchestrated Service Providers (OSP)

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

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

4. Obtain a sample of the technical measures implemented by the OSP to determine if those measures adhere to the OSP’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 OSP 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. Determine how the OSP ensures that all third-party providers protect the transfer of personal or sensitive data.

10. Review data flow documentation, mapping all sensitive data transfers between integrated services.

11. Assess integration security controls that prevent unauthorized data transfers between orchestrated components.

12. Evaluate consistent implementation of data transfer policies across the entire orchestration layer.

13. Verify monitoring capabilities for detecting unauthorized cross-service data transfers.

14. Review compliance verification mechanisms that validate data transfers adhere to the defined scope and regulatory requirements.

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

1. Examine whether the OSP’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 OSP 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 OSP’s processes. Confirm that all relevant evidence was formally documented.

4. Determine if third-party providers are evaluated according to the OSP’s policy and procedures related to data privacy, and whether those providers address the requirement that authorized users must be able to access, modify, or delete personal data

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

6. Verify implementation of tracking mechanisms that ensure comprehensive fulfillment of requests across integrated services.

7. Review data flow documentation between services to confirm all personal data touchpoints are covered in request handling processes.

8. Assess orchestration interfaces to verify they support data access, modification, and deletion capabilities.

9. Evaluate coordination procedures for handling requests that span multiple services.

10. Verify that audit trails capture the complete fulfillment process across orchestrated components.

11. Review testing that validates end-to-end request fulfillment across the orchestration layer.

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

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

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

3. Review the OSP’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 OSP’s processes that inform data subjects why it requests this data and what it will be used for. Confirm that any OSP 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. Determine if the organization evaluates third-party providers to ensure that personal data is processed according to applicable laws and regulations and for the purposes declared to the data subject.

10. Examine how processing purpose metadata is maintained and propagated across integrated services.

11. Verify implementation of orchestration controls that enforce purpose limitations throughout service integrations.

12. Review data flow documentation, identifying processing purposes at each point in the orchestration.

13. Assess monitoring and alerting capabilities to detect potential purpose limitation violations.

14. Verify that service design incorporates purpose limitations as architectural constraints.

15. Review testing procedures that validate purpose limitation enforcement across the orchestration.

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

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

4. Examine the OSP’s contractual requirements for subprocessor compliance, reporting, and non-compliance sanctions and the OSP’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. Examine the OSP’s documented processes and procedures for the identification, management, and oversight of subprocessors within its orchestrated service ecosystem.

10. Verify the existence and comprehensiveness of the OSP’s sub-processor register, including data flow documentation across all orchestrated services.

11. Assess the technical controls implemented to secure data transfers between orchestrated services and sub-processors (API security, encryption, access controls).

12. Review the OSP’s data transfer impact assessments for cross-border data flows to sub-processors.

13. Examine the OSP’s process for notifying customers of sub-processor changes and obtaining necessary approvals.

14. Assess the monitoring and compliance verification processes for sub-processors, including regular security assessments and audits.

15. Review documentation of data lineage tracking capabilities that enable visibility into how personal data flows through orchestrated services.

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

1. Policies, Roles, and Contracts: Examine the OSP’s documented policies, procedures, and contractual requirements requiring sub-processors to disclose access to personal or sensitive data prior to processing. Verify that roles and responsibilities for managing and communicating disclosures are clearly documented and assigned. Review contracts with sub-processors to confirm they include: provisions for handling PII in compliance with legal and ethical standards, requirements to comply with the same privacy and security standards as the OSP, clauses disclosing the use of subcontractors in customer contracts, and policies enforcing data minimization, ensuring only the minimum necessary PII is disclosed.

2. Sample-Based Validation: Select a sample of sub-processor data transfers and validate that: disclosures were made before processing began and controls and reporting align with the OSP’s privacy and security policy.

3. Disclosure Records and Record-Keeping: Verify that the OSP maintains detailed, auditable records of all PII disclosures to third parties, including: what PII was disclosed, when the disclosure occurred, to whom it was disclosed, the authority or legal basis for disclosure, and review the OSP’s record-keeping system to ensure it comprehensively documents all disclosures and approvals.

4. Customer Notification and Legal Request Handling: Confirm the OSP has a documented process for: notifying customers promptly of any legally binding requests to disclose their PII, rejecting requests that are not legally binding unless approved by the customer, and ensuring timely notification while respecting any applicable legal constraints.

5. Customer-Facing Disclosure Process: Verify the existence and completeness of the OSP’s sub-processor register, which should include: sub-processor identity, location, purpose, data categories accessed, and security measures. Review the customer notification process for changes to sub-processors, ensuring: notifications include all relevant details, notification timelines allow customers adequate time to review and respond, and approval workflows are defined and followed.

6. Upstream Provider Disclosures: Examine how the OSP collects and incorporates disclosures from its upstream providers (e.g., MPs, CSPs) and ensures that this information is reflected in its own customer-facing disclosures.

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

1. Verify that orchestration platforms and tools include controls for preventing unauthorized replication or processing of production data in non-production pipelines.

2. Verify if approvals are obtained before using production inputs or prompts in testing orchestrations or evaluation workflows.

3. Verify if data passing through orchestration layers is anonymized or obfuscated when used outside production contexts.

4. Verify if any special-case uses of real production data in development pipelines have been approved through formal governance processes.

5. Verify if orchestration framework policies and procedures are reviewed and updated in response to evolving enterprise integration and data governance needs.

6. Verify if relevant staff and integrators are trained on best practices and controls for managing data flow securely through orchestration layers, especially across environments.

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

1. Verify if policies and technical procedures define how AI orchestration data (e.g., prompts, API logs, intermediate outputs) are retained, archived, and deleted, including role assignments.

2. Verify if data elements orchestrated across services are categorized and governed by documented retention schedules aligned with platform policies and regulatory requirements.

3. Verify if orchestration layer logs and runtime data are retained and managed in accordance with defined schedules.

4. Verify if third-party orchestration tools and libraries follow retention agreements aligned with customer or platform requirements.

5. Verify if orchestrated data is deleted securely after the retention period using appropriate technical mechanisms.

6. Verify if system and user actions related to data deletion or archiving are logged, monitored, and available for audit.

7. Verify if orchestration services enforce security measures to protect temporary and retained data.

8. Verify if orchestration platform policies are reviewed to accommodate new data processing frameworks or legal standards.

9. Verify if orchestration services support custom retention rules for AI-generated or AI-processed data.

10. Verify if orchestrated workflows are designed to avoid unnecessary retention of sensitive data.

11. Verify if transient data (e.g., intermediate inference outputs) is anonymized or securely discarded.

12. Verify if access to orchestration runtime data and prompts is restricted and auditable.

13. Verify if orchestration frameworks support secure deletion of data post-workflow execution.

14. Verify if orchestration platforms offer dashboards or logs to audit compliance with 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 Orchestrated Service Providers (OSP)

1. Verify whether the orchestrated service platform includes policy guidelines for protecting sensitive data as it moves across integrated AI models, tools, and environments.

2. Verify whether responsibilities for managing data privacy across orchestration layers are clearly assigned (e.g., prompt routers, connectors, plugin handlers).

3. Verify that orchestrated workflows include controls to classify, restrict, and protect sensitive data; check implementation of encryption, data masking, and secure API gateways; and ensure privacy requirements are well-documented and regularly maintained.

4. Verify that sensitive data flowing through orchestrated AI workflows is managed consistently with the organization’s privacy policies, including storage, caching, and third-party model access.

5. Verify whether there have been privacy-related incidents involving orchestrated systems (e.g., leakage through API calls or logging), and ensure all remediation actions are documented.

6. Verify that orchestration strategies include monitoring for privacy violations, bias propagation, and transparency gaps across complex AI workflows.

7. Verify that procedures exist for handling incidents across orchestrated systems, including breach reporting, component isolation, and notification to impacted stakeholders.

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

1. Verify if the platform defines procedures for managing law enforcement requests that may target orchestration metadata or AI-generated outputs.

2. Verify if legal response procedures are aligned with data privacy standards and the service provider’s contractual obligations.

3. Verify if disclosure responsibilities (e.g., legal, technical, compliance) are clearly distributed across platform functions.

4. Verify if secure communications and approval chains are used for processing law enforcement disclosures.

5. Verify that the disclosure process, including rationale, communications, and affected data, is formally logged.

6. Verify if disclosure notifications are managed in compliance with defined timelines and jurisdictional requirements.

7. Verify if platform procedures are routinely updated based on changes to AI workflows or new privacy legislation.

8. Verify if staff interacting with law enforcement are trained on orchestration-specific privacy and data disclosure practices.

9. Verify if data request logs include audit trails for who accessed what orchestration or AI-related data and why.

10. Verify if deviations in the disclosure process are documented and investigated with root cause analysis.

11. Verify if AI orchestration systems account for how AI-generated content or logic can be disclosed to authorities.

12. Verify if technical controls (e.g., access control, encryption) are enforced during the disclosure of orchestrated AI data.

13. Verify if audit logging and monitoring mechanisms are implemented for all AI-related law enforcement interactions.

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

1. Verify policies and technical requirements for physical storage of data within AI orchestration platforms, including ethical guidelines for AI-enabled data processing and storage.

2. Verify that roles and responsibilities related to managing AI orchestration system data storage are clearly defined and documented.

3. Verify that storage and processing policies incorporate compliance with geographic and jurisdictional restrictions relevant to orchestrated data flows.

4. Verify that authoritative records are maintained for physical storage locations involved in orchestrated AI workflows, including data lineage tracking.

5. Verify that these records are accurate and comply with organizational policies.

6. Verify documentation of obligations related to AI systems used in orchestration, including supplier roles and responsibilities.

7. Verify that AI systems supporting data storage and processing within orchestration frameworks meet ethical and organizational requirements.

8. Verify procedures exist for monitoring and auditing AI orchestration platforms to ensure ethical and regulatory compliance.

9. Verify that risk management strategies address bias mitigation and transparency concerns within AI orchestration data storage and processing.

10. Verify incident management procedures cover AI orchestration-related storage and processing incidents, ensuring timely reporting and remediation.

DSP-20: Data Provenance and Transparency

Control Specification

Define, implement and evaluate processes, procedures and technical measures to: 1) Document and trace data sources, and 2) Make the data source available according to legal and regulatory requirements

Auditing Guidelines for Orchestrated Service Providers (OSP)

1. Verify that data sources used for orchestration (e.g., prompts, tool outputs, embeddings, workflow metadata) are clearly identified and documented.

2. Verify that data lineage illustrates how data flows across steps in the AI orchestration process (e.g., LangChain workflows).

3. Verify that a dictionary of orchestration artifacts (e.g., prompt templates, intermediate outputs) is maintained.

4. Verify that provenance records capture processing history, tool invocation, and response timing.

5. Verify that orchestration monitoring tools log access and modifications to prompt pipelines, tool chains, or external data integrations.

6. Verify that validation or checksums ensure workflow data integrity across orchestrated chains.

7. Verify that scalability (e.g., dynamic chaining), privacy (e.g., sensitive prompt data), and complexity (e.g., recursive calls) are addressed.

8. Verify that orchestration data practices align with applicable legal and customer-specific data requirements.

9. Verify that encryption and access controls apply to all orchestration data elements and APIs.

10. Verify that data used in orchestration (e.g., temporary context data) is deleted when no longer needed, per policy.

11. Verify that developers and admins are trained on data sensitivity and workflow lifecycle documentation requirements.

12. Verify that metadata and logs (e.g., flow traces, execution times) can be produced for audit and analysis.

13. Verify that versioning applies to workflows, prompt templates, and orchestration configuration files.

14. Verify that disclosure processes for orchestrated data (e.g., audit logs, user prompts) are documented and legally compliant.

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

1. Verify that data sources integrated and routed by orchestration platforms are validated to prevent malicious or poisoned data entry.

2. Verify that data quality checks are implemented within orchestration workflows to detect and eliminate corrupted or suspicious data.

3. Verify that orchestration systems include automated monitoring to identify unusual data patterns or anomalies indicating poisoning attempts.

4. Verify that orchestration platforms support techniques such as adversarial filtering or data sanitization to enhance resilience to poisoned data.

5. Verify that access controls restrict unauthorized modification of datasets flowing through orchestration pipelines.

6. Verify encryption is enforced for data stored or transmitted within orchestration systems to prevent unauthorized tampering.

7. Verify monitoring and alerting mechanisms are in place within orchestration platforms to detect tampering or poisoning attempts.

8. Verify that incident response plans include handling of data poisoning events affecting orchestration services.

9. Verify that staff managing orchestration platforms are trained to recognize and mitigate data poisoning threats.

10. Verify use of automated tools within orchestration workflows to continuously monitor data integrity and detect anomalies.

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

1. Verify that PETs orchestrated as part of AI pipelines (e.g., private data handling, secure input processing) are mapped to documented business use cases.

2. Verify that orchestration systems continuously monitor PET configurations and log their effectiveness or failures.

3. Verify that orchestrated PETs (e.g., private inference steps) meet applicable privacy and AI governance standards.

4. Verify that PET metrics and KPIs (e.g., anonymization rate, differential privacy budget) are captured and reported as part of pipeline monitoring.

5. Verify that platform users and developers are trained on deploying and maintaining PETs within orchestration workflows.

6. Verify that PET libraries, APIs, and orchestration scripts are regularly patched for vulnerabilities.

7. Verify that orchestration logs involving PET usage are monitored for errors, unauthorized access, or privacy violations.

8. Verify that PET-enabled orchestration workflows are tested by independent parties for privacy and security weaknesses.

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

1. Verify that data sources integrated into AI orchestration workflows are clearly identified and traceable.

2. Verify that orchestration systems log changes or updates to data as it flows through the platform.

3. Verify that automated tools monitor data integrity continuously and detect anomalies in orchestrated data flows.

4. Verify that access controls are implemented to prevent unauthorized data changes within orchestration processes.

5. Verify that encryption is applied to sensitive data managed in orchestration workflows to prevent unauthorized access.

6. Verify that version control is implemented to track changes to datasets and models within orchestration systems.

7. Verify that employees managing orchestration workflows are trained on data handling and integrity best practices.

8. Verify that procedures are in place to identify, report, and remediate data integrity issues in orchestration platforms.

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

1. Verify if clear and accessible information about AI system operation within orchestration services is provided to stakeholders.

2. Verify if continuous monitoring and improvement tools are used to test and refine AI orchestration workflows.

3. Verify if orchestration services comply with applicable privacy regulations and governance standards.

4. Verify if feedback is gathered and used to improve AI orchestration systems.

5. Verify adherence to data governance policies and privacy regulations in orchestration platforms.

6. Verify that sensitive information is protected and data integrity maintained within orchestration systems.

7. Verify the use of monitoring tools to ensure ongoing performance and relevance of AI orchestration workflows.

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

1. Examine whether the organization has established a comprehensive strategy for information governance, ensuring AI service orchestration activities (e.g., coordination of distributed AI components, API-mediated workflows, and automated service interactions) are explicitly included, leadership sponsorship is documented, and governance policies, standards, and procedures are formally approved, communicated, and applied.

2. Confirm that policies, standards, and procedures are reviewed and updated at least annually, with documented evidence of the review process, and assess whether reviews and updates are also considered following significant changes in orchestration processes, supporting technologies, regulatory expectations, or related industry guidance.

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

1. Program Examination

   • a. Verify that a formal, documented AI Risk Management (AIRM) program exists and has been approved by executive leadership.

   • b. Confirm that the AIRM program includes defined roles and responsibilities for managing AI-specific risks in orchestrated services, including coordinating data flows, API integrations, and model interconnectivity.

2. Program Content Assessment

   • a. Verify that the AIRM program includes documented procedures for identifying, evaluating, assigning ownership of, treating, and accepting risks related to AI orchestration, such as cross-service data exposure, misconfigured APIs, cloud service dependencies, and AI system handoffs and chaining errors.

   • b. Verify whether the AIRM framework accounts for orchestration-specific AI risks, including inter-model communication failures, versioning mismatches, service chaining errors, or loss of contextual accuracy degradation. If not, assess whether a documented rationale and alternative risk mitigation approach exists.

   • c. Confirm that the AIRM program considers the reliability, security, and privacy implications of using multi-cloud orchestration, shared service layers, or distributed microservices environments.

   • d. Verify that responsibilities for managing orchestration-related risks are clearly assigned, including cross-functional roles (e.g., platform engineers, service owners, data security leads).

3. Program Alignment Evaluation:

   • a. Evaluate whether the AIRM program aligns with the organization’s orchestration governance strategy, internal risk management framework including operational resilience practices.

   • b. Confirm that the AIRM program incorporates applicable regulatory and industry standards and guidelines related to AI service orchestration and cloud-based data transfer, particularly in regulated industries.

4. Implementation Validation

   • a. Validate implementation of the AIRM program by reviewing risk records, escalation logs, or monitoring dashboards tied to AI service orchestration environments (i.e., orchestration-layer failures or integration incidents).

   • b. Inspect a sample of risk treatment or acceptance documentation related to orchestration-specific AI risks, including AI inter-service integration errors, coordination delays, or incident escalations tied to service chaining or orchestration logic, to assess traceability, decision rationale, and evidence of assigned ownership or leadership 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 Orchestrated Service Providers (OSP)

1. Policy Examination

   • a. Verify that the organization maintains a documented inventory of policies and procedures governing AI service orchestration, including those related to data flow integration, API communication, and system interdependencies.

   • b. Confirm that the organization has criteria for identifying which orchestration-related policies are “relevant” for review, particularly those that influence cross-system behavior and cloud service integration.

2. Policy Assessment

   • a. Verify that orchestration-related policies and procedures are reviewed at least annually, with records showing version control, timestamps, and approval history.

   • b. Confirm that reviews are conducted by accountable owners and that results are reviewed or approved through appropriate governance bodies.

3. Review Process Evaluation

   • a. Determine whether the organization has defined what constitutes a “substantial change” in orchestration environments (e.g., platform re-architecture, new service chaining workflows, or SLA model updates).

   • b. Verify that there is a process in place to trigger out-of-cycle policy reviews in response to such changes.

4. Implementation Validation

   • a. Review policy documentation and change logs to confirm that orchestration-related policies have been reviewed at least annually and reflect the current service design.

   • b. Inspect a sample of recent orchestration changes or integration updates and validate that corresponding policies were reviewed and updated as necessary.

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

1. Policy Examination

   • a. Exception Process Documentation: Verify that a formal, documented process exists for requesting, reviewing, approving, and tracking exceptions to policies relevant to AI service orchestration, including those that govern integration protocols, service chaining, data flow control, or API management.

   • b. Governance Integration: Confirm that the exception process is formally established under the organization’s governance program and is referenced within orchestration-related standards, policies, or governance charters.

2. Policy Assessment

   • a. Process Criteria: Verify that the exception process outlines required documentation, approval authority, justification standards, and expiration or renewal periods.

   • b. Scope and Applicability: Confirm that the exception process applies to all policy deviations, including those that may involve orchestration scenarios such as bypassing data validation layers, disabling flow control mechanisms, or temporarily relaxing service constraints.

   • c. Communication Protocols: Assess whether approved exceptions are shared with affected teams (e.g., platform engineers, data privacy staff) and stored in a centralized, auditable system.

3. Review Process Evaluation

   • a. Enforcement Mechanism: Determine whether control points exist to prevent or flag policy deviations that occur without approved exceptions (e.g., CI/CD checks, system logging, or workflow enforcement).

   • b. Governance Oversight: Confirm that the governance team (e.g., orchestration or enterprise governance function) periodically reviews exception activity as part of compliance monitoring or policy review cycles.

4. Implementation Validation

   • a. Sample Testing: Review a sample of approved exceptions related to orchestrated services to confirm that each includes justification, formal approval, expiration or review timelines, and supporting documentation.

   • b. Exception Coverage Check: Examine a sample of recent deviations from orchestration policies (e.g., undocumented integrations, temporary overrides of automated data handling) and validate that exceptions were properly documented and approved.

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

1. Program Existence and Scope: Confirm that the organization has a documented Information Security Program that governs risks related to orchestrated digital services, including aspects such as system integration, data routing, interdependencies, and cloud-based workflows. Where AI orchestration is part of the service offering, verify that the program identifies and incorporates security considerations from relevant AICM domains (e.g., Infrastructure, Data Security, Model Lifecycle).

2. Policy Coverage and Governance: Assess whether the program addresses key security risks associated with service orchestration, such as access control across interconnected systems, communication integrity, system availability, and service chaining. Confirm that ownership of orchestration-related security is clearly assigned and that formal governance structures (e.g., security councils, architecture review boards) oversee the program across DevOps, platform engineering, and security operations. Verify alignment with internal security policies and industry frameworks, especially where third-party APIs, external models, or multi-cloud environments are involved.

3. Program Integration Across Domains: Evaluate whether the Information Security Program explicitly maps to AICM domains that are relevant to the OSP’s service responsibilities. Confirm that orchestration-related security policies and controls are implemented across operational functions, such as cloud engineering, service reliability, and incident responses, and are not siloed within a single department.

4. Implementation Evidence and Control Validation: Review assurance documentation such as policy deployment logs, audit findings, risk assessments, or training records to verify that the security program is operationalized across in-scope AICM domains. Select representative areas, such as Data Protection, Infrastructure, and Service Management, and confirm that the program includes effective controls and that those controls are demonstrably in use.

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

1. Policy Examination

   • a. Verify that the organization has formally documented roles and responsibilities related to governance of AI orchestration activities, including oversight of integrated services, system coordination, and cross-platform data flow or API interactions.

   • b. Confirm that the assigned responsibilities cover each stage of the governance lifecycle—planning, implementation, operation, assessment, and continuous improvement—as it applies to orchestrated AI services.

2. Policy Assessment

   • a. Assess whether designated roles for orchestration governance clearly define accountable parties and their decision-making authority for managing service interactions, interdependencies, and runtime behavior.

   • b. Confirm that the documented roles align with how orchestrated services are actually implemented and supported (e.g., DevOps, platform engineering, IT operations), and reflect cross-functional coordination across technical and support teams.

3. Program Evaluation

   • a. Determine whether governance responsibilities are embedded into processes such as service onboarding, change control, and system monitoring workflows, especially in dynamic or cloud-native orchestration environments.

   • b. Verify that roles include defined escalation paths and regular review checkpoints for managing governance-related issues in orchestration environments.

4. Implementation Validation

   • a. Review documentation such as team charters, service runbooks, meeting records, or internal assurance results (e.g., compliance reports or service reviews) to confirm roles are actively carried out.

   • b. Select a governance-related orchestration function (e.g., data routing review, integration approvals, flow control exception handling) and verify that responsible roles are fulfilling their duties as defined.

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

1. Policy Examination

   • a. Verify that the organization maintains a documented inventory of relevant regulatory, legal, contractual, and industry standards that apply to orchestrated AI services, including cross-system data handling, integration, and inter-service communication.

   • b. Confirm that multiple sources are considered when identifying applicable requirements, including cloud service agreements, cross-border data regulations, service-level commitments, and internal risk policies, with particular attention to interoperabilitie and third-party dependencies.

2. Policy Assessment

   • a. Assess whether the inventory is reviewed and updated regularly, especially in response to regulatory or contractual changes, and whether accountability for maintaining this list is clearly assigned to appropriate operational or compliance functions.

   • b. Confirm that the inventory reflects the specific orchestration environment, including AI pipelines, external integrations, dependency chains, and cross-functional responsibilities.

3. Program Evaluation

   • a. Determine whether the identified obligations are embedded into orchestration practices, such as service onboarding, workflow configuration, and cross-system data flow controls, real-tine data processing, or hand-off protocols.

   • b. Confirm that relevant stakeholders (e.g., security architecture, legal, DevOps) are aware of and actively use the documented requirements when designing or modifying orchestrated AI services.

4. Implementation Validation

   • a. Review documentation such as integration workflows, vendor agreements, or internal assurance reports to confirm that identified obligations are referenced or considered during orchestration design and operation.

   • b. Select a sample of listed requirements (e.g., cross-border data handling, third-party API commitments) and verify that relevant documentation or workflows demonstrate application of or compliance with these obligations.

GRC-08: Special Interest Groups

Control Specification

Establish and maintain contact with related special interest groups and other relevant entities in line with business context.

Auditing Guidelines for Orchestrated Service Providers (OSP)

1. Policy Examination Engagement Strategy: Verify whether the organization has a documented policy or strategy encouraging participation in external groups related to cloud orchestration, API security, interoperability, or service coordination. Confirm that the purpose of such engagement is defined and aligned with the organization’s need to manage orchestration complexity, integration standards, or cross-platform risk awareness.

2. Policy Assessment Group Relevance: Assess whether the organization participates in groups that focus on areas relevant to orchestration (e.g., cloud service interoperability forums, CI/CD pipeline security alliances, MLOps-focused communities, DevOps communities). Responsibility Assignment: Verify that designated roles or teams are responsible for engaging with external groups and that their responsibilities are reflected in governance documentation or internal meeting materials.

3. Program Evaluation Engagement Mechanism: Determine whether the organization has a process for identifying and prioritizing external entities or communities based on orchestration needs (e.g., cloud platform integration risks, third-party service dependencies). Information Flow: Confirm that key insights gained through external participation are captured and distributed internally (e.g., through working group summaries, process updates, or governance briefings).

4. Implementation Validation Evidence of Participation: Review records such as event logs, working group minutes, membership confirmations, or shared summaries to validate ongoing interaction with relevant external organizations. Sample Group Validation: Select a sample of groups (e.g., CNCF, CSA working groups, MLOps consortiums, cloud orchestration security task forces) and verify that their relevance to orchestration services is established and that engagement supports governance objectives.

GRC-09: Acceptable Use of the AI Service

Control Specification

Define, document and enforce policies and procedures on the acceptable use of AI services offered by the organization. Ensure effectiveness by continuous risk assessments, reviews and human oversight.

Auditing Guidelines for Orchestrated Service Providers (OSP)

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 orchestration services and users subject to these guidelines.

3. Verify that the AI Acceptable Use Policy clearly defines the acceptable and prohibited use of the orchestration services, with respect to AI systems and use cases (i.e. prohibiting unacceptable AI use cases within the service)

4. Verify, through interviews or otherwise, that the policy is communicated to Orchestration service users, 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 Orchestrated Service Providers (OSP)

1. Verify that an approved impact assessment process exists for AI models and ecosystem around it such as infrastructure, platforms, API integrations that are aligned with global AI standards.

2. Verify that the evaluation process is integrated within the AI ecosystem (e.g., design, development, deployment Integration and monitoring phases).

3. Verify the evaluation criteria and scoring mechanism exists and ensure scoring covers OSP specific risks 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 Orchestrated Service Providers (OSP)

1. Policy and Governance Framework: Confirm a documented policy exists for evaluating bias and fairness across hosted models and AI services, aligned with global standards and customer obligations.

2. Inclusive Service Design: Ensure datasets, prebuilt models, and APIs are developed or selected with consideration for demographic and regional diversity.

3. Fairness Controls in Platform Offerings: Verify the availability of platform features (e.g., bias mitigation options, fairness constraints) for customers deploying models through the OSP.

4. Monitoring and Detection Tools: Confirm that tools and APIs are provided for detecting and addressing bias in both OSP-hosted and customer-deployed models.

5. Transparency and Communication: Ensure fairness risks, limitations, and best practices are documented in service documentation, model cards, and customer guidance materials.

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

1. Verify that OSP has an ethics committee consists of a diverse set of stakeholders.

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

3. Verify that there are clear understanding of their role and have knowledge to contribute/guide.

4. Verify that there is established standards for decision making and approvals.

5. Verify that no individual committee member has a conflict of interest with the AI applications under review.

GRC-13: Explainability Requirement

Control Specification

Establish, document, and communicate the degree of explainability needed for the AI Services.

Auditing Guidelines for Orchestrated Service Providers (OSP)

1. Verify that the Orchestrated Service Provider (OSP) has clearly defined explainability requirements that align with applicable compliance, regulatory, or ethical obligations.

2. Verify that the OSP prioritizes explainability based on risk levels and use cases, ensuring alignment with customer requirements and potential consequences of decision errors.

3. Verify that the OSP maintains consistent and transparent communication with all stakeholders—including customers, integrated service providers, and internal teams—regarding explainability standards and responsibilities.

4. Verify that the OSP has a documented framework for selecting, integrating, or substituting AI components based on explainability factors outlined in its requirements.

5. Verify that the OSP ensures transparency, enabling customers to understand explainability expectations and how decisions are made across the full AI pipeline.

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

1. Verify that explainability requirements are defined for each orchestrated component, aligned with regulatory, ethical, and compliance requirements

2. Verify that the OSP has established processes and frameworks to evaluate the explainability of all integrated AI services

3. Verify that limitations (e.g., inherited from upstream models) and exceptions (e.g., low-risk model outputs) are clearly identified, documented, and communicated to stakeholders.

4. Ensure that the degree of explainability is assessed and documented for the overall orchestrated services, including dependencies across multiple AI components.

5. Verify that the explanations generated at each stage of the orchestration are interpretable and usable by non-technical stakeholders, including business users.

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

1. Verify that the Orchestrated Services Provider (OSP) 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’ lifecycle (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 Orchestrated Service Providers (OSP)

1. Policy Documentation and Approval: Verify that the OSP has a documented, approved background screening policy that applies to all employees, contractors, and third parties, proportionate to risk and access level. Confirm the policy explicitly applies to personnel managing the orchestration platform and accessing multi‑tenant data flows or cross‑service credentials.

2. Defined Criteria: Verify that the policy defines consistent criteria: criminal records, employment history, education, professional licenses, and credit history (if relevant).

3. Transparency and Consent: Verify that the policy is communicated to applicants clearly and that written consent is obtained, respecting privacy and fairness principles and applicable laws.

4. Use of Providers: Verify that the OSP uses reputable, legally compliant background check providers.

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 is securely stored, protected, and handled in compliance with data protection laws.

7. Contractual Accountability: Confirm that the OSP includes contractual provisions requiring upstream and downstream partners to conduct appropriate background checks on their personnel who interact with the orchestration platform or data.

8. Review and Update: Verify that the background screening policy is reviewed and updated at least annually or after significant changes.

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

1. Policy Establishment and Documentation: Verify that the OSP has established and formally documented an Acceptable Use Policy (AUP) that governs the use of orchestration platform(s) and their components, APIs and integration points, and multi‑tenant resources and shared services.

2. Policy Communication and Acknowledgement: Confirm that the AUP is communicated to all internal personnel, contractors, and relevant customers or tenants, and acknowledgements are recorded. Ensure external parties consuming the OSP’s orchestration platform have access to applicable AUP provisions.

3. Content of the AUP: Verify the AUP explicitly defines acceptable and prohibited actions for using orchestration services, APIs, and integrated services; prohibited activities that could negatively impact stability of the multi‑tenant environment; security of orchestration workflows; compliance with SLAs or regulatory obligations; as well as specific examples, such as: resource exhaustion through unauthorized scripts, circumventing orchestration security controls, unauthorized access to other tenants’ resources, and consequences for violations.

4. Monitoring and Enforcement: Confirm that monitoring mechanisms (e.g., logs, alerts, anomaly detection) are in place to identify violations of orchestration platform AUP provisions. Verify that procedures for investigating and enforcing consequences of violations are documented and implemented.

5. Periodic Review and Maintenance: Verify that the AUP is reviewed and updated at least annually or following significant changes in services, technologies, SLAs, or regulations. Confirm that version history and evidence of updates are retained.

6. Stakeholder Feedback and Continuous Improvement: Check whether feedback from tenants, internal teams, or auditors is collected and incorporated into periodic AUP updates to reflect operational realities and emerging risks.

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

1. Confirm that the AI Orchestrator Service Provider has a documented and implemented policy requiring that confidential model-related data, such as orchestration metadata, deployment configurations, routing logic, prompt logs, model outputs, or customer-specific tuning parameters are not visible in unattended workspaces (e.g., admin consoles, orchestration dashboards, cloud terminals).

2. Ensure the policy is communicated to all personnel involved in orchestrator operations, including platform engineers, ML operations teams, customer success engineers, and DevOps staff managing model deployment pipelines and runtime environments.

3. Review incident logs or security reports for any breaches involving unattended exposure of sensitive orchestration data, such as open terminals showing customer-specific model routing or logs containing sensitive inference data.

4. Confirm that the policy is reviewed and updated at least annually, especially in response to changes in orchestration architecture (e.g., new multi-tenant deployment models), evolving regulatory requirements (e.g., EU AI Act, ISO/IEC 42001), or updates to customer SLAs or data handling agreements.

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

1. Verify the OSP’s remote work policy enforces strict access controls for personnel managing the orchestration platform from remote locations.

2. Check that the policy requires secure network connections and prohibits the use of personal devices for administrative tasks.

3. Verify if the Remote and Home Working Policy and associated procedures are reviewed and updated at least annually or upon significant changes in legal or regulatory requirements, information security or operational risk, business or workforce model, technology controls, or assurance and audit expectations.

HRS-05: Asset returns

Control Specification

Establish and document procedures for the return of organization-owned assets by terminated employees, contractors and third parties.

Auditing Guidelines for Orchestrated Service Providers (OSP)

1. Verify the OSP’s offboarding process includes the return of all assets and the immediate revocation of access to the orchestration platform, cloud environments, and all integrated service credentials.

2. Review a sample of recent termination records to confirm compliance.

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

1. Verify the OSP’s policies for employment changes ensure that access to the orchestration platform, tenant configurations, and all upstream/downstream service credentials is revoked or transferred in a timely manner.

2. Review role change procedures to ensure the principle of least privilege is maintained.

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

1. Verify the OSP’s process requires new employees to sign an employment agreement covering their responsibilities for protecting the orchestration platform and tenant data before they receive any system access.

2. Check for signed agreements in employee files.

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

1. Review the OSP’s employment agreement to ensure it includes provisions requiring employees to comply with policies on multi-tenant security, data segregation, and the protection of the orchestration platform’s integrity.

2. Check for clauses related to confidentiality of customer data.

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

1. Verify that the OSP’s role definitions clearly separate duties for platform administration, service integration, security and privacy monitoring within the orchestrated environment.

2. Confirm that responsibilities for managing tenant security, privacy controls, and data flows are explicitly documented.

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

1. Assess whether the AI Orchestrator Service Provider (OSP) has identified and documented its non-disclosure and confidentiality requirements, with specific attention to protection of orchestrated AI workflows, models, training data, and prompt engineering logic; confidential handling of customer data, orchestration metadata, and intellectual property; third-party integrations, access controls, and contractual confidentiality obligations. Determine whether these non-disclosure and confidentiality agreements are reviewed at planned intervals, ensuring they align with internal policies and applicable regulations, reflect changes in technology, threat landscape, or business operations, and are updated and re-approved as necessary.

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

1. Verify the OSP’s training program covers the security of cloud-native environments, container security, and the specific risks of managing a multi-tenant orchestration platform.

2. Confirm that training includes procedures for handling incidents that span multiple services.

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

1. Confirm that personnel with access to sensitive orchestration data (e.g., model routing logic, API keys, system logs, prompt metadata) receive security training. For example, platform engineers managing model pipelines must complete secure access and data handling training before working in production environments.

2. Check for documented training policies and access-role mappings, such as policies requiring DevOps and orchestration engineers to complete annual security refreshers before being granted elevated permissions.

3. Verify that training is completed and regularly updated to reflect evolving AI orchestration risks for instance topics like prompt leakage, model misuse detection, and secure API integration.

4. Ensure training is tailored to specific roles (e.g., orchestration engineers, platform operators, ML infrastructure teams). For example, DevOps staff receiving secure deployment training, while workflow designers focus on prompt sanitization and model selection risks.

5. Interview staff to confirm awareness of responsibilities and recent updates. For example,ask a platform operator how they handle sensitive logs and whether they’re aware of the latest workspace security protocols.

6. Review how updates are communicated, such as through internal alerts, engineering briefings, or monthly platform governance bulletins that highlight changes in orchestration security practices and link to updated training modules.

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

1. Review how the Orchestrator Service Provider (OSP) identifies and updates applicable AI-related legal, statutory, and regulatory obligations (e.g., ISO 42001, EU AI Act, U.S. state-level AI laws).

2. Collect evidence of documented processes, legal/compliance reviews, and involvement of relevant stakeholders (e.g., AI governance, legal, risk teams).

3. Interview staff (e.g., ML engineers, platform operators) 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 Orchestrated Service Providers (OSP)

1. Verify the orchestration service provider (OSP) has an approved AI training policy aligned with orchestration design, deployment, and client support (e.g., safe model chaining and third-party integration).

2. Check that the training program defines role-based paths (e.g., engineers on secure pipelines, architects on ethical use, support on workflow monitoring).

3. Ensure training is accessible and communicated through onboarding, portals, or team sessions.

4. Review participation records to confirm staff receive training relevant to their orchestration roles.

5. Evaluate effectiveness through assessments or feedback, and confirm updates follow incidents or audits.

6. Confirm training content is regularly updated to reflect new orchestration features, regulations, or model integrations.

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

1. Verify that the orchestration provider maintains a documented Acceptable Use Policy (AUP) for AI orchestration workflows, approved by governance bodies (e.g., prohibiting chaining models to automate harmful tasks like synthetic identity creation or bypassing moderation filters).

2. Confirm the AUP is accessible to all relevant staff (e.g., orchestration engineers, platform teams, customer support) and clearly outlines acceptable orchestration practices (e.g., restricting routing of sensitive data through unverified third-party models).

3. Confirm that the policy is communicated through onboarding, training, and regular updates (e.g., training solution architects on secure orchestration patterns and enabling customer success teams to guide clients on compliant AI pipeline design).

4. Assess enforcement mechanisms such as orchestration logs, usage audits, and automated alerts (e.g., detecting misuse like chaining models to generate and distribute misinformation, and confirming consistent enforcement actions).

5. Confirm the policy is reviewed and updated regularly based on evolving AI capabilities, regulations, and customer use cases (e.g., when integrating new foundation models or enabling cross-region orchestration 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 Orchestrated Service Providers (OSP)

1. Verify that IAM policies are tailored to multi-tenant orchestration platforms and include tenant-level access segregation.

2. Confirm audit trails exist showing IAM policy dissemination to orchestration support staff and DevOps personnel.

3. Ensure periodic policy reviews are triggered by changes to orchestration frameworks or deployment boundaries.

4. Validate that automated access provisioning and deprovisioning workflows are governed by the IAM policy.

5. Check that access policies cover APIs and automation scripts used to orchestrate AI services

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

1. Verify the Orchestrated Service Provider (OSP) has established, documented, approved, and communicated policies governing authentication credentials across orchestration platforms, dashboards, pipelines, and integrated services, and confirm annual or event-driven review.

2. Confirm credential policies apply consistently to human and non-human identities within orchestration workflows.

3. Verify MFA enforcement for privileged orchestration access and confirm support for conditional or risk-based authentication mechanisms.

4. Confirm lifecycle management controls exist for service account credentials, automation tokens, and pipeline secrets, including rotation and revocation procedures.

5. .Verify secure storage and transmission of authentication credentials across orchestrated components and integrations.

6. Confirm periodic compliance assessments and monitoring are performed to evaluate enforcement of credential management controls.

IAM-03: Identity Inventory

Control Specification

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

Auditing Guidelines for Orchestrated Service Providers (OSP)

1. Review the inventory of identities accessing orchestration platforms (e.g., CI/CD, deployment pipelines).

2. Confirm automated tooling is in place to update identity inventories in real-time.

3. Validate controls to detect duplicated or conflicting identity entries across integrated services.

4. Verify periodic reconciliation between the identity inventory and the access control system.

5. Assess whether metadata (e.g., creation time, source system, assigned roles) is captured per identity.

6. Confirm the inventory includes system accounts used in orchestrated workflows.

IAM-04: Separation of Duties

Control Specification

Employ the separation of duties principle when implementing information system access.

Auditing Guidelines for Orchestrated Service Providers (OSP)

1. Review OSP’s role-mapping documentation to verify non-overlapping critical access roles.

2. Verify SoD policy alignment across orchestrated services and integrated components.

3. Confirm automation controls for detecting and alerting on SoD violations.

4. Check if operational runbooks define ownership and segregation of key operational functions.

5. Validate periodic review processes of conflicting role assignments.

6. Confirm audit logs capture privilege escalation attempts that breach SoD.

IAM-05: Least Privilege

Control Specification

Employ the least privilege principle when implementing information system access.

Auditing Guidelines for Orchestrated Service Providers (OSP)

1.Confirm that orchestration logic enforces least privilege for API calls and workflows.

1. Review identity federation policies to ensure minimal access inheritance across services.

2. Validate RBAC/ABAC configurations within the orchestration framework.

3. Assess whether admin accounts are scoped only to essential operational tasks.

4. Verify logs include actions taken by roles with elevated privileges.

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

1. Verify orchestration tooling provisions access dynamically and securely.

2. Confirm integration with IAM systems ensures consistent access policies across services.

3. Assess provisioning delays or failures and their impact on user roles.

4. Review logs and audit trails related to access assignments.

5. Confirm onboarding/offboarding processes are standardized across services.

IAM-07: Access Changes and Revocation

Control Specification

De-provision or modify identity access in a timely manner.

Auditing Guidelines for Orchestrated Service Providers (OSP)

1. Validate orchestration platform supports automated access revocation.

2. Review scripts or policies that revoke access across distributed service layers.

3. Check whether revocations sync with directory services (e.g., LDAP, AD).

4. Confirm logs show comprehensive coverage of de-provisioning activities.

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

1. Confirm that the OSP maintains a schedule for reviewing access rights across orchestration platforms.

2. Verify that service accounts and inter-service permissions are reviewed separately.

3. Check evidence of review results and adjustments made to access controls.

4. Validate that high-privilege access is subject to heightened review frequency.

5. Ensure cross-team participation in access reviews for collaborative services.

6. Confirm that access reviews are aligned with changes in orchestration architecture.

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

1. Verify segregation of orchestration admin roles from standard operators.

2. Confirm automated deployment agents do not hold privileged human-level roles.

3. Validate access logs for mixed-role usage in a single session.

4. Ensure documentation prohibits shared accounts for elevated roles.

5. Check that temporary elevated roles expire automatically or trigger alerts.

6. Confirm role definitions map cleanly to orchestration tasks and functions.

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

1. Verify privileged access to orchestration tools is governed by formal approval workflows.

2. Confirm that privilege escalation scripts or backdoors are disallowed.

3. Review detailed audit logs of privileged actions (e.g., container restarts, node changes).

4. Ensure privilege boundaries are maintained between CI/CD pipelines and production environments.

5. Check whether role assignments are aligned with task-specific scopes.

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

1. Ensure a risk-based approval workflow exists for assigning privileged roles in orchestration layers.

2. Verify the criteria used to define high-risk roles requiring elevated access.

3. Confirm records show customer-aligned roles receive stakeholder visibility or sign-off.

4. Check for audit logs capturing all authorization approvals.

5. Confirm mechanisms are in place for reviewing assigned roles periodically.

6. Review role mapping to underlying services and confirm justification for each.

7. Ensure policies are enforced consistently across services and domains.

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

1. Confirm orchestration components log events with traceable user or service IDs.

2. Validate that each operational activity can be mapped to a unique individual or role.

3. Ensure automation scripts or bots have unique service accounts.

4. Check logs include accurate user attribution for provisioning or scaling actions.

5. Verify separation between human and system identities is maintained and enforced.

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

1. Verify all service orchestration components (e.g., workflow engines) use strong, authenticated service identities.

2. Check that API calls between orchestrated services are secured with mutual TLS or equivalent.

3. Ensure automated mechanisms rotate and manage authentication credentials for orchestrated components.

4. Confirm monitoring for anomalies or failed authentication attempts across orchestrated services.

5. Verify privileged orchestration actions require MFA or time-bound access tokens.

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

1. Verify container orchestration tools securely mount secrets using native secrets managers.

2. Confirm secrets are injected at runtime and not stored in plaintext, with any temporary storage encrypted and access-controlled. (“never stored on disk” technically may invalidate compliant encrypted storage mechanisms)

3. Validate use of one-time passwords or short-lived tokens for service-to-service communication.

4. Ensure secrets access is governed by RBAC and usage scopes.

5. Check that secrets used in orchestration pipelines are rotated at a defined minimum frequency or based on documented risk-based rotation schedules.

6. Confirm secure retrieval and expiration of secrets through CI/CD systems.

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

1. Confirm orchestrated workflows implement access controls for all pipeline stages.

2. Check that access to shared artifacts (e.g., models, logs) is governed by scoped permissions.

3. Validate systems restrict access to configuration files and credentials.

4. Verify logging of access decisions within the orchestration layer.

5. Ensure that temporary or elevated access is reviewed and revoked automatically.

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

1. Validate policy enforcement for knowledge artifacts shared across orchestrated pipelines and services.

2. Ensure controls restrict access to orchestration metadata, DAGs, and runtime logs based on “need-to-know.”

3. Confirm isolation between tenant environments in multi-tenant AI pipelines.

4. Check for enforcement of access boundaries across integrated service endpoints and APIs.

5. Verify periodic review and de-provisioning of access for ephemeral compute roles.

6. Review access granularity applied to orchestrated AI workloads and intermediate model results.

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

1. Validate controls that prevent downstream output manipulation without special approval.

2. Confirm secure APIs or service connectors restrict write-back or override permissions.

3. Check traceability of modified outputs to originating workflows or user identity.

4. Verify documentation exists for exception handling when output transformations are necessary.

5. Confirm safeguards are in place to prevent suppression or alteration of alerts from AI pipelines.

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

1. Confirm orchestration tools support identity-aware pipelines that respect consent revocation.

2. Validate that identity-token exchange and mapping components comply with the customer’s privacy model.

3. Verify mechanisms exist to anonymize or redact user identifiers post-revocation.

4. Check consent-aware routing policies for triggering alternate processing or opting out.

5. Ensure audit trails are available for consent changes across service orchestrations.

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

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 OSP’s organization.

3. Examine evidence of a regular review and update cycle, ensuring the policies and procedures are evaluated and updated.

4. Verify that the OSP ensures interoperability and portability controls are applied across all orchestrated services, and conducts due diligence on providers whose services are integrated into the orchestration layer.

5. Verify that the policies are effectively communicated to relevant stakeholders, including internal personnel and any external partners or service customers impacted by these controls.

6. Verify that the review and update of the interoperability and portability policies and procedures occur at least annually, and that evidence of review (e.g., change logs, approvals) is retained.

IPY-02: Application Interface Availability

Control Specification

Provide application interface(s) to service customers so that they programmatically retrieve their data to enable interoperability and portability.

Auditing Guidelines for Orchestrated Service Providers (OSP)

1. Examine the documentation provided by the Orchestrated Service Provider (OSP) detailing the application interfaces that enable AI service customers to programmatically retrieve their data.

2. Confirm that the application interfaces are designed to be highly available and performant. This may involve reviewing Service Level Agreements (SLAs) to ensure the interfaces meet expected performance and availability thresholds.

3. Investigate whether the application interfaces have appropriate security measures in place to protect service customer data during transmission. This includes verifying the implementation of encryption protocols, authentication processes, and access controls aligned with industry best practices and relevant compliance requirements.

4. Verify that the OSP provides adequate support and resources to enable service customers to effectively use the interface for data retrieval. This includes reviewing the availability of user guides, API documentation, technical support channels, and any training materials. Assess that there are feedback mechanisms for service customers to report issues or request improvements.

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

1. Review the Interoperability and Portability Policy and procedures to ensure they adequately cover necessary aspects related to the secure management, import, and export of data including across containerized environments and orchestration platforms like Kubernetes.

2. Validate the inclusion of data types explicitly covered under the policy, like LLM training data, user interaction logs, and model weights.

3. Verify the policy lists specific, secure network protocols used within the organization with sufficient detail and context of where each protocol is used.

4. Through interviews or documentation review, ensure the policy has been communicated to all relevant users, internal personnel, and external stakeholders.

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

1. Examine contractual agreements between the OSP and its service customers, providers to ensure that the agreements explicitly detail data portability provisions (e.g., Article 20 of the EU GDPR (right to data portability), California Consumer Privacy Act (CCPA) and CPRA provisions on data access and transfer, OECD privacy guidelines on individual participation and data mobility).

2. Examine contract clauses and technical documentation to verify that the data format specified is accessible, common, and supports interoperability. Confirm that the format facilitates easy data migration without significant transformation (e.g., ISO/IEC 19944 for cloud services and data flow across devices and cloud services; use of CSV, JSON, XML as common, machine-readable formats; data on the Web Best Practices (W3C)).

3. Review policy documentation to confirm that data retention periods are clearly defined and align with regulatory requirements and industry standards (e.g., ISO/IEC 27040 for storage security, including retention policies, NIST SP 800-88 Rev. 1 for media sanitization guidelines, HIPAA for healthcare-related data).

4. Verify through process documentation, technical controls, and evidence of practice that data is irreversibly deleted after the retention period lapses (e.g., NIST SP 800-88 Rev. 1 for guidelines on data destruction, ISO/IEC 27001:2022 (control 8.10 on data deletion and disposal), secure erasure tools).

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

1. Examine Orchestrated Service Providers (OSP) policies and procedures that defines the scope, objectives, roles, and responsibilities for securing orchestration of the models and AI technology infrastructure and virtualization environments.

2. Verify the Policies and Procedures ensure third-party (e.g., MP, AP, CSP) reviews and controls are place and considered in the OSP 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 orchestration operational effectiveness and compliance.

6. Verify that security policies and procedures are regularly reviewed and updated to address emerging threats, vulnerabilities, and evolving business needs, ensuring clear documentation of changes and approvals exists.

I&S-02: Capacity and Resource Planning

Control Specification

Plan and monitor the availability, quality, and adequate capacity of resources in order to deliver the required system performance as determined by the business.

Auditing Guidelines for Orchestrated Service Providers (OSP)

1. Examine the Orchestrated Service Provider’s capacity and resource planning document that explicitly addresses third-party services and AI resources 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 Orchestrated Service Providers (OSP)

1. Examine documented network policy and procedures to ensure they are aligned with AI-driven business requirements.

2. Verify network segmentation to enforce isolation between orchestrated workloads, security zones, and environments.

3. Determine network access controls, authentication protocols, and encryption mechanisms to secure communication between orchestrated environments, services, and applications.

4. Verify continuous monitoring of orchestrated network traffic, logging, and anomaly detection for unauthorized or unusual activities.

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

1. Examine the Orchestrated Service Providers’ documented policies and security baselines to ensure alignment with AI-driven orchestration requirements and industry best practices.

2. Determine if appropriate technical controls are in place to enforce and verify system hardening for orchestrated environments (e.g., CIS benchmarks for Docker, CIS benchmarks for Kubernetes)

3. Verify regular security assessments against established security baselines, ensuring prompt remediation of identified vulnerabilities.

4. Verify an annual review of hardening configurations for orchestrated platforms, ensuring documented results are reviewed and approved.

5. Verify if emerging threats are monitored and hardening procedures are updated systematically with documented approvals.

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

1. Examine Orchestrated Service Provider (OSP) policies and procedures ensuring separation of production and non-production orchestration environments to reduce the risk of sensitive production data exposure.

2. Verify role-based and least-privilege access controls enforce separation between production and non-production orchestration environments, restricting production access to authorized personnel only.

3. Verify procedures ensuring production data is not used in non-production environments unless sanitized or otherwise protected before any authorized use.

4. Verify formal promotion and deployment processes between non-production and production orchestration environments prevent unauthorized data transfer and preserve environment separation, including documented approvals and integrity validation.

5. Verify monitoring and logging across orchestration components 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 mitigate emerging security risks and evolving operational requirements.

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

1. Verify documented policies and procedures define how segmentation and segregation are implemented within orchestration platforms to enforce service customer (tenant) access boundaries across workflows and integrated services.

2. Verify segmentation mechanisms within orchestration environments (e.g., workflow isolation, service-to-service boundaries, API mediation) are effectively implemented to prevent unauthorized cross-tenant access or data movement.

3. Verify access controls governing orchestration components, pipelines, and service integrations restrict identities and permissions to their assigned service customer (tenant) context, consistent with segmentation policies.

4. Evaluate whether segmentation and isolation controls within orchestration workflows are periodically tested or validated to confirm that service customer (tenant) boundaries cannot be bypassed through orchestration logic, integrations, or misrouting.

5. Confirm incident response procedures address failures of service customer (tenant) isolation within orchestrated services, including cross-tenant access, workflow compromise, or data exposure scenarios.

6. Verify logs and monitoring across orchestration platforms are configured to detect and alert on unauthorized cross-tenant activity, including anomalous workflow execution or service-to-service communication spanning tenant boundaries.

7. Confirm relevant personnel receive training on orchestration-specific segmentation responsibilities, including risks associated with configuration errors or integration changes that could impact service customer (tenant) 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 Orchestrated Service Providers (OSP)

1. Verify the Orchestrated Service Provider (OSP) documented migration procedures explicitly require secure, encrypted communication channels (e.g., across instances, AI models, AI deployments).

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

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., threat models, secure design, risk assessments, and mitigations).

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

1. Verify the Orchestrated Service Provider (OSP) documented procedures clearly define network defense mechanisms.

2. Confirm regular implementation and evaluation of defense strategies (e.g., DevSecOps controls, monitoring, alerting, DS/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 Orchestrated Service Providers (OSP)

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. Confirm the orchestration layer logs control plane and data plane activities, including resource provisioning and job execution.

   2. Validate enforcement of log policies across multi-tenant services and shared infrastructure.

   3. Verify the segregation of logs per tenant or service instance to support traceability and forensics.

   4. Check that monitoring systems are configured to flag anomalies in workload orchestration and AI lifecycle events.

   5. Ensure logs from orchestrated services are included in the incident response workflow.

   6. Confirm periodic review of log completeness and alignment with orchestration policies.

   7. Verify secure access control mechanisms to view and query orchestration-related 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 Orchestrated Service Providers (OSP)

1. Inquiring with Control Owners

   1. Conduct interviews with personnel responsible for defining, implementing, and evaluating audit log security and retention processes for AI orchestration platforms and integration services to understand their roles in protecting multi-tenant workflow logs and API access data. Verify their understanding of technical measures implemented to ensure audit logs from AI pipeline orchestration, API gateways, and enterprise integrations remain secure and are retained according to organizational requirements.

2. Inspecting Records and Documents

   1. Verify that orchestration workflow logs, API access logs, and multi-tenant service logs are stored in write-once or append-only formats where feasible.

   2. Confirm that logs containing customer API keys, workflow configurations, and cross-service communications are protected using encryption at rest and in transit.

   3. Ensure access to orchestration logs is restricted to authorized DevOps and platform personnel only, with RBAC or IAM controls maintaining tenant isolation.

   4. Validate mechanisms to detect and alert on unauthorized access attempts or changes to logs containing customer workflow data and service configurations.

   5. Check that orchestration platform log protection is periodically tested through internal audits, including validation of tenant data segregation.

   6. Confirm that log retention for orchestration services aligns with customer SLA requirements, compliance standards, and business policy requirements.

   7. Verify that controls are in place to prevent cross-tenant access to audit logs and maintain service isolation.

   8. Review documented processes and procedures for orchestration service audit log security, including incident response and customer notification procedures.

   9. Validate that backup and recovery procedures exist for orchestration audit logs to ensure service continuity and customer data protection.

   10. Confirm that log disposal procedures are secure and documented for orchestration logs when retention periods expire, including customer data purging requirements.

   11. Validate that orchestration logs (e.g., scheduler, job controller) are protected against unauthorized modifications.

   12. Confirm that tamper-evident logging mechanisms are implemented for shared multi-tenant environments.

   13. Ensure that logs are replicated securely to centralized logging stores with strict write controls.

   14. Check that controls are in place to segregate log access across tenants and workloads.

   15. Verify periodic assessments of log integrity mechanisms as part of the platform audit process.

   16. Confirm procedures to promptly detect and respond to attempts to disable or corrupt logs.

   17. Validate logging protection policies apply consistently across all orchestrated services and microservices.

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

1. Inquiring with Control Owners: Conduct interviews with personnel responsible for identifying, monitoring, and alerting on security-related events within AI orchestration platforms, API gateways, and service integration layers. Determine how security events are defined, classified, and mapped to alerting thresholds, and confirm understanding of stakeholder notification procedures for orchestration-related security incidents (e.g., unauthorized workflow modification, API abuse, cross-tenant access attempts).

2. Inspecting Records and Documents

   1. Verify documented procedures define security-related events to be monitored within orchestration components, including workflows, API gateways, service-to-service communications, and tenant boundaries.

   2. Verify monitoring mechanisms are implemented to detect defined security-related events across orchestration components, including workflows, API gateways, service-to-service communications, and tenant boundaries (e.g., unauthorized workflow modification, API abuse, credential misuse, cross-tenant access attempts, or service mesh tampering).

   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 are met.

   5. Verify that alert notifications are directed to appropriate responsible stakeholders and that roles for triage and escalation are defined.

   6. Review evidence that security monitoring configurations and alert thresholds are periodically reviewed and updated as orchestration 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 Orchestrated Service Providers (OSP)

1. Conduct interviews with personnel responsible for managing orchestration platform audit log access controls and maintaining access records to understand their authorization processes for accessing workflow logs, API gateway logs, and multi-tenant service events. Verify their understanding of access restriction mechanisms and record-keeping requirements for all orchestration platform audit log access activities.

2. Inspecting Records and Documents

   1. Verify access to orchestration platform-generated audit logs (including workflow executions, API transactions, multi-tenant events, and security incidents) is restricted to authorized personnel.

   2. Ensure orchestration platform logging access is role-based and mapped to least privilege principles, maintaining tenant isolation and customer data protection.

   3. Confirm all orchestration platform log access events are themselves logged with timestamps, actor IDs, and specific tenant data accessed.

   4. Check for formal review processes of orchestration platform log access permissions, including customer data segregation requirements.

   5. Validate platform engineers and DevOps teams are not granted persistent access to customer-specific logs without approval and operational justification.

   6. Review incident records for unauthorized access to orchestration platform audit logs and follow-up actions taken.

   7. Confirm procedures are in place to revoke orchestration platform log access upon role changes or terminations.

   8. Examine documented access control policies and procedures for orchestration platform audit log systems, including multi-tenancy protections.

   9. Validate that orchestration platform access records are retained according to customer contracts and regulatory requirements.

   10. Review monitoring and alerting mechanisms for unauthorized or suspicious orchestration platform audit log access attempts.

   11. Verify access to orchestration platform logs is strictly controlled and reviewed regularly.

   12. Confirm automated enforcement of role-based restrictions for accessing orchestration audit logs.

   13. Check accountability measures such as user ID tagging and timestamping for all log access.

   14. Ensure logs from orchestration events (e.g., Kubernetes audit logs) are protected and access-monitored.

   15. Validate access reviews are conducted periodically for all orchestration log access roles.

   16. Review escalation procedures for violations related to orchestration log access.

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

1. Inquiring with Control Owners: Conduct interviews with personnel responsible for monitoring orchestration platform security audit logs to understand how anomalous workflow patterns and suspicious activity are identified, how baseline orchestration behavior is defined, and how detected anomalies are reviewed and acted upon in a timely manner.

2. Inspecting Records and Documents

   1. Verify security audit logs are generated and monitored for orchestration components, including workflow execution, API transactions, service mesh communications, and tenant activities.

   2. Verify correlation rules or detection mechanisms are implemented to identify suspicious or anomalous activity that deviates from defined baseline or expected orchestration patterns.

   3. Review documentation defining baseline orchestration behavior 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 orchestration architecture or threat conditions change.

LOG-06: Clock Synchronization

Control Specification

Use a reliable time source across all relevant information processing systems.

Auditing Guidelines for Orchestrated Service Providers (OSP)

1. Inquiring with Control Owners

   1. Conduct interviews with personnel responsible for managing time synchronization across orchestration platforms and workflow management systems to understand their implementation of reliable time sources for pipeline execution, API transactions, and multi-tenant service coordination. Verify their understanding of time synchronization requirements for orchestration components, workflow scheduling, and procedures for maintaining accurate timestamps across distributed AI service environments.

2. Inspecting Records and Documents

   1. Confirm orchestration platform systems handling workflow execution and API coordination use a centralized time source.

   2. Verify implementation of Network Time Protocol (NTP) or equivalent time synchronization protocols across orchestration infrastructure and service mesh components.

   3. Check synchronization logs to validate accurate timestamping across workflow executions, API transactions, and multi-tenant service activities.

   4. Assess whether unsynchronized orchestration systems trigger alerts or errors that could affect workflow coordination or service reliability.

   5. Verify clock drift thresholds are defined and monitored for orchestration platforms, API gateways, and distributed service components.

   6. Confirm the accuracy of timestamps in orchestration logs critical for workflow debugging and multi-tenant security investigations.

   7. Validate incident response records for orchestration issues reference consistent timestamps across distributed services and customer environments.

   8. Examine documentation of reliable time source configuration for orchestration platforms and backup time synchronization mechanisms.

   9. Review time synchronization policies covering orchestration services, API gateways, and multi-tenant workflow management systems.

   10. Validate that time source reliability is monitored for orchestration platforms and backup time sources are available to maintain service coordination.

   11. Confirm synchronization of all orchestration components (e.g., Kubernetes, CI/CD tools) to a trusted time source.

   12. Review procedures for clock drift correction in container orchestration environments.

   13. Validate infrastructure supports auditability across nodes with synchronized logs.

   14. Ensure time synchronization configurations are applied uniformly through automation scripts.

   15. Confirm alerts are configured for failures in time synchronization.

   16. Verify that scheduled jobs, logs, and events reflect the same time baseline.

   17. Validate documentation of time source configuration and maintenance processes.

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

1. Inquiring with Control Owners

   1. Conduct interviews with personnel responsible for establishing, documenting, and implementing logging scope for orchestration platform events and workflow metadata to understand their process for defining which AI pipeline and multi-tenant service events should be logged and their procedures for annual reviews. Verify their understanding of orchestration security threat environment changes that trigger scope updates and their implementation of documented logging requirements across API gateways, workflow engines, and service mesh components.

2. Inspecting Records and Documents

   1. Confirm documentation specifies which orchestration platform events must be logged (e.g., workflow execution, API transactions, tenant access, service configurations, pipeline deployments).

   2. Validate inclusion of both success and failure events in the orchestration logging scope, including successful workflow completions and failed service integrations.

   3. Ensure regular reviews of orchestration logging scope to capture evolving platform security threats such as workflow tampering, API abuse, and cross-tenant attacks.

   4. Check scope alignment with customer SLA requirements, multi-tenancy security standards, and platform service contractual obligations.

   5. Assess procedures for adjusting logging scope when deploying new orchestration features, API endpoints, or service integrations.

   6. Confirm stakeholder approval for the defined orchestration logging scope, including input from platform engineering teams, customer success managers, and compliance officers.

   7. Verify logs reflect real-world orchestration events as specified in scope documents, including workflow executions, API calls, and tenant activities.

   8. Examine evidence of annual orchestration logging scope reviews and documentation of any scope updates driven by new platform threats or customer requirements.

   9. Review procedures for monitoring and responding to orchestration threat environment changes that may require logging scope adjustments for emerging attack patterns.

   10. Validate that implementation of orchestration logging scope requirements is consistently applied across all API gateways, workflow engines, multi-tenant services, and integrated platforms.

   11. Confirm defined logging scope includes container orchestration events and resource changes.

   12. Validate logging of API calls and inter-service communication events.

   13. Review configurations for infrastructure components generating logs.

   14. Check whether automated workflows document and log deployment changes.

   15. Ensure logs are collected from all active orchestration components.

   16. Assess regular updates to logging scope based on threat modeling or service evolution.

   17. Confirm that changes to the defined logging scope are documented with version history, formal approvals, and traceability to relevant regulatory requirements or compliance obligations.

LOG-08: Audit Logs Sanitization

Control Specification

Define, implement and evaluate technical measures for service customers to detect and scrub or tokenize sensitive data from logs to prevent unauthorized exposure, as per applicable laws and regulations.

Auditing Guidelines for Orchestrated Service Providers (OSP)

1. Inquiring with Control Owners

Conduct interviews with personnel responsible for defining, implementing, and evaluating the technical measures that enable service customers to detect, scrub, or tokenize sensitive data from applicable, scoped AI logs, which helps customers prevent unauthorized exposure in accordance with applicable laws and regulations. Verify their understanding of this customer responsibility, and its applicability for the scoped product or service within the workflow, and across diverse infrastructure, the Orchestrated Service Provider support

1. Review product or service baseline, or agreement to verify that the customer can opt-in for this responsibility, within the workflow, and across diverse infrastructure, the Orchestrated Service Provider support, and based on the regulations that are applicable.

2. Verify that automated safeguards are in place according to the technical measures defined for the product or service within the workflow, across diverse infrastructure, the Orchestrated Service Provider support, 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.

3. For those customers who opt in, examine logs of the scoped product or services to verify that only allowed information exists within logs. Because 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 Orchestrated Service Providers (OSP)

1. Inquiring with Control Owners

   1. Conduct interviews with personnel responsible for generating audit records containing relevant orchestration platform security information to understand their processes for capturing, formatting, and maintaining security-related audit data across AI pipeline orchestration and multi-tenant service operations. Verify their understanding of what constitutes relevant orchestration security information and their procedures for ensuring audit records contain sufficient detail for platform security investigations, tenant isolation validation, and service integrity requirements.

2. Inspecting Records and Documents

   1. Verify orchestration platform logs capture event type, timestamp, actor, and source for all workflow executions, API transactions, and multi-tenant service activities.

   2. Confirm logs include identifiers for correlating orchestration actions across workflow components, API gateways, and tenant environments.

   3. Ensure structured formats (e.g., JSON, syslog) are used for consistency across orchestration platform logging systems.

   4. Check completeness of orchestration platform log records by sampling workflow execution trails, API transaction flows, and tenant activity patterns.

   5. Validate that custom orchestration events are logged where relevant (e.g., workflow tampering attempts, API abuse detection, cross-tenant boundary violations).

   6. Review orchestration platform audit logs for evidence of tampering or missing entries related to workflow executions and tenant activities.

   7. Examine orchestration platform audit records to ensure they contain relevant security information such as workflow access controls, API authentication events, tenant isolation activities, and service configuration changes.

   8. Validate that orchestration platform audit records include sufficient contextual information to support platform security investigations, tenant isolation verification, and service integrity analysis.

   9. Confirm that orchestration platform audit record generation covers all security-relevant events across API gateways, workflow engines, multi-tenant services, and integrated platforms.

   10. Review orchestration platform audit record retention and storage mechanisms to ensure platform security information remains available for customer SLA compliance and service integrity timeframes.

   11. Ensure orchestration platforms generate logs for scheduling, scaling, and health checks.

   12. Confirm logs contain metadata on containers, pods, and deployments.

   13. Validate events from infrastructure as code (IaC) are logged and attributed.

   14. Review completeness of logs during autoscaling or failover operations.

   15. Confirm proper tagging and correlation identifiers exist in generated logs.

   16. Check logs reflect accurate status of orchestrated workloads.

LOG-10: Audit Records Protection

Control Specification

Protect audit records from unauthorized access, modification, and deletion.

Auditing Guidelines for Orchestrated Service Providers (OSP)

1. Inquiring with Control Owners

   1. Conduct interviews with personnel responsible for protecting orchestration platform 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 orchestration platform 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 Orchestrated Service Providers (OSP)

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 orchestration platforms and multi-tenant services to understand their oversight processes for tenant data protection and platform security. Verify their understanding of monitoring controls for encryption of workflow data, internal reporting mechanisms for orchestration cryptographic operations, and procedures for maintaining ongoing oversight of key management for tenant isolation and service security.

2. Inspecting Records and Documents

   1. Confirm monitoring mechanisms are in place to detect encryption failures or unauthorized decryption attempts for orchestration platform data, tenant workflows, and API communications.

   2. Verify reports are generated on the use of encryption in orchestration platform data transmission, tenant data storage, and multi-service communication protection.

   3. Review documentation on how cryptographic keys are handled, rotated, and monitored for orchestration platform security, tenant data protection, and service isolation.

   4. Validate that orchestration platform teams receive alerts for deviations in encryption policy adherence affecting tenant security and platform integrity.

   5. Check integration with central SIEM tools for real-time visibility into orchestration platform cryptographic operations and tenant protection events.

   6. Ensure audit logs capture orchestration platform encryption-related events like certificate expiration, invalid key use, or tenant data encryption failures.

   7. Confirm documentation of encryption algorithms and configurations in use for orchestration platform operations, tenant data protection, and API security.

   8. Examine internal reporting processes for communicating orchestration platform cryptographic and key management findings to platform engineering and customer security teams.

   9. Review periodic assessment and reporting schedules for orchestration platform cryptographic policy compliance and tenant protection effectiveness.

   10. Validate that monitoring and reporting capabilities cover all aspects of orchestration platform cryptographic operations including tenant isolation, service security, and regulatory compliance.

   11. Verify orchestration environments log key management lifecycle events (e.g., creation, rotation, revocation).

   12. Confirm enforcement of encryption-in-transit between orchestrated containers and services.

   13. Review alerts generated on unauthorized access or tampering of encryption configurations.

   14. Validate centralized visibility into all orchestration-level cryptographic operations.

   15. Check that secrets managers used in orchestration are included in monitoring reports.

   16. Confirm regular audits are performed on encryption processes across orchestrated components.

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

1. Inquiring with Control Owners

   1. Conduct interviews with personnel responsible for logging and monitoring key lifecycle management events for orchestration platforms to understand their processes for capturing, analyzing, and reporting on cryptographic key usage for tenant data protection and service security. Verify their understanding of key lifecycle event logging requirements for orchestration operations, monitoring procedures for encryption keys protecting multi-tenant services, and reporting capabilities that enable auditing and compliance oversight of cryptographic key management activities in AI pipeline orchestration.

2. Inspecting Records and Documents

   1. Verify that cryptographic key usage for orchestration platform data encryption, tenant isolation, and API security is logged by the platform management systems.

   2. Confirm logs include timestamped records of key creation, use, rotation, and destruction for orchestration platform operations, tenant data protection, and service communication security.

   3. Ensure visibility into key usage by different orchestration platform components, API gateway services, and multi-tenant workflow systems.

   4. Validate alerts are generated on suspicious or unauthorized key operations affecting orchestration platform security or tenant data protection.

   5. Check alignment with internal policy for lifecycle monitoring of keys used within orchestration platforms for tenant isolation and service integrity protection.

   6. Review SIEM or monitoring tool integrations that centralize and analyze orchestration platform key-related activities and tenant protection events.

   7. Confirm audit trails exist for every critical key management operation supporting orchestration platform functionality and tenant data security.

   8. Examine reporting capabilities and procedures for generating orchestration platform key lifecycle management reports to support tenant compliance and platform security auditing requirements.

   9. Review log retention policies and practices to ensure orchestration platform key lifecycle event records are maintained for tenant protection and service integrity timeframes.

   10. Validate that key lifecycle monitoring covers all orchestration platform cryptographic operations including tenant data encryption, API security, and workflow backup protection activities.

   11. Confirm orchestration tools log all access to secrets, certificates, or encryption keys.

   12. Review container lifecycle logs for usage of environment-based key references.

   13. Verify secure and auditable key retrieval mechanisms in pipeline configurations.

   14. Check that key management events are integrated into centralized logging pipelines.

   15. Ensure privilege escalation leading to key access is also captured and flagged.

   16. Validate periodic reviews are performed on key access logs in the orchestration layer.

LOG-13: Access Control Logs

Control Specification

Monitor and log physical access using an auditable access control system.

Auditing Guidelines for Orchestrated Service Providers (OSP)

1. Inquiring with Control Owners

   1. Conduct interviews with personnel responsible for monitoring and logging physical access using auditable access control systems for orchestration platform infrastructure to understand their processes for tracking, recording, and reviewing physical access to facilities hosting multi-tenant AI services and orchestration platforms. Verify their understanding of access control system monitoring capabilities for orchestration environments, logging procedures for physical access to platform infrastructure and tenant service facilities, and audit trail requirements that ensure all physical access activities affecting platform security and tenant data protection are properly documented and reviewable.

2. Inspecting Records and Documents

   1. Verify physical access control systems are in place for all orchestration platform environments, including multi-tenant infrastructure, API gateway facilities, workflow management centers, and service integration environments.

   2. Check logging mechanisms capture physical access timestamps, user identity, and location for orchestration platform infrastructure and tenant service facilities.

   3. Confirm physical access logs are retained in accordance with tenant protection and service level agreement requirements for orchestration platform operations.

   4. Validate alerts are generated for unauthorized or after-hours physical access to orchestration platform infrastructure and tenant service facilities.

   5. Review role-based access controls to ensure only authorized platform personnel can retrieve physical access logs for orchestration environments.

   6. Confirm periodic audits assess physical access adherence across all orchestration platform facilities and tenant data protection areas.

   7. Examine whether physical access logs are integrated into centralized SIEM systems for correlation with orchestration platform security and tenant protection events.

   8. Verify encryption is applied to stored physical access logs for orchestration platform facilities.

   9. Review monitoring procedures and capabilities of the physical access control system to ensure real-time visibility into physical access events affecting orchestration platform infrastructure.

   10. Validate that the access control system provides comprehensive audit trails with tamper-evident logging for all physical access activities in orchestration platform and tenant service facilities.

   11. Examine backup and recovery procedures for orchestration platform physical access control system logs to ensure continuity of audit capabilities for tenant 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 Orchestrated Service Providers (OSP)

1. Inquiring with Control Owners

   1. Conduct interviews with personnel responsible for defining, implementing, and evaluating processes for reporting orchestration platform monitoring system anomalies and failures to understand their procedures for detecting, classifying, and immediately notifying accountable parties of platform issues affecting tenant services and workflow integrity. Verify their understanding of technical measures for orchestration platform anomaly detection, notification workflows for different platform failure types, and evaluation processes that ensure orchestration monitoring system reliability and timely escalation to responsible stakeholders including platform engineering teams and customer success managers.

2. Inspecting Records and Documents

   1. Verify orchestration platform systems are configured to detect logging anomalies such as dropped workflow events, API gateway failures, or tenant data format corruption affecting service reliability and tenant isolation.

   2. Check processes are in place for classifying orchestration platform failure severity and identifying responsible owners including platform engineering teams, customer success managers, and compliance officers.

   3. Validate orchestration platform failures trigger alert workflows in ticketing or incident response platforms with appropriate escalation to platform engineering and tenant support teams.

   4. Ensure fallback mechanisms exist when primary orchestration platform logging systems fail, including backup workflow monitoring and tenant activity tracking capabilities.

   5. Confirm logs of orchestration platform failure events are themselves collected and analyzed to understand impact on tenant services and platform reliability.

   6. Check that post-incident reviews incorporate root cause analysis for orchestration platform failures with focus on tenant impact and service level agreement compliance.

   7. Verify metrics are defined to track detection and resolution of orchestration platform anomalies including tenant service impact and platform availability measures.

   8. Examine immediate notification procedures for orchestration platform monitoring failures to ensure accountable parties including platform operations teams and customer success managers receive timely alerts.

   9. Review evaluation processes for assessing the effectiveness of orchestration platform anomaly reporting and failure notification procedures in maintaining tenant trust and service quality.

   10. Validate that technical measures include automated escalation mechanisms for orchestration platform monitoring failures when initial notifications are not acknowledged by responsible platform teams.

   11. Verify that documented processes exist for identifying, classifying, and reporting logging failures and anomalies, including assignment of accountability for detection, triage, and resolution.

   12. Ensure that failure and anomaly reports are consistently generated, reviewed, and retained, and that detection thresholds and alert criteria are clearly defined.

   13. Confirm that clear escalation procedures exist for handling significant anomalies, including predefined severity levels, responsible responders, and response timelines.

   14. Check that corrective actions are documented and tracked to resolution, and that any systemic issues identified during remediation are escalated for root cause analysis.

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

1. Inquiring with Control Owners

   1. Conduct interviews with personnel responsible for logging and monitoring all input events (content and metadata) to orchestrated AI services to understand their processes for capturing, storing, and analyzing workflow input data for auditing platform usage and reporting on service utilization across tenants. Verify their understanding of input event logging requirements for orchestration platforms, monitoring procedures for multi-tenant service patterns and workflow performance, and reporting capabilities that enable comprehensive auditing of orchestrated AI service interactions and platform analytics.

2. Inspecting Records and Documents

   1. Confirm input logging covers all orchestration platform endpoints including API gateways, workflow interfaces, tenant portals, and third-party service integrations.

   2. Verify logs capture tenant identity, service source, timestamp, workflow context, and input payload structure for orchestrated AI service requests.

   3. Check that logging does not capture sensitive tenant data unless explicitly required for service functionality and properly protected under tenant agreements.

   4. Validate logging covers both direct tenant inputs to orchestrated services and indirect inputs processed through workflow automation and service mesh communications.

   5. Confirm that orchestration platform logs are used to detect service abuse, workflow anomalies, or malformed requests affecting platform security and tenant isolation.

   6. Review retention settings to ensure orchestration platform input logs are stored in alignment with tenant agreements and service level requirements.

   7. Ensure orchestration platform input logs feed into usage analytics dashboards for service optimization and tenant experience monitoring.

   8. Verify access to orchestration platform input logs is role-restricted to authorized platform personnel and fully auditable for tenant data protection.

   9. Examine monitoring capabilities to ensure real-time visibility into orchestration platform usage patterns, service performance metrics, and tenant utilization trends.

   10. Validate that metadata logging includes comprehensive platform context such as workflow parameters, service configurations, tenant details, and performance metrics.

   11. Review reporting mechanisms to confirm they provide adequate audit trails for orchestration platform governance, tenant compliance, and service analytics.

   12. Confirm input logs are collected across orchestrated services feeding AI models.

   13. Validate logs include input event metadata such as origin service, pod/container ID, and routing path.

   14. Check mechanisms to correlate inputs to downstream inference or transformation pipelines.

   15. Ensure real-time logging is maintained even during autoscaling or failover.

   16. Verify integration with centralized SIEM or logging systems.

   17. Validate noise filtering is applied to reduce irrelevant or malformed input logs.

   18. Confirm that log anomalies trigger alerts and are reviewed periodically.

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

1. Inquiring with Control Owners

   1. Conduct interviews with personnel responsible for logging and monitoring all output events (content and metadata) from orchestrated AI services to understand their processes for capturing, storing, and analyzing workflow-generated outputs for auditing platform performance and reporting on service utilization patterns across tenants. Verify their understanding of output event logging requirements for orchestration platforms, monitoring procedures for service quality and tenant safety, and reporting capabilities that enable comprehensive auditing of orchestrated AI outputs and platform analytics.

2. Inspecting Records and Documents

   1. Verify logs capture AI service outputs returned to tenants through orchestration workflows or platform APIs.

   2. Check logs include confidence scores, service version, timestamp, tenant ID, and workflow context for orchestrated AI responses.

   3. Ensure auditability of orchestration platform outputs that were modified, filtered, or rejected by platform governance or tenant policies.

   4. Validate logs help detect service anomalies, policy violations, cross-tenant issues, or problematic AI responses affecting platform integrity.

   5. Confirm orchestration platform outputs are categorized by risk level, tenant classification, and service type for review prioritization and platform security.

   6. Ensure orchestration platform output logs are used to improve service quality, tenant experience, and platform optimization systems.

   7. Verify access to orchestration platform output logs is restricted to authorized platform personnel and properly encrypted for tenant data protection.

   8. Confirm orchestration platform output monitoring feeds into usage analytics for service optimization and tenant satisfaction insights.

   9. Examine reporting mechanisms for orchestration platform outputs to ensure they provide comprehensive audit trails for tenant compliance and platform governance oversight.

   10. Validate that metadata logging includes complete platform context such as workflow parameters, service configurations, tenant details, and performance quality metrics.

   11. Review orchestration platform output log retention policies to ensure compliance with tenant agreements and enable long-term auditing of service behavior and platform performance patterns.

   12. Validate all output responses passing through orchestration pipelines are logged.

   13. Confirm logs include routing path, service component ID, and output latency.

   14. Ensure logs allow correlation with input logs for full traceability.

   15. Review filtering mechanisms to redact PII or confidential data from logs.

   16. Check alerting rules flag abnormal output patterns (e.g., unusually long or empty outputs).

   17. Confirm output logs are available for testing rollback or regression.

   18. Verify logs are consistently replicated across clusters or zones.

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

Policy and Procedure Review: Review documented processes and procedures for training pipeline security related to the orchestrated services, covering relevant aspects such as data preprocessing (if applicable), training orchestration (if applicable), integration, use of datasets and pre-trained models (if applicable), and codebase security (if applicable). Ensure that these policies and procedures are formally approved.

Best Practices Adherence: Assess alignment with security best practices (e.g., OWASP Top 10), as applicable to the OSP’s role.

1. Implementation Verification: Audit implementation of relevant processes and procedures; this may include reviewing configurations of orchestration tools, auditing API security, and interviewing operations staff.

2. Regular Review and Update: Review evidence of regular reviews and updates to relevant security measures.

3. Coordination with MP and/or AP: Verify clear definition/documentation of responsibilities and assess communication/coordination effectiveness between the OSP, MP, and AP (if the AP is fine-tuning).

4. Data and Pre-trained Model Security (if applicable): Verify how datasets and pre-trained models are being used and secured by the OSP, if applicable to their role.

Not Applicable: If the OSP has no involvement with the training pipeline, document this as Not Applicable.

MDS-02: Model Artifact Scanning

Control Specification

Define, implement, and evaluate policies, procedures, and technical measures for the scanning of model artifacts for vulnerabilities and attacks, at each step of the service lifecycle and at each hand over point. Regularly review and update policies, procedures and technical measures to address model artifact scanning.

Auditing Guidelines for Orchestrated Service Providers (OSP)

1. Examine documented processes/procedures for periodic model artifact scanning, covering lifecycle stages where the OSP handles the model (e.g., deployment, orchestration, storage).

2. Verify documented process coverage.

3. Assess if scanning frequency aligns with risk appetite and best practices.

4. Confirm procedure and process approval

5. Audit implementation.

6. Verify appropriate scanning tool usage.

7. Inspect scan configurations.

8. Examine scan reports.

9. Confirm timely remediation or hand-off of vulnerabilities to the responsible party (MP or AP).

10. Assess communication/coordination effectiveness between OSP, MP, and AP.

11. Verify a documented process for secure model hand-over.

12. Check for evidence of regular process, procedure, and tool reviews/updates.

13. If the OSP is not involved in handling model artifacts, document this as not applicable.

MDS-03: Model Documentation

Control Specification

Define, implement, enforce, approve, document, communicate, maintain and evaluate processes and procedures for model documentation. Regularly review and update the model documentation.

Auditing Guidelines for Orchestrated Service Providers (OSP)

1. Review OSP processes for managing model documentation (e.g., Model Cards) provided by MPs or APs, focusing on storage, access control, and transmission.

2. Assess the technical measures implemented by the OSP to maintain the integrity of and control access to the stored model documentation.

3. Audit the communication and coordination mechanisms between the OSP, MP, and AP regarding the availability, updates, and secure transfer of model documentation.

4. Verify procedures for the secure hand-over or provision of model documentation as part of the orchestrated service.

5. Review documentation maintenance procedures to keep data artifacts up to date.

6. If the OSP has no role in handling model documentation, document this as Not Applicable.

MDS-04: Model Documentation Requirements

Control Specification

Establish and implement baseline requirements for Model documentation.

Auditing Guidelines for Orchestrated Service Providers (OSP)

1. Review OSP policies and procedures that ensures model documentation adheres to standards before deployment and management of any model through the orchestrated platform.

2. Assess procedures followed to meet best practices (for example, technical or governance changes that could occur during deployment), and verify artifacts’ ability to track and to align with industry standards.

3. Audit documented handoff procedures where model developers or data science teams provide model artifacts and sign-off for compliance with the standards, and inspect logs that track that policy has been confirmed.

4. If the OSP is not involved in creating the framework for the model, and that template is with a third party, document this as Not Applicable.

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

1. Review what the procedures to perform regular verification to check if there are any manual approvals for model changes or updates to documentation.

2. Assess if there any mechanisms and processes for managing the validation activities (for example, what validation schedule is used and if alerts are sent to personnel and relevant third parties).

3. Audit that validation and security reports were generated as expected.

4. Examine if the OSP has the ability to support validation based on the features that they are using in the environment.

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

1. Examine documented processes for assessing adversarial threats specific to orchestrated deployment environments.

2. Verify identification of threats related to service configurations, scaling mechanisms, and multi-tenant environments that could impact model security.

3. Review methodologies for evaluating attack vectors targeting APIs, service integration points, and orchestration components.

4. Assess the threat prioritization framework, confirming that threats are ranked based on service architecture and customer usage patterns.

5. Verify implementation of monitoring systems for detecting orchestration-specific attack indicators.

6. Review coordination processes with MPs on threats that span model and deployment domains, including information sharing protocols.

7. Examine mechanisms for sharing deployment-specific threat intelligence with APs and AICs.

8. Verify that adversarial threat assessments influence security controls implemented in orchestration environments.

9. Review procedures for testing orchestration-specific defenses against prioritized threats.

10. Assess processes for updating threat assessments when deployment configurations change or new attack techniques emerge.

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

1. Examine the OSP’s procedures for maintaining model hardening protections during service orchestration and deployment.

2. Verify the implementation of service-level protective measures that complement model hardening, such as input validation, rate limiting, and anomaly detection.

3. Assess coordination documentation between the OSP and MP regarding model-specific vulnerabilities and appropriate orchestration approaches.

4. Review testing procedures that verify model hardening measures remain effective in the orchestrated environment.

5. Confirm that monitoring mechanisms detect potential adversarial attacks against the orchestrated service.

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

1. Examine procedures for verifying model integrity upon receipt from Model Providers.

2. Verify the implementation of regular integrity checks during orchestration and deployment processes.

3. Assess documentation of verification results, including timestamp, method used, and outcome.

4. Review the process for responding to integrity verification failures.

5. Confirm that integrity verification occurs at least annually and after any change of hands.

6. Verify that checksum verification results are securely communicated to downstream Application Providers and AI Customers.

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

1., Examine procedures for verifying signatures of models received from Model Providers.

1. Verify the implementation of signature verification during orchestration and deployment processes.

2. Assess security controls for any signing keys used by the OSP for applying additional signatures.

3. Review documentation of all signature verification results, including timestamp, verification method, and outcome.

4. Confirm that signature verification occurs any time a model is loaded from storage.

5. Verify that procedures exist for handling signature verification failures.

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

1. Examine monitoring systems implemented for orchestrated model environments.

2. Verify that service-level monitoring tracks performance across different deployment configurations.

3. Assess correlation capabilities between infrastructure metrics and model performance metrics.

4. Review alerting mechanisms and threshold configurations for detecting performance degradation.

5. Verify the implementation of monitoring dashboards providing visibility to downstream consumers.

6. Confirm that automated or semi-automated response procedures exist for common performance issues.

7. Examine how monitoring data is used to inform service improvements and optimization.

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

1. Examine the documented evaluation of redundancy requirements based on service criticality.

2. Verify implementation of appropriate redundancy strategies (e.g., multi-model deployment, load balancing).

3. Assess failover mechanism design and effectiveness in redirecting traffic during failures.

4. Review testing procedures and results that validate redundancy measures under various failure scenarios.

5. Examine monitoring systems that detect failures and trigger redundancy mechanisms.

6. Verify documentation of redundancy architecture and recovery procedures.

7. Confirm that redundancy implementation aligns with service level agreements and business continuity requirements.

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

1. Examine orchestration-level security controls specific to open weight models.

2. Verify risk assessment procedures conducted when integrating open weight models into service offerings.

3. Review monitoring mechanisms for detecting suspicious activities that might exploit open weights during operation.

4. Assess implementation of appropriate access controls and authentication mechanisms for accessing model weights.

5. Confirm regular review and update of security measures based on emerging threats.

6. Verify that security guidance from MPs is appropriately implemented in the orchestration environment.

MDS-13: Secure Model Format

Control Specification

Adopt secure model formats and processes for AI model serialization where applicable.

Auditing Guidelines for Orchestrated Service Providers (OSP)

1. Examine documentation of serialization formats supported in the orchestration environment.

2. Verify implementation of validation procedures when loading serialized models from MPs.

3. Assess security measures applied during any format conversions performed for orchestration purposes.

4. Review processes for maintaining the security properties of serialized models throughout the orchestration lifecycle.

5. Confirm that security guidelines from MPs regarding serialization are followed.

6. Verify that serialization security information is appropriately communicated to APs.

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

1. Verify the Orchestration Services Provider (OSP) has documented and approved security incident management policy, aligned with recognized industry standards such as NIST SP 800-61 or ISO/IEC 27035.

2. 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 APs, MPs, AICs).

3. Confirm the Orchestration Services Provider (OSP) has procedures for E-discovery and Forensics for Orchestrated Services.

4. Check that procedures cover the full incident lifecycle, including initial reporting, triage, escalation criteria, containment, eradication, recovery, and post-incident review.

5. Ensure that the policy and procedures are communicated effectively to all internal and external stakeholders, including third-party service providers, where applicable.

6. Verify that the incident management policy and related procedures are reviewed and updated periodically, or following major incidents, organizational changes, or regulatory updates.

7. Confirm that regular training is provided to incident response teams, with materials updated based on emerging threats and lessons learned.

8. Validate that incident response drills or tabletop exercises are conducted regularly, with documentation of scenarios, participants, outcomes, and improvement actions.

SEF-02: Service Management Policy and Procedures

Control Specification

Establish, document, approve, communicate, apply, evaluate and maintain policies and procedures for the timely management of security incidents. Review and update the policies and procedures at least annually, or upon significant changes.

Auditing Guidelines for Orchestrated Service Providers (OSP)

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, retaining data consistently across orchestration)

3. Review dependencies and partners (e.g., AP, MP) which could impact the ability of the OSP 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 Orchestrated Service Providers (OSP)

1. Verify Orchestration Services Provider (OSP) has incident response plans clearly documented and approved.

2. Confirm incident response plans cover critical scenarios for executing orchestration services (OSP) comprehensively.

3. Check plans define specific roles and escalation procedures.

4. Verify the incident response plan includes a documented communication strategy for notifying internal teams, affected service customers, and key integration partners involved in orchestration workflows.

5. Ensure regular reviews and updates of incident response documentation.

6. Confirm testing and drills of incident response plans performed periodically.

7. Verify documented corrective actions following response plan testing.

SEF-04: Incident Response Testing

Control Specification

Exercise the incident response plans at planned intervals or upon significant changes.

Auditing Guidelines for Orchestrated Service Providers (OSP)

1. Confirm the OSP conducts regular exercises of incident response plans at predefined intervals or following orchestration/environmental changes (e.g., service integration or model updates).

2. Verify thorough documentation of exercises, including scope, procedures, and analysis of results.

3. Assess implementation of response plan refinements based on findings from exercises.

4. Ensure participation from cross-functional teams (e.g., orchestrators, infrastructure, AI ops).

5. Validate that exercise scenarios simulate realistic orchestration-specific disruptions (e.g., service chain breakage, cascading model failure).

6. Confirm that exercises and resulting updates are logged and reviewed by the responsible governance body.

SEF-05: Incident Response Metrics

Control Specification

Establish, monitor and report information security incident metrics.

Auditing Guidelines for Orchestrated Service Providers (OSP)

1. Verify OSP documented metrics for evaluating incident response effectiveness.

2. Confirm metrics align with orchestration objectives, organizational goals and industry best practices (e.g., detection rate, automation rate).

3. Check regular collection, analysis, and reporting of response metrics.

4. Ensure documentation of actions taken based on metrics analysis.

5. Confirm clear accountability for monitoring incident response metrics.

SEF-06: Event Triage Processes

Control Specification

Define, implement and evaluate processes, procedures and technical measures supporting business processes to triage security-related events.

Auditing Guidelines for Orchestrated Service Providers (OSP)

1. Verify the OSP has 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., logging for containers, services, APIs and data flows).

4. Understand triage models from suppliers and partners (e.g., APM, CSP, MP, AIC).

5. Understand any cascading impacts of orchestrated events on overall triage.

6. Check regular training provided on event triage methods.

7. Ensure continuous improvement through periodic review and update of triage processes.

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

1. Verify incident response categories and severity levels clearly documented (e.g., consider impacts such as cascading issues, orchestration failures, control plane breaches, infrastructure misconfigurations).

2. Verify well defined response procedures are determined, including automated responses where applicable (e.g., Orchestration Monitoring and alerts, secure configuration to support detection and automated response).

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

1. Verify the OSP has documented policies clearly specify requirements for breach notification.

2. Confirm procedures comply with applicable legal and regulatory requirements.

3. Confirm notification procedures provide essential information (e.g., impacted services, impacted infrastructure).

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

1. Verify the Orchestrated Services Provider (OSP) has documented policies that clearly specify requirements for collecting, classifying, storing, protecting and retaining incident records related to AI service orchestration.

2. Verify the policies define clear trigger conditions for when a security incident must be recorded.

3. Confirm the OSP maintains a secure incident record repository with appropriate access controls, encryption (in transit and at rest) and audit logging to prevent unauthorized access, modification or deletion.

4. Determine whether the OSP conducts periodic reviews of incident records to identify recurring patterns, root causes and systemic vulnerabilities (e.g. cascading workflow failures, agent loops, inconsistent model responses or dependency driven failures) and whether the review cadence and review process are formally documented.

5. Confirm corrective actions identified through incident record analysis are documented, tracked, implemented and verified for effectiveness in addressing the identified issues.

6. Ensure records of reviews and corrective actions are retained and available for audit.

SEF-10: Points of Contact Maintenance

Control Specification

Maintain points of contact for applicable regulation authorities, national and local law enforcement, and other legal jurisdictional authorities. Review and update the points of contact at least annually.

Auditing Guidelines for Orchestrated Service Providers (OSP)

1. Verify documented procedures for Orchestration Service Provider (OSP) to meet regulatory responsibilities and maintain points of contact.

2. Verify procedures for review of dependencies with AP, MP, AIC and CSP that would impact Application Provider’s ability to meet its regulatory contact obligations (e.g., AI and data regulations).

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

1. Confirm it covers orchestration agents, toolchains, AI modules/plugins.

2. Check who owns and signs off policy, and review changelog.

3. Ask AI engineers/architects about policy awareness.

4. Request evidence of plugin/module review or sandboxing protocols.

5. Examine how services are scored by trust/reliability (e.g., open-source vs. closed, public audit reports).

6. Confirm recent policy updates reflect AI component shifts or new orchestration logic.

7. Check that the policy aligns with recognized standards and regulatory expectations (e.g., CSA CCM, ISO/IEC 27036).

8. Verify the presence of metrics or periodic reviews to evaluate policy effectiveness and identify improvement opportunities.

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

1. Examine the OSP’s policies and procedures for adequacy, approval, communication, and effectiveness in addressing SSRM responsibilities across its orchestration role and third‑party risks.

2. Verify that the SSRM policy is clearly defined and tailored to the orchestration services and the integrated upstream and downstream components.

3. Confirm SSRM policies and procedures for compliance with regulatory requirements and industry best practices.

4. Verify formal approval of SSRM policies and procedures by authorized management.

5. Ensure SSRM policies have been communicated to stakeholders and clearly understood, with explicit role definitions and no conflicting areas of responsibility.

6. Confirm implementation of SSRM policies in daily operations by relevant stakeholders.

7. Verify that metrics and indicators are monitored to evaluate the effectiveness of SSRM policies and procedures.

8. Verify evidence of periodic review (at least annually) and updates to SSRM policies and procedures in response to changes in technology, threat landscape, or contractual requirements.

9. Verify that the SSRM policy explicitly defines the OSP’s responsibilities at the orchestration layer, covering tenant isolation, data flows, and security of integrated components.

10. Review contracts with upstream (MP) and downstream (AP) partners to ensure clear SSRM alignment and mutual understanding of shared and split responsibilities.

STA-03: SSRM Supply Chain

Control Specification

Apply, document, implement and manage the SSRM throughout the supply chain.

Auditing Guidelines for Orchestrated Service Providers (OSP)

1. Confirm the orchestration provider (OSP) documents its SSRM in customer-facing materials, contracts, and service documentation, clearly outlining shared responsibilities across the orchestration stack.

2. Evaluate how the OSP applies and manages inherited responsibilities from upstream providers (e.g., securing infrastructure from CSPs, ensuring model integrity from model providers), and how these are integrated into its own operational and security controls.

3. Review the implementation of a clear responsibility matrix, mapping roles and obligations across the supply chain including CSPs, model providers, application developers, and customers to ensure accountability and traceability.

4. Examine whether the OSP monitors the effectiveness of SSRM implementation across all orchestrated components. This includes assessing whether metrics, KPIs, or alerts are used to identify integration gaps, breakdowns in shared controls, or unowned responsibilities throughout the service chain.

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

1. Verify the orchestrator service provider (OSP) offers clear and accessible SSRM guidance to AI service customers (AICs), outlining shared responsibilities across orchestration, infrastructure, model, and application layers.

2. Review the OSP’s public documentation, trust center, or support resources for detailed information on service customer responsibilities such as configuring orchestration policies, securing integration points, managing access controls, and monitoring service interactions.

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

1. Confirm the OSP has mapped all CSA AICM controls to its internal framework, showing which are OSP-owned, inherited (e.g., from AWS or Azure), or customer-owned (AIC), with clear documentation.

2. Review the mapping using SSRM guidance to ensure accuracy. Validate ownership assumptions, fix gaps (e.g., unclear logging responsibilities), and update regularly to reflect current roles.

STA-06: SSRM Documentation Review

Control Specification

Review and validate the SSRM documentation.

Auditing Guidelines for Orchestrated Service Providers (OSP)

1. Confirm the AI Orchestrator Provider has a process to regularly review its own SSRM documentation and that of key suppliers (e.g., CSPs, model providers), ensuring shared responsibilities are clearly defined and made current by updating its own matrix to reflect orchestration-layer responsibilities such as data routing and API access control.

2. Verify these reviews are conducted at least annually or when major service changes occur (e.g., new model integrations, orchestration logic updates, the orchestrator updates its SSRM to reflect changes in data flow, logging, and access control ownership).

STA-07: SSRM Control Implementation

Control Specification

Implement, operate, and audit or assess the portions of the SSRM which the organization is responsible for.

Auditing Guidelines for Orchestrated Service Providers (OSP)

1. Verify through testing and evidence review that the OSP is implementing its responsibilities, such as tenant isolation, secure API gateway configuration, and monitoring of the orchestrated services.

2. Review internal or third-party audit reports of the OSP’s platform.

STA-08: Supply Chain Inventory

Control Specification

Develop and maintain an inventory of all supply chain relationships.

Auditing Guidelines for Orchestrated Service Providers (OSP)

1. Confirm that the OSP maintains a centralized, up-to-date inventory of all service provider and partner relationships involved in orchestrating services.

2. Ensure that all orchestrated service relationships across infrastructure, platforms, and applications are clearly and accurately documented.

3. Assess whether the inventory is regularly reviewed and validated to maintain its completeness, accuracy, and alignment with current operational needs.

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

1. Determine whether the orchestration service provider (OSP) maintains a documented SBoM process, with regular reviews triggered by updates to orchestration workflows, infrastructure, or security configurations.

2. Examine the SBoM for completeness, ensuring it outlines orchestration components such as APIs, service versions, scaling policies, dependencies, security controls, and risk classifications with relevant metadata.

3. Validate inclusion of both core and AI-specific orchestration elements, including compute provisioning, network routing, model deployment paths, inference endpoints, and monitoring hooks.

4. Inspect the security and access controls of the SBoM repository, confirming role-based access for authorized stakeholders such as cloud security teams, model providers, and application developers.

5. Review the update cadence and accuracy of the SBoM, ensuring changes to orchestration logic or integrations are promptly reflected, with documented impact assessments reviewed by security teams.

6. Confirm that SBoM information is clearly communicated, including orchestration capabilities (e.g., deployment patterns, failover strategies, latency thresholds, scaling triggers), 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 Orchestrated Service Providers (OSP)

1. Assess whether the OSP performs supply chain risk reviews at least annually or following significant changes such as onboarding a new cloud or model provider, or modifying service orchestration to address operational, security, compliance, and reputational risks.

2. Review whether risk assessments are properly documented, consistently updated, and based on indicators such as SLA breaches, incident trends, or third-party audit findings (e.g., recurring disruptions from a cloud partner or compliance issues), with input from relevant internal teams.

3. Evaluate if identified risks result in appropriate mitigation actions such as contract revisions, enhanced monitoring, or replacement of underperforming partners and confirm that these actions are tracked and supported by audit-ready documentation, particularly when orchestration dependencies affect service delivery or compliance.

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

1. Assess whether the OSP’s contracts with third-party partners include terms such as service scope, security (including SSRM), change management, monitoring, incident response, audit rights, termination provisions, interoperability, data privacy, and operational resilience.

2. Verify that the OSP periodically reviews and enforces these contractual terms through audits, performance assessments, or compliance checks to ensure third-party adherence.

STA-12: Supply Chain Agreement Review

Control Specification

Review supply chain agreements at least annually, or upon significant changes.

Auditing Guidelines for Orchestrated Service Providers (OSP)

1. Verify if the Orchestrated Service Provider (OSP) performs review of supply chain agreements with key partners (e.g., CSPs, MPs, APs, and other third parties), and that reviews occur 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 Orchestrated Service Providers (OSP)

1. Confirm the OSP has a documented, recurring audit process to assess internal governance across AI, data, cloud, and orchestration services.

2. Review audit records maintained by the OSP, including identified gaps and corrective actions. Confirm timely remediation and compliance with applicable AI regulations, standards, and internal policies.

3. Ensure the OSP communicates audit findings to stakeholders and maintains a feedback mechanism to continuously improve audit effectiveness and responsible AI orchestration.

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

1. Verify that the orchestration service provider (OSP) has established and implemented a process for including security, compliance, and governance requirements into contracts with its supply chain partners, including cloud providers, AI model vendors, data sources, and integration service providers.

2. Assess whether these contractual agreements explicitly include provisions covering key areas such as data protection, service reliability, regulatory compliance, and orchestration integrity, ensuring alignment with organizational and regulatory expectations.

3. Confirm that the OSP performs these reviews at least annually, or upon significant changes, and maintains documentation demonstrating that the reviews are conducted in accordance with the established process.

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

1. Verify that the orchestration service provider (OSP) has established and implemented a formal process to review the IT governance practices of its supply chain partners, including those responsible for data provisioning, AI model development, cloud infrastructure, and service orchestration.

2. Confirm that the OSP performs these reviews on a defined schedule (e.g., annually or quarterly) and maintains documentation demonstrating that the reviews are conducted in accordance with the established process.

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

1. Verify that the OSP maintains a structured process to assess supply chain data (risk-based) security, including cloud infrastructure (e.g., IAM, containers) and AI components (e.g., model orchestration, data pipelines).

2. Evaluate how the OSP identifies risks from third parties, such as insecure APIs, unverified models, or non-compliant data handling by platforms, model providers, or integrators.

3. Review documented procedures and regular assessments that address risks from external entities managing sensitive data or supporting AI workflows, including storage misconfigurations, model versioning, and data leakage.

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

1. Verify that the OSP has established and documented policies and procedures for vulnerability and threat management, covering scope, objectives, roles, and responsibilities.

2. Inspect whether the policies are compliant with regulatory requirements, industry best practices, and relevant threat scenarios.

3. Verify that the policies have been formally approved by authorized management.

4. Verify that the policies are communicated to all relevant stakeholders and understood.

5. Confirm that the policies are effectively applied in day‑to‑day operations.

6. Verify that metrics are in place to monitor effectiveness and identify improvements.

7. Inspect evidence that the policies are reviewed and updated at least annually or upon significant changes.

8. Verify that the TVM policy explicitly addresses the orchestrated ecosystem, including first‑party code, third‑party services, and the orchestration platform itself.

9. Confirm that the policy defines procedures for receiving vulnerability disclosures from upstream providers (e.g., MP) and communicating relevant findings to downstream consumers (e.g., AP), and that these procedures are operationalized.

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

1. Verify that the Orchestrated Services Provider (OSP) 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 OSP’s policy requires malware scanning of all components integrated into the orchestration platform, including container images and third-party plugins.

9. Confirm the policy includes measures to detect and block malicious instructions traversing the service chain.

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

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 OSP’s remediation schedule accounts for the complexity of the orchestrated environment.

7. Confirm the process includes coordinating patches with upstream and downstream partners to avoid breaking the service chain.

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

1. Verify that the Orchestrated Services Provider (OSP) 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 Orchestrated Service Providers (OSP)

1. Verify that the Orchestrated Services Provider (OSP) 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 OSP’s process for updating detection signatures across the orchestration platform, including network sensors, container security tools, and API gateways.

7. Confirm that threat intelligence feeds are used to update indicators of compromise (IoCs).

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

1. Verify that the Orchestrated Services Provider (OSP) 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 OSP has a process to manage vulnerabilities in the external libraries and components used by the orchestration platform itself.

7. Confirm the OSP has a policy for how to handle vulnerabilities discovered in the third-party services it orchestrates, including notification to the responsible parties.

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

1. Verify that the OSP has defined and documented processes, procedures, and technical measures for periodic penetration testing by independent third parties. Documentation must include scope, objectives, roles, and responsibilities.

2. Examine whether these processes comply with regulatory requirements and industry best practices.

3. Inspect alignment of the processes with relevant threat scenarios, including systemic risks specific to orchestration.

4. Confirm that these processes are implemented appropriately and on schedule.

5. Verify that penetration testing findings are reviewed and translated into concrete remediation actions.

6. Inspect whether metrics and KPIs are monitored to evaluate the efficacy and efficiency of the penetration testing program.

7. Inspect evidence that the processes are reviewed and updated at least annually or upon significant changes.

8. Verify that the penetration testing scope explicitly includes the orchestration control plane, management APIs, and tests for cross‑tenant data access vulnerabilities.

9. Confirm that penetration tests simulate realistic attacks on the entire service chain to identify systemic weaknesses, not just individual component flaws.

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

1. Verify that the Orchestrated Services Provider (OSP) 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 Orchestrated Service Providers (OSP)

1. Verify that the Orchestrated Services Provider (OSP) 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 Orchestrated Service Providers (OSP)

1. Identify risks from agent/workflow orchestration and chaining.

2. Review threat models accounting for cascading AI failure risks.

3. Validate the presence of a risk-based prioritization method for service-to-service threats.

4. Examine controls for plugin/module abuse and unauthorized workflow invocation.

5. Check if orchestration logic uses threat intelligence or telemetry for prioritization.

6. Review mitigation protocols for agent malfunction or data leakage.

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

1. Verify that the Orchestrated Services Provider (OSP) 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 Orchestrated Service Providers (OSP)

1. Verify that the Orchestrated Services Provider (OSP) 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 Orchestrated Service Providers (OSP)

1. Verify that the Orchestrated Services Provider (OSP) 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 Orchestrated Service Providers (OSP)

1. Verify that the OSP has established and documented endpoint device management policies and procedures, including scope, objectives, roles, responsibilities, audit frequency, criteria, methodology, and remediation strategies.

2. Inspect whether these policies comply with applicable regulatory requirements, industry best practices, and the OSP’s risk profile.

3. Verify formal approval by authorized leadership.

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

7. Inspect evidence of periodic review and update of policies (at least annually or after significant changes).

8. Verify the policy explicitly covers all administrative endpoints used to monitor and manage the orchestration platform.

9. Confirm the policy includes specific controls to mitigate the risk of a compromise propagating across tenants in the multi‑tenant environment (e.g., isolation, least‑privilege, MFA, endpoint hardening).

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

1. Verify that the Orchestrated Services Provider (OSP) has defined processes, procedures, and technical measures to identify and implement updates for applications that used by endpoints that interface with orchestrated services, in order to mitigate risks of accessing unapproved services and it’s sources. 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 approved endpoint services/applications 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 to validate compliance.

4. Inspect whether the above-mentioned processes, procedures, and technical measures are monitored against sets of efficacy and efficiency metrics / indicators.

5. Inspect whether the above-mentioned processes, procedures, and technical measures are periodically reviewed and updated by responsible parties.

UEM-03: Compatibility

Control Specification

Define and implement a process for the validation of the endpoint device’s compatibility with operating systems and applications.

Auditing Guidelines for Orchestrated Service Providers (OSP)

1. Verify that the OSP has a documented Device Compatibility Policy, covering supported OS platforms, device types (e.g., servers, workstations, mobile, IoT), and required hardware specifications.

2. Inspect whether the policy defines roles, responsibilities, approval process, and review cadence. Confirm inclusion of testing protocols (e.g., performance, stress, integration) and update mechanisms for evolving device/OS landscapes.

3. Confirm the policy addresses service compatibility and resilience, including graceful degradation under limited resources and meaningful error logging for misconfigurations.

4. Review implementation evidence, such as compatibility matrices, certification logs, benchmarking results, support tickets, and configuration documentation.

5. Verify that compatibility controls are integrated into broader orchestration and security processes, especially in multi-tenant environments, and align with applicable regulatory and sector-specific requirements.

UEM-04: Endpoint Inventory

Control Specification

Maintain an inventory of all endpoints used to store, access and process company data.

Auditing Guidelines for Orchestrated Service Providers (OSP)

1. Verify that the OSP has a documented Endpoint Inventory Policy, including governance approval, roles, and responsibilities specific to orchestrated service environments.

2. Inspect whether the policy covers inventory of endpoints supporting orchestration workloads, defines update frequency and event-based triggers, and captures critical attributes such as orchestration tooling, hardware specs, and network details.

3. Confirm the policy mandates audits or reconciliations between physical and virtual environments, and addresses inventory of ephemeral or containerized workloads.

4. Review implementation evidence including inventory reports, device classification, reconciliation records, audit logs, and decommissioning documentation.

5. Verify the use of automated discovery and asset management tools that integrate with orchestration platforms, and confirm that decommissioned devices are securely removed from clusters and the inventory.

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

1. Verify that the OSP has a documented Endpoint Management Policy, formally approved and covering endpoint lifecycle stages relevant to orchestration environments.

2. Inspect whether the policy addresses procurement, provisioning, configuration, updates, and decommissioning of orchestrated nodes, including containerized and virtualized environments.

3. Confirm the policy enforces minimal attack surfaces, mandates centralized management, patching schedules, and ties into incident response and regulatory compliance processes.

4. Review implementation evidence such as orchestration console logs, device configuration records, patching history, and offboarding procedures.

5. Verify that standardized tools are used to automate endpoint management across nodes and that compensating controls exist for unsupported or legacy systems.

UEM-06: Automatic Lock Screen

Control Specification

Configure all relevant interactive-use endpoints to require an automatic lock screen.

Auditing Guidelines for Orchestrated Service Providers (OSP)

1. Verify that the OSP has a documented Automatic Lock Screen Policy, formally approved and including governance, scope, and assigned responsibilities.

2. Inspect whether the policy mandates inactivity timeouts appropriate to orchestration risk levels, specifies secure unlock methods, defines exception conditions, and references applicable regulations.

3. Confirm that the policy addresses all endpoint types in the orchestration environment, ensures background workloads remain uninterrupted, and includes regular compliance checks.

4. Review implementation evidence such as device configurations, compliance dashboards, exception documentation, audit records, and operational impact assessments for orchestration processes.

5. Verify that lock screen enforcement is automated through centralized endpoint or orchestration management tools.

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

1. Verify that the OSP has a documented Change Management Policy for all orchestrated nodes (servers, VMs, containers, edge/HPC), including OS version management and patching frequency.

2. Inspect policy content for defined governance, roles, approval workflows, and review intervals aligned with service‑level and security objectives.

3. Confirm the policy enforces baseline OS hardening on orchestration hosts and incorporates routine vulnerability scans of OS layers and container images.

4. Verify that the policy requires compatibility testing of patches/OS upgrades against orchestration frameworks and performance benchmarks.

5. Review evidence (inventory records, patch logs, staging test reports, vulnerability scan results, and policy review minutes) to ensure OS changes are controlled and audited.

UEM-08: Storage Encryption

Control Specification

Protect information from unauthorized disclosure on managed endpoint devices with storage encryption.

Auditing Guidelines for Orchestrated Service Providers (OSP)

1. Verify that the OSP has a documented Storage Encryption Policy, approved by governance, that defines roles, responsibilities, and periodic review requirements.

2. Inspect whether the policy specifies robust cryptographic standards and key lifecycle management (generation, storage, rotation, revocation), including for ephemeral containers and volumes.

3. Confirm the policy covers encryption across all orchestrated environments (servers, VMs, containers, edge/IoT devices, HPC/GPU nodes) and addresses exceptions with documented risk assessments.

4. Verify that the policy mandates regular audits of encryption controls, automated key provisioning/rotation solutions, and secure teardown or re‑encryption of temporary storage.

5. Review operational evidence (encryption status dashboards, key management logs, compliance reports, exception approvals, and integration with orchestration security tools) to validate implementation.

UEM-09: Anti-Malware Detection and Prevention

Control Specification

Configure managed endpoints with anti-malware detection and prevention technology and services.

Auditing Guidelines for Orchestrated Service Providers (OSP)

1. Verify that the OSP has a documented Anti‑Malware Policy, approved by governance, with defined roles, responsibilities, and periodic review.

2. Inspect the policy to confirm it requires baseline protections for orchestrated environments, including container images, ephemeral workloads, and build pipelines, plus timely signature/engine updates.

3. Confirm the policy mandates advanced detection techniques and specifies response procedures (isolation/quarantine of infected containers or nodes) and integration with central SIEM.

4. Verify the policy covers all orchestration endpoints such as servers, VMs, containers, edge/IoT, HPC/GPU nodes, and includes regular assessments of anti‑malware effectiveness.

5. Review operational evidence (deployment/config records, policy‑compliance dashboards, update logs, malware incident reports, advanced detection logs, and audit findings) to validate implementation.

UEM-10: Software Firewall

Control Specification

Configure managed endpoints with properly configured software firewalls.

Auditing Guidelines for Orchestrated Service Providers (OSP)

1. Verify that the OSP has a documented Software Firewall Policy, formally approved, defining roles, responsibilities, and periodic review requirements.

2. Inspect the policy to confirm it specifies baseline configurations for container hosts, servers, edge devices, and ephemeral workloads, and requires default‑deny by default.

3. Confirm the policy mandates logging of firewall events for all orchestrated endpoints and central collection for analysis.

4. Verify that the policy requires formal change‑control for port‑or protocol‑opening requests and patching of firewall software in host and container images.

5. Review evidence (configuration snapshots, rule‑change management logs, aggregated firewall logs, patch/update records, and audit findings) to validate enforcement.

UEM-11: Data Loss Prevention

Control Specification

Configure managed endpoints with Data Loss Prevention (DLP) technologies and rules in accordance with a risk assessment.

Auditing Guidelines for Orchestrated Service Providers (OSP)

1. Verify that the OSP has a documented DLP Policy, approved by governance, defining scope, roles, responsibilities, and periodic review.

2. Inspect the policy to confirm it mandates data classification within orchestration workflows, DLP modules or agents on all hosts (servers, VMs, containers, edge), and coverage of ephemeral volumes.

3. Confirm the policy specifies detection of suspicious transfers (logs, metrics, environment variables), controls on outbound channels, and exception approval processes.

4. Verify that the policy requires automated response actions such as quarantine containers, block transfers, alert security teams, and regular audits of DLP controls across orchestrated environments.

5. Review operational evidence (classification artifacts, DLP configuration snapshots, compliance dashboards, incident/escalation records, and audit findings) to validate implementation.

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

1. Verify that the OSP has a documented Remote Locate Policy, formally approved and including clear roles, responsibilities, and management procedures.

2. Inspect whether the policy specifies authorized personnel for remote locate actions, defines multi-layer approvals, safeguards privacy, manages automated tracking scenarios, sets retention rules for location data, and aligns with incident response.

3. Confirm the policy mandates periodic audits of remote locate requests and ensures protection of sensitive operational environments during location tracking.

4. Review implementation evidence such as authorization logs, privacy assessments, technical documentation of location tools, locate event records, and incident response integrations.

5. Verify the use of standardized, secure remote locate platforms and confirm safeguards to prevent misuse or unauthorized access to location data.

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

1. Verify that the OSP has a documented Remote Wipe Policy, approved under formal governance, covering scope, roles, and responsibilities.

2. Inspect whether the policy requires strict approval for remote wipe actions, aligns actions with data classification in containerized environments, addresses legal constraints, differentiates full and selective wipes, integrates with incident response, and mandates regular audits.

3. Confirm the policy addresses wipe procedures across servers, VMs, containers, edge devices, and other orchestrated nodes, with encryption and authentication safeguards for wipe commands.

4. Review implementation evidence such as authorization logs, technical execution records, compliance dashboards, and incident response records.

5. Verify that secure, automated tools are used to enforce wipe actions and that appropriate operational safeguards are in place for orchestrated services.

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

1. Verify that the OSP has a documented Third-Party Endpoint Security Policy or Agreement, approved under formal governance, defining roles and responsibilities.

2. Inspect whether the policy mandates security vetting of vendor endpoints before access to orchestration environments, enforces security clauses in contracts, requires continuous monitoring, mandates breach notification, prescribes secure offboarding from orchestration tools, references regulations, and calls for periodic audits.

3. Confirm that vendor endpoints are restricted to essential container environments, and that robust controls are in place for vendor access to container registries, APIs, and infrastructure.

4. Review implementation evidence such as vendor risk assessments, contract terms, security monitoring dashboards, incident reports, and offboarding documentation.

5. Verify vendor compliance with endpoint security requirements by reviewing periodic audit results, SLAs, certifications, breach responses, and exception records.