SOC 2 CC6.3: Role-Based Access, Least Privilege, and Segregation of Duties

SOC 2 CC6.3 is where role design meets audit evidence: it requires that access to protected information assets is authorized, modified, or removed based on roles and responsibilities, with least privilege and segregation of duties considered in the design. It sits in the CC6 series (Logical and Physical Access Controls), and a frequent finding under it is access that outgrew its role definitions.

What does SOC 2 CC6.3 require?

In plain terms, CC6.3 asks whether every permission a person holds traces to a defined role and a documented decision. Role-based access control ties permissions to job responsibilities instead of individuals. Least privilege caps each role at the access its work requires. Segregation of duties keeps any one person from controlling a sensitive process end to end, such as writing and approving the same change.

Like the rest of the CC6 series, the criterion is technology-neutral. A three-person company with an approved role matrix, access change tickets, and a documented explanation of which duties one person must hold can satisfy CC6.3. A large company with formal RBAC tooling and standing admin rights nobody has reviewed in a year cannot. Where headcount makes true segregation impossible, auditors accept documented role consolidation with compensating controls: independent change review, alerting on privileged activity, and access reviews by someone outside the consolidated role.

Meeting the criterion and operating it well are separate questions. One company passed SOC 2 four years running on a self-built identity stack; the audits were clean, but every lockout and manual grant pulled an engineer off product work. CC6.3 sets the floor for role design and says nothing about the operating cost of the design chosen to clear it.

What are the CC6.3 points of focus?

The AICPA defines 4 points of focus for CC6.3. Because the Trust Services Criteria are AICPA copyrighted material, the points of focus below are paraphrased and grouped by theme rather than reproduced verbatim; consult the official TSC document for exact wording.

• Authorized access changes. Creating or modifying access to protected information assets follows an authorization, so every grant traces to an approval.
• Access removal. Processes remove access when an individual no longer requires it, whether through departure, role change, or system change.
• Role-based access and least privilege. Role-based access control ties access to job responsibilities, so each identity carries the minimum access its role needs.
• Periodic review of roles and rules. Access roles and rules are reviewed on a defined cadence and modified as responsibilities and systems change.

How do you meet CC6.3 in cloud environments?

Cloud environments satisfy CC6.3 by making the identity provider's group model the role model, then constraining and time-boxing what those roles can do:

• IdP groups as role containers. Groups in Okta, Entra ID, or Google Workspace map one-to-one to the roles in the access matrix, and applications are assigned to groups rather than individuals, so a group membership export reads as a role assignment report.
• Permission boundaries and guardrails. AWS IAM permission boundaries, service control policies, and Azure management group policies cap what any role can reach, so a mis-scoped grant cannot exceed its role's ceiling.
• Just-in-time elevation. Standing administrator rights give way to time-boxed elevation through tools such as Entra PIM or AWS temporary elevated access, each with an approval and an expiry, making privileged access a logged event rather than a permanent state.
• Access change tickets. Every grant or modification references a ticket naming the role, the approver, and the justification. The ticket trail is the authorization evidence the first point of focus asks for.
• Segregation through the pipeline. Branch protection and deployment approvals keep the author of a change from approving its release: segregation of duties expressed in tooling rather than org charts.

Multi-tenant SaaS providers carry one extra obligation. When tenant administrators manage their own users' roles, the provider cannot control how much access a tenant admin hands out; the SOC 2 report must state that boundary as a complementary user entity control. One development team with well-designed per-tenant user pools realized during a readiness session that nobody had defined the customer's responsibilities, and that customer-facing audit logs (login history, role changes, MFA status) were a compliance expectation rather than a nice-to-have.

How do you meet CC6.3 on-prem?

On-prem environments satisfy CC6.3 by turning Active Directory groups into the role model and separating administrative identity from daily identity. The on-prem access control guide covers the full implementation; the shape is:

• AD security groups as role containers. Each role in the access matrix becomes a security group, and resource permissions are granted to groups, never to individual users. Group membership exports mirror the IdP evidence used in cloud environments.
• Admin account separation. Administrators hold two identities: a daily account with no privileged rights and a named admin account (the -adm convention) used only for administrative work, so least privilege holds for everyday activity and privileged actions stay attributable to a person.
• Documented role definitions. A role matrix defines the baseline access for each role, with management sign-off. Anything beyond the baseline requires a ticket with justification and approval.
• Segregation through work orders. Changes are requested by one person and approved by another, enforced through the ticketing workflow. Where team size rules that out, the consolidation is documented with compensating review of the change log.

Cloud vs on-prem at a glance

What evidence do auditors expect for CC6.3?

A second recurring gap is the undocumented duty consolidation. In a five-person engineering team, the person who writes infrastructure changes often approves and deploys them too. That consolidation can pass an audit when it is named in the risk register and paired with compensating review by someone outside the role. Left undocumented, the same arrangement reads as an unmanaged segregation failure.

How does CC6.3 map to ISO 27001:2022?

Organizations pursuing both frameworks can reuse CC6.3 evidence directly for these Annex A controls. The SOC 2 to ISO 27001 control mapping covers the full crosswalk across all five Trust Services Categories.

Related criteria

CC6.3 operates inside the access architecture that SOC 2 CC6.1 establishes: CC6.1 covers the software, infrastructure, and design that restrict access, while CC6.3 tests whether what gets granted matches defined roles. CC6.2 covers the adjacent lifecycle of registering, authorizing, and deprovisioning users, and shares much of its evidence with CC6.3. Further along, CC6.4 applies the same discipline to physical access, and monitoring for misuse of granted access lives in CC7.2.

Frequently Asked Questions

What does SOC 2 CC6.3 mean?

SOC 2 CC6.3 requires that access to data, software, and other protected information assets is authorized, modified, or removed based on roles and responsibilities, with least privilege and segregation of duties considered in the design. In practice, it asks whether every permission a person holds traces to a defined role and a documented approval.

What evidence satisfies CC6.3?

Typical CC6.3 evidence includes a role matrix with management sign-off, access change tickets referencing it, group membership exports from the IdP or Active Directory, offboarding checklists with removal confirmations, just-in-time elevation logs, role review records, and documented compensating controls where duties are consolidated.

Does SOC 2 require role-based access control?

CC6.3 includes a point of focus on using role-based access control to enforce least privilege, but the criterion is technology-neutral. An organization without formal RBAC tooling can satisfy it with a documented role matrix, approvals for every grant, and periodic reviews. Access that maps to no role at all is where findings come from.

How do small teams handle segregation of duties for SOC 2?

When headcount forces one person to hold conflicting duties, the accepted path is documented role consolidation plus compensating controls: a risk register entry naming the gap, independent change review, alerting on privileged activity, and access reviews by someone outside the role. Auditors accept documented consolidation; an undocumented one reads as an unmanaged gap.

What is the difference between CC6.2 and CC6.3?

CC6.2 covers the user lifecycle: registering people, authorizing them, issuing credentials, and deactivating accounts. CC6.3 covers what those users can do: whether access matches roles and least privilege, whether duties are segregated, and whether roles and rules get reviewed. Provisioning records answer CC6.2; role design and review records answer CC6.3.