SOC2Prep

SOC 2 access control policy: what to write

The document is short. The trouble is that four or five sentences in it set the tempo of your entire audit year, and a downloaded template picks them for you.

Last reviewed 2026-09-01Written by Jacob Masse, TrazTech Inc.

A SOC 2 access control policy has to answer six questions in writing: who approves access, how it is granted, what authentication is required, how often you review who has what, how fast access is removed when someone leaves, and who holds privileged rights. Two to three pages covers all six. Everything beyond that is padding, and every cadence you name in it becomes a control your auditor tests on a schedule for the rest of the observation window.

An American template pack will hand you monthly access reviews and 24 hour deprovisioning because those numbers read well. If you miss one round, the miss is an exception on your report, and it is an exception you wrote for yourself.

2 to 3 Pages a workable access control policy runs to

1 business day Offboarding commitment most small teams can actually keep

What has to be in the document

Provisioning and approval
Access is requested, approved by a named role, and recorded. Say which role approves production access, because "management" is not a role and the auditor will ask who that was on 3 March.
Authentication
Unique named accounts, single sign-on where the system supports it, multi-factor authentication with no standing exemptions, and password rules that your identity provider actually enforces. Write the rule you have configured, not the one you admire.
Least privilege and privileged access
Roles rather than per-person grants, and a named, small group holding administrator rights in the cloud account, the production database and the identity provider itself.
Access review
A stated cadence, a stated scope of systems, a named reviewer, and the requirement that removals get recorded. A review that found nothing to remove is still evidence; a review with no record is not.
Revocation
A time limit measured from a defined trigger. Define the trigger, since "termination" is ambiguous when someone resigns three weeks before their last day.

The policy checklist will tell you whether you also need this content split out into a separate password standard or a privileged access standard, which depends mostly on how many systems sit outside single sign-on.

What cadence should we commit to?

Quarterly access reviews are the default in every template and they are the right answer for maybe half of the companies that copy them. The comparison below is the one to make before you sign the document, using a worked estimate of about four hours per review round for a 40 person company with a dozen in-scope systems.

Annual access review effort by committed cadence At about four hours per review round, an annual cadence costs 4 hours a year, semi-annual 8, quarterly 16 and monthly 48. Hours per year spent on access reviews Annual 4 Semi-annual 8 Quarterly 16 Monthly 48 0 12 24 36 48
Worked estimate at four hours per round, 12 in-scope systems. Quarterly, highlighted, is the usual landing point. The same figures are in the table below.
Access review cadence: what you commit to and what it costs you
CadenceRounds per yearHours per yearWho it suits
Annual14Almost nobody. One round inside a 12 month window gives the auditor a sample of one, and a single missed month sinks it.
Semi-annual28A team under 15 people with few systems and low turnover. Defensible, and rarely challenged.
Quarterly416The default, and the right one for most 20 to 100 person companies.
Monthly1248Companies with contractor churn or a customer contract that demands it. Do not choose it to look serious.

The rule for every cadence in the document

Pick the frequency you will still be keeping in month nine, when the novelty is gone and the person who owns it is busy. You can tighten a cadence mid-window and the auditor will read that as improvement. Missing one you promised reads as a control that did not operate.

What gets an access control policy turned into a finding?

Rarely the structure. Almost always one of these five clauses, which arrive in nearly every downloaded pack and which you should cut or rewrite before the document is approved.

  1. "Access is reviewed on a periodic basis." Cut the word periodic. It is unauditable, and an auditor faced with it will either ask you to name a frequency or default to the strictest reading. Name the number.
  2. "Access is revoked immediately upon termination." Nobody revokes anything immediately at 6pm on a Friday. Write one business day, or 24 hours from notification to IT, and define which system that clock is measured in. Immediately means you fail on any timestamp that is not the same minute.
  3. Terminology from a company you are not. Packs written for US enterprises reference data owners, system custodians, a security operations centre and a change advisory board. If those roles do not exist on your organization chart, delete the sentences. An auditor who reads about a role will ask to interview the person holding it.
  4. Password rules that contradict your identity provider. A policy demanding 90 day rotation while your provider is configured for no expiry is a self-reported exception. Export the configuration first and write the policy to match it.
  5. Silence on contractors and service accounts. The most common real finding is not a policy defect at all: it is a contractor account or a machine account that no review ever covered because the review scope was written as "employees". Write the scope as accounts, not people.

None of that is exotic. It is what the policy templates page means when it says the editing is the work rather than the download, and the checklist section on access control lists the artifact each of these clauses has to produce once the policy is signed.

What the policy has to be able to produce

Write each clause so that a specific export answers it. The provisioning clause should be answerable with a ticket trail, the authentication clause with an enforcement report from the identity provider, the review clause with a dated record naming the reviewer and the removals, and the revocation clause with a per-departure checklist carrying timestamps. If you cannot name the export while writing the sentence, the sentence will be a problem later, and the evidence collection page covers what auditors accept in each of those formats.

Common questions

Can we fold access control into our information security policy?

Yes, and for a company under about 20 people it is usually the better choice. Auditors test coverage of the topic, not the number of files. What breaks is folding it in and then losing the specifics, so the merged document still needs the cadence, the time limit and the named approver role written out.

Do we need quarterly access reviews for SOC 2?

No. SOC 2 does not name a frequency anywhere. Quarterly is a convention that became an expectation because platforms ship with it. What the criteria require is that access is reviewed at a defined frequency and that you keep to yours.

What counts as evidence of an access review?

A dated record showing the system reviewed, the list of accounts as it stood, who reviewed it, and what was changed as a result. A screenshot of a user list with no reviewer and no date is the single most commonly rejected artifact in a first audit.

Our founders have admin on everything. Is that a problem?

Not by itself. Concentrated privilege in a small company is expected. What causes a finding is unexplained privilege: write down who holds administrator rights and why, review that list on the same cadence as everything else, and remove the accounts of people whose role changed.

Does PIPEDA change what goes in this policy?

Indirectly. PIPEDA expects safeguards proportionate to the sensitivity of the personal information you hold, so if your product holds customer records rather than anonymous telemetry, the access review scope should say so and should cover the systems where that data lives, including support tooling and data warehouses that engineering teams often forget.

Work out which policies you actually need

The set depends on your criteria and the data you hold, not on how many documents a template pack contains.

Run the policy checklist