User access provisioning under SOX ITGC: evidence

What SOX user access provisioning asks for and why auditors test it

When an auditor testing user access provisioning picks a grant from the access listing for a financially significant application, the first question is usually the same: show the request that authorized it. The control assures that access to those systems is granted only through an authorized request, approved by someone with the right to approve it, before the access is provisioned. Auditors test this because of the risk it addresses. PCAOB AS 2110 names unauthorized access to data as an IT risk to internal control over financial reporting, since it can lead to improper changes to data or the recording of unauthorized or non-existent transactions. A grant without a matching request is the most direct sign that this risk is not being managed.

The control is hard to run well for a few reasons. Requests usually live in ticketing tools, while grants happen in directories, application consoles, database roles and cloud accounts, so the two records drift apart. Approvals are often given by email or chat, which an auditor may not accept as evidence of who approved what. SEC Release 33-8810 states that the aspects of IT general controls relevant to an ICFR evaluation vary with each company's facts and circumstances. That makes scope the first decision: which applications, databases and infrastructure feed financial reporting, and which of them an auditor will expect to see provisioning evidence for.

A practical starting point is to ask the control owner for the population of access grants in a defined period, then ask for the request and approval behind a sample of them. Confirm with your auditor how they plan to select that sample and which systems they consider in scope, since the answer shapes what must be recorded. Where an identity platform such as authentik, FreeIPA, Keycloak or Zitadel is used, confirm which systems it provisions directly and which still require manual grants, because manual paths are where unmatched access tends to appear.

Which systems, teams and third parties fall under provisioning controls

Provisioning controls only need to cover the systems that carry financial reporting risk, so scoping starts with the applications, databases, operating systems and directories that feed the financial statements. The teams who request and approve access, and any third party that holds an account, then determine who must be included in the population an auditor will test.

In-scope applications and data stores

Start with the general ledger, subledgers, consolidation tools and any application that calculates or posts financially significant balances. Each one needs a documented link to a control that addresses a financial reporting risk. Databases behind those applications belong in scope too, because unauthorized access to data can lead to improper changes or unrecorded transactions. Check that the list matches the application inventory and that no system is excluded only because it is hosted separately.

Operating systems and directories

Operating systems that host in-scope applications and the directories that authenticate users to them are part of the provisioning population. An account created in a directory can reach financial data even when the application itself looks locked down. Confirm which directory issues identities for each application, and whether local operating system accounts exist outside that directory.

Teams that request and approve access

Document who may raise a request, who approves it, and who grants it. Business owners usually approve application roles, IT administrators grant them, and HR or managers confirm employment status. Auditors compare the approver with the authority matrix, so the approver must hold the right level of authority for the role requested. Gaps appear when a team grants access directly without a request.

Third parties and managed providers

Consultants, outsourced application support, managed service providers and vendor support staff may hold accounts in financial systems. Their accounts need the same request, approval and grant trail as employee accounts, along with a defined end date. Ask each provider for a list of named individuals and their access, and confirm which provisioning steps the provider performs and which remain with your team.

Documenting excluded systems

SEC guidance says management only needs to evaluate the IT general controls necessary for other controls addressing financial reporting risk, and need not evaluate controls that only affect operational efficiency. A system excluded on that basis should have written reasoning, a risk assessment reference and a review date. Auditors will ask how the exclusion was decided, so keep the rationale with the scoping file.

How to implement a provisioning workflow auditors can trace

The sequence turns access grants into a chain of records: each grant traces back to a request, an independent approval and a closed ticket. The final reconciliation shows that what exists in the systems matches what was authorized.

