Include security / compliance at the start of ERP Implementations

New technologies and deployment options have companies rethinking their old, on-premises ERPs. In fact, according to g2.com, nearly 50% of companies are planning to or are already going through an ERP implementation or upgrade.

Unfortunately, for many of these companies, bringing in the compliance and security team is almost an afterthought.

Failing to include the Compliance team early on in your implementation efforts can be costly. Far too often, the compliance team is left out or not even considered during an ERP implementation or upgrade until it is too late. It appears that they assume that once the implementation is completed, then the compliance team can go about the task of configuring the security and user roles and permissions. This leads to costly mistakes and prolonged risk exposure that could have been avoided from day one of the system going live.

Security and access management governance should be one of the cornerstones to implementing a compliant ERP solution.

The following outline breaks down the access management governance principles that guide compliant ERP implementations, regardless of the specific ERP being used:

• Define the Ruleset. Identify the requirements of the new system for inclusion in the ruleset.
• Analyze Security Design. Evaluate the access risk to ensure security entitlements are designed in a compliant manner.
• Define Emergency Access. Define when emergency access should be used, what access should be restricted, who should approve the assignments and audit logs, and the frequency of reviews.
• Analyze Test IDs and Go-Live User Mapping. Identify access risk before critical phases in the project to prevent additional clean-up efforts down the road to ensure the application works as expected with a compliant security model during testing.
• Establish/Map Mitigating Controls. Evaluate risk and develop mitigating controls prior to go-live. When risks are identified after go-live, a mitigating or compensating control must be developed and tested/validated, as well as a potential lookback to prove fraudulent activities were not performed during the exposure period.
• Provisioning and Access Certifications. Establish critical processes such as compliant user provisioning/de-provisioning and periodic access certifications.
• Go-Live Support and Risk Analysis. Once the preceding activities are completed, combining them with other implementation success factors (for example, organizational change management, thorough testing, successful data loads, etc.) will set the organization up for a successful go-live.

When compliance is not included before going live on a new system, we often see the initial risk analysis uncover large volumes of Segregation of Duties (SoD) and Critical Access (CA) conflicts. Addressing this risk is no easy task. Typically, security must be redesigned, testing reperformed, user mapping updated, and more. In addition, compensating controls or additional manual tasks must be performed to prove fraudulent activities did not occur while the exposure was present.