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.
What Stops Being Visible After an ERP Cloud Go-Live
Once an ERP cloud environment is live, the control environment can look stable even while key application controls are already drifting. That is the core problem: users, roles, workflow approvals, journal controls, and exception handling keep operating, but without monitoring there is no reliable way to see when they stop behaving as designed. For organisations, the risk is not only noncompliance, but also silent process degradation that becomes expensive to untangle later.
In practice, many organisations discover application control drift only after audit testing, month-end reconcilations, or a failed business process exposes the issue.
Cloud ERPs make this easier to miss because the application often appears “up” and transaction processing continues normally. The hidden failure is usually not availability. It is governance visibility. A role that should have been removed may remain active, an approval path may be bypassed by an exception, or a control owner may assume a workflow is operating because no alert has ever challenged that assumption. The question is therefore less about whether the ERP works, and more about whether the control design still matches real use.
How Application Controls Drift in Day-to-Day ERP Operations
Application controls are the rules embedded in the ERP process layer: access approvals, segregation of duties, posting limits, workflow routing, master data checks, and other transaction controls that shape how records are created and approved. After go-live, these controls are exposed to organisational change. New roles get added, emergency access is granted, business process workarounds appear, and configuration changes are made to support operational pressure. Without monitoring, these changes become part of the normal pattern and are treated as expected behaviour.
The practical breakdown usually happens in three ways. First, control ownership weakens because no one is assigned to review whether the control still functions as intended. Second, the control is technically present but no longer effective, often because an exception path or overbroad role has expanded access. Third, the control operates, but nobody is watching the output signals that would reveal failure, such as duplicate approvals, unusual postings, or recurring manual overrides.
- Access controls can remain too broad after testing or cutover support ends.
- Workflow controls can be bypassed through temporary permissions that never expire.
- Transaction-level controls can be undermined by master data changes or configuration drift.
- Detecting these failures late usually turns a control issue into an audit, finance, or fraud issue.
This is why post-go-live monitoring is not just a technical activity. It is part of control assurance, because application controls only stay trustworthy when someone is comparing expected behaviour to actual behaviour on a continuing basis. For ERP environments, the relevant checks often combine access review, exception review, transaction analytics, and evidence that remediation actually happened. The OWASP Non-Human Identity Top 10 is not an ERP control framework, but it is useful where automated accounts, service identities, or integrations are part of the control path and can silently expand access or bypass human approval. Where monitoring is absent, the guidance breaks down because the organisation can no longer distinguish a designed control from a control that merely appears to exist.
Where Monitoring Fails: Exceptions, Workarounds, and Control Ownership Gaps
Tighter post-go-live oversight often increases operational overhead, requiring organisations to balance control confidence against the effort of reviewing exceptions and transaction signals. That tradeoff matters because many ERP teams treat go-live as a project milestone rather than the start of an ongoing control lifecycle.
The most common edge case is the temporary workaround that becomes permanent. A business user may be given elevated access to keep operations moving, a control may be waived during hypercare, or a workflow step may be softened to reduce friction. Those decisions can be legitimate in the short term, but they become risky when no one revisits the exception. The same issue applies when controls are monitored only at a high level. A dashboard may show that the process is “healthy” while the underlying transaction population contains repeated override patterns or unapproved access changes.
There is also a governance gap that appears in shared environments. ERP application owners, process owners, and internal control teams may each assume another team is reviewing the evidence. When ownership is unclear, controls are rarely verified with enough discipline to catch slow drift. Guidance is not fully consistent across organisations on the ideal monitoring cadence, but there is broad agreement that controls tied to financial reporting, privileged access, and workflow approvals deserve more frequent review than controls with low business impact.
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 and MITRE ATT&CK address the attack surface, NIST CSF 2.0 and CIS Controls v8 set the technical controls, and ISO/IEC 42001:2023 define the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | DE.CM-1 — Monitoring for Anomalies and Events | Post-go-live control drift requires ongoing detection of abnormal behavior. |
| Recommendation — Establish continuous monitoring to detect control drift before it reaches audit or loss events. | ||
| CIS Controls v8 | 5.3 — Detect and Remediate Unauthorized Software and Control Changes | ERP control failures often emerge through unauthorized or unreviewed changes. |
| Recommendation — Track control-relevant changes and remediate unauthorized exceptions quickly. | ||
| ISO/IEC 42001:2023 | A.3 — Internal Organization | Ongoing control ownership and accountability are central after ERP go-live. |
| Recommendation — Assign accountable owners for post-go-live control monitoring and escalation. | ||
| OWASP Non-Human Identity Top 10 | NHI-06 — Lifecycle and Offboarding | Automated identities and integrations can quietly expand ERP access paths. |
| Recommendation — Review non-human accounts to prevent lingering access from bypassing ERP controls. | ||
| MITRE ATT&CK | T1078 — Valid Accounts | Excessive or lingering access in ERP often manifests as abuse of legitimate accounts. |
| Recommendation — Hunt for valid-account misuse when ERP transactions or approvals look unusual. | ||
Practitioner Guidance
What to prioritise: Focus first on the controls whose failure would remain invisible to business users, especially access, SoD, approval routing, and exception handling. Those are the controls most likely to degrade quietly after go-live.
What to verify: Confirm that each control has an owner, a review cadence, and an evidence source that is independent of the person performing the transaction. If a control cannot produce reviewable evidence, it is not being monitored in any meaningful sense.
Decision rule: If a post-go-live exception is still active after hypercare, treat it as a control risk, not a project convenience. Temporary access and waived workflow steps should expire by default unless they are explicitly re-authorised.
What practitioners underestimate: Many teams assume that successful processing means successful control operation. In reality, process continuity can conceal control failure for months, which is why the first reliable signal is often an audit query, not an operational alert.
Practitioner takeaway: The key judgement is to monitor controls as living operating conditions, not as static design artifacts; once that distinction is lost, ERP assurance tends to fail quietly before it fails visibly.
Related resources from NHI Mgmt Group
- How should security teams embed ERP controls into business processes instead of retrofitting them after go-live?
- How should organisations build security and application controls into an ERP cloud implementation from the start?
- How should organisations discuss segregation of duties and sensitive access before an ERP cloud go-live?
- How should organisations plan for IGA maintenance after go-live?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 7, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
