Working with hundreds of business customers over the years, we have learned that if a company is large enough and complex enough to need SAP for ERP, it’s more than large enough to require Segregation of Duties (SoD) controls. SoD is designed to prevent a single person from performing multiple duties that allow him or her to violate a regulation, and is often used to prevent fraud. SoD also applies to activities like environmental inspections, healthcare processes and more. Compliance schemes, with Sarbanes Oxley (SOX) being the most prominent, require minimizing SoD risks in SAP.
A Brief Overview of Segregation of Duties (SoD)
SoD is tied to transactional workflows. For example, if your company hires a vendor to perform a service, someone in your company needs to set up that vendor in SAP so the vendor can get paid for invoices you receive. Your employees are responsible for drafting and approving purchase orders (POs), receiving and approving payments (Payables) and finally, issuing and signing checks to pay vendors.
For each step in this transaction workflow, there’s a person and a software function on the SAP platform. There’s also the potential for SoD risks in SAP and ultimately fraud. If one employee can set up the vendor in SAP, write the PO, approve the invoices and sign checks, that employee has the means to embezzle funds. This may not be a pleasant topic, and in general, most people perform these duties with care and integrity. However, as experience has shown, when there’s the potential for abuse, there is abuse more often than people want to admit. To prevent fraud, accounting principles hold that you should separate, or segregate the various duties involved in a transaction workflow.
SoD Roles and Responsibilities
SoD works by means of role-based responsibilities in the transaction workflow. In the vendor-PO-invoice flow, the roles would correspond to each critical portion of the job function. Each portion (e.g. approve the PO) should correspond to a role with specific duties, aligning with a suitable SAP security model that satisfies the separation of these duties.
Each role then needs to correspond to a specific system usage capability. Someone who can set up vendors should only be able to access the “vendor set up” function in SAP. A user with this role would be prohibited from accessing the “PO approval” function, and so forth. By limiting employees to such defined roles, it is possible to reduce SoD risks in SAP.
What are SoD Risks in SAP and SoD Violations?
When we look at SoD in the context of a finite, familiar transaction like paying a vendor, it makes inherent sense. What could be so hard about it? The problem arises from organizational and transactional complexity. Big organizations, as well as small organizations with a lot of locations and teams, tend to create complicated SoD scenarios.
There could be thousands of users in an SAP system, with a role roster that spans dozens of access rights. Figuring out who should be able to do what can be a difficult task. Not to mention that things are continually changing. An admin could establish a new role with too many access privileges without understanding its impact on SoD. This is known an example of SoD risks in SAP. If a role allows for actual SoD problems, it’s called an SoD violation. These need to be remediated or the company will be at risk for fraud and non-compliance with laws like SOX, ultimately resulting in failed audits.
SoD Risk Review
SoD Risk Review is the process of inspecting an organization’s users, their roles and the underlying SAP system for situations where SoD violations are occurring. It’s a daunting task. One that involves defining the organizational structure, mapping out transaction steps and correlating them with user roles. Done by hand, it’s a big chore, so an automated solution can be highly beneficial.
What is an SoD Matrix?
One traditional approach to reviewing SoD risks in SAP was to map out roles and responsibilities graphically in a matrix. An SoD Matrix plots transaction permissions on the X and Y axes of a matrix. By eye, it is then possible to inspect the matrix and discover places where two roles have an SoD conflict. Though once considered a best practice, the SoD matrix is now obsolete. A rulebook or ruleset, implemented with (and oftentimes included with) a GRC solution, is far more efficient and effective.
SAP GRC Access Risk Analysis
SoD is a subset of the broader Governance, Risk Management and Compliance (GRC) functions of a business. GRC is partly a board- and c-suite executive level responsibility that covers how well they’re governing the corporate entity. As part of GRC responsibilities, the IT department (or security team) will conduct a GRC access risk analysis. Access risks relate to the danger that an unauthorized outsider could access the company’s digital assets. It also deals with controlling which digital assets, and software tools, an employee can access one he or she has logged into the network.
Access Risk Analysis and SoD Risk Analysis are linked. Access controls and user roles are typically governed by the same system. A User role dictates what he or she can do on the system. Thus, GRC Access Risk Analysis is usually part of SoD Risk Analysis.
SAP GRC Risk Management
Access Risk Analysis and SoD Risk Review does the hard work of mapping user roles to SAP software functions. This way, it prevents SoD violations and reduces SoD risks in SAP. If you’re using an automated tool like ControlPanelGRC, it is also able to monitor for SoD risks continually. This is a big advantage over a periodic approach, which can easily miss SoD problems that arise between risk reviews—which, in some companies, occur on an annual basis. To learn how ControlPanelGRC can help you with SoD risks in SAP, contact us today.