User Access Reviews That Work: Beyond the Rubber-Stamp Recertification

The structural problems with most access review implementations are predictable and fixable. The first is volume: asking a manager to review 200 accounts with no filtering is asking them to do work that would take three hours if done properly, in the 20 minutes they have between meetings. They will not do it properly. They will approve everything, because approving is fast and revoking requires a judgment call they do not have enough information to make. The second problem is context absence. A manager sees an account name and an access right. They do not see that this account last logged in 400 days ago, that the user has changed roles since this access was granted, or that no one with a similar role has this access. Without that context, the only rational decision is to approve and avoid disrupting a business workflow they cannot fully evaluate. The third problem is consequence asymmetry. If a manager incorrectly approves access that should be revoked, nothing bad happens immediately, and the manager will likely never know a bad outcome resulted from their approval. If a manager incorrectly revokes access that is needed, they get an escalation call within 24 hours. Rational managers weight the costs of the two types of errors correctly given the feedback they receive, and they always choose to approve. Fixing access reviews requires addressing all three structural problems: reduce volume through intelligent filtering, add context that makes decisions tractable, and reduce the consequence of correct revocation decisions.

When a reviewer sees an account in a review campaign, they need to answer one question: does this person still need this access to do their job? Answering that question requires information that most access review systems do not provide by default. Last login date for this specific access right, not just the account overall, tells the reviewer whether the access has been used recently. Access granted date tells the reviewer whether this was a historical grant that predates the current role. The user's current job title and department, compared to the job title at the time access was granted, tells the reviewer if the access is a role artifact from a previous position. Access usage data, specifically whether the permission or system access has been exercised in the last 90 days, is the most decision-relevant signal available: unused access is almost always removable. Peer comparison tells the reviewer whether anyone else in the same role has this access. If 50 people in the same role do not have access to a given system, the one person who does has an anomaly that requires a real justification. IGA platforms like SailPoint IdentityNow, Saviynt, and Omada can surface all of this context at the review task level. The implementation requirement is that these platforms be connected to the access usage data sources (application authentication logs, database audit logs, API gateway logs) not just the provisioning data. Provisioning data tells you what access exists. Usage data tells you whether it matters.

Not all accounts warrant the same review cadence. A standard analyst account with read access to a reporting database can reasonably be reviewed annually. A Domain Admin account should be reviewed quarterly, and dormant accounts should be reviewed immediately upon detection. Stratifying review frequency by risk level reduces the volume that goes through human review while increasing the scrutiny applied to the accounts that actually matter. Privileged accounts, specifically accounts with administrative rights to critical systems, should be reviewed quarterly at minimum. This includes local administrator accounts, service accounts with Domain Admin membership, accounts in custom privileged groups, and accounts with administrative access to cloud infrastructure. Standard user accounts, accounts with normal user-level access to internal systems, can follow an annual review cycle. The annual review is most useful for identifying role-change artifacts: users who moved to different departments but retained access to their previous department's systems. Dormant accounts should not wait for a review cycle. Define a dormancy threshold (commonly 30, 60, or 90 days depending on the environment) and configure automatic revocation or suspension at that threshold. Dormant accounts that sit in an annual review queue for six months create unnecessary exposure. Service accounts require a different treatment: they do not log in interactively, so login-based dormancy detection does not apply. Service account reviews should focus on whether the service that uses the account is still operational, whether the account's privilege level is still required, and whether the credentials have been rotated recently.

The default presentation order in most access review systems is alphabetical or by account age. This is the worst possible ordering for producing meaningful review outcomes. Anomalies, the accounts most likely to represent access that should be revoked, get distributed randomly through a list of 500 items. Reviewers who run out of time and stamina before reaching item 347 never see the anomalous account at item 347. Redesign review campaign presentation to surface anomalies first. The accounts at the top of the review list should be the accounts that most need review: accounts unused for over 90 days, accounts held by users whose roles have changed since the access was granted, accounts with access combinations that no peer holds, accounts in SoD violation, accounts associated with users on extended leave, and privileged accounts held by non-privileged-role users. Standard access that is current, used regularly, and consistent with the user's role should appear at the bottom of the list or be pre-certified automatically (pending manager confirmation that the role is unchanged). This reordering does not require a sophisticated IGA platform. Even a spreadsheet-based review can implement it by sorting on a risk score derived from the signals above. The key metric for measuring whether anomaly-first presentation is working is the revocation rate: if reviewers are revoking access for 1-2% of accounts in a campaign, the anomaly-first presentation is surfacing real findings.

Dormant accounts are the clearest category of access that should be revoked without requiring a manager decision. An account that has not been used in 90 days does not need a human to evaluate whether it is still needed. It demonstrably is not being used. Automatic revocation or suspension after a defined inactivity threshold eliminates this entire category from the human review queue and reduces exposure continuously rather than waiting for a review cycle. The implementation sequence for dormant account automation should be: first, configure a 30-day warning notification to the account owner and their manager, giving them a window to log in if the account is needed but dormant due to leave or project pause. Second, configure account suspension at the threshold, not deletion. Suspension is reversible and avoids support escalations when an account is incorrectly identified as dormant. Third, configure a review period for suspended accounts (commonly 30 additional days) after which the account is deprovisioned if no reactivation request is received. The threshold values (30, 60, or 90 days) should vary by account type: 30 days for privileged accounts and service accounts, 60 days for standard user accounts, and longer for accounts associated with known seasonal workflows. Document the thresholds in your access management policy so that managers know what to expect and can plan for exceptions before the automatic action triggers.