Define the in-scope access population
Start by listing the financially significant applications, databases, operating systems and directories that the workflow must cover, along with the roles that grant access to them. Management owns this list and should confirm it against the SOX ITGC scope for the period. The output is a scoped system inventory with a named owner for each system, which becomes the population every later step and test refers to.
Build the access matrix per role
For each in-scope system, document which roles exist, what each role permits and which conflicting duties must not be combined. System owners approve the matrix, and the same version is used for every request. The output is an access matrix per role with an approval date and version, so an assessor can compare any grant against the role it was supposed to represent.
Submit a request with justification and named approver
The requester submits a standard access request form that names the person, system, role, business justification and the approver responsible for that system. Free-text emails or chat messages do not meet this step. The output is a request record with a unique identifier, timestamps and the named approver, which is the first document an auditor will sample.
Approve the request independently
An owner of the system or role who is not the requester reviews the request against the access matrix and approves, rejects or sends it back with comments. The workflow should block self-approval and record the approver's identity and decision time. The output is an approved, rejected or returned request record. Confirm with your identity platform whether it can enforce this rule natively or whether a manual check is needed.
Grant access only through the approved request
Administrators or an automated connector create the account or role assignment based solely on the approved request, not on an informal instruction. Where a provisioning connector is used, it should carry the request identifier into the grant so the two can be linked. The output is a granted-access record that references the request. Ask your identity provider how it logs each create, change and delete event and how long those logs are retained.
Record the grant and close the ticket
Once access is granted, the administrator records the completion date, the granted role and the account identifier, then closes the request. Closed tickets should be locked so the history cannot be edited after the fact. The output is a closed request record that shows the full lifecycle from request to grant, which allows an auditor to walk through a sample without relying on memory.
Reconcile grants against approved requests
Periodically, compare the accounts and role assignments that actually exist in each in-scope directory or application with the set of approved requests. Investigate any account with no approval, any approval with no matching grant, and any grant that exceeds the approved role. The output is a reconciliation report with each exception, its owner and its resolution. This report is the evidence that the workflow is complete, not only that it runs when someone remembers to use it.

How a request becomes a grant in identity platforms

The central directory is the system of record for who exists, which groups they belong to and who may administer those objects. In a self-hosted estate, FreeIPA uses 389 Directory Server as a multi-master LDAPv3 directory that stores users, groups, hosts and other network objects. Access control and delegated administration are managed centrally through its web UI and command line tools, so the group memberships an auditor samples usually originate here.

Account creation records: Directory audit logs show when a user or group was created, by which administrator account and when.
Group membership changes: Each add or remove of a user from a group is an event that can be compared with the approved request.
Delegated administration rights: The rules that let help desk or application owners manage certain groups should be exported and reviewed as evidence of who can change access.
Directory snapshots: Periodic exports of users and groups give the auditor a population to test completeness against the request log.

Confirm with your platform team exactly which directory events are retained, for how long, and whether they are shipped to a log store the administrators cannot edit.

How an assessor tests provisioning design and operation

The external auditor tests user access provisioning in two steps under PCAOB AS 2201. First comes a walkthrough, where the auditor follows one access grant from request to approval to activation in the in-scope application, directory or database to confirm the control is designed as management describes it. Then comes testing of operating effectiveness across the whole period. Paragraph 45 of AS 2201 describes the methods the auditor combines: inquiry of personnel, observation of the process, inspection of documentation and re-performance of the control. For provisioning, the most important of these is inspection, because the auditor needs to see who asked for access, who approved it, what was granted and when. Management should walk through the same path before the auditor does and confirm that the ticketing system, identity platform and application logs tell the same story.

For operating effectiveness, the auditor typically selects a sample of access grants made during the period and asks for the approval record behind each one. The record should show a request that describes the access, an approver with authority over that system, and a grant that matches the request in scope and timing. A grant with no matching request or approval is an exception, and the auditor will ask whether the control failed once or whether the population is incomplete. This is why the population itself matters. If grants can be made directly in an application or directory without a ticket, the auditor cannot select from a complete list, so management should confirm that every grant path produces a traceable request.

Sample sizes, the choice of items, and the timing of testing are set by the auditor's judgment, not by management. Interim testing covers part of the year, and the auditor then tests the remaining period through roll-forward procedures or year-end testing. Management should ask the auditor early which populations and sample sizes they expect, and should confirm that approval records are retained in a form that can be produced quickly for any selected item. Ask whether the auditor will rely on system-generated reports, and if so, what evidence shows those reports are complete and accurate. Confirm these points with your auditor and your own environment before the period begins, not during fieldwork.

Evidence that passes a provisioning test

A provisioning test starts with one grant and works backward to an approved request, then forward to proof the grant was made. The artifacts below connect those two directions, so each grant on a financially significant system can be traced end to end. Keep them current throughout the year, not assembled just before fieldwork.

Request tickets with justification

Each access request should record who needs the access, the system and role requested, the business reason, and the start date. Auditors sample grants and ask for the matching ticket, so a request that names only a username or says "same as colleague" will not show the access was justified. Check that the request describes the role actually granted, not a broader one.

Approver authority evidence

