TSC-CC6.3 Guidance

TSC-CC6.3 is the SOC 2 access governance criterion auditors use to validate that access to data and systems is not ad hoc. The control intent is straightforward: access gets granted only after authorization, changes happen only through an approved process, and access is removed when the user no longer needs it. ¹

For most organizations, the fastest path to a clean SOC 2 result is to stop treating access as an IT-only task. You need a defined decision model (who approves what), a consistent mechanism (IAM, SSO, tickets, or automated joiner-mover-leaver flows), and evidence that the mechanism ran as designed during the audit period. Auditors rarely fail you for having a lightweight process; they fail you for gaps: undocumented approvals, missing removals, unclear ownership, and logs that don’t tie back to a business justification. ¹

This page translates the tsc-cc6.3 guidance requirement into an operator checklist you can implement, test, and evidence without guessing what your auditor will ask for. ¹

Regulatory text

Requirement (TSC-CC6.3): “The entity authorizes, modifies, or removes access to data, software, functions, and services.” ¹

What the operator must do:
You must implement controls that (1) require authorization before access is provisioned, (2) require authorization and traceability for access changes, and (3) ensure timely removal of access when it’s no longer appropriate (for example: termination, role change, end of contract, or system de-scope). You also need evidence that these controls operated for the entire SOC 2 reporting period. ¹

Plain-English interpretation (what CC6.3 is really testing)

Auditors test whether access is intentional and reversible:

• Intentional: every account and permission set exists because someone asked for it, someone approved it, and it maps to a role or justified exception. ¹
• Reversible: when people leave or no longer need access, you can reliably remove access, and you can prove you did. ¹

This applies to data, software, functions, and services, so scope typically includes:

• Production infrastructure and cloud consoles (AWS, Azure, GCP)
• Customer data stores (databases, object storage)
• Corporate systems that can change production or access customer data (IdP, CI/CD, endpoint admin tools)
• SaaS apps storing sensitive information (support tooling, CRM) when in audit scope

Who it applies to (entity and operational context)

Applies to: organizations undergoing a SOC 2 examination using the AICPA Trust Services Criteria. ¹

Operational context where CC6.3 becomes “real”:

• You have multiple teams provisioning access (IT, engineering, data, security).
• You use third parties (MSPs, contractors, offshore developers) who need time-bound or privileged access.
• You run production on cloud platforms where a single permission can expose or alter sensitive data.
• You rely on SaaS tooling where access is managed outside your core IAM stack.

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

Use this as a build checklist for the control and its evidence.

Step 1: Define your access control policy and ownership

1. Write an Access Control Policy covering provisioning, modification, and removal across in-scope systems. Keep it short, explicit, and testable. ¹
2. Assign roles:
   • Control owner (accountable)
   • System owners (approve access for their systems)
   • IT/IAM admins (execute provisioning/deprovisioning)
   • HR or People Ops (source of truth for employment status)
3. Define approval rules:
   • Who approves standard access by role
   • Who approves privileged/admin access
   • Who can approve exceptions and for how long

Operator tip: If you cannot explain “who can grant access to what” in one page, your evidence will sprawl and your audit will drag.

Step 2: Standardize provisioning with a request + approval workflow

1. Choose the system of record for requests (ticketing system, IAM workflow tool, or access request platform).
2. Require each request to include:
   • Requestor and recipient
   • System / application
   • Requested role/permissions
   • Business justification
   • Approver identity and timestamp
3. Enforce approvals before changes. If your tooling allows it, block execution until approval is captured.

Examples that work in audits:

• Access request tickets with manager + system owner approval
• IdP/IAM access packages with built-in approval and logs
• GitOps-style access changes via pull request approvals (for infrastructure permissions), if approvals are enforced and logs are retained

Step 3: Control access modifications (“movers” and privilege changes)

1. Treat changes as first-class events: promotions, team transfers, temporary projects, incident response elevation.
2. Require:
   • Approval for elevated privileges
   • Defined time bounds for temporary admin access
   • Removal or rollback after the approved period ends
3. Implement “break glass” if needed, but log it and review it.

Auditor focus: they will sample access changes. If you cannot show an approval trail that matches the change event, CC6.3 becomes a finding. ¹

Step 4: Remove access promptly (joiner-mover-leaver discipline)

1. Define removal triggers:
   • Termination (voluntary/involuntary)
   • End of contract for contractors/third parties
   • Role change that no longer needs access
   • Access no longer justified (project ended)
2. Connect your source of truth (HRIS/People Ops list, contractor roster) to IT deprovisioning tasks.
3. Cover all identity surfaces:
   • Primary identity (SSO/IdP)
   • Local accounts (databases, servers, SaaS apps without SSO)
   • Shared secrets (API keys, service accounts, vault access)
4. Track completion with a ticket or workflow that shows:
   • Date/time of disablement
   • Systems removed
   • Executor identity

Step 5: Monitoring, review, and testing (prove it worked)

1. Run periodic access reviews for in-scope systems:
   • Validate user lists against HR/contractor rosters
   • Validate privileged access list against approved admin population
   • Validate service accounts against owners and purposes
2. Review audit logs for access changes (or export them to a SIEM) and spot-check anomalies.
3. Test effectiveness by sampling:
   • New hires: was access approved?
   • Movers: were changes approved and documented?
   • Leavers: was access removed and evidenced? ¹

Where Daydream fits naturally: Daydream can centralize access review evidence collection, map systems-in-scope to owners, and keep a clean audit trail of approvals, reviews, and remediation so you are not assembling proof across ten tools at audit time.

Required evidence and artifacts to retain

Auditors evaluate design and operating effectiveness. Keep artifacts that show both. ¹

Minimum evidence set (practical)

• Access Control Policy and supporting procedures (provision, modify, remove). ¹
• Access request and approval records (tickets, IAM workflow logs, access package approvals). ¹
• System-generated audit logs for access events (IdP logs, admin console logs, PAM logs). ¹
• Offboarding/termination deprovision records (HR trigger + completion evidence). ¹
• Access review reports (who reviewed, when, exceptions, remediation tickets, closure proof). ¹
• Control testing results (internal audit/GRC testing, sample set, exceptions, corrective actions). ¹

Evidence quality checklist (what makes it “audit-ready”)

• Ties a user to access, to approval, to implementation, to timestamp.
• Shows the approver had authority (manager/system owner).
• Demonstrates removals happened and were complete across systems in scope.

Common exam/audit questions and hangups

Auditors typically push on these areas because they fail often in real programs. ¹

1. “Show me how access is approved.”
   Hangup: approvals exist in chat, not in a system of record.

2. “How do you ensure terminated users lose access everywhere?”
   Hangup: SSO is disabled, but local SaaS accounts and API keys remain.

3. “How do you control privileged access?”
   Hangup: too many admins, no time-bound elevation, weak evidence of review.

4. “What systems are in scope, and who owns them?”
   Hangup: unclear system inventory and control coverage.

5. “Show operating effectiveness for the whole period.”
   Hangup: one-time screenshots instead of a repeatable audit trail.

Frequent implementation mistakes (and how to avoid them)

Mistake	Why it fails CC6.3	Fix
Relying on informal approvals (Slack/email)	Hard to sample and prove consistently	Require ticket/workflow approvals and link them to the change record
Offboarding stops at disabling SSO	Leaves orphaned accounts, tokens, local users	Maintain an access removal checklist per system; confirm completion with evidence
No periodic access review	Access accumulates; exceptions linger	Schedule access reviews and record decisions + remediation tickets
Privileged access not segmented	Admin access becomes default	Separate admin roles, require explicit approval, monitor/admin list review
Evidence retention is inconsistent	Controls may exist but are not provable	Define an evidence folder structure and retention owner; automate exports where possible

Enforcement context and risk implications

SOC 2 is an audit framework rather than a regulatory enforcement regime, so you should treat CC6.3 as an assurance requirement tied to customer expectations and contractual commitments rather than a direct fine schedule. ¹

Operationally, CC6.3 gaps map to real incident patterns: unauthorized access, excessive privileges, delayed deprovisioning, and inability to reconstruct “who had access when.” Those failures drive breach impact, customer escalations, and audit findings that can block deals.

Practical 30/60/90-day execution plan

Days 1–30: Stabilize and define

• Confirm in-scope systems and owners for access decisions. ¹
• Publish/update Access Control Policy and access request procedure. ¹
• Pick the system of record for access requests and approvals.
• Implement a minimum workflow: request, manager approval, system owner approval for sensitive systems, execution, closure evidence.

Days 31–60: Operationalize and instrument

• Connect HR/offboarding to deprovision tasks; document the joiner-mover-leaver process.
• Turn on and retain access logs for core platforms (IdP, cloud provider, key SaaS).
• Stand up privileged access governance (admin roster, approval path, emergency access procedure).
• Run your first access review for one critical system and track remediation to closure. ¹

Days 61–90: Prove operating effectiveness

• Expand access reviews across remaining in-scope systems; record decisions and exceptions.
• Perform control testing: sample provisioning, modifications, and removals; document results and fixes. ¹
• Clean evidence packaging: a single repository with policy, workflows, samples, logs, and review outputs.
• If you use Daydream, configure control mappings and automated evidence pulls so monthly evidence collection becomes routine.

Frequently Asked Questions

Does TSC-CC6.3 require role-based access control (RBAC)?

The criterion requires authorization and control over granting, changing, and removing access; RBAC is a common way to implement that consistently. If you don’t use RBAC, you still need a repeatable method to approve and evidence permissions. ¹

Are contractors and other third parties covered?

Yes, if a third party has access to in-scope data, software, functions, or services, you must authorize, modify, and remove that access under the same discipline. Make contract end dates and sponsor ownership part of your process. ¹

What counts as “evidence” for access removal?

Auditors typically accept system logs showing the account disabled/deleted and a ticket/workflow showing the trigger and completion. A screenshot can work as supporting evidence, but it’s weaker than an exportable log with timestamps. ¹

If we have SSO, is that enough for CC6.3?

SSO helps, but it doesn’t automatically cover local accounts, API keys, service accounts, or SaaS apps not integrated with the IdP. You still need a full inventory of access paths and a removal process for each. ¹

How should we handle emergency access (“break glass”)?

Allow it only with clear conditions, strong authentication, and logging, then require after-the-fact review and documented justification. Keep the break-glass access list short and reviewed. ¹

What’s the fastest way to get this audit-ready for a SOC 2 Type II period?

Start by enforcing request/approval for all access changes in scope and capturing logs centrally, then run recurring access reviews with tracked remediation. Tools like Daydream reduce evidence chase-work by organizing requests, reviews, and artifacts in one place.

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