TSC-CC6.2 Guidance

To meet the tsc-cc6.2 guidance requirement, you must ensure every new user is formally registered and explicitly authorized before you issue credentials or grant access to systems in SOC 2 scope. Operationally, this means documented joiner workflows, defined approvers, role-based access rules, and an auditable trail showing each account’s request, approval, provisioning, and activation timing. ¹

Key takeaways:

• Access cannot start with “account created”; it starts with a documented request and authorization. ¹
• Auditors will look for consistent approvals, least-privilege role assignment, and logs tying approvals to provisioning actions. ¹
• Your fastest path is a standardized joiner process in your IAM/HRIS/ticketing tools plus evidence retention that survives staff turnover. ¹

TSC-CC6.2 is one of the SOC 2 Trust Services Criteria “Common Criteria” requirements that auditors use to evaluate access control governance: the organization must register and authorize users before issuing credentials and granting access. ¹ For a Compliance Officer, CCO, or GRC lead, the practical challenge is rarely the policy statement; it’s proving that provisioning consistently follows authorization across employees, contractors, and third parties with access to in-scope systems.

This requirement gets operationalized through your joiner workflow: identity proofing (as appropriate), a recorded access request, a defined approver with authority, and controlled provisioning steps that follow the approval. You also need evidence that the workflow ran as designed, not just “we would have done it.” Expect auditors to sample accounts, trace each one back to an approved request, and confirm that access was not granted before approval. ¹

If you have multiple sources of access (SSO, local accounts, cloud consoles, SaaS admin panels), you’ll need a single control story that connects them. This page gives requirement-level implementation guidance you can apply quickly.

Regulatory text

Requirement (TSC-CC6.2): “Prior to issuing credentials and granting access, the entity registers and authorizes new users.” ¹

What the operator must do (in plain terms):

• Register means the user is identified in your process as a real, accountable person (or service identity) with a clear relationship to the organization (employee, contractor, third-party support, etc.). ¹
• Authorize means an approved, recorded decision grants the user a defined level of access before any credentials are issued or access becomes effective. ¹
• “Prior to” means sequencing matters: approval must occur before provisioning or activation. ¹

Plain-English interpretation

You need a reliable gate in front of access. No “helpful” admin creating an account because someone asked in chat. No shared accounts to bypass provisioning delays. No backdoor local users created outside the process. The control intent is to prevent unauthorized access by making sure every account starts with (1) a known identity and (2) an explicit authorization. ¹

Who it applies to

Entities: Any organization undergoing a SOC 2 audit where CC6.2 is in scope (typical for Security and related Trust Services Categories). ¹

Operational contexts commonly in scope:

• Workforce identities: employees, interns, temps
• Non-employee identities: contractors, consultants, third-party support, implementation partners
• Privileged/admin identities: cloud administrators, database administrators, CI/CD admins
• Application-level accounts: SaaS admin roles, internal tools, customer support consoles
• Service accounts (where applicable): non-human identities used by applications or automation

Boundary decision you must make (and document):

• Which systems are “in scope” for SOC 2 and therefore must follow the registration/authorization workflow. Keep the list current and align it with your SOC 2 system description and control narratives. ¹

What you actually need to do (step-by-step)

Step 1: Define a “new user” standard and approval authority

1. Define account types: workforce, contractor, third-party, privileged, service account.
2. Define who can approve each account type:
   • Line manager for standard workforce access
   • System owner/data owner for sensitive apps and datasets
   • Security for privileged/admin access
3. Define minimum approval content: user identity, business justification, systems/roles requested, start date, end date (if time-bound), and approver identity.

Deliverable: an access control procedure (or IAM standard) that states these rules in enforceable language. ¹

Step 2: Implement a joiner workflow that enforces sequencing

A workable pattern (tool-agnostic):

1. Request is created in an HRIS-triggered workflow or a ticketing system.
2. Identity is registered (record created in IAM directory) with required attributes (name, email, manager, employment type, start date).
3. Authorization occurs (approval captured in the workflow).
4. Provisioning runs only after approval, ideally automated through IAM/SSO group assignment.
5. Credentials are issued (initial password, SSO enrollment, MFA enrollment) after provisioning is approved.
6. Access is validated (optional but strong): notify requester/manager; confirm least privilege.

Practical control design tip: prefer “approval gates” inside the system of record (ticketing/IAM) over approvals that happen in email or chat, because auditors need durable evidence. ¹

Step 3: Standardize role-based access so approvals are meaningful

Approvers cannot reliably approve a pile of ad-hoc permissions. Create role/group bundles:

• “Engineering-Standard”
• “Customer Support-Standard”
• “Finance-AP”
• “Cloud-ReadOnly”
• “Cloud-Admin” (restricted)

Map each bundle to:

• Systems it grants
• Data sensitivity
• Required approver(s)
• Whether it is time-bound

This is where least privilege becomes auditable: approvals refer to roles, and roles map to permissions. ¹

Step 4: Cover third-party access explicitly

Third parties routinely break CC6.2 because onboarding happens outside HR workflows. Add:

• A required sponsor (internal owner)
• A contract/ticket reference
• A defined end date and offboarding trigger
• Separate admin review for third-party privileged access

If you use Daydream to manage third-party onboarding, tie the third-party request to the access ticket so you can prove authorization and accountability in one place.

Step 5: Ensure logging/audit trails exist for “who approved” and “who provisioned”

Your evidence must connect:

• Request record → approval record → provisioning action → account created/activated

Minimum sources of truth:

• Ticketing system approvals (or IAM workflow approvals)
• IAM/SSO admin logs (group assignment, user creation)
• Cloud/SaaS audit logs for direct assignments outside SSO

