# Separation of duties

> Source: Courseiva IT Certification Glossary — https://courseiva.com/glossary/separation-of-duties

## Quick definition

Separation of duties means that no single person should have complete control over a sensitive process from start to finish. Instead, different people handle different steps so that one person cannot misuse the system without being caught. For example, the person who approves a purchase should be different from the person who processes the payment. This reduces the risk of mistakes or dishonest behavior.

## Simple meaning

Imagine you are running a small charity that collects donations and then uses that money to help people. If one person collects the cash, records the donation, decides who gets help, and then hands out the money, that person could easily take some cash for themselves without anyone knowing. There is no check on their actions. To prevent this, you split the job. One person collects donations and records them. A different person decides which families receive help based on the records. A third person actually hands out the money, but only after checking the approved list. If anyone tries to cheat, the others are likely to notice because they each see only part of the picture.

In the IT world, separation of duties works the same way. Instead of one administrator having every permission, the organization divides tasks so that no one person can compromise the system alone. For instance, a developer writes code, but a different person reviews and approves that code before it is deployed to a live server. The person who reviews the security logs cannot also change those logs. This principle is built into many operating systems, databases, and enterprise applications through role-based access control. It is a fundamental part of good security governance because it forces collaboration and oversight. Even if someone is trustworthy, separating duties protects them from being blamed if something goes wrong, and it protects the organization from insider threats.

## Technical definition

Separation of duties (SoD), also known as segregation of duties, is a core security and internal control principle that requires more than one person to complete a sensitive or critical process. The goal is to prevent any single individual from being able to execute a set of actions that could lead to fraud, data corruption, or unauthorized changes. This concept is formally defined in frameworks such as the NIST Special Publication 800-53 (specifically the AC-5 control, Separation of Duties) and is also a key component of the COSO internal control framework, ISO 27001 Annex A.9.2.3, and the Sarbanes-Oxley Act (SOX) for financial systems.

In practice, separation of duties is implemented through access control mechanisms, often using Role-Based Access Control (RBAC) or Attribute-Based Access Control (ABAC). Administrators define distinct roles with specific permissions. For example, in a database environment, the role of Database Administrator (DBA) might be split into three roles: a backup operator, a security administrator, and a schema developer. No single role has permissions to both modify data and change audit logs. In enterprise resource planning (ERP) systems like SAP or Oracle, SoD is enforced by conflict-of-interest rules that prevent a user from holding two incompatible roles (e.g., a user cannot be both a purchase requisition creator and a purchase order approver).

SoD operates at multiple levels. At the organizational level, it defines job responsibilities and reporting structures. At the system level, it restricts permissions through operating system controls, application logic, and database views. For example, in a Linux environment, the root account is a powerful single point of failure. To enforce SoD, organizations use sudo with specific command whitelists, requiring a separate approval for high-risk actions. In cloud environments like AWS, SoD is achieved using IAM policies that enforce the principle of least privilege, combined with multi-person approval workflows for changes to production resources. Audit trails and logging are essential for SoD because they provide the evidence that duties were properly separated and that the controls worked as intended. Without logs, there is no way to verify that separation was maintained. Organizations regularly perform SoD reviews using automated tools that scan user permissions and flag violations, such as a single user having both 'create user' and 'approve access requests' permissions.

## Real-life example

Think about how a bank handles a large cash withdrawal. You walk in and ask to take out ten thousand dollars. The teller cannot just open the vault and hand you the money. Instead, the teller enters the request into the system, prints a receipt, and then a manager must come over with a special key or code to authorize the vault opening. The manager checks your account balance and the teller's paperwork. Only then does the teller count out the cash and give it to you. The teller cannot do it alone, and the manager cannot do it alone either. One person cannot steal the bank's money without the other noticing (or colluding). That is separation of duties in action.

Now map this to an IT scenario. In a company that manages customer data, a support employee can view customer records to help with a problem. However, that same person cannot export all customer data to a spreadsheet or delete records. Those actions require a supervisor's approval in the system. The developer who builds a new feature cannot push that code directly to the live website. Instead, the developer submits the code to a repository, a peer reviews it, and a deployment engineer releases it to production after automated tests pass. If any one person had the ability to both write code and deploy it, a malicious or careless developer could introduce a backdoor or break the site without anyone checking. By separating the duties, the organization creates a safety net. The analogy shows that separation of duties is not about distrusting everyone; it is about building a system that assumes one person might make a mistake or be tempted, and putting checks in place to protect both the organization and the employee.

