SOX evidence gathering: what auditors ask for at the infrastructure layer

SOX evidence requests feel arbitrary the first time they arrive. They are not. The requests come from a small, stable set of IT general controls, and once you have seen the pattern you can predict almost every one of them a year in advance.

The problem is rarely that the controls do not exist. It is that the systems underneath them were built to run infrastructure, not to answer questions about it a year later, so evidence gets reconstructed by hand at year end from grep, shell history and memory. That reconstruction is expensive, it produces exactly the kind of artefact auditors are trained to distrust, and it happens every single year.

The four areas every request comes from

Sarbanes-Oxley says nothing about servers. The chain of reasoning that drags infrastructure into scope runs: material account, to the process that produces it, to the application that runs the process, to the general IT controls that keep that application trustworthy, and finally to the operating system and database beneath it. That last link is where most of the painful requests land.

Access to programs and data. Who can reach production, who approved it, and did access go away when people left. The requests: a user listing with roles as of a date, straight from the system; access request tickets with approvals; the HR leavers list reconciled against the timestamp each account was actually disabled; a periodic access review with the reviewer’s sign-off; a list of privileged accounts with justification for each.

Program change management. Was every change requested, approved, tested, and deployed by someone other than its author, and did anything else reach production. The requests: the full population of changes for the period, then a sample with the request, the business approval dated before deployment, test evidence, and proof the deployer was not the developer.

Program development. Only tested in years where something significant went live. New system implementations, data conversion with control totals reconciled before and after, user acceptance sign-off.

Computer operations. Do the jobs that feed financial data run, are backups tested by actually restoring something, and do incidents get resolved. The requests: schedules and job history, backup results plus a documented restore test, incident tickets showing resolution.

That is the whole surface. Four areas, roughly a dozen recurring requests, entirely predictable.

Why the evidence gets rejected

The most common reason a SOX evidence pack comes back is not that the control failed. It is that the evidence cannot be relied on.

Auditors work to a concept called information produced by the entity. If you hand over a listing of users, the auditor cannot use it unless you can show it is complete and accurate: which system it came from, the exact query or report, the parameters including the date range, who ran it, and when. A spreadsheet with no provenance is not evidence. A screenshot cropped so the filter is not visible is worse, because it looks like evidence.

There is a related trap in how the request is phrased. When an auditor says “show us the changes for the period”, they are not asking for a list. They are testing whether the population is complete, and their next question is how you know nothing is missing from it. A list exported from a ticket system answers the first question and cannot answer the second, because a change made without a ticket leaves no trace in the ticket system by definition. That is the single hardest thing in ITGC to evidence, and it is where most findings come from.

The three answers that close requests fastest

System-generated beats human-asserted. “We remove access within 24 hours” is a policy. A record showing the account was deleted on the host at 14:02, two hours after the leaver’s last day, with the command and the person who ran it, is evidence. The first invites a sample; the second closes it.

Two independent populations beat one. The reason completeness is hard is that most organisations have exactly one source of truth about change, and it is the same system the change was supposed to be recorded in. Getting a second population from somewhere the deployment process cannot influence, such as file integrity and configuration change records captured in the kernel, turns an unanswerable question into a reconciliation with an exception list at the end of it.

Attribution beats activity. A log line saying root modified /etc/sudoers names nobody. Auditors ask who, and “root” is not an answer when six people can become root. Evidence that carries the login identity behind a sudo chain answers the question the first time it is asked.

What to instrument now, not in Q4

The calendar matters more than the tooling. Testing samples across the whole period, so the useful question in January is not “what will the auditor want” but “what will exist by the time they ask”.

Three things are worth turning on at the start of a fiscal year, because none of them can be backfilled:

• Privileged access as used, not as granted. Entitlement lists say who could. Records of every sudo, su, privilege escalation and SSH session with its source say who did, which is the population auditors sample from and the one nobody has.
• Change observed at the host, not just declared in a ticket. Writes to /etc, package changes, service restarts, binary modifications, recorded independently of whatever deployed them.
• The response half of every alert. Detection alone answers nothing under computer operations. The evidence is the alert, the notification that reached a named person, the acknowledgement, and the resolution, all timestamped. That is what escalation policies and on-call records produce as a side effect of working normally.

The pattern across all three: evidence should be a by-product of running the systems, not a project that starts when the request arrives. Infrastructure that records what happened, continuously and off the host, turns a six-week evidence scramble into an export.

AlertKick was built around that shape. Kernel-level capture means the record does not depend on the thing being recorded cooperating; shipping events off the host in real time means a local wipe does not remove them; and declaring changes in advance is what makes an unauthorised change something you can compute rather than something you argue about. The details of the change side are in proving your change population is complete, and the year-round sequence is in the SOX audit preparation checklist.