AICM AtlasCSA AI Controls Matrix
LOG · Logging and Monitoring
LOG-12Cloud-Specific

Access Control Logs

Specification

Monitor and log physical access using an auditable access control system.

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

Design, Training, Guardrails, Supply Chain

Evaluation

Evaluation, Validation/Red Teaming, Re-evaluation

Deployment

Orchestration, AI Services supply chain, AI applications

Delivery

Operations, Maintenance, Continuous monitoring, Continuous improvement

Retirement

Archiving, Data deletion, Model disposal

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 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. Physical Access Control Integration: Use auditable access control systems (e.g., smart badges, biometrics) to monitor entry points where AI-related infrastructure or data is hosted. Synchronize physical access events with logical access logs for comprehensive visibility.

2. Centralized Logging and Monitoring: Collect and analyze logs from both physical entry systems and AI-specific events (model training, inference requests) in a unified monitoring environment. Enable real-time detection of anomalies by correlating physical entry with system activities.

3. Logging Security and Retention: Store physical access logs and AI event logs in an encrypted, access-controlled repository. Enforce defined retention periods based on regulatory requirements and organizational policies. Protect logs from tampering with immutability checks or other integrity mechanisms.

4. Automated Alerts and Anomaly Detection: Implement rule-based or AI-driven analytics to detect unusual patterns (e.g., after-hours facility entry followed by large-scale data transfers). Configure automated alerts to escalate suspicious activity to incident response teams.

5. Incident Response and Collaboration: Document clear escalation paths for AI-related security incidents involving physical intrusions. Share relevant logs and coordinate investigations across internal teams and external AI service providers to ensure swift remediation.

6. Regular Reviews and Continuous Improvement: Schedule periodic reviews that reconcile provider-side logs with consumer-side records, identifying discrepancies in physical or system access. Update log requirements, retention policies, and incident response playbooks in line with new AI use cases or emerging threats.

Auditing guidelines

1. Inquiring with Control Owners

1.1 Conduct interviews with personnel responsible for monitoring and logging physical access using auditable access control systems for cloud infrastructure and AI processing facilities to understand their processes for tracking, recording, and reviewing physical access to data centers, compute clusters, and customer workload environments. Verify their understanding of access control system monitoring capabilities for cloud infrastructure, logging procedures for physical access to customer tenant facilities and AI processing resources, and audit trail requirements that ensure all physical access activities affecting infrastructure security and customer data protection are properly documented and reviewable.

2. Inspecting Records and Documents

2.1 Verify physical access control systems are in place for all cloud infrastructure environments, including data centers, AI processing clusters, customer tenant facilities, and compute resource centers.

2.2 Check logging mechanisms capture physical access timestamps, user identity, and location for cloud infrastructure facilities and customer workload environments.

2.3 Confirm physical access logs are retained in accordance with customer protection and regulatory compliance requirements for cloud infrastructure operations.

2.4 Validate alerts are generated for unauthorized or after-hours physical access to cloud infrastructure facilities and customer data centers.

2.5 Review role-based access controls to ensure only authorized infrastructure personnel can retrieve physical access logs for cloud environments.

2.6 Confirm periodic audits assess physical access adherence across all cloud infrastructure facilities and customer data protection areas.

2.7 Examine whether physical access logs are integrated into centralized SIEM systems for correlation with cloud infrastructure security and customer protection events.

2.8 Verify encryption is applied to stored physical access logs for cloud infrastructure facilities.

2.9 Review monitoring procedures and capabilities of the physical access control system to ensure real-time visibility into physical access events affecting cloud infrastructure and customer environments.

2.10 Validate that the access control system provides comprehensive audit trails with tamper-evident logging for all physical access activities in cloud infrastructure and customer facilities.

2.11 Examine backup and recovery procedures for cloud infrastructure physical access control system logs to ensure continuity of audit capabilities for customer protection and regulatory compliance.

2.12 Verify CSP data center physical access logs meet ISO/IEC 27001 and SOC 2 standards.

2.13 Ensure detailed audit trails exist for infrastructure used by regulated or high-risk tenants.

2.14 Check physical access logs are securely stored and cryptographically protected.

2.15 Confirm that access to physical access log systems themselves is restricted and monitored.

2.16 Validate that all physical access events are automatically reconciled with badge activity.

2.17 Review retention and redaction protocols for tenant-specific physical access logs.

2.18 Confirm customer audit rights for physical access under contractual obligations.

2.19 Ensure physical access logs are regularly shared with tenants under shared responsibility models.

2.20 Verify physical access controls and logging meet SOX compliance requirements for financial reporting systems and customer data protection.

2.21 Validate physical access monitoring supports SOC audit requirements and control effectiveness testing.

Standards mappings

ISO 42001Partial Gap
No Mapping for ISO 42001
ISO 27001 A.7
Addendum

No ISO 42001 control maps to LOG-12 topic.

EU AI ActFull Gap
No Mapping
Addendum

Monitoring and logging of physical access.

NIST AI 600-1Full Gap
MG-3.2-008
Addendum

Need to add guidance regarding physical access.

BSI AIC4No Gap
C4 DM-02
C5 PS-04
Addendum

N/A

AI-CAIQ questions (1)

LOG-12.1

Is physical access logged and monitored using an auditable access control system?