How should teams build security and compliance into an ERP implementation from the start?

Design security into the ERP blueprint, not the rollout checklist

An ERP implementation creates new access paths, data flows, and control dependencies before the first production user logs in. The practical goal is to make security requirements part of design decisions, not an after-the-fact cleanup effort. That means aligning the business process model, role model, and control model before configuration hardens into a costly default.

Security decisions that are easy to change on paper can become expensive once workflows, integrations, and reporting structures are live. If teams define governance after build-out, they usually inherit inconsistent approvals, weak segregation of duties, and ad hoc exceptions that are difficult to unwind without rework.

What must be defined before go-live?

The first deliverable is a clear ruleset for access and control design: who should be able to initiate transactions, approve them, view them, and override them. That ruleset should be translated into role design, not left as a verbal policy. NIST Cybersecurity Framework 2.0 is useful here because it reinforces governance, identity, and protection as design-time concerns rather than deployment afterthoughts.

Emergency access needs the same treatment. Teams should define when break-glass access is allowed, who can approve it, how it is logged, and how it is reviewed after use. If that path is not designed up front, organizations often create informal exceptions during testing that later become permanent operational shortcuts.

Provisioning and certification are part of the same control picture. Access should be provisioned through a repeatable process, then reviewed periodically so that dormant access, role drift, and excessive privilege are visible early. NIST SP 800-53 Rev 5 Security and Privacy Controls maps well to this stage because it ties access control, identification and authentication, audit, and configuration management into one control discipline.

How do testing and compliance work together during implementation?

Testing should validate the role model, not just application functions. That means checking whether users can only see and do what their job requires, whether privileged paths are tightly limited, and whether exceptions behave as designed. If testing starts only after go-live, teams discover control failures when users are already operating in production, which is the most expensive time to fix them.

Compliance should be treated as evidence of control design, not just policy language. For ERP programmes, the real question is whether the system can demonstrate approval logic, access recertification, audit trail quality, and segregation of duties before launch. That is why frameworks such as ISO/IEC 27002:2022 Information Security Controls and CSA Cloud Controls Matrix are often useful for mapping implementation work to operational control expectations.

For teams that need a maturity lens, OWASP SAMM helps frame security as a build practice, which is especially useful when ERP projects include custom integrations, extensions, or workflow logic that must be assessed before release.

Where implementation teams usually get it wrong

The most common failure is allowing role design to follow organizational politics instead of process necessity. When roles are too broad, too many users inherit access they do not need, and the result is avoidable exposure during testing and after go-live. Another common mistake is treating emergency access as a temporary workaround instead of a controlled process with explicit review.

Compliance drift also appears when provisioning is handled manually for speed. Manual setup can get the project over the line, but it usually leaves weak evidence, inconsistent approvals, and poor recertification discipline. If the ERP must support regulated processes, that weakens audit readiness and increases the chance of cleanup work after the system is already embedded in operations.

Practitioner Guidance

What to prioritise: Lock the role model, emergency access model, and provisioning workflow before the configuration freeze. Those three design choices determine most of the downstream security and compliance burden.

What to verify: Confirm that every critical business process has a named owner, a least-privilege role, an exception path, and an evidence trail. If any of those four are missing, the control design is not ready.

Common mistake: Do not confuse “we can grant access later” with “the implementation is secure enough to launch.” Late access cleanup usually means the system has already been built around the wrong assumptions.

Practitioner takeaway: The best ERP implementations treat access governance as a design requirement, because security fixes are cheapest before users, workflows, and audit expectations become locked in.

Related resources from NHI Mgmt Group

• How should security teams govern non-human identities for compliance?
• How should security teams govern non-human identities for SOC 2 compliance?
• How should organisations build security and application controls into an ERP cloud implementation from the start?
• How should IT and security teams build compliance into system design from the start?