Linford and Company, a CPA firm, published detailed user access review guidance on 3 December 2025. One of its points is that review notes never acted on leave access unchanged. A spreadsheet that a manager signed, with no record that anything changed, will not hold up in fieldwork.
What's affected
Criteria CC6.2 and CC6.3 in the AICPA Trust Services Criteria. CC6.2 requires that before issuing credentials the entity "registers and authorizes new internal and external users," and that credentials are removed "when user access is no longer authorized." CC6.3 requires that access is authorized, modified or removed "based on roles, responsibilities, or the system design and changes, giving consideration to the concepts of least privilege and segregation of duties."
The points of focus in the AICPA text include reviewing the appropriateness of access credentials and of access roles on a periodic basis. The criteria do not set a cadence. Your policy does, and the auditor tests what your policy says.
How to check if you're exposed
Pick your three most sensitive systems, typically production cloud, source control and the identity provider, and answer these.
- Can you export the full user and permission list today, without asking the vendor?
- When was the last review, who did it, and where is the record?
- Compare the list with HR's current staff and contractor list. Does anyone remain who has left, or who has changed role?
- Did the last review produce any change? If nothing ever changes, the review is probably not looking hard.
What to do now
- Set a cadence by risk. Linford says reviews should happen "at least annually, but more frequently (e.g., monthly or quarterly) for high-risk systems." Quarterly for production and source control is a common choice. Whatever you pick goes in the policy and must be kept every time.
- Involve people who know the work. The same guidance says IT or compliance staff should not be the only reviewers, and names department managers and system owners as the people who know what access is needed.
- For every review, save: the systems covered, the access list as it stood on the review date, the reviewer, the decision for each account, the changes requested, and proof that each change was made.
- Add a verification step. Re-pull the list after changes, or create a ticket per change and close it with evidence.
- Review service accounts, API keys and contractor accounts with the same rigor as staff accounts.
An evidence record per review, in plain text:
System: production cloud account
Review date: 2026-10-01 Reviewer: head of engineering
List source: identity provider export, 2026-10-01 09:12
Accounts reviewed: 41 Changes requested: 3
Change 1: remove contractor X, ticket SEC-218, done 2026-10-02
Change 2: reduce admin to read-only for Y, ticket SEC-219, done 2026-10-02
Change 3: remove unused service key Z, ticket SEC-220, done 2026-10-03
Verified: re-export 2026-10-04, all three changes confirmed
How to avoid this trap
- Do not review from memory. A list with dates, pulled from the system, is the only reliable input.
- Do not stop at "approved." Linford's guidance describes review notes that were never acted on, leaving access unchanged, which is the failure auditors find.
- Do not let one person review their own access.
- Do not skip a quarter. A control you describe as quarterly is tested across the whole period.
Why it matters
Access changes constantly. People join, contractors rotate, and tools get connected through a quick sign-in. A review is the only control that catches the account nobody remembers.
The documentation rule is blunt. In Linford's words, "if it is not documented, auditors will treat it as though it never happened."
Try it yourself
Export the user list from one system and highlight every account you cannot name an owner for. Open a ticket for each, then close the loop with a second export a few days later. That one cycle is a complete review record.
Click through it at your own pace, or open it full screen.
Quick check
Does SOC 2 say how often access must be reviewed?
No. The criteria call for periodic review. You set the cadence in your policy, based on risk, and the auditor tests that you followed it.
What proves that a review changed anything?
A record of the requested change and evidence it was completed, such as a closed ticket and a fresh export showing the access is gone.