An approval only counts if the approver had authority over the system or the business function. Keep a current list of application owners and their delegates, dated and tied to the in-scope applications. Confirm that the person who approved the request is on that list at the time of approval, not only today.

Grant log with timestamps

The directory or application record of the grant, with the timestamp, the account that made the change, and the entitlement added, shows what actually happened. Compare the grant time with the approval time. A grant that precedes approval is an exception an auditor will raise, so confirm your logs capture both events with synchronized clocks.

Connector sync logs

When an identity provider pushes accounts into a target application, the sync log is the record of that automated grant. For example, the authentik SCIM provider runs a full sync every hour and pushes changes to target applications. Retain those logs and confirm which change triggered each grant so automated provisioning can be traced like a manual one.

Role-to-access matrices

A matrix that maps each job role to the entitlements it should hold is the reference auditors use to judge whether a grant was appropriate. Maintain it per in-scope application and version it when roles change. Without it, a grant that matches a ticket can still be inappropriate, and the reviewer has no baseline to test against.

Completeness checks back to requests

Run a periodic comparison of every active grant against the approved requests and the role matrix. Any grant with no matching ticket is a finding to investigate, and the check itself becomes evidence that the population is complete. Record the date, the scope, the person who ran it, and how exceptions were resolved.

What meeting provisioning controls costs in money and effort

This table breaks down the cost of running user access provisioning as a SOX control, showing who is paid for each component, whether it is one-time or recurring, and what moves it up or down. Use it to shape the quote request, since most of the spend sits in integration, approver process and evidence handling rather than software licenses. The main takeaway is that self-hosted open-source tooling removes license fees but not the labor and infrastructure needed to run the control.

Cost component	Who is paid and one-time or recurring	What drives it up or down	What to ask for in a quote
Tooling and licenses	Open-source identity platforms carry no license fee. Infrastructure hosting and any vendor support contracts are paid to your cloud or data center provider and the support vendor. Recurring.	Number of in-scope applications, high availability requirements and whether you buy paid support. Fewer identity sources and simpler topology keep this low.	Itemized list of hosting, storage and any support subscription, with the scope each one covers.
Engineering time to integrate applications	Internal engineers or an implementation partner are paid for connecting each in-scope application to the provisioning source. One-time per application, plus upkeep when apps change.	Whether the application supports SCIM or only manual or file-based onboarding, and how many roles and groups must be mapped. Standard connectors reduce this.	Per-application integration plan, the provisioning method for each, and who maintains connectors after go-live.
Process design and approver training	Internal control owners and sometimes an outside advisor are paid to define request forms, approval matrix and approver duties. One-time, with refresher training recurring.	Number of business owners who approve access, whether approval rules already exist, and how many systems share one approval path. Documented rules shorten design.	Draft approval matrix, role definitions and training materials, plus the expected number of approvers to train.
Ongoing request handling and log retention	Internal IT service desk and access administrators handle tickets. Storage for request, approval and provisioning logs is paid to your infrastructure provider. Recurring.	Joiner, mover and leaver volume, how many requests are manual, and how long your retention period runs. Automated provisioning lowers handling time.	Expected monthly request volume, log retention period and where logs are stored, with confirmation that logs are protected from change.
External review or co-sourced testing	Internal audit, a consultant or a co-source provider is paid to test design and operation before the auditor arrives. Periodic, often before year end.	Number of in-scope systems, whether prior deficiencies exist, and how much testing your internal audit team can perform. Clean prior results reduce scope.	Testing approach, sample sizes used, deliverables, and whether the reviewer will also perform the control as an independent check.
Auditor sampling effort	The external auditor charges fees for selecting and inspecting access requests and approvals. The fee is set by the audit engagement, recurring each year.	Number of provisioning events in the period, reliance on automated controls (which often needs fewer samples), and documentation quality. Complete records shorten testing.	Sampling approach and expected population sizes from the auditor before fieldwork, and documents they will request.
Filer status context (illustrative)	The SEC estimated in 2020 that an issuer newly exempt from the Section 404(b) auditor attestation would save about $210,000 per year on average, including about $110,000 in audit fees (Release 34-88365). This is an attestation savings figure, not a provisioning cost.	Filer status and whether the company qualifies for the exemption. It does not change what the provisioning control must do.	Confirm filer status with counsel before budgeting, since the exemption depends on each company's public float and revenue.

Who owns the control, who prepares evidence and who tests it

