Who should own ERP change evidence for SOX audits?

Why This Matters for Security Teams

For SOX audits, ERP change evidence is not just a ticket trail. It is the proof that financial-impacting changes were authorised, tested, approved, and retained in a way that stands up to scrutiny. The ownership question matters because control failure usually appears first as a gap between application operations, identity governance, and audit expectations. NIST’s Cybersecurity Framework 2.0 reinforces that accountability and evidence handling are governance problems, not just technical ones.

In NHI-heavy environments, change evidence often depends on service accounts, API keys, and automation tied to ERP workflows. That makes the evidence chain fragile if no single owner is responsible for preserving context across approvals, identity changes, and system logs. NHIMG’s Ultimate Guide to NHIs — Regulatory and Audit Perspectives notes that audit-ready governance depends on lifecycle discipline, not ad hoc recordkeeping. The practical failure is usually not the absence of evidence, but evidence that cannot be tied cleanly to the right control owner when auditors ask for it.

In practice, many security teams discover ownership ambiguity only after a control test fails or an external auditor requests a sample that no one can reconstruct.

How It Works in Practice

Ownership should be split by function, with a clearly designated control owner coordinating the process. Application owners should own the ERP change itself, including what changed, why it changed, and whether the business requirement was valid. IAM or IGA teams should own identity-related evidence, such as who approved access, who executed the change, whether privileged access was used, and whether the account had the right entitlement at the right time. Audit or control owners should own the retention standard, sampling expectations, and evidence package format.

This division works best when there is a single evidentiary workflow that collects records from ticketing, ERP logs, approval systems, and identity systems into one retained package. Current guidance suggests that the control owner should define the minimum evidence set, while the technical teams supply source records. For ERP systems, that usually includes change tickets, testing results, approval metadata, privileged session logs, and post-change validation. The Top 10 NHI Issues highlights why this matters: excessive privileges and weak visibility routinely undermine auditability when machine identities are involved.

• Application owners validate the business need and system impact.
• IAM or IGA teams verify who had access and whether access was appropriate.
• Audit owners define retention, evidence completeness, and control-test readiness.
• Security teams preserve logs and correlate them to the specific change request.

Where possible, align the workflow to the evidence expectations in the Ultimate Guide to NHIs — Lifecycle Processes for Managing NHIs and cross-check it against SOX control design. These controls tend to break down when ERP changes are made through shared accounts or when logging is split across multiple tools without a retained chain of custody.

Common Variations and Edge Cases

Tighter evidence ownership often increases coordination overhead, requiring organisations to balance audit readiness against operational speed. That tradeoff becomes more visible in global ERP estates, emergency change windows, and heavily automated environments where one change can trigger several downstream actions. There is no universal standard for this yet, but best practice is evolving toward a named control owner with delegated evidence contributors.

One common edge case is when the ERP platform team insists it owns all technical records, while the compliance team expects business ownership. Another is when changes are executed by automation accounts, which can obscure who actually initiated the action unless workload identity and session attribution are preserved. In those cases, the control owner should require both the initiating identity and the approving human role to be captured. The Ultimate Guide to NHIs — Key Challenges and Risks is useful here because it shows how poor visibility and weak rotation discipline create audit blind spots.

When SOX scope spans multiple ERPs or outsourced support models, the evidence owner must also define how third-party records are collected and preserved. That becomes especially important when the ERP vendor, integrator, and internal team each hold part of the record, because fragmented custody weakens the audit trail.

Related resources from NHI Mgmt Group

• How should teams design SOX controls across IAM, PAM, and ERP systems?
• Who should own identity governance for ERP, HCM, and integration users?
• Who should own evidence and remediation when audit findings affect access controls?
• How do change management tools help with SOX, PCI DSS, or HIPAA evidence?