“Segregation of Duties” (SoD), also known as “Separation of Duties”, is a system of internal controls within an organization. SoD policies act as a first line of defense when protecting organizations against regulatory noncompliance and fraudulent activity.
Many business processes, if executed by a single person, can often create a conflict of interest. For example, an employee should not be able to submit and approve their own purchase orders. SoD principles dictate that such processes must be split up between multiple people within an organization. A process may even require multiple approvers in the case of high-risk processes.
It is not possible to simply purchase SoD. Organizations often implement SoD through diligent risk management practices. There are, however, software solutions that can help reinforce SoD policies and greatly assist compliance efforts. They do this by strengthening access controls, as well as by providing extensive monitoring and the ability to trace audit trails.
SoD Examples
Additional examples of processes that utilize SoD include:
- Employees can’t write their own reimbursement checks or execute their own purchase orders
- Project managers must review and sign off on their team’s work or documentation
- Hiring staff may not set compensation levels
- Different employees must be responsible for ordering inventory as those who verify and enter the received goods into inventory systems
Internal controls separate incompatible duties to prevent fraud and minimize temptation or mistakes. Blackmail and coercion are major concerns for employees with important roles or that handle valuable data. Without SoD policies, the above examples are susceptible to the following:
- Employees could fraudulently route funds to themselves
- Employees editing their own work may not catch a mistake or may be able to abuse non-compliant access
- Hiring staff may offer a friend a position or inflated compensation over other applicants
- An employee could create and cover up an order discrepancy to take goods for themselves
SoD & Regulations (Sarbanes-Oxley)
In 2002, the United States introduced the Sarbanes-Oxley (SOX) Act. This was done in the wake of many high-profile fraudulent acts in the financial sector. This new legislation directly influenced SoD and auditing requirements for financial and public institutions. SOX compliance required strict enforcement of internal audit controls. Most notably, it required organizations to hire independent auditors to review their accounting practices, rather than use internal auditors.
These independent audits made it much more difficult to cover up fraud. SOX further reinforced compliance by restricting independent auditors from providing certain non-audit services to eliminate conflicts of interest.i
SoD & Identity & Access Management
SOX significantly contributed to the early development of modern identity and access management (IAM) systems. Financial corporations initially struggled to adapt to the new regulations. Processes had to be overhauled. Legal and audit resources were suddenly required at unprecedented levels. IAM systems tackled these new business challenges on two fronts: access control and audit trails.
IAM’s enforcement of “role-based access control” (RBAC) is the foundation of many SoD practices. With RBAC, restrictions can be placed on information systems based on an employee’s role. Roles can be determined according to department, hierarchy, or job function. RBAC ensures that users only have access to the specific resources their roles require; no more, no less.
IAM systems also compile audit trails by logging users’ activity. IT administrators can report on those audit trails to demonstrate compliance. Further, audit trails help identify and address any issues within the RBAC structure. These audit trails reduce the burden of preparing for government or third-party audits. Manual preparation, on the other hand, can require months of review efforts conducted by large teams.
Broader roles don’t always apply to all users, however. In nearly all organizations, ad-hoc changes and assignments are required. These requirements must be met while remaining compliant with both SoD and applicable regulations. To that end, many IAM systems incorporate some method of self-service request and approval workflow platforms.
With a self-service platform, users may request additional access at their own discretion. Their requests are then routed for approval to one or more responsible parties. Some platforms take into account SoD policies during the request stage, preventing users from requesting access that would violate the policies.
New Regulations & Data Privacy
The latest wave of regulations affecting public and private organizations will primarily focus on data protection. The EU’s General Data Protection Regulation (GDPR) has already brought about sweeping changes regarding data collection, storage, and access. Moving forward, SoD policies will have to expand beyond just who executes what part of a process. Now, enforcing which users have access to what data on your organization’s file system is necessary for compliance.
i. https://searchcio.techtarget.com/definition/Sarbanes-Oxley-Act