Every SOC 2 Type II audit will include some version of the same question: how do you verify that only authorized people have access to your production systems? CC6.3 requires that you register, authorize, and modify access based on job roles, and that you remove access when it's no longer needed. The control looks simple on paper. Running it at any meaningful scale — across cloud IAM roles, identity provider groups, SaaS application seats, and database access permissions — exposes every friction point in how most teams actually manage access.
The manual quarterly access review (also called an access certification campaign) is where those friction points compound. The access review evidence that auditors see is often dated, incomplete, and assembled under pressure. This post is about why that happens structurally, not because teams are negligent.
The Structural Problem with Manual Access Reviews
A typical manual access review process looks like this: one week before the end of the quarter, someone on the security or GRC team exports user lists from Okta, AWS IAM, and the primary SaaS tools used by engineering and operations. The exports go into a spreadsheet. Managers are assigned rows to review. The spreadsheet gets shared via email. Some managers review it promptly; others don't. The GRC team sends reminders. After three to five days, incomplete responses start coming back.
The core problem here is not that managers are busy (they are). It's that the access snapshot they're reviewing may be anywhere from two to eight weeks old by the time the review completes. Access was granted, modified, or left in place during that gap — and the review evidence reflects a state of the world that no longer exists.
For the auditor, CC6.3 compliance isn't just about whether you ran the review. It's about whether the review was timely, whether findings were acted upon, and whether the evidence shows a closed loop: access reviewed, inappropriate access identified, access removed, removal documented. A spreadsheet with 67% manager response rate and no documented follow-up on the flagged accounts doesn't satisfy that closed-loop requirement.
What Access Drift Looks Like in Practice
Access drift is the accumulation of excess permissions between formal review cycles. It happens through ordinary operational activity:
- An engineer is granted elevated IAM permissions to debug a production issue and the permissions aren't revoked after the incident closes.
- A contractor finishes their engagement, their HR record is updated, but their Okta group memberships and database access aren't removed because offboarding isn't fully integrated.
- A team member moves from the engineering team to sales. Their production read access stays active because the access modification request never gets submitted.
- A SaaS tool gets added to the stack. Fifteen people get provisioned with admin access during setup. Six months later, twelve of them have no operational reason for admin access, but no one ran a right-sizing review.
Each of these is a CC6.3 gap in isolation. When multiple instances accumulate across your IAM, identity provider, and application layer simultaneously, your access surface has drifted significantly from what your formal access policy intends — and you won't fully see it until the next review cycle, if the review is thorough enough to catch it.
A Scenario: Access Review Coverage at Scale
Consider a 90-person B2B SaaS team with a 3-person GRC function. Their access review scope covers: AWS IAM roles (240 policies, 38 users with direct permission attachments), Okta groups (67 groups, 312 active user profiles), their core product database (role-based access with 8 distinct privilege levels), Jira and Confluence administration, and 11 additional SaaS tools with dedicated admin roles. Their quarterly review is entirely manual.
In the first quarter of their SOC 2 observation period, the review took 12 days to complete. Manager response rate was 71%. Of the 312 Okta users reviewed, 14 were flagged as needing access changes. Eight of those 14 had the changes applied within the review cycle. Six did not — the tickets were open but not resolved before the quarter closed. The evidence package shows flagged access and open remediation tickets, but no closed-loop evidence for those six accounts. The auditor issued a management comment against CC6.3 noting incomplete remediation tracking.
This is not an unusual outcome. The access review process worked. The remediation tracking did not. The gap between identifying excess access and confirming it was removed is exactly where manual processes lose fidelity.
Continuous Monitoring as the Alternative Model
The conceptual shift from periodic access reviews to continuous access monitoring is worth explaining precisely, because the two are often conflated.
A periodic access review is a snapshot: at a point in time, you compare who has access against who should have access. Continuous monitoring is a stream: you observe access state changes as they occur and flag anomalies against policy in near-real-time.
In a continuous model, the access certification campaign still exists — but it becomes smaller and lower-stakes. Instead of reviewing 312 user records from scratch every quarter, the GRC team reviews the delta: accounts where access changed since the last review, accounts with roles that exceed their job function baseline, accounts that haven't been active in a defined period. The quarterly review is a confirmation of an already-monitored state, not a retroactive investigation.
We're not saying continuous monitoring eliminates access reviews — CC6.3 requires periodic certification and the audit evidence needs to reflect that. We're saying that continuous monitoring shrinks the scope of each certification cycle and closes the gap between when access drift occurs and when it's detected.
What the Evidence Package Needs to Show
For auditors reviewing CC6.3, the evidence they want to see is structured around three things:
1. Review Scope and Coverage
Which systems were in scope for the review, how many accounts were reviewed, and what percentage of managers completed their review assignments. Auditors flag reviews with low completion rates as controls that weren't operating effectively for the full period.
2. Findings and Disposition
How many accounts were flagged, what types of access were at issue (excess privilege, dormant accounts, role misalignment), and how each was resolved. A flagged account that was reviewed but with no action recorded is treated as unresolved.
3. Remediation Timing
How quickly was flagged access removed? Auditors will look at the timestamp between "flagged in review" and "access removed" events. A 90-day gap on a high-privilege account is a meaningful control failure even if it eventually got remediated.
In a manual process, assembling this evidence requires reconstructing a chain of events across email threads, spreadsheets, and ticketing systems. In an instrumented system, that chain is automatically timestamped and directly exportable to an audit package.
What We Built in Tenurex to Address This
When we designed Tenurex's access review module, we started from the auditor's evidence requirement and worked backward to the operational process. The result is a review workflow that generates a timestamped, exportable evidence log as a byproduct of the review itself — not a post-hoc reconstruction.
Tenurex connects to your identity provider and cloud IAM to maintain a live access inventory. When a quarterly review cycle opens, the review scope is pre-populated from that inventory. Managers receive review assignments with current access context — not a static export from two weeks ago. Disposition decisions (confirm, revoke, escalate) are recorded with timestamps and the identity of the reviewer. Revocation actions are tracked against the linked ticket or automation. The closed-loop evidence package is generated automatically when the review cycle closes.
The team that ran a 12-day review with 71% completion and six open remediations could, with this structure, see that those six accounts were unresolved before the quarter ended — giving them time to close the loop within the observation window rather than explaining the gap to an auditor. The access review becomes a control that actually operates as designed, rather than one that produces evidence of partial operation.
Access drift doesn't announce itself. It accumulates quietly between the scheduled moments when you're paying attention. The answer isn't a better spreadsheet — it's a process that keeps the current state visible at all times, so the periodic review confirms what you already know rather than discovering what you've been missing.