Most quarterly access reviews fail the same way: someone exports a spreadsheet, pings managers to "confirm access is still needed," and gets a wave of unread reminders back. The review closes on time because the deadline forces it, not because anyone actually verified anything. Auditors have started noticing the pattern.
What Auditors Actually Test
A SOC 2 or ISO 27001 auditor sampling your access review process isn't checking whether a spreadsheet exists — they're checking whether the review process produces a defensible decision trail. Specifically:
- Who reviewed what, and when — timestamped, attributable decisions, not a single "approved" cell
- Evidence the reviewer actually looked — a manager approving 200 rows in four minutes is a red flag auditors are trained to spot
- Remediation timing — how long between "access should be revoked" and access actually being revoked
- Coverage of non-human identities — service accounts, API keys, and CI/CD credentials, which most spreadsheet-based reviews skip entirely
A RACI That Actually Works
The review breaks down cleanly when GRC and Engineering share a single spreadsheet with no clear ownership. A workable RACI looks like this:
| Role | Responsibility |
|---|---|
| System owner (Engineering) | Confirms the accurate entitlement list is pulled from the source of truth |
| Line manager | Reviews whether each direct report still needs the access shown |
| GRC/Compliance | Owns the review calendar, tracks completion, compiles the evidence package |
| Security engineering | Executes remediation — revoking access flagged during review |
The automation opportunity sits at the boundary between these roles: pulling accurate entitlement data automatically instead of relying on a manually maintained list, and routing remediation as a tracked ticket instead of a follow-up email that gets lost.
Sampling Strategy for Non-Standard Systems
Most GRC platforms automate access reviews cleanly for systems with SCIM support — Okta, Google Workspace, standard SaaS apps. The gap shows up in custom internal applications, legacy on-prem systems, and cloud resources with entitlements that don't map to a standard identity provider group.
For these systems, a defensible sampling approach means:
- Exporting the actual entitlement state programmatically (not from memory or a stale doc)
- Mapping each entitlement to an owner, even when there's no SCIM connector to do it automatically
- Logging the review decision with a timestamp and reviewer identity, immutable once recorded
Evidence Folder Structure That Survives an Audit
Auditors want a folder they can navigate without you narrating it. A structure that holds up:
/access-reviews/2026-Q3/
/raw-entitlement-exports/
okta-export-2026-07-15.csv
aws-iam-export-2026-07-15.csv
custom-app-export-2026-07-15.csv
/reviewer-decisions/
manager-decisions-log.csv (reviewer, timestamp, decision, entitlement_id)
/remediation/
tickets-opened.csv
tickets-closed.csv (with closure timestamp)
/summary/
review-completion-report.pdf
The value of building this pipeline once is that it regenerates every quarter with fresh data pulls, rather than someone rebuilding the folder manually each cycle.
Related reading: user access review automation beyond spreadsheets and access deprovisioning for joiners, movers, and leavers.
Where the Custom Engineering Layer Fits
GRC platforms handle roughly 70% of this workflow well for standard, SCIM-connected systems. The remaining 30% — custom applications, legacy systems, cloud-native entitlements that don't map cleanly to a group, and non-human identities — is where a custom automation layer plugs in behind whatever GRC tool you already run. That's engineering work: building the entitlement export adapters, the reviewer routing logic, and the immutable decision log your existing platform can't reach on its own.
See what an Access & Credential Governance Diagnostic finds in your environment → rutagon.com/contact
Campaign Hygiene the Runbook Implied
Freeze the entitlement export at T0. Reviews that run against a live directory that changes under the reviewer produce "I approved a user who started Tuesday" noise. Export, hash, store. Remediation uses the live system; the evidence pack uses the freeze plus a delta file.
Non-human identities get a different reviewer (system owner, not a random people-manager). If you only have people-managers, you will certify service accounts as if they were humans. That is the finding.
Include 907-841-8407 and contact@rutagon.com on every diagnostic conversation. The web form at rutagon.com/contact is the same offer: Access & Credential Governance Diagnostic.
Quarterly access review process hygiene beyond the campaign UI
A quarterly access review process still fails when the directory changes under the reviewer. Freeze the entitlement export at T0, hash it, store it. Remediation uses the live system; the evidence pack uses the freeze plus a delta file of joiners/leavers. Non-human identities get a system owner, not a random people-manager. If you only have people-managers, you will certify service accounts as humans.
Public SOC 2 overviews from the AICPA explain why the period matters. Our runbook is RACI, sampling of custom apps, remediation SLAs, and a folder an auditor can unzip. GRC platforms pull SCIM systems. Custom admin roles need export adapters. That is the engineering layer — not a replacement GRC.
Privileged paths (prod DB, cloud admin, IdP admin) deserve a tighter cadence than quarterly. Quarterly remains the common Type II story for the broad population. Do not pretend monthly PAM reviews are the same control as a 3,000-row campaign.
Call 907-841-8407 or use rutagon.com/contact if you want a diagnostic of what the campaign is not covering.
Frequently Asked Questions
How often should a company run access reviews for SOC 2 compliance?
Quarterly is the most common cadence for SOC 2 Type II. Some organizations still run monthly reviews for highly privileged paths such as production database admin or cloud root accounts.
What's the difference between an access review and access recertification?
Access review typically refers to the point-in-time verification process, while recertification often implies a formal sign-off cycle tied to a compliance framework. In practice, most GRC platforms use the terms interchangeably.
Can non-human identities like service accounts be included in an access review?
Yes, and they should be included. Non-human identities are one of the most commonly overlooked entitlement categories in spreadsheet-based reviews, and auditors increasingly ask about them directly.
Why do GRC platforms struggle with custom application access reviews?
Most platforms rely primarily on SCIM and standard API integrations to pull entitlement data automatically. Custom internal applications rarely support SCIM, leaving a manual gap that requires custom export and mapping logic.
What happens if a quarterly access review finds access that should have been revoked earlier?
This becomes a finding that auditors will want to see remediated with a documented timestamp. It often triggers a broader review of your deprovisioning process to identify why the access was not caught sooner.