Periodic user access reviews: SOX requirements and evidence

Periodic user access reviews: what SOX auditors expect management to recertify

A periodic user access review asks management to confirm, at set intervals, that everyone who holds access to a financially significant application, database or operating system still needs it for their current job. The review exists to catch access that has accumulated over time, as people change roles, take on temporary projects and keep rights they no longer use. PCAOB AS 2110 names IT personnel holding access beyond what their duties require as a risk to internal control over financial reporting, because that excess access can break segregation of duties. A compliance lead or CIO should expect the auditor to ask two things: who signed off on each reviewed entry, and what evidence shows the reviewer had a real basis for the decision. Management owns this control. The review is also tested as a control in its own right, so the auditor will check whether it operated as designed, which PCAOB AS 2201 frames as whether the performer had the necessary authority and competence.

Where these reviews most often fail is the population, not the sign-off. If the listing sent to reviewers omits accounts, nested group memberships, database roles or service accounts, the review can be clean and still miss the access that matters. Confirm how the listing is generated, which systems feed it, and how someone checks it against an independent source such as the directory or the application's own user table. Reviewers also struggle when role names are unclear, because a reviewer who cannot tell what a role grants will approve it by default. Define each role's meaning and its conflicts before the campaign starts, and record what happened to every item marked for change or removal, including the date the access was actually revoked.

Identity tooling can make the campaign repeatable and the trail easier to show. Open-source options such as midPoint document access certification campaigns in which designated reviewers decide within a set timeframe whether to keep, change or revoke each item. Directory and provisioning tools such as FreeIPA and authentik can then enforce the decision, since authentik's SCIM provider deprovisions users from a target application when they lose access. Tooling does not satisfy the control by itself. Management still has to define the review frequency, the reviewer for each system, the escalation for overdue items and the evidence retained, and must confirm with its auditor how much of the population the sample will cover.

Which access lists a periodic user access review must cover

A review is only as complete as the listings it starts from. Scoping decides which applications, databases, operating systems, administrative paths and directories appear in the population, and those decisions follow from the financially significant systems identified in the SOX ITGC scoping work. Management needs these controls only where they support reliable financial reporting.

In-scope applications and their user lists

Start with the financially significant applications identified in scoping, then pull the complete user list from each one, including inactive, locked and disabled accounts. Reviewers cannot recertify access they never see, so compare the extract against the application's own user table or a system report. Ask who owns the extract logic and whether it has been tested for completeness.

Databases beneath the applications

Many users reach financial data through a database login or a reporting tool rather than the application screen. Each database role, schema owner and direct login that can change financial records belongs in the listing. Confirm that the population includes database accounts mapped to application service logic, since a review that covers only the front end can miss a direct path to the data.

Operating systems and infrastructure administrators

Operating system accounts, hypervisor consoles and administrative groups on servers that host financial systems give broad control over the data beneath them. List local administrators, sudoers entries and privileged groups on each in-scope host, and record which of them are shared. Reviewers should see these entries alongside application access so that an administrator who can also change data is visible in one place.

Directories that grant access

Central directories supply group membership that flows into many applications, so a directory group can grant access that appears nowhere in an application screen. List the groups that map to in-scope systems and their nested members. The FreeIPA project describes its directory as storing users, groups and hosts with centralized access control, so confirm that the review population follows nested groups and delegated administrators.

Shared and service accounts

Decide explicitly whether shared and service accounts appear in the listing. Excluding them is a common gap, because these accounts often hold standing privileges and have no named owner. Where they are included, the reviewer must identify an accountable owner and a business purpose for each one. Where they are excluded, document the reason and the separate control that covers them.

Role expansion and third-party systems

Role-based entitlements must be expanded to the individual users who hold them, because a reviewer who sees only a role name cannot judge the access. Record how each role maps to permissions, and treat hosted or vendor-managed systems as in scope when they process financial data. For those systems, confirm with the provider what user listings it can produce and how the organization receives them.

