Encryption Risk Management
Specification
Establish and maintain an encryption and key management risk program that includes provisions for risk assessment, risk treatment, risk context, monitoring, and feedback.
Threat coverage
Architectural relevance
Lifecycle
Data storage
Guardrails
Not applicable
Orchestration, AI Services supply chain, AI applications
Maintenance, Continuous monitoring, Continuous improvement
Data deletion, Model disposal
Ownership / SSRM
PI
Shared Cloud Service Provider-Model Provider (Shared CSP-MP)
The CSP and MP are jointly responsible and accountable 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.
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 Model Provider-Orchestrated Service Provider (Shared MP-OSP)
The MP and OSP are jointly responsible and accountable 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.
Application
Shared Orchestrated Service Provider-Application Provider (Shared OSP-AP)
The OSP and AP are jointly responsible and accountable 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.
Implementation guidelines
Auditing guidelines
1. Verify that the CSP has a documented CEK risk management program covering cryptographic services across cloud infrastructure, including KMS, HSMs, and tenant encryption support. 2. Confirm that CEK risks are contextualized based on infrastructure layers, service models (e.g., IaaS, PaaS, SaaS), tenant-specific encryption requirements, and jurisdictional or regulatory factors. 3. Review the risk assessment methodology used to evaluate CEK risks, including how key exposure, data classification, control maturity, and threat likelihood are quantified. 4. Verify that a CEK-specific risk register is maintained, documenting known vulnerabilities, associated risks, treatment plans, responsible teams, and risk disposition timelines. 5. Confirm that CEK treatment strategies include service reconfiguration (e.g., key isolation), upgrades (e.g., algorithm replacement), or compensating controls (e.g., data access throttling, increased logging). 6. Validate that residual CEK risks are reviewed by cloud risk governance forums and updated following significant architecture changes, security incidents, or compliance findings. 7. Review how CEK risks are monitored through ongoing controls such as encryption coverage scans, key usage monitoring, tenant isolation testing, and compliance dashboards. 8. Confirm that lessons learned from incidents, customer-reported issues, or audit findings feed into the CEK risk program and lead to updates in service design or policy. 9. Verify that CEK risks tied to multi-tenancy, shared cryptographic infrastructure, or tenant misconfiguration (e.g., improper key policy enforcement) are included in the risk register. 10. Validate that the CSP accounts for upstream component risks (e.g., hardware supply chain, crypto libraries) and downstream consumer expectations (e.g., AP, OSP, AIC encryption guarantees) in its CEK risk posture and documentation. From CCM: 1. Identify and confirm the existence of the organization's risk assessment process and obtain the risk register. 2. Confirm that the risk register includes encryption and key management as part of a regular process or control review. 3. Obtain evidence that demonstrates a risk assessment of the encryption and key management program and process is performed.
Standards mappings
No Mapping for ISO 42001 ISO 27001: A.8.24 Clause 6.1 ISO 27002: 8.24 5.1 5.7
Addendum
Add a control to establish and maintain an encryption and key management risk program for AI systems, explicitly requiring risk assessment, treatment, context, monitoring, and feedback tailored to cryptographic controls, enhancing ISO 27001 (A.8.24, Clause 6.1) and ISO 27002 (8.24, 5.1, 5.7) with AI-specific focus and comprehensive risk management provisions.
Article 9 (1) Article 9 (2) (a), (b), (c), (d)
Addendum
Cover an encryption and key management risk program.
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 implementation of a risk management program in such domain.
CRY-01 CRY-04 OIS-06 OIS-07
Addendum
N/A
AI-CAIQ questions (1)
Is a cryptography, encryption, and key management risk program established and maintained that includes risk assessment, risk treatment, risk context, monitoring, and feedback provisions?