SOC 2 CC6.2: Registers, Authorizes, and Administers User Access

SOC 2 CC6.2 is the credential lifecycle criterion in the Trust Services Criteria: it requires an organization to register and authorize new users before granting access, and to remove credentials when access is no longer authorized. It belongs to the CC6 series (Logical and Physical Access Controls) and is where auditors test whether onboarding, offboarding, and access reviews leave a usable evidence trail.

What does SOC 2 CC6.2 require?

In plain terms, CC6.2 treats access as a lifecycle with three checkpoints:

1. A user is registered and authorized before credentials exist.

2. Credentials are removed when authorization ends.

3. The access held in between is reviewed at defined intervals.

Contractors, vendors, and business partners whose access the organization administers are in scope alongside employees.

Scope follows the phrase administered by the entity: accounts the organization creates and controls are covered, while end users of a multi-tenant product who self-register generally are not. The system description should draw that boundary.

CC6.2 is technology-neutral. It does not require an identity provider, SCIM provisioning, or an automated review tool. What it requires is a documented, consistently followed process that produces evidence: a record that access was approved before it was granted, that it was removed when the person left, and a dated review confirming what remains is still appropriate.

Undocumented access reviews are a recurring evidence gap under this criterion: the review happens informally, but no dated artifact shows who was reviewed, who approved continued access, and what changed.

What are the CC6.2 points of focus?

The AICPA defines 3 points of focus for CC6.2. 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.

• Authorization before access. Access credentials are created on the basis of an authorization from the asset owner or an authorized custodian, so every grant traces to a named approver.
• Removal when authorization ends. Defined processes remove credential access when an individual no longer requires it, covering terminations, role changes, and contractor end dates.
• Periodic review. The appropriateness of the credentials in place is checked at defined intervals, confirming that the access people hold still matches what they are authorized to hold.

How do you meet CC6.2 in cloud environments?

Cloud environments meet CC6.2 by wiring the credential lifecycle into the identity provider, with the ticketing system carrying the approval record:

• Provisioning driven by the IdP. A new hire in the HR system triggers account creation in the identity provider (Okta, Entra ID, Google Workspace), and SCIM pushes the account to downstream applications with role-appropriate groups. The HR record is the registration; the group assignment is the baseline authorization.
• Ticket-based approval records. Access beyond the role baseline flows through a request ticket naming the system, the permission, and the approving system owner. The closed ticket ties each grant to an authorization.
• Deprovisioning as a single action. Suspending the user in the IdP cascades through SCIM, revokes active sessions, and disables SSO. Applications outside the SCIM chain still need a manual checklist; auditors sample terminations across every in-scope system.
• Automated access review campaigns. IdP access certification features and GRC platform review workflows route each assignment to a reviewer, record the decision, and export a dated report. The tooling removes the spreadsheet; the review design (who reviews, on what cadence, against which population) still has to be deliberate.
• Dormant account detection. IdP last-login reports feed the review, and accounts idle past a defined threshold are flagged or automatically suspended.

How do you meet CC6.2 on-prem?

On-prem environments run the same lifecycle through Active Directory and a ticketing system instead of an IdP and SCIM. The on-prem access control guide and the HR security guide for teams without automated provisioning cover the full implementations; the shape is:

• AD provisioning tied to an HR ticket. The onboarding ticket, opened when HR signals a new hire, drives AD account creation and records the approver and the RBAC role. With its named owner and closing timestamps, the ticket is the registration and authorization evidence.
• Offboarding as a per-system checklist with a same-day SLA. A documented HR trigger opens an offboarding ticket covering every in-scope system: AD, VPN, bastion, servers, databases, security tools, version control, SaaS applications. Same-day revocation for security-relevant departures and 24 hours for voluntary ones, measured against ticket timestamps, with a second person verifying removal before the ticket closes.
• Periodic review of the directory export. When no SCIM chain exists, the review is manual but the artifact is the same: extract users and roles from each in-scope system, compare against the RBAC matrix and an HR-sourced employee list, record a keep, remove, or modify decision per account, and capture management sign-off.
• Local accounts inside the review scope. Appliances and legacy systems that cannot join the domain keep unique named local accounts and sit in the review population, as do break-glass credentials and their usage alerts.
• Dormant account flagging. The AD last logon attribute and VPN logs identify inactive accounts, and the review documents what happened to each one.

Cloud vs on-prem at a glance

What evidence do auditors expect for CC6.2?

A second recurring gap is a lifecycle sized for a smaller company. One team that doubled from 20 to 40 people in a year, including offshore contractors with access to customer data, found that every hire generated provisioning, training, and review work nobody owned. The contractors were the sharper issue: fully inside CC6.2's registration, removal, and review expectations, but outside the onboarding rhythm built for employees.

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

Organizations pursuing both frameworks can reuse CC6.2 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.2 operates the user lifecycle inside the access architecture that CC6.1 establishes. CC6.3 governs how granted access is structured: role-based access, least privilege, and segregation of duties. The people side of the lifecycle (competence, training, accountability) sits under CC1.4 and CC1.5, and the Trust Services Criteria guide summarizes every series.

Frequently Asked Questions

What does SOC 2 CC6.2 mean?

SOC 2 CC6.2 requires an organization to register and authorize new internal and external users before issuing credentials and granting access, and to remove credentials when access is no longer authorized. Its points of focus add periodic review of access appropriateness, making it the criterion governing the full credential lifecycle.

What evidence satisfies CC6.2?

Typical CC6.2 evidence includes onboarding tickets naming the approver for each grant, offboarding tickets with per-system removal timestamps, access review reports with keep, remove, or modify decisions and management sign-off, an HR-sourced employee and contractor list, and IdP or Active Directory exports showing account status and last logon.

How often does CC6.2 require access reviews?

The points of focus say periodic without naming a cadence. Annual reviews are the accepted minimum; quarterly reviews demonstrate stronger control operation during a Type 2 observation period. Auditors look for a cadence defined in policy, dated review artifacts, and outcomes showing the review changed something when it needed to.

Does CC6.2 require automated provisioning?

No. CC6.2 describes outcomes: authorized creation, timely removal, periodic review. A manual program run through a ticketing system, with named approvers, per-system offboarding checklists, and reviews reconciled against an HR-sourced employee list, satisfies the criterion. Automation reduces effort and drift but is not a prerequisite for passing.

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

CC6.1 covers the technical architecture of access control: the software, infrastructure, and design decisions that restrict access. CC6.2 covers the lifecycle of individual users: registration, authorization, credential removal, and periodic review. CC6.3 covers how granted access is structured, through role-based access, least privilege, and segregation of duties.

How quickly must access be removed when someone leaves?

CC6.2 does not name a number. Auditors look for a documented SLA measured against actual offboarding timestamps. A common approach is same-day removal for security-relevant departures and 24 hours for voluntary ones, enforced through an offboarding ticket and verified by a second person before the ticket closes.