How an assessor tests a periodic user access review

This table compares each test step an external auditor typically performs on a periodic user access review, the evidence requested for that step and the findings that most often cause exceptions. Read it as a checklist for preparing the review before fieldwork begins, since the same evidence supports design and operating effectiveness testing.

Test step	Evidence requested	Common findings
Walkthrough of the review process	Written procedure, the review calendar, the tool or ticket workflow used to run the campaign, and the names of the people who perform each step	Procedure describes a review that the tool does not actually run, or the owner named in the procedure has left the company
Design: cycle frequency	Documented review frequency for each in-scope application, database and operating system, and the approved schedule for the year	Frequency is set for the application but not for the database or directory layer beneath it, leaving those accounts unreviewed
Design: reviewer assignment	Reviewer list per system, with the business or system owner role that justifies each assignment and any rule that stops reviewers from approving their own access	Reviewers are IT administrators who approve their own privileged accounts, or the reviewer is not the owner of the system
Design: defined scope	Scope document listing the in-scope systems, the account types covered (named, shared, service and privileged) and the role or group definitions reviewed	Scope omits service accounts, nested group membership or direct database grants, so those accounts never appear in a review
Operating effectiveness: sample of cycles	For a selected sample of review cycles, the campaign record, reviewer decisions, sign-off dates and any escalations	Reviews signed without evidence of reviewer decisions, or sign-off dated after the period the review was meant to cover
Population completeness	System-generated listing of accounts and role assignments as of the review date, with the query or report parameters used to produce it	The listing used for review does not match the system population, often because it was exported manually or filtered by a stale group
Reviewer authority and competence	Evidence that the reviewer owns the business process or system and understands the access being approved, such as a role description or delegation record	Reviewer lacks the knowledge to judge access, for example approving database roles they cannot interpret, or lacks authority over the system
Follow-up on removals and changes	Revocation tickets or tool actions for each item marked for removal or change, with completion dates and a re-check of the account state	Removals recorded in the review but not carried out in the target system, or access still active weeks after the reviewer decided to revoke it
Segregation of duties check	Reviewed role assignments compared against conflict rules, with any conflicting combinations flagged and resolved	Excessive privileges are approved as routine, so a single person can both create and approve transactions without a documented exception

Running a recertification cycle from listing to closed removals

This sequence turns a periodic access review into evidence an auditor can trace from the system listing to the reviewer decision, the ticket, and the confirmed removal. Management sets the scope and frequency first, so each cycle can be compared against the same documented baseline.

Document scope and review frequency
Management decides which applications, databases, operating systems and directories fall in scope, based on which ones feed financially significant reports, and sets how often the review runs. Record both in a written review standard approved by a named owner before the first cycle starts. The output is the approved scope and frequency document, which the auditor will compare against each cycle to confirm nothing was quietly dropped.
Produce complete system-generated listings
Generate user, role and privileged account listings directly from each in-scope system or its directory, not from a spreadsheet maintained by hand. Include disabled, service and shared accounts, since reviewers cannot certify what they cannot see. The output is a dated listing per system with its generation method and parameters recorded. Confirm the listing row count against the system's own totals so you can show the population was complete.
Assign reviewers who understand each role
Assign each listing to a reviewer who knows what the role does and who can judge whether the person still needs it, typically the business owner of the application or the manager of the user. Record the reviewer, the scope they are responsible for, and any reviewer who is also a user of the same access, which must be reassigned. The output is a reviewer assignment log that shows every listing has an owner.
Record keep, change or revoke decisions
Each reviewer marks every line as keep, change or revoke and must state a reason for changes and revocations. Set a decision deadline in the review standard and track overdue items to escalation. An open-source identity platform such as midPoint can run this as a certification campaign, which keeps decisions, reviewers and timestamps in one record. The output is a completed decision record for every line, with no blank entries.
Action removals through tickets
Raise a change or access ticket for every revoke or change decision, referencing the review cycle and the line item. Assign the removal to the team that administers the system, and require the ticket to name the exact account and entitlement to be removed. The output is a ticket for each removal, linked back to the decision record, so the auditor can follow each revocation from review to action.
Verify removals against the systems
Re-run the listing or query the target system after the removal window closes and confirm each revoked entitlement is gone. Check that no revoked user reappears through a group, role or sync path, since that is a common gap. The output is a verification record that compares the post-removal listing to the decision record, with exceptions logged and followed up to closure.
Archive the signed review package
Bundle the scope document, dated listings, reviewer assignments, decision records, removal tickets, verification results and a signed reviewer or manager attestation into one package per cycle. Store it in a location with restricted write access and a retention period set by the organization's policy. The output is an archived package an auditor can sample from without asking for each piece separately, and it becomes the baseline for the next cycle.

