SOX privileged access management: requirements and evidence

What privileged access management means for SOX ITGC

For SOX purposes, privileged access management means controlling who can act with administrator, superuser, root or database owner rights on financially significant systems, and making sure every such action is visible and reviewed. A Section 404 test asks whether a small set of powerful accounts could change financial data or configurations without anyone noticing, and whether management can show that they could not. The control is not only about having fewer administrators. It requires a defined list of privileged roles, limits on who holds them, and evidence that privileged activity is captured and examined by someone other than the person performing it.

The risk is that privileged users can sit below the application's own controls. An administrator who can write directly to a database, edit a configuration file or change a service's permissions may alter balances, bypass an approval workflow or switch off logging, and the application may show nothing wrong. That is why auditors look at the layers beneath the application: operating system, database, directory, cloud console and deployment pipeline. The control is hard in practice for four reasons: shared accounts that several people use under one name, service accounts whose credentials rarely rotate, privileged access in cloud and database layers that teams forget to inventory, and privileged activity that is logged but never reviewed. Confirm with your auditor which of these layers they consider in scope for your systems before you design the control.

Within the access to programs and data area, this topic covers the privileged accounts themselves, how they are granted and restricted, how shared and service credentials are controlled, and how privileged activity is logged and reviewed. It sits next to user access provisioning, access removal, periodic reviews and direct database access, which address the same accounts from different angles. Start by asking your team to produce a complete inventory of privileged accounts across every in-scope layer, including accounts that exist only for vendors, automation or emergency use. An incomplete inventory is the most common reason a privileged access design fails testing.

Which privileged accounts and systems are in SOX privileged access scope

Privileged access scope starts with the financial systems and the layers beneath them, then narrows to the accounts that can change financial data or the controls over it. Management evaluates only the IT general controls needed for reliable operation of controls that address financial reporting risks, so each layer below should be tied to a specific reporting risk.

Operating system root and administrator accounts

Root and local or domain administrator accounts on the servers that host in-scope applications and databases are usually in scope, because they can replace files, change configuration or bypass application logic. Confirm which hosts run financially significant processing, then list every account that can log in with elevated rights on each one, including emergency and vendor accounts. Check whether any administrator can change application binaries or data files without leaving a trace.

Application superusers and built-in administrators

Superuser roles inside financial applications often bypass approval workflows, reopen closed periods or edit master data. Scope them by what they can do to ledgers, master data and configuration, not by their job title. Ask for a list of every role with those capabilities and the people or service identities assigned to it.

Database owner and DBA accounts

Database owner, DBA and schema owner accounts can change financial tables directly, often outside application controls. They are usually in scope for any database that stores financially significant data. Confirm which accounts hold these rights and whether their direct updates are logged and reviewed. Direct changes are covered in more detail under Direct data and database access.

Cloud, hypervisor and directory administrators

Cloud tenant owners, virtualization administrators and directory administrators can create, copy or modify the servers and identities that financial systems depend on. An administrator of the hypervisor or directory can often reach every system beneath it. Map which of these platforms host in-scope systems, and confirm which administrator roles can alter those hosts or the identities that authenticate to them.

Shared, break-glass and service accounts

Shared administrator accounts, emergency break-glass accounts and service accounts that run batch jobs or interfaces often have standing rights and weak ownership. Auditors commonly ask who can use each one, how its password is controlled and how its use is tied to an individual or a ticket. Build an inventory of these accounts with a named owner for each, and confirm which ones run jobs that post to the ledger.

Scope by ledger and configuration impact

A platform enters SOX scope when its data feeds financial reporting or when the controls it operates support reporting risks. A privileged role is in scope when it can alter ledgers, master data or configurations that affect those reports, even if the platform itself looks like an operations tool. Document this decision for each platform so the scope can be defended to the external auditor.

Why weak privileged access limits how far auditors can rely on automated controls

Privileged access sits underneath almost every automated control an auditor might want to rely on. If an administrator can change a configured approval threshold, edit a journal posting rule or alter a report that feeds a reconciliation, the automated control is only as trustworthy as the people who can touch it. PCAOB AS 2110, in paragraph B4, warns that IT personnel who gain access privileges beyond what their duties require can break down segregation of duties. For a finance application, that means a developer, an infrastructure engineer or a database owner who can both change code or data and post or approve transactions has defeated a control that management may believe is working.

