When ERP changes, controls must follow

Treat controls as a core workstream from day one and achieve smoother implementations and stronger compliance positions.

Contact us
People looking at screens
Every ERP transformation brings a fundamental tension. The project team is focused on delivering new functionality, migrating data, and meeting go-live deadlines. Meanwhile, the controls that protect financial reporting, segregation of duties, and audit trails need to be redesigned, tested, and documented - often by people who aren't part of the core project. 

This tension explains why so many organisations discover compliance gaps only after go-live, when remediation costs are highest and audit scrutiny is immediate.

The good news: this pattern is avoidable. 

The real cost of waiting

ERP systems are essentially control environments. The way transactions flow, who can approve what, how exceptions are logged, which data fields are mandatory: these configurations determine whether your controls will function as designed. 

When control requirements enter the conversation late, project teams face difficult choices. Retrofitting access restrictions into a system already configured around different assumptions creates friction. Bolting on audit logging after data structures are finalised often means incomplete coverage. And compensating controls (manual workarounds to address gaps) tend to persist far longer than anyone intends. 

The economics are straightforward. Addressing a control gap during requirements and design is a matter of documentation and configuration decisions. Addressing the same gap after go-live involves change requests, regression testing, retraining, and often a period of elevated audit risk while fixes are implemented. 

A 7-phase approach to building controls

Controls should be woven into each stage. Ensure compliance considerations are addressed at the moments when they're easiest (and least expensive) to get right is central to BDO’s 7‑phase approach.

1
Project initiation and planning

Effective control integration starts with establishing clear ownership. A dedicated controls workstream, reporting to both project governance and audit, creates accountability that might otherwise fall between teams. This workstream typically includes internal audit, SOX owners, compliance specialists, IT security, and business process owners who understand how controls operate in practice. 

The first substantive deliverable is a control impact assessment: mapping existing controls to target ERP processes and identifying what transfers directly, what needs redesign, and what is entirely new. 

2
Requirements and design

Control needs now translate into functional specifications. Abstract requirements like "appropriate segregation of duties" become concrete system behaviours: specific approval thresholds, defined role combinations that trigger conflicts, mandatory fields that ensure audit trails capture required information. 

Segregation of duties deserves particular attention here. Role design in modern ERP systems is complex, and conflicts that seem theoretical during design become real exposures in production. Defining the SoD matrix before configuration begins prevents the painful exercise of unwinding access after users are already active in the system. 

3
Configuration and development 

This phase requires disciplined change control for anything affecting controls. Version management, clear linkage between change tickets and control requirements, and baseline documentation all contribute to the evidence trail auditors will eventually review.

4
Data migration 

Data migration presents specific control risks that project teams often underestimate. Master data elements (such as approver hierarchies, account mappings, and historical audit fields) carry significant control implications. Reconciliation procedures that verify control-relevant data migrated correctly (tested end-to-end from source through staging to target) provide assurance that the new system starts with clean foundations. 

5
Testing 

Testing phases should include explicit control validation alongside functional and integration testing. This means test scripts designed to confirm controls work as specified, including negative testing to verify the system correctly prevents what it should block. Test evidence needs clear organisation: linked to control identifiers, with metadata showing who executed tests, when, and in which environment. 

6
Cutover and go-live

Cutover planning often focuses on data conversion and system availability, but control activation deserves equal attention. The cutover runbook should specify when each control becomes active, who owns verification, what constitutes a rollback trigger, and what checks occurs immediately post-go-live. 

7
Post-go-live stabilisation 

The first ninety days represent a period of elevated control risk. Transaction volumes are real, users are still learning the system, and edge cases emerge that testing didn't anticipate. A structured verification plan focusing on high-risk transaction types and key reconciliations helps identify issues early. Continuous monitoring capabilities provide ongoing assurance and feed the issue remediation process. 

Patterns that signal elevated risk

Certain project characteristics tend to correlate with post-go-live compliance difficulties. 

Late involvement of control specialists.
When control expertise joins only during user acceptance testing, major design decisions are already fixed, limiting their impact. The value of control expertise is highest during design, when input shapes outcomes rather than merely documenting them. 

Heavy reliance on manual compensating controls. 
While compensating controls have legitimate uses, a landscape dominated by manual procedures suggests the ERP system isn't delivering the control automation that justified the investment. 

Disorganised evidence management. 
Test documentation scattered across email threads and personal drives, unclear version control, gaps in the audit trail create risk even when controls themselves function correctly. 

No traceability. 
Projects without clear links between control requirements and implementation decisions struggle to demonstrate intentional design, leaving gaps in assurance. 

The opportunity in transformation 

ERP transformation represents a genuine opportunity to strengthen controls, provided that strengthening is planned rather than hoped for. Legacy systems often carry years of accumulated workarounds and controls that made sense but no longer reflect current realities. A new implementation allows the design of controls aligned with today’s risks, regulatory expectations, and operational needs. 

The discipline required to document, test, and evidence controls during implementation creates foundations that support compliance for years to come. It requires investment: dedicated people, explicit governance, and willingness to treat control requirements with the same seriousness as functional requirements. The return shows up in smoother audits, reduced remediation costs, and confidence that the new system actually delivers what the business case promised. 

Bringing control expertise to your ERP transformation

Our Risk Advisory team works with organisations throughout the ERP lifecycle, from initial control impact assessments through post-go-live verification. We bring practical experience in application security, control integration, and audit readiness across major ERP platforms. 

If you're planning a transformation or navigating one already, don’t hesitate to reach out to our expert for a conversation on how controls fit into your approach.