Field Notes
Why SOX Programs Still Run on Spreadsheets
Why SOX programs keep returning to spreadsheets, and what a governed control workflow changes.
Problem
Most SOX programs do not stay on spreadsheets because teams prefer them. They stay there because no single operating layer manages ownership, evidence, timing, review, exceptions, and escalation. The spreadsheet fills that gap quickly and remains long after the temporary solution becomes a critical process.
A tracker can show a status, but it cannot reliably own the work behind that status. Evidence still arrives through email, review comments live in separate conversations, and overdue tasks depend on someone noticing and following up.
Why it persists
Spreadsheets are flexible, familiar, and easy to change. That makes them useful during process discovery. It also makes weak process definitions easy to tolerate because each cycle can be repaired manually.
The hidden operating model becomes a network of experienced people who know which owner to chase, which evidence is acceptable, and which exception needs attention. The documented process and the actual process gradually separate.
System pattern
A control operating system treats the control, owner, evidence requirement, execution period, review state, and exception as connected records. Routing rules move work between accountable roles. Status is calculated from the underlying workflow rather than typed into a cell.
This does not require removing every spreadsheet. It requires deciding which responsibilities belong to software: assigning work, preserving evidence context, recording review, surfacing exceptions, and keeping a traceable history.
What changes when software owns the workflow
Follow-up becomes a managed exception instead of the default operating method. Owners can see what is required, reviewers can see what changed, and program leaders can inspect the real state of execution without rebuilding it from messages.
The strongest benefit is not a cleaner dashboard. It is a closer match between the intended control process and the process that actually runs.
Boundary and caution
Software cannot decide whether a control design is appropriate or whether evidence is sufficient in every context. Those judgments remain with accountable professionals.
Automation should make ownership and review more visible. If it hides uncertainty or turns a weak process into a faster weak process, it has not solved the operating problem.