Access Reviews: Cadence, Scope, and the Paper Trail

Access reviews fail in predictable ways. The failure rarely happens when the auditor sits down across from you. It was already baked in, sometimes months earlier, when someone picked a review cadence that looked responsible on paper but was completely disconnected from the team's actual capacity to execute it. Or when attestation got routed to the CISO because no one wanted to bother the business managers. Or when service accounts got quietly left out of scope because they felt like a different category of problem.

By the time the evidence request lands in your inbox, the gaps are structural. The audit is just the moment you find out.

Cadence: The Honest Version

The first instinct, especially for teams trying to demonstrate rigor, is to commit to the most aggressive frequency they can imagine. Monthly sounds more serious than quarterly. Quarterly sounds better than semi-annual. What nobody says out loud is that a semi-annual review you actually complete is worth more than a monthly review that happened twice.

Cadence selection is one of the most consequential early decisions in building a review program, and teams consistently underweight it. I've watched organizations spend significant energy defending a monthly commitment to auditors while quietly acknowledging internally that two-thirds of those cycles were nominal at best: no meaningful remediation, attestation collected weeks late, no documentation anyone would want scrutinized.

For most organizations pursuing SOC 2 Type II, semi-annual reviews of standard employee access are common and generally sufficient. Privileged access, administrative accounts, root credentials, production environment access, warrants something shorter. Quarterly is where most practitioners land. That tiered approach is defensible because it's proportionate to risk, and it's practical because it concentrates the heavier lift on the smaller, higher-stakes population.

ISO 27001 doesn't prescribe a specific interval. It expects "periodic" reviews and leaves interpretation open, which means your auditors will fill that gap with their own opinions. Ask them directly before you finalize your calendar. That conversation is worth having early; it's far less pleasant after you've run two cycles at a cadence they consider insufficient.

One diagnostic worth running right now: look at the past twelve months and count how many scheduled review cycles actually completed. Documented. Attestation collected. Remediation closed. If that number is lower than your committed cadence, you have one of two problems, a broken process or an unrealistic schedule, and they require different fixes. Conflating them makes both worse.

But what if the number looks fine on paper? Cycles completed, boxes checked. That raises a harder question: are you measuring completion, or quality?

Attestation Belongs to the People Who Actually Know the System

Attestation is a formal assertion. A named person is saying they reviewed this access and found it appropriate. That claim only means something if the person making it actually understands what "appropriate" means in that system: who the users are, what the roles permit, who legitimately needs what.

Routing a spreadsheet of 200 Salesforce users to the CISO is not attestation. It's performance of attestation. The CISO almost certainly cannot evaluate whether a sales development rep still needs a specific reporting permission in a compensation tool. They can confirm accounts exist. That's a different thing entirely.

Why does this happen so often, if the limitation is this obvious? Usually because it's operationally convenient, and convenience has a way of winning when no one has articulated the cost clearly. The business managers have other priorities. Security owns the audit relationship. So the spreadsheet goes to security, security signs off, and everyone moves on.

The right attester is almost always the system owner or the business function manager whose team lives in that application. For a CRM, that's a sales or revenue operations leader. For cloud infrastructure, it's an engineering or DevOps manager. For a financial reporting tool, it's a finance leader, probably with input from the controller. HR plays a supporting role, useful for confirming employment status and departmental placement, but not as a primary attester on system access decisions.

The mistake I see repeatedly is centralizing all attestation to IT or security because it solves the coordination problem while creating a different one: the people signing off lack the context to make meaningful judgments, and a rigorous auditor will eventually notice. On FedRAMP or higher-control assessments, auditors will sample individual accounts and ask whether the attester plausibly knows why that person has that access level. A security engineer confirming a finance analyst's permissions in a compensation system does not survive that question well.

For larger environments, role-based attestation changes the dynamic usefully. Instead of asking a manager to work through individual accounts, you ask them to confirm that a role definition is still accurate, and then the system identifies who holds that role. It scales, produces cleaner evidence, and concentrates the attester's judgment on the part of the question they can actually answer. It also requires your identity infrastructure to support it, which isn't always a safe assumption.

What "Complete" Actually Means

Most review programs are underbuilt, not because teams are careless, but because they scoped the review around the obvious population and stopped. Active employee accounts are the obvious starting point. They are not the whole picture.

The Populations That Get Missed

Employees on extended leave create an ambiguity that surfaces in audits and rarely gets resolved before one. Does someone on parental leave retain full system access during absence? Most organizations don't have an explicit policy on this. They have a default, which is usually "yes, we never touched it," and that default is not the same as a policy decision.

Contractors and consultants are where I've seen some of the messiest gaps. Their access often bypassed the standard provisioning process, added informally during a project ramp, and it frequently outlasts their engagement because offboarding is typically triggered by HR actions, and contractors often aren't in the HRIS. The access persists. No one removes it because the process that would remove it never knew they existed.

Third-party vendor access falls between organizational seams. Vendors granted access for support, integrations running on named accounts tied to a vendor's identity, external parties with read access to data stores or monitoring systems: these span procurement, IT, and security ownership without cleanly belonging to any of them. That diffuse ownership is precisely the reason they get left out of review scope, and it is precisely the reason they're worth paying particular attention to.