Role mining is the analytical process of examining who has what access across your user population and identifying where actual access patterns diverge from what roles and job functions would predict. It is the mechanism that turns access review from a yes/no decision about current access into a structural improvement in how access is provisioned going forward. The basic role mining output is a map of access permissions held by users in each role or organizational unit, showing the common access (access held by 80% or more of the role) and the outliers (access held by fewer than 20% of the role). Outliers are the primary finding from role mining. A user who has access to a financial reporting system that no one else in their department has is either a genuine business exception (in which case there should be a documented justification) or an access accumulation artifact (access granted for a past project that was never removed). Role mining identifies these outliers systematically across the entire user population, producing a prioritized list of exceptions that can feed directly into access review campaigns. IGA platforms like SailPoint and Saviynt perform role mining as a core capability. For organizations without an IGA platform, role mining can be approximated using spreadsheet analysis: export the access matrix for a given system, group users by role or department, and identify permissions held by fewer than 20% of any peer group. This is lower fidelity than algorithmic role mining but produces actionable findings.

Separation of duties (SoD) is the principle that a single individual should not be able to both initiate and approve a transaction in a high-risk business process. The classic SoD example is payment processing: the person who creates a payment should not also be the person who approves it. SoD violations in access permissions, meaning a user who holds access rights on both sides of a controlled business process, represent a fraud risk that should trigger immediate access review rather than waiting for the next review cycle. SoD rule sets are defined based on the business processes in your environment. The most common SoD rules involve financial systems (ERP platforms, payment processors, general ledger systems), HR systems (the ability to create employees and set their salary is a classic SoD concern), and privileged IT operations (the ability to both create accounts and approve access requests). When a new access grant creates a SoD violation, the IGA platform should generate an immediate review task rather than allowing the violation to persist until the next review campaign. If the violation is a genuine business exception, a documented compensating control should be recorded. If it is an artifact of over-provisioning, the conflicting access right should be revoked. Most ERP platforms (SAP, Oracle, Workday) have built-in SoD rule libraries that can be integrated with IGA platforms to generate violation reports. Implementing automated SoD detection reduces the risk that a fraud-enabling access combination survives undetected through multiple review cycles.

Identity Governance and Administration platforms are the infrastructure layer for enterprise-scale access review. They are worth the investment for organizations with more than a few hundred users and more than a handful of systems, because the manual alternative, spreadsheet-based review campaigns, does not scale and cannot provide the access usage context that makes reviews meaningful. SailPoint IdentityNow is the market leader for enterprise IGA, offering comprehensive joiner-mover-leaver automation, role management, access request workflows, and compliance reporting. Its strength is breadth of connector support and compliance report quality. The implementation complexity is significant. Saviynt is positioned as a cloud-native alternative with strong integration for cloud infrastructure access (AWS IAM, Azure RBAC, GCP IAM) in addition to SaaS applications. It is a strong choice for cloud-heavy environments where cloud infrastructure access is a significant part of the review scope. Omada Identity is a strong mid-market option with cleaner implementation requirements than SailPoint for organizations that do not need the full enterprise feature set. Microsoft Entra ID Governance (formerly Azure AD Identity Governance) provides access reviews natively for Microsoft-centric environments and integrates directly with Entra ID groups and application assignments. For organizations with predominantly Microsoft workloads, Entra ID Governance is often the lowest-friction starting point for automated access review. The alternative to an IGA platform, a spreadsheet-based process with manual correlation, is acceptable for organizations with fewer than 200 users and fewer than 20 reviewed systems. Above that scale, the manual process consumes more time than the IGA platform costs and produces worse outcomes.

Access reviews are largely a remediation for the failure of joiner-mover-leaver (JML) automation. When joiners receive appropriate role-based access, movers have their access automatically adjusted when they change roles, and leavers have all access revoked immediately when they depart, the accumulated access anomalies that make access reviews necessary do not accumulate as rapidly. The joiner workflow should provision access based on role templates, not ad-hoc requests, so that every new hire in a given role receives the same starting set of permissions. The mover workflow, triggered by an HR system update when a user's job title or department changes, should compare the user's current access against the target role template, revoke access from the previous role that is not present in the new role, and provision any access required by the new role that the user does not already have. The mover workflow is the hardest to implement correctly because it requires the HR system to be the authoritative source for role changes and requires that role templates accurately reflect the minimum necessary access for each role. Leaver workflows are the most critical: account disable must happen within hours of an HR separation event, not days. The accounts most frequently exploited by terminated employees and external attackers are accounts that remain active after the user has left because the leaver workflow failed or was delayed.

Access review evidence for auditors should demonstrate that reviews happened, that reviewers made real decisions, and that access changes resulted from the review. An evidence package that proves checkbox compliance contains review completion timestamps showing that reviews were completed within the campaign window, a list of accounts reviewed with the reviewer identified for each, and a summary count of accounts approved and revoked. A real evidence package demonstrates that access cleanup happened. It includes the percentage of accounts flagged as anomalous before review, the revocation rate for anomalous vs. non-anomalous accounts (a higher revocation rate for flagged items demonstrates that the anomaly flagging is doing real work), the access rights revoked as a result of the review with the business justification, the SoD violations identified and resolved, and the automated dormant account revocations that occurred during the review period. Auditors, particularly those conducting SOC 2 Type II, ISO 27001, or PCI DSS assessments, are becoming more sophisticated about distinguishing real reviews from theater. Building an evidence package that demonstrates genuine risk reduction, rather than just process completion, is increasingly necessary to satisfy audit requirements and genuinely reduces your attack surface.