How to run a SOC 2 user access review that an auditor will accept
A customer or contract now asks for a SOC 2 report, and the periodic user access review is one of the controls the auditor will sample. Your organization owns the review, its scope and every removal decision. An independent CPA firm tests the review and issues the report; an implementation partner can help prepare the systems and records but does not sign off on the control. The review has to show that someone accountable checked who holds access to each protected system, decided whether that access still fits the person's role, and that every change was carried out. Under the 2017 criteria, this work sits mainly under CC6.2, which covers credentials and whether they stay valid, and CC6.3, which covers granting, changing and removing access based on roles and least privilege.
A workable review needs four things written down before the first campaign. First, a defined scope: every production system, administrative console, cloud account, repository and shared credential store that holds customer or company data, with the identity source for each. Second, named reviewers, usually the system owner or the line manager for each population, with a stated reason why they can judge the access. Third, a set frequency that you can keep for the whole observation period if you are heading to a Type 2 report. Fourth, retained records for each cycle: the population extracted, who reviewed it, what they decided, and a ticket or change showing each revocation was completed. Auditors sample the revocations as well as the reviews, so a review that finds problems but leaves no closure trail will not pass.
No fact supplied for this page gives a fee or a duration for the review, so confirm cadence, reviewer effort and sampling expectations with your auditor before you commit to a calendar. The effort depends on the number of systems in scope, how many identity sources feed them, and how many roles and role-based rules exist. A small team with one identity provider and a few applications will spend far less time per cycle than a team with several directories and hand-managed local accounts. Your costs are internal reviewer time and the tooling you choose, and they recur every cycle. Ask the auditor which populations they expect to see, whether they accept exports from your identity provider, and how they want evidence of removals presented.
The steps of a SOC 2 access review cycle
The sequence turns a broad question, whether everyone who can reach protected systems still should, into a set of signed decisions and removal records that an auditor can sample across the period. Each step leaves an artifact, and the artifacts together show the review was complete, owned and acted on.
Define the systems and accounts in scope
Start by listing every system that holds protected information or grants administrative control over it, including production cloud accounts, source control, the identity provider, data stores and internal tools that carry customer data. Record the owner of each system and whether human accounts, service accounts or both are included. Agree the list with the control owner and keep it as a versioned scope statement. The output is a dated scope document that the auditor can compare against the system description, so that no in-scope system is quietly left out.
Export the user population from the identity source
Pull a complete list of accounts and their role, group or permission assignments directly from the system of record, such as the identity provider or each application's own user directory, rather than from a spreadsheet someone maintains by hand. Include disabled and dormant accounts, because they are where removals are most often missed. Check that the export row count matches the count reported by the source. The output is a time-stamped population file with an identifier and hash or screenshot, which becomes the basis for every decision in the review.
Assign reviewers by system owner or manager
Assign each population to a reviewer who can actually judge whether the access is needed, usually the system owner for application roles and the line manager for individual employees. Avoid letting anyone review their own access or the access of the administrators who control the review. Record the reviewer for each item and confirm that the reviewer received the list and instructions. The output is a reviewer assignment register that shows who was responsible for which accounts during the review period.
Set the decision window and send the campaign
Open a defined decision window in which reviewers must respond, and state what happens to items left undecided. Tools that run access certification campaigns, such as midPoint, let designated reviewers keep, change or revoke each access item within that window. Confirm the window length and the review frequency with your auditor before the first cycle, because the criteria do not fix either number and auditors differ in what they expect. The output is a campaign record with its start date, close date, reviewers and items sent.
Record keep, change or revoke decisions
Each reviewer marks every item as keep, change or revoke, with a short reason where access is unusual, such as broad administrative rights or a role held by someone who has moved teams. Escalate items that are left open or that the reviewer cannot judge. Reviewers should not be able to edit the population after the export, so the decisions stay tied to the list they saw. The output is the completed decision log with reviewer identity, timestamp and reason, which shows that a person made each judgment rather than the process approving everything by default.
Execute removals and keep the ticket or log
Apply every revoke and change decision in the source system, preferably through the identity provider or an automated deprovisioning job so the removal is logged by the system itself. Where a change must be made by hand, open a ticket that names the account, the access removed, the approver and the completion time. Check afterward that the account no longer holds the access in the live system, not only in the campaign tool. The output is a removal record for each decision, with the system log entry or closed ticket that proves the access was actually taken away.
Report exceptions and retain the review record
Summarize the outcome: how many items were reviewed, kept, changed or revoked, which items were escalated or missed their decision window, and how each exception was resolved or accepted by management. Route the summary to the control owner for sign-off and store it with the population file, decision log and removal records under the retention period set in your policy. The output is a signed review report with exception tracking, which is the document an auditor samples when testing whether the review operated across the period.
Scope, reviewers and frequency decisions
Before a review runs, four decisions define what the auditor will test: which accounts are in the population, who signs off on each one, how often the review happens, and how exceptions such as contractors and shared accounts are handled. Each decision changes the evidence the auditor samples, so settle them in writing before the first review period starts.
Systems and privileged roles in scope
Define the population from the systems that hold protected information or can change production, including the identity provider, cloud consoles, source control, production databases and admin tooling. Privileged roles such as administrators and deploy rights need their own list, because a broad role grants more access than its name suggests. An overly broad population creates unreviewed access: any system left off the inventory can accumulate rights that nobody has ever certified. Check the population against CC6.2 and CC6.3 by tracing accounts from each in-scope system back to the identity source.
Reviewer selection: managers, owners or both
Managers know whether a person still needs a role, while system owners know what each role actually permits. Many organizations use managers for business need and system owners for privileged rights, and they record which reviewer covered which item. A reviewer who approves their own access, or who cannot see the roles they are approving, produces a review the auditor will reject. Write the reviewer rule into the access review procedure and confirm that the reviewer list is current at each cycle.
Review frequency tied to risk
SOC 2 does not fix a single review interval in the criteria, so the organization sets frequency through its own risk assessment and documents the reason. Privileged and production access usually warrants shorter cycles than standard business applications. The frequency you choose becomes a commitment the auditor tests, so a quarterly rule that runs twice a year becomes an exception. Confirm the interval with your auditor before the period begins and record the risk rationale that supports it.
Contractors and shared accounts
Contractors and vendor staff hold access under the same CC6.2 and CC6.3 logic as employees, so they belong in the population with an end date tied to their contract. Shared accounts are harder: a shared login cannot be attributed to one person, so the review must name the people who know the credential and confirm that each shared account is either retired or replaced with individual identities. Ask your auditor how they expect shared and service accounts to be listed, because undocumented shared access is a common exception.
How to prove removals actually happened
A reviewer's decision to revoke access is not evidence that access was removed. The auditor looks for the change in the system itself, a matching ticket or identity provider event, and timing that shows the removal happened within the window the organization set for itself. For CC6.2 and CC6.3, the test is whether the credential that should have gone is actually gone. Keep the decision and the removal as two linked records, so an auditor can start at a revoke decision in the review and follow it to the system change that carried it out, then to the ticket or event that proves the change happened and when.
Keep before and after snapshots of role assignments for every campaign. The before snapshot shows what the reviewer saw, and the after snapshot shows what remained. Each revoke decision should carry the identifier of the account, the role or group removed, the reviewer, the date of the decision and the date of the change, so that a single sampled item can be traced end to end. Confirm with your identity platform whether it can export assignments with their history, and whether the export includes the timestamp of each change, because a current-state list alone cannot show that a removal happened during the period being tested.
Decide in advance what happens to items the reviewer does not answer. An unanswered item left in place is an exception the auditor will ask about, so define an escalation path and a default action, such as revoking after the deadline or routing to the reviewer's manager, and record when that default was applied. Screenshots of an admin console are weak evidence because they are easy to alter, cannot be re-run by the auditor and capture one moment only. System-generated exports and logs with timestamps are stronger, and they are the artifacts to request when the platform can produce them.
Which open-source identity tools include access certification free
midPoint is an open-source identity governance and administration platform licensed under EUPL-1.2+. Its access certification feature runs campaigns in which designated reviewers decide, within a set timeframe, whether to keep, change or revoke each access item, such as a role assignment. This matters for SOC 2 because a periodic review is the step that catches access that accumulated over time, and the same decisions support segregation of duties when reviewers see conflicting roles side by side.
- Campaign structure: A campaign defines which access items are in scope and who reviews them, so the scope and reviewer list become evidence the auditor can read.
- Decision outcomes: Reviewers choose keep, change or revoke, and revocations need to flow through to the actual systems to count as removals.
- Deadlines: The set timeframe gives the review a defined end, which lets you show that overdue items were escalated rather than silently left open.
- Segregation of duties: Reviewing role assignments together helps surface combinations that should not coexist.
- Record keeping: Campaign results, reviewer identities and completion dates should be exported and retained with the rest of the review evidence.
Confirm current feature availability and licensing against the midPoint access certification documentation before you commit to a design, and confirm that the version you deploy includes the campaign functions you rely on.
authentik is an open-source identity provider. Several features that a SOC 2 team typically needs for periodic and joiner-leaver controls are listed as Enterprise features in its license terms. Those include scheduled user offboarding, Google Workspace and Microsoft Entra ID provisioning, OAuth authentication for SCIM, privileged access requests, enhanced audit logging with before and after values, CSV exports and Object Lifecycle Management, which the vendor describes as periodic access reviews. Teams should plan around that split rather than assume the free edition covers the review workflow.
- Periodic access reviews: Object Lifecycle Management is the feature that performs periodic access reviews, and it sits in the Enterprise tier.
- Scheduled offboarding: Timed removal of users is an Enterprise feature, so the community edition leaves leaver removal to manual steps that need their own evidence.
- Provisioning: Google Workspace and Microsoft Entra ID provisioning, along with OAuth authentication for SCIM, are Enterprise features.
- Privileged access requests: Request and approval of elevated access is an Enterprise feature.
- Audit detail and exports: Enhanced audit logging with before and after values and CSV exports are Enterprise features, which affects how much change history you can show an assessor.
Check the LICENSE file in the authentik repository and the current provider and stage documentation against the version you plan to run, because editions and feature names change between releases.
Teleport provides access to infrastructure such as servers, Kubernetes clusters and databases through a single access plane. Its access lists, access reviews and identity governance capabilities are Enterprise only. The Community Edition is narrower: its single sign-on support is limited to GitHub, and access requests are handled through the command line only. A team that expects a web-based review workflow with reviewer decisions should expect to need the paid tier.
- Access lists and reviews: Both are Enterprise only, so periodic review of infrastructure access needs the paid edition or a separate process.
- Identity governance: Governance workflows are Enterprise only.
- Single sign-on: The Community Edition supports GitHub SSO only, while OIDC and SAML single sign-on are Enterprise features.
- Access requests: The Community Edition handles access requests through the CLI only, which limits how approvals are recorded.
- Session evidence: Session recording is a separate capability from access review, so confirm what it covers in your edition before relying on it as review evidence.
Confirm the current split against the Teleport Community Edition license and the feature matrix, since the boundary between editions has moved over time.
eramba is a governance, risk and compliance platform that covers use cases such as risk management and internal controls. Its Community edition covers 4 of 7 use cases. Automated Account Reviews, which is the feature closest to periodic access review, is in the paid Enterprise edition, along with Awareness Programs, Online Assessments, automation, REST APIs, reporting and notifications. Because the review workflow sits outside the free tier, an organization using eramba for access certification should budget for Enterprise or run reviews outside the tool.
- Use case coverage: Community covers 4 of 7 use cases, so the free edition is a partial GRC base rather than a complete one.
- Automated Account Reviews: This use case needs the Enterprise edition.
- Reporting and notifications: These are Enterprise features, which matters when you need reminders for overdue reviewers.
- Automation and APIs: REST APIs and automation are Enterprise, so pulling directory data into review campaigns is a paid capability.
- Edition changes: The vendor announced license changes for its Community and Enterprise (On-Prem) editions in June 2024, so confirm the current terms directly.
Before buying, ask the vendor in writing which edition includes each use case you need and check the current licensing announcement and course materials.
Running the review yourself or with an implementation partner
The decision to run user access reviews in-house or with an implementation partner turns on who will carry the recurring work and who must be able to explain it to an auditor. The organization owns every decision in the review: which systems are in scope, who the reviewers are, what counts as an appropriate role, and whether a removal was justified. An implementation partner such as DeployOpen can plan the review workflow, configure a self-hosted identity platform inside your own cloud accounts or data centers, integrate it with the systems that hold access, and document the procedure and evidence trail. The partner does not decide who keeps access, and it does not issue the SOC 2 report. Only the independent CPA firm does that.
Before choosing, confirm three things with your team. First, whether you already have an identity provider that feeds your applications through SCIM or single sign-on, because a review is only as complete as the source of access it reads. Second, which open-source tool you plan to use and whether the access certification feature you need sits in its free edition or a paid tier, since the licensing terms change and the answer must come from the vendor's current documentation. Third, who on your staff will own the campaign calendar and sign off on revocations. If no one internal can do that, an outside partner will not fill the gap, because the sign-off is a management responsibility.
DeployOpen works on fixed scope agreed in writing before work starts, so the deliverables, systems covered and handover items are defined up front rather than billed by open-ended effort. A useful scope statement names the applications and infrastructure in each review, the reviewer roles, the evidence each campaign must produce, and who receives the auditor's requests afterward. Ongoing support, upgrades and continuous testing are available as retainers for the period after the first campaigns run. Ask any partner, including DeployOpen, to show you how the evidence will be exported and stored under your control, and ask your CPA firm to confirm in advance that the design and sampling approach meet its expectations.
What usually breaks an access review in an audit
Most failed SOC 2 access reviews fail on process, not on access itself. The five failures below are the ones auditors most often find when they sample a review, and each has a specific check that prevents it.
Reviews that cover only some systems
A review that covers the identity provider but skips the cloud console, the code host, the production database or the support tooling leaves gaps an auditor will test. Auditors compare the review scope against the system inventory in the system description. Before the period starts, list every system that holds customer data or grants production access, and confirm each one appears in the review population with its own named owner.
Reviewers who approve their own access
When a manager, engineer or administrator reviews access that benefits them directly, the review does not test appropriateness. Assign each system or role group to a reviewer who is independent of the people whose access they approve, and record the reviewer's identity on every decision. Where the only available approver is the account holder, route that item to their manager or to the system owner and document the exception.
No record of removals
Auditors do not accept a reviewer's statement that access was removed. They look for a change record showing the account, role or group membership was revoked, with a timestamp and the actor who made the change. Keep the review decision, the ticket or certification item that triggered it, and the system log showing the revocation, and link them together so a single sampled item can be traced end to end.
Reviews that stop when staff change
A review campaign that was set up for last quarter's team often breaks when a reviewer leaves, a system owner changes role or a new tool is added and nobody updates the assignments. Items then sit unreviewed or are closed by default. Name a backup reviewer for every assignment, check reviewer status before each campaign launches, and keep a record of reassigned items so the reviewer change is visible.
Population exports that do not match the system of record
If the spreadsheet given to the reviewer is exported by hand, filtered or stale, the review tests the wrong set of accounts. Auditors often re-pull the user list from the source system and compare it to the review population. Generate the population directly from the identity provider or the application, record the query or export parameters and timestamp, and reconcile counts against the source before the reviewer starts.
Access review questions buyers ask
How much effort does a SOC 2 user access review take?
The effort depends mainly on how many systems and accounts are in scope, how many reviewers must sign off, and whether access data can be exported from each system in a usable form. A review of a small product with one identity provider and a few production tools is far lighter than a review that spans cloud accounts, databases, source control, and dozens of SaaS applications. Costs have two parts: the internal time of managers and system owners who must approve or revoke access, and any tooling or engineering work needed to pull account lists automatically. The one-time work is designing the review, defining the systems and reviewers, and building the export. The recurring work is running each cycle and keeping the records. Ask any implementation partner for a written scope listing the systems, reviewers, and export method before agreeing on a fixed price.
Can a small team run SOC 2 access reviews without outside help?
Yes, a small team can run access reviews internally, provided someone owns the process and keeps complete records. The auditor does not require a particular tool or a consultant. What the auditor does require is evidence that the review happened at the defined frequency, that the right people reviewed the right accounts, and that any unneeded access was removed. Outside help is most useful when the team lacks time to build exports from each system, when the identity setup is complex, or when no one internal understands what the criteria expect. An implementation partner can prepare the systems, exports, and review records, but the organization still owns the controls and the decisions. Only the independent auditor issues the report.
How long before the audit period should access reviews start?
A Type 2 report covers an observation period, and the controls must operate throughout it, so access reviews should be running for the whole period before the auditor begins testing. The Type 2 report depends on controls having operated over the period, which is why teams should start reviews early enough to complete at least one full cycle inside that window. Confirm the exact observation period and review frequency with your chosen auditor, since both are set in the engagement and in your control design rather than by a general rule. If the first review is run late or skipped, the auditor may record an exception. Ask your auditor how they will test the review cycles they expect to sample.
Does a SOC 2 Type 1 report need an access review?
A Type 1 report evaluates whether controls are suitably designed and in place as of a specific date, not whether they operated over time. Even so, the access review control must be designed, documented and ready to run at that date, because the auditor will test whether the process exists and would work as described. Teams often run one or more review cycles before the Type 1 date to show the design is working in practice. Whether a single trial review is enough is a question for your auditor, who will set the expectations for your system and scope. A Type 1 does not cover operating effectiveness over a period, so it will not show that reviews ran regularly.
Which open-source identity tools include access certification for free?
Licensing differs by product and edition, so check the current license and feature list before choosing a tool. midPoint, licensed under EUPL-1.2+, provides access certification campaigns in which designated reviewers decide within a set timeframe whether to keep, change or revoke role assignments and other access items. authentik documents periodic access reviews, through its Object Lifecycle Management feature, as part of its Enterprise features. Teleport lists access lists and access reviews as Enterprise only, while its Community Edition supports GitHub SSO and access requests through the CLI. Confirm what each edition includes with the vendor, and verify against the license file and feature matrix before you rely on any tool for evidence.
What will the auditor sample from our access reviews?
Auditors typically select a sample of review cycles within the period and check each one for completeness, reviewer identity, and follow-through. For each sampled review, expect requests for the population of accounts or roles reviewed, the reviewer's sign-off, the date, and evidence that any revoked access was actually removed from the system. They may also check that reviewers had enough information to decide, such as the role, last login, or business justification. Sampling methods and sample sizes are set by the auditor, so ask them to confirm the approach early. Keep system exports unaltered and dated, because auditors test whether the population was complete as well as whether the decisions were right.
How does an implementation partner differ from the auditor for access reviews?
An implementation partner prepares the systems, exports, review workflows and records, and helps the organization design a control that fits its environment. The organization remains responsible for the control, its reviewers, and its decisions. An independent auditor or CPA firm tests the control, samples the evidence, and issues the SOC 2 report. DeployOpen prepares systems and evidence for compliance assessments, but it does not issue audit reports, attestations or certifications. Because the auditor must remain independent, ask any partner to confirm in writing which tasks it will perform and which the auditor will perform, and agree the scope before work begins.
How DeployOpen prepares access review evidence
DeployOpen starts by agreeing the access review scope in writing before any tooling is touched. The written scope names the systems in the review, the reviewers for each system, the review frequency your own policy sets, and the rule for what counts as a removal that must be evidenced. Because most engagements are fixed-scope, these decisions, along with the deliverables and timeline, are fixed before work starts. Your organization still owns the control itself, including who approves access and who signs off each campaign.
Where the chosen self-hosted identity tooling is in scope, DeployOpen implements or integrates it inside your own cloud accounts, data centers or air-gapped network. That work covers connecting the identity source, configuring the review campaigns or reports, setting the retention of exports, and documenting the procedure that reviewers follow. Before you commit to a tool, confirm in its current documentation and license that the review feature you need is in the edition you plan to run, since the free and paid tiers of several open-source identity products differ on access certification.
DeployOpen then prepares the evidence package the auditor will sample: the written procedure, the scope document, dated campaign records with each reviewer's decision, the tickets or change records that show each removal was carried out, and the list of exceptions with follow-up. DeployOpen prepares systems, controls and evidence for the examination. It does not issue audit reports, attestations or certifications; only the independent CPA firm performing your SOC 2 can do that. Hiring DeployOpen does not guarantee a particular result, and the outcome of the examination depends on whether your controls operated as designed across the period.
