How should security teams track ERP configuration changes for SOX compliance?

Why This Matters for Security Teams

SOX evidence for ERP change control is only useful when it can be tied to a specific business control, a specific approver, and a specific execution path. Security teams often over-collect logs and still miss the audit question because raw event data does not show whether the change was authorised, segregated, and limited to the right financial objects. Current guidance from the NIST Cybersecurity Framework 2.0 supports outcome-based control evidence, while Ultimate Guide to NHIs — Regulatory and Audit Perspectives explains why identity context is central to auditability, especially where service accounts and integrations make the change trail harder to interpret. The real risk is not just missed detection, but evidence that cannot be reconciled to the control owner’s intent or the auditor’s sampling method. In practice, many security teams discover their ERP change trail is incomplete only after auditors ask for a control-by-control walkthrough, rather than through intentional SOX evidence design.

How It Works in Practice

The strongest approach is to track only SOX-relevant ERP configuration objects and to preserve the chain of custody around each change. That means capturing four things for every event: who initiated it, what object changed, what approval or ticket authorised it, and when it took effect. The object list should be narrow and defensible, such as posting rules, approval workflows, vendor master controls, segregation-of-duties logic, and privileged role assignments. Broader platform noise rarely helps an auditor and often obscures the evidence that matters. A practical workflow usually includes:

• Mapping ERP objects to specific SOX controls and owners.
• Recording identity context for humans and non-human identities, including service accounts, APIs, and automation jobs.
• Linking change events to tickets, approvals, and emergency change justifications.
• Retaining before-and-after values so auditors can see the actual delta, not only that “a change occurred.”
• Preserving timestamps, source system, and session metadata to support reconstruction.

For ERP platforms with automation and integrations, change evidence should also distinguish between direct administrative changes and indirect changes made by scripts or orchestration tools. The Top 10 NHI Issues research is relevant here because over-privileged and poorly rotated identities are common causes of control drift. Where possible, align reporting with lifecycle discipline described in Ultimate Guide to NHIs — Lifecycle Processes for Managing NHIs so the evidence shows not just the change, but the authorised state of the identity that made it. These controls tend to break down when ERP customisations are made outside the ticketing workflow because the resulting evidence cannot prove approval, segregation, or rollback readiness.

Common Variations and Edge Cases

Tighter change tracking often increases operational overhead, requiring organisations to balance audit precision against admin effort and system performance. The best practice is evolving for hybrid ERP landscapes, especially when cloud ERP, custom middleware, and legacy on-prem modules all touch the same control. There is no universal standard for this yet, but current guidance suggests keeping the audit trail consistent even when the execution path differs. Two edge cases matter most. First, emergency changes: auditors usually accept them if the evidence shows a documented reason, post-implementation review, and timely normalisation of the control state. Second, automated configuration management: if a pipeline pushes approved ERP settings, the pipeline identity still needs the same level of accountability as a human approver, because the control question is who had authority, not who clicked the button. This is where NHI governance overlaps with SOX. If the same service account can deploy, approve, and reconcile changes, the segregation story fails even if the logs are complete. For organisations trying to prioritise, the best starting point is the control universe itself, not the logging platform. The NHI governance lens in the The 2024 ESG Report: Managing Non-Human Identities is useful because it shows how identity weakness compounds reporting risk when privileges are broad and unmanaged. Security teams should treat ERP change evidence as a control narrative, not a data dump. When the environment depends heavily on custom interfaces or external administrators, even well-designed tracking can become ambiguous because the identity behind the change no longer maps cleanly to the control owner.

Related resources from NHI Mgmt Group

• How should security teams govern non-human identities for compliance?
• How should security teams govern non-human identities for SOC 2 compliance?
• What should security and compliance teams ask for in AI review processes?
• How should security teams implement PBAC in ERP and SaaS applications?