SOC 2 Access Review Process: Periodic User Access Certification

Maria Delgado had built the access review deck three times before her auditor ever opened it. As Director of Security and Compliance at DataVantage Analytics — a 220-person customer-analytics SaaS platform processing behavioral data for retail chains — she'd assumed "we review access" was a sentence, not a program. Then Ashcroft & Vale LLP, the CPA firm running DataVantage's first SOC 2 Type II examination, requested evidence of quarterly user access reviews for the six-month observation period. Maria had one screenshot from March. Nothing from January, April, or June. A $2.4 million enterprise renewal with a national retail client was contractually contingent on a clean SOC 2 report landing before the customer's own audit committee met in eight weeks.

What followed was three weeks of scrambling: pulling user lists from Okta, AWS IAM, Salesforce, Snowflake, and a homegrown billing system; chasing eleven department managers for sign-off on people who had, in several cases, left the company months earlier; and discovering that a departed contractor still held standing production database access nobody had revoked. The auditor didn't just flag a missing control — she flagged a pattern, because access reviews are one of the most heavily sampled tests in any SOC 2 examination, and inconsistency is exactly what a CPA is trained to smell.

This article exists because Maria's scramble is astonishingly common, and it's almost entirely preventable with a repeatable process built before the audit clock starts, not during it.

Who this is for and what you'll walk away with

This is written for the people who actually run access reviews — security and IT leaders, GRC managers, and engineering managers at service organizations pursuing or maintaining a SOC 2 report — not for auditors explaining the standard from the outside. You'll walk away with a concrete review cadence you can defend to an auditor, a reviewer-role model that doesn't collapse under its own weight, a checklist of what "least privilege" actually means when you're staring at a spreadsheet of 400 users, and the exact evidence artifacts — signed reviews, tickets, exception logs — that turn a sampled test into a non-event. We'll also cover privileged access, orphaned and terminated accounts, remediation SLAs, and how to build a program that survives turnover on your own team, not just the next audit.

Why access reviews sit at the center of every SOC 2 audit

Access review evidence shows up in nearly every SOC 2 Type II fieldwork request list, and for good reason: it's the single control that proves — or disproves — that everything else you say about access control is actually true day to day, not just on paper. A well-written access provisioning policy means little if nobody checks, three months later, whether the access granted still matches the job the person holds. Auditors know that access sprawl is the default state of every growing organization; the review is the mechanism that fights entropy back.

Under the AICPA Trust Services Criteria, access reviews map most directly to the CC6 series — the logical and physical access controls that form the backbone of the Security (Common Criteria) category required in every SOC 2 report. Specifically:

• CC6.1 requires the entity to implement logical access security software, infrastructure, and architecture over protected information assets to protect them from security events, which includes restricting access to authorized users and periodically evaluating that access remains appropriate.

• CC6.2 requires that prior to issuing system credentials and granting access, the entity registers and authorizes new internal and external users, and that access is modified or removed when no longer required — the de-provisioning half of the equation, which a review is designed to catch when it fails.

• CC6.3 requires the entity to authorize, modify, or remove access based on roles, responsibilities, or the system design, and to review such access on a periodic basis for appropriateness — the specific criterion most auditors cite by name when they request your access review evidence.

Together, CC6.1 through CC6.3 form what I think of as the access lifecycle triangle: grant appropriately, maintain appropriately, and periodically prove both. The review is the "prove it" leg, and it's the leg auditors sample hardest because it's cheap to test and highly diagnostic. Pull a population of reviews, sample a handful, and check whether the sign-off actually reflects reality — an auditor can do that in an afternoon and learn more about your control environment than a week of policy reading would tell them.

If you haven't already, it's worth reading how access controls and logical security are structured at DataVantage-style organizations before you build a review program on top of them — the review is only as good as the provisioning process feeding it.