## Why it matters

Separation of duties matters because insider threats are one of the most dangerous risks an organization faces. An insider already has legitimate access, which makes their actions harder to detect than an outsider's. By enforcing SoD, organizations dramatically reduce the chance that a single person can cause serious harm, whether through fraud, data theft, or accidental misconfiguration. This principle is not optional for regulated industries. Financial institutions, healthcare providers subject to HIPAA, and companies handling credit card data (PCI DSS) are all required by law or regulation to enforce separation of duties. Failure to do so can lead to audits failures, fines, and loss of business.

In everyday IT operations, SoD prevents many common problems. For example, if the same person who manages backups also restores from backups, they could secretly restore an old database to cover up a theft. If a network administrator can both change firewall rules and review firewall logs, they could hide a security breach. SoD forces these tasks to be performed by different people, creating an automatic second pair of eyes. This also helps with disaster recovery planning because no single person becomes a single point of failure; if one person leaves, the knowledge and permissions are distributed.

For IT professionals, understanding SoD is crucial when designing systems and writing policies. You need to know when to split roles, how to document the separation, and how to use access control systems to enforce it. A common mistake is to think that SoD is only for large enterprises. Even a small startup with a handful of employees can apply SoD by using separate accounts for different responsibilities and requiring code review before deployment. It is a mindset that builds resilience into every layer of the organization.

## Why it matters in exams

Separation of duties is a frequent topic on major IT certification exams, especially those focused on security, governance, and management. For CompTIA Security+, it appears in Domain 2 (Architecture and Design) and Domain 3 (Implementation) under security controls and identity and access management. The exam expects you to identify scenarios where SoD is missing and to recommend the correct control. For example, a question might describe an employee who can both create purchase orders and approve payments, and you need to recognize that this violates SoD. The CISSP exam covers SoD heavily in Domain 3 (Security Architecture and Engineering) and Domain 4 (Communication and Network Security), as well as in Domain 7 (Security Operations). You will need to understand how SoD relates to other principles like least privilege, need-to-know, and defense in depth. CISSP questions often present complex governance scenarios where you need to determine whether the control is administrative, technical, or physical, and SoD is typically an administrative control implemented through technical means.

For the CISA (Certified Information Systems Auditor) exam, SoD is a core concept in the governance and management domain, as well as in the information systems operations and business resilience domain. Auditors must evaluate whether SoD is properly enforced and whether there are compensating controls when it is not possible. The exam may ask about testing SoD through user access reviews and segregation of duties matrices. The PMP exam, while not a security certification, touches on SoD in the context of project governance and risk management. You may see questions about assigning project roles to prevent a project manager from also being the quality control reviewer.

For the AWS Certified Security – Specialty exam, SoD is implemented through IAM policies, service control policies, and multi-party approval workflows. Questions often require you to choose the correct IAM policy that enforces separation between developers and production environments. For the Microsoft SC-900 and SC-300 exams, SoD appears in the context of Azure role-based access control and Privileged Identity Management (PIM). You need to understand how to create custom roles that enforce separation. Regardless of the exam, the pattern is the same: the question will present a scenario with a conflict of interest or a single point of failure, and the correct answer will involve splitting responsibilities among different individuals or roles.

## How it appears in exam questions

Exam questions about separation of duties typically fall into three patterns: scenario-based, concept definition, and control identification. In scenario-based questions, you are given a brief story about an organization's operations. For example, 'A company has one database administrator who is responsible for creating user accounts, assigning permissions, and reviewing access logs. Which security principle is being violated?' The answer is separation of duties because the administrator has conflicting responsibilities that could allow them to hide unauthorized access. A variation of this involves financial systems: 'An employee in accounting can create vendor records and also process payments to those vendors. What type of risk does this create?' The answer is fraud risk, and the control is to separate those duties.

Another common question type asks you to identify which control is being described. For instance, 'Which security principle requires that two or more people be involved in a critical task to prevent a single point of failure?' The answer is separation of duties (or segregation of duties). Some questions may ask you to distinguish between separation of duties and least privilege. The trap here is that least privilege limits the amount of access, while separation of duties limits the combination of accesses.

