How to Run a Quarterly Privileged Account Access Review That Is Not Rubber-Stamp Theater

Access reviews that try to cover all accounts in the organization produce the rubber-stamp outcome because the volume overwhelms reviewer attention. Access reviews scoped to privileged accounts only -- with a consistent definition of "privileged" -- produce manageable volume and meaningful decisions.

Define privileged account categories for your environment:

Tier 0: Highest-privilege accounts. Domain administrators, global administrators (Microsoft 365, AWS root, Google Workspace Super Admin), and emergency access accounts. These warrant review at every cycle and individual justification for every account.

Tier 1: Elevated administrative accounts. Local administrators on servers, service accounts with write access to production systems, accounts with access to encryption keys or certificate stores, accounts with access to identity provider administrative functions (Okta admin, Entra ID privileged roles below Global Admin). These warrant review quarterly.

Tier 2: Sensitive but non-administrative accounts. Service accounts with read access to production databases containing regulated data, third-party vendor accounts with access beyond public-facing systems, privileged access workstation accounts. These warrant review semi-annually.

Define this categorization explicitly in your access management policy. Without explicit scoping, the review either covers too much (every account, which produces rubber-stamping) or too little (only the accounts the IAM team already knows about, which misses discovered accounts).

Identify all accounts in each tier by querying your identity provider for role membership: in Entra ID, query members of Global Administrator, Privileged Role Administrator, Exchange Administrator, and custom high-privilege roles. In AWS, query for accounts with AdministratorAccess or accounts whose attached policies include "Action": "*", "Resource": "*". In Okta, query for Super Admin and Org Admin role assignments. In Active Directory, query Domain Admins, Schema Admins, Enterprise Admins, and custom tier-0 groups.

Each account record sent to a reviewer for the access review should include four pre-built data points, collected from your IAM systems and authentication logs before the review package is assembled:

1. Last authentication date. When did this account last successfully authenticate? Pull from your identity provider's authentication logs: Entra ID sign-in logs, Okta system log, AWS CloudTrail (for IAM users and assumed roles), or Active Directory domain controller authentication events. Express as "last authenticated N days ago" rather than a raw timestamp -- reviewers process "last authenticated 287 days ago" faster than "last authenticated 2024-09-14."

2. Permission scope summary. What elevated permissions does this account carry? Not a raw dump of every policy attachment -- a human-readable summary. For an Entra ID account: "Global Administrator, Exchange Administrator." For an AWS IAM user: "AdministratorAccess policy (all services, all resources)." For an Active Directory account: "Member of Domain Admins, WSUS Administrators." This allows a reviewer to assess whether the permission scope is appropriate without reviewing raw policy JSON.

3. Original provisioning justification. Why was this account created with these privileges? Pull from your IAM ticketing system, the original provisioning request, or the access management policy record. "Provisioned for Active Directory migration project, Q2 2022. Project status: completed Q4 2022." A reviewer seeing this does not need to investigate why the account exists -- they can make an immediate decision based on the current state versus the original justification.

4. Account owner. Who is the named owner of this account today? For human accounts: the account holder's current manager. For service accounts: the team responsible for the application or service the account serves. An account with no identifiable current owner should automatically be flagged for escalation regardless of authentication activity.

Reviewers given subjective judgment ("is this access appropriate?") produce highly variable outcomes across different reviewers and different periods. Reviewers given objective criteria produce consistent decisions.

A privileged account passes the review if and only if it meets all three criteria:

Criterion 1: Active use. The account has authenticated within the last 90 days. A privileged account with no authentication in 90 days has no demonstrated current business need. Exceptions: accounts that are legitimately used less frequently than quarterly (annual review accounts, break-glass emergency access accounts) should be explicitly tagged as low-frequency accounts with a documented rationale, and reviewed against their expected use pattern rather than the 90-day threshold.

Criterion 2: Justified current scope. The permission scope is documented in a current business requirement that the reviewer can confirm is still active. "This account is the Domain Admin for the Active Directory infrastructure" is a justified current scope for an IT infrastructure team member. "This account has Domain Admin because they needed it for the 2022 migration project" is a historical justification that does not support current elevated access.

Criterion 3: Named current owner. A specific person (or team, for service accounts) who can be contacted, who acknowledges responsibility for the account, and who has the authority to authorize or revoke the access. An account whose owner has left the company, transferred to a different team, or cannot be identified fails this criterion.

