They should shift as many controls as possible to population-based testing, especially access, segregation of duties, and configuration controls that can be validated from system data. Manual sampling should be reserved for judgement-heavy areas. The goal is to make the audit programme executable against live evidence, not merely documented after the fact.
Why This Matters for Security Teams
In multi-ERP environments, manual sampling often gives audit teams a false sense of coverage because control evidence is fragmented across systems, business units, and custom integrations. Population-based testing is the better direction: it lets auditors validate access, segregation of duties, and configuration controls against system data rather than a handful of exported records. That shift also aligns better with the evidence-first posture reflected in the NIST Cybersecurity Framework 2.0 and NHIMG guidance on audit-ready NHI governance in the Ultimate Guide to NHIs — Regulatory and Audit Perspectives.
This matters because ERP controls are rarely isolated. A user may be provisioned in one platform, inherit permissions through an interface account in another, and trigger a workflow in a third system that changes the actual risk posture. If auditors sample only a few transactions, they can miss systematic exceptions, dormant access, or SoD conflicts that exist across the full population. NHIMG research shows only 5.7% of organisations have full visibility into their service accounts, which is a useful warning sign for audit teams trying to rely on incomplete extracts rather than complete data sets from each ERP and connected identity layer. In practice, many audit teams discover control failures only after a cross-system exception has already become a repeat finding, rather than through intentional population testing.
How It Works in Practice
The practical move is to build repeatable data-driven tests for the highest-volume, most deterministic controls. Start with complete populations for user access, privileged roles, interface accounts, and configuration states across every ERP instance. Then standardise the data fields needed to compare like-for-like records, because multi-ERP audit work usually fails when each platform names roles, cost centres, and approval paths differently. Where possible, auditors should test from authoritative system extracts and logs instead of screenshots or manually assembled spreadsheets.
A useful operating pattern is:
- Extract full access and role populations from each ERP on a fixed cadence.
- Join those populations to approved role matrices and SoD rules.
- Flag exceptions automatically, then review only the outliers.
- Validate configuration baselines against policy, not against sampled cases.
- Reserve manual sampling for judgement-heavy exceptions, such as business justification or unusual compensating controls.
This approach is consistent with NHIMG’s broader lifecycle emphasis in the NHI Lifecycle Management Guide and the control visibility issues described in the Ultimate Guide to NHIs — Key Challenges and Risks, especially where access sprawl and stale entitlements create audit blind spots. The main implementation challenge is not the test logic itself but data quality: if one ERP cannot reliably expose historical approvals, effective dates, or privileged assignments, population testing can still be performed but may require compensating reconciliation steps. These controls tend to break down when legacy ERPs lack consistent audit logs or when interface accounts are shared across business processes.
Common Variations and Edge Cases
Tighter population testing often increases reconciliation effort, requiring organisations to balance audit coverage against extract quality, system ownership, and timing constraints. That tradeoff is especially visible in hybrid ERP estates, where cloud and on-premise systems may have different retention rules, access models, and reporting capabilities. Current guidance suggests auditors should prefer a standardised control library, but there is no universal standard for how every ERP should express SoD or privileged access evidence.
Some environments still justify sampling in narrow cases. For example, post-implementation reviews, manual journal approvals, or exception-driven governance checks may need targeted human review because the control depends on context rather than pure system state. The key is to make sampling the exception, not the operating model. Internal audit teams should also avoid over-relying on one-time exports, because a population test is only as reliable as the data refresh cycle behind it. NHIMG’s audit perspective content and the Top 10 NHI Issues both reinforce the same operational lesson: incomplete visibility turns even good controls into untestable assumptions.
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.RM-03 | Risk-informed testing supports scalable audit coverage across ERPs. |
| OWASP Non-Human Identity Top 10 | NHI-08 | Cross-system identity visibility is essential when auditing service and interface accounts. |
| NIST AI RMF | Governance and measurement practices apply to evidence-driven audit programmes. |
Establish repeatable measurement, traceability, and accountability for control testing.
