AICM AtlasCSA AI Controls Matrix
LOG · Logging and Monitoring
LOG-11Cloud & AI Related

Transaction/Activity Logging

Specification

Log and monitor key lifecycle management events to enable auditing and reporting on usage of cryptographic keys.

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

Development

Training

Evaluation

Re-evaluation

Deployment

Orchestration, AI Services supply chain, AI applications

Delivery

Operations, Maintenance, Continuous monitoring, Continuous improvement

Retirement

Archiving

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

[All Actors]
1. Dedicated Logging Framework for Cryptographic Events: Implement a logging framework that records key lifecycle management operations (e.g., generation, rotation, revocation). Include relevant AI model usage events (e.g., data ingestion, inference requests, hyperparameter changes) to correlate cryptographic key actions with AI workflows.

2. Centralized Log Management and Access Controls: Store cryptographic key logs and AI-related logs in a centralized, secure system. Enforce strong authentication and granular, role-based permissions to ensure only authorized personnel can view or modify logs.

3. Continuous Monitoring and Alerting: Use real-time analytics and alerting to detect suspicious key usage (e.g., unexpected key rotations, unauthorized decryption attempts) and abnormal AI model behavior (e.g., large-scale inference spikes). Define escalation paths for key-related incidents, linking them to AI incident response processes where appropriate.

4. Lifecycle Traceability and Auditing: Maintain comprehensive records of key usage, model updates, and data changes for complete traceability. Periodically review logs for anomalies, errors, or policy violations, and ensure logs are retained according to data classification and regulatory requirements.

5. Incident Response and Reporting: Define a collaborative incident management process among internal teams and service providers to investigate cryptographic or AI-related security incidents. Clearly assign incident ownership, notification protocols, and root cause analysis responsibilities.

Auditing guidelines

1. Inquiring with Control Owners

1.1 Conduct interviews with personnel responsible for logging and monitoring key lifecycle management events for cloud infrastructure to understand their processes for capturing, analyzing, and reporting on cryptographic key usage for customer data protection and infrastructure security. Verify their understanding of key lifecycle event logging requirements for cloud operations, monitoring procedures for encryption keys protecting customer workloads, and reporting capabilities that enable auditing and compliance oversight of cryptographic key management activities in AI processing infrastructure.

2. Inspecting Records and Documents

2.1 Verify that cryptographic key usage for cloud infrastructure data encryption, customer workload protection, and compute resource security is logged by the infrastructure management systems.

2.2 Confirm logs include timestamped records of key creation, use, rotation, and destruction for cloud infrastructure operations, customer data protection, and tenant isolation security.

2.3 Ensure visibility into key usage by different cloud infrastructure components, compute cluster services, and customer tenant systems.

2.4 Validate alerts are generated on suspicious or unauthorized key operations affecting cloud infrastructure security or customer data protection.

2.5 Check alignment with internal policy for lifecycle monitoring of keys used within cloud infrastructure for customer isolation and service availability protection.

2.6 Review SIEM or monitoring tool integrations that centralize and analyze cloud infrastructure key-related activities and customer protection events.

2.7 Confirm audit trails exist for every critical key management operation supporting cloud infrastructure functionality and customer data security.

2.8 Examine reporting capabilities and procedures for generating cloud infrastructure key lifecycle management reports to support customer compliance and infrastructure security auditing requirements.

2.9 Review log retention policies and practices to ensure cloud infrastructure key lifecycle event records are maintained for customer protection and regulatory compliance timeframes.

2.10 Validate that key lifecycle monitoring covers all cloud infrastructure cryptographic operations including customer data encryption, compute security, and infrastructure backup protection activities.

2.11 Verify cloud KMS and HSM services generate logs for all key operations (create, use, rotate, delete).

2.12 Confirm customer access to logs through secure APIs or dashboards.

2.13 Review policies ensuring that all key usage is auditable and traceable to specific identities.

2.14 Check real-time alerting is in place for abnormal or failed key transactions.

2.15 Ensure audit logs support chain-of-custody for regulatory compliance.

2.16 Confirm backup and retention policies preserve transaction logs for cryptographic events.

2.17 Validate internal reviews of key usage logs are conducted regularly.

Standards mappings

ISO 42001Partial Gap
No Mapping for ISO 42001
ISO 27001 8.24
ISO 27001 9.1
ISO 27001 9.2
Addendum

No ISO 42001 control maps to LOG-11 topic.

EU AI ActFull Gap
No Mapping
Addendum

The EU AI Act does not provide for the monitoring of the use of encryption keys and/or cryptographic operations.

NIST AI 600-1Partial Gap
MP-2.3-003
Addendum

Specifically requiring lifecycle management events.

BSI AIC4No Gap
C4 DM-03
C4 RE-02
C5 CRY-04
Addendum

N/A

AI-CAIQ questions (1)

LOG-11.1

Are key lifecycle management events logged and monitored to enable auditing and reporting on cryptographic keys' usage?