Service Accounts and Non-Human Identities

Service accounts are consistently the weakest element in access review programs. The typical story goes like this: an engineer creates a service account for a specific integration, it gets attributed to that engineer in the system, the engineer leaves, ownership becomes ambiguous, and then the account gets excluded from review cycles because someone decided it's "not a human account" and therefore out of scope.

Auditors are increasingly focused on non-human identities, especially in cloud-native environments where service accounts, API keys, and OAuth grants proliferate faster than any manual tracking process can manage. Excluding them from scope is no longer a defensible position in most audit contexts.

Four questions that should apply to every service account in your environment: Does this account still serve an active purpose? Who owns it now? Does its permission scope match the minimum required for its function? When were its credentials last rotated? If you can't answer those for every service account, you have a gap worth closing before someone else surfaces it.

OAuth authorizations between SaaS platforms are the category most programs haven't reached yet. An employee grants a third-party application access to their Google Workspace environment. That authorization persists. No one reviews whether it's still necessary. Some audit frameworks are beginning to surface questions about this. It is worth considering what your current posture looks like before an auditor raises it first.

Permission Creep Lives in Role Changes

Reviewing whether an account exists is only part of the job. The review should also assess whether the access level is still appropriate. This is where permission creep accumulates quietly: the employee who transferred from finance to marketing two years ago and still has read access to financial systems because no one triggered a role change review at the time of the transfer.

Promotions, lateral moves, and role changes are the most common source of excess privilege. The structural fix is a provisioning process that handles these rigorously at the point they occur, tied to joiner-mover-leaver workflows. Periodic reviews catch drift. They don't substitute for getting provisioning right at the moment of transition.

Remediation: Define the Timeline Before You Need It

Identifying excess access is only useful if it's removed within a timeframe that was documented before the review started. This is a detail that trips up a lot of programs. The remediation timeline needs to be a policy decision, written down in advance, not something you reconstruct after the findings are logged.

Common practice differs by access type. For privileged accounts flagged during review, 24 to 72 hours is where most practitioners land. For standard user access, one to two weeks is frequently cited, though some auditors expect faster action on anything touching sensitive data. The specific numbers matter less than the consistency: the same standards applied across every cycle, with a written policy to reference.

When an auditor examines your remediation evidence, they will compare the date an account was flagged to the date access was removed. If those intervals are inconsistent, or if there's no policy to explain them, the evidence loses credibility. It stops looking like governance and starts looking like cleanup.

Document exceptions explicitly. If a business justification delays remediation past the standard window, that exception should capture who approved it, why, and what compensating controls applied during the extension. An undocumented extension looks like a missed deadline. A documented exception looks like a governance process that handles edge cases, which is a meaningfully different impression.

The Documentation Set Auditors Actually Examine

"We reviewed access" is not evidence. Evidence is a document with a date.

For each review cycle, the documentation set typically needs to include: a scope definition identifying which systems were reviewed and why; the user access list or report that was reviewed, with an extraction timestamp; the attestation record showing who reviewed each system and when; a findings log identifying what was flagged; and remediation confirmation showing what was done and when. Many audit teams will also ask for the policy or procedure document that defines the review program itself, including cadence, scope criteria, attester assignment, and remediation timelines. Without that document, the cycle-level evidence is harder to contextualize.

The attestation record deserves specific attention. An email thread where a manager writes "looks fine" is technically evidence. It's also fragile evidence. A structured attestation, a spreadsheet with a confirmed column and a date, a GRC workflow, a dated PDF with explicit confirmation, is more legible and more durable. The format matters less than what it makes clear: who reviewed, what they reviewed, when, and what they concluded.

Audit firms vary in how deeply they examine attestation quality versus simply confirming its existence. The more rigorous ones, particularly in FedRAMP or high-control environments, will sample individual accounts and probe whether the attester plausibly has meaningful knowledge of each one. That level of scrutiny is the reason attester assignment matters at the design stage, not just at the evidence collection stage.

What Makes a Program Defensible Over Time

Frequency matters. Documentation matters. Consistency matters most. A review program that runs on the same schedule, follows the same defined process, and produces the same categories of evidence across cycles is far more credible than one that looks different every time.

Auditors are pattern-matchers. A well-worn, repeatable process reads as operational discipline. A process that appears to have been assembled around the evidence request reads as something else.

As your systems environment grows, your in-scope system list needs to grow with it. If a new production data store went live six months ago and isn't included in the current review cycle, a thorough auditor will find that by cross-referencing your system inventory against your review scope. Tying access review scope explicitly to a maintained system inventory is one of the more reliable structural defenses against that finding.

The honest thing to say about access reviews is that they're operationally demanding. Done well, they require real engagement from business managers who have other priorities. The pressure to make the process lighter, to reduce what it asks of attesters, to leave service accounts out of scope, to formalize a cadence without building the infrastructure to sustain it, is real and constant. Each of those shortcuts has a cost. It just surfaces at a moment when you would very much prefer it hadn't.