Least privilege is the easiest control to write and the hardest to show. Every security policy says users get the minimum access their job requires. Very few companies could produce, on request, a list of what that minimum is for each job.
The gap is not intent. It is that access grows by accretion. Someone needs write access for a migration, an engineer is given admin to debug an outage, a new hire gets "the same as" a colleague who has been collecting permissions for three years. Nobody grants excess access on purpose. It arrives one reasonable request at a time.
This article covers what the frameworks ask, how to design roles that make least privilege the default, how to find and remove the excess you already have, how to handle segregation of duties on a small team, and what evidence shows the control is working.
What the frameworks ask for
The requirement appears everywhere, in slightly different words.
SOC 2 CC6.3 asks that access is authorized, modified, or removed based on roles, responsibilities, or the system design, giving consideration to least privilege and segregation of duties.
ISO 27001:2022 spreads it across Annex A 5.15 (access control), 5.18 (access rights), 8.3 (information access restriction), and 5.3 (segregation of duties).
NIST SP 800-53 Rev. 5 has AC-6 (least privilege) with enhancements for privileged accounts and for reviewing user privileges, and AC-5 for separation of duties.
PCI DSS v4.0 Requirement 7 restricts access by business need to know, with access assigned by job classification and function at the least privilege necessary.
The HIPAA Security Rule covers it through information access management at 45 CFR 164.308(a)(4). The Privacy Rule's minimum necessary standard is a related but separate requirement about uses and disclosures of PHI.
None of them tells you what the right permissions are. That is deliberate: it depends on your systems and your jobs. What they share is an expectation that access follows a defined role, is approved, and is reviewed. If you work to NIST, start from our overview of NIST SP 800-53.
Start from roles, not from people
Least privilege fails when access is granted per person. It holds when access is granted per role and people are placed into roles.
A role catalog does not need to be elaborate. For each role, record:
The role name and owner. The owner is the person who decides what the role should include, usually the team lead.
The systems in scope. Identity provider groups, cloud accounts, source control, production databases, support tooling.
The permission level in each system. Read, write, deploy, administer, and read customer data, kept as separate levels.
What is birthright and what is requested. Birthright access arrives with the role. Everything else goes through a request and approval.
Then implement the catalog in the identity provider. Each role becomes a group, and each group maps to permissions in the downstream systems. When access follows group membership, changing a role means changing one group rather than fifteen individual grants. If those systems are federated, SSO as a compliance control covers how the identity provider becomes the place where this is enforced.
Separate the permission levels that matter
Not all access is equal. The useful distinction is between levels that change the risk materially.
Reading customer data is its own permission. An engineer who can deploy code does not automatically need to query production tables. A support agent who can see a ticket does not automatically need to impersonate the customer's account. Treat customer data access as a separate grant with its own approval.
Deploying and administering are different. Deploy rights let someone ship an approved change through the pipeline. Administrative rights let someone change the pipeline, the infrastructure, or other people's access. Most engineers need the first. Few need the second as a standing permission.
Wildcards hide privilege. Cloud permission policies that grant every action on a service, or every resource in an account, are the usual source of unintended administrative access. They are worth searching for directly.
Administrative access needs more than role design: separate accounts, time-limited elevation, and logging of what was done. It is worth treating as its own control rather than one level among others.
Find the excess you already have
Most teams start with years of accumulated access. Fixing it in one pass rarely works, because removing access that someone uses breaks things, and the next request for access then bypasses the process.
A workable sequence:
List who holds administrative or customer-data access in each in-scope system. This list is usually shorter than the full population and carries most of the risk.
Use last-used data where the system provides it. Most cloud platforms report when a permission or credential was last exercised. Permissions unused for a long period are the first candidates for removal.
Ask the role owner, not the user. "Does this role need this?" gets a better answer than "Do you need this?"
Remove in stages and announce it. Give people a short window and a fast way to request access back.
Record each change. A ticket per removal, or a dated export before and after, is evidence that the clean-up happened and when.
Make requesting access fast. If an approval takes two days, people hold on to access they might need. A quick, recorded request path is what makes least privilege sustainable.
Segregation of duties on a small team
Segregation of duties means no single person can both perform and approve a sensitive action. The classic examples are writing and approving a code change, and requesting and granting access.
Small teams cannot always separate these completely. A five-person company may have one person who administers the cloud account. Auditors understand this. What they look for is that you have identified where duties are combined and put a compensating control in place:
Changes made by the sole administrator are logged to a place they cannot alter.
Someone else reviews those logs, or a summary of administrative actions, on a schedule.
The combination is documented, with the reason and the compensating control.
What does not hold up is combined duties that nobody has noticed. Write them down before the auditor finds them.
What evidence shows it is working
You cannot prove least privilege directly. No export says "these are the minimum permissions." What you can prove is that the process producing access is controlled. Expect an auditor to look for:
The role catalog, with a date and an owner.
User-to-role mapping, exported from the identity provider.
Access requests and approvals for a sample of grants outside birthright, showing approval before access was given.
Periodic review results, with the reviewer's decisions and the resulting removals.
A list of privileged accounts per in-scope system, and the justification for each.
For SOC 2, these artifacts sit under CC6 alongside provisioning and removal. What the SOC 2 security criterion actually requires shows how CC6 fits with the rest of the common criteria.
How TrustLynce helps
TrustLynce continuous monitoring runs control checks against the identity and cloud systems you connect and routes each failure to its owner, so access drift is raised during the period rather than discovered at the next review.