PCAOB AS 2201 connects this directly to audit effort. Paragraph B33 lists access controls among the elements of the IT control environment that determine how long an auditor can rely on a benchmark of an automated control, meaning a configuration the auditor has already tested and can assume is unchanged between tests. Paragraph 47 treats reliance on IT general controls as a risk factor for the control itself, and states that an automated control is generally lower risk when the relevant ITGCs are effective. Privileged access is one of the ITGCs that feeds that judgment. Before the audit starts, confirm with your external auditor which privileged roles they consider relevant to each in-scope application and database, and ask how long a benchmark can be relied on given the current access design.

When privileged access is weak, the auditor has fewer options. They may test more transactions manually, reduce reliance on the automated control, or extend testing to periods that would otherwise be covered by a single benchmark. Each option adds sample sizes, walkthroughs and evidence requests across the company, not only within IT. The practical lever is to document the privileged roles, show who can use them, and show that their activity is logged and reviewed before the auditor selects samples. Management owns that position, and a fixed-scope review by an implementation partner can help prepare the logs, role listings and review evidence, but only the independent auditor can conclude on the control.

How an assessor tests privileged access management

This table sets out how management testers and the external auditor approach privileged access design and operating effectiveness, the evidence each step requests and the findings that appear most often. Read it as a checklist for preparing evidence before fieldwork starts. Sample sizes are set by the auditor, so confirm them during planning rather than assuming a number.

Test area	What the assessor does	Evidence requested	Common findings
Design: role definition	Walks through how privileged roles on each financial system, database and cloud console are defined and which duties justify them	Role catalog, role-to-permission mapping, documented approval criteria	Privileged roles granted broadly by default or defined without a documented business purpose
Design: approval and grant	Traces how a request for privileged access is submitted, approved by an appropriate owner and provisioned	Request tickets, approver identity, provisioning records for the sampled grants	Approvals given by the requester's own manager without a second review, or granted before approval is recorded
Design: revocation	Walks through how privileged access is removed when a role changes or a person leaves	Termination or transfer triggers, revocation tickets, system removal timestamps	Privileged rights left in place after a transfer because no one owns the cleanup step
Operating: privileged assignments	Samples current privileged role holders and compares them with approved requests and job duties	Current privileged user listings from each layer, matched to approvals	Users holding administrator or database owner rights whose duties do not need them
Operating: shared and service accounts	Checks that each shared or service account has a named owner and that each use is tied to a ticket or change record	Account inventory with owners, password vault check-out logs, linked tickets for sampled sessions	Shared administrator accounts with no individual accountability and service accounts with no named owner
Operating: privileged activity logs	Selects sampled privileged sessions and traces them to logs, then asks how logs are reviewed	Log extracts for sampled periods, reviewer sign-off, alerting rules and their settings	Logs generated and retained but never reviewed, or reviewed without evidence of who reviewed them
Operating: periodic privileged reviews	Checks that privileged access reviews happened on schedule, covered all layers and led to documented follow-up	Review campaign records, reviewer decisions, evidence of removals or changes made after review	Reviews that cover application roles but skip databases, operating system root, or cloud consoles, and reviews completed late
Completeness of populations	Confirms the privileged user listing is complete before sampling from it	System-generated listings with parameters, reconciliation to the directory and to the access request log	Listings exported from one layer only, so privileged accounts in other layers are never tested

How to implement privileged access management for SOX ITGC, step by step

This sequence takes privileged access from an unknown population of accounts to a documented, reviewed and logged process that an external auditor can walk through and test for the full period under review.