The review decision tree: if all three criteria are met, approve. If any criterion is not met, the reviewer should initiate the escalation path rather than approving with reservations.

The escalation path is what transforms the access review from a documentation exercise into a risk reduction exercise. An account that fails one or more justification criteria should not be approved with a note -- it should be escalated for resolution within a defined timeframe.

Escalation tier 1: The reviewer escalates to the IAM team (within 5 business days of the review start). The reviewer marks the account as "cannot justify" in the review platform and provides the specific criterion that was not met. The IAM team contacts the account owner (or attempts to identify the owner) and requests a justification document or schedules account removal. For accounts that fail Criterion 1 (no recent authentication): the IAM team disables the account (not deletes -- disabling preserves audit logs) and sets a 30-day monitoring window. If no one complains about loss of access in 30 days, the account is deleted.

Escalation tier 2: The CISO escalates to the account holder's department leadership (within 15 business days of the review start). If the IAM team cannot reach the account owner, or if the account owner disagrees with the revocation and escalates, the CISO presents the account's current state (no authentication in N days, original justification no longer applicable) to the relevant business leader with a clear binary choice: provide a current business justification or authorize revocation. This removes ambiguity and documents the decision at an appropriate authority level.

Emergency revocation (immediate, no waiting period). Any account where the owner's employment has ended, where the account appears in an external threat intelligence report, or where the account is associated with an active security investigation should be disabled immediately rather than waiting for the standard escalation process.

Manual access review process management (spreadsheets, email campaigns, manual log queries) makes thorough reviews operationally difficult for the IAM team and time-consuming for reviewers. Identity Governance and Administration (IGA) tools automate the administrative work while preserving decision quality.

What IGA platforms automate: reviewer notification and follow-up, pre-building the four data points per account (last authentication, permission scope, justification, owner), capturing reviewer decisions with timestamps, generating audit reports of review completion, and routing non-approved accounts to the escalation queue.

IGA tools commonly used for privileged access reviews: SailPoint IdentityNow and SailPoint IIQ (enterprise, large environments), Saviynt (enterprise, strong cloud integration), Microsoft Entra ID Governance (native for Microsoft environments, includes access reviews with last sign-in data), Okta Identity Governance (native for Okta environments), Ping Identity, and smaller tools like Lumos, ISIM, or Bravura Security for mid-market environments.

Minimum viable without an IGA platform: If you are running access reviews without IGA tooling, the minimum viable process uses: a structured spreadsheet template with pre-populated columns for last authentication (pulled from identity provider export), permission scope (pulled from role membership export), justification (from provisioning ticket system), and owner. The spreadsheet is distributed to reviewers with a documented decision threshold (the three criteria) and a firm deadline. Follow-up is manual but structured -- daily reminders to incomplete reviewers with manager escalation on day 5.

The key constraint without IGA: the IAM team bears the administrative burden of pre-building the data and chasing reviewers. For an environment with 200+ privileged accounts, this becomes a full-time task each quarter. That operational burden is the business case for IGA tooling investment.

Report the following metrics after each access review cycle. These metrics distinguish a review that produced real decisions from one that produced documentation of non-decisions.

Accounts reviewed versus accounts changed. What percentage of accounts reviewed resulted in removal or scope reduction? A review where 100% of accounts are approved unchanged is either a perfectly clean environment (unlikely) or a rubber-stamp review (likely). Target: at least 5 to 15% of accounts should result in modification (removal or scope reduction) in a healthy access review cycle. First-cycle reviews often produce 20 to 30% modification rates as historical accumulation is surfaced.

Review completion rate. What percentage of assigned reviewers completed the review by the deadline? Low completion rates indicate either too many accounts per reviewer (volume overwhelm) or insufficient reviewer engagement (reviewers do not understand why the review matters). Track and trend over time.

Time-to-resolution for escalated accounts. How long did accounts that failed the justification criteria take to reach resolution (approval with new justification or revocation)? Escalated accounts that remain unresolved after 30 days indicate the escalation process is not functioning. Track the number of escalated accounts and their average resolution time.

Privileged account count trend. Total privileged accounts at the end of each review cycle. If privileged account count is growing quarter over quarter despite access reviews, the provisioning process is adding accounts faster than the review process is removing them -- a sign that least-privilege provisioning practices need attention, not just the review process.