Segregation of duties (SoD) is a required compliance control that reduces fraud risk. With SoD, instead of having one person responsible for all duties related to a critical business process, you distribute those responsibilities by assigning them to different individuals.
In your accounting department, for example, one person is responsible for creating vendor accounts in an Enterprise Resource Management (ERP) system like SAP, Oracle, or NetSuite, while another is responsible for paying vendors. Similarly, human resources teams manage sensitive data and processes in Human Capital Management (HCM) systems, and revenue teams do so using Customer Relationship Management (CRM) software. Those business processes and many others require segregation of duties.
Without careful, continuous segregation of duties, there is a high likelihood that some people in your organization have a toxic combination of access privileges. They have the potential to conduct fraud—and cover it up.
However, keeping track of the myriad of duties that are part of key business processes is extremely challenging, especially as tasks, transactions, and approvals often take place in multiple IT applications that aren’t tightly integrated. Plus, business processes change as new workflows are introduced and people come and go from your organization.
Therefore, SoD becomes impossible to manage without a scalable, automated process.
In this blog, you’ll learn how a segregation of duties matrix helps to address this challenge. You’ll understand the key components of a SoD matrix and see how you can easily maintain it using automation as your organization and risk profile change.
A segregation of duties matrix is a key building block for SoD analysis that is required for regulatory compliance. Even companies that aren’t bound by regulations can benefit from an SoD matrix to help maintain identity security best practices and a strong internal control system.
The matrix provides a central place for you to document responsibilities and tasks that are part of a critical business process, as well as the level of access and entitlements granted to execute each specific task or job function. It also identifies the level of risk associated with each process and task if it were completed incorrectly, not completed, or compromised.
A segregation of duties matrix lets you see the full picture of entitlements and identify toxic combinations. Then you can decide if you want to re-design risky processes to add oversight or insert new steps, or re-assign roles to different people.
In some cases, you may choose to accept the risk of certain combinations—but you’ll be able to do so with your eyes open.
An SoD matrix helps you align with the Principle of Least Privilege Access, which means users should have access only to what they need to do their jobs when they need it. Nothing more. Following the Principle of Least Privilege helps you avoid the risk of excessive privileges, much like segregation of duties does.
In addition to what access people have, the Principle of Least Privilege also requires that you specify and control when they have access. With least privilege access controls, a user may have standard privileges for the majority of their work, and then have their privileges elevated just-in-time to perform a function when needed. After the task is completed, their privileges revert to that of a standard user.
To put this in terms of a financial process, think of an accounting function that is only available until the end of the quarter. In the past week of the quarter, accounts must be reconciled, and activity is heavy. Then, once the books are closed, they are closed. Whoever had access to make changes can no longer do so.
An SoD matrix should outline each task that is part of a critical business process.
Depending on your authorization process, you may define levels of access according to a person’s role in the organization, the group they belong to, attributes of the user, or context-aware, dynamic policies. Or, you may be relying on the out-of-the-box roles within each of your business applications rather than a centralized process.
The challenge with out-of-the-box roles is they are not designed with segregation of duties in mind, so they are littered with SoD conflicts when roles that would be common to one job function, as assigned.
The most important part of your SoD matrix is your rulesets. What access rights or roles should never be combined? What risk thresholds can your organization tolerate, and what risk is unacceptable?
Within an SoD matrix, you should incorporate a risk-scoring formula or a ranking system that prioritizes oversight for certain processes or tasks.
For many organizations, it’s a daunting task to start a segregation of duties project, much less the development of an SoD matrix. However, if you start to break down the steps required to implement segregation of duties controls successfully, the tasks will be less daunting, including building out a matrix.
Gaining stakeholder buy-in for an SoD approach is an important step in designing your matrix. An SoD matrix isn’t something that an IT department can create in isolation; business teams know their processes best and understand the related risk. Ultimately, they are the ones responsible for accepting that risk and approving the matrix.
Start by identifying and documenting all key processes that need SoD controls, such as financial transactions, procurement, etc., and involve the business stakeholders in those functions.
Most organizations first create a segregation of duty matrix manually. Business and IT teams huddle over a whiteboard (and, if you’re lucky, some good takeout) and outline workflow steps in each process.
Clearly define all roles and their associated responsibilities. Ensure each role is tied to specific duties within the key processes. Create a cross-reference between roles and the specific tasks they are responsible for, ensuring no role has control over incompatible duties.
Evaluate the risk level for each combination of duties performed by a single role, categorizing risks (low, medium, high) based on their potential for fraud or errors.
Without a proper risk assessment, the matrix may be incomplete or provide a false sense of security control-wise. It’s paramount to evaluate the potential risks associated with each role and the access it provides if you are to properly prioritize segregation of duties as the matrix is developed and ultimately used to review for SoD conflicts.
Review the roles required to execute transactions within each business application involved in the process.
Commonly, the application owner—the administrator of your ERP, HCM, or CRM—has set up roles as best as possible to match different levels of responsibility. This can be challenging if the security model for the application isn’t granular enough to suit your organization or if the application doesn’t allow for customization. Often, you have to choose an available role that suits your requirements as best as possible.
Next, some lucky person (you, perhaps) gets to transfer that information to a spreadsheet.
Here are some examples of a simple SoD matrix in spreadsheet form:
Sounds simple enough, right?
But most organizations don’t just have one critical business process—they have many!
Multiple business processes and systems = a SoD matrix spreadsheet with multiple tabs.
Add in the need to assign risk levels to these business processes, and then to each of the possible segregation of duty role conflicts that can exist and need to be documented in a matrix, and you really are starting to document and update lots of information manually. What a headache!
If you’re an Excel guru, maybe you’ve got some formulas in your SoD matrix to show how different tasks in different systems are dependent on others or connected to each other. But even the best Excel guru needs data to work with, and with changing roles, business processes, risk levels, and source system security models, how does an organization ensure all this information is fed into the segregation of duty matrix? Whether this information is collected in a series of matrices, or one big spreadsheet, that is a lot of data to keep track of manually and prone to errors the more time it is processed manually.
Once the spreadsheet is created, you must decide where to store and maintain it. The SoD matrix itself is a highly confidential document that only certain people should be able to access or edit.
Once you have a matrix in place, it’s time to test it in practice. This is an iterative process. How simple is it for IT operations teams to follow this matrix when provisioning users and entitlements? How easy is it for risk management teams to understand?
A SoD matrix is a living document. In a fast-growing organization, a manual SoD matrix may be incorrect as soon as it’s created. Business process, where SoD risks can reside are constantly changing. Risk levels or ranking of business processes also are changing, which requires each and every possible segregation of duty conflict listed in a SoD matrix to be reviewed and possibly updated as well. All these review and update exercises are part of the need for continuous updates to a SoD matrix to ensure it can be trusted as an accurate reflection of possible toxic combinations of access that roles in source systems can provide to a user.
Auditors love documentation. It is no secret that without detailed documentation, it becomes a challenging task to explain to auditors how the matrix was developed and how it is used to evaluate user access for segregation of duty conflicts. The easiest way to solve the documentation challenge is to maintain detailed records of all changes, testing, and reviews. You'll want to establish a formal process for managing exceptions to SoD policies, ensuring that deviations are documented, approved by management, and monitored with additional controls if necessary.
No two organizations are the same when it comes to business objectives, processes, risk levels, or functions. While you can leverage existing rulesets and templates, you should continually tune your SoD matrix to match your need.
The challenge is how best to keep the matrix and, perhaps, if used, the SoD matrix spreadsheet up to date. If the matrix and possible SoD conflicts are included in one spreadsheet, that is a bit easier to maintain, but many organizations develop individual matrices by business process area, and end up with 40, 50, 60, or even more than 100 SoD matrices when must all be constantly reviewed and updated when business processes and or risk levels change. Quite a time-consuming task to review, update the SoD matrix and document why the change was made.
Once you understand toxic combinations and document them in a segregation of duties matrix, you can begin implementing preventive controls at the point of user provisioning.
When setting up new users or adjusting roles as part of a Joiner-Mover-Leaver process, your IT operations or identity management team should be able to check the SoD matrix for toxic combinations and avoid assigning entitlements that lead to conflict. When users or employees are requiring new access (joiner), changing roles in the organization (mover), and leaving the organization, it is critical to review their access request for segregation of duty conflicts BEFORE provisioning the access.
A SoD matrix or set of matrices can be reviewed for SoD conflicts with each Join-Move-Leave access request to determine if the execution of the request would provide a segregation of duties conflict. Of course, again, if a set of manual SoD matrices is being used in the provisioning process to review for toxic SoD combinations, it will be a large manual effort, prone to errors. An automated segregation of duties solutions, integrated directly into an IGA solution for provisioning user access is the preferred approach to ensure strong controls around a compliant provisioning process.
Developing a segregation of duties matrix is a great first step to assist with mitigating SoD risks, but due to its manual nature, it can be difficult to use consistently. Without some form of automation in place, completing the tasks outlined above can be extremely time-consuming and prone to errors. Hence, automated SoD solutions, like the one from Fastpath, now part of Delinea, have become quite popular.
Consider that security models for source systems can change, and each time this occurs, segregation of duties matrices must be reviewed and updated. If an organization is using a manual SoD matrix, all these matrices must be reviewed and updated when new toxic SoD combinations are identified. In an automated solution, the SoD ruleset is kept up to date by the solution provider as they monitor changes to the source systems’ security models and update their segregation of duties rulesets accordingly.
Similarly, organizations' business processes also change over time. A segregation of duties matrix is often mapped to a business process, and assigned a risk level based on the business process and its risk as it relates to the overall risk model of the organization. Imagine the amount of work required to manually review and update all SoD matrices when business processes change, and to update risk levels.
Each matrix must be reviewed individually and updated accordingly. Automated solutions provide an easy method for adding new business processes, adjusting risk levels to SoD conflicts, and adding or deleting the toxic combinations or conflicts that are required when business processes change. The level of effort required to update the ruleset with an automated solution is significantly lower.
Fastpath, now part of Delinea, has been an industry leader for twenty years with an automated solution for reviewing segregation of duties. With a native SoD ruleset created from a segregation of duties matrix designed by a team of auditors and accountants, Fastpath’s Access Control product is trusted by over a thousand customers and the world’s leading audit firms to provide a solid control around segregation of duties for over thirty different business applications.
Fastpath’s Identity Governance Administration (IGA) solution checks for segregation of duties conflicts during the automated provisioning process. Combined, these preventative controls lower fraud risks, support least privilege access, and improve the security posture of your organization. To learn how your organization can benefit from automated SoD solutions, sign up for a live demo.