Do you have questions about what a Risk Matrix is for, or when to use it? In this series of articles on the Segregation of Function Matrix (SoD Risks) topic, you will answer many of your questions.
Segregation of Duties is the concept of having more than one person required to complete a set of tasks considered critical. In business, segregation through the sharing of more than one individual in a single task is an internal control designed to prevent fraud and error. The concept is alternatively called segregation of function or, in the political field, segregation of powers.
The technical structure of the risk matrix below illustrates the main attributes necessary to define a Segregation of Duty (SoD) and/or Sensitive Access Transaction (SAT) risk and therefore the composition of the set of rules called Risk Matrix. This structure is part of the TrustSis method for defining, creating, adjusting the SoDs/SAT risk matrix and compensating controls.
Figure: Structure of the SoDs Risk Matrix
What is the risk matrix for and should I use the ones already on the market?
It is very common for companies concerned to avoid fraud, errors or even the simple desire to know their processes better, to have a Risk matrix with several Segregation of Function (SoD) rules to identify which individuals can perform tasks considered critical and conflicting. If these tasks are segregated into different individuals, no SoD rules will be violated and therefore there will be no risk of fraud or errors occurring.
A SoD risk analysis seeks to identify and point out users of a system being monitored who may be violating SoD risk rules. Let’s use the SoD risk rule as an example, which seeks to identify users – in a monitored system – who can make purchases and at the same time also have access to make payments for these purchases. For this scenario, the example user would be violating a SoD risk rule and therefore would be pointed out in the analysis result report. Based on this result of the analysis, indicating a violation of the rule, the process of recognition of the legitimacy of the violation pointed out begins, evaluating according to the following criteria:
The violated risk rule indicates a user with the power to buy and make payment, however, by definition of the organization’s business, this risk is legitimate and acceptable by the area, management, controls, audit, etc. In this case, a compensatory control is applied.
The violated risk rule indicates a user with the power to buy and make payment, however, by definition of the organization’s business, this risk is not acceptable by the area, management, controls, audit, etc. In this case, the remediation steps apply.
-
- Determine if the SoD risk rule actually represents the correct conflicting privilege set to identify SoD risk violations and therefore non-compliances. Adjust the rules – if applicable – and carry out a new SoD risk analysis.
- Determine if user profile privileges can be corrected to eliminate SoD risk rule violation. In this scenario, it should be observed if the user’s access profiles are shared with other users, to determine if the adjustments will not impact those users, who may need to maintain the privileges being modified.
- Evaluate if the tasks and/or transactions and/or actions are not allowing the execution of conflicting activity (eg buy and pay) intrinsically by definition of the system supplier. This situation is more difficult to map, however, some suppliers (eg SAP) have information notes detailing these “anomalies”.
Depending on the result of the SoD risk analysis, a project to redesign access profiles and/or assessment and adjustments of the access management process and SoD risk monitoring is recommended. When the result of the analysis shows that most users of the evaluated system violated SoD risks, this usually implies – in the vast majority of cases – that the access profile model (and even the access management process and SoD risk monitoring) should be reviewed and improved, to obtain greater effectiveness of the desired control.
Risk Matrix SoDs offered by consulting companies or GRC tools can be used by my company?
The answer to this question is YES and NO. And everything will depend on the evaluation of the criteria below, used for decision making.
Every matrix of “out-of-box” SoDs Risks, those offered by consulting companies or GRC tools (eg SAP GRC Access Control) bring a set of rules that represent the critical combination of tasks and/or transactions and/or actions of a given business system (for example: SAP ECC, S4/HANA, Oracle, Ariba, TOTVS Protheus, TASY, RM, HCM, CRM, SRM, HR, Success Factor, etc.). These combinations are based on processes and/or active modules of the business systems in question. Therefore, the matrix will be fully adherent or not, if the ERPs (in our example) have the same tasks and/or transactions and/or actions being used.
How to determine if the Risk Matrix is 100% adherent to my company?
The simplest way to assess whether the “out-of-box” SoDs risk matrix offered by consulting companies or GRC tools (eg SAP GRC Access Control) adhere to your company’s business system, is by considering and seeking the answers to the following questions: The Sod Risk Matrix,
-
- Do you have tasks and/or transactions and/or actions equivalent to the release version of my business system?
- Does it represent all active processes and modules in my business system?
- Does it present processes and modules that don’t make sense to my business system?
- Should the customizations performed by my company be included in this “out-of-box” Risk matrix?
- Do the SoD risk combinations represent the particularities of my business to avoid false positives in risk analysis results?
Example: approval flow where it is mandatory that any payment be submitted systemically for approval and release.
-
- Does the risk description have language that users in my organization can understand?
- Are the criticality of the matrix risks aligned with the criticality desired by our organization?
- Have all the risks in the matrix been recognized by our organization as being legitimate?
These, among other questions, are extremely important to determine if the SoDs Risk Matrix offered by consulting companies or GRC tools (eg SAP GRC Access Control) is adherent to your business system and can be used without going through a process of review and adequacy.
It is worth remembering that the intention to have a SoD Risk Matrix at any cost to resolve an audit GAP, carry out a redesign of access profiles or even try to establish an access management process and SoD risk monitoring, can – consequently – generate a cycle of other problems when the issues mentioned above are not observed. It is recommended to understand the structure of the SoD Risk Matrix acquired and in order not to establish an improvement roadmap that could worsen your organization’s risk scenario, it is **important to consult an experienced service partner to propose best practices** for adjustments, adequacy and process of use of the SoD risk matrix.
Contact us and have highly trained professionals to help you in this choice!
