Access control policy for SOC 2: what it should say

What an access control policy is for in SOC 2

An access control policy sets out who may access your systems and data, how that access is granted, protected and taken away, and who is responsible for each step. In a SOC 2 audit it is the reference point for the logical access controls in the Common Criteria. In general terms:

• CC6.1 covers logical access security over your software, infrastructure and data: authentication, restricting access to what is protected, and the systems that manage identities.
• CC6.2 covers registering and authorizing new users before they get access, and removing access when it is no longer needed.
• CC6.3 covers granting, changing and removing access based on roles and responsibilities, with least privilege and separation of duties in mind.

The auditor reads your policy, then tests whether you did what it says, so every statement is a promise. Promising to remove leavers' access within an hour is a finding waiting to happen if your real process takes two days. Write down good practice you actually follow.

Principles: least privilege, need to know, separation of duties

Open the policy statements with the principles every later rule follows from. Keep them short and concrete.

• Least privilege. People get only the access their role needs, at the lowest level that works. If every engineer is an admin by default, the policy and the practice disagree.
• Need to know. Access to sensitive or customer data is limited to people with a documented business reason. Tie this to your data classification, so "sensitive" means something specific.
• Separation of duties. No single person should be able to make and approve their own high-risk change, or grant themselves access. Small teams can't always split every duty, so say where you rely on a compensating control instead, such as a second person reviewing logs or approving changes.
• Unique accounts. Every person has their own account, so actions can be traced to an individual.

The account lifecycle: joiners, movers and leavers

Most access control findings come from the lifecycle, not from the principles. Cover each stage.

Request and approval

Access is requested and approved before it is granted, and both are recorded. Name who approves: usually the system owner or the person's manager. A ticket, a form or an approval in your identity provider all work, as long as it leaves a dated record.

Provisioning

New starters get access based on their role, ideally through groups or role templates in your identity provider rather than one-off grants. Say that default accounts and default passwords are disabled or changed before a system goes into use.

Role changes

When someone moves team, access they no longer need is removed. Teams often forget this step. Give it a timeframe, for example a few business days after the move.

Removal on termination

When someone leaves, their access is revoked within a stated timeframe, and immediately for involuntary departures. Pick one you can meet every time, including for Friday afternoon leavers. Many small companies commit to the last working day or the next business day. Also say that credentials for any shared or service accounts the leaver knew are rotated.

Authentication: SSO, MFA policy and passwords

This section usually doubles as your MFA policy and password policy.

• Single sign-on. Where a system supports it, access goes through your identity provider, so you can grant and remove it in one place.
• Multi-factor authentication. List where MFA is required. A common baseline is the identity provider, email, remote access, cloud consoles, source code hosting and any system holding customer or sensitive data. Some teams also state a preference for phishing-resistant methods such as security keys or passkeys where available.
• Passwords. Rules differ between companies, so choose ones that fit your tools. Common choices include a minimum length (12 or more characters is a frequent pick), a unique password per system, a company password manager, no sharing, and an immediate change when a password may have been exposed. Many teams drop routine forced rotation where MFA is in place.

Whatever you choose, make sure your systems are configured to match. An auditor may compare the password and MFA settings in your identity provider with the policy text.

Privileged and admin access

Admin, root, production and security tooling access deserves its own statements, because it is where a mistake or a compromised account does the most damage.

• Granted only to named people with a clear need, and kept to a short list.
• Separate admin accounts from everyday accounts where the system allows it.
• MFA always required.
• Time-limited where practical, for example elevated access granted for a task and removed afterwards.
• Reviewed by someone other than the account holder.

Shared, service and third-party accounts

Shared and service accounts

Shared logins for people break accountability, so the policy should say they are not used for day-to-day work. Where a shared or service account can't be avoided, it needs a named owner, a reason to exist, only the permissions it needs, and credentials kept in the password manager or a secrets store.

Contractors and other third parties

Contractors, consultants and vendor support staff follow the same rules as employees: requested and approved, individually assigned, MFA, least privilege. Add an end date to their access where possible, and name who is responsible for telling IT when the engagement ends, because third parties rarely show up in HR's leaver list.

