Customer Key Management Capability
Specification
Providers must provide the capability for customers to manage their own data encryption keys.
Threat coverage
Architectural relevance
Lifecycle
Data storage
Not applicable
Not applicable
Not applicable
Not applicable
Data deletion
Ownership / SSRM
PI
Owned by the Cloud Service Provider (CSP)
The Cloud Service Provider (CSP) is responsible for the design, development, implementation, and enforcement of the control to mitigate security, privacy, or compliance risks associated with cloud computing (processing, storage, and networking) technologies in the context of the services or products they develop and offer. The CSP is responsible and accountable for implementing the control within its own infrastructure/environment. The CSP is responsible for enabling the customer and/or upstream partner to implement/configure the control within their risk management approach. The CSP is accountable for ensuring that its providers upstream implement the control related to the service/product developed and offered by the CSP.
Model
Owned by the Model Provider (MP)
The model provider (MP) designs, develops, and implements the control as part of their services or products to mitigate security, privacy, or compliance risks associated with the Large Language Model (LLM). Model Providers are entities that develop, train, and distribute foundational and fine-tuned AI models for various applications. They create the underlying AI capabilities that other actors build upon. Model Providers are responsible for model architecture, training methodologies, performance characteristics, and documentation of capabilities and limitations. They operate at the foundation layer of the AI stack and may provide direct API access to their models. Examples: OpenAI (GPT, DALL-E, Whisper), Anthropic(Claude), Google(Gemini), Meta(Llama), as well as any customized model.
Orchestrated
Shared across the supply chain
Shared control ownership refers to responsibilities and activities related to LLM security that are distributed across multiple stakeholders within the AI supply chain, including the Cloud Service Provider (CSP), Model Provider (MP), Orchestrated Service Provider (OSP), Application Provider (AP), and Customer (AIC). These controls require coordinated actions, communication, and governance across all involved parties to ensure their effectiveness.
Application
Owned by the Application Provider (AP)
The Application Provider (AP) is responsible for the design, development, implementation, and enforcement of the control to mitigate security, privacy, or compliance risks associated with Large Language Model (LLM)/GenAI technologies in the context of the services or products they develop and offer. The AP is responsible and accountable for the implementation of the control within its own infrastructure/environment. If the control has downstream implications on the users/customers, the AP is responsible for enabling the customer and/or upstream partner in the implementation/configuration of the control within their risk management approach. The AP is accountable for carrying out the due diligence on its upstream providers (e.g MPs, Orchestrated Services) to verify that they implement the control as it relates to the service/product develop and offered by the AP. These providers build and offer end-user applications that leverage generative AI models for specific tasks such as content creation, chatbots, code generation, and enterprise automation. These applications are often delivered as software-as-a-service (SaaS) solutions. These providers focus on user interfaces, application logic, domain-specific functionality, and overall user experience rather than underlying model development. Example: OpenAI (GPTs,Assistants), Zapier, CustomGPT, Microsoft Copilot (integrated into Office products), Jasper (AI-driven content generation), Notion AI (AI-enhanced productivity tools), Adobe Firefly (AI-generated media), and AI-powered customer service solutions like Amazon Rufus, as well as any organization that develops its AI-based application internally.
Implementation guidelines
Auditing guidelines
1. Verify that the CSP provides technical capabilities that allow AICs to manage their own cryptographic keys (e.g., BYOK, HYOK, customer-managed KMS) within the CSP's infrastructure or services. 2. Confirm that keys provisioned by the AIC are logically isolated and that the CSP enforces tenant-level key usage boundaries to ensure cryptographic separation across customer environments. 3. Validate that CSP systems support key lifecycle operations under AIC control, including key generation, import, rotation, revocation, and deletion. 4. Verify that the CSP makes available audit logs or monitoring tools that allow AICs to track key usage events, such as access, encryption, decryption, and administrative changes. 5. Review whether service agreements, documentation, or customer policies clarify the scope of AIC key control, including enforceable rights and limitations on key visibility and usage. 6. Confirm that the CSP assigns clear responsibility to internal roles or teams (e.g., cloud security engineering, cryptographic services) for supporting and maintaining AIC key control capabilities. 7. Verify that exceptions to AIC-managed key usage are documented and accompanied by compensating controls, fallback options, or roadmaps for future support. 8. Validate that CSP customers can securely test their key configurations prior to deployment of sensitive or production data within the CSP environment. 9. Confirm that AIC key control features and supporting infrastructure are subject to periodic review and validation by CSP governance bodies or CEK oversight functions. 10. Verify that the CSP supports downstream AIC key control requirements across its cloud service offerings and evaluates upstream dependencies (e.g., HSMs, KMS APIs, third-party encryption services) to ensure ongoing support for secure, auditable, and isolated key management. From CCM: 1. Identity CSP's data key encryption policy and standards. 2. Review the implementation of the CSP key broker and key management services (KMS) and the cloud hardware security modules (HSMs). 3. Confirm that the configuration enables appropriate management of the key (e.g., customer-managed master key, CSP-managed master key, CSP-owned master key). 4. Confirm that HSM meets internal compliance standards (e.g., FIPS 140-2).
Standards mappings
No Mapping for ISO 42001 ISO 27001: A.8.24 ISO 27002: 8.24
Addendum
This specific requirement for CSPs to enable AIC key management is absent in ISO 42001, which does not address CSP-AIC relationships or key management autonomy. Add a control requiring Cloud Service Providers (CSPs) supporting AI systems to provide AI Customers (AICs) with the capability to manage their own data encryption keys, addressing the gap in ISO 42001:2023, which lacks specific provisions for CSP-AIC key management responsibilities. This enhances general cryptographic controls (e.g., ISO 27001 A.8.24, ISO 27002 8.24) by explicitly mandating CSP support for AIC key autonomy, including implementation guidance and compliance verification.
No Mapping
Addendum
Providers must provide the capability for customers to manage their own data encryption keys.
No Mapping
Addendum
No (implicit/explicit) reference to cryptography, encryption, or key management is made in the NIST AI 600-1 standard, let alone to the requirement for CSPs to allow AICs to manage their own data encryption keys.
C4 DM-04 C5 CRY-03
Addendum
N/A
AI-CAIQ questions (1)
Are providers providing customers with the capability to manage their own data encryption keys?