Evidence that passes a periodic user access review

An access review is only as credible as the records behind it. Auditors look for a written standard that defines scope and frequency, listings that prove what was reviewed, signed decisions, and proof that removals actually happened, and they expect each piece to be kept current between audit cycles.

Review policy and standard

The written access review standard sets which applications, databases and operating systems are in scope, how often each is reviewed, who the reviewers are for each system, and what counts as an acceptable decision. Auditors compare the review actually performed against this document, so a stale policy that names systems the company no longer runs creates a finding of its own. Keep it under change control with an owner, an approval date and a revision history. Confirm that the scope section lists the same financially significant systems used in your ICFR scoping.

System-generated user and role listings

Each review starts from a complete listing of users and their roles or group memberships, produced by the system itself with the run date and the query parameters shown. A listing a person edited by hand is hard to defend. Store the export with its date, the report name and the filter used, and confirm it includes disabled, service and generic accounts, not just active employees. Completeness is shown by reconciling the listing's record count against an independent source, such as the directory or the database user table.

Reviewer sign-off with decisions

The reviewer, who should be the business owner of the role and not the person who granted the access, records a decision on every line: keep, change or revoke. Auditors look for evidence that each item was actually considered, so blanket approvals and unsigned spreadsheets are weak. Retain the signed or timestamped record with the reviewer's name, the review period and the population reviewed. Campaign tools that log each decision and its timeframe make this easier to show, but you still need to confirm the reviewer was authorized for that system.

Tickets and change records for removals

Every access revoked or changed during the review needs a traceable request, usually a ticket that links the reviewer's decision to the action taken. Auditors pick revoked items and follow them to the change record to confirm who executed the removal and when. Keep the ticket number on the review line item so the chain runs in both directions. A decision recorded as revoke with no matching change is a gap that auditors will test for.

Post-removal listings

After revocations are executed, a fresh listing from the same system, with its own run date, shows the removed access is gone. This is the artifact that proves the change happened in the system and not only in a ticket. Compare the post-removal listing to the reviewer's decisions line by line and file both together. Where access is granted through groups or automated provisioning, confirm the listing reflects effective access, since a removed group membership can leave access in place through another route.

Exception logs and follow-up

Some items will not be resolved within the review cycle, such as access a system owner cannot yet remove or a reviewer who disputes a decision. Log each exception with its owner, the risk accepted, any compensating control, a target date and the eventual closure evidence. Auditors read exception logs closely because overdue or unexplained items point to weak review follow-up. Confirm who approves each exception and whether leadership sees the open items before the review is signed off.

What running periodic user access reviews costs

This table compares the main cost components of a SOX periodic user access review program, who is paid for each, whether it is one-time or recurring, and what drives it up. Read it as a checklist for a written quote: no figures are given because total cost depends on the systems in scope and how often reviews run. The main takeaway is that open-source tooling removes license spend but not reviewer time, listing work or auditor sampling effort.