A more advanced pattern appears on CISSP and CISA exams: questions about compensating controls. If separation of duties is not feasible due to a small staff size, what can be done? The answer might be enhanced logging and monitoring, mandatory vacations, or rotation of duties. For example, 'A small nonprofit has one IT administrator who handles all systems. Which control best compensates for the lack of separation of duties?' The correct answer could be 'requiring the administrator to take annual leave and having another staff member review logs during that period.' You may also encounter questions that ask you to interpret a SoD matrix or to identify violations from a set of user permissions.

Finally, there are troubleshooting-style questions where you need to figure out why a security event occurred. For example, 'A company discovered that an employee changed their own salary in the payroll system. What control was missing?' The answer is that the employee should not have both the ability to edit payroll data and the ability to approve that change. The corrective action is to implement separation of duties between payroll input and payroll approval.

## Example scenario

You are a security consultant hired by a mid-sized e-commerce company called ShopSmart. The company has twenty employees and one IT administrator named Alex. Alex set up the entire network, created all user accounts, and manages the server that processes customer orders and payments. Alex also reviews the security logs every week. The CEO asks you to evaluate the security. You immediately notice a problem: Alex has too much power. Alex created his own user account, he can add new users and give them permissions, he can access the database of customer orders, and he can delete logs after reviewing them. If Alex wanted to, he could create a fake customer account, place an order with a stolen credit card, ship the product to himself, and then delete the log entries that show the order. No one would ever know because Alex controls both the action and the evidence.

To fix this, you recommend separation of duties. You create three distinct roles. The System Administrator role (still held by Alex) handles server maintenance, updates, and backup configuration, but cannot view customer data or create user accounts. A new Security Officer role (given to a different employee, Maria) is responsible for reviewing logs and creating user accounts. Maria cannot modify the server settings. A third role, Database Auditor (given to a part-time consultant), is given read-only access to the database to review order records. Now, if Alex does something suspicious, Maria will see it in the logs. If Maria misuses her account creation power, the Database Auditor might notice inconsistencies in the audit trail. No single person can both commit fraud and cover it up. The CEO approves the change because the risk is clearly explained. This scenario is typical of what you might see in an exam: a single person with conflicting duties, leading to a risk that must be mitigated by splitting roles.

## Common mistakes

- **Mistake:** Thinking that separation of duties is the same as least privilege.
  - Why it is wrong: Least privilege means giving a user only the minimum permissions needed to do their job. Separation of duties means splitting a process so no one person has all the permissions that would allow them to misuse the process. They are related but different concepts. A user can have least privilege and still have a conflict of interest if their permissions allow them to both initiate and approve an action.
  - Fix: Understand that least privilege is about the amount of access, while separation of duties is about the combination of access. Always ask: Could this one person perform two steps in a critical process? If yes, you need separation, even if each step has minimal permissions.
- **Mistake:** Believing that separation of duties only applies to financial systems.
  - Why it is wrong: While SoD originated in accounting, it is critical in IT for code deployment, database changes, user management, and security monitoring. Any process where a single person could cause harm or hide their actions should have separation of duties.
  - Fix: Apply SoD to any sensitive system, including production servers, source code repositories, user directories, and security tools. For example, the person who approves firewall rules should be different from the person who implements them.
- **Mistake:** Assuming that SoD means you need two people for every single action.
  - Why it is wrong: That would be impractical and slow. SoD is only needed for high-risk actions or processes that span multiple sensitive functions. Routine tasks like reading a file or creating a temporary ticket do not require separation.
  - Fix: Focus on high-risk processes: where there is a potential for fraud, data loss, or unauthorized changes. Conduct a risk assessment to identify which tasks need separation, and apply compensating controls (like logging) for lower risk tasks.
- **Mistake:** Thinking that SoD is a technical solution that can be completely automated.
  - Why it is wrong: SoD is primarily an administrative control. The technical tool (like RBAC) enforces it, but the policy must be designed by people, and the enforcement must be audited. Automated tools can prevent a user from having two conflicting roles, but they cannot detect collusion between two users.
  - Fix: Implement technical controls like role-based access control and IAM policies, but also require manual reviews, periodic audits, and a culture of accountability. Document the SoD policy and train employees on why it matters.

## Exam trap

