Of the four ITGC areas, access to programs and data is usually the largest, with the most controls and the most populations to prove. The controls are familiar to any security team. What changes under SOX is the scope, the emphasis on who can change financial data, and the standard of proof for every population.
The question an auditor is answering is narrow: could someone without the right authority change financial data, configuration or programs in a system that feeds the financial statements, and would you know? Every access control they test is a piece of that answer.
This article goes through the controls auditors typically test in this area, what each one needs as evidence, and where teams lose credit. For how access fits with the other ITGC areas, start with our overview of SOX IT general controls.
The controls in this area
Most SOX programs test some version of these, for each in-scope application and the layers beneath it:
User provisioning, with approval.
Timely removal of access on termination.
Periodic user access reviews.
Restriction and review of privileged access.
Segregation of duties within and around financial systems.
Authentication settings.
Restrictions on direct changes to data.
Your auditor will agree the exact set with you, and the layers they apply to, during planning.
Provisioning
New access should be requested, approved by someone with the authority to approve it, and granted as approved. The approval comes before the access, not after.
The auditor's test usually starts from the system, not from your ticket queue. They take the list of accounts created during the period, pull a sample and ask for the approval behind each one. Accounts with no matching request are exceptions.
Two details that matter:
The approver must be appropriate. A manager approving their own report's access to the general ledger is normal. An engineer approving their own admin access is not.
The access granted must match the access approved. A ticket approving read-only access, followed by a grant of a role that can post journal entries, fails the test even though a ticket exists.
Role changes, when someone moves teams, are part of provisioning too. Our article on joiner-mover-leaver processes covers why movers are the case most often missed.
Removal on termination
When someone leaves, their access to in-scope systems should be removed within the timeframe your policy sets. The auditor compares a list of terminated employees and contractors, usually from your HR system, against the dates their accounts were disabled.
Three things make this control hold up:
A defined timeframe. The auditor tests against your policy. If the policy does not set one, the test has no standard, and that is a finding of its own.
Coverage beyond the identity provider. If an in-scope application has local accounts outside single sign-on, disabling the identity provider account is not enough.
No activity after termination. Some auditors check for logins after the termination date. An account disabled late but never used is a weaker exception than one that was used.
Our article on offboarding that removes access the same day covers the mechanics.
Periodic access reviews
A periodic review asks the people who know what access is appropriate to confirm it, and to remove what is not. Under SOX, auditors look hard at three features.
The population. The user list reviewed must be complete and accurate, and you must be able to show how it was produced. This is IPE, and auditors test it. Our article on proving population completeness goes into the methods.
The precision of the review. Reviewing names is not enough. The reviewer needs to see each user's role or permissions, and the review must be detailed enough to catch inappropriate access. A reviewer who approves a list of 200 users in one click is not performing a precise review.
The follow-through. Every access marked for removal needs a record that it was removed, confirmed in the system.
Our article on access reviews that hold up describes the four artifacts a defensible review produces. Under SOX, the same artifacts apply, scoped to financial systems.
Privileged access
Privileged accounts can change configuration, bypass application controls or alter data directly. They include application administrators, database administrators, operating system root or administrator accounts and cloud console administrators.
Auditors want to see that privileged access is limited to people who need it, that the list is reviewed, and that its use is logged. Where the business needs occasional elevated access, a break-glass or temporary elevation process with a request, an approval, a time limit and a review of what was done is far easier to defend than standing admin rights.
Our article on managing privileged access covers the patterns in more depth.
Segregation of duties
Segregation of duties is where SOX access testing differs most from security frameworks. The concern is that one person can carry out an incompatible pair of actions without another person's involvement.
Inside financial applications, the classic conflicts include creating a vendor and approving payment to it, or preparing a journal entry and posting it. Your finance team defines which combinations are incompatible, usually in a conflicts matrix. IT's job is to make sure roles enforce it and that access reviews check for it.
Around financial applications, the concern is IT staff who can both change programs and move them to production, or who have business-user access to financial transactions in addition to their administrative rights.
Where full segregation is not possible, document the conflict, the reason and the compensating control, such as a review of the activity performed by the person holding conflicting access.
Authentication, shared accounts and direct data access
Authentication settings. Auditors check that in-scope applications enforce the authentication your policy requires. If an application relies on single sign-on, show that it is enforced and that local login is disabled or restricted.
Shared and generic accounts. An account used by several people breaks accountability, because no record can say who acted. Eliminate them where you can. Where a shared account is unavoidable, restrict who holds the credentials and log its use.
Service accounts. System-to-system accounts often hold broad rights and no owner. Inventory them, assign an owner and include them in reviews.
Direct data access. Anyone with write access to the production database of a financial application can change data without passing through the application's controls. Limit that access, log it and review the changes made through it.
An evidence checklist
For each in-scope application and layer:
- Not done:
A system-generated list of accounts and roles, with the method used to produce it.
- Not done:
New accounts and role changes in the period, with approvals.
- Not done:
Terminations from HR, matched to account disable dates.
- Not done:
Completed access reviews, with reviewer, date, decisions and removals.
- Not done:
A list of privileged accounts, with the review of that list.
- Not done:
The segregation of duties conflicts matrix and the results of checking roles against it.
- Not done:
Authentication configuration, exported from the system.
The SOX ITGC framework page summarizes how these controls sit alongside change management and computer operations.
How TrustLynce helps
TrustLynce runs user access reviews against account lists pulled directly from the source system, records each reviewer's decision and tracks removals to completion. Evidence collection gathers identity and HR records on a schedule, so terminations can be matched to disable dates without assembling spreadsheets by hand.