How Identity and Access Management Supports SOX IT General Controls

Access provisioning and approval

New access to in-scope applications, databases and infrastructure is requested, approved by an accountable approver and provisioned from a recorded request.

15 U.S.C. 7262, Management assessment of internal controls (Sarbanes-Oxley Act section 404), 15 U.S.C. 7262(a)(1): state the responsibility of management for establishing and maintaining an adequate internal control structure and procedures for financial reporting

15 U.S.C. 7262, Management assessment of internal controls (Sarbanes-Oxley Act section 404), 15 U.S.C. 7262(a)(2): contain an assessment, as of the end of the most recent fiscal year of the issuer, of the effectiveness of the internal control structure and procedures of the issuer for financial reporting

In practice: A new finance analyst asks for access to the general ledger in the access request workflow, the application owner approves it, and the account is created from that recorded request.

Access changes on role change

Access is adjusted when a worker changes role, department or manager, so prior access does not accumulate.

In practice: When an employee moves from accounts payable to treasury, the HR change triggers a recalculation, and the old payables access is removed instead of piling up next to the new access.

Timely access removal on termination

Access is disabled or removed within a defined interval after a worker leaves, for directory, application and privileged accounts.

In practice: HR records a termination and the identity governance platform disables directory, application and administrator accounts, while a reconciliation report flags any account still active afterward.

Periodic user access review

In-scope users and their access are reviewed on a defined cycle by an accountable reviewer, and access found inappropriate is removed and the removal is recorded.

15 U.S.C. 7262, Management assessment of internal controls (Sarbanes-Oxley Act section 404), 15 U.S.C. 7262(a)(2): contain an assessment, as of the end of the most recent fiscal year of the issuer, of the effectiveness of the internal control structure and procedures of the issuer for financial reporting

In practice: On a defined cycle, often quarterly, managers and application owners work through a review campaign for in-scope systems, confirm or revoke each person's access, and export the revocations and completion record.

Segregation of duties

Conflicting access combinations are defined, prevented or detected, and approved exceptions are recorded with a compensating control.

In practice: A rule set built with the process owner stops one person from both creating vendors and approving payments, and a scheduled scan reports any conflicts that exist, with approved exceptions noted.

Privileged and administrative access

Administrative and other privileged access to in-scope systems is limited, approved, separated from ordinary accounts and used only when needed.

In practice: Administrators use a separate admin account for system work, elevate only when a task needs it, and the shared privileged passwords sit in a vault with the membership of admin groups reviewed regularly.

Service, system and shared account governance

Non-human accounts have a named owner, a documented purpose, controlled credentials and a periodic review.

In practice: Every service account has a named owner and a stated purpose, its password is rotated from a vault, and the account appears in the same review campaigns as regular user accounts.

Authentication and password settings

In-scope systems enforce authentication settings set by policy, including password length, lockout and the handling of default and shared credentials.

In practice: Password length and lockout settings are set once in the central directory, applications that use single sign-on rely on those settings instead of their own, and local accounts and default passwords are found and removed.

Multi-factor authentication for remote and privileged access

Remote access and privileged access to in-scope systems require more than one authentication factor.

In practice: Anyone signing in from outside the network, and every administrator, must complete a second factor; a registration report lists who is enrolled and any documented exclusions.

Dormant and inactive accounts

Accounts that have not been used for a defined period are reviewed and disabled or removed.

In practice: A last-sign-in report across the directory and applications lists accounts unused beyond a set number of days, and the owner either confirms the account is needed or it is disabled.

Emergency and break-glass access

Emergency access to in-scope systems is time-limited, approved, logged and reviewed after use.

In practice: Emergency accounts are checked out with an approval, expire after a short window, and the session record is reviewed by a second person once the incident is over.

Separation of development, test and production access

The same person does not hold unrestricted access to develop, approve and move a change into production.

In practice: Roles are designed so the developer who writes a change is not the same person who approves it or deploys it to production, and a conflict rule flags anyone holding all three.

Privileged activity logging and review

Privileged activity on in-scope systems is logged, the logs are protected from alteration by the privileged user, and a person independent of the user reviews exceptions.

In practice: The security team reviews privileged session activity independently of the administrators; identity tooling records elevations and session recordings and sends those events to the monitoring platform.

Completeness and accuracy of user and entitlement listings

The user and access listings used for reviews and testing are complete and accurate for the systems in scope.

In practice: The control owner defines the listings; identity matches accounts to people, compares them with each target system's own list, and records how each listing was pulled.

Direct database and back-end data access

Access that bypasses the application, such as direct database or file-level access, is limited, approved and monitored.

In practice: Database administrator rights are requested and approved like any other access, the credentials sit in a vault, and those direct-access entitlements are included in the periodic review.

Third-party and contractor access

Access held by contractors, vendors and other non-employees is sponsored, time-bound and reviewed.

In practice: Each contractor account has a named internal sponsor and an end date, and contractors appear in the review campaigns so the sponsor confirms who still needs access.

Restricted access to move changes into production

Only authorized personnel and service identities can deploy or migrate changes to production systems.

In practice: The change management owner controls releases; identity reviews which people and pipeline service accounts hold production deployment rights and grants elevated access just in time.

Change request, testing and approval workflow

Changes follow a documented request, test and approval process before release.

Job scheduling and batch processing

Scheduled jobs and batch processes run as authorized and exceptions are followed up.

Backup and recovery

Data and systems are backed up and restoration is tested.