Eric Van Hofwegen Eric Van Hofwegen
Oct 29, 2020 3:52:35 PM

How much loss is an organization prepared to accept due to poor operational risk management?

Most organizations admit that their people and processes will inherently incur errors leading to ineffective operations. However, "accepting" and "admitting" is not the answer. Don't we know how unsuccessful operations can tarnish an organization's reputation and cause financial damage? Here is what can be done to minimize the risk of loss to an organization because of a failed operation.

In evaluating operational risk, practical remedial steps should be emphasized to eliminate exposures and ensure successful responses. So, to reduce the risk of loss due to ineffective operations and fraudulent transactions, you should implement Segregation of Duties (SoD) in your organization.

What is Segregation of Duties?  

Separating various tasks that should be performed by different roles or users is termed as Segregation of Duties. So, how is SoD performed? One can set up rules to separate tasks. Start with listing all the risks of operational transactions and then define the Segregation of Duties.

For example, you might not want the same person to acknowledge the receipt of goods and to process payment to the vendor. Segregation of Duties helps you to lessen the risk of fraud, also detecting errors or irregularities.

You can also use the Segregation of Duties to enforce internal control policies. By using STAEDEAN's Data Security Solution for Dynamics 365 Finance & Supply Chain Management, for instance, you can map your risk against the segregation of permissions and ensure that all the risks are assessed and taken care of for your organization.

Microsoft also provides a clear explanation of the setup of SoD duties. 

Dynamics 365 Finance and Supply Chain Management (D365 F&SCM) also provides functionality to set up Segregation of Duties, but there exists a gap in standard D365 F&SCM SoD rules.

What is the "gap" in standard D365 F&SCM functionality to set up SoD?

D365 F&SCM is a reliable and robust ERP platform, and efficiently provides functionality to set up SoD. However, as stated above, there is a gap. Let’s understand this better through the given flow chart:

the "gap" in standard D365FO functionality to setup SoD

SoD-Rule1 segregates Duty1 and Duty2. So, these duties cannot be linked to the same role/users.

For example, Role1.

Using the entry points of Duty1, a new duty is created: Duty3.

Using the entry points of Duty2, a new duty is created: Duty4.

As SoD-Rule1 does not segregate Duty3 and Duty4, both can be linked to Role1. This gives Role1 all rights as defined by Duty1 and Duty2, which is not allowed by SoD-Rule1.

SoD-Rule2 segregates EntryPoint1 and EntryPoint5. By defining the segregation on the entry point level, Duty3 and Duty4 are not allowed together for Role1.

Segregation on duty level only:

With the gap in standard D365 F&SCM SoD rules explained, we know that it is crucial to define SoD rules at the lowest level so that it recognizes all the scenarios. Plus, we have a proper validation check in place. With the Enhanced Segregation Rules SoD in Data Security Solution, you can define not only segregation rules at the duty level but also the privilege level and entry point level.

Importance of Enhanced SoD rule in Data Security Solution

With the enhanced segregation rules, you can not only define segregation rules on duty level but also the privilege level and entry point level.

With a segregation rule on duty level only, the related privileges or entry points can also be linked to another duty to which the segregation rule does not apply. By defining segregation on a lower level (privilege or entry point), you can enforce segregation more precisely.

If you use enhanced segregation rules, the related validation and verification of user-role compliance are done on the defined level.

Segregation on entry point level:

Segregation on entry point level

For getting more details on how to define Enhance SoD rules at the entry point level, please visit our solution documentation page.

If you define a segregation rule at the entry point level, you would also need to define the access level. This defines the valid and invalid entry point permission combinations. On validation, the defined access level combinations are considered.

The access levels that are:

  • Lower than the defined access level, are valid.
  • Equal to or higher than the defined access level, are invalid.

Example:

SoD-rule2 segregates these entry points:

  • First = EntryPoint1; First access level = Create (so, permission is Create).
  • Second = EntryPoint2; Second access level = Update (so, permission is Edit).

Example segretation

Take this example, when assigned to Role1, some cases of entry point permission combinations are:

  • Valid:
    • EntryPoint1, Update - EntryPoint2, Read
    • EntryPoint1, Read - EntryPoint2, Update
    • EntryPoint1, Create - EntryPoint2, Read
  • Invalid:
    • EntryPoint1, Create - EntryPoint2, Update
    • EntryPoint1, Create - EntryPoint2, Create
    • EntryPoint1, Delete - EntryPoint2, Update

The primary purpose of applying segregation of permission at the entry point level is to prevent instances and opportunities for committing or concealing fraud and/or error in the normal course of an organization's activities. Having more than one person to perform a task minimizes the opportunity of wrongdoing and helps in detecting any misconduct or unintentional errors— whatever the real cause.

How Enhanced SoD in Data Security Solution functions

In D365 F&SCM, when a user is a member of multiple groups, the Segregation of Duties functionality is not working. To be able to use the SoD features correctly, you need to assign the roles to the user himself. Using Enhanced SoD in Data Security Solution, we can validate the SoD violation for the Azure Active Directory (AAD) group as well.

For example:

  • You have created SoD rules, such as Duty1 and Duty2, that cannot exist together.
  • Duty1 is part of Role1, and Duty2 is part of Role 2.
  • According to the SoD rule, Role1 and Role2 cannot coexist on a user.
  • You have assigned Role1 to UserA now; then, you will not be able to assign Role2 to UserA.
  • If User A is a part of AAD GroupA, then Role2 can be assigned to GroupA.
  • Effectively UserA can get access to both Role1 and Role2.
  • Standard SoD fails to recognize this assignation as a SoD violation.

We also capture this violation in Enhanced SoD feature of Data Security Solution; the user will not be able to violate the SoD rules through the AAD group as well.

Integrated Risk Management – the answer to the "gap" in standard D365 F&SCM functionality to set up SoD

In our Data Security Solution for D365 F&SCM, we have developed a workspace - Integrated Risk Management - that can help you define your risk and then link an SoD rule against the risk. This step helps in getting an overall picture of risk assessment in terms of defining the segregation of permissions within an organization.

Use an Integrated Risk Management workspace to manage the operational risks for your company. These risks can be security-and-compliance related or any other type of risk for your organization.

You can link risk to the Enhanced SoD rule to help reduce business risks, human errors, or fraudulent transactions. Several graphs can help you monitor the risks. With our efficient Integrated Risk Management and well-defined Enhanced SoD, say no to operational risk.

Apart from helping D365 F&SCM users enhance and implement correct SoD in D365, our Data Security Solution also helps in streamlining security management, avoiding data misuse and fraud, preparing for audit compliance requirements, and monitoring security change requests. Additionally, our solution also helps in end-to-end data security and governance by helping D365 F&SCM customers integrate, migrate, model, create, enrich, and distribute their data without any need for coding.

To learn more about the features and benefits of our comprehensive solution, please download our solution factsheet from the link shared below.

 

Eric Van Hofwegen Eric Van Hofwegen
TI_LOGO_TI-Logo-color andAXP_365

have now rebranded to

staedean-logo-teal