What an access review actually is (and isn't)

An access review — sometimes called a user access certification, an entitlement review, or a recertification — is a point-in-time, documented process where someone with the authority and context to judge appropriateness looks at who has access to what, and either affirms it, flags it for change, or flags it for removal. It is not the same thing as continuous monitoring, and I've watched more than one audit stumble because a company conflated the two.

Continuous monitoring — automated alerts on privilege escalation, unusual login patterns, or configuration drift — is valuable and increasingly expected, but it answers a different question: "did something unusual just happen?" An access review answers a slower, more deliberate question: "looking at the full population of access right now, is each grant still justified?" You need both. A SIEM alert won't tell you that Derek in finance still has admin rights to a system he moved off of eight months ago because nothing "anomalous" happened — the access was simply never revoked, and it will sit there quietly until either an attacker finds it or a reviewer does.

The distinction matters for evidence, too. Auditors want to see the deliberate, periodic, human judgment call — a reviewer's signature or system-recorded approval — not just a log stream. A review is inherently a point-in-time attestation with a named accountable person behind it, which is precisely why CC6.3 language uses "periodic" and not "continuous."

The JML lifecycle: where the review fits

Every access review program sits inside the broader joiner-mover-leaver (JML) lifecycle, and understanding that placement is what keeps a review program from becoming redundant busywork or, worse, a false sense of security layered on top of a broken provisioning process.

• Joiner: a new hire or contractor is granted access based on role, typically through a request/approval workflow tied to HR onboarding.

• Mover: an existing person changes role, team, or manager, and their access should change to match — this is the stage most organizations handle worst, because moves rarely trigger an automatic access review the way terminations (usually) do.

• Leaver: a person's employment or engagement ends, and access should be revoked, ideally same-day or within a contractually defined window.

The access review is the safety net underneath all three stages. Joiners get reviewed to confirm the initial grant was appropriate and nothing extra slipped in during onboarding. Movers get reviewed because role changes are the single biggest source of privilege creep — someone accumulates access from their old role plus their new one, and nobody ever prunes the old permissions. Leavers get reviewed because de-provisioning failures — the "orphaned account" problem — are the single most common access-related exception auditors write up.

Defining "least privilege" in a way a reviewer can actually apply

Least privilege is one of those principles everyone nods along to and almost nobody operationalizes. Telling a reviewer to "check that access follows least privilege" without more context produces inconsistent, low-value reviews — the manager either rubber-stamps everything or second-guesses things they don't understand well enough to judge. A usable least-privilege check breaks into three concrete questions:

1. Is the access tied to a current, documented job function? Not "did this person once need this," but "does the role they hold today require it."

2. Is the level of access the minimum required for that function? Read-only versus write versus admin/delete — reviewers should be forced to pick the narrowest tier that still lets the person do their job.

3. Is there a legitimate, time-bound reason for any exception? Sometimes broader access is genuinely needed temporarily (an incident, a migration project); the review should catch whether that temporary grant has an expiration and whether it was actually removed when the reason ended.

"The single biggest thing I coach clients on is stop asking reviewers 'does this look okay.' Ask them 'would you personally sign your name to this being the minimum access this person needs to do their job today.' Framing it as a personal certification, not a vibe check, changes the quality of what comes back." — Priya Chandrasekaran, CPA, Audit Partner, Ashcroft & Vale LLP

I ask clients to give reviewers a one-page reference card at review time — role definitions mapped to expected access tiers — because a manager reviewing twelve direct reports' entitlements once a quarter simply won't remember what "Snowflake Analyst" role is supposed to include versus "Snowflake Admin." Memory is not a control. A reference artifact is.

Segregation of duties deserves its own callout inside least-privilege review: a person holding conflicting entitlements — say, the ability to both provision vendor payments and approve them — is a distinct risk category from simple over-provisioning, and reviewers need to be prompted to look for it explicitly rather than assume the access-tier question covers it.

How often: setting a defensible review cadence

"How often should we review access" is the question I get asked most, and the honest answer is: it depends on risk, but quarterly is the de facto standard that both satisfies most auditors and remains operationally sustainable. I've seen companies try semiannual reviews to save reviewer time and get hit with a qualified opinion because six months is long enough for a meaningful population of leavers and movers to accumulate unnoticed. I've also seen companies attempt monthly reviews for every system and burn out their managers so badly that review quality collapsed — people started clicking "approve all" just to get the email out of their inbox.

The right answer is tiered by risk, not one blanket cadence for everything you own.

DataVantage settled on quarterly reviews for anything touching customer data or infrastructure, and semiannual for low-risk internal tools — a defensible middle ground that Ashcroft & Vale accepted without pushback once Maria could explain the risk-tiering logic, not just the calendar.

One nuance worth flagging: your review cadence needs to be consistent enough, across the full audit period, that an auditor sampling any given quarter finds the same rigor. A Type II examination typically covers three to twelve months, so if your period is six months and your cadence is quarterly, the auditor expects to see two completed review cycles with evidence for both — not one thorough review and one rushed afterthought.

Who reviews: building a reviewer model that scales

The most common structural mistake I see is routing every access review through a central IT or security team. It feels efficient — one team, one process — but it fails the appropriateness test, because IT knows what access exists, not whether it's still needed for a given person's job. The people who can actually judge appropriateness are the ones closest to the work: direct managers, system/application owners, and — for the most sensitive tiers — a second layer of security or compliance oversight.

I use a three-tier reviewer model with almost every client:

• Line manager review — the person's direct manager confirms the person still needs access to a given system for their current role. This is the primary appropriateness check and should cover the majority of standard user access.

• System/application owner review — the person accountable for a specific system (e.g., the Snowflake data platform owner, the payroll system owner) reviews the full access list for that system, catching things a line manager might miss, like a person from a different team who was granted access for a project that ended.

• Security/GRC oversight review — a security or compliance function reviews privileged and administrative access specifically, and spot-checks the overall program for completeness — did every in-scope system actually get reviewed, did every reviewer actually respond.

A simple RACI clarifies who's Accountable versus who's Responsible, which matters enormously once an auditor asks "who approved this specific review" and you need a name, not a department.

"We used to route everything to IT because it was the path of least resistance. The audit exception that changed our minds was a contractor with standing access to a system his own manager didn't even know he still had — IT saw the account, not the context. Now the manager signs first, always." — Derek Osei, IT Manager, DataVantage Analytics

Defining the systems in scope for review

An access review is only as complete as its inventory. I ask every client to build — and keep current — a system-of-record list of everything that holds access to be reviewed, because "we reviewed access" means nothing if half the SaaS estate never made it onto the list. This inventory should live alongside, and ideally be generated from, the same asset inventory that supports your broader logical security program.

At minimum, your in-scope list should capture:

• Cloud infrastructure and IAM (AWS, Azure, GCP root/console access, IAM roles and policies)

• Production databases and data warehouses (direct SQL access, not just application-layer access)

• Source code repositories and CI/CD pipelines

• The identity provider itself (SSO/SSO admin console, directory services)

• Core business applications: CRM, ERP/finance, HR/payroll, ticketing/support platforms

• Customer-facing production application admin panels

• Physical access systems where they gate access to sensitive facilities (data centers, offices with server rooms)

• Third-party and vendor access to your systems (contractors, MSPs, integration partners)

A system falls out of scope only if it genuinely holds no sensitive data and no path to sensitive systems — and even then, I log the exclusion decision explicitly rather than let it fall through silently, because an auditor who finds an unreviewed system you didn't disclose will ask why it's missing from the population.

Privileged access: the higher bar

Privileged accounts — domain admins, cloud root users, database superusers, break-glass emergency accounts, and anyone with the ability to modify security controls or access broad swaths of data — deserve a materially higher bar than standard user access, and auditors treat them that way. A single compromised or inappropriate standard user account is bad; a single compromised privileged account can be catastrophic, which is why privileged access management exists as its own discipline.

For privileged access reviews specifically, I add checks that go beyond the standard least-privilege questions:

I recommend a dedicated privileged access review, run by security/GRC rather than delegated purely to line managers, on the same quarterly cadence as your Tier 1 systems, with results reported directly to whoever owns the risk register or steering committee. This is also where multi-factor authentication enforcement gets verified as a standing control, not just assumed.

"Auditors will ask for your privileged user list before they ask for almost anything else. If you can produce it in under five minutes, with MFA status and last-review date attached, you've already told them something important about how seriously you take this control." — James Whitfield, CISO, Larkspur Health Tech

Orphaned and terminated accounts: the auditor's favorite finding

If there's one exception type that shows up in more SOC 2 management letters than any other, it's the orphaned account — access that should have been revoked but wasn't, usually tied to someone who left the organization, changed roles, or was a contractor whose engagement ended. It's the finding auditors go looking for first, because it's the single clearest signal of a broken de-provisioning process, and it directly evidences a CC6.2 gap.

The reason it happens so consistently isn't laziness — it's process fragmentation. Termination is initiated in an HR system. IT off-boarding is a separate ticket, sometimes triggered manually by a manager who forgets, sometimes triggered automatically by an HR-to-IT integration that doesn't cover every system. Contractors often aren't in the HR system at all, so their termination has no automated trigger whatsoever — someone has to remember to tell IT the engagement ended.

A quarterly access review acts as the compensating control that catches whatever the real-time off-boarding process misses — but it should never be your only control for terminations. I push every client toward an automated HR-to-IT-to-identity-provider integration that disables access same-day, with the quarterly review functioning purely as a verification layer, not the primary de-provisioning mechanism. Waiting three months to discover a terminated employee still has VPN access is not a control failure an auditor will accept as "well, we caught it at review."

The review itself should always include an explicit reconciliation step: pull the full HR termination list for the period, cross-reference it against active accounts in every in-scope system, and document zero exceptions or document the exception and its remediation. This single reconciliation is, in my experience, the piece of evidence auditors ask for most specifically by name.

The step-by-step review workflow

A review that isn't structured as a repeatable workflow degrades every cycle — someone forgets a system, a reviewer doesn't respond, and by the third quarter nobody remembers what "done" looked like the first time. I walk clients through a seven-step workflow that's deliberately boring, because boring is repeatable.

1. Scope confirmation. Confirm the current in-scope system list is accurate before pulling any data — new systems added since the last cycle need to be added to the review population.

2. Population pull. Export the current user/access list for every in-scope system, including role, access level/tier, last login date, and account status.

3. Reviewer assignment. Route each population to the correct reviewer (line manager, system owner, security/GRC for privileged) with a defined due date.

4. Reviewer decision. For each entry, the reviewer marks: retain as-is, modify (specify the change), or remove. This decision must be recorded, not verbal.

5. Remediation execution. IT operations executes every "modify" or "remove" decision, and records completion — including the date the change was actually made, not just requested.

6. Verification/closure. Security/GRC confirms every remediation item was actually completed, closes the cycle, and reconciles against the HR termination list.

7. Evidence archival. All review artifacts — population exports, reviewer sign-offs, remediation tickets, closure confirmation — are archived in a consistent, retrievable format tied to the review period.

I recommend giving reviewers no more than ten business days to respond, with an automated reminder at day five and an escalation to their manager's manager at day nine if the review is still outstanding. Non-response is itself a finding waiting to happen — an auditor sampling a review cycle where three reviewers never responded, and nobody escalated, will read that as a control that exists on paper but doesn't operate.

Manual spreadsheets versus automated identity governance tools

Every organization starts access reviews with spreadsheets, and there's nothing wrong with that at a smaller scale — DataVantage ran its first two cycles on shared spreadsheets with locked columns and a defined naming convention, and it worked, if painfully. The question is when the manual approach stops scaling, and the honest threshold I use with clients is somewhere around 150–200 employees across more than a handful of systems, or sooner if turnover is high.

Purpose-built identity governance and administration (IGA) tools — and increasingly, access-review modules bolted onto broader GRC platforms — automate the population pull, route reviews to the correct owner based on org-chart data, chase non-responders automatically, and produce a clean, timestamped audit trail without anyone manually screenshotting an inbox. Fenwick Cloud Solutions, a 340-person infrastructure-monitoring vendor, moved from spreadsheets to an automated platform between their first and second SOC 2 Type II cycles and cut review-cycle labor from roughly 120 person-hours per quarter to about 18, almost entirely by eliminating manual chasing and manual evidence collection.

"The spreadsheet era wasn't the problem — the problem was that every quarter, someone had to remember the entire process from scratch. Automating it didn't just save time, it made the fourth cycle as rigorous as the first, which is the thing auditors actually care about." — Sana Okafor, GRC Lead, Fenwick Cloud Solutions

Whichever approach you use, the underlying discipline — clear scope, clear ownership, recorded decisions, closed-loop remediation — matters more than the tooling. A poorly configured automated tool that nobody understands produces worse evidence than a disciplined spreadsheet process.

Writing the access review policy: what auditors expect on paper

Every piece of evidence we've discussed so far proves the control operated. Auditors separately want a written policy or procedure proving the control was designed deliberately — a document they can read during planning, before fieldwork even starts, that tells them what to expect when they later sample your evidence. Organizations that skip this step often run a perfectly good review process informally, then struggle when an auditor asks for "the policy" and gets a shrug instead of a document.

A usable access review policy doesn't need to be long — I've seen effective versions run two to three pages — but it needs to answer a specific set of questions unambiguously, so that a new hire in your security team could pick it up and run the next cycle correctly without institutional memory.

The policy and the practice need to match exactly — this is one of the more common, and entirely self-inflicted, exception types I see. A policy that promises monthly reviews of privileged access, written two years ago by someone who's since left, while the actual program runs quarterly, is worse than having no written policy at all, because it hands the auditor a documented control failure rather than an undocumented-but-functioning one. I recommend reviewing the policy itself at least annually — ideally as part of the Q4 program retrospective described earlier — specifically checking that every cadence, role, and SLA it describes still matches reality.

Remediation: closing the loop on findings

A review that surfaces findings but never closes them is arguably worse than no review at all, because it creates a paper trail proving you knew about a problem and didn't fix it. Remediation needs its own defined SLA, tracked separately from the review itself, with severity-based urgency.

Every remediation item needs a ticket — in whatever system you already use for IT work, this doesn't need a dedicated tool — with a clear before/after state, the date the change was requested, and the date it was actually completed. That gap between "requested" and "completed" is exactly what an auditor will test when they sample a finding: did the fix actually happen, and did it happen inside the SLA you claim to follow.

I also push clients to run a lightweight root cause analysis on any finding that recurs across cycles. A single orphaned contractor account is a one-off; three consecutive quarters of orphaned contractor accounts is a broken process (probably: contractors aren't being tracked in the same off-boarding trigger as employees), and the fix belongs at the process level, not the individual-ticket level.

Evidence: what auditors actually want to see

This is the section I'd bookmark if I were you. Access review evidence gets sampled in nearly every SOC 2 Type II engagement, and the difference between a smooth walkthrough and a stressful one comes down almost entirely to whether your audit evidence is organized before the auditor asks, not assembled in a panic after.

The most common evidence mistake is treating the review as an event rather than a record. An email thread where a manager replies "looks fine" is weak evidence — it doesn't show the population reviewed, doesn't show a per-entry decision, and disappears into an inbox nobody archives systematically. A structured artifact — even a well-organized spreadsheet with locked review columns and timestamps — beats a clean-looking but unstructured email chain every time an auditor tests it.

I recommend a consistent evidence folder structure per review cycle: one folder per quarter, with subfolders for population exports, reviewer sign-offs, exception logs, and remediation tickets, named consistently enough that an auditor (or a new hire on your team) could navigate it without a guided tour. This maps directly to how control testing works during fieldwork — auditors request a PBC list item, and the faster and more completely you can produce it, the less follow-up scrutiny the item attracts.

How auditors sample and test your access review control

Understanding the mechanics of how your auditor actually tests this control changes how you build the program, so it's worth walking through what happens on the other side of the table. For a Type II examination, the auditor is testing operating effectiveness over the full audit period — which, for a control that runs quarterly, typically means a population of two to four review cycles, depending on the length of your observation window.

The auditor will generally:

1. Request the full population of review cycles conducted during the period — every system, every cycle, no cherry-picking which cycles to disclose.

2. Select a sample — often not every cycle, and rarely every system within a cycle, using an audit sampling approach appropriate to the size of the population.

3. For each sampled item, request the underlying evidence: the population export, the reviewer's actual decision, and (critically) proof of remediation for anything flagged.

4. Often perform a re-performance test — independently checking, for a sampled user, whether their actual current access matches what the review said should exist.

5. Cross-reference your review population against the HR termination list independently, specifically hunting for anyone terminated during the period who still shows up with active access after the point they should have been removed.

A test of one generally isn't sufficient for a control designed to run quarterly across a multi-month period — the auditor expects to see the control operate consistently across the whole window, which is precisely why a single well-documented cycle followed by three sloppy ones is a worse outcome than four moderately good cycles. Consistency beats a single standout performance every time in a Type II report.

Common exceptions and the patterns behind them

I've now sat through enough SOC 2 fieldwork debriefs to recognize the same handful of access review exceptions recurring across almost every organization, regardless of industry. Recognizing the pattern in advance lets you pressure-test your own program before the auditor does it for you.

Two of these deserve extra emphasis because they're deceptively easy to miss. First, rubber-stamping is invisible from the outside — the review "happened," a name is attached, but the actual judgment never occurred. Auditors catch this through re-performance testing: if they independently check a sampled user's access and find something a diligent reviewer clearly should have flagged, the sign-off itself becomes suspect. Second, missing systems are a scope problem, not an execution problem — no amount of rigor applied to the systems you did review compensates for a system that was never in the population to begin with.

Access reviews and ISO 27001: a complementary discipline

Many organizations pursuing SOC 2 are also working toward, or already hold, ISO 27001 certification, and access reviews are one of the cleanest points of overlap between the two frameworks — which matters enormously if you're trying to avoid building two parallel evidence trails for what is, functionally, the same control. ISO/IEC 27001:2022 Annex A control 5.18 (Access rights) explicitly requires that access rights be provisioned, reviewed, and adjusted or removed following any change in role or employment status, and control 8.2 (Privileged access rights) requires the allocation and use of privileged access to be restricted, formally managed, and reviewed on a defined basis — language that maps almost directly onto what CC6.3 expects from a SOC 2 access review, even though the two standards test it differently.

The main structural difference is in how each framework verifies the control. ISO 27001 treats access rights review as a certifiable requirement checked by an internal auditor and then a certification body auditor against your documented Statement of Applicability and internal audit records. SOC 2 tests the same underlying activity empirically, cycle by cycle, through sampling and re-performance during fieldwork. In practice, that means the same underlying evidence — population exports, reviewer sign-offs, exception logs, remediation tickets — can satisfy both, provided the review's frequency, scope, and documentation are consistent enough to survive an ISO 27001 surveillance audit and a SOC 2 Type II sample in the same year.

If your organization is running ISO 27001 and SOC 2 together, I'd treat the access review program as one of the first controls you consolidate rather than duplicate — maintaining two separate review cadences, two separate reviewer models, and two separate evidence folders for the same underlying activity is one of the most common (and most avoidable) sources of audit fatigue I see in dual-framework organizations. Teams mapping the overlap in more depth sometimes reference a full ISO 27001, SOC 2, and NIST CSF crosswalk to keep control language and evidence definitions aligned across all three frameworks rather than drifting into inconsistent wording that confuses reviewers and auditors alike.

Metrics and KPIs that prove your program is maturing

A single clean audit cycle tells an auditor your control worked once. A trend line of metrics, tracked cycle over cycle, tells your leadership team — and, indirectly, your auditor — that the program is actually maturing rather than just repeating the same effort with the same results. I encourage every client to track a small set of metrics on a standing dashboard, reviewed at least quarterly alongside the review cycle itself.

Presenting this dashboard to an audit committee or leadership team does double duty: it keeps the program visible and funded internally, and it gives your auditor a second, independent data source — beyond the individual cycle artifacts — that corroborates the control is operating consistently rather than being reconstructed just before fieldwork.

Case study: DataVantage Analytics rebuilds its program mid-audit

Returning to Maria's story: after the initial gap was flagged, DataVantage had eight weeks to build a credible program, retroactively document what evidence could be reconstructed for the earlier part of the observation period, and demonstrate at least one full, rigorous cycle going forward before the report could be finalized.

The team's approach:

• Week 1–2: Built the risk-tiered system inventory (11 in-scope systems identified, two previously untracked SaaS tools added), defined the three-tier reviewer model, and created role-to-access reference cards for the eight most common job functions.

• Week 3: Ran a full population pull across all 11 systems (approximately 380 total access grants across 220 employees and 14 active contractors), and discovered the orphaned contractor with production database access during the population pull itself — before any reviewer even saw it, because the population export was cross-referenced against the contractor register as a first-pass sanity check.

• Week 4–5: Routed reviews to 19 line managers and 6 system owners with a seven-business-day deadline and automated reminders; achieved 100% reviewer response by day nine after one escalation.

• Week 6: Remediated 34 findings — 21 medium-severity over-provisioning cases, 9 stale access grants tied to prior role changes, 3 accounts needing MFA enforcement, and the 1 critical orphaned contractor account, closed within 36 hours of discovery.

• Week 7–8: Documented the full cycle as formal evidence, reconciled against the HR termination list (zero additional exceptions found), and ran a second, lighter-weight cycle to demonstrate the process repeating.

The second cycle, run six weeks after the first, surfaced only 2 findings — both minor role-mapping issues remediated within 48 hours. Ashcroft & Vale accepted the two-cycle evidence, noted the initial-period gap as a corrected deficiency rather than a current material weakness, and DataVantage received its report in time for the retailer's audit committee meeting, preserving the $2.4 million renewal.

"What saved us wasn't perfection — it was showing a control that clearly worked the second time because we'd fixed the actual process, not just produced better paperwork. The auditor could see the exception count drop from 34 to 2 and that told its own story." — Maria Delgado, Director of Security and Compliance, DataVantage Analytics

Case study: a missed privileged account at Northbridge Payments

Northbridge Payments, a payment-orchestration platform serving mid-market e-commerce merchants, had a mature quarterly access review program running for over a year when its dedicated privileged access review — introduced specifically because a prior audit had flagged the absence of one — caught something the standard-user review cycle had missed for two consecutive quarters: a departed infrastructure contractor whose personal AWS IAM user, created outside the standard onboarding process for an urgent migration project eight months earlier, still held broad EC2 and RDS permissions.

The account had never appeared in the standard-user population pull because it was tied to a project-specific IAM user rather than the company's SSO-federated access, meaning it fell outside the normal review's data source entirely. It surfaced only because the newly introduced privileged access review specifically cross-referenced all IAM users against the company's active personnel and contractor registers, not just SSO-linked identities.

• Time between contractor's engagement end and account creation being flagged: approximately 8 months.

• Remediation: account disabled within 4 hours of discovery, followed by a full IAM audit that identified two additional non-SSO-linked service accounts requiring cleanup.

• Process fix: all future project-specific IAM users required to be provisioned through the standard identity provider federation, eliminating the blind spot going forward.

"The lesson wasn't that our review process failed — it's that our review process was only ever looking at the front door. This account came in through a side door we didn't know we had. Every organization has at least one side door; the privileged review's job is to go find it." — Tom Reilly, VP Engineering, Northbridge Payments

This is precisely why I recommend privileged access reviews be scoped explicitly to include all forms of elevated access — including non-SSO-federated accounts, service accounts, and cloud-native IAM users — rather than inheriting the scope of the standard user review by default.

Building a sustainable annual review calendar

Access reviews fail long-term not because the process is hard, but because it's easy to let slip when nobody owns the calendar. I recommend building a fixed annual calendar, published at the start of the fiscal year, so review cycles aren't negotiated fresh each quarter around whoever's busy.

Building the retrospective into Q4 matters more than it sounds — this is where you review the exception patterns from the whole year, decide whether cadence or scope needs to change, and update the role-to-access reference cards before the new year's first cycle. Programs that skip this step tend to fossilize, applying a reference card that's two years out of date to a role that's since changed significantly.

I also recommend tying your review calendar explicitly to your broader internal audit program cadence, so the two functions aren't independently discovering the same gaps months apart. If internal audit already spot-checks access review evidence in Q3, that's a second layer of assurance before your external SOC 2 fieldwork even begins.

Common pitfalls that undermine an otherwise solid program

Even organizations with a well-designed process on paper trip over a handful of recurring operational pitfalls. Worth a deliberate gut-check against each one before your next cycle.

Access reviews as a business advantage, not just an audit checkbox

It's tempting to treat access reviews as pure audit overhead — a quarterly tax you pay to keep the SOC 2 report clean. I'd push back on that framing, because in my experience the organizations that get the most value from this control are the ones that stop thinking of it as compliance theater and start thinking of it as operational hygiene that happens to also satisfy an auditor.

A disciplined access review program catches privileged access management gaps before they become breach headlines, not just before they become audit findings. It shrinks your attack surface continuously rather than in periodic bursts, because the discipline of asking "does this access still make sense" quarter after quarter naturally prunes the accumulated cruft every growing organization generates. And it becomes a genuine sales asset — when a prospect's security team asks how you manage access to systems holding their data, "here's our quarterly review process, here's our privileged access controls, here's our SOC 2 report demonstrating it operates" is a materially stronger answer than a policy document nobody's tested against reality.

The organizations I've watched turn this control into a competitive advantage share one habit: they treat the review findings, in aggregate, as a management metric worth tracking over time — exception counts trending down, remediation SLAs trending faster, reviewer response rates trending toward 100%. That trend line, more than any single clean cycle, is what tells both your leadership team and your auditor that the control is maturing, not just surviving.

If your organization is building or rebuilding this program, start with the risk-tiered system inventory and the three-tier reviewer model — those two artifacts alone resolve most of the structural gaps I see. Our SOC 2 Control Matrix and RACI Template gives you a starting framework for exactly that reviewer mapping, and our SOC 2 Readiness Checklist will help you confirm access reviews sit correctly alongside every other CC6-series control before your next audit window opens. For teams still deciding how to scope the full program, PentesterWorld's SOC 2 Gap Analysis Tool can benchmark your current access review maturity against what a Type II examination will actually test — a far cheaper way to find your gaps than Maria's eight-week scramble was.

PentesterWorld can help you build this before your auditor finds the gap

Whether you're standing up your first access review cycle or hardening a program that's survived a few audits with scars, PentesterWorld's compliance and security engineering team has helped organizations across SaaS, fintech, and healthcare technology design access review programs that hold up under sampling — not just look good in a policy binder. If you'd rather not learn your program's weaknesses the way Maria did, reach out to PentesterWorld to talk through where your current access controls, review cadence, and evidence practices stand against what CC6.1 through CC6.3 actually require.