IAM · Identity and Access Management
IAM-01 Policy for Identities and Access Rights
Changed since C5:2020 · formerly IDM-01
Basic criterion
Specified which data types the criterion applies to.
Split up first requirement into a list for better readability.
Extended aspects to be adressed by the documents by aspects to be considered for access control decisions, use of a role-based mechanism, definition of the different types of identities and role-based access supported, assignment and monitoring of privileged access rights, remote access or access across geographic boundaries, and measures for the case of identity compromise.
Added requirement for the cloud service provider to maintain a list of all users and their access rights.
Bullet points are now sorted to ease discussions about specific list items.
Additional criterion
Additional criterion newly included.
Wording in C5:2020
Basic criterion
A role and rights concept based on the business and security requirements of the Cloud Service Provider as well as a policy for managing user accounts and access rights for internal and external employees of the Cloud Service Provider and system components that have a role in automated authorisation processes of the Cloud Service Provider are documented, communicated and made available according to SP-01:
- Assignment of unique usernames;
- Granting and modifying user accounts and access rights based on the “least-privilege- principle” and the “need-to-know” principle;
- Segregation of duties between operational and monitoring functions (“Segregation of Duties”);
- Segregation of duties between managing, approving and assigning user accounts and access rights;
- Approval by authorised individual(s) or system(s) for granting or modifying user accounts and access rights before data of the cloud customer or system components used to provision the cloud service can be accessed;
- Regular review of assigned user accounts and access rights;
- Blocking and removing access accounts in the event of inactivity;
- Time-based or event-driven removal or adjustment of access rights in the event of changes to job responsibility;
- Two-factor or multi-factor authentication for users with privileged access;
- Requirements for the approval and documentation of the management of user accounts and access rights.
Basic criterion
The cloud service provider documents, communicates and makes available according to SP-01:
- An authorisation framework based on role-based access control and the business and security requirements of the cloud service provider; and
- A policy for managing identities and access rights for internal and external personnel of the cloud service provider and system components that have a role in automated authorisation processes of the cloud service provider.
Supplementary information
External personnel includes freelancers, temporary workers, suppliers and service providers with access to system components.
Supplementary information
Also applies to 02B
Requirements for physical access control in accordance with the policy for identities and access rights are specified in more detail in the physical access control policy (cf. PS-04).
If the cloud service provider offers federated identity services, in particular if the cloud service provider offers these services as a cloud service broker, the documents defined in these subcriteria should recognise the complexity of the particular cloud service architecture. This can include, but is not limited to, the following aspects:
- Management of the trust boundaries between the different parties involved in the authentication process of a federated identity;
- Propagation of identity management-related events across all parties involved in the authentication process of a federated identity;
- Logging of events related to the authentication process of a federated identity; and
- Notification of cloud service customers in case of a federation credential being compromised or a trust boundary being violated.
For the purpose of the business and security requirements these documents address at least the following aspects:
- Aspects that are relevant for making access control decisions;
- Assignment of unique usernames;
- Granting and modifying identities and access rights based on the 'least-privilege-principle' and the 'need-to-know-principle';
- Application of a role-based mechanism for assigning access rights;
- Definition of the supported identity and role-based access types, including an assignment of access control parameters and roles to be considered for each type;
- Segregation of duties between operational and monitoring functions ('Segregation of Duties');
- Assigning and monitoring privileged access rights;
- Approval by authorised individual(s) or system(s) for granting or modifying identities and access rights before cloud service customer data, cloud service derived data and cloud service provider data can be accessed;
- Regular review of assigned identities and access rights;
- Blocking and removing identities or limiting access in the event of inactivity;
- Specific measures for managing identities whose use is restriced to emergency recovery and similar scenarios;
- Time-based or event-driven removal or adjustment of access rights in the event of changes to job responsibility;
- Multi-factor authentication for users with privileged access;
- Remote access and access across geographic boundaries;
- Requirements for approving and documenting the management of identities and access rights; and
- Measures to be taken upon the detection of a potential identity compromise, such as disabling and removing the affected identities.
Supplementary information
System components in the sense of the criterion are defined in OPS-26. Automated authorisation processes in the sense of this basic criterion concern procedures for automated software provisioning (continuous delivery) as well as for automated provisioning and deprovisioning of identities and access rights based on approved requests.
For containers, identities and access rights should be managed according to a regulated process, especially for automated authorisation processes in container environments.
If a cloud service provider uses alternative access methods for which it is not possible or feasible to block and remove identities (such as time-bounded access methods), limiting the access to an identity is an another solution for handling inactivity that fulfils this subcriterion.
Supplementary information
Also applies to 01B
Requirements for physical access control in accordance with the policy for identities and access rights are specified in more detail in the physical access control policy (cf. PS-04).
If the cloud service provider offers federated identity services, in particular if the cloud service provider offers these services as a cloud service broker, the documents defined in these subcriteria should recognise the complexity of the particular cloud service architecture. This can include, but is not limited to, the following aspects:
- Management of the trust boundaries between the different parties involved in the authentication process of a federated identity;
- Propagation of identity management-related events across all parties involved in the authentication process of a federated identity;
- Logging of events related to the authentication process of a federated identity; and
- Notification of cloud service customers in case of a federation credential being compromised or a trust boundary being violated.
The cloud service provider is capable of producing a list of the currently granted cloud-based access rights for each identity under its responsibility.
Supplementary information
Based on this list, the cloud service provider is able to review the cloud-based access rights of the given identity.
'Cloud-based' in this case refers to all of the access rights that are within the scope of the cloud service provider's system of internal control.
Additional criterion
IAM-01.01AC
Additional, complementingAccess logs are reviewed at least every month in order to detect attempts of unauthorised access or suspicious access patterns.
Supplementary information
A review can be carried out manually or via automated manners. In a monthly review, suspicious behaviours like e.g. access failures over a larger time frame (e.g. once a day) or consecutive logins from different countries may show up that a SIEM that only analyses real-time login attemps may overlook.
Related criteria
BSI text from C5:2026 and its changelog: © Federal Office for Information Security 2026, reproduced unchanged under CC BY-ND 4.0. Unofficial site, not affiliated with BSI. Licence and sources