Access reviews and exceptions

The policy should commit you to periodic access reviews: which systems, how often and who reviews. Quarterly is a common cadence for production and sensitive systems, with less frequent reviews for lower-risk systems. The review itself is a recurring control with its own steps and evidence, covered in How to run a user access review for SOC 2.

Then say how exceptions work. Some systems can't enforce MFA or SSO, and some people need temporary extra access. A workable exception process asks for:

• a written request with the business reason;
• the compensating controls in place;
• approval by a named role, such as the security lead;
• an expiry date, after which the exception is reviewed before it is renewed;
• a record of every exception in one place.

The evidence that proves the policy is followed

For a Type 2 report, the auditor samples events across the observation period and asks for proof. Exactly what they sample and which formats they accept is their call, so ask early. This table shows typical pairings:

To organize this across all your controls, see SOC 2 evidence collection.

Access control policy checklist

1. State least privilege, need to know, separation of duties and unique accounts.
2. Name who approves access requests, and require a record of each one.
3. Set timeframes for removing access on role changes and on termination that you can meet every time.
4. List where SSO and MFA are required, and the password rules you have chosen.
5. Cover privileged access, shared and service accounts, and contractors.
6. Commit to a review cadence for each group of systems.
7. Define the exception process, with approval and expiry.
8. Check your system settings and HR handoffs match the text.
9. Get the policy approved, have employees acknowledge it, and review it at least annually.

Running your access control policy in Confluence with Compliance in a Box

Compliance in a Box turns one Confluence space into your SOC 2 program. When you set up SOC 2, it creates an Access Control Policy page that covers passwords and MFA, mapped to CC6.1, CC6.2 and CC6.3 in the app's controls matrix. Like every policy template, it has Purpose, Scope, Roles & Responsibilities, Policy Statements, Exceptions, Enforcement and Related Documents sections, and your company name and security contact are filled in when the page is created. The template is a starting point: tailor it to how your company works before you approve it.

From there, the policy is managed like this:

• An owner and a lock. A Compliance Admin assigns the owner and one to ten approvers in Settings, under Owners & approvers. The page is locked so only the owner and Compliance Admins can edit it (page restrictions need Confluence Standard or above). See Who can edit a policy.
• Version-bound approval. The owner selects Submit for approval, and every approver must approve. The approval is tied to the exact Confluence page version, so editing the page cancels a pending submission and an approved policy shows Changes pending until the new text is approved. If an owner approves their own policy, it is flagged as a self-approval, which supports the separation of duties point above. More on this in Policy version control and approvals auditors accept.
• Employee acknowledgement. The Access Control Policy requires acknowledgement. On the first approval, and on any version marked as a Material change, everyone in the policy's audience is asked to acknowledge it with one click, with 30 days to do so. New joiners in the audience are picked up by the daily check. See Policy acknowledgements.
• Annual review. The policy defaults to a 12-month review. It is flagged Review due 30 days ahead, and Mark as reviewed records a no-change review that still goes to the approvers.

The policy's review commitment is backed by the User Access Review recurring activity, quarterly by default and mapped to CC6.2 and CC6.3. Before each quarter is due (14 days ahead by default), the app creates an evidence page under the activity page with a checklist for the systems in scope, the reviewer, the users removed or changed, and the exports attached. The owner submits it for approval, and periods that pass their due date without approval show as overdue. See Recurring activities for the full workflow.

FAQ

Does SOC 2 require MFA?

The Trust Services Criteria don't prescribe specific technologies. They ask for logical access controls that fit your risks, and your policy sets the rules. In practice, auditors expect strong authentication on systems that hold customer data, and MFA is the usual way to show it.

Do we need separate MFA and password policies?

No. Many companies put authentication rules in the access control policy, which means one fewer document to approve and review. Either approach works if the rules are written down and followed. For the other policies a SOC 2 program usually has, see Which SOC 2 policies do you need?

How fast must we remove a leaver's access?

SOC 2 doesn't set a number. You choose a timeframe in your policy, and the auditor tests whether you met it for the leavers they sample. Choose one you can meet every time.

← All articles