Cost component	One-time or recurring	What drives it	How to keep it down
Tooling or licenses for review campaigns	Recurring (license or subscription); one-time setup	Number of reviewers, campaign types and whether the tool is commercial or self-hosted open source	Self-host an open-source campaign platform in your own environment; confirm its capabilities against your review design before committing
Engineering time for complete listings and source connections	One-time build, then recurring upkeep	Number of in-scope applications, databases and operating systems, and how many lack directory integration	Connect sources to a central directory, then reuse connectors; ask the provider to state which systems need manual extracts
Reviewer time for each cycle	Recurring, every review period	Number of accounts and roles per system, review frequency, and how much context reviewers receive	Use role-based grouping and pre-filled details so reviewers decide faster; agree on cycle frequency with the auditor early
Removal and follow-up work	Recurring, after each cycle	Number of revocations, how often removals need ticket-based action, and whether revocations are automated	Automate deprovisioning where possible and track each removal to closure with evidence
Evidence upkeep	Recurring	Retention period, number of cycles, and the detail required to show who reviewed what and when	Standardize exports of listings, decisions and sign-offs so each cycle produces the same artifacts
External testing or review of the process	Recurring or periodic, depending on scope	Whether an independent party reviews design, population completeness or operating effectiveness	Scope the review to the controls that carry financial reporting risk and ask for the scope in writing
Auditor sampling effort	Recurring, set by the external auditor	Number of cycles tested, sample sizes, and the quality of the listings and evidence provided	Provide complete, reconciled populations and clear decision records so fewer follow-up requests are needed

Open-source tools that can run or support the review

Access reviews depend on three things: a complete listing of who holds access, a decision record from a designated reviewer, and proof that removals reached the target systems. The four tools below each cover one of those needs, and none of them replaces the organization's own review decisions or its evidence of operation.

Certification campaigns with midPoint

midPoint (EUPL-1.2+) runs access certification campaigns in which designated reviewers decide, within a set timeframe, whether to keep, change or revoke each access item, such as a role assignment. That decision record is the core evidence auditors ask for. Check whether the campaign scope covers every in-scope application, database and operating system, whether reviewers are independent of the access they approve, and how overdue items escalate. The EUPL-1.2+ license terms should be reviewed by your legal team before deployment.

Removal propagation with authentik

authentik (MIT) uses its SCIM provider to push user and group creations, changes and deletions to target applications over SCIM 2.0. It runs a full sync every hour and deprovisions users from the target when they lose access to the application. This shows that a removal decided in the review actually took effect downstream. It does not replace the review itself. Confirm in your environment which target applications support SCIM and which still need manual removal.

Complete listings from FreeIPA

FreeIPA (GPL-3.0-or-later) holds users, groups and hosts in a central directory built on 389 Directory Server, with centralized access control and delegated administration through its web UI and command line tools. That gives the reviewer one source for the population being recertified. Auditors will still ask whether the listing is complete, so compare it against systems outside the directory. Confirm which applications and operating systems authenticate against it, and how the GPL-3.0-or-later terms apply to your deployment.

Evidence tracking with CISO Assistant

CISO Assistant (AGPL-3.0-only) tracks audits and compliance assessments and can hold the evidence attached to them, including review records and sign-offs for SOC 2 and ISO 27001 work. Use it to keep review evidence, exceptions and follow-up tickets in one place for the assessor. Its framework mapping across frameworks is a feature you should verify for this control before relying on it. The AGPL-3.0-only terms also apply if you modify and offer the software over a network, so confirm this with counsel.

Who signs the review and who may help with it

Your organization owns the access review control from start to finish. A named control owner is accountable for the design, the review calendar, and proof that each cycle ran. Reviewers are the business managers who understand what each role in a financial application is for, so they can decide whether a person still needs that access. IT staff produce the user and entitlement listings, confirm that those listings are complete and accurate, and act on the decisions reviewers record. Auditors will ask who did each step, so the names and responsibilities should be written down.

Control owner: holds accountability for the control, approves the scope of each cycle, and answers auditor questions.
Business reviewers: managers who certify whether each user's access matches their current duties.
IT listing producers: staff who extract listings from applications, databases and operating systems and document how they were generated.
Access administrators: staff who apply approved removals or changes and retain the tickets showing completion.
Backup reviewers: named alternates so the cycle still closes when a reviewer is absent.

