What Is Separation of Duties (SoD)?

In today's digital landscape, organizations face increasing challenges in managing access to sensitive information and critical systems. One key principle that helps mitigate risks and ensure compliance is Separation of Duties (SoD). This blog will explore what SoD is, why it's crucial, and how it fits into modern Identity Governance and Administration (IGA) systems.

A Brief History

Despite what many might believe, the foundation of what we know as the Separation of Duties was established long before the technology we know (and love) today was even a dream in someone’s mind. 

How far back are we talking? Ancient.

In fact, the concept dates all the way back to ancient Rome and Greece. But, the ideology didn’t become popular until the 18th century when the French philosopher, Montesquieu, spoke of the “division of powers” and used it to outline the separation between the different branches of government. This system of checks and balances has since been used in governments across the world to limit what politicians, judges, and other influential people can do, preventing overreach and mitigating risk within a global scale.

In the modern business world, SoD gained prominence in the wake of financial scandals in the early 2000s (Enron/Worldcom), leading to regulations like the Sarbanes-Oxley Act, which mandated stronger internal controls in financial reporting.  This included the establishment of checks and balances across access, IT security, data backup, and change management.

What is Separation of Duties (SoD)? 

Separation of Duties is a principle that divides critical functions and responsibilities among different individuals or departments within an organization. The goal is to prevent any single person from having excessive control over a process, which could lead to errors, fraud, or misuse of resources.

In the context of IT and identity management, SoD ensures that no single user has conflicting or incompatible access rights that could compromise security or violate compliance requirements.

Why is SoD important?

SoD is crucial for several reasons:

• Risk Mitigation: By distributing responsibilities, SoD reduces the risk of fraud, errors, and insider threats.  It also prevents “easy mistakes” by forcing more people to be involved in high risk processes.
• Compliance: Many regulatory frameworks require SoD as part of internal controls, including SOX, HIPPA, PCI DSS, ISO27001, NIST 800-53, FISMA
• Operational Integrity: SoD helps maintain the accuracy and reliability of business processes.
• Auditability: Clear Separation of duties makes it easier to track actions and responsibilities.

What regulations require SoD Controls?

Separation of Duties (SoD) controls are required or strongly recommended by various regulations and audit frameworks.  Here's some key regulations and standards that mandate or emphasize SoD controls:

• • Applies to: Public companies in the United States
  • Requirement: Section 404 mandates internal controls over financial reporting, including SoD

• • Applies to: Organizations handling credit card data
  • Requirement: Requirement 6.4.2 specifically calls for Separation of duties between development, test, and production environments

• • Applies to: Healthcare organizations and their business associates
  • Requirement: The Security Rule requires implementation of policies and procedures for workforce security, including SoD

• • Applies to: Organizations handling EU citizens' data
  • Requirement: Article 32 requires appropriate technical and organizational measures to ensure data security, which often includes SoD

• • Applies to: Organizations seeking certification in information security management
  • Requirement: Control A.6.1.2 explicitly mentions Separation of duties

• • Applies to: IT governance framework used by many organizations
  • Requirement: DSS06.03 (Manage Roles, Responsibilities, Access Privileges and Levels of Authority) includes SoD principles

• • Applies to: U.S. federal information systems
  • Requirement: Control AC-5 specifically addresses Separation of Duties

• • Applies to: Financial institutions
  • Requirement: Safeguards Rule requires administrative, technical, and physical safeguards, often interpreted to include SoD

• • Applies to: U.S. federal agencies and their contractors
  • Requirement: Mandates implementation of information security programs, which typically include SoD controls

• • Applies to: Service organizations providing services to other entities
  • Requirement: Often includes evaluation of SoD controls as part of the overall control environment

• • Applies to: Pharmaceutical and medical device companies
  • Requirement: Requires controls for electronic records and signatures, including SoD in system access and data handling

• • Applies to: IT service management framework
  • Requirement: Recommends SoD as a best practice in various processes

What are examples of common SoD policies implemented today?

Common SoD policies include:

1. Financial: Separating the roles of those who can initiate payments from those who can approve them.
2. IT: Ensuring developers can't push code directly to production without review.
3. Procurement: Separating the ability to create purchase orders from the ability to approve vendors.
4. Human Resources: Separating the ability to hire employees from the ability to set salaries.
5. Access Management: Preventing individuals from both requesting and approving their own access rights.

It’s easy to see with these examples exactly why these kinds of policies have become so common.

What are examples of SoD failures?

If, by this point, you’re asking, “So, how bad can it get?,” the answer is: Bad. The ramifications for not having strong SoD policies and controls can be brutal. And, there is a never-ending list of organizations that have fallen victim to the crushing outcomes. 

Here’s a top 8 list of the biggest failures:

Enron Scandal (2001)

• • One of the most infamous corporate scandals in history
  • Executives were able to manipulate financial statements and hide billions in debt
  • Lack of SoD allowed CFO Andrew Fastow to create and manage off-the-books partnerships that concealed Enron's true financial state

