Access control policy for SOC 2: a working template (with example language)

The Access Control Policy is the single most-tested policy in a SOC 2 audit. Here's a working template with example language, aligned to Common Criteria CC6, and the mistakes that turn it into an audit finding.

If an auditor is going to find something wrong with your SOC 2 policies, there is a roughly 60% chance it's in the Access Control Policy. It's the most-tested, most-evidenced policy in a Type 2 audit, and it's the one where the gap between what the document says and what the company actually does shows up first.

This post gives you a working Access Control Policy, section by section, with example language you can adapt. It's aligned to the AICPA 2017 Trust Services Criteria with 2022 Revised Points of Focus, specifically Common Criteria 6 (CC6) — Logical and Physical Access Controls.

The goal isn't to maximize length. A good Access Control Policy for an early-stage SaaS is four to six pages. What matters is that every line is true for your company, and that every control you promise is one you actually operate.

What CC6 asks for

Before the template, it's worth understanding what the criterion actually requires. CC6 breaks into eight subcriteria. The short version:

CC6.1 — The entity implements logical access security software, infrastructure, and architectures over protected information assets to protect them from security events to meet the entity's objectives.

CC6.2 — Prior to issuing system credentials, the entity registers and authorizes new internal and external users whose access is administered by the entity.

CC6.3 — The entity authorizes, modifies, or removes access to data, software, functions, and other protected information assets based on roles, responsibilities, or the system design, with consideration of the concept of least privilege.

CC6.4 through CC6.8 cover physical access, data transmission, encryption, and protection against malware — covered elsewhere in your policy kit.

The Access Control Policy primarily addresses CC6.1, CC6.2, and CC6.3. That's what the template below covers.

Template — with example language

1. Purpose

The Purpose section tells the auditor why this policy exists. Keep it short. Two to three sentences is enough.

Example:

This policy defines how [Company] grants, manages, reviews, and removes access to its information systems and data. It establishes the principles of least privilege, need-to-know, and segregation of duties, and defines the process for authorizing and revoking access over a user's lifecycle.

2. Scope

The Scope section tells the auditor which systems the policy covers. This matters because your SOC 2 boundary is defined by which systems are in scope, and your Access Control Policy has to match.

Example:

This policy applies to all logical access to [Company]'s production systems, corporate systems, source code repositories, and SaaS applications used to support business operations. It applies to all personnel (employees, contractors, and interns) and to any third party granted access to [Company] systems.

Production systems include [Company]'s customer-facing services hosted in [Cloud Provider], and the supporting databases, storage, and observability infrastructure. Corporate systems include identity provider accounts, collaboration tools, and the ticketing and code-review systems materially supporting production.

The cloud provider and identity provider should be named explicitly. "We use AWS" and "we use Google Workspace" are specific; "we use cloud services" is a finding waiting to happen.

3. Policy Statements

This is the meat of the document. Each subsection is a control.

3.1 Access Principles

State the three governing principles upfront. They don't need to be elaborate; they need to be explicit.

Access to [Company] systems and data is granted on the basis of:

• Least privilege. Users are granted only the access necessary to perform their role.
• Need-to-know. Access to restricted or confidential data is granted only to personnel with a business need.
• Segregation of duties. Where practical, no single individual can execute and approve a privileged action.

At a five-person company, segregation of duties is often aspirational — the CTO approves their own deploys because there's no one else. State this honestly: "where practical." Do not promise a two-person rule you can't operate.

3.2 User Lifecycle

This is where audit evidence lives. Four sub-sections: provisioning, modification, revocation, and review.

Provisioning:

New users are provisioned only after a written access request approved by the user's manager and [Policy Owner]. Access is granted through the company identity provider wherever technically feasible. Exceptions are documented and retained.

Modification:

When a user changes roles, their manager submits a revised access request. [Policy Owner] validates the change and adjusts access within five business days. Access granted for a prior role that is no longer needed is removed.

Revocation:

When a user leaves the company, access is revoked within 24 hours of their separation. For voluntary departures with notice, access may be reduced earlier at the manager's discretion. Revocation covers the identity provider, all SaaS applications federated to it, local accounts on company-managed devices, shared credential vaults, and any standalone accounts on non-federated systems.

A termination checklist is completed and retained as evidence.

Review:

Access to production systems and privileged accounts is reviewed at least quarterly. Access to non-privileged corporate systems is reviewed at least annually. Reviews are performed by the account owner or the user's manager, with results reviewed by [Policy Owner]. Accounts with access no longer justified are removed within ten business days of the review.

The quarterly review is one of the most-tested controls in SOC 2. Auditors will ask for the review records for every quarter in the audit period. If you promise quarterly, you have to do quarterly.

3.3 Authentication

This is where MFA lives. Be explicit.

All access to [Company] systems requires authentication. The following requirements apply:

