Identity compliance requirements Reference guide Last updated August 2025

Ready to simplify access management?

We'd love to help you get to more maintainable access controls

Authorization

Authorization controls what resources users can access and what actions they can perform after authentication. Authorization ensures both that users have the access they need for their job function, as well as limiting sensitive systems and data from unnecessary and unauthorized access.

The compliance requirements below can be implemented in many different ways — and confusingly, can also overlap. For example, just-in-time access is a way of implementing a process for emergency access; and multi-party approval could be used to meet requirements for segregation of duties. Understand the scope of your organization's requirements and consider if your existing controls meet requirements before implementing additional controls.

Role-Based Access Control (RBAC)

Role-based access control is an access control model that groups permissions into roles aligned with job functions, rather than assigning permissions to individual users.

Common compliance requirements

  • Documentation of roles and permissions
  • Process for creating, modifying, and deleting roles
  • Process for assigning roles to employees
  • Restrictions on inappropriate role combinations
  • Regular reviews of roles and permissions against business needs
  • Regular reviews of employee role assignments, possibly including reviewing usage patterns

Privileged Access Management (PAM)

Privileged access refers to sensitive administrative accounts and permissions, such as those that can modify systems, access sensitive data, or change security controls. This often refers to administrative accounts, including root privileges or "super admin" permissions. These permissions are typically used by security, IT, DevOps, or SRE.

Common compliance requirements

  • Process for requesting, approving, and using privileged accounts
  • Inventory and classification of privileged accounts
  • Encrypted storage of privileged account credentials
  • Restrictions for separating privileged and non-privileged accounts, i.e. separate accounts for personal vs. administrative duties
  • Restrictions on sharing privileged accounts, i.e. separate accounts for each admin
  • Time-based restrictions on privileged access
  • Logging, monitoring, recording or escorting privileged access sessions
  • Regular reviews of privileged access usage

Just-in-Time (JIT) access

Just-in-time access provides elevated permissions only when needed and automatically revokes them after use, reducing the risk of standing privilege.

Although Privileged Access Management (PAM) and Just-in-Time (JIT) access both restrict the usage of sensitive permissions, these are typically implemented differently. In PAM, a user invokes the use of an existing privileged account — which may be specific to them or shared by many users in the same role — and their access is removed after use. Whereas in JIT, an account with elevated permissions is created on demand or specific elevated permissions are temporarily added to their existing account; this account is used only by them, and deleted after use.

Common compliance requirements

  • Process for requesting and approving temporary elevated access
  • Time-based restrictions on elevated access
  • Logging, monitoring, recording or escorting elevated access usage
  • Regular reviews of elevated access usage

Segregation of Duties (SoD)

Segregation or separation of duties prevents individuals from having permission combinations that could enable them to perform highly sensitive or malicious activities, such as fraud. Segregation of duties may be implemented as part of general role assignment, but can also be implemented as part of specific workflows, e.g., so that a user who has both a privileged and a non-privileged account cannot use them in combination to perform a sensitive action single-handedly, or unilaterally.

Segregation of duties typically means that some activities, such as transferring money, deleting an account, or accessing user data, requires a second user's approval (multi-party approval).

Common compliance requirements

  • Restrictions on incompatible combinations of roles or permissions
  • Controls to prevent incompatible role assignments
  • Process for managing, approving, and documenting exceptions
  • Regular reviews of role and permission assignments for SoD violations

Emergency access management

Emergency access procedures allow users to access sensitive systems during critical situations while maintaining security controls. Emergency access may be automatically provisioned, for example, to SREs when they are on-call, or may be granted on-demand, such as after declaring an incident.

Common compliance requirements

  • Documentation of criteria for emergency access usage
  • Process for invoking emergency access usage
  • Encrypted storage of emergency access credentials
  • Multi-party approval requirements for emergency access
  • Time limitations on emergency access, i.e. emergency access is short-lived, not permanent
  • Logging, monitoring, recording or escorting emergency access usage
  • Post-incident reviews of emergency access usage
  • Regular testing of emergency access procedures

Multi-party approval

Multi-party approval requires high-risk changes to be approved by multiple authorized individuals. These could include sensitive access grants, exceptions to access requirements, the use of specific permissions, or specific operations.

Two-party control is a kind of multi-party approval where changes need two individuals to be made (or "two sets of eyes"): the individual requesting the change and the individual approving the change.

Common compliance requirements

  • Documentation of changes requiring multiple approvals
  • Process for approvals
  • Process for emergency approvals
  • Minimum number of required approvers
  • Types of required approvers, e.g., a security approver plus a manager
  • Separation of duties between requestors and approvers, i.e. a requestor cannot approve their own request
  • Logging of approval decisions

Remote access

Remote access creates additional security risks that require stronger authentication controls than standard internal access.

Since remote users connect over untrusted networks where traditional network security controls don't apply, organizations often need alternative methods to verify and validate users' identities. This could include analyzing context like user location and device characteristics, or implementing strong authentication requirements like multi-factor authentication. This is usually a combination of authentication and authorization controls.

Common compliance requirements

  • Enhanced authentication requirements for remote access
  • Use of VPN or secure tunnel
  • Restrictions on access based on geography or IP address
  • Restrictions on access based on time
  • Restrictions on access based on device properties or characteristics
  • Enhanced monitoring and logging