Inventory privileged roles and accounts
Pull a complete list of administrator, superuser, database owner and root-level accounts across in-scope applications, databases, operating systems, cloud consoles and directories. Include shared accounts, service accounts and break-glass accounts, and record the system owner for each. Compare the list against directory exports and vendor role tables so nothing is missed. The output is a privileged account inventory with a stated completeness check, which the auditor can use as the population for testing.
Define privileged roles and justify each one
Decide which roles count as privileged for each in-scope system, then document the business duty that requires each role. Compare role membership with job descriptions and the segregation of duties matrix, and remove access that the duty does not need. This step matters because AS 2110 warns that access beyond what duties require can break segregation of duties. The output is an approved privileged role definition with a named justification per role.
Set an approval workflow with separate requester and approver
Route every grant, change or elevation of privileged access through a ticketed request that names the requester, the business reason, the system, the role and an approver who is not the requester and does not administer the system alone. Decide whether emergency access follows a different path and what evidence it must leave afterwards. The output is a written procedure and a sample of tickets showing the approval happened before the access was granted.
Assign named owners to shared and service accounts
Map every shared and service account to a named owner who is accountable for its use, password or credential rotation, and removal. Where a person must check out a shared credential, use a controlled checkout that records who took it, when and for what ticket, and that rotates the secret on return. Where a service account runs automation, document the job it serves and restrict interactive logon. The output is an account register showing owner, purpose and checkout records.
Enable logging of privileged activity to a protected location
Turn on audit logging for privileged actions in each in-scope system, and send the logs to a location that the administrators cannot edit or delete. Some applications write their own audit files, such as the admin_audit app in Nextcloud, which logs to audit.log in the data directory or to a path set with logfile_audit. Secrets management platforms such as OpenBao keep detailed JSON audit devices with sensitive values hashed. Confirm each product's logging options with the vendor and test that a sample privileged action appears in the log. The output is a logging configuration record and a test event trail.
Run periodic privileged access reviews with documented outcomes
Assign reviewers who know the systems and the duties, and have them confirm, change or revoke each privileged assignment within a set timeframe that management defines and documents. Identity governance tools such as midPoint support certification campaigns that record each reviewer decision, which helps counter access accumulation. Follow up on every revocation to confirm the access was actually removed. The output is signed review records, a list of exceptions and evidence that each revocation was completed.
Walk through the process before the test period
Before the audit period starts, run a dry-run walkthrough that follows one privileged grant, one shared account checkout, one log review and one review campaign from start to finish. Check that the evidence exists, that dates and approvers line up and that the logs cannot be altered by the people they record. Fix gaps in the design before they become operating deficiencies. The output is a walkthrough memo with the samples used, the findings and the owner of each correction.

What privileged access evidence passes an auditor and how to keep it current

Auditors test privileged access by asking who can do what in each in-scope system, who approved it, and whether the activity was watched. The cards below cover the six artifacts that answer those questions and how to keep each one current between audit cycles, rather than rebuilding them at year end.

Current privileged role and account inventory

This is the list of administrator, superuser, database owner and root-equivalent accounts for each in-scope application, database, operating system and directory, with a named owner for every entry. Auditors use it as the population for every other privileged test, so an incomplete list weakens all of them. Keep it current by exporting role assignments on a schedule and placing the role definitions under change control. Check that shared and service accounts appear on the list too, not only named individuals.

Approval records for privileged grants

Each new privileged grant or change to a privileged role should trace to a request that states the business need, names the approver and shows the approval date. Auditors compare grant records against the inventory to find accounts that were granted without a request. Make the request tool the only route to privileged roles, and retain approvals alongside the ticket. The auditor's first question is whether every privileged account has an approval that predates its first use.

Checkout and session logs for shared and service accounts

Shared and service accounts cannot be tied to one person by identity alone, so auditors expect a checkout record showing who used the credential, when, and under which ticket. A password vault or session broker can produce this record if checkout is required and the reason field is mandatory. Review checkouts that have no matching ticket. Confirm with each platform vendor which events the tool records for shared credentials, because capabilities differ.

Privileged activity logs with protection and retention

Logs of privileged actions prove that administrators were visible in the system. Auditors look for three things: that the logs capture privileged events, that the logs cannot be edited by the people they monitor, and that they are kept for the period the organization's retention policy sets. Nextcloud's admin_audit app writes extra event detail to a dedicated audit log file, and OpenBao's audit devices record every API request and response with most sensitive values hashed. Confirm the log destination, access restrictions and retention setting for each system during setup.

Periodic privileged access review records

A periodic review shows that someone independent of the grant reviewed each privileged account and decided whether it should stay. The record needs the reviewer's name, the date, the population reviewed, the decision for each item and proof that removals were carried out. Access certification campaigns in midPoint give designated reviewers a set timeframe to keep, change or revoke role assignments, which produces a dated decision trail. Auditors also check that the population used for the review was complete, so reconcile the review list with the inventory before sign-off.

Revocation records for leavers and role changes

When a privileged administrator leaves or moves to a role that no longer needs the access, auditors expect the privilege to be removed promptly and the removal to be documented. Compare HR termination and transfer lists against privileged account records each period, and keep the revocation ticket with a timestamp showing the change took effect. Secret detection in CI/CD pipelines can also surface hard-coded privileged credentials that outlive their owner. Ask the organization to define how quickly revocation must occur and to test a sample each quarter.

What meeting the privileged access requirement costs and what drives it

This table compares the main cost components of controlling privileged access to financial systems, showing who is paid, whether each cost is one-time or recurring, and what pushes it up or down. Use it to build a written scope and to ask vendors and your auditor for the figures you must confirm, since no price or duration is stated here.

