Security, Risk, and Compliance in EnterpriseOne

This article presents information on corporate IT governance and discusses the role that enterprise applications, such as JD Edwards EnterpriseOne, play in this important area. Introduction to GRC Let’s start with a definition of governance, risk, and compliance (GRC). CIO Newsletter defines GRC as a strategy for managing an organization's overall governance, enterprise risk management and compliance with regulations.[i] GRC’s main components include:

• Governance: Ensuring that organizational activities, like managing IT operations, are aligned in a way that supports the organization's business goals.
• Risk: Making sure that any risk (or opportunity) associated with organizational activities is identified and addressed in a way that supports the organization's business goals. In the IT context, this means having a comprehensive IT risk management process that rolls into an organization's enterprise risk management function.
• Compliance: Making sure that organizational activities are operated in a way that meets the laws and regulations impacting those systems. In the IT context, this means making sure that IT systems, and the data contained in those systems, are used, and secured properly.

As corporate data and information systems proliferate in this time of increased digitization of business, GRC continues to take on increasing importance for all organizations, regardless of industry, size, business model.Enterprise applications, as defined in Gartner Group’s Information Technology Glossary, are:“…designed to integrate computer systems that run all phases of an enterprise’s operations to facilitate cooperation and coordination of work across the enterprise … to integrate core business processes (e.g., sales, accounting, finance, human resources, inventory and manufacturing). “ [ii]Enterprise applications present a unique security scenario for organizations, and this scenario must be considered as part of your GRC strategy.Segregation of Duties and Enterprise ApplicationsSegregation of Duties (SoD) for enterprise applications is part of an organization's GRC framework. As a general principle, security is about risk management. What risks are you trying to reduce through security design and compliance in your enterprise application?Some important considerations include:

In the Enterprise Resource Planning (ERP) software world, we put the focus on application risk, and we design controls and policies specific to what the application does. This may have overlap with operational or other risk areas, but those controls cannot be designed the same way that controls for the ERP can.Additionally, a major compliance goal for SoD is to increase visibility about who in the organization has potentially risky access and to provide decision-makers with information about what to change to improve compliance. What does this mean for EnterpriseOne?First, it is important to remember that by default EnterpriseOne is an open system. If you did nothing or failed to enter the appropriate security records, users will have implicit access to any function in EnterpriseOne (whether you are licensed for it or not, but that’s a story for another day).Let's assume you have the security designed properly and have the All Doors Closed settings correctly in place. Access is granted back through individual applications or a generic *ALL setting. The access is attached at one of three levels:

1. Individual User IDs
2. Roles that are then assigned to users
3. *PUBLIC - a generic "user-id" from which all users inherit access.

The very nature of EnterpriseOne as an ERP system means that many functions run through the same system. Your ERP system likely has some combination of Financials, Human Resources, Operations and Logistics, and Sales and Marketing functionality (and therefore data) in use.This results in many different user communities having access to the same system and users who could have access to multiple functions in the same system. Bringing these thoughts back to risk, if data in any of the modules can be manipulated by a single user, this presents a fraud risk.Segregation of Duties within enterprise systems doesn't generate the same buzz that data privacy and cyber-security threats have but should still be top of mind for organizational leaders, because the ERP system plays a central role on both fronts.If we think of Segregation of Duties in the GRC context, it often plays out as described below.

Implementing Segregation of Duties in EnterpriseOneIt is important to note that EnterpriseOne does not have any built-in Segregation of Duties capabilities. Oracle has deferred to the ecosystem of third-party vendors to provide this functionality. However, the process of implementing SoD remains the same: identify and document the policies and risks that need to be accounted for.I find it helpful to start with the risks. Like any solution, identifying the problem to be solved is critical. When risks are defined, you can align them to different functions in EnterpriseOne. The functions then map to various applications available in EnterpriseOne. One point I like to make is on the mapping of applications to functions. Look for any application or UBE in the Object Librarian that contributes to the function. Don't look only at the existing security design. As we stated above, since EnterpriseOne is by default an open security model, users could have access to an object that allows them access to perform a function, even if it isn’t explicitly defined in the security model.The SoD design will include risk statements, a listing (or matrix) of which functions should not be performed by the same person (the controls), and the list of objects associated with each function. Plug this into the tool of your choosing (for example, Q Software) and you should see which users have access to functions that should be segregated and ideally where that access is coming from. Because of the complexity of the evaluation, it is recommended to use a third-party tool and not try to manage this in Excel. There are simply too many layers to consider.Armed with the information about who has access and how they are getting the access, you have decisions to make on remediating the issues.If there is security at the *PUBLIC level that is causing SoD issues, we recommend addressing that first.Then, anything at the user level should be moved into a role. Not only will this contribute to the resolution of SoD issues, but it is also best practice.Finally, with the access coming from the roles, there are usually three choices to resolve the issue:

1. If access to both functions within a single control comes from the same role, the security definition of that role must be adjusted
2. If access to both functions within a single control comes from different roles, the security definition for one of the roles could be adjusted or the roles that are assigned to the user can be switched to change their access
3. If the access is needed for a particular user and this access is granted approval, record this approval against the control using a mitigation note that includes appropriate sign-off and any external controls in place

This should all be wrapped into a business process with defined timelines and participants. This will help set expectations and clarify roles and responsibilities.Supporting Compliance Activities in EnterpriseOneSetting up and defining a Segregation of Duties model for EnterpriseOne is not a one-time event. Similarly, you don’t run a validation once and leave it as that.Primarily, changes to the organizations usage of the ERP system (including newly developed custom objects) need to be evaluated for inclusion in the SoD model. If a new object is added that impacts one of the functions identified in the risk statements, be sure to update the function before the next validation.Running the validation and preparing the data/reports for action by the decision-makers is another task that requires attention. It should be on a regular schedule (defined in the business process) and administrators should be aware any new or unusual results in advance of distributing the review so they can help explain or provide context.If your services provider has the security expertise and knowledge of your system, they can be a great resource to help you work with these reviews. They can help keep you on schedule and provide insights into the results. Ideally, they can provide advice on options for issue resolution and provide training or support for your third-party software compliance tool. ConclusionSecurity and related controls are about risk. If access to certain functions within the enterprise application (ERP) does not present risk to the organization, then question if you need to evaluate it.Once you have a good understanding of the various risk points, work backwards to define the controls you need to evaluate to meet compliance needs.Don’t forget to spend time defining the business process for generating, reviewing, and addressing the Segregation of Duties information. This is not a one-time event and should be built into your regular operating procedures.[i] Lindros, K. (2017, July 11). What is GRC and why do you need it? Retrieved January 11, 2021, from https://www.cio.com/article/3206607/what-is-grc-and-why-do-you-need-it.html[ii] Source: https://www.gartner.com/en/information-technology/glossary/enterprise-applications

Author – Matt Vanderkooy, ERP-One Consulting