SOX Change Management: Common Pitfalls and How to Avoid Them

Change management controls exist to make sure that changes to financially relevant systems are requested, reviewed, tested, and approved before they go live, and not, for example, approved after the fact because someone forgot a step under deadline pressure. It's a simple idea in principle. In practice, it's one of the ITGC areas most likely to turn up a deficiency, because the evidence trail runs through multiple systems and multiple people, and any one gap breaks the chain.

The pitfalls that show up again and again

• Approval after deployment. The most common finding: the "Approved to Deploy" timestamp comes after the change was actually deployed, or QA sign-off is dated after go-live. The control is supposed to happen before the change ships, not get documented afterward.
• No independent approver. A developer who can write, test, and deploy their own code without anyone else in the approval chain undermines the control regardless of how well-documented the ticket is.
• Incomplete change population. If the population used for testing was pulled from the wrong system, the wrong environment, or the wrong date range, the sample drawn from it doesn't represent what actually happened.
• Emergency changes without retroactive review. Emergency fixes are usually a legitimate exception to the standard process, but only if there's a defined retroactive approval step that actually gets performed and documented.
• Evidence that doesn't tie to the ticket. A generic "approved" email or Slack message that doesn't reference the specific change, version, or ticket number doesn't hold up as evidence for that specific change.

What actually fixes them

Most of these pitfalls come down to sequencing and traceability, not the absence of a process. Fixing them usually means: pulling the full population directly from the system of record instead of a manually maintained list, comparing approval timestamps against deployment timestamps as a matter of course rather than only when something looks off, and requiring that every approval reference the specific change it applies to.

That timestamp comparison in particular, approval date versus deployment date, is exactly the kind of test that benefits from being computed rather than eyeballed. It's unambiguous, it doesn't require judgment, and it's easy to miss when you're reviewing a stack of tickets manually. Audagic tests it automatically for every change in the population, not just the ones sampled, and flags the exact dates involved when a change fails.