Skip to content
AuditFront
CC6.3 SOC 2

SOC 2 CC6.3: Logical and Physical Access - Role-Based Access and Least Privilege

What This Control Requires

The entity authorizes, modifies, or removes access to data, software, functions, and other protected information assets based on roles, responsibilities, or the system design and changes, giving consideration to the concepts of least privilege and segregation of duties, to meet the entity's objectives.

In Plain Language

Auditors see access creep in almost every organisation they examine. People join, change teams, pick up side projects - and their access just keeps growing. CC6.3 exists because unmanaged access is one of the fastest paths to a material finding.

The core idea is straightforward: give people only the access they need for their current role, and make sure no single person can both initiate and approve sensitive actions. In practice, that means role-based access control (RBAC), regular access reviews that actually mean something, and a clear process for stripping old permissions when someone moves to a new team.

Access creep - where users accumulate excessive permissions over time - is one of the most common audit findings. If you can show a clean joiner-mover-leaver process and genuine periodic reviews, you're already ahead of most organisations going through SOC 2.

How to Implement

Start by defining and documenting access roles for every in-scope application and system. Each role should map to a job function and spell out exactly what permissions it grants. Get system owners to sign off on these role definitions.

Default to the minimum access required for each role. When someone requests access beyond their standard role, require a written business justification and approval from the relevant data or system owner. Track every exception.

Map out your segregation of duties requirements. Identify which combinations of access could enable fraud or significant errors - think creating and approving transactions, modifying code and deploying to production, or setting up vendor records and processing payments. Enforce these separations in your systems where possible. Where you can't enforce them technically, put detective controls in place (monitoring, review logs, management sign-off).

Run regular access reviews - quarterly for privileged access, semi-annually for everything else at minimum. Have managers or system owners validate whether each person's access still matches their current role. Document the review, any changes made, and who signed off.

Build a process for role changes specifically. When someone moves teams, that should trigger a full review - not just adding new permissions on top of old ones. Remove access that's no longer relevant.

Monitor for anomalous access patterns. Log privileged operations and review those logs. Automated tooling that flags SoD violations, unused privileges, and access anomalies will save you significant time.

Evidence Your Auditor Will Request

  • Role definitions for each system with documented permissions and approval by system owners
  • Access review records (quarterly for privileged, semi-annual for all) with reviewer sign-off
  • Segregation of duties matrix identifying incompatible access combinations and mitigating controls
  • Evidence of access modification during role changes, including removal of no-longer-needed access
  • Exception records for access granted beyond standard roles with business justification and approval

Common Mistakes

  • Users accumulate access over time through role changes without removal of previous role permissions
  • Privileged access is granted broadly rather than limited to specific individuals who require it
  • Access reviews are performed as a rubber-stamp exercise without genuine evaluation of appropriateness
  • Segregation of duties conflicts are not identified or documented, and no compensating controls exist
  • Role definitions are outdated and do not reflect current system capabilities or organisational structure

Related Controls Across Frameworks

Framework Control ID Relationship
ISO 27001 A.5.15 Equivalent
ISO 27001 A.5.18 Related
ISO 27001 A.8.2 Related
nist-csf PR.AA-05 Equivalent

Frequently Asked Questions

How do we prevent access creep?
Build a proper joiner-mover-leaver process that reviews and adjusts access whenever someone changes roles, not just when they join or leave. Run regular access reviews that compare current access against role requirements. Automated tooling that flags users with more access than their role profile calls for is a big help. And make managers confirm that every permission their team members hold is still needed.
How granular should access reviews be?
It depends on the risk level of the system. At minimum, cover each user's access to each application. For critical systems, go deeper - review individual permissions or roles within the application. A review that just confirms user accounts exist won't satisfy any auditor. The higher the risk, the more granular you need to be.
What if our small team makes strict segregation of duties impossible?
Small teams run into this all the time, and auditors understand that. The key is compensating controls: management review and approval of sensitive transactions, detailed audit logging with regular review, dual-control for critical operations, and periodic independent checks. Document the SoD conflict, explain what compensating controls you've put in place, and note the accepted residual risk. That's what auditors want to see.

Track SOC 2 compliance in one place

AuditFront helps you manage every SOC 2 control, collect evidence, and stay audit-ready.

Start Free Assessment