Management owns the user access provisioning control. That means the company decides who may receive access to each financially significant application, database and infrastructure component, and a named business owner approves each request before it is granted. Management must also be able to show that the control operates as designed throughout the fiscal year, because the annual ICFR assessment under Section 404 is management's responsibility, not the auditor's. Delegating the decision to a vendor or consultant does not transfer that responsibility.

Approval authority: Define which managers or application owners may approve access to each in-scope system, and keep that list current as roles change.
Access request standard: Require every request to state the system, role, business reason and end date where applicable, so approvers and testers can match grants to requests.
Role design: Own the role catalog and the mapping from job roles to permissions, including conflict rules that the segregation of duties control depends on.
Exception handling: Decide who may approve emergency or out-of-cycle access and how it is reviewed afterward.
Ongoing operation: Staff the control, perform it every time, and retain the approvals.

Check that your approval matrix is written, that named owners exist for every in-scope system, and that the people approving access are not the people who receive it.

Common provisioning gaps and how to close them

Most provisioning failures found in SOX ITGC testing are not exotic. They are direct grants that skip the ticket, approvals that carry no authority check, and records that live outside the system of record. The cards below pair each gap with the closing action management can evidence to an auditor.

Direct grants bypassing tickets

Administrators sometimes add a user to an application role directly in the application, then open a ticket afterward or never. The auditor sees an access record with no matching request, which fails the core test of this control. Close it by restricting role assignment to the provisioning workflow and comparing application role membership against approved tickets each period. Ask whether any local administrator accounts can assign roles without going through the workflow.

Self-approval by the requester's manager

A manager who approves a request for their own team may have no authority over the financial system or the role being granted. Approval becomes a formality rather than a check on whether the access fits the person's duties. Define an approver matrix per application and role owner, and require the business owner of the system to approve high-privilege roles. Test a sample of approvals to confirm each approver held the authority the matrix assigns.

Shared and generic accounts

Shared logins such as a finance team account make it impossible to tie a transaction to one person. Auditors treat unattributable activity as a gap in provisioning, because no authorized request names the individual who used the account. Inventory generic and service accounts in each in-scope application, assign each one a named owner, and retire shared credentials where the application allows. Confirm which accounts the application cannot attribute and document the compensating review for those.

Incomplete application lists in scope

A provisioning control only covers the systems someone remembers to include. Reporting tools, data warehouses, interfaces and end-user computing spreadsheets that feed financial statements often sit outside the list. Build the list from the ICFR scoping documentation, not from the IT asset register alone, and reconcile it against identity directory connections and SSO application assignments. Ask who signed off the list and when it was last compared with the systems that actually produce financial reports.

Sync failures that go unnoticed

Automated provisioning connectors can fail silently, leaving accounts in an application that no longer match the directory. Where an identity provider pushes changes with SCIM, the authentik SCIM provider pushes creations, changes and deletions to target applications and runs a full sync every hour, which narrows the window but does not remove the need to monitor it. Set alerts on failed sync jobs, review error logs on a schedule, and reconcile target accounts against the source directory. Confirm who receives failure alerts and what they must do with them.

Approvals recorded only in chat

Approvals given in email, chat or a phone call are hard to tie to the access granted and easy to dispute later. Auditors need the approval to be retained in a system the company controls, with the requester, approver, role and date visible. Require that every grant reference a ticket or workflow record, and block chat-based approvals from counting as authorization. Ask for a sample of recent grants and trace each one back to a stored approval.

Questions buyers ask about provisioning controls

What does it cost to implement user access provisioning controls for SOX?

No supplied figure sets the cost of provisioning controls, so the answer depends on the scope you agree in writing. Costs fall into three groups: internal staff time to define the access request workflow, approval matrix and evidence standard; the cost of the identity platform, which is software you own or license; and external help to design, configure and document the controls. Costs recur through operating the controls each quarter, reviewing requests and keeping the approval matrix current. Ask any provider for a quote that lists the in-scope applications, the number of identity sources, the number of approval paths and whether integration with each application is included. Ask the external auditor separately what it will need to test.

How long does it take to put provisioning controls in place?

The timeline depends mainly on how many financially significant applications need automated or documented provisioning, how clean the existing identity data is, and how many approval paths the business uses. Duplicate accounts, inconsistent job titles and undocumented application roles add the most time because they must be resolved before access can be matched to approved requests. Integration work for each application also varies, since some systems support automated provisioning through standards such as SCIM and others need manual, documented steps. Ask for a written schedule that separates design, build, parallel running and the period of operating evidence the auditor expects.

