AICM AtlasCSA AI Controls Matrix
CEK · Cryptography, Encryption & Key Management
CEK-05Cloud & AI Related

Encryption Change Management

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.

Threat coverage

Model manipulation
Data poisoning
Sensitive data disclosure
Model theft
Model/Service Failure
Insecure supply chain
Insecure apps/plugins
Denial of Service
Loss of governance

Architectural relevance

Physical infrastructure
Network
Compute
Storage
Application
Data

Lifecycle

Preparation

Data storage, Resource provisioning

Development

Guardrails

Evaluation

Not applicable

Deployment

Orchestration, AI Services supply chain, AI applications

Delivery

Maintenance, Continuous monitoring, Continuous improvement

Retirement

Archiving, Data deletion, Model disposal

Ownership / SSRM

PI

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.

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

[All Actors]
Applies to all Roles (Baseline) before application of role context.
1. Establish and document policies and procedures for Cryptography, Encryption, and Key Management.

2. Approve the policies and procedures through formal governance processes (e.g., security committee, 
CISO).

3. Communicate the policies and procedures to all relevant stakeholders.

4. Apply the approved policies and procedures to all systems, services, and processes under the role’s 
control.

5. Evaluate the effectiveness of policy and procedure implementation using internal audits, technical 
reviews, and encryption control validations.

6. Review and update the policies and procedures at least annually, or when significant system, 
model, or regulatory changes occur.

Auditing guidelines

1. Verify that the CSP maintains a documented change management procedure specifically for cryptographic, encryption, and key management technologies, covering infrastructure-layer services (e.g., KMS, HSM, TLS endpoints).

2. Confirm that the procedure accommodates changes from both internal sources (e.g., platform enhancements, algorithm updates) and external sources (e.g., industry deprecations, regulatory mandates, customer requirements).

3. Review whether CEK-related change requests are tracked in a centralized system and routed through formal change review and risk assessment processes (e.g., CAB, security design review).

4. Verify that roles and responsibilities are clearly defined for CEK change request review, approval, testing, and rollout, including participation from cryptographic engineers, infrastructure leads, and compliance officers.

5. Confirm that each approved CEK change includes a structured implementation plan, with defined testing procedures, contingency/rollback steps, and timeline for execution.

6. Review how changes are communicated to internal teams (e.g., operations, DevOps, customer engineering) and external stakeholders (e.g., tenants impacted by changes to cryptographic behavior).

7. Validate that version control is enforced for encryption configurations, key policy templates, and any code or automation artifacts related to the CEK change.

8. Verify that post-implementation testing is conducted to validate the effectiveness of the change, including automated checks for service availability, encryption correctness, and logging integrity.

9. Confirm that full CEK change documentation is maintained, including testing results, implementation notes, approval evidence, and communications, and confirm that it is available for audits and tenant assurance requests.

10. Review whether CEK change management includes analysis of upstream dependencies (e.g., third-party crypto libraries, hardware appliances) and downstream impact on tenants and shared service consumers.

From CCM:

1. Examine policy and procedures and obtain evidence that these include the change management process.
2. Obtain representative samples of recent changes relating to cryptographic, encryption, and key management technology.
3. Confirm that sample changes have followed the organization's change management procedures, including approval by appropriate individuals, communication of changes to relevant stakeholders, and assessment of the success of implementing changes with any required remediation actions being tracked.

Standards mappings

ISO 42001Partial Gap
No Mapping for ISO 42001
ISO 27001: A.8.32
ISO 27002: 8.32
8.24
Addendum

Add a control mandating a standard change management procedure for cryptographic, encryption, and key management technology changes in AI systems, detailing review, approval, implementation, and communication processes for internal and external updates, enhancing ISO 27001 (A.8.32) and ISO 27002 (8.32, 8.24) for AI-specific applicability.

EU AI ActPartial Gap
Article 17 (1) (a)
Addendum

There is no EU AI Act coverage for "cryptographic, encryption, and key management technology changes."

NIST AI 600-1Full Gap
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 establishment of a standard change management procedure in such domain.

BSI AIC4No Gap
CRY-01
CRY-04
DEV-03
Addendum

N/A

AI-CAIQ questions (1)

CEK-05.1

Are standard change management procedures established to review, approve, implement, and communicate cryptography, encryption, and key management technology changes that accommodate internal and external sources?