What breaks when organisations do not monitor application controls after an ERP cloud go live?

Without ongoing monitoring, control failures can hide inside normal business operations. Segregation of duties violations, excessive access, and unusual transaction patterns may persist until audit findings, fraud, or process errors force attention. Continuous monitoring is what turns controls from a one time design exercise into a living governance capability that can be tested and improved.

Why This Matters for Security Teams

An ERP cloud go live is usually treated as a control milestone, but it is really the start of continuous exposure. Once users, service accounts, integrations, and automation begin operating at scale, application controls can drift faster than change boards and audit cycles can track. That is why continuous monitoring matters: it is the only way to detect when segregation of duties, privileged access, and transaction controls are still “working” on paper but no longer functioning in production.

Security teams often underestimate how much post go live behaviour changes normal control assumptions. A role that was approved during design may become overbroad after business exceptions accumulate. A workflow control that passed testing may fail quietly when an interface retries, a batch job is resubmitted, or a manual override becomes routine. The NIST Cybersecurity Framework 2.0 reinforces that governance and monitoring must operate continuously, not only at deployment. In NHI terms, this is the same reason NHI Lifecycle Management Guide treats identity and access as living controls rather than one-time setup tasks.

In practice, many security teams discover control gaps only after an audit exception, a fraud review, or a failed business process has already exposed the weakness.

How It Works in Practice

Post go live monitoring should focus on whether application controls still behave as designed under real business load. That means tracking not just access rights, but the transactions, overrides, approvals, and exception paths that reveal whether the ERP control environment is actually effective. A control can remain technically enabled while its intended safeguard is bypassed by process change, temporary access, or an integration account.

For security teams, the practical model is to combine access review, transaction analytics, and exception monitoring into one operating rhythm. The strongest programs look for patterns such as incompatible role combinations, dormant privileged accounts that suddenly activate, unusual approval chains, and repeated manual overrides. The goal is not to drown the team in alerts, but to surface control drift early enough for remediation.

• Compare actual ERP role usage to approved business role design.
• Monitor privileged and emergency access separately from standard user access.
• Flag SoD conflicts that emerge through new integrations or process workarounds.
• Review high-risk transactions, overrides, and journal entries on a recurring basis.
• Validate that compensating controls are still operating when primary controls fail.

Continuous monitoring also helps separate genuine control failure from expected operational change. That distinction matters because ERP environments evolve through patches, new modules, acquisitions, and workflow redesigns. A post go live control that never changes is usually a control that is no longer aligned to reality. Guidance from NIST Cybersecurity Framework 2.0 and the NHIMG Top 10 NHI Issues both support the broader operational principle that identity and access controls must be measured against actual runtime behaviour, not static design intent.

These controls tend to break down when ERP integrations, shared service accounts, and emergency access procedures grow faster than the monitoring rules that are meant to govern them.

Common Variations and Edge Cases

Tighter monitoring often increases operational overhead, requiring organisations to balance stronger assurance against the cost of false positives and manual review. That tradeoff is especially visible in large ERP estates, where finance, procurement, HR, and supply chain teams each create legitimate exceptions that can look suspicious in isolation.

Best practice is evolving on how much automation is appropriate. Some organisations rely on periodic detective controls and exception sampling, while others use near-real-time analytics for critical processes only. There is no universal standard for this yet, but current guidance suggests prioritising the controls that protect cash movement, master data, approval integrity, and privileged change paths. The NHIMG Ultimate Guide to Non-Human Identities is relevant here because ERP controls often depend on service accounts and automated workflows that behave like NHIs in practice.

One important edge case is post merger or multi-entity ERP rollouts. In those environments, a control may appear effective in one legal entity but fail when replicated across regions, subsidiaries, or chart-of-account variations. Another is audit reliance on configuration screenshots rather than transaction evidence. Screenshots show intent, not operating effectiveness. For high-value processes, continuous evidence from logs, approvals, and exception reports is the safer basis for assurance. The most useful external pattern is to align monitoring with the NIST Cybersecurity Framework 2.0 so that governance, detection, and response stay connected after the go live date.

Related resources from NHI Mgmt Group

• How should security teams embed ERP controls into business processes instead of retrofitting them after go-live?
• What breaks when organisations try to govern cloud access with proxies or bastions alone?
• What breaks when organisations do not govern third-party application access closely?
• How should public sector organisations evaluate identity security controls for cloud services under GovRAMP or similar frameworks?