• Password complexity: A minimum of 12 characters, with commonly-breached passwords blocked via the identity provider's breached-password screening. Passwords are not rotated on a schedule in the absence of evidence of compromise, consistent with NIST SP 800-63B guidance.
• Multi-factor authentication: MFA is required for all accounts. MFA is enforced at the identity provider for federated applications, and individually for non-federated systems. Phishing-resistant MFA (WebAuthn / FIDO2) is required for privileged accounts where supported.
• Password storage: Passwords are not stored in plaintext. Shared passwords for accounts that do not support SSO are stored in the company-approved password manager.
• Session timeouts: Production system sessions time out after 12 hours of inactivity. Corporate system sessions follow the defaults of the identity provider.

"Password complexity" language sometimes contains leftover 90-day rotation rules from older templates. NIST explicitly deprecated scheduled rotation in 2017. Keep it out unless you have a compelling reason.

3.4 Privileged Access

Privileged accounts are the audit hot zone. Define them narrowly and restrict them tightly.

A privileged account is any account with:

• Administrative access to production infrastructure (e.g., cloud provider root, IAM administrators, database administrators).
• The ability to read or modify customer data outside normal application flows.
• The ability to modify access controls (add or remove users, change roles).
• The ability to access security or audit logs.

Privileged accounts:

• Are granted only when required for a role, not as a default.
• Require phishing-resistant MFA where supported.
• Are logged with all administrative actions captured for audit.
• Are reviewed quarterly with results retained for three years.
• Use a break-glass procedure for emergency access, with the break-glass credential retrieved from a sealed vault and rotated after use.

The break-glass language is important. Auditors will ask: what happens if your sole administrator is unreachable? Having a documented break-glass procedure and a rotation record is the answer.

3.5 Third-Party and Contractor Access

Third parties (including contractors, consultants, and vendor support engineers) are granted access under the same lifecycle controls as employees. Additional requirements:

• A signed agreement (master services, consulting, or vendor) must be in place before access is provisioned.
• Access is time-bounded. Third-party access expires automatically after the engagement period and must be re-provisioned if extended.
• Third parties do not receive privileged access except where required by the engagement and approved by [Policy Owner].

3.6 Physical Access

This section is usually short for early-stage SaaS, because physical access to production infrastructure is inherited from the cloud provider.

[Company] does not operate its own data centers. Physical security of production infrastructure is inherited from [Cloud Provider]'s SOC 2 Type 2 controls. [Cloud Provider]'s most recent SOC 2 Type 2 report is referenced in the [Company] vendor register and reviewed annually.

For a remote-first company: "[Company] does not operate a physical office. Personnel work from home or from co-working spaces they arrange independently. Company-issued devices are managed under the Acceptable Use Policy and Asset Management Policy."

For a company with an office: describe the actual badge or key controls and visitor procedures. Do not copy enterprise language about mantraps and biometric access if you have a leased floor with a front-desk buzzer.

4. Roles and Responsibilities

Every policy needs a named-role responsibility table. For a small company, this is usually three roles: a Policy Owner who maintains the policy and administers the quarterly privileged access review; Managers who submit access requests for their reports and review their reports' access quarterly; and all Personnel, who must request only the access needed for their role and report suspected credential compromise immediately.

5. Exceptions

Exceptions to this policy must be documented, approved in writing by [Approver], and reviewed at least quarterly. Unapproved exceptions are treated as violations.

6. Enforcement

Violations of this policy may result in disciplinary action up to and including termination, and may be treated as security incidents under the Incident Response Policy.

7 & 8. Related Documents and Revision History

A dated revision history table is table stakes. Every policy has it. Every change to the policy adds a row. Related documents typically include the Information Security Policy, Acceptable Use Policy, Incident Response Policy, Data Classification Policy, and Vendor Management Policy.

Four mistakes that turn this into a finding

A policy document is easy to write. The hard part is making it survive contact with an audit. Four patterns I've seen flag repeatedly:

Promising quarterly reviews you don't run. If you commit to quarterly privileged access reviews and your audit period is twelve months, the auditor will ask for four distinct review records. If they find three, that's a finding. If they find four but they're all dated the same week, that's also a finding. Run them on a schedule.

Access revocation that misses shared credentials. Termination checklists usually cover the identity provider — that's the easy part. What gets missed: shared passwords in the team password manager, standalone accounts on tools that aren't federated, personal devices with company data, API tokens. Your policy should name the full revocation surface, and your termination checklist should match.

Unlabeled privileged accounts. "Privileged" has to be defined in the policy, not left to interpretation. Without a definition, the auditor will ask you to list your privileged accounts, you'll produce a list, and they'll find an account that meets the common definition but isn't on your list. Define it in the policy; keep the list current.

Template language about physical security in data centers you don't operate. A remote-first SaaS should not have a section about "server room access logs" or "dual-custody key procedures for the cage." Auditors read these pages and immediately know which sentences are true. Write about the infrastructure you actually run.

The "what you actually do" test

Here's the fastest way to check whether your Access Control Policy is audit-ready: pick any five sentences at random from the policy. For each one, ask:

What would the evidence of this look like? Where would I find that evidence? When was the last time it was generated?

If you can answer all three questions for all five sentences, the policy probably survives. If you can't answer for two or more, your policy is describing a company you aspire to be rather than the one you are.

The fix is not to get more ambitious about the controls. The fix is to write a policy that matches the controls you actually run, and then tighten the controls themselves if the result feels thin.