Auditors see the same access review problems across nearly every mid-market SOC 2 engagement. If you've had a finding on CC6.1-6.3 in a prior audit, it almost certainly falls into one of a handful of recurring patterns — and each one has a specific, buildable fix rather than "review more carefully next time."
Failure 1: Rubber-Stamped Reviews With No Judgment Evidence
What auditors flag: A reviewer attested to 60+ rows of access in an afternoon with zero flagged items. That's statistically implausible for most real organizations and reads as a checkbox exercise, not genuine review.
The fix: Pre-flag risk before a human ever sees the review — dormant accounts (no login in 90+ days), privilege combinations that violate separation of duties, and access that doesn't match the reviewer's own team roster. This forces the reviewer to engage with a shorter, higher-signal list instead of skimming past everything.
Failure 2: No Timestamped Decision Trail
What auditors flag: A shared spreadsheet edited in place, with no record of who reviewed which row or when — just a final "approved" state with no history.
The fix: Every review decision needs an immutable, timestamped record: reviewer identity, entitlement reviewed, decision, and rationale where relevant. This is table stakes for CC6.1 evidence and is straightforward to build as an append-only log rather than a mutable spreadsheet cell.
CREATE TABLE access_review_decisions (
id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
reviewer_id TEXT NOT NULL,
principal TEXT NOT NULL,
source_system TEXT NOT NULL,
entitlement TEXT NOT NULL,
decision TEXT NOT NULL CHECK (decision IN ('approve', 'revoke', 'escalate')),
reviewed_at TIMESTAMPTZ NOT NULL DEFAULT now(),
rationale TEXT
);
Failure 3: "Revoke" Decisions That Never Actually Happen
What auditors flag: A reviewer marked access for removal, but the underlying account still has that permission three months later at the next review cycle. This is the single most damaging finding pattern because it demonstrates the review process itself is ineffective, not just imperfect.
The fix: Close the loop programmatically. A revoke decision should generate a ticket with an SLA, or trigger an automated deprovisioning action for systems where that's safe, and the review evidence should reference the remediation ticket ID so the auditor can trace decision → action → verification.
Failure 4: Access Reviews That Don't Cover Every System in Scope
What auditors flag: The review evidence covers your SSO-connected SaaS apps beautifully but has a gap for AWS console access, database roles, or an internal admin tool nobody thought to include in scope.
The fix: Build a system inventory that maps every system touching in-scope data to a review owner, before the review cycle starts — not discovered reactively when the auditor asks "what about this system?" This inventory itself becomes useful audit evidence of a mature access governance program.
Failure 5: No Separation Between Provisioning and Review
What auditors flag: The same person who grants access also "reviews" it, with no independent check — undermining the control's design, not just its operation.
The fix: Route review ownership to a different party than the provisioner — typically the resource/system owner or the requester's manager — enforced structurally in the review tool rather than as an informal policy nobody checks.
Building This Once, Not Every Quarter From Scratch
Most companies rebuild their access review process from scratch every cycle because the underlying entitlement data was never centralized. The fix that actually holds up across multiple audit cycles is a standing pipeline: continuous entitlement ingest from every in-scope system, a normalized role model reviewers can actually understand, and a remediation loop with proof of execution — reviewed on the same cadence, but never rebuilt from zero. This is the same architecture behind our broader user access review automation approach.
Frequently Asked Questions
What's the most common single reason companies fail an access review control test?
Unremediated "revoke" decisions — access flagged for removal in a prior review that's still active when the auditor samples it later. This is the pattern auditors specifically test for because it proves whether the control actually works.
Can we fix a failed finding before our next audit window?
Often yes, if the finding is process-related (missing evidence trail, unremediated revocations) rather than a fundamental system gap. Building the evidence pipeline and running one clean cycle before the next audit window is usually enough to close the finding.
Do auditors require a specific review frequency?
SOC 2 doesn't mandate a universal frequency, but quarterly is the most common cadence for privileged and sensitive access, with less-sensitive standard access sometimes reviewed less frequently. Your specific control language in the SOC 2 report defines what you committed to — consistency with that commitment matters more than the specific interval chosen.
Does this apply to Type I or Type II reports, or both?
It matters more for Type II, since Type II specifically tests operating effectiveness over a period of time — meaning the auditor will sample multiple review cycles and check for consistent, evidenced execution, not just a single point-in-time snapshot.
What if we already use an IGA tool but it doesn't cover all our systems?
That's the exact gap we build for — extending review coverage to internal, non-SCIM, or database-level systems that off-the-shelf identity governance tools don't reach, feeding clean evidence back into your existing platform.
See what an Access & Credential Governance Diagnostic finds in your environment → rutagon.com/contact or call 907-841-8407.