Fragmented governance creates blind spots because controls, approvals, and monitoring are split across applications and teams. As ERP estates modernise, organisations need consistent policy enforcement, risk analysis, and audit evidence across old and new systems. Without that consistency, elevated access, risky transactions, and compliance gaps are harder to detect and easier to miss during change.
Why This Matters for Security Teams
ERP modernisation and cloud migration rarely fail because of a single control gap. They fail when access governance, GRC, and technical enforcement are not aligned across the old environment, the target platform, and the transition period in between. That creates duplicated approvals, inconsistent role definitions, weak segregation of duties, and evidence that no longer reflects actual risk. The result is not just audit friction. It is a real increase in the chance that privileged users, service accounts, and automated workflows retain access longer than intended.
From a security operations perspective, this matters because modern ERP programmes often combine replatforming, process redesign, and identity consolidation at the same time. If GRC teams are tracking controls in one system while IAM or PAM teams are enforcing them in another, exceptions can persist without clear ownership. Guidance in the NIST Cybersecurity Framework 2.0 reinforces the need for coordinated governance, risk management, and control execution rather than isolated point controls.
In practice, many security teams encounter the real failure only after a migrated workflow has already inherited excessive access, not through intentional review of the changed process.
How It Works in Practice
Fragmentation increases risk because ERP modernisation changes how identities, entitlements, and transactions are created, approved, and monitored. Old role catalogues may not map cleanly to cloud-native permissions, and control owners may lose sight of whether a given user, bot, or integration account still needs access. This is especially difficult when audit evidence, risk acceptance, and access recertification are managed through separate tools or spreadsheets.
A practical governance model needs one source of truth for policy intent and a reliable way to translate that intent into platform-specific enforcement. That usually means aligning business roles, technical entitlements, and control tests before cutover, then revalidating them after go-live. Security teams should check whether approvals, SoD rules, and privileged sessions are linked to the actual identity lifecycle, including non-human identities and automation accounts. The NIST SP 800-53 Rev 5 Security and Privacy Controls and OWASP Non-Human Identity Top 10 both support this kind of control discipline, especially where secrets, service identities, and delegated access can outlive the business process they were created for.
- Define control ownership across ERP, cloud, IAM, PAM, and GRC before migration starts.
- Map legacy roles to target entitlements and flag any access that has no business justification.
- Reconcile access reviews with actual system logs, not just approval records.
- Track exceptions separately so temporary migration access does not become standing privilege.
- Test SoD and privileged transaction rules in both environments during the transition window.
These controls tend to break down when migration teams customise roles late in the programme because the approval model can no longer keep pace with the system design.
Common Variations and Edge Cases
Tighter governance often increases migration overhead, requiring organisations to balance speed of delivery against the cost of stronger review, testing, and evidence collection. That tradeoff becomes sharper when ERP customisations are extensive or when cloud services introduce more dynamic permissions than the legacy platform allowed. In those cases, current guidance suggests using risk-based access tiers rather than trying to force every entitlement into a rigid legacy model.
There is no universal standard for this yet, especially where agentic workflows, API-driven integrations, and temporary migration accounts overlap. The key question is whether the organisation can prove who approved access, why it was granted, and when it will be removed. For systems handling financial reporting or regulated processes, aligning to ISO/IEC 27002:2022 Information Security Controls can help formalise access review, segregation, and supplier oversight expectations.
Edge cases often appear when a cloud migration preserves the old control language but changes the actual enforcement layer. That is common in hybrid ERP estates, where application roles, identity federation, and workflow approvals do not fail together. The safest approach is to treat migration as a control redesign exercise, not only a technical move, and to rebaseline risk after each major cutover.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST CSF 2.0 and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | GV.RM-01 | Fragmented governance is a governance and risk alignment problem across the migration lifecycle. |
| NIST SP 800-53 Rev 5 | AC-2 | Account lifecycle control is central when roles and permissions change across ERP and cloud. |
| OWASP Non-Human Identity Top 10 | NHI-05 | Non-human identities often retain access after process changes and create hidden governance gaps. |
Assign one accountable risk owner and align access governance to migration risk decisions.
