Least Privilege Access: The Control That Shows Up in Every Framework and Fails in Most Audits
If you have reviewed the control requirements for SOC 2, CMMC, and ISO 27001, you have noticed that they share significant overlap in certain areas. No single concept appears more consistently across all three frameworks than least privilege access: the principle that users, systems, and processes should have access only to the resources they need to perform their specific function, and nothing more.
It is one of the most foundational security controls in existence.
It is also one of the most consistently underdeveloped in real-world compliance programs. Here is what the control actually requires across frameworks, why it fails in practice, and what a functional least privilege program looks like.
What Each Framework Requires
SOC 2 addresses least privilege primarily through CC6.3, which requires that access to system components is restricted on a need-to-know basis and that access is removed when no longer required. CC6.6 extends this to logical access controls for infrastructure and software. Auditors testing these criteria evaluate whether your access model is designed around job function and whether access provisioning follows a documented, authorized process.
CMMC Level 2 addresses least privilege through AC.1.001 and AC.2.006 in the access control domain. AC.1.001 requires limiting system access to authorized users and the transactions and functions they are permitted to execute. AC.2.006 specifically calls out the principle of least privilege, requiring that organizational processes and system accounts are configured to provide only the access required for their defined function.
ISO 27001 addresses least privilege through Annex A control A.9.2.3, which requires restriction of access rights, and A.9.4.1, which addresses restrictions on access to information and application system functions. The 2022 version of the standard consolidates and strengthens these requirements under the access control domain.
Three different frameworks. Three different citation structures. The same underlying requirement: access should be proportional to need, and nothing more.
Why It Fails in Practice
The technical implementation of least privilege is well understood. The organizational discipline required to maintain it over time is where programs break down.
Access accumulates. A user receives elevated access to complete a project. The project ends. The access is not removed. Six months later, that user has permissions to systems they no longer interact with and do not need. Multiply this by a growing team over multiple years and you have an access model that reflects the history of your organization rather than its current structure.
Privileged accounts proliferate. Developer environments, service accounts, and administrative roles accrue over time. Admin access granted "temporarily" for a configuration task becomes permanent because removing it requires a ticket, a review, and someone with the authority to approve the removal. The path of least resistance is to leave it.
Role definitions drift. Access is provisioned based on job title or team membership. Job functions evolve. New tools are added. Role definitions that were accurate two years ago no longer match what people actually do, which means access provisioned against those definitions no longer matches what people actually need.
The result is an access model that looks nothing like least privilege in practice, regardless of what your access control policy says. Auditors see this pattern frequently. They look for it specifically because they know how common it is.
What a Functional Least Privilege Program Requires
Defined roles with documented access requirements. Access provisioning should start from a role definition, not from a request. Each role should have a documented set of access entitlements that reflects what that function actually needs. New user access is provisioned against the role definition, not granted ad hoc.
A provisioning and deprovisioning workflow. Access requests should require documented authorization. Access removal should be triggered automatically or by a defined process when employment ends or role changes. The workflow should create evidence — tickets, approvals, system logs — that auditors can sample.
Privileged access management. Administrative and service accounts should be inventoried, reviewed, and subject to stricter controls than standard user accounts. Shared administrative credentials — a single admin password known to multiple people — are a specific finding in both SOC 2 and CMMC assessments.
Regular access reviews. As described in the access review post, periodic review of current access against current role definitions is the mechanism that catches drift before it compounds. The review process and least privilege principle are the same control operating on different timescales: provisioning gets it right initially, access reviews keep it right over time. See our post on access reviews for SOC 2 for a detailed breakdown of what those reviews need to include.
The Privileged Access Problem in SaaS Environments
SaaS companies have a specific version of this problem: cloud infrastructure accounts. AWS IAM policies, Azure role assignments, and GCP service account permissions are notoriously difficult to keep clean. Engineers working in fast-moving development environments frequently need broad access during build phases, and that access is rarely scoped back down when the build is complete.
Cloud infrastructure least privilege is tested directly in SOC 2 audits and CMMC assessments for organizations with cloud CUI environments. Auditors will ask for evidence of IAM policy reviews and will look for wildcard permissions, overly broad service account roles, and administrative access granted to accounts that should have read-only access. A compliance readiness assessment reviews your access model before your auditor does.
