How to Automate SOX User Access Reviews in 7 Steps

Consider a finance team that has finished its quarterly access review. Managers have recorded their decisions, and IT has opened the resulting removal tickets. Yet a contractor still holds the payment approval permission that a reviewer rejected. The review record shows the decision; the finance system still needs the change.

To automate SOX user access reviews, connect the applications in scope, validate their access data, assign informed reviewers, and carry their decisions through to verified changes and supporting evidence. The following steps explain how to put those capabilities to work while preserving the judgment and accountability the control requires. Apply the workflow to one representative application first, then use the results to prepare for a wider rollout.

1. Define SOX Scope Before Configuring the Review

The application inventory provides a starting point for scoping, but it does not explain which access could affect financial reporting. Finance, the SOX control owner, and application owners need to establish that connection together. An enterprise resource planning application may belong in scope, along with relevant database administration, identity infrastructure, or other systems through which someone could alter financial information. For each system, document the financial-reporting risk and the user access control rules intended to address it. Use those rules to identify the permissions reviewers need to examine.

The contractor may still need the finance application to reconcile invoices even after responsibility for approving payments has ended. The review therefore needs a decision about that specific permission. Scope the other accounts with the same attention to what their access allows, including employee, contractor, privileged, and relevant service or shared accounts. Assign non-human accounts to owners who can explain their purpose and evaluate their permissions.

Before configuring the campaign in Lumos, establish the reviewer responsibilities, review frequency, decision and remediation deadlines, and exception process. Agree on the evidence the workflow must retain, including the source population, decisions, reasons where required, and proof of access changes. The frequency should follow the documented control design and risk assessment; a quarterly schedule is one possible design. Record exclusions and their rationale, and resolve technical coverage gaps before treating the campaign as ready.

Periodic reviews should also remain connected to departure and job-change processes. A contractor’s access that should end when the engagement ends belongs in the departure workflow. The next review can detect a missed change, but it should not become the planned removal date.

2. Connect Systems and Validate the Access Population

With the scope defined, the next step is to gather the account and permission records reviewers need to evaluate access. Those records may be spread across applications, directories, and legacy systems, with each source showing only part of the picture. Bringing them together and resolving gaps before launch gives reviewers a more reliable basis for deciding which access to retain or remove.

Establish What Each Connection Can See

The review population is the set of accounts and permissions the control requires reviewers to examine. Building it involves reconciling records across applications, directories, and other identity sources. Lumos supports application connectors, directory connections, database connections, and custom integrations, giving teams several ways to bring that data into a review. For each connection, establish which accounts and entitlements—the specific permissions granted to an identity—it retrieves, how often the data refreshes, and which access changes it supports.

An identity provider’s application assignment may reveal that the contractor can enter the finance application without revealing the payment approval role held inside it. Local accounts, privileged roles, and inherited permissions can require additional data from the application itself. Match those records using stable identifiers wherever possible, since names and email addresses can change. Decide how the review will handle access changes that occur after the initial extraction so reviewers understand the period their decisions cover.

Reconcile the Population Before Launch

Suppose the source application contains 1,240 accounts, while the proposed review contains 1,197. That 43-account difference needs an explanation before the campaign launches. Matching totals would not settle the matter either: different accounts or missing permissions could still produce the same count. Compare identifiers and relevant entitlements, and preserve the extraction time, filters, and reconciliation results. An account that fails to match an employee record should remain visible for investigation because it may belong to a contractor, a service, or someone who has left.

The reliability of that population matters when the review becomes audit evidence. PCAOB AS 1105 calls for auditors using company-produced information to test its accuracy and completeness, or the controls over those attributes, and evaluate whether it is sufficiently precise and detailed. Documenting how source records become review items helps the team explain the information it provides.

Include Legacy Applications Through Validated Imports

For applications without a suitable direct connection, CSV imports allow Lumos to ingest records using field mapping and validation. External scripts or workflow tools can schedule imports, while the team preserves the original exports and documents transformations. A file-based connection reflects the data available at its last import, so the review plan needs to account for that delay.

