A user access review is a scheduled check in which the owner of each system, or each person’s manager, looks at who has access to what and confirms that every account and permission is still needed, then removes whatever is not. It is also called an access review, access certification or access recertification, and the goal is the same in each case: catching access that was granted for a good reason once and has since outlived it, such as a contractor whose project ended or an engineer who moved teams and kept their old admin rights. For a SaaS team the useful version is small and repeatable: list the systems in scope, export who has what, have a named reviewer decide keep or revoke for each row, make the changes, and file proof that you did.
The rest of this post explains how the terms differ, who asks for these reviews and why, the five steps in order, how often to run them, the columns for a review sheet you can copy, and where an identity provider (the system that handles logins for your applications) makes the work shorter. It is written for engineers and security leads at software companies that are preparing for a SOC 2 audit or answering enterprise security questionnaires, and it includes the specifics for Keycloak 26.x, the open-source server behind our identity management as a service.
What is a user access review?
A user access review compares the access people actually have with the access they should have. Access builds up in predictable ways: people change roles, projects end, someone is added to a group “temporarily”, and a departing employee is removed from the main directory but not from a handful of tools that were set up by hand. None of these looks like a failure when it happens, so nothing flags them at the time, which is why a periodic review exists.
The review has two halves that are easy to blur. The first is a decision: a person with enough context says whether each access should continue. The second is remediation, where the access that should not continue is actually removed and the removal is recorded. A review that produces decisions but no changes has not reduced any risk, and an auditor reading it will see that.
What is access certification, and how does it differ from recertification and entitlement review?
Access certification is the formal version of a user access review, in which a named reviewer attests that each person’s access is still appropriate and the attestation is recorded as evidence. In practice the terms overlap heavily, and different teams pick different ones, so it helps to know what each tends to mean.
| Term | What it usually means | Typical context |
|---|---|---|
| User access review | The general activity: someone reviews who has access and confirms or removes it | Audits, SOC 2, ISO 27001 evidence |
| Access certification | The same review, framed as a reviewer formally attesting that the access is appropriate | Identity governance tools, larger enterprises |
| Access recertification | Certification repeated on a schedule, so that earlier approvals are not assumed to stay valid | Identity governance tools, regulated industries |
| Entitlement review | A review at the level of individual permissions (a role, a group, a scope) rather than of accounts | Privileged access and application-level roles |
| Account review | A review that only asks whether the account itself should still exist | Offboarding clean-up, dormant account sweeps |
An account review answers “should this person still be here?”, while an entitlement review answers “should this person still be able to do this?”. Most of the risk sits in the second question, because a legitimate employee with leftover permissions from a previous job is a more common finding than an account that belongs to nobody. If you want the wider picture of where reviews fit in identity governance, our post on automated access request and approval workflows covers the request side that feeds into review. For how reviews fit into the wider discipline, see IAM vs IGA.
Who asks for user access reviews?
Several parties ask for them, usually in slightly different words, and one well-kept process can satisfy most of them.
- SOC 2 auditors. SOC 2 is an attestation report from an independent CPA firm, assessed against the AICPA’s Trust Services Criteria. The Security criteria include a group of logical access criteria (the CC6 series) covering how access is granted, changed and removed, and auditors commonly ask for evidence that you periodically review who has access. We have not quoted the criteria wording here, because the AICPA text is the authority and your auditor will tell you how they map it to your controls. Our post on SOC 2 Type 1 versus Type 2 explains why the evidence needs to cover a period of time for a Type 2 report, which is exactly what a quarterly review produces.
- ISO 27001 auditors. The standard’s Annex A includes controls on access rights, and certification audits typically sample your records of access being reviewed.
- HIPAA. The Security Rule’s administrative safeguards in 45 CFR 164.308 include workforce security and information access management requirements, which are the usual basis for reviewing who can reach systems containing protected health information.
- Enterprise customers. Procurement teams send security questionnaires with questions along the lines of “do you review user access periodically, and how often?”. Our posts on what security questionnaires ask about login and on why SSO alone does not get you through procurement show how those questions usually read and what evidence satisfies them.
What are the five steps of a user access review process?
The process below works for a team of any size, and it is deliberately short so that people actually run it every quarter.
1. Scope the systems
List the systems that hold customer data, production access or the ability to change either. For most SaaS companies that means the identity provider, the cloud console, source control, the CI/CD system, the production database, the ticketing and support tools that can see customer data, and the admin side of your own product. Review the ones where a wrongly held permission would do the most damage first.
2. Pull who has what
For each system, export the current list of accounts with their roles or group memberships. Do this on a single day and keep the export, because it is the snapshot the reviewer is deciding on. This step is the most tedious in a manual process, and it is the one that benefits most from centralising access behind a single identity provider, as the next sections describe.
3. Assign reviewers
Each row needs a reviewer who can judge whether the access is still appropriate. That is usually the person’s manager for general access and the system owner for administrative access. Reviewers should not review their own access, and the name should be written against the row before the review starts.
4. Decide keep or revoke
The reviewer marks each row as keep, revoke or change (for example, downgrade from admin to read-only). They should be able to see enough to decide without a conversation: the person’s role, what the permission allows, and when they last used the system. Rows left undecided after the deadline should default to a follow-up, not to keep, because otherwise silence becomes approval.
5. Remediate and keep evidence
Carry out every revoke and change, then record that it was done. The evidence an auditor wants is generally the original export, the reviewer’s decisions with dates, and proof that the removals happened (a ticket reference, a screenshot, or an admin log entry). Keep these together in one place per review cycle, so that a year later you can open a single folder and show the whole sequence.
How often should you run access reviews?
No single cadence is mandated for every organisation, and your auditor or customer contracts may set their own expectations, so treat the following as common practice rather than a rule.
| Access type | Common cadence | Reason |
|---|---|---|
| Privileged and administrative access | Quarterly | Highest impact if misused, and the group an auditor samples first |
| Standard access to production and customer data | Every six months | Changes more slowly, but still drifts as people move roles |
| Third-party, contractor and partner access | Quarterly, or at the end of each engagement | Least visibility into whether the person still works on your project |
| Any access after a role change or departure | At the event | A scheduled review is too late for someone who left last week |
The event-driven row is the one that is most often missed. Reviews on a calendar catch drift, but a role change should trigger an immediate check of what the person had in their old job. Our explainer on user provisioning covers the joiner, mover and leaver lifecycle that those events come from.
Why are third-party and partner accounts the riskiest rows?
Contractors, agencies, support vendors and partner users are the accounts you have the least information about. You do not control their employment, you often do not know when their engagement ended, and their accounts frequently sit outside your normal offboarding because no HR event triggers it. They also tend to be granted access quickly, to unblock a project, with broad rights that are never narrowed afterwards.
For that reason it is worth reviewing these rows separately, with the business owner who sponsored the relationship as reviewer rather than a line manager. Give each external account an expiry date at creation, and treat a missing sponsor as a reason to revoke. Where a partner organisation has its own identity provider, federating with it (so their staff sign in with their employer’s credentials) means their access ends when their employer removes them, which is a stronger guarantee than a password you manage yourself.
What does a user access review template look like?
A spreadsheet is enough for most teams, and the sheet below has one row per user per system (or per role, if a person holds several), and the columns are the minimum an auditor will usually look for.
| Column | What goes in it |
|---|---|
| User | Name and unique identifier (email or username) |
| System | The application or environment being reviewed |
| Role or entitlement | The role, group or permission the account holds |
| Last login | Date of the most recent sign-in, to spot dormant access |
| Reviewer | Named person responsible for this decision |
| Decision | Keep, revoke or change, with the new role if it changes |
| Remediation date | The date the change was actually made |
| Evidence link | Ticket, screenshot or log entry proving the change |
Create one sheet per review cycle and never overwrite an old one, because the history across cycles is what shows the process operates consistently over time. A front tab recording the scope, export date, reviewers and completion date makes the file self-contained evidence.
Where does an identity provider help?
The manual version of this process spends most of its time on step 2, collecting access lists from many separate tools. An identity provider reduces that in four ways.
- Centralise application access behind single sign-on. When applications authenticate through one provider, there is one place to see who can reach each of them, and removing a person there cuts off all of them at once. Applications that are not behind SSO remain the ones you must review by hand, so the list of those is worth keeping.
- Use groups and roles as the unit of review. Reviewing 40 role assignments is more practical than reviewing 4,000 individual permissions. If access follows from membership of a group such as “billing-admins”, the reviewer decides on the group’s members and the permissions follow. The RBAC feature page describes how roles and groups work on Skycloak.
- Use login and admin events as evidence. Last login dates come from authentication events, and the record that an account was disabled or a role was removed comes from admin events. Both are generated by the provider rather than assembled by hand afterwards.
- Close the loop with SCIM. SCIM (System for Cross-domain Identity Management) is a standard for pushing user changes from the source of truth to connected applications. When a leaver is deactivated in the directory, SCIM propagates it to each application that supports it, so remediation does not depend on someone remembering to log in to each one. Our comparison of JIT provisioning and SCIM explains why JIT alone does not remove accounts, and the SCIM feature page describes how it works with Skycloak.
How do you run an access review on Keycloak?
Keycloak has what the process needs, though it is not an access review tool: it has no built-in campaign that sends reviewers a list to approve. You assemble the review from its roles, groups, events and admin API.
Model access as realm roles, client roles and groups. Assign permissions to roles and give users membership of groups that carry those roles, rather than assigning roles to users one at a time. A reviewer can then work through group membership.
Turn on event logging. Under Realm settings, open the Events tab. In User events settings, toggle Save events to ON, set an Expiration for how long events are kept (set it to cover your audit period, plus margin), and check under Saved types (the Add saved types button) that the login event types you need, such as LOGIN, are included. In Admin events settings, toggle Save events to ON, and turn on Include representation if you want the request body stored, which shows exactly what was changed but can store a lot of data. The Keycloak Server Administration Guide documents both settings, and our complete guide to Keycloak auditing and event logging goes through them in more depth.
Pull who has what with the Admin REST API. The endpoints below are under /admin/realms/{realm}, and they require a token for a user or service account with realm-management permissions.
| Question | Request |
|---|---|
| Which users hold this realm role directly? | GET /roles/{role-name}/users (direct assignments only) |
| Which groups carry this realm role? | GET /roles/{role-name}/groups |
| Who is in this group? | GET /groups/{group-id}/members |
| What realm roles does this user hold, including through groups and composite roles? | GET /users/{user-id}/role-mappings/realm/composite |
| Which groups is this user in? | GET /users/{user-id}/groups |
| When did this user last log in? | GET /events?user={user-id}&type=LOGIN&max=1 |
Two of these endpoints return direct assignments only: GET /roles/{role-name}/users leaves out anyone who holds the role through a group or a composite role, which is exactly how this post recommends assigning access. For a complete answer, combine the role’s groups with each group’s members, or use the composite endpoint per user. Effective client roles use the equivalent clients/{client-uuid}/composite path under the same role-mappings resource. Results are paginated, so use the first and max query parameters for large realms. The last-login query only works if login events were saved, and only back to the expiration you set, so a user with no recent event might be dormant or might simply be older than your retention. Our guide to Keycloak data retention and erasure includes a script that walks all users and checks their last login event, and you can adapt it to write rows for the review sheet (remove the step that deletes users before you reuse it, because that script is written for erasure and not for review).
Remediate in the admin console or API. To remove access, delete the role mapping or the group membership. To stop a person signing in while keeping the record, disable the account (set the user’s enabled field to false, or toggle Enabled off on the user’s page), and delete it only when your retention policy allows. The matching admin event is your proof of remediation, and its timestamp goes in the remediation date column.
On Skycloak the same event data is available through the audit logs feature, which the feature page describes as covering authentication events and administrative actions with export to a SIEM (a security monitoring system). For the less common case of reviewing what an automated agent is allowed to reach, see resource access certifications for AI agents in Keycloak.
What are the most common mistakes in access reviews?
Rubber-stamping. When a reviewer is handed 300 rows and a deadline, the fastest response is to approve everything. Reduce the size of each reviewer’s list by assigning rows to the person who knows them, show last login and the meaning of each role so the decision does not need research, and look at the approval rate: a review in which nothing is ever revoked deserves a second look.
Reviewing accounts instead of entitlements. Confirming that “Priya still works here” is not the same as confirming she still needs production database write access. Put the role or permission on every row, and make the reviewer decide on that.
No proof of remediation. A spreadsheet saying “revoke” is a statement of intent. Auditors look for the change itself, and a missing remediation date or evidence link is one of the easiest findings for them to write. Collect the evidence as you make each change, not afterwards.
Reviewing only the identity provider. If half your applications keep their own local accounts, a review of the SSO user list will not find them. Keep an inventory of systems outside SSO and review those by hand.
Frequently asked questions
What is the difference between a user access review and an access audit?
A user access review is an internal control that you run on a schedule to keep access appropriate, and the person deciding is usually a manager or system owner. An audit is an independent assessment, by an external auditor or internal audit team, of whether your controls (including the access review) exist and operate. The review produces the evidence that the audit examines.
Who should perform a user access review?
The reviewer should be someone who knows what the person’s job requires: typically their manager for general access and the system owner for administrative access. Reviewers should never approve their own access, and a second reviewer from security is common for privileged accounts.
Is a user access review required for SOC 2?
SOC 2 does not prescribe a specific review format or frequency, but its logical access criteria lead auditors to ask how you confirm access stays appropriate, and a periodic review is the usual answer. Your auditor will tell you what they expect to see, and the frequency you document should be one you actually keep to.
Can user access reviews be automated?
Parts of them can be automated, including exporting access lists, flagging dormant accounts, routing rows to reviewers and applying removals through SCIM or an API. The decision itself should stay with a person, because judging whether a permission is still justified needs knowledge of the person’s work.