Before relying on this split, confirm that each reviewer is independent of the access they approve and that no one reviews their own access.

Where periodic access reviews usually fall short

Most failed periodic reviews are not caused by a missing review but by a review that did not cover the right population, did not test the right risks, or left no trail. The cards below cover the gaps auditors find most often, with the fix and the evidence they will ask for.

Incomplete system listings

The review is only as complete as the listing it starts from. Service accounts, shared accounts, and direct database users often sit outside the identity provider and never appear in an application export. Reconcile each in-scope system's account list against a source such as the directory, the database user table, and the operating system account store, and record the reconciliation. Auditors will ask how the population was generated and whether it was checked for completeness before the review began.

Rubber-stamped whole lists

A reviewer who approves a 400-line export in one click provides little assurance. Require reviewers to act on each access item, keep, change, or revoke, within a set timeframe, and escalate items left undecided. Designated reviewers should be the people who understand the job, not only the line manager when the manager lacks system knowledge. Auditors will ask for item-level decisions with reviewer identity and dates, not a single signed summary.

Privileged and cross-application roles skipped

Reviews often check base application access and miss administrator roles, database owner rights, and roles that combine permissions across systems. AS 2110 treats IT personnel holding access beyond their duties as an IT risk to financial reporting, so these roles need their own review step. Pull role assignments for each application, flag conflicting combinations, and review administrative groups at the operating system and database layers. Auditors will ask whether privileged roles were reviewed separately and whether conflicts were resolved.

Removals recorded but not verified

A reviewer who marks access for revocation has not removed it. Confirm each revocation in the target system, not only in the review tool, and keep the before and after state. Automated provisioning can help here, but confirm that deprovisioning reaches every target, including databases and operating systems that a connector may not cover. Auditors will sample revoked items and check the account state in the system itself.

Scope that shifts between cycles

When the list of in-scope applications, databases, or reviewers changes from quarter to quarter without a record, auditors cannot tell whether access was reviewed consistently. Fix the scope in a written, approved document tied to the SOX scoping analysis, and record every addition or removal with its reason. Compare each cycle's population against the prior one. Auditors will ask for the approved scope document and the change log behind any difference.

Missing follow-up on exceptions

Reviews frequently identify inappropriate access but leave no record of what happened next. Every exception needs an owner, a due date, a closure action, and a closure date, with escalation when deadlines pass. Keep the exception log with the review package so the trail runs from finding to resolution. Auditors will ask for the exception list for each cycle and evidence that each item closed.

Questions buyers ask about periodic user access reviews

How much effort does a periodic user access review cycle take?

The effort depends mainly on how many in-scope systems, accounts and reviewers the cycle covers, and on how clean the access data is when the review starts. No supplied source gives a standard number of hours, so ask any partner or internal team to estimate effort from your own inventory. The main drivers are the number of applications, databases and operating systems in scope, how many roles and entitlements each system exposes, whether group membership is nested, and whether reviewers can see what each access item actually permits. Reviews get heavier when the listings must be extracted by hand from several systems and reconciled to HR records. Ask for the effort split between data extraction, reviewer time, follow-up on removals and evidence retention.

How often must user access reviews run, and who decides?

SOX Section 404 does not set a fixed review frequency for user access, so management sets the cadence as part of its control design and must be able to show that the cadence fits the risk. Management owns that decision, and the external auditor tests whether the chosen frequency was followed and whether it is sensible for the systems involved. Confirm the frequency with your external auditor before the control is designed, because a cadence that is documented but not performed will become a testing exception. Your control owner should also name the reviewers for each system, since the auditor will check that the person performing the review has the authority and competence to judge access.

Can management run user access reviews without an outside firm?