What does our team need to provide for a provisioning project?

The organization must supply the decisions and the people who can make them. That includes the owner of each financially significant application, the HR source of truth for joiners, movers and leavers, the list of job roles and the access each role should receive, and the people who approve access requests. Your IT team must provide admin access to the systems in scope, change windows for integration and a named contact for the identity platform. Compliance or internal audit should confirm the evidence the auditor will expect before build starts. Your team keeps ownership of the control design and of each approval decision, even when an implementation partner prepares the systems and documentation.

Can we implement SOX provisioning controls in-house?

Yes, many organizations do this in-house, provided they have people who understand both the financial applications and identity administration. The work that most often needs outside help is designing a control set that maps to what auditors test, configuring the identity platform so that each access grant traces to an approved request, and producing evidence in a form the auditor can re-perform. An internal team can handle those tasks if it has the time and the skills. A co-sourced partner can take on system build or documentation while management keeps the decisions. Only the external auditor issues the attestation, so the choice affects cost and workload, not the audit opinion.

What will the external auditor sample when testing user access provisioning?

Auditors typically select a sample of access grants for in-scope systems and trace each one back to a request that was approved before access was given. They also check that the approver had the authority to grant that access and that the granted access matched what was requested. Under PCAOB AS 2201, operating effectiveness testing combines inquiry, observation, inspection of documentation and re-performance, so expect requests for the workflow records, the approval history and screenshots or exports from the systems. Auditors will also ask how they know the population is complete, which means they will want a list of all access changes in the period, so keep that list reliable.

Does an open-source identity stack satisfy SOX auditors?

No open-source product by itself satisfies an auditor. What satisfies the auditor is a control that works as designed and leaves reliable evidence, and the platform is one part of that. Open-source options such as authentik, which pushes user and group changes to target applications over SCIM 2.0 and deprovisions users who lose access, FreeIPA, which centralizes users and groups with delegated administration, and Keycloak, which provides single sign-on through OpenID Connect and SAML 2.0, can support automated provisioning and central access control. Confirm with your auditor that the platform's logs, approval records and sync reports meet its evidence needs, and confirm each application integration yourself before relying on it.

Should we use single sign-on as part of provisioning controls?

Single sign-on helps by limiting the places where access is granted and removed, so there are fewer local accounts to track. Keycloak can broker logins to existing OpenID Connect or SAML 2.0 identity providers, and Zitadel can sign users in through external providers such as Google, Microsoft Entra ID or Okta, so applications do not need to trust each provider separately. Single sign-on does not replace provisioning, though. Applications that keep local accounts or use their own roles still need approved requests and recorded grants, so you must confirm which applications can be fully federated and which require separate controls.

How DeployOpen prepares provisioning controls and evidence

DeployOpen plans, implements and documents self-hosted open-source identity platforms inside your own cloud accounts, data centers or air-gapped networks. For user access provisioning, that work usually covers the path a request takes: the directory that holds identities and groups, the single sign-on layer, and the connectors that push accounts into financially significant applications. Platforms in this space include authentik, whose SCIM provider creates, changes and deletes users and groups in target applications, FreeIPA, which stores users and groups in a centralized directory with delegated administration, Keycloak for single sign-on and brokered logins, and Zitadel as a central identity broker. DeployOpen configures these components, documents the settings auditors will ask about, and tests the access path for weaknesses such as accounts that bypass the approved workflow.

DeployOpen prepares systems and evidence. It does not issue audit reports, attestations or certifications. Those come only from the independent external auditor, and management still owns the control design, the approval rules and the decision to grant each access. Before work starts, DeployOpen agrees a fixed scope with written deliverables and timelines. Ask for a written list of which applications, directories and connectors are covered, which evidence exports will be produced, and who in your organization signs off each one. Because DeployOpen does not publish a price list, the quote follows from that written scope, so the more precisely you define the in-scope systems up front, the more closely the quote will match the work.

Provisioning controls need upkeep after go-live. Connector changes, new financial applications and identity platform upgrades can each break the link between an approved request and the account that appears in the application. DeployOpen offers ongoing retainers for support, upgrades and continuous testing of the access path, which can cover re-running provisioning tests after changes. Confirm with DeployOpen during scoping whether a retainer is needed, what it covers, and how changes to in-scope systems are reported back to your control owners before the next audit period.

User access provisioning