<img height="1" width="1" style="display:none;" alt="" src="https://dc.ads.linkedin.com/collect/?pid=523033&amp;fmt=gif">

What’s in a Name? It’s not the role's name; it’s what the role can do!

Recently, Pat Wadland, Director of Product at Fastpath, had a conversation with Boris Agranovich of Global Risk Community. They discussed several issues related to the management of Segregation of Duties risks across multiple business applications. Below is an excerpt from that interview:

 

What do you think is the biggest misconception businesses have about Segregation of Duties?

When companies hear the term “segregation of duties” (SoD) and are asked how to assess them within their ERP applications, many seem to think all that it entails is manually reviewing the names of all the roles assigned to end users and, based purely on those names, determining if users have access to the company’s key business activities (such as maintaining the vendor master or posting journal entries). The logic here is that the reviewers are confident that they “just know what the roles can do” because they have been with the company for so long or do not think they need to obtain any further information about the roles themselves.

However, since the configuration of roles changes over time, this is clearly not the correct approach, nor does it address the underlying root cause of SoD conflicts. While the term “role” may differ depending on the ERP (e.g., D365FO/SAP = Role, Oracle EBS = Responsibility, Workday = Security Group, Oracle Cloud = Job Role, etc.), the essential ask is the same thing: what tasks can this person do with his or her assigned roles?

SoD conflicts are not driven by the names of the roles themselves but by the underlying security objects within the roles. Therefore, companies must obtain information regarding the underlying security objects within each role, down to the most granular level, to properly assess SoD and other ERP application access risks.

Similar to “role”, the term “security object” differs depending on the ERP (e.g., D365FO = Menu Item Display or Action, SAP = TCode, Oracle EBS = Function, Oracle Cloud = Privilege, etc.). However, regardless of the ERP, it is necessary to look at not only the user-role assignments but also the configuration of security objects within each role to properly analyze and determine all of the true SoD conflicts within an ERP.

Fastpath provides tools that analyze access in your business software, by user or role, down to the lowest security level and reports conflicts or risks associated with the access. Fastpath’s Segregation of Duties module also can evaluate conflicts across applications to provide full SoD management in today’s multi-application cross-application environments.

What actions can risk managers start doing now?

If they have not done so already, risk managers should work with their teams, managers, and subject matter experts to identify the key, high-risk, high-level business activities within their organization relevant to SoD. For example, most companies consider vendor master data to be a high-risk P2P area. So, along with setting up the critical configurations in your accounts payable or procurement system, whether SAP, D365FO, Coupa, Oracle, etc., that could be one area of focus. Then, go a bit deeper via business process walkthroughs or scoping assessments to identify the more granular key areas of access risk. Start with the highest risk areas first and work your way down.

Bottom line, if you have not already performed a full risk assessment, I would start with that for building your SoD controls, forming the foundation for a sound security environment.

What changes do you think risk managers should make in their processes?

Many companies rely too much on a System Integrator or IT to handle the security of their business applications when, in fact, that is not their primary job function. For example, when a company implements a new ERP, HCM, CRM, or other critical business system, they often look to the system integrator to determine the system security design. But, in reality, it should be the organization itself driving this responsibility and leveraging the system integrator only for guidance during the implementation, not for Go Live and beyond.

Risk professionals also tend to rely on IT to figure out the SoD conflicts found in their reports when, in fact, that guidance should come from the business managers or process owners since they know the type of access each employee should have in the system. Effective SoD monitoring and remediation should be a harmony of the business, IT, and internal audit. These are complex security elements that should not be done strictly by IT. Even though IT might implement the changes or desired remediation, security design should primarily come from business process owners.

 

Click here to listen to the entire podcast, Cross-Application Segregation of Duties, with Pat Wadland at Fastpath.