Separation of duties prevents one person from completing a sensitive process without an appropriate independent check.
A simple example is a payment process: creating a payment and approving that same payment should not automatically be the same person's responsibility.
You don't need a long security definition to explain why that matters. Start with the mistake or misuse the organization wants to prevent, then show how the responsibilities and controls are divided.
Explain the dangerous combination, not just the individual permissions
Imagine a fictional company where an employee can create a supplier, change its bank details, and approve payments to it.
Each permission may be legitimate for some job. The combination deserves attention because it gives one person control over a complete path from creating the destination to releasing money.
That is the useful explanation for a hiring manager: the risk comes from capabilities that should not sit together without appropriate controls.
NIST's definition of separation of duty describes dividing sensitive capabilities so one user cannot misuse the system alone.
Distinguish separation of duties from least privilege
Least privilege asks whether someone has only the access needed for their responsibilities. Separation of duties asks whether particular responsibilities or actions should be kept apart.
A person could have a carefully limited role and still hold an incompatible second role.
In the payment example, “payment preparer” and “payment approver” might each be narrowly scoped. Assigning both to the same person could still defeat the intended independent review.
This is why “we use roles” is not enough. Someone must define which combinations are unacceptable and how exceptions are handled.
Describe two ways to enforce the separation
One approach prevents conflicting roles from being assigned together. Another checks the specific action, such as preventing the person who submitted a request from approving that request.
NIST distinguishes these kinds of static and dynamic separation. You do not need the terminology to explain the business effect, but you should understand the difference when discussing a design.
A small organization may need carefully governed exceptions. That does not mean the conflict disappears. It means the exception needs an owner, a reason, an expiry or review point, and an appropriate independent check.
Build a small lab around the approval decision
You can explore the concept without buying a large governance platform.
Create a fictional access-request workflow with requester and approver identities. Define a rule that the requester cannot approve their own request. Record an approved request from a different authorized reviewer and a self-approval attempt that is rejected.
Label any manual simulation clearly. A spreadsheet showing the intended rule is a design artifact; it is not proof that an application enforces the rule.
Keep the distinction between policy, implementation, and test evidence visible in your portfolio.
Check whether another route bypasses the approval
An approval screen doesn't prove that the whole access process is controlled.
Ask:
- Direct changes: Could an administrator grant the same access outside the workflow?
- Authority: Who is permitted to make that direct change?
- Evidence: Would the change be recorded and reviewed?
- Exceptions: How would an urgent or unusual request be authorized?
These questions help you distinguish the workflow's technical enforcement from the surrounding procedures.
For a small lab, you can demonstrate that one request follows an approval path while acknowledging that privileged administrators have other capabilities. Don't present the exercise as proof that every bypass has been eliminated.
Explain what the lab enforces, what remains a process requirement, and what would need more investigation in production. That makes the demonstration more credible than simply calling it a complete separation-of-duties solution.
Use a plain-English interview answer
Try: “Separation of duties prevents one person from controlling incompatible steps in a sensitive process. I would first identify the conflicting actions, then check how the system prevents or detects the combination.”
Follow it with the payment example or your actual lab. Avoid reciting a control name without explaining the problem it addresses.
The Six-Figure IAM Career Playbook introduces IAM lanes, including governance, and practical ways to build evidence for a career move. The $9 guide helps connect concepts like this to a role and a project rather than leaving them as interview vocabulary.