As per AICPA Segregation of Duties (SOD) AICPA, Segregations of Duties (SOD) is a basic building block of sustainable risk management and internal controls for a business. The principle of SOD is based on shared responsibilities of a key process, wherein the critical functions of a process are assigned to more than one person or department. Managing fraud and error risks is difficult without this separation in key processes.
The main purpose of applying segregation of duties is to prevent the instances and opportunities for committing or concealing a 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.
At To-Increase, our Security & Compliance Studio for D365FO (SCS) has been helping our customers establish policies that enable them to optimize and maintain their licensing, security, user management, and audit processes more efficiently and reliably than ever before.
Security & Compliance Studio comes with separate workspaces for managing your security, audit, and license optimization requirements. It offers an out-of-the-box list of SOD rules defined to help your organization meet their compliance needs. You can define and track all your organizational risks in one place. Moreover, it lets you outline your Enhanced SOD rules as well, which is a practitioner’s delight as it is not possible in the standard product offered by Microsoft.
In this blog, I will explain how you can meet your compliance requirements using our Security & Compliance Studio.
Steps in managing segregation of duties in D365 Finance and Supply Chain Management
Security and Compliance Studio ensures the segregation of duties is simple and easy. It provides the appropriate level of protection to the key information in your ERP system by controlling who has access to what data.
SCS comes with an out-of-the-box SOD set of rules associated with security risks and mitigations to help advise partners and customers. Designing a management process for the segregation of duties (SOD) to support the organization’s internal compliance needs is critical in an era where there is an increased legal requirement to be compliant on this aspect.
As an example, companies registered on the U.S. stock exchange have a legal requirement to be compliant with the Sarbanes–Oxley Act (SOX). SOX control 404, the assessment of internal control, deals with the need to define and maintain segregation of duties ruleset. This SOC Act, which was passed in 2002 by the U.S. Congress, protects investors from the possibility of fraudulent accounting activities by corporations. It mandated strict reforms to improve financial disclosures from corporations and prevent accounting fraud. SOD controls are also applicable to EU and U.K. based companies to ensure better internal controls.
ISO 27001 Section 6.1.2 also requires organizations to put proper controls in place for segregation of duties.
Other key challenges include the ongoing changes to regulatory requirements (GDPR), increased regulatory inquiries, and a rapidly evolving business technology landscape.
Fig- SOD rule - Security management workspace
Step 1. Define and list down organization risks
Even if an organization is not pursuing a specific regulatory compliance objective like SOX or GDPR, it’s highly recommended to start with creating a list of applicable SOD conflicts that can either allow fraud or can cause significant security or financial risks.
This can be achieved by revisiting the organization’s GRC objectives together with the organization structure. The final result of this phase is to determine potential risky ERP transactions and categorize them as high, medium, or low severity.
Risk identification matrix based on SCS transaction type
For D65F3O, To-Increase Security & Compliance Studio provides you a predefined list of “SOD” ruleset designed to exclude transactions to the same role, which can cause fraud. This ruleset also significantly enables an organization to pursue their specific compliance requirements like SOX.
It is critical to understand the standard roles provided by Microsoft in D365FO DO NOT support the SOD principle and leave it for partners and customers to arrive at their own list of the custom roles. For most organizations that simply adopt the standard security roles for want of effort and time, this may pose a security risk.
Step 2. Organization risk register and SOD ruleset at duty, privilege or permission level
It helps you define and track all your organizational risks in one place. Besides, you can also define enhanced SOD rules, which is not possible in the standard product offered by Microsoft.
Image- Organization Risk Register in Integrated Risk Management Workspace
Image- Defining enhanced SODs in integrated risk management workspace
Step 3. Fine-tune the SOD Ruleset
Based on the Security & Compliance studio out-of-the-box ruleset, the internal key controls and risks are identified. Then, you can arrive at a final set of SOD rules with appropriate severity, risks, and mitigation information for each record. The finance head, internal auditor, IT head, and the external auditor should be a part of the team that prepares this list.
Step 4. Analyze risks
Analyze the risks against the ruleset to identify conflicts. Any conflicts should be highlighted, and recommendations escalated, to the appropriate department, such as Internal Controls/Finance. This may require further interaction with the business to find a suitable solution to eliminate risk.
Image- SOD conflicts in security management workspace
Step 5. Finalize the security roles according to the role-based access control in D365FO
A review of the D365FO security model should be undertaken to implement the required change to either a conflicting role or role assignment. The risk assessment will lead to redefining and recreating many standard D365 FO security roles. SCS helps you create, modify, or merge multiple roles as required by the organizational structure. This is done in a way to identify different ways of performing segregation of duties to the business process within various functional areas and departments.
Step 6. Security Mitigation
It’s not always possible to strictly go by the SOD ruleset either due to business setup, low employee count, or other organizational constraints. Then the best practice would be to have appropriate control in place to mitigate the risk.
Image- Example of SOD rules security management workspace with associated risk and mitigation
Step 7. Continuous audit and compliance – SOD Dashboard
A continuous process should be set up to review all new user access requests and changes to the D365FO security model against the SOD ruleset. This should be focused more upon during the following events:
- Before moving any new role definition to live environment
- Defining new roles in D365FO based on a new user job profile
- New business processes arising out of M&A, reengineering, digital transformation, or process improvement initiatives
- Changes to an existing role
- Merging roles
- Assigning temporary or stand-in permissions
In the transactions above, Security & Compliance Studio ensures that proper warning and prompts are sent to the security officer or system administrator, whenever any violation of the SOD rules is detected.
SCS provides SOD dashboard (actionable insights) to assist you in all conflicts and violations at all times, both at the role definition and user role assignment levels.
Image- Resolved and unresolved SOD conflicts Dashboard in Security management workspace
Image- Incompliant roles and user assignment Dashboard in Security management workspace
Best practices for implementing SoD
One has to remember that “out-of-the-box” SOD ruleset presents the transactions that pose a theoretical risk of fraud. However, this has to be balanced with an internal assessment of the actual compliance needs based on the key controls required for the compliance requirements being pursued.
The benefits of implementing segregation of duties to security must be balanced with the increased cost and effort required. This will help organizations to fix an optimal budget and not overdo in these areas.
To put it simply, you need to just focus on the most legal requirements, like SOX, towards the risk of material misstatement and not on covering all possible scenarios of theoretical risks in various ERP transactions. The risk of material misstatement is the one that the financial statements of an organization have been misstated to a material degree.
As an example, a typical procurement cycle for a large enterprise-class organization using D365FO with high focus on security and compliance to SOX404/ISO 27001 may have the following segregation of duties:
However, for practical reasons based on how departments and human resources are structured, the same person may perform more than one procurement cycle steps with the approving authority’s consent on the assignments.
