ITGCs After Go-Live: Why the Control Environment Slips

Organizations invest significant time designing controls during major ERP, HRIS, and financial systems implementations. Roles are defined, test scripts are executed, approvals are documented, and implementation teams spend months preparing for production.

Then the system goes live.

In our experience, most post-go-live control deficiencies are not the result of poor design. They emerge during the transition from implementation to operations, when project teams leave, priorities shift, and business users begin managing real-world issues.

Production environments rarely remain static for long. Emergency access is granted to support hypercare activities. Temporary roles remain in place because the business still needs support. Changes are expedited to resolve issues during financial close. Interfaces that were intended to be temporary remain in service months longer than planned.

None of these situations are unusual.

However, each one introduces potential control risk and creates evidence that may eventually be reviewed by internal or external auditors.

Where the Control Environment Typically Weakens

Three IT general control areas tend to experience the greatest pressure immediately after go-live.

Access Management

User provisioning may continue through established ticketing processes, but user access reviews are often still based on implementation assumptions rather than actual production usage.

Hypercare access is another common challenge. Elevated privileges granted during stabilization are frequently intended to be temporary, yet organizations often struggle to remove them once day-to-day operations begin.

Change Management

During implementation, the system integrator's processes often drive change management activities. After go-live, responsibility shifts to the organization.

Many companies discover that they inherited a technology platform but never fully established the governance processes needed to manage ongoing changes. Procedures that worked well during the project do not always translate into sustainable operational controls.

Computer Operations

Project teams typically pay close attention to interfaces, scheduled jobs, backup procedures, and monitoring activities during implementation.

After go-live, those responsibilities must transition into repeatable operational processes with documented ownership, escalation procedures, and supporting evidence.

Without that transition, organizations may find that important operational controls exist conceptually but not consistently in practice.

A More Durable Approach

Organizations can reduce post-go-live control issues by treating hypercare as a control transition period rather than simply a support period.

Practical steps include:

• Validating the actual user population before completing the first access recertification rather than relying on implementation design assumptions.
• Defining change management criteria that business and technology teams can consistently apply, including during high-pressure periods such as financial close.
• Reviewing control evidence during the first one or two close cycles using the same level of scrutiny an external auditor would apply.

This creates an opportunity to identify gaps while implementation resources, system knowledge, and project documentation are still readily available.

The Most Important Window

The first two close cycles after go-live often reveal more about the long-term health of the control environment than the final phase of implementation testing.

By that point, production activity is occurring, operational teams have assumed responsibility, and real business scenarios are testing the control framework.

After that window closes, organizations can still address issues, but understanding what happened often requires reconstructing events from system logs, tickets, and historical evidence.

It is far easier to establish a sustainable control environment during the transition to operations than it is to rebuild the control story months later.