Enterprise Resource Planning (ERP) projects often start with a lot of excitement. Organizations invest in them to be more efficient, drive revenue, improve decision-making, and give employees better tools to do their jobs.
The promise is compelling: stronger business performance and more growth.
However, in that push to modernize, one question is often overlooked: Who should have access to what in the new ERP environment?
As ERP systems evolve, so do the risks tied to excessive access, outdated permissions, and weak application governance. Modernization should not only focus on functionality. It should also be the moment to reassess security, tighten access, and strengthen governance across the application landscape.
In this blog, we will explore why security and compliance should be addressed early in both ERP and other critical business application implementation and upgrade projects. As companies modernize legacy, on-premise ERP systems as part of broader digital transformation efforts, too many still treat security and compliance as an afterthought.
Failing to include the compliance team early in implementation efforts can be costly. Far too often, teams assume that configuring security, user roles, and permissions can be addressed once the implementation is complete. But when compliance is brought in late, organizations face costly mistakes and prolonged risk exposure when the system goes live that could have been avoided from day one.
Even when security and compliance tasks are included in the project plan, they are often pushed aside when projects start to slip, and deadlines must be met. The choice defaults to either postpone the step, to be addressed with ‘phase 2’ tasks, or security from the old system is just copied into the new one.
In both these scenarios, organizations lose the opportunity to improve application access governance, introduce stronger role design, and apply principals like least privilege in a meaningful way. While ERP projects are often led by the IT department, they are first most concerned about making sure the functional needs of their users are met, and security is not a top priority.
Successful companies treat security and compliance as firm requirements that must be executed as planned, not as optional workstreams during their implementations. Successful companies test new security during user acceptance testing (UAT), and work with users and IT to ensure the security in the new system is set up correctly. They also prioritize concepts like least privilege access and zero trust, and ensure that the use and assignment of elevated privileges is locked down.
To talk through where ERP projects often get off track and what Governance, Risk, and Compliance (GRC) teams should push for early, I spoke with Luke Leaon, Director of ERP, GRC, and Integrated Risk Management at RSM.
Q: What usually happens when organizations wait until late in the project to deal with access governance?
Luke Leaon: You start to see a predictable pattern. Teams rely too heavily on out-of-the-box roles, or they only slightly modify them. This can leave significant Segregation of Duties (SoD) conflicts embedded in the role design.
As go-live pressure increases, an over-reliance on broad or “super” roles happens to keep the project moving. Manual compensating controls are introduced as a stopgap, often poorly designed or undocumented. At the same time, application controls may not be fully evaluated, so sensitive access and SoD risks are unresolved.
That is usually when the project runs into delays, audit findings at go-live, or both. And once you reach that stage, remediation becomes expensive, requiring role redesign, rework of security architecture, and sometimes reconfiguration of business processes.
Q: What should be defined early if an organization wants a more compliant ERP implementation?
Luke Leaon: Three things need to be established upfront.
- The ERP implementation project needs a clear Access Governance Framework that defines how roles will be designed, who owns them, how approvals will work, and how access will be provisioned. As part of this framework, SoD policy should be aligned to business risk tolerance.
- The project also needs a Risk and Control Matrix (RACM) that is integrated across both business and IT processes and clearly mapped to system capabilities and configurations. This should be broad enough to reflect the full regulatory landscape— not just SOX, but FDA, DOJ, GPDR, etc.
- The team needs a set of Security Design Principles aligned to the broader identity governance strategy to guide decisions from the start: including least privilege, segregation between configuration, operations, and monitoring roles, and a clear approach to privileged and emergency access.
Defining these early ensures security is embedded in design, not retrofitted.
Q: Where do ERP projects most often miss access risk before go-live?
Luke Leaon: Access risk usually gets missed in a few predictable places.
- Clear access and risk ownership: Organizations struggle with data governance, and therefore, teams are not always clear on who is responsible for access and risk acceptance decisions.
- Custom security, industry solutions and extension: The focus is often on standard roles, while custom transactions, Fiori apps, NetSuite 3rd part bundles, Oracle Cloud extensions, and D365 privileges introduce unmitigated risk.
- Cross-module/cross-application conflicts: Projects also tend to miss cross-module or cross-application conflicts, for example end-to-end SoD (e.g., Procure-to-Pay, Order-to-Cash) is not fully validated across integrated processes.
- Configuration access: This is another common blind spot, especially when elevated access to table/config changes (e.g., movement types, document types) isn’t tightly controlled.
- Batch jobs and non-human identities: These are often overlooked, even though they can create indirect SoD violations.
- Incomplete rulesets: If risk rules are not tuned for customizations, it can lead to false negatives.
Q: What does a compliant go-live look like from a GRC perspective?
Luke Leaon: A compliant go-live is not “zero risk"—it’s controlled, transparent, and sustainable. Roles have been designed, tested, and approved under a defined Role-Based Access Control (RBAC) framework.
SoD conflicts have been identified, and either remediated or covered by formally approved mitigating controls. Application controls have been identified, mapped to SOD risks, and tested before go-live. Access provisioning workflows are operational and have been tested, emergency access (firefighter) capability is implemented and monitored, and RACM is aligned to system design, with control ownership established. Just as important, the team has audit-ready documentation, including roles, risks, controls, and approvals.
The real marker of a compliant go-live is that there are no known critical-risk conflicts without a defined mitigating control strategy.
Q: What is the biggest message GRC leaders should bring to an ERP implementation?
Luke Leaon: The biggest message is that “security is a design decision, not a testing activity.”
If you don’t embed access governance, SoD, and control design into the blueprint phase, you are accepting technical debt that will surface as audit findings, operational, cyber and fraud risk, and costly remediation. GRC leaders are most effective when they position themselves as an enabler of scalable operations—not a blocker—by helping design roles and controls that the business can actually operate.
Q: Can you share an example of a successful ERP implementation where security and compliance were included early, and what measurable results the customer achieved as a result?
Luke Leaon: One example that stands out is a mid-sized, multi-entity organization with roughly $2B in revenue that brought GRC in during the design phase of its ERP transformation, with a mandate to integrate access governance into the program.
Key actions that the team took included developing a tailored SoD ruleset aligned to business processes and system configuration, and designing an RBAC model tied to job functions, not users. The organization embedded security review checkpoints into each sprint/release cycle. They also integrated RACM development with system design workshops and automated SoD analysis and provisioning workflows pre-go-live.
The results were meaningful. The organization was able to reduce SoD conflicts at go-live by about 85% compared to the initial design baseline, eliminate the need for broad “super user” roles in production, and achieve audit readiness at go-live with no significant deficiencies. The team also saved an estimated 60–70% in post-go-live remediation efforts and improved provisioning speed through controlled, role-based automation.
The key differentiator was treating GRC as part of the transformation architecture—not a parallel compliance track.
How Delinea helps
ERP modernization is the right time to fix the access risks, SoD issues, and governance gaps that legacy environments often carry forward. Organizations that bring security and compliance into the design phase are better positioned to build cleaner roles, enforce least privilege, reduce post-go-live remediation, and support audit readiness from day one.
Delinea’s Fastpath solutions can help by giving teams the visibility needed to assess access, identify SoD risk, and strengthen application access governance across ERP and other critical business applications.
Instead of leaving security for phase two, make it part of a stronger, more controlled implementation from the start.