Step 6: Monitor and periodically review the process

CC6.2 is a gate control; auditors still expect you to confirm it is operating:

• Monitor for accounts created outside workflow (local accounts, direct SaaS invitations)
• Review exceptions and document remediation
• Perform periodic assessment/testing of a sample of new users (your own internal test, separate from the auditor’s testing) ¹

Required evidence and artifacts to retain

Keep artifacts that let you prove timing, authorization, and completeness:

Policy & procedure artifacts

• Access control policy / IAM standard describing registration and authorization requirements. ¹
• RACI or approval matrix (who approves what).
• Role catalog (groups/roles and what they grant).

Operational evidence (auditor-ready)

For sampled new accounts:

• Access request ticket (or HRIS workflow record) with date/time and requester
• Approval record showing approver identity and timestamp
• Provisioning evidence:
  • IAM/SSO group assignment log
  • System audit log showing user created/activated
• If exceptions exist: exception approval + compensating controls + expiration

Monitoring/testing evidence

• Reports showing accounts created outside workflow and follow-up actions
• Internal control testing notes (what you sampled, what you found, remediation) ¹

Common exam/audit questions and hangups

Auditors commonly drill into these areas because they reveal control gaps:

1. “Show me the joiner process.” They want a walkthrough tied to system screenshots and records, not a diagram alone.
2. “How do you ensure approval happens before access?” Be ready to show timestamps from ticket approval and audit logs. ¹
3. “How do contractors and third parties get access?” Many teams lack a consistent workflow here.
4. “How do you prevent direct access grants in SaaS tools?” If admins can bypass SSO groups, you need monitoring and remediation.
5. “What about service accounts?” Expect questions on who authorizes them, rotation, ownership, and where they are tracked.

Frequent implementation mistakes and how to avoid them

Mistake	Why auditors reject it	Fix
Approvals happen in Slack/email	Evidence is inconsistent, hard to retain	Require approvals in ticketing/IAM workflow with immutable history
Account created “ahead of time” and enabled on start date	Still counts as issuing credentials/granting access early if usable	Disable until approved; document activation controls and prove sequencing
Generic “IT approves everything”	Authorization lacks business ownership	Define system/data owners and manager approvals for standard access
Shared accounts for speed	Breaks user registration and accountability	Replace with named accounts; restrict break-glass accounts with logging
Third-party access handled ad hoc	High risk and frequent gaps	Sponsor + approval matrix + end dates + monitoring for orphan accounts
No evidence retention	Control may exist but cannot be proven	Centralize artifacts in GRC repository; define retention rules 1

Enforcement context and risk implications

SOC 2 is an attestation framework, not a regulator with public penalty schedules in the SOC 2 criteria itself. ¹ The “enforcement” outcome is audit-based: if you cannot show registration and authorization before access, the auditor may note exceptions, qualify the opinion, or require management to describe deviations and remediation depending on the engagement.

Risk-wise, CC6.2 failures map to real incident patterns: unauthorized access, privilege creep, and inability to attribute actions to a specific identity. Even when no breach occurs, weak joiner controls create downstream gaps in access reviews, incident response, and customer security questionnaires.

A practical 30/60/90-day execution plan

First 30 days: Build the control spine

• Identify in-scope systems and where accounts are created (SSO, local, SaaS direct).
• Write or update the access control procedure to explicitly require registration and authorization before credentials/access. ¹
• Publish an approval matrix (by role/system).
• Choose the system of record for access requests (ticketing or IAM workflow).
• Define required fields and minimum evidence (request, approval, provisioning logs).

Days 31–60: Implement and close bypass paths

• Configure IAM/SSO group-based provisioning for common roles.
• Configure ticketing approvals or IAM workflow approvals with required approvers.
• Restrict who can directly invite users into key SaaS tools; align admin roles to a small group.
• Add a monitoring report for “accounts created outside workflow” and start working exceptions.
• Run an internal sample test of recent joiners and document results. ¹

Days 61–90: Make it auditable and durable

• Formalize third-party onboarding (sponsor, end date, access scope, approval).
• Standardize privileged access approvals and require separate authorization.
• Centralize evidence retention (export logs, preserve tickets, link records).
• Document periodic assessment cadence and assign an owner.
• Prepare an “auditor packet”: narrative + screenshots + sample evidence sets mapped to CC6.2. ¹

Frequently Asked Questions

Does CC6.2 require a specific tool (IAM, ticketing, HRIS)?

No. It requires that you register and authorize users before issuing credentials and granting access, and that you can prove it with evidence. ¹

Are contractors and third parties included?

If they receive credentials or access to in-scope systems, treat them as “new users” under the same registration and authorization control, with a sponsor and defined scope. ¹

What counts as “authorization” in practice?

A recorded approval by a person with authority to grant the requested access, captured in a durable system (ticketing or IAM workflow). The approval must be tied to the identity and requested roles/systems. ¹

Can we create accounts in advance of a start date?

You can pre-stage accounts if you can show access is not granted and credentials are not usable before authorization and the intended start time. Preserve evidence of the disablement/activation control and sequencing. ¹

How do we handle service accounts under CC6.2?

Track service accounts in an inventory, require an owner, document the business purpose, and record authorization before creation and permission assignment. Store the approval and the creation/audit logs together. ¹

What evidence is strongest for auditors?

A complete chain for each sampled account: request ticket/workflow record, approval timestamp, and IAM/SaaS audit logs showing account creation and access assignment after approval. ¹

Related compliance topics

• 2025 SEC Marketing Rule Examination Focus Areas
• Access and identity controls
• Access Control (AC)
• Access control and identity discipline
• Access control management

Footnotes

1. AICPA TSC 2017