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.
Where ERP accountability actually lives when controls are fragmented
ERP accountability follows the control, not the meeting structure. If finance owns the business process, IT owns system operation and technical access, and audit owns independent assurance, then missing or misaligned controls usually mean the operating model has not assigned a single accountable owner for each control objective. That distinction matters because ERP environments blend business logic, configuration, access, and evidence, so weak handoffs can leave gaps in approvals, reconciliations, segregation of duties, and change oversight. NIST Cybersecurity Framework 2.0 is useful here because it frames governance, roles, and oversight as part of the security operating model rather than an afterthought. In practice, many organisations discover the accountability gap only after a control failure has already been traced across finance, IT, and audit boundaries.
How accountability should be split across process, platform, and assurance
ERP control ownership is easiest to understand when it is separated into three layers. First, the business process owner is accountable for whether the control is needed, whether it is designed correctly, and whether it supports the financial or operational requirement. Second, IT is accountable for the technical conditions that let the control work, including configuration, access paths, logging, change management, and integration stability. Third, audit is accountable for independent testing and challenge, which means it can identify gaps, rate severity, and press for remediation, but it cannot be the control owner.
That split becomes especially important when a control spans teams. For example, a segregation-of-duties rule may be defined by finance, enforced through ERP role design by IT, and tested by audit. If one side assumes another side is checking it, the control can exist on paper while failing in operation. The practical question is not simply who “knows” about the control, but who can make it work, prove it works, and fix it when it does not.
A useful operating model is to assign one accountable owner per control objective, then document supporting owners for configuration, monitoring, and evidence. NIST SP 800-53 Rev 5 Security and Privacy Controls is relevant because it distinguishes control responsibility, implementation, and assessment in a way that maps well to ERP environments. The failure point is usually not a lack of controls, but a lack of explicit ownership when the control depends on both business process decisions and technical enforcement.
- Account for the business requirement at the process level.
- Assign technical operation and evidence collection to the system owner.
- Use audit to test, escalate, and validate remediation, not to own control performance.
Where this guidance breaks down is when the ERP environment has no clear process owner or when outsourced operations blur responsibility without a documented control matrix.
Where shared ERP controls usually break down
Tighter control alignment across finance, IT, and audit often increases coordination overhead, requiring organisations to balance clearer accountability against slower decision-making. The main breakdowns are familiar: a control is defined by finance but never translated into ERP configuration, IT changes a role or workflow without revalidating the business control intent, or audit identifies a deficiency that no operational owner has authority to remediate. Those are governance failures as much as control failures.
The harder edge cases appear in shared-service models, subsidiaries, and system integrations. A control may be “owned” centrally but executed locally, which creates gaps in sign-off, evidence retention, or exception handling. There is also a genuine governance tradeoff where centralisation improves consistency, but can make it easier for teams to assume someone else is accountable for the last mile. That is why control ownership should be tested against real activity, not job titles.
Practitioners should also distinguish between accountability and dependency. A team may depend on another function to operate a control, but dependency does not transfer accountability. The accountable owner is the one who must answer for the control outcome, even when another team performs part of the work. If that line is unclear, remediation tends to stall because findings are debated as ownership disputes rather than resolved as control defects.
In practice, the most durable fix is a control ownership model that names one accountable business owner per ERP control objective and makes every supporting team’s role explicit.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST CSF 2.0, CIS Controls v8 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 — Organizational Context | ERP accountability depends on defined business ownership and governance context. |
| GV.RM-03 — Risk Management Strategy | Misaligned controls create governance and remediation risk across functions. | |
| Recommendation — Define ERP control ownership in the governance model and assign each control to one accountable owner. Use the risk strategy to assign escalation and remediation authority for cross-functional ERP gaps. | ||
| CIS Controls v8 | 5.3 — Account Management | ERP control gaps often arise from unclear ownership of privileged and user access. |
| 6.3 — Access Control Management | Role design and segregation issues in ERP are control ownership problems. | |
| Recommendation — Map ERP access and approval responsibilities to named owners and review them routinely. Enforce access control ownership for ERP roles, approvals, and segregation rules. | ||
| NIST AI RMF | GOVERN — GOVERN | Accountability across finance, IT, and audit is a governance coordination problem. |
| Recommendation — Establish AI-style governance discipline for ERP ownership, oversight, and escalation paths. | ||
Practitioner Guidance
What to prioritise: Start with the controls that affect financial integrity, access approval, and change management, because those are the ones most likely to fail quietly when ownership is unclear. If a control cannot be tied to one accountable owner, treat that as a governance defect rather than a documentation gap.
What to verify: Confirm that each ERP control has one named owner, a documented backup, and a clear test path showing who detects failure and who remediates it. If finance, IT, and audit each describe the same control differently, the organisation does not yet have aligned accountability.
Common mistake: Treating audit findings as evidence that audit “owns” the control problem. Audit can surface the defect and assess its severity, but remediation ownership must sit with the function that operates or governs the process.
Practitioner takeaway: ERP accountability works only when ownership is anchored to the control objective itself, not to whichever team is most visible when the issue is discovered.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 7, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
