How to run an access review an auditor will accept

The one control worth looking at on day one of an engagement is the access review. Not because it is the most important control — because it is the one that shows how the company really operates. A company that reviews access on a calendar, with a named approver, and keeps the evidence, usually does everything else properly too.

A note on "the most common exception"

You will read a lot of confident claims about which control produces the most first-year SOC 2 exceptions, including an earlier version of this article. It is worth being straight about the status of that claim.

Nobody can source it, and we could not source ours either. SOC 2 reports are distributed to customers under non-disclosure agreements. There is no public corpus of them to count, the way there is with SEC filings, so no study of SOC 2 exception rates exists — not from the AICPA, not from academia, and not behind the vendor blog posts that rank them. What those posts are describing is one firm's caseload, which is a reasonable thing to have an opinion from and not a statistic.

So: in our practice, incomplete or undocumented user access reviews are the exception we see most often in a first-year SOC 2. Treat that as observation, not measurement.

The nearest thing to real data comes from the adjacent SOX world, where filings are public and can be counted. In Ideagen Audit Analytics' nineteen-year review of SOX 404 disclosures, information technology issues were cited in 54.5% of adverse ICFR auditor attestations for FY2022 — the top issue that year, and the first time in five years IT had taken the top spot. The same report finds that an ICFR disclosure is, on average, three times more likely to be adverse during a first-time assessment. Different framework, different population, same shape of problem: IT controls, and the first year is the hard one.

What the criteria actually say

Access reviews sit under two of the trust services criteria, and they cover different things — a distinction worth getting right, because saying "CC6.2 or CC6.3" reads like someone who has not opened the document.

CC6.2 is about credentials and accounts. The criterion reads, in part, that "prior to issuing system credentials and granting system access, the entity registers and authorizes new internal and external users," and that "user system credentials are removed when user access is no longer authorized."

CC6.3 is about roles, entitlements and rules: the entity "authorizes, modifies, or removes access to data, software, functions, and other protected information assets based on roles, responsibilities, or the system design and changes, giving consideration to the concepts of least privilege and segregation of duties."

Here is the nuance most articles miss. Periodic review is not in either criterion. It appears in the points of focus underneath them — under CC6.2, "the entity reviews access credentials on a periodic basis for validity"; under CC6.3, "the appropriateness of access roles and access rules is reviewed on a periodic basis." The AICPA is explicit that using the criteria does not require an assessment of whether each point of focus is addressed.

That is not a loophole. An auditor still has to form an opinion on CC6.2 and CC6.3, and a periodic review is the ordinary way a company demonstrates that access remains authorized and appropriate. But it does mean the accurate sentence is "the points of focus call for periodic review," not "CC6.3 requires a quarterly access review" — which is a rule nobody wrote.

And nothing anywhere specifies a frequency. The criteria say "periodic." NIST SP 800-53 requires you to "review accounts for compliance with account management requirements" at an organization-defined frequency, and to review assigned privileges at an organization-defined frequency under AC-6(7). NIST's Cybersecurity Framework 2.0 says access permissions are "defined in a policy, managed, enforced, and reviewed." None of them says quarterly. What they require is that you pick an interval and meet it.

Access reviews are also, formally, an IT general control. The AICPA's SAS No. 145 defines general IT controls and lists example ITGCs by process — "user-access reviews: controls to recertify or evaluate user access for ongoing authorization over time" appears by name.

Why reviews fail the test

Most companies do review access. The exception comes from one of four things:

1. No named approver. "The team looked at it" is not testable. One person signs.
2. No evidence. The review happened in a meeting; nothing was retained.
3. No action trail. Accounts were flagged for removal; nobody can show they were removed.
4. Wrong population. The review covered the application but not the database, the cloud console, or the deploy pipeline.

The fourth is the one that surprises people. An access review over the application while the engineers hold standing credentials to the database underneath it does not tell an auditor what it needs to know, and a reviewer who knows the stack will ask.

The minimum that passes

This is our recommendation, built from what survives testing — not a standard:

• Quarterly, on a calendar, for production systems that touch customer data. Pick the interval deliberately, write it in the policy, and then hold to it; an interval you miss is worse than a longer one you keep.
• A system-generated export of users and permissions — not a hand-typed list. The population is the first thing an auditor reperforms.
• One named reviewer per system who understands what the permissions mean. Not the CFO by default; the person who can say whether this engineer should still have production write access.
• A ticket that records the review, the decisions, and the removals, with a completion date.
• Follow-through within a defined window — five business days is a reasonable target. Define it, then meet it.
• Privileged accounts reviewed separately, and service accounts included. Shared and service accounts are where reviews most often go quiet.

Evidence an auditor will ask for

Request	What satisfies it
Population of systems in scope	A list, with an owner for each
Proof the review occurred	The export, the ticket, the sign-off, dated
Proof of action	Tickets or logs showing removals
Consistency	The same thing, every period, across the observation window

Three quarters of this, done the same way, is a clean control. One good quarter and two spreadsheet quarters is an exception — not because spreadsheets are disallowed, but because the inconsistency is what the auditor samples into.

If you are not sure whether your current process would survive that, the readiness scorecard asks the same question an auditor would, and Type 1 vs Type 2 explains why the consistency across a window matters more than any single quarter.

Common questions

How often does a SOC 2 access review have to happen?

No framework in this area sets a frequency. The trust services criteria say access roles and rules are reviewed on a periodic basis; NIST SP 800-53 leaves the interval as an organization-defined frequency. Quarterly is a convention and our own recommendation, not a requirement — what matters is that you define an interval, and then meet it every time.

Which trust services criteria do access reviews map to?

Both CC6.2 and CC6.3, and they cover different objects. CC6.2 concerns registering and authorizing users and removing credentials when access is no longer authorized. CC6.3 concerns authorizing, modifying and removing access to assets with regard to least privilege and segregation of duties. Most real access reviews touch both.

Is a periodic access review actually required by the criteria?

Strictly, periodic review appears in the points of focus beneath CC6.2 and CC6.3 rather than in the criterion text itself, and the AICPA is explicit that using the criteria does not require assessing whether each point of focus is addressed. In practice, an auditor forming an opinion on CC6.2 and CC6.3 will expect to see how you satisfy yourself that access remains appropriate — and a periodic review is the usual answer.

What evidence does an auditor actually test?

A system-generated population of users and permissions, a named reviewer's sign-off, a record of the decisions made, and proof that the removals happened — with dates that line up. A review that produced no removals is fine if that is genuinely the answer; a review that flagged accounts nobody can show were removed is an exception.

Does a spreadsheet review count?

It can, if the population came out of the system rather than being typed by hand, one named person signed it, and the follow-up actions are traceable. What fails testing is not the spreadsheet — it is the missing population, the absent approver, and the removals nobody can evidence.

Sources

1. TSP Section 100, 2017 Trust Services Criteria (With Revised Points of Focus — 2022) — see CC6.2 and CC6.3 · AICPA Assurance Services Executive Committee
2. Statement on Auditing Standards No. 145, Understanding the Entity and Its Environment and Assessing the Risks of Material Misstatement (AU-C section 315) — Appendix F · AICPA Auditing Standards Board
3. NIST SP 800-53 Rev. 5, Security and Privacy Controls for Information Systems and Organizations — AC-2 Account Management, AC-6(7) Review of User Privileges · National Institute of Standards and Technology
4. The NIST Cybersecurity Framework (CSF) 2.0 (NIST CSWP 29) — PR.AA-05 · National Institute of Standards and Technology
5. SOX 404 Disclosures: A 19-Year Review, 2004–2022 · Ideagen Audit Analytics