SOC 2 · Trust Services Criteria · 3 min read

SOC 2 CC6.3: least privilege, explained for startups

What CC6.3 asks you to show about least privilege, and what proves it.

People get the access their role needs and no more, and that access is reviewed. Admin rights are rare and named. A periodic access review catches what drifted, and changes in role trigger a change in access.¹

CC6.3 is a common criterion, so it is part of every SOC 2 report.

What usually proves it

An auditor wants records from the period being examined, pulled from the systems that hold them rather than written up afterwards. Dates matter. A record with a date and a named owner carries more weight than a screenshot with neither. For CC6.3, the usual records are these.

User access review records with decisions and sign off
A role to permission matrix
Tickets for access changes when people move roles

What Polara asks about it

The free readiness assessment asks 5 questions that bear on CC6.3. A yes becomes a task to show the proof. A no becomes a task to fix the gap, with the steps written out.

Role-based access for production systems? If yes, show it: AWS identity and access management (IAM) groups and roles screenshot, Okta groups list, Azure Active Directory group assignments, or role-based access control (RBAC) matrix export. If no, the fix: define production roles, assign access through those roles only, and export the role configuration.
User access removed within 24 hours of termination? If yes, show it: offboarding ticket, deprovisioning log from your human resources system to Okta, access removal checklist, or terminated user access report. If no, the fix: add a 24 hour access removal step to the offboarding checklist and retain the completed checklist for each departure.
How often is a documented review of all user access to production performed? If yes, show it: signed access review record, a user list export carrying the reviewer name and date, the access review ticket with the removals it produced, or an identity provider access review report. If no, the fix: review every production account at least quarterly and retain the completed review with its reviewer and its date.
Is access to production approved by a named manager before it is granted? If yes, show it: access request ticket showing the approver and the date, an identity provider access request record, an approval email saved to the ticket, or a signed access request form. If no, the fix: require a named manager to approve each production access request and retain the approval record.

It also asks, for context:

Number of privileged admins for production.

Policies, templates and connected evidence

A policy states the rule, a template gives you the record to keep, and a connected system pulls the proof from the source. An auditor checks that the three agree: the cadence in the policy, the dates in the record and what the system shows.

In the policy pack, the Access Control Policy covers CC6.3.

Free templates that help, printed in full with Word, PDF or Excel downloads:

Connected systems that pull evidence for it:

Amazon Web Services, IAM users: who has access, with each user's multi-factor authentication status and last login.
Amazon Web Services, IAM roles: privileged roles and the trust policies that grant them.
Amazon Web Services, IAM groups: groups and their member assignments.
GitHub, Organization members: all members of the organization with their access type.
GitHub, Organization teams: teams in the organization and their permissions.
GitHub, Repository collaborators: per-repository collaborator access, including outside collaborators.
Google Cloud, IAM members: project-level IAM policy bindings, showing which roles are granted to which members.
Google Workspace, Directory users: all users in the Workspace domain with admin, suspended and 2-Step Verification enrollment status.
Google Workspace, Directory groups: all groups in the Workspace domain with member counts.
Okta, Users and last sign-in: Okta users with their status and last sign-in time.
Okta, Admin role assignments: the users who hold an Okta admin role, and which role each one holds.
Okta, Deprovisioned users: users deprovisioned in the collection window, with the date their status changed.
Microsoft Entra ID, Users and last sign-in: directory users with their enabled status, user type and last sign-in.
Microsoft Entra ID, Privileged role assignments: directory role assignments, including who holds Global Administrator.
Linear, Workspace members: Workspace members with their active, admin and guest status.
Jira, Site users: users on the Jira site with their active status and account type.
Slack, Workspace members: Workspace members, admins, guests and deactivated accounts.

If you also run ISO 27001, the Annex A controls A.5.15, access control rules, A.5.18, granting and removing access, A.8.2, privileged access and A.8.3, restricting access to data ask for overlapping evidence. One record can serve both when it names what it proves.

Where it goes wrong

One gap a remediation playbook covers here is role-Based Access Control. The fix: define access roles and document who has what level of access. The proof: access control matrix or IAM role listing showing user-to-role mappings.

An auditor asks two things about it. Is there a documented role-based access control model? Are user access levels defined and mapped to roles in the system?

Is it in your scope?

Yes, always. CC6.3 is one of the 33 common criteria, and the common criteria are in every SOC 2 report, Type 1 or Type 2. The common criteria. Every SOC 2 report covers them, whatever else you add: governance, risk, access, operations, change and vendors. Most of the work in any SOC 2 sits here.

Polara Labs is not a CPA firm. SOC 2 examinations are performed by independent licensed U.S. CPA firms.

Logical and physical access: the criteria around it

CC6.3 is one of 8 criteria in logical and physical access, CC6.1 to CC6.8. Reading a group together shows how its outcomes fit, and one record often serves more than one of them.

Before it: CC6.2, user provisioning. After it: CC6.4, physical access. All the criteria are on the Trust Services Criteria page, grouped by category.

Questions

What does SOC 2 CC6.3 ask a startup to show?

What evidence proves CC6.3?

The usual evidence is user access review records with decisions and sign off, a role to permission matrix and tickets for access changes when people move roles. An auditor tests it across the report period, so dated records matter more than a written promise.

Sources

TSP Section 100, Trust Services Criteria for Security, Availability, Processing Integrity, Confidentiality, and Privacy AICPA. The criteria themselves, including the common criteria every SOC 2 report covers.

Get audit-ready without a compliance team.

The readiness assessment is free, with no payment and no card. Star is $2,000 one time to get on the platform and close your gaps. Orbit is $7,800 a year, and your SOC 2 Type 2 audit is included in every contract year. You can be audit-ready starting at about a week.

Take the free assessment