SoD (Segregation of Duties) is your best line of defense in ERP security. Let’s talk about why it is so important and how your team can manage role conflicts across applications.
Segregation of Duties is an internal control that prevents a single person from being solely responsible for business process tasks. Giving one person control of entire business processes can allow error and possible fraud. The result would be disastrous for your business. You could risk financial loss, reputational damage, and compliance violations. For example, take the process of paying vendors. You don’t want to give one person the capability to create and pay vendors. You’d run the risk of the user creating and paying themselves as a vendor.
How can your organization protect itself from the danger of too much responsibility falling to one person? This article will discuss Segregation of Duties (SoD), an internal control that’s critical in helping today’s businesses minimize risk across their organization and applications.
Pat Wadland, Director of Product at Fastpath, talked with Boris Agranovich of Global Risk Community. They discussed several issues related to managing SOD risks across multiple business applications. Here is some insight from that interview:
Misconceptions about SoD
We ask companies how they assess their segregation of duties within their ERP applications. Many review the names of all the roles assigned to end-users. They base their assessment on those labels to determine who has access to the company’s key business activities. They may feel confident that they know just what each role can do. And if everything is going well, they may not see the need to obtain any further information about the roles themselves. But activities such as maintaining the vendor master or posting journal entries need to be secure.
The configuration of roles can change, so there has to be a better approach. And there must be a protocol for addressing SoD conflicts.
The term “role” may differ depending on the ERP. For example, Dynamics and SAP call it Role while Oracle calls it Responsibility, Workday calls it Security Group, and Oracle Cloud calls it Job Role. They are essentially the same. They designate what tasks will be permitted for the person with the assigned role.
SoD conflicts are not driven by the names of the roles themselves but by the underlying security objects within the roles. Therefore, organizations need to know the underlying security objects within each role, down to the most granular level. Only then can they properly assess SoD and other ERP application access risks.
Regardless of the ERP solution, it is necessary to examine not only the user-role assignments but also the configuration of security objects within each role. Properly analyzing these will help you determine SoD conflicts within your ERP.
provides tools that analyze access in your business software, by user or role, down to the lowest security level. Conflicts or risks associated with access are detected and reported. Fastpath’s SoD module will also evaluate inter-application conflicts to provide total SoD management. This is crucial in today’s multi-application, cross-application business environment.
First steps for risk managers
Risk managers must work with their teams to identify high-level, high-risk business activities within their company. That will include everyone from managers and subject-matter experts on down. For instance, most risk assessors consider vendor master data a high-risk area of P2P (Procurement to Pay). So, that should be a focal area when configuring your accounts payable or procurement system.
Dig deeper with a thorough business process analysis to identify areas of risk. A scoping assessment will begin with the high-risk areas and proceed through all the access roles.
What else can risk managers do?
It’s dangerous to rely entirely on a System Integrator or IT to handle the security of your business applications. That is not their primary job function. When organizations implement a new ERP, HCM, CRM, or another critical business system, they often rely on the system integrator to design system security. However, the organization itself should be responsible for this. They should depend on the system integrator for guidance during the implementation, not during Go Live and beyond.
It is also inappropriate to rely on IT to sort out SoD conflicts brought to light during analysis. Business owners, managers, and process owners know the type of access to the system each employee needs and is entitled to.
Effective SoD monitoring and remediation is a product of management, users, and IT, benefiting from a thorough internal audit. Even though IT may implement the changes or desired remediation, security design should primarily come from business process owners.
Would you like to know more about Segregation of Duties across applications?
.
To learn about ® Suite, which includes a module for SoD analysis, our experts at Fastpath.
By Fastpath,