• • Trader Jérôme Kerviel caused losses of €4.9 billion
  • Kerviel had knowledge of the bank's control systems from his previous back-office role
  • He was able to exceed trading limits and conceal unauthorized trades due to inadequate SoD between front and back office functions

• • Nick Leeson, a derivatives trader, caused losses of £827 million, leading to the bank's collapse
  • Leeson was able to both execute trades and settle them, violating basic SoD principles
  • The lack of oversight allowed him to hide losses and take increasingly risky positions

• • Employees created millions of fraudulent accounts without customer consent
  • Lack of SoD between sales and account creation processes allowed the fraud to continue undetected
  • Aggressive sales targets and inadequate controls contributed to the widespread abuse

• • The German payment processor collapsed after €1.9 billion went missing
  • CEO Markus Braun and COO Jan Marsalek had outsized control over the company's operations
  • Lack of SoD allowed executives to potentially manipulate financial statements and deceive auditors

• • Trader Bruno Iksil, known as the "London Whale," caused losses of over $6 billion
  • Inadequate SoD in risk management allowed traders to value their own trades and hide mounting losses

• • Revealed $1.2 billion in inflated profits over seven years
  • Lack of SoD allowed top executives to put excessive pressure on subordinates to meet unrealistic targets
  • Weak internal controls and audit processes failed to detect the long-running fraud

• • Engineers were able to implement software to cheat emissions tests without adequate oversight
  • Lack of SoD between software development and compliance functions allowed the deception to continue for years

While these failures seem so large and unlikely, they really can become any organization’s reality when SoD policies are neglected. And, that happens more often than you might think. IT often carries the burden of having to protect an organization under pressure from itself, and these examples show why. In each case, stronger SoD policies and enforcement could have potentially prevented or at least mitigated the impact of these scandals.

What are the key capabilities of IGA systems that support SoD?

Modern IGA systems offer several features to support SoD:

1. Role Mining and Management: Analyzing existing access patterns to define clear, non-conflicting roles.
2. SoD Rule Definition: Allowing organizations to define and enforce custom SoD policies.
3. Access Request and Approval Workflows: Implementing multi-step approval processes that align with SoD policies.
4. Continuous Monitoring: Detecting and alerting on potential SoD violations in real-time.
5. Reporting and Analytics: Providing insights into SoD status and potential risks across the organization.
6. Automated Remediation: Suggesting or automatically implementing access changes to resolve SoD conflicts.

What should I consider before implementing an IGA/SoD solution? 

1. Policy Definition: Clearly define your SoD policies based on business needs and regulatory requirements.
2. Stakeholder Engagement: Involve key stakeholders from IT, security, compliance, and business units.
3. Technology Evaluation: Choose an IGA solution that aligns with your specific SoD needs and integrates with your existing systems.
4. Phased Implementation: Consider a phased approach, starting with critical systems or high-risk areas.
5. Change Management: Prepare for the organizational impact and potential resistance to new processes.
6. Continuous Improvement: Plan for ongoing monitoring and refinement of your SoD policies and processes.  ← This part is important, build a process that allows for change in your policies!

What are common challenges with implementing SoD in complex hybrid environments?

Implementing Separation of Duties (SoD) in complex, hybrid environments can be challenging due to various factors. Here are some common challenges:

1. Lack of documentation:
Older or home-grown systems may lack proper documentation, making it hard to identify and map out existing access rights and responsibilities.  HR teams are also not used to thinking in systems terms, making it hard to partner.

2. Technical limitations:
Home grown systems might not have the granular access control features needed to implement SoD effectively, resulting in extra service accounts being created, or other workarounds. 

3. Integration issues:
Complex environments often involve multiple interconnected systems, making it challenging to implement SoD consistently across all platforms.

4. Resource constraints:
Smaller organizations or teams may lack the personnel to properly separate duties without overburdening staff.

5. Skill set limitations:
The specialized knowledge required to manage legacy systems may be concentrated in a few individuals, making it difficult to separate their duties.

How Clarity makes it easy to implement Separation of Duties policies.

Clarity has created a uniquely simple approach to SoD policy enforcement.  Since Clarity provides universal visibility into all accounts and entitlements in a company's infrastructure, you have everything needed at your fingertips.  Here’s how other companies have solved it with Clarity.

Create SoD policy tags for each separation that needs to be managed.  Tag entitlements with the SoD tag. Each policy is it’s own tag which keeps things separate and easy to manage.
Clarity will refresh all identities, and automatically tag identities that violate any SoD policy with
There’s a specific SoD access review, where you can review and approval any SoD exceptions so you have an audit trail for governance
There’s specific reports to pull both identities and entitlements with changes tied to SoD for any ad-hoc requests your editors have

If you can tag entitlements, you can enforce SoD policies.  It really is that simple.  

Schedule a demo today to see first-hand how we are redefining the realm of Identity Governance.