Permissions inherited from groups, not users
Demonstrate that access permissions throughout the environment are granted through group membership and that direct user-level permission assignments are either prohibited or documented as exceptions with appropriate justification.
Description
What this control does
This control requires that access permissions to systems, applications, and data resources be assigned through group membership rather than directly to individual user accounts. When a user requires access, they are added to a group with the appropriate permissions rather than granting permissions to the user object itself. This approach centralizes permission management, reduces administrative overhead, and ensures consistent application of access policies. Group-based inheritance also facilitates auditing by creating clear permission structures that can be reviewed programmatically and reduces the risk of orphaned permissions persisting after role changes.
Control objective
What auditing this proves
Demonstrate that access permissions throughout the environment are granted through group membership and that direct user-level permission assignments are either prohibited or documented as exceptions with appropriate justification.
Associated risks
Risks this control addresses
- Permissions granted directly to users remain undetected when performing group-based access reviews, allowing unauthorized access to persist
- Direct user permissions bypass centralized approval workflows and change management processes, enabling privilege escalation outside formal controls
- Administrators struggle to identify all permissions held by a user during offboarding or role changes, leading to incomplete access revocation
- Inconsistent permission assignments create configuration drift where users with identical roles have different access levels, violating least privilege principles
- Orphaned direct permissions accumulate over time as users change roles, creating undocumented access pathways exploitable by insiders or compromised accounts
- Audit trails become fragmented when permissions exist at multiple levels, obscuring who authorized specific access grants and when
- Automated provisioning and deprovisioning systems fail to detect or manage direct user permissions, leaving gaps in identity lifecycle management
Testing procedure
How an auditor verifies this control
- Obtain an inventory of all systems, applications, and data repositories within scope that support role-based or group-based access control mechanisms.
- Export access control lists, permission assignments, and group membership data from representative systems including Active Directory, cloud IAM platforms, databases, and enterprise applications.
- Execute queries or scripts to identify all permissions assigned directly to user objects rather than through group membership across sampled systems.
- Select a representative sample of 20-30 user accounts spanning different roles, departments, and privilege levels for detailed permission analysis.
- Review each sampled user account to enumerate all direct permission assignments and verify whether documented exception processes exist for each instance.
- Interview system administrators and identity management personnel to confirm the existence and enforcement of policies prohibiting direct user permission grants.
- Examine change management records and ticketing systems to verify that any identified direct permissions were authorized through formal exception approval processes.
- Test group membership changes by selecting a recent role change or offboarding event and verify that permission removal occurred solely through group membership revocation without residual direct grants.
Where this control is tested