Compliance and security teams should own access governance before the system goes live. That includes defining emergency access rules, approving assignments, reviewing audit logs, establishing provisioning and de-provisioning processes, and running periodic access certifications. Shared ownership matters because ERP risk is created by business process design, user access, and control validation together.
What compliance and security teams should own before an ERP goes live
Compliance and security teams should own the control layer around access, evidence, and validation before the ERP is turned on. That means defining who can request, approve, and revoke access; how emergency access is granted and reviewed; how logs are retained and tested; and what proof is required to show the control design works in practice.
The key point is that ERP rollout risk is not just an IT cutover issue. It is a business control issue, because the same roles that approve transactions, maintain master data, and handle exceptions can also create segregation-of-duties conflicts if access governance is not designed early.
How access governance becomes the compliance boundary in an ERP rollout
ERP systems concentrate finance, procurement, HR, and operations into a single process engine, so access decisions have outsized impact. Compliance and security teams should therefore set the rules for privileged access, emergency access, and periodic certification before business users begin working in the system. Without that boundary, access is often inherited from project convenience rather than control design.
Practically, this means the teams responsible for governance should own the standards for provisioning, de-provisioning, temporary elevation, and review cadence. They should also require that role design be validated against business process ownership, so that approvals, posting rights, and exception handling do not end up in the same hands by accident.
That ownership model is reinforced by access-control guidance such as NIST SP 800-53 Rev 5 Security and Privacy Controls, which ties access, authentication, and auditability to control design, and by NIST Cybersecurity Framework 2.0, which frames governance and protective controls as part of operational security management.
Which controls need to be defined before go-live
The minimum pre-go-live scope should include emergency access rules, approval workflows, provisioning and de-provisioning procedures, log review expectations, and access certification timing. These controls should not wait until after launch, because post-launch clean-up is usually slower, more disruptive, and harder to evidence to auditors.
Security teams should also confirm that logging is actually usable for review, not just technically enabled. If audit logs cannot show who granted access, when an emergency role was activated, or whether a privileged action was later reviewed, the control exists only on paper.
For organisations that rely on cloud-hosted ERP services or shared control responsibilities, it is useful to anchor the control model to a broader governance baseline such as the CSA Cloud Controls Matrix, which helps map access, audit, and assurance expectations across cloud operating models. Where regulated payment data is involved, PCI DSS v4.0 is especially relevant because it demands least-privilege access and tighter handling of system and application accounts.
Why shared ownership matters when business process design and control testing collide
ERP access governance works best when compliance, security, and business process owners share responsibility but do not share ambiguity. Business teams know which functions are operationally necessary, security teams know which access paths raise exposure, and compliance teams know which evidence will stand up in review. If any one of those perspectives is missing, the rollout tends to optimise for speed rather than control.
The practical result is that role design, exception handling, and certification should be treated as one connected workstream. A role that looks efficient in testing can still fail in production if it allows incompatible duties, weak emergency elevation, or unreviewed retained access after a joiner, mover, or leaver event.
Risk and Threat Considerations
ERP rollouts are attractive to attackers and risky for organisations because they concentrate high-value process authority into a small number of roles and workflows. If access governance is weak, a single overprivileged account or poorly reviewed emergency entitlement can expose financial posting, vendor setup, payroll, or master data controls.
Failure mechanism: Misaligned role design, delayed de-provisioning, weak emergency access review, or incomplete logging allows excessive privilege to persist after the system goes live.
Impact: The organisation can lose segregation of duties, miss fraudulent or erroneous activity, and struggle to prove that access decisions were authorised and reviewed.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5, CIS Controls v8 and CSA Cloud Controls Matrix set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | AC-6 — Least Privilege | ERP access governance depends on limiting assignments to the minimum necessary. |
| AU-6 — Audit Review, Analysis, and Reporting | The question explicitly includes audit-log review and validation of access controls. | |
| IA-5 — Authenticator Management | Provisioning and de-provisioning of access depend on credential lifecycle control. | |
| Recommendation — Enforce least-privilege ERP roles and restrict emergency access to the minimum duration needed. Review ERP audit logs for privileged activity, approvals, and exception use on a defined cadence. Rotate and revoke ERP credentials promptly when users change roles or leave. | ||
| CIS Controls v8 | CIS-5 — Account Management | ERP rollout ownership centers on provisioning, de-provisioning, and periodic access review. |
| Recommendation — Assign account ownership, remove stale access, and certify ERP accounts regularly. | ||
| CSA Cloud Controls Matrix | IAM — Identity & Access Management | Cloud and hosted ERP deployments need formal identity governance across approvals and reviews. |
| Recommendation — Define ERP access approval, revocation, and review workflows under a single IAM process. | ||
Practitioner Guidance
What to prioritise: Treat role approval and emergency access design as the first go-live gate, not a post-launch cleanup task. If a role cannot be mapped cleanly to business ownership and review responsibility, it is not ready.
What to verify: Confirm that every privileged or exception path has an owner, an approval rule, a review cadence, and a revocation trigger. Also verify that audit logs show enough context to reconstruct who granted access, who used it, and whether the action was reviewed.
Practitioner takeaway: The safest ERP rollout is the one where access governance is designed before business users arrive, because late control fixes are usually weaker, costlier, and harder to evidence than early ownership decisions.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 28, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