{"trap":"The exam question describes a situation where an administrator has the ability to both create user accounts and assign permissions to those accounts. The question asks: 'What control should be implemented to reduce the risk?' Many learners see the word 'admin' and think the solution is to give the admin less privileges (least privilege). They answer 'Implement the principle of least privilege.'","why_learners_choose_it":"Learners often confuse least privilege with separation of duties because both involve restricting access. They focus on reducing the admin's power rather than splitting the tasks between two people. The trap is that least privilege would still allow one person to create a user and then assign that user the highest permissions, which is the same conflict.","how_to_avoid_it":"Identify the conflict: the same person can both create an identity and grant it authority. This is a classic SoD violation. The correct solution is to have one person create accounts and a different person (or a separate role) assign permissions. Do not jump to 'least privilege' until you have determined whether the core issue is one person having conflicting duties. If the conflict exists, SoD is the primary control."}

## Commonly confused with

- **Separation of duties vs Least privilege:** Least privilege limits the permissions a user has to the minimum necessary for their job. Separation of duties ensures that no one person has a combination of permissions that would allow them to misuse a critical process. For example, a backup operator might need least privilege to only run backup software, but separation of duties would also require that they cannot restore backups without a second person approving. (Example: A user who can only read files (least privilege) is fine. But if one person can both initiate a payment and approve that payment, that is a SoD issue, not a least privilege issue.)
- **Separation of duties vs Defense in depth:** Defense in depth is the strategy of layering multiple independent security controls so that if one fails, others still protect the system. Separation of duties is one specific control that can be part of a defense in depth strategy. They are not interchangeable. Defense in depth includes firewalls, encryption, and monitoring, not just separation of duties. (Example: A castle with a moat, a wall, and guards inside is defense in depth. Having two different guards for the same gate (one with the key, one with the code) is separation of duties, a single layer within that larger strategy.)
- **Separation of duties vs Mandatory vacation:** Mandatory vacation is a control that requires employees to take a week or more of leave so that their activities can be reviewed by others during their absence. It is a compensating control when separation of duties is not feasible, but it is not the same thing. SoD is a proactive, ongoing control, while mandatory vacation is a periodic detective control. (Example: A small business with one bookkeeper cannot separate duties, so they require the bookkeeper to take two weeks off every year while an outsider reviews the books. That is mandatory vacation, not separation of duties.)

## Step-by-step breakdown

1. **Identify critical processes** — The first step is to inventory all business processes that involve sensitive data, financial transactions, or system changes. Examples include user account management, code deployment, payment processing, and backup/restore operations. Not every task needs separation; focus on those where a single person could cause harm or hide fraud.
2. **Decompose each process into conflicting duties** — For each process, break it down into tasks that could be split. For example, user account creation has tasks like 'request account,' 'approve request,' 'create account,' and 'assign permissions.' Duties conflict if one person can both 'create account' and 'assign permissions' because they could give themselves or a fake user high privileges. Also identify tasks like 'approve' and 'execute' that must be separated.
3. **Define roles with non-overlapping permissions** — Create distinct job roles that each cover only one part of the conflicting duties. For instance, a 'User Provisioner' role can create accounts but not assign permissions. A 'Permissions Manager' role can assign permissions but not create accounts. Document these roles and the permissions they include. Use a role-based access control (RBAC) system to enforce these boundaries.
4. **Assign users to roles and verify no conflicts** — Assign each employee to one or more roles, but ensure no single user holds two roles that are conflicting. Many organizations use a SoD matrix (a grid showing which role combinations are forbidden). Automated tools can scan the assignment and flag violations. For example, if a user is both in 'Purchase Order Creator' and 'Purchase Order Approver,' that is a violation.
5. **Implement monitoring and audit trails** — Even with SoD in place, you need logging to detect if the separation is being bypassed or if two users are colluding. Enable detailed audit logs for every privileged action. Set up alerts for anomalies, such as an account creation followed immediately by a high permission assignment from the same IP address. Regularly review these logs as part of security audits.
6. **Conduct periodic SoD reviews and updates** — Organizations change over time, and roles can drift. Conduct quarterly or annual reviews of user permissions to ensure SoD is still intact. When employees change positions, their role assignments should be updated immediately. Use automated reporting tools to identify new conflicts introduced by system changes or role modifications.

## Practical mini-lesson

Separation of duties is not just a concept you read about, you have to apply it in real systems. As an IT professional, you will often be responsible for designing access control structures in environments like Active Directory, Azure AD, AWS IAM, or on-premises Linux/Unix systems. The first practical step is to understand the business processes that your systems support. Talk to the accounting department, the development team, and the compliance officer to learn which transactions must be split. For example, in an SAP environment, the classic conflict is that a user should not be able to create a vendor, create a purchase order, and then approve payment to that vendor. In a cloud environment, the equivalent conflict is having a developer with permission to both write code and deploy it to production.

