How should security teams assess risk before moving ERP controls to the cloud?

What changes when ERP controls move into a cloud operating model?

ERP controls do not disappear in the cloud, but the control plane changes. The first assessment should separate the business objective of each control from the mechanism used to achieve it, then test whether that mechanism still works when infrastructure, identities, logging, and change paths are shared with a cloud provider. That means checking control design, not just control intent.

For ERP environments, the most important categories are usually access governance, configuration control, segregation of duties, financial reporting integrity, and evidence retention. A control that was effective through local admin rights or static network boundaries may become weaker once administration is delegated through cloud consoles, APIs, or integrated platforms. The assessment should therefore ask whether the cloud design preserves the same assurance outcome, not whether the old checklist can be copied across unchanged.

Cloud control testing is also about dependency mapping. If an ERP control depends on a logging pipeline, a configuration baseline, or a privileged approval workflow, the team needs to know which parts remain under company control and which parts now depend on shared services, provider settings, or automation. That distinction drives the migration decision because a control can look complete on paper while losing auditability, timeliness, or enforcement in practice.

Which control areas deserve the deepest review first?

Start with the controls that protect financial data, privileged access, and application configuration because those three areas determine whether ERP integrity survives the transition. Cloud migration often changes where approvals happen, how privileged changes are made, and how exceptions are detected. If those control paths are not revalidated, the organisation may preserve the application while weakening the assurance behind the application.

Access controls deserve special attention because ERP risk often comes from over-broad roles, inherited entitlements, and emergency access that was never redesigned for cloud operations. The team should verify that role design, segregation of duties, and privileged approval flows still align with the way administrators, support staff, and automation actually operate in the cloud. A control is only useful if it can still prevent, detect, and evidence inappropriate access after the migration.

Configuration controls need the same treatment. Cloud ERP programs often introduce policy-as-code, infrastructure templates, and platform defaults, which can be stronger than manual controls, but only if they are governed and monitored. If configuration changes can be made outside the intended pipeline, or if provider defaults override enterprise baselines, the control is weaker than the on-premise version even when the interface looks modern.

Business process controls are another common blind spot. Order approval, invoice validation, master data changes, and journal posting controls may still exist, but the evidence trail and timing may change once the ERP stack relies on cloud-native integrations or managed services. Teams should test whether the cloud environment preserves the control objective, not merely whether the workflow still completes.

Risk and Threat Considerations

ERP migration to the cloud creates risk when teams assume that existing controls will behave the same way after identity, administration, logging, and automation are reimplemented in a shared operating model. The main exposure is control drift, where a control remains documented but no longer enforces the same financial, access, or configuration assurance.

Failure mechanism: The control fails when privilege models, cloud defaults, or automated change paths bypass the original approval, segregation, or monitoring logic. That can produce silent over-privilege, unreviewed configuration change, or incomplete evidence for auditors and business owners.

Impact: The organisation may face financial misstatement risk, weaker fraud detection, slower incident investigation, and migration rework after go-live. In the worst case, the cloud design expands blast radius because a single access or configuration weakness affects multiple ERP environments or business units.

Practitioner Guidance

What to verify: Confirm that each ERP control still has a clear owner, an enforceable mechanism, and testable evidence in the cloud environment. If the control depends on manual review, insist on proving that the review remains timely and complete after automation, not just that a report exists.

Decision rule: If a control cannot be demonstrated in the target cloud model without relying on the old on-premise boundary, treat it as a redesign item before migration approval. If the control works only through exception handling, require a compensating control and a documented exit plan.

Practitioner takeaway: The right question is not whether ERP controls can be moved, but whether they still create the same assurance when identity, configuration, and evidence now depend on cloud-native operating paths.

Related resources from NHI Mgmt Group

• Why do cloud ERP transformations create risk when security teams focus on migration before controls?
• How can teams tell whether cloud data security controls are actually reducing risk?
• How should security teams assess identity risk before an acquisition closes?
• How should security teams assess supplier cyber risk before onboarding?