Accountability should sit with the business owners who run the process, the IT teams who operate the systems, and the control leaders who define governance expectations. Audit can test and challenge, but it cannot own the controls. Clear accountability matters because shared systems need clear responsibility for design, operation, monitoring, and remediation.
Why This Matters for Security Teams
ERP control gaps are rarely a single-team failure. They usually appear where process ownership, system administration, and independent assurance blur together. Finance owns the business control objective, IT runs the platforms and integrations, and audit evaluates whether the control actually works. When those lines are unclear, teams end up assuming someone else is handling access reviews, change control, segregation of duties, or reconciliation.
That ambiguity matters because ERP environments concentrate sensitive financial processing, approvals, and privileged access in one place. NHI Management Group’s Ultimate Guide to NHIs notes that 97% of NHIs carry excessive privileges, which is the same governance problem pattern seen when ERP service accounts, API keys, and system-to-system accounts are poorly assigned. The control owner must be able to explain who approves access, who operates it, and who remediates exceptions. Audit can challenge that design, but audit cannot be the operator of record. For control expectations, NIST SP 800-53 Rev 5 Security and Privacy Controls and NIST Cybersecurity Framework 2.0 both reinforce that governance, operation, and assurance are separate responsibilities.
In practice, many security teams discover ownership gaps only after a failed audit finding, a disputed journal entry, or a privileged access exception has already been exploited.
How It Works in Practice
The cleanest accountability model assigns three different duties. Finance or the business process owner defines what the ERP control must achieve, such as who can create vendors, approve payments, or post manual journals. IT owns the technical implementation, including role provisioning, system configuration, logging, backups, and interface stability. Control leaders or GRC functions define the baseline expectations, evidence requirements, and escalation path for exceptions. This aligns with the operational logic in the Top 10 NHI Issues, where ownership failures often start with unclear lifecycle responsibility rather than a purely technical defect.
In practice, accountability should be documented in a RACI or control matrix that names a single control owner for each ERP control. That owner is not always the person doing the hands-on work, but they must be responsible for the outcome. The control owner should verify:
- Who approves the control design and any changes to it
- Who performs the control operation on a recurring basis
- Who reviews exceptions and overdue items
- Who remediates failed control evidence or access drift
- Who signs off when a compensating control is used
For systems with service accounts, API integrations, and scheduled jobs, accountability must also extend to non-human identities. The NHI Lifecycle Management Guide is useful here because ERP control failure often stems from credentials that outlive the business process they support. NIST guidance on access and monitoring also makes clear that operating controls is not the same as testing them. These controls tend to break down when ERP ownership is split across outsourced operations, cloud-hosted finance systems, and custom integrations because no single team can consistently see the full control path.
Common Variations and Edge Cases
Tighter control ownership often increases coordination overhead, requiring organisations to balance clear accountability against local team autonomy. That tradeoff is real in shared-service finance, global ERP rollouts, and heavily outsourced IT operations, where too many approvers can slow remediation and too few can leave gaps unresolved.
There is no universal standard for exactly how many control owners should exist, but current guidance suggests there should always be one clearly named accountable owner per control. Audit should remain independent. If audit drafts the control, executes the review, or closes the remediation ticket, independence is weakened and the assurance model becomes hard to defend. Similarly, control leaders should not inherit day-to-day system operation simply because finance lacks technical depth. The point is to separate accountability from execution, not to collapse both into the same team.
Edge cases arise when ERP controls span multiple business units, shared platforms, or managed service providers. In those environments, accountability should follow the process, not the tool. If the control is about payment approval, finance owns the business risk. If the issue is role design or privileged account enforcement, IT owns the technical control. If evidence is missing, the accountable owner is the one responsible for fixing the gap and proving closure. NHI Management Group’s Ultimate Guide to NHIs - Regulatory and Audit Perspectives is especially relevant where auditors need traceable ownership rather than informal handoffs.
Where organisations get into trouble is when “everyone is accountable” becomes the default answer, because that usually means nobody is accountable when the control fails.
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, NIST SP 800-53 Rev 5 and NIST AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | GV.OC-1 | Defines business ownership and governance expectations for control accountability. |
| NIST SP 800-53 Rev 5 | AC-2 | User and account management is central when ERP controls rely on privileged access. |
| OWASP Non-Human Identity Top 10 | NHI-01 | ERP service accounts and API keys need clear lifecycle ownership and accountability. |
| NIST AI RMF | Governance and accountability principles apply to shared ERP control ownership. |
Name a business owner for each ERP control and document governance so ownership is unambiguous.
Related resources from NHI Mgmt Group
- How should security teams implement policy-based access controls for ERP systems that contain sensitive personal and financial data?
- How should security teams embed ERP controls into business processes instead of retrofitting them after go-live?
- How should security teams make NHI best practices usable across the business?
- How should security teams handle audit evidence for Oracle ERP controls?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on August 27, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