When you configure RBAC, you must create granular roles. In AWS, you might create an IAM role called 'DevDeploy' that can only push code to a staging environment, and a separate role called 'ProdDeploy' that is given only to a release manager. You would then create a policy that prevents any single user from assuming both roles. In Azure, you can use Privileged Identity Management (PIM) to require approval before a user can activate a privileged role, which is a form of dynamic SoD. In Active Directory, you can delegate administration by creating separate OUs for different responsibilities. For example, one group of admins can reset passwords, but a different group can modify group memberships.

What can go wrong? The most common failure is 'role creep', over time, users accumulate permissions from multiple roles, and eventually someone ends up with a conflict. Another problem is that small teams cannot always separate duties because there are not enough people. In that case, you need compensating controls. You might implement mandatory vacations (where someone else covers the role), enhanced logging and suspicious activity alerts, and regular third-party audits. You can also use break-glass accounts that are closely monitored. The key is to not ignore SoD just because it is hard, you must document the risk and the compensating controls for compliance.

Another practical issue is that SoD can conflict with the need for speed. In DevOps, for example, continuous deployment requires developers to push code rapidly. Strict SoD would slow that down. The solution is to use automated pipelines that enforce separation through code review (a person reviews the code) and automated tests (the system rejects untested code). The developer cannot bypass the pipeline, so the separation is automated. This is an example of 'technical enforcement' of SoD. Always aim for automated enforcement when possible, as it is more reliable than relying on people remembering to follow a policy.

## Memory tip

Remember SoD as 'Two keys, one lock', no single person holds both keys to a critical system.

## FAQ

**What is the difference between separation of duties and segregation of duties?**

There is no difference. The terms are used interchangeably in IT security and auditing. Both mean splitting critical tasks among multiple people to prevent fraud or errors.

**Can separation of duties be applied in a small company with only two IT staff?**

Yes, but it is harder. You can still split tasks, for example, one person handles user account creation, the other approves changes. You can also use compensating controls like enhanced logging and third-party audits to make up for the lack of full separation.

**Is separation of duties required by law?**

For many regulated industries, yes. SOX requires it for financial reporting systems, HIPAA expects it for access to health data, and PCI DSS mandates it for cardholder data environments. Even when not legally required, it is considered a best practice.

**Does separation of duties apply to cloud environments?**

Absolutely. In AWS, you use IAM policies and Service Control Policies (SCPs) to enforce SoD. For example, you can prevent a developer from having both the 'ec2:RunInstances' and 'iam:PassRole' permissions, which would allow them to spin up an instance with an overly permissive role.

**What is a SoD matrix?**

A SoD matrix is a grid that lists job roles or functions along the rows and columns. The cells indicate whether two roles conflict (should not be held by the same person). It is used during user access reviews to quickly spot violations.

**How often should separation of duties be reviewed?**

At least annually, but more frequent reviews are better, especially in fast-changing environments. Any time an employee changes roles or a new system is introduced, you should check for conflicts. Automated tools can alert you in real time when a conflict is created.

## Summary

Separation of duties is a fundamental security principle that prevents any single person from having too much control over a critical process. By dividing tasks such as creation, approval, and execution among different individuals, organizations reduce the risk of fraud, human error, and intentional misuse. This concept is deeply embedded in security frameworks like NIST 800-53, ISO 27001, COSO, and regulatory requirements such as SOX, HIPAA, and PCI DSS.

For IT professionals, implementing separation of duties means designing role-based access control systems carefully, documenting conflicting duties, and using automated tools to enforce and monitor the separation. It is not the same as least privilege, but the two work together. In exams like CompTIA Security+, CISSP, CISA, and cloud certifications, you will be tested on your ability to recognize violations and recommend the correct control. The typical exam question presents a scenario where one person can perform two steps in a sensitive process, and you need to identify that as a separation of duties issue.

The key takeaway for your exam preparation is this: whenever you see a situation where a single user can both initiate and approve a high-risk action, or can both perform an action and audit that same action, the answer is almost always separation of duties. Remember the memory tip: 'Two keys, one lock.' No matter what certification you are pursuing, mastering this concept will serve you well in both the exam and your career.

---

Practice questions and the full interactive page: https://courseiva.com/glossary/separation-of-duties