Logical access controls are the most tested component of every SOC 2 audit. CC6 — which covers authentication, authorization, access provisioning, access reviews, and privileged access management — accounts for more audit time, more evidence requests, and more exceptions than any other cluster. Implementing CC6 controls correctly, with a clean and contemporaneous evidence trail, is the single highest-leverage activity in SOC 2 readiness.
Multi-Factor Authentication Implementation
MFA enforcement is the non-negotiable baseline of CC6. Every user who can authenticate to in-scope systems must use MFA — with no exceptions for privileged users, service accounts, or contractor accounts. Cloud console access, VPN, SSO, and any direct application authentication are all in scope. MFA exceptions for specific users or groups, even if documented with a business justification, create audit findings.
| System Category | MFA Requirement | Enforcement Mechanism |
|---|---|---|
| Identity provider / SSO (Okta, Azure AD, Google Workspace) | MFA enforced for all users at the IdP layer; phishing-resistant MFA (hardware keys, passkeys) preferred for privileged users | Conditional access policy requiring MFA; MFA registration enforcement; session policies preventing MFA bypass |
| Cloud infrastructure consoles (AWS, Azure, GCP) | MFA required for root/super-admin accounts; MFA required for all IAM users with console access | IAM policy requiring MFA; Service Control Policies (SCPs) blocking non-MFA-authenticated actions |
| Production application access (for admin users) | MFA required for admin and privileged application access | Application-level MFA enforcement; SSO integration with MFA at IdP layer |
| VPN | MFA required for all VPN authentication | VPN client configured for MFA; integration with IdP or dedicated MFA platform |
| Developer tooling (GitHub, CI/CD) | MFA enforced organization-wide; code signing where applicable | Organization-level MFA policy enforcement; SAML/OIDC integration with IdP |
Role-Based Access Control (RBAC)
RBAC is the foundation of CC6.3 — the authorization requirement. Every in-scope system should have a documented access control model: the roles defined, the permissions each role carries, and the assignment of users to roles. The principle of least privilege should be applied to every role: users should have the minimum access necessary to perform their job function.
Building the RBAC matrix is often more time-consuming than implementing the controls themselves. The matrix requires: an inventory of all in-scope systems, the roles defined in each system, the permissions each role carries, and the list of users assigned to each role. For organizations with many systems and complex permission models, this work takes weeks — but it is foundational to both CC6.3 and CC6.5 (access reviews).
| KEY IDEA | Segregation of duties is a specific CC6.3 requirement that organizations often overlook. The most important segregations for technology companies: the developer who writes code should not be able to deploy directly to production without review; the user who requests access should not be able to approve their own access; the person who processes transactions should not be the same person who reconciles them. Document segregation of duties in the RBAC matrix. |
Access Provisioning and Deprovisioning Workflow
Access provisioning and deprovisioning must follow a documented, ticket-based workflow with clear approval requirements. The workflow should include: a formal access request (specifying system, role, and business justification), approval by the requesting user’s manager or the system owner, implementation of the access following approval, and notification to the requester. Deprovisioning should be triggered automatically by HR system termination events, with same-day revocation for all in-scope systems.
| Process | Required Workflow Elements | Evidence |
|---|---|---|
| New hire access provisioning | Standard access package defined for each role; provisioned as part of onboarding checklist; approval documented | HRIS onboarding record + access provisioning ticket + approval confirmation |
| Additional access requests | User submits request with business justification; manager or system owner approves; IT implements | Ticketing system record with request, approval, and implementation timestamps |
| Role change access adjustment | Manager submits role change; prior role access reviewed and removed; new role access provisioned | HR role change record + access review + new access provisioning ticket |
| Contractor / vendor access provisioning | Same formal process as employee; time-limited access preferred; additional approvals for privileged access | Same ticket trail + contract reference + access expiry date documentation |
| Termination / offboarding deprovisioning | Automatic trigger from HR system; same-day revocation from all in-scope systems; confirmation to HR | Termination date in HRIS + access revocation timestamps across all in-scope systems + offboarding checklist completion |
Quarterly Access Reviews
Access reviews are the most operationally demanding ongoing CC6 requirement. For each in-scope system, a designated reviewer (typically the system owner or the user’s manager) must periodically review who has access and confirm that each user’s access is still appropriate. SOC 2 auditors generally expect privileged access to be reviewed monthly and standard access quarterly.
The review process must be documented. At minimum, the evidence package for each access review cycle includes: the date of review, the reviewer’s name, a list of users reviewed, confirmation that each access is appropriate (or a record of access removed as a result of the review), and the reviewer’s sign-off. GRC platforms automate this workflow: they generate the access list from system integrations, route it to the reviewer, collect the sign-off, and timestamp the completion.
| BITLION INSIGHT | Access reviews fail most often not because the review isn’t performed but because the review isn’t documented. A system owner who reviews access by scanning a list in their head, revokes one stale account, and considers the review complete has no evidence to show an auditor. The discipline is: open the GRC task, review the generated access list systematically, mark each user as appropriate or flag for revocation, and submit the completed review with a timestamp. |
Privileged Access Management
Privileged accounts — administrative accounts with elevated permissions to cloud consoles, production databases, network infrastructure, and identity systems — require additional controls beyond standard access management. CC6 requires that privileged accounts are separately identified, their access is limited to what is necessary, their activity is logged and monitored, and they are reviewed more frequently than standard accounts.
For cloud-native organizations, privileged access management typically includes: Just-In-Time (JIT) access for production systems (privileged access granted only when needed and for a defined time window), separate administrative accounts distinct from daily-use accounts, MFA enforcement with phishing-resistant factors for privileged accounts, and comprehensive audit logging of all privileged actions. Cloud platforms provide native tools for each of these capabilities — AWS IAM Identity Center, Azure Privileged Identity Management, and GCP Cloud Identity are the primary implementations.