What do security teams get wrong about controls testing in ERP systems?

A common mistake is assuming that successful login and basic role assignment prove the control environment is sound. Effective testing must go deeper into transaction paths, exceptions, role combinations, and configuration drift. Without that depth, teams miss silent failures that only surface during audit review or after an operational incident.

Why This Matters for Security Teams

ERP controls testing is often treated as a checkbox exercise: confirm users can sign in, confirm a role exists, then move on. That misses how ERP risk actually materialises, which is through transaction routing, exception handling, indirect access, and custom configuration drift. Security teams need to test whether the control behaves under real business logic, not whether the interface merely permits access. NIST’s NIST Cybersecurity Framework 2.0 emphasises continuous, outcome-based control validation, which maps well to ERP environments where a control can appear intact while failing at the process layer.

This is especially important in environments with heavy reliance on service accounts, integrations, and privileged automation. In those cases, the control surface is not just human access but the non-human identity layer that executes transactions, moves data, and triggers approvals. NHIMG’s Ultimate Guide to NHIs — Standards notes that 97% of NHIs carry excessive privileges, which helps explain why broad ERP access often goes unchallenged until something breaks. In practice, many security teams discover control failure only after an audit sample or an operational incident exposes the gap.

How It Works in Practice

Effective ERP controls testing starts with the business process, then traces the control points backward. A valid test plan should include transaction paths, fallback paths, exception approvals, segregation-of-duties conflicts, and whether a control still works after role changes or configuration updates. For example, a purchase order control is not proven by confirming that a buyer role exists. It must also be tested for threshold overrides, delegated approvals, emergency access, and whether custom code or interface users can bypass the intended workflow.

Security teams should separate access testing from control testing. Access testing answers who can log in. Control testing answers whether the system prevents or records an unauthorised action at the right point in the process. That usually requires combining role review, configuration review, and transaction-level evidence. For ERP environments with automation, the same logic applies to NHIs: a service account may not be a “user” in the human sense, but it can still create, approve, or post transactions. That is why the State of Non-Human Identity Security is relevant here: identity sprawl and weak visibility make it easy to miss hidden execution paths.

• Test controls against real transactions, not just screen access.
• Include negative testing for overrides, exceptions, and broken segregation of duties.
• Validate that logs capture the event, not just that the action is blocked.
• Re-test after ERP patches, role redesigns, and configuration changes.

Operationally, teams should sample controls at the process layer, then confirm the underlying entitlement, integration account, and workflow setting that makes the control effective. These controls tend to break down when customisations, middleware, or privileged automation create alternate execution paths that bypass the standard workflow.

Common Variations and Edge Cases

Tighter control testing often increases audit effort and production disruption, so organisations have to balance depth against the cost of repeated evidence collection. That tradeoff is real in ERP environments because controls are often distributed across modules, regional instances, and third-party integrations. Current guidance suggests treating those integrations as part of the control environment, not as external noise.

Edge cases usually appear in three places. First, emergency access can be formally approved yet functionally overpowered if it is not time-bound or independently monitored. Second, indirect access through bots, schedulers, or interface users may bypass the role model entirely. Third, shared service accounts can create false confidence because one account appears low risk while actually representing many business functions. This is where NHI governance becomes part of ERP control testing, not a separate discipline.

For teams formalising this approach, the control question is not “can someone get in” but “can the right action still be prevented, detected, and explained at the transaction level.” That is the practical standard worth testing against, and it aligns with the broader control-validation approach in NIST Cybersecurity Framework 2.0 and the NHI lifecycle emphasis in Ultimate Guide to NHIs — Standards.

Related resources from NHI Mgmt Group

• What do security teams get wrong about scaling identity controls across regions and channels?
• What do security teams get wrong about testing brittle systems?
• What do security teams get wrong about using APIs to manage user roles and application licences?
• What do security teams get wrong about access control when they focus only on login authentication?