AICM AtlasCSA AI Controls Matrix
IAM · Identity & Access Management
IAM-07Cloud & AI Related

User Access Changes and Revocation

Specification

De-provision or modify identity access in a timely manner.

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

Team and expertise, Data storage, Resource provisioning, Data curation

Development

Training, Guardrails, Supply Chain

Evaluation

Evaluation, Validation/Red Teaming, Re-evaluation

Deployment

Orchestration, AI Services supply chain, AI applications

Delivery

Operations, Maintenance

Retirement

Archiving, 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 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.

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. Define time-bound policies for revoking access upon role change, termination, or inactivity.

2. Automate access modification and revocation workflows based on triggers (e.g., HR system updates).

3. Revoke all credentials and tokens (passwords, API keys, cloud roles, third-party SaaS entitlements) and/or any standing sessions the user still holds.

4. Detect and handle orphaned or dormant accounts; auto-disable or flag them for immediate review.

5. Log every modification or revocation action to an immutable store for audit, forensics and compliance reporting.

6. Run periodic access-list reviews to validate that current entitlements match active business roles and projects; document any exceptions and corrective actions.

Auditing guidelines

1. Review CSP’s automated de-provisioning mechanisms.

2. Confirm revocation includes access to cloud APIs, consoles, and back-end storage.

3. Verify that emergency revocation (e.g., threat detection) is supported and logged.

From CCM:
1. Determine if a process is established for removing logical access when users leave the organization or when access is no longer appropriate.
2. Determine if a timeframe for access removal and access modification is defined.
3. Verify that a process is established for removing existing system access and assigning appropriate access or for modifying existing access after internal transfer or change of job functions.
4. Determine if established processes for access removal and modification, within the defined time frame, are followed in practice.

Standards mappings

ISO 42001No Gap
42001: A.2.3 - Alignment with other organizational policies
42001: A.2.4 - Review of the AI policy
27001: A.5.1 - Policies for information security
27001: A.5.18  - Access rights
Addendum

N/A

EU AI ActPartial Gap
Article 8
Article 9
Article 10
Article 13
Article 20
Addendum

In the EU AI Act, the specific word "deprovisioning" is not mentioned explicitly in Article 20.

NIST AI 600-1Full Gap
No Mapping
Addendum

No explicit reference to the definition and implementation of a user access de-provisioning or change process is made in the NIST AI 600-1 standard. The latter mentions "user access removal" as part of the process of deactivation or disengagement of AI systems that is recommended to be established. The provision is, therefore, AI-related and has been interpreted as out of scope in comparison to the aspects of identity and access management (users deprovisioning) on which the AICM control focuses.

BSI AIC4No Gap
C4 DM-01
C4 DM-02
C5 IDM-03
C5 IDM-04
Addendum

N/A

AI-CAIQ questions (1)

IAM-07.1

Is identity access de-provisioned or modified, in a timely manner?