Yes, management can run user access reviews in-house, and most do. Management owns the control, names the reviewers and signs off on the outcome, so an outside firm cannot take that responsibility. An implementation partner can help by preparing the listings, configuring a certification workflow or documenting the control, but it does not perform the attestation or issue an audit report. Whether to bring in help depends on whether your team can extract complete access lists from each in-scope system, route reviews to the right owners and keep the evidence in a form the auditor can re-perform. Check your own capacity and your auditor's expectations before deciding.

What does a review need from finance and IT teams?

Finance and IT each own different inputs, and the review fails if either side is missing. IT must produce complete user listings from each in-scope application, database and operating system, including privileged and service accounts, and must confirm the listings are complete before reviewers see them. Finance and business process owners must confirm which roles are appropriate for each job, identify conflicting access and decide whether each person still needs what they hold. Both teams must act on removals promptly and keep records of who approved what. Assign a named owner from each side and agree on a completeness check before the first cycle starts.

How long does a first user access review cycle usually take?

No supplied source gives a typical duration for a first cycle, so treat any figure you hear as something to verify. The first cycle usually takes longer than later ones because teams must build the in-scope inventory, extract listings from each system, agree reviewer assignments and set up evidence retention. The main drivers are the number of in-scope systems, whether access data is held in one directory or many local stores, how many people must be contacted to confirm access, and how many removals follow. Ask for a written schedule with milestones for inventory, listing extraction, reviewer sign-off and remediation, and confirm it against your fiscal year end.

What should we ask an implementation partner or auditor before signing?

Ask each party to state its role in writing. For an implementation partner, confirm which systems and listings are in scope, who performs each reviewer step, what evidence the work produces and that the partner prepares evidence but does not issue reports or attestations. Ask how the scope and deliverables are fixed before work starts and what happens if an in-scope system is added. For an external auditor, ask which review frequency, population completeness checks and evidence formats they expect, and whether they accept the planned approach. Also ask what the auditor may not do for you, since independence rules limit the services an audit firm can provide. Get both answers in writing before signing.

Which open-source tools can help run user access reviews?

Open-source identity tools can support the workflow, but they do not make the control effective on their own. midPoint documents access certification campaigns in which designated reviewers decide within a set timeframe whether to keep, change or revoke access items such as role assignments, which supports the counter to access accumulation and segregation of duties. Its access certification documentation describes how campaigns are configured. Directory and provisioning tools such as FreeIPA and authentik can supply user and group listings, and authentik's SCIM provider documentation describes how removals are pushed to target applications. Confirm with your team that each in-scope system can export complete listings and that reviewer decisions are retained as evidence.

How DeployOpen scopes and prepares periodic access review evidence

DeployOpen plans and implements self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks, so the review campaigns, directory sources and reporting sit where your financial systems already run. We prepare the systems and evidence for your periodic access reviews, while your management owns the review decisions and an independent auditor tests them.

How we scope

Agree in writing which financially significant applications, databases and operating systems fall inside the access review population.
Confirm which directories, identity sources and privileged groups feed each in-scope system and must appear in the listings.
Define reviewer assignments, review frequency and the timeframe for keep, change or revoke decisions before work starts.

How we build

Configure certification campaigns in the chosen open-source identity tooling so designated reviewers receive access items for their systems.
Build extracts that list every account and role per in-scope system, and reconcile record counts against the source to show completeness.
Test the campaign with sample reviews, including a removal path, and document how revoked access is confirmed as removed in the target system.

How we hand over

Deliver a runbook covering campaign setup, reviewer steps, listing generation, exception handling and evidence retention.
Provide completed review records, reviewer sign-offs, completeness reconciliations and removal tickets organized by review period.
Document the control design and walkthrough material so your management and external auditor can test operating effectiveness.

How we support

Offer ongoing support, upgrades and continuous testing of the review platform as a retainer after the fixed-scope engagement ends.
Revisit the scope when systems, reviewers or directories change so the listings stay complete for each review cycle.
Ask your auditor early which listing format, sample sizes and reviewer evidence they expect, and confirm those details before the first cycle.