ERP Support Procedures for Regulated Companies

Publicly traded and highly regulated companies face intense scrutiny from regulators and auditors. Organizations subject to frameworks such as Sarbanes-Oxley (SOX), PCI DSS, FDA regulations, GDPR, CCPA, NIST, Basel III, and ISO 37301 must carefully manage how IT and support teams access production systems through quality ERP support procedures.  

When implementing or supporting a digital transformation project, we often see organizations with improper access controls or poorly designed support procedures which creates serious compliance and audit risks.  

These weak processes often remain in place until they are identified by internal auditors, external auditors, or regulators. At that point, management is forced into a defensive position trying to justify a security posture that may be difficult to defend.  

This article provides high-level guidance for executives, IT leaders, and compliance teams on how to design ERP support procedures that can withstand regulatory and audit scrutiny. 

Why Proper ERP Support Procedures Matter 

Support procedures are critical because they protect organizations from: 

• Unauthorized changes to production systems 
• Unauthorized access to sensitive data 
• Regulatory compliance violations 
• Audit findings and significant deficiencies 

The access escalation model described in this article is designed to minimize these risks while still allowing IT and support teams to troubleshoot issues effectively. 

We recognize that ERP support procedures and staffing models can vary significantly depending on the size of the organization.  Thus, if you have specific questions about the contents of this article and the adoption of these principles, we will offer a free 1-hour consultation to any organization.  

Typically, IT is responsible for designing and implementing ERP support procedures.   In some cases, ERP systems are implemented with minimal IT involvement, creating what is often called shadow IT. In these environments, support may be performed by personnel in finance, operations, or other departments. 

In this case, support may look different for those organizations, but the concepts below would be the same. 

Not all ERP Systems Are the Same 

Organizations using modern ERP systems need to consider the audit implications of their ERP support procedures.  One of the most common issues auditors identify is excessive access privileges for support personnel. In many organizations, support staff are granted far more access than is necessary to troubleshoot problems. 

To reduce this risk, organizations should follow a structured escalation approach to system access when investigating issues. 

Recommended ERP Support Escalation Model 

Support should follow a progressive escalation approach, starting with the least intrusive method and only increasing access when necessary. 

Recommended escalation procedures: 

1. Screen share with the end users who are having issues.   
2. View only access in the production environment 
3. Elevated access in a non-Production environment with redacted data 
4. Elevated access in a non-Production environment to replicate the issue 

Let’s dig into each of these in more detail: 

Level 1: Screen share with the end users. 

The least intrusive and lowest risk method for identifying an issue is to have the end user(s) who reported this issue demonstrate the issue via a screen sharing session.  Often, issues reported by end users are not system defects but a lack of understanding or training.  We call these issues “Functional Training Opportunities (FTOs)”.   

When a user doesn’t fully understand how to perform the activities, the next step is often referring to their manager or training team to take, re-take, or reinforce training. 

Security Consideration 

Screen sharing may expose Personally Identifiable Information (PII) or other sensitive data. Organizations may need to segregate support staff so that only authorized personnel can view sensitive information.

Level 2: View-Only Access in Production 

The next possible protocol for support would be to allow support personnel read-only or inquiry access to the production system.

View-only access allows support teams to:

• Review transaction data 
• Identify potential data anomalies 
• Understand the context of the issue 

However, read-only access does not allow support teams to replicate the issue, which may limit troubleshooting capabilities.

Level 3: Elevated Access in Non-Production (Redacted Data)  

A more advanced troubleshooting method involves using a non-production environment where sensitive data has been redacted or masked.

In this environment:

• PII and sensitive information are removed or masked 
• Support users can be granted elevated privileges 
• The issue can potentially be recreated without exposing real data

This model provides strong security controls while allowing deeper troubleshooting capabilities.

Level 4: Elevated Access in Non-Production With Production-Like Data 

This environment provides the most realistic troubleshooting conditions but also introduces the highest level of data exposure risk.

In some situations, organizations maintain a non-production environment containing production-like data that has not been redacted.

Before granting access in this environment: 

• The data owner should approve the exposure of sensitive data
• Access should be limited to authorized personnel 
• Monitoring and logging should be implemented 

In these cases, support users may receive access beyond what they have in production because the data owner has accepted the associated risks.

Impact on System Integrators Supporting ERP Implementations 

As you can see from this analysis, each of these four processes and access levels have different levels of risk and should have different levels of approval as it cascades to higher levels of access. 

Management needs to determine what levels are appropriate, when they are appropriate, and put in place the necessary approvals and controls for each level of escalation. 

Impact on System Integrators Supporting ERP Implementations 

During ERP implementations, organizations often rely on System Integrators (SIs) to configure and deploy the system.

One of the most common control failures occurs after go-live, when system integrators continue to retain excessive access to production environments.

Common problems include: 

• Broad administrative privileges for SI personnel 
• Ability for SI teams to assign roles or permissions 
• Lack of oversight or approval processes 
• Weak change management controls 

These practices can create significant audit exposure. 

Many ERP platforms do not provide a full audit trail for all inserts, updates, and deletions, making it difficult to hold external vendors accountable for changes made within the system. 

Potential Audit Findings from Excessive Access 

When system integrators retain excessive access, auditors may identify Significant Deficiencies (SDs) such as:

1. Overprovisioned Access

Users receive roles or privileges that were not properly approved or exceed what is necessary for their job responsibilities. 

2. Change Management Failures

Changes are made directly in production without following formal change management procedures.

Without adequate mitigating controls, auditors may have no choice but to report these issues to management. 

Designing a Defensible ERP Support Model 

To create a support structure that withstands regulatory and audit scrutiny, management should: 

• Define clear escalation procedures for access levels
• Require approvals for higher-risk access levels 
• Restrict system integrator access after go-live 
• Implement strong change management controls 
• Protect sensitive data in non-production environments 
• Monitor and audit privileged access activity 

These controls should apply whether support is performed by: 

• Internal IT teams 
• Business users 
• System integrators 
• Managed service providers 

Conclusion 

A structured ERP support escalation model is essential for maintaining a well-controlled and accountable environment.

By starting with low-risk troubleshooting methods and escalating access only when necessary, organizations can protect: 

• Production environments 

• Sensitive data 

• Regulatory compliance posture 

Ultimately, management is responsible for implementing ERP support procedures that safeguard production systems and ensure sensitive data is protected across all environments — including development, testing, and support systems.

Organizations that adopt these best practices will be significantly better positioned to pass audits, satisfy regulators, and maintain strong internal controls.