SOX audit preparation checklist: a year-round sequence, not a Q4 scramble

Most SOX checklists are lists of controls. That is the wrong axis. The controls are not the hard part; the timing is. Evidence for a control that was implemented in November covers two months of a twelve-month period, and no amount of diligence in December fixes that.

What follows is organised by when the work has to happen, with the traps that turn a control that genuinely worked into a finding.

Q1: scope and decide what is in

Scoping decides the cost of everything that follows.

• Confirm which sections apply. 302 certification is quarterly and applies to everyone in scope. 404(a) is management’s annual assessment and also applies to everyone. 404(b), the external auditor’s separate opinion, applies to accelerated and large accelerated filers. Emerging growth companies and smaller reporting companies are exempt from 404(b) and not from 404(a).
• Set materiality and identify significant accounts, then the processes that feed them.
• List the in-scope applications, and then the layer underneath. This is the step that gets skipped. If a Linux host runs the ERP database, that host’s access and change controls are in scope as IT general controls. Finding that out in year two is expensive.
• Identify service organisations and request SOC 1 Type II reports covering a period that overlaps your fiscal year. Type I is design only and is not sufficient for reliance.

Before the period starts: instrument what cannot be backfilled

Three things produce evidence only from the moment they are switched on. Everything else can be written up later; these cannot.

• Privileged access as used, not as granted. Entitlement lists say who could. Records of every privilege escalation, sudo, and interactive session with its source say who did, which is the population auditors sample.
• Change observed at the host. Writes to configuration, package changes, service restarts, binary modifications, captured independently of whatever performed them. This is what makes the completeness argument possible later.
• Attribution through shared accounts. If six people can become root, “root did it” names nobody. Evidence that carries the login identity behind an escalation answers the auditor’s first follow-up.

Also worth setting now, because it silently governs everything above: data retention long enough to cover the fiscal year plus the roll-forward period. Evidence that expired in month four is not evidence, and this is the most quietly destructive misconfiguration in a compliance programme.

Q2: document and walk through

• Write process narratives and a risk-control matrix: for each risk, the control, its owner, frequency, whether it is preventive or detective, manual or automated, and which financial statement assertion it addresses.
• Walk each control end to end with the owner. Design comes before operation: if the control as described could not catch what it is supposed to catch, testing whether it ran is beside the point.
• Prefer automated, configuration-enforced controls where you have the choice. Backed by effective general controls, an automated control can often be tested with a sample of one, against forty for a daily manual one.
• Start remediating prior-year findings now. A control remediated in Q4 has almost no population left to sample.

Quarterly: the reviews that have to actually happen

• Privileged access review. Who holds administrative access, is each one still justified, and has anything appeared that nobody approved.
• Access review follow-through. The review artefact is half the evidence. The other half is proof that access flagged for removal was actually removed, closed out against system state rather than a checkbox. Auditors test the follow-through, and the follow-through is where reviews fail.
• Reconcile leavers. HR’s leaver list against the timestamp each account was disabled on each system, including the hosts and databases people forget.
• Unauthorised change exceptions. Observed changes with no approved change covering them, investigated and written up at the time. A twelve-month backlog of exceptions investigated in January is not a detective control operating effectively.
• 302 certification support for each quarter’s filing.

Interim and year end: test, then export

• Test operating effectiveness at interim, then roll forward to year end with an update procedure.
• Assemble the evidence pack per control area, and for every listing include its provenance: source system, query or report, parameters, who ran it, when. Evidence without provenance gets rejected however good the control was.
• Export the change reconciliation for the period: declared population, observed population, and a documented explanation for every difference.
• Export completed access reviews with reviewer sign-off and remediation status.
• Rate every deficiency as a control deficiency, significant deficiency, or material weakness, and aggregate them. IT general control deficiencies aggregate upward, because one failure invalidates reliance on every automated control and system-generated report depending on that system.

The traps

Approval dated after deployment. Timestamps give this away immediately and it converts a fine change into a finding.

Reconciling against the planned window. A change approved for Saturday and executed on Tuesday is unauthorised at the point it was executed. Matching on the planned window hides exactly the thing the control exists to catch.

Reviews with no follow-through. A signed access review where flagged accounts still exist three months later is worse than no review: it documents that someone looked and nothing happened.

Screenshots. Cropped, undated, no visible filter. They look like evidence and fail the completeness and accuracy test.

Absence of evidence read as evidence of absence. “No unauthorised changes were found” and “no unauthorised changes are visible in the data we still hold” are different statements. If retention did not cover part of the period, say so.

What makes the next year cheaper

The teams that stop dreading this are the ones where evidence is a by-product of running the systems rather than a project that starts when the request arrives. Access changes recorded as they happen. Changes declared before they happen and verified after. Alerts that carry their own response history. Reports that can be shown not to have been altered since they were generated.

That is the shape AlertKick is built around: continuous change tracking and compliance monitoring that produce the artefacts rather than requiring someone to reconstruct them. The two companion posts go deeper on each half: what auditors ask for at the infrastructure layer, and proving your change population is complete.