An imported permission record also needs a defined removal route. Where the integration cannot make the required change, an administrator must receive the task and return evidence of its completion.

3. Give Reviewers the Context to Make Access Decisions

A finance manager and an application owner bring different knowledge to the contractor’s payment approval review. The manager may know that the contractor’s current assignment no longer includes approving payments, while the application owner understands which role grants that authority. A technical identifier alone may communicate little to the manager. Pair it with a plain-language description of what the permission allows, retaining the identifier so the decision remains traceable to the source system. Where both perspectives are needed, establish how the reviewers will exchange and record that information.

Once the population and responsibilities are clear, Lumos can assign reviews to the appropriate owners and send reminders. Configure due dates, notifications, and reassignment procedures around the people who will actually perform the work. An absent manager or a change in application ownership should have a defined resolution path, and the control should address potential self-review. These arrangements keep an administrative interruption from becoming an unresolved access decision.

Reviewers also need criteria they can apply consistently. For the contractor, that means evaluating the permission against the current assignment and explaining why payment approval access should be removed or retained. Other decisions may require checking employment status, privileged access, or conflicting permissions under the organization’s policy. Specify when a rationale is required, especially for exceptions and decisions that depart from a recommendation, and make clear whether reviewers are evaluating whole accounts or individual entitlements.

An unanswered review needs escalation to an accountable owner. The campaign deadline should not turn silence into approval.

4. Use AI Insights to Support Informed Access Decisions

A list of permissions becomes more useful when reviewers can see what deserves attention and why. In Lumos, Albus supplies Accept, Reject, or Review recommendations with supporting insights, drawing on information such as employment status, activity, role alignment, and access policies. The Review recommendation identifies cases that need additional information and a reviewer’s determination. That context can help reviewers investigate the access in front of them without reconstructing every relevant detail themselves.

The control owner should define how reviewers evaluate those recommendations and authorize resulting access changes. Any automated decision rules need separate documentation and confirmation that the configured workflow supports them. Organizational policy establishes what the team permits; implementation determines what the system can execute and how it handles exceptions.

Examine the Business Reason Behind an Insight

Low activity can warrant investigation without settling whether access is appropriate. An employee might use a financial consolidation permission only during the annual close, making recent inactivity consistent with a legitimate responsibility. The reviewer needs that context before deciding whether to retain the permission or require a new request when it is next needed. Missing activity data could also reflect a collection problem, while an outdated department record could distort the assessment of role alignment. When a decision depends on those signals, resolve the uncertainty and record the business justification.

In permission-based reviews, Albus can surface segregation-of-duties and overprivileged insights. Those capabilities depend on the relevant entitlement data and policies being available. For the contractor’s review, the useful question is whether the payment approval permission still fits the assignment and any applicable access rules. A recommendation becomes actionable when the reviewer can connect its rationale to those criteria.

5. Remove Rejected Access and Verify the Change

When the reviewer rejects the contractor’s payment approval permission, the decision needs a removal route that matches how the application grants access. Lumos can automate revocation and track remediation through IT service management workflows. The available route depends on the integration and the specific change, so confirm those capabilities during setup. A connection that retrieves a role may not support removing it, and the remediation plan must identify who handles that case.

Confirm the Result in the Target Application

For an automated removal, define what constitutes successful execution and how the team will investigate failures. A useful verification approach is to retrieve the updated permissions from the target application and confirm that the rejected role is absent, including through relevant group memberships. In the contractor’s case, removing a direct assignment could leave payment approval access available through a group. The check should cover the access paths relevant to the decision and identify provisioning rules that could grant the permission again. Validate the chosen verification method for each application as part of the pilot.

Timing needs the same precision. Record when the reviewer rejected the access, when the target system removed it, and when the team verified the result. A permission rejected on Monday, removed on Tuesday, and checked on Wednesday has three distinct timestamps. If the implementation time is unavailable, report the verification time without treating it as the exact time access ended.

Complete Manual Remediation and Manage Exceptions

Applications requiring administrator intervention can use Lumos’s manual task or IT service management integration options. Give the task an owner and a deadline, then require evidence of the resulting change. That might include an updated access record or an application audit event that identifies the removed permission and the affected account. A closed ticket is useful only to the extent that its contents establish what happened.

Some access may need to remain temporarily under an approved exception. Record the reason, authorizing owner, expiration date, and any compensating controls, then schedule follow-up before the exception expires. Failed removals and expired exceptions should remain visible as unresolved work rather than disappearing into a completed campaign.

6. Assemble Evidence That Explains the Review

Because evidence requirements were established during setup, this stage should bring together records already generated by the workflow. Another person should be able to follow the contractor’s payment approval permission from the original access record to the reviewer’s decision and the verified removal. The same record should explain a retained permission or an approved exception. Missing links reveal where the process needs additional documentation before the cycle can be closed.

‍

Lumos user access review software provides reports that help teams document their campaigns. Examine an actual export during the pilot and compare it with the requirements above, adding supporting records where the control needs more detail. If AI insights informed decisions, the auditor-report setting can include those insights when enabled. Preserve the reviewer’s determination and any explanation needed to understand a departure from the recommendation.

Evidence also needs protection against inappropriate access or alteration and retention under the organization’s applicable policy. An early walkthrough with the internal assurance team can expose gaps in the package, while auditors remain responsible for deciding whether the evidence is sufficient for their procedures.

7. Evaluate the Pilot and Expand Review Coverage

The pilot should test the entire workflow on the representative application selected at the outset. Compare the imported population with the source, inspect what reviewers see, and follow decisions through to the evidence export. Controlled test cases should cover a successful removal, a failed or unsupported change, reassignment, and an approved exception where those paths are relevant. Use test arrangements that protect necessary business access.

An internal assurance reviewer can then reconstruct a decision from the resulting records. If the reviewer cannot identify the original permission, understand the decision, or verify its resolution, the team has a specific gap to address before expanding coverage. Track the time and effort the pilot requires alongside the quality of its results. The following measures provide a practical starting point for reporting from the review and remediation records.

‍

Define the units and reporting cutoff consistently, especially when some campaigns review accounts and others review individual permissions. Track overdue decisions, failed changes, and aging exceptions alongside completion rates. The timing measures should retain the distinction between access ending and the team confirming that it ended.

Design Subsequent Cycles Around the Approved Control

After the pilot establishes a reliable process, consider how subsequent reviews can reduce repetitive work. Delta reviews in Lumos focus attention on access that has changed since a previous cycle. Their use should follow the approved control design and preserve any broader periodic coverage that design requires. A narrower campaign needs a documented basis for what it includes.

As the program expands, document the configuration and review material changes to mappings, connectors, decision rules, and reviewer assignments. Repeat the checks that those changes could affect so the next campaign retains the coverage and reliability demonstrated in the pilot.

Automate Your Next SOX Access Review with Lumos

Sun Country Airlines offers a practical example of the administrative work automation can remove. In its published Lumos case study, the airline reported saving approximately 50 hours per quarter while reviewing 13 business-critical applications. Its previous process involved screenshots, spreadsheet entry, emailed confirmations, removal tickets, and additional screenshots to verify changes. The team used Lumos to connect data gathering, reviewer assignments, remediation, and reporting within its access review process.

For teams improving user access management, the next SOX review offers a practical place to start. Bring an application list, a representative access export, and the current control description to identify where automation can support the process. Those materials make it possible to examine the integration coverage, reviewer context, removal options, and evidence the actual workflow needs. A focused walkthrough can show where automation will take over recurring work and where an owner still needs to resolve a decision.

Book a Lumos demo to explore that workflow using the requirements of your next SOX access review.

‍