It becomes a governance problem when logs exist but cannot prove control operation, review activity, or approval integrity. At that point, the organisation has evidence storage, not evidence assurance, and SOX testing becomes manual reconstruction instead of reliable control validation.
Why This Matters for Security Teams
ERP change tracking stops being a routine audit feature when the system can no longer show who approved a change, who executed it, and whether the control actually operated as designed. At that point, the issue is not retention but governance: the organisation cannot demonstrate evidence integrity, segregation of duties, or reliable review. NIST CSF 2.0 frames this as an accountability problem, not just a logging problem, because controls must be verifiable in operation, not merely documented in policy.
This is where ERP logs often fail practitioners. A timestamped event may exist, but if it cannot be tied to a named approver, a preserved workflow state, and an immutable record of the change path, SOX testing becomes reconstruction after the fact. NHIMG’s Ultimate Guide to NHIs — Regulatory and Audit Perspectives makes the same core point for NHI governance: evidence without assurance is not control validation. In practice, many security teams discover the gap only after auditors ask for proof that a control operated correctly, rather than through intentional design.
How It Works in Practice
Governance-grade change tracking requires more than application logs. It needs a complete control narrative: request, approval, execution, verification, and exception handling. For ERP environments, that usually means capturing workflow metadata, identity context, change ticket linkage, and tamper-resistant storage. Where change approval is mediated by service accounts or automation, the identity behind the action must still be provable. That is why the NHI lifecycle guidance in NHIMG’s Ultimate Guide to NHIs — Lifecycle Processes for Managing NHIs is relevant even in classic ERP operations: the system must record not just what changed, but what identity performed the change and under what authority.
In practice, mature teams align ERP change evidence to three questions:
- Was the change pre-authorised by the correct control owner?
- Can the organisation prove the control executed, not merely that an entry was written?
- Is the evidence resistant to later alteration, deletion, or selective export?
That model maps well to the NIST Cybersecurity Framework 2.0, especially around governance, protection, and detection activities. NHIMG’s Top 10 NHI Issues also highlights that weak rotation, inadequate logging, and over-privileged access frequently combine, which is why ERP change data often fails when service accounts are shared or long-lived. These controls tend to break down when custom ERP workflows are heavily scripted because the approval trail, execution identity, and change artefact are split across multiple systems and cannot be reassembled reliably.
Common Variations and Edge Cases
Tighter change tracking often increases operational overhead, requiring organisations to balance auditability against workflow speed. That tradeoff is real in ERP platforms with high-volume configuration changes, emergency fixes, or delegated regional administration. Current guidance suggests that not every event needs the same evidentiary depth, but there is no universal standard for this yet; the practical threshold is whether the record can support an auditor’s test of control without manual reconstruction.
Edge cases usually appear when automation performs the change, when approvers are outside the ERP, or when logs are exported into a separate SIEM without preserving original context. In those environments, change tracking may still be useful for forensics, but it is not enough for governance unless the organisation can show durable linkage between identity, approval, and execution. Teams should also be careful not to treat periodic review of a log archive as equivalent to control operation. A review record helps, but it does not prove that the underlying change was authorised or that the control could not be bypassed. The strongest programmes treat ERP change records as governed evidence, not operational exhaust.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST CSF 2.0 and NIST AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | GV.OC-01 | ERP change tracking needs clear governance ownership and accountability. |
| OWASP Non-Human Identity Top 10 | NHI-03 | Service accounts and automation often undermine change evidence integrity. |
| NIST AI RMF | The question is about reliable governance evidence and accountability. |
Inventory non-human identities involved in ERP changes and enforce rotation, traceability, and least privilege.