Cost component	Who is paid or who spends effort	One-time or recurring	What drives it up	What keeps it down
Licensed privileged access or vaulting tools	Software vendor, or none for self-hosted open source	Recurring if licensed, often per user, node or session	Number of platforms, databases and cloud accounts brought under vaulting	Choose a self-hosted option where the license model allows it, and confirm feature coverage before buying
Engineering time to build role models and approval workflows	Internal platform team or implementation partner under a written scope	One-time, with later change work	Many overlapping admin roles, unclear owners, manual approval paths	Design a small set of privileged roles mapped to duties before configuring anything
Shared and service account remediation	Internal application owners and engineers	One-time, then recurring for new accounts	Large numbers of shared logins and undocumented service accounts	Retire shared accounts, move services to named identities or managed secrets
Privileged activity logging and log storage	Infrastructure team or storage provider	Recurring, growing with activity volume	High request volume, verbose logging, long retention periods set by policy	Log only what reviewers use, set retention with the auditor, export logs automatically
Periodic review of privileged access	Access owners and reviewers, who are often managers	Recurring each review cycle	Large privileged populations, inaccurate role listings, reviewers without context	Automate listings from the source system and set a review timeframe reviewers can meet
Log review and follow-up of privileged activity	Security or finance IT staff	Recurring	Unfiltered logs, no alerting rules, unclear escalation owners	Define which privileged events need review and automate exports for sampling
External testing or readiness review	Independent testers or consultants, under written scope	Usually one-time per engagement, repeated on change	Broad scope, unclear system boundaries, unresolved findings from earlier tests	Agree scope and evidence list in writing before testing starts
Auditor sampling and walkthroughs	External auditor, billed under the audit engagement	Recurring each audit cycle	Number of in-scope systems, manual evidence, exceptions that need follow-up	Provide system-generated evidence with clear date ranges and populations

Which open-source tools produce privileged access evidence, and their license caveats

Several self-hosted open-source platforms can generate logs and reports that auditors use to test privileged access. Each produces a different kind of evidence, and each carries license terms that affect how it can be deployed and modified. None of them decides whether access is appropriate.

OpenBao audit devices for secret access

OpenBao (MPL-2.0) audit devices write a detailed JSON log of every API request and response, including errors. Most sensitive values are hashed with HMAC-SHA256, so the log can show which service account or administrator read or changed a secret without exposing the secret itself. Check that an audit device is enabled before the period under test begins, that logs are shipped to storage the privileged users cannot edit, and that the HMAC-hashed fields still let reviewers match entries to tickets.

Nextcloud admin audit logging

The admin_audit app in Nextcloud (AGPL-3.0-only) records additional event information about administrative actions to audit.log in the data directory, or to a path set with logfile_audit. For SOX purposes, this supports evidence of changes to administrator roles, group membership and sharing settings on systems that hold financial documents. Confirm the app is installed and enabled in your version, decide where the log is written, and restrict who can read or alter that file. AGPL terms may apply if you modify the server and make it available to users over a network.

GitLab secret detection reports

Pipeline secret detection in GitLab Community Edition (MIT) scans files committed and pushed to a repository inside a CI/CD job and writes findings to a gl-secret-detection-report.json job artifact. The feature is available in every tier. It helps identify service credentials, tokens and keys that were committed to code, which is a common route to unmanaged privileged access. The report shows detection, not remediation, so keep records of how each finding was rotated or revoked and confirm the scanner's coverage for your languages and file types.

midPoint access certification campaigns

midPoint (EUPL-1.2 or later) runs access certification campaigns in which designated reviewers decide within a set timeframe whether to keep, change or revoke access items such as role assignments. This creates a dated record of privileged role recertification, which supports segregation of duties and counters access accumulation. Confirm the campaign scope covers the administrator and database owner roles in your financial systems, that reviewers are not reviewing their own access, and that revocations are actually applied. EUPL obligations apply when you distribute modified versions.

Who owns privileged access controls and who can help

Your organization owns privileged access controls from design through operation. The control owner, usually a finance systems or IT controls lead, is accountable for defining which accounts count as privileged, who may hold them, and how their use is reviewed. System owners for each financially significant application and database approve privileged grants for their systems, while security and IT administrators perform the changes and must work within those approvals. Reviewers who certify access on a set schedule decide whether each privileged assignment should stay, change or be removed.

Management must keep the decisions, the reviews and the signed records. That means approval tickets, the privileged account inventory, review sign-offs with dates and reviewer names, and documented follow-up on any revoked access.

Control owner: keeps the policy, the inventory of privileged and shared accounts, and the list of who may hold each role.
System owners: approve every privileged grant and removal for their applications and databases.
Administrators: perform privileged work only under a recorded request and keep their own activity traceable.
Reviewers: certify privileged access on a defined schedule and document keep, change or revoke decisions.
Management records: retain signed reviews and logs so the auditor can test them later.

Confirm that each reviewer has enough knowledge of the system to make a meaningful decision, and that someone other than the administrator reviews the administrator's own access.

Privileged access management questions buyers ask before hiring help

How much effort does privileged access management take for SOX ITGC?

The effort depends mostly on how many financially significant systems hold privileged accounts, how many of those accounts are shared or service accounts, and whether privileged activity is already logged somewhere an auditor can sample. A single ERP with a small admin group is a very different job from a estate of databases, operating systems and directories where administrators log in through shared credentials. No duration or cost is quoted here. Ask for an inventory of in-scope systems and privileged accounts before you compare proposals, because that inventory sets most of the work.

Number of in-scope applications, databases and operating systems
Count of shared, generic and service accounts with elevated rights
Whether privileged sessions and changes are already logged and retained

Can our team run privileged access management in-house with open-source tools?

Often yes, if you have engineers who can operate the tools and an owner who can run the recurring reviews. Open-source components can produce useful evidence. For example, Nextcloud's admin_audit app writes additional event information to audit.log, OpenBao's audit devices keep a detailed JSON log of every API request and response, and midPoint's access certification campaigns let designated reviewers keep, change or revoke role assignments within a set timeframe. Confirm with each vendor what its logs capture in your version and environment before you rely on them. Your team still owns the control design, the reviewer assignments and the evidence an auditor will sample.

How long does privileged access management implementation usually take?

No duration is quoted here. The written scope sets the timeline, and the main variables are the number of in-scope systems, how much privileged access is shared or undocumented, whether logging must be added to systems that lack it, and how quickly your role owners and reviewers can respond. Most engagements are fixed-scope, so deliverables and dates are agreed in writing before work starts. Ask any partner to show which milestones depend on your staff and which depend on their work.

What does privileged access management require from our organization?

Expect to provide system access, named role owners and reviewer time. Implementation needs administrative access to the in-scope systems so configurations, account lists and logs can be examined. Each privileged role needs an accountable owner who can say why it exists and who should hold it. Reviewers must commit time to periodic recertification. Sample data, such as exported account lists, change tickets and log extracts, helps test the design before the auditor arrives. Confirm these commitments in the scope, including who approves access to production systems during the work.

Can a consulting partner sign off on our privileged access controls?

No. A partner can prepare systems, document controls and assemble evidence, but only an independent external auditor issues the opinion on internal control over financial reporting. Management owns the controls and the annual assessment under Section 404 of the Sarbanes-Oxley Act. Under PCAOB AS 2201, the external auditor tests the controls and forms its own conclusion, so the partner's work is an input to that testing, not a substitute for it. Ask your auditor early which evidence they expect for privileged access.

What should we ask for in a privileged access management quote?

Ask for a written scope that names every in-scope system, privileged role and shared or service account covered, and states what is excluded. The quote should list deliverables, such as account inventories, configuration documentation, logging changes, review procedures and evidence packages, and the responsibilities of your staff. Ask how the work is priced (fixed scope or retainer), which costs are one-time and which recur, such as periodic reviews and log retention, and what changes are needed if the scope grows. Confirm that the partner does not issue audit reports or attestations.

How DeployOpen scopes and prepares privileged access evidence

DeployOpen plans, implements and documents self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks, so privileged access controls run where your financial systems run. We prepare the systems, settings and evidence an assessor will inspect, while your organization keeps ownership of the controls and the independent auditor issues any conclusion.

How we scope

Inventory the administrator, superuser, database owner, shared and service accounts tied to in-scope financial applications and infrastructure.
Confirm with you which privileged activities affect financial reporting risks and which are operational only.
Document the scope in writing before work starts, including systems, deliverables and timelines agreed with your team.

How we build

Configure audit logging for privileged actions, such as the admin_audit app for Nextcloud, with log destinations kept outside the administrators' reach.
Set up secret storage and audit devices that record privileged API requests, with sensitive values hashed rather than stored in plain text.
Add secret detection to build pipelines and configure periodic access certification campaigns with named reviewers and deadlines.

How we hand over

Deliver configuration baselines, runbooks and an account register that maps each privileged account to an owner and purpose.
Provide walkthrough material and sample evidence packs showing how privileged logs, certification records and secret scan reports are produced.
Document known gaps and the compensating steps your team owns, so the control design can be explained to the external auditor.

How we support

Support ongoing operation, upgrades and log review as a retainer if your team wants continued help after handover.
Run security testing against privileged paths on request, including attempts to reach administrator functions from standard accounts.
Confirm with each platform vendor which logging, secret management and certification capabilities your chosen version provides before committing to a design.