How to Write an Access Control Policy for SOC 2

What does CC6.1-6.3 actually require your policy to cover?

The Trust Services Criteria don't hand you a template. They describe outcomes and leave the implementation to you, which is why two companies can pass the same criteria with very different policies. CC6.1 requires logical access security measures that restrict access to information assets and protect against unauthorized use. CC6.2 covers registration and authorization: access is provisioned and modified only on the basis of an authorized request, and removed when no longer needed. CC6.3 requires you to manage access based on roles and least privilege and to review those rights on a defined cadence.

Map your policy cleanly to these three points and you remove ambiguity for your team and the assessor at the same time. Each clause below should read as an enforceable statement someone can be held to, not an aspiration you hope to grow into.

• Least privilege by default: users get the minimum access their role requires, and any elevated rights need documented approval tied to a business reason.
• Unique, attributable accounts: every user authenticates as an individual. No shared logins, no generic 'admin' account three people know the password to.
• Role-based access control (RBAC): access is assigned by role or group rather than one-off per person, so entitlements stay predictable and a reviewer can actually reason about them.
• MFA on everything that supports it: enforced across SSO, VPN, cloud consoles, email, and production—not left as an option users can skip.
• Provisioning tied to authorization: access is granted only after the manager or system owner approves it against the role definition, and that approval is retained.

How do you handle the joiner/mover/leaver lifecycle?

The identity lifecycle—joiner, mover, leaver—is where CC6.2 lives, and it's the most heavily sampled area of access control in a Type II. Your policy needs to state, for each event, who triggers it, who approves it, the SLA for completing it, and what evidence gets kept.

Deprovisioning is the clause assessors scrutinize hardest, because it's the one that fails quietly. A leaver whose accounts stayed live for three weeks is an exception, and stale terminated access is one of the most common findings in first-year reports.

• Joiner: HR or the hiring manager raises a ticket; access is provisioned to the role baseline only after approval; the ticket is retained as the evidence trail.
• Mover: a role change triggers a re-evaluation of entitlements. Access from the old role is removed rather than layered under the new access, so privilege doesn't quietly accumulate.
• Leaver: termination triggers deprovisioning within a defined SLA—24 hours is common, immediate for involuntary terminations. Accounts are disabled, then removed.
• Every lifecycle event produces a ticket. The ticket, its approval, and its timestamp are the artifacts the assessor samples against your stated SLA.

How do you document privileged and break-glass access?

Administrative and production access earns tighter controls than standard user access, so treat it as its own tier in the policy. Privileged accounts should be few, assigned to named individuals, protected by MFA, and logged. Vague 'admins have full access' language is exactly what gets probed.

Break-glass (emergency) access needs its own clause. Define when it's permitted, how it's requested, how the credential is secured, and how each use gets reviewed after the fact. Assessors expect break-glass activations to be logged and reviewed, not exercised silently and forgotten.

• Privileged access is granted by role, reviewed more frequently than standard access, and never runs on shared credentials.
• Break-glass accounts live in a vault, alert on use, and require a documented post-activation review of every checkout.
• Production access is separated from standard corporate access and follows least privilege, with time-bound or just-in-time grants where the tooling supports it.
• Logs for privileged and production access are retained (90 days is a common floor, a year is better) and are available for the assessor to sample.

How does an assessor actually test your access control policy?

The assessor doesn't grade your prose. For a Type II report they test whether the control operated across the review period, which means they request evidence and sample it. Knowing exactly what they'll pull tells you what to build before the window opens.

The gap between a well-written policy and a passing report is almost always missing evidence: the review happened but nobody kept the artifact, or the account was disabled on time but no ticket exists to prove the date.

• Access review evidence: your completed quarterly reviews, showing who reviewed, what got flagged, and the remediation tickets that closed the gaps.
• Deprovisioning tickets: they pull a sample of terminated employees from HR records and match each to a deprovisioning ticket, checking the completion date against your SLA.
• MFA enforcement: a configuration export or screenshot proving MFA is enforced, not merely available.
• New-hire provisioning: they sample joiners and confirm access was approved before it was granted, not after.
• User listings: they reconcile system user lists against active employees to surface orphaned or ghost accounts.

What are the most common access control failures on a first SOC 2?

First-year exceptions are rarely exotic. They're the same operational gaps repeated across companies. Writing the control into the policy is necessary but not enough. You have to run it and evidence it for the full period, and these are the places teams slip.

• Access reviews performed but not documented: no signed artifact, no record of what was reviewed, no remediation trail.
• Terminated users still active because deprovisioning blew the SLA or was never logged.
• Shared or generic accounts—a single 'admin' login—that break the unique-identity requirement.
• MFA enforced everywhere except one legacy system nobody flagged, which is exactly the exception the assessor finds.
• Privilege creep from movers: people accumulate access across role changes because old entitlements were never revoked.
• Contractors and service accounts left out of reviews, leaving a blind spot the assessor walks straight into.

Should you write the policy from scratch or start from a mapped template?

Writing from scratch means guessing at the clause structure that maps to CC6.1-6.3, then rewriting half of it after your assessor's first read. A pre-mapped policy hands you the enforceable clauses, the RBAC and lifecycle language, the review cadence, and the evidence expectations already aligned to the criteria, so your time goes into operating the control instead of drafting it.

A complete access control policy pack pairs the policy with the access review template and deprovisioning workflow that produce the evidence assessors sample. That turns the policy from a document you file and forget into a system you can actually pass an audit with.

A SOC 2 access control policy passes not because it reads well but because you can produce the deprovisioning tickets and quarterly access review evidence that prove least privilege, unique identity, and MFA operated for the entire review period.