Separation of duties

One person, start to finish

Priya Nair became Harbor Clinic's billing supervisor in October. Supervisors approve supplier payments, so Priya requests Approve supplier payments in the billing system. Priya already holds Create suppliers, given in April to cover for an accounts clerk on leave and never removed.

Each entitlement is reasonable on its own. Together, they would let one person carry a sensitive process from start to finish. Someone holding both could add a supplier called Harbor Medical Supplies with their own bank account details, enter an invoice from it, and approve the payment. Nothing in the billing system would look unusual, because every step was taken by someone allowed to take it. Nobody suspects Priya of anything. The problem is that if a payment like that were ever made, nothing in the process could have stopped it or noticed it.

Separation of duties divides a sensitive process so that no single person can complete it alone. One person creates a supplier and another approves payments to it, so each step is checked by someone with no stake in the step before. It catches honest mistakes as well as fraud. A supplier entered with the wrong bank details is more likely to be noticed by a second person than by the one who typed them.

Toxic combinations

A toxic combination is a set of entitlements that are each acceptable alone but together let one person complete a sensitive process with nobody else involved. Harbor's list starts with four:

• Create suppliers and Approve supplier payments in billing. One person could invent a supplier and pay it.
• Order controlled medication and Receive controlled medication in pharmacy. One person could order medication, record it as received, and keep some of it, with the paperwork still matching.
• Carrying out access changes and approving access requests. One person could approve a request and fulfil it, including their own, with no independent step between the decision and the change.
• Editing a role and holding that role. One person could add permissions to a role they hold and receive them without making any request.

Harbor records its conflicting pairs in a matrix, with entitlements on both axes:

All names, identifiers, and records in these examples are fictional.

The fourth combination does not fit a matrix, because it depends on which role is being edited and who holds it. Harbor handles it with a rule of its own: nobody edits a role they hold.

Each conflict rule has an owner, like any other access decision. The finance director owns the billing rule, the pharmacy manager owns the medication rule, and Morgan Hale owns the rule for access changes in patient records. Harbor keeps the list short on purpose. Reading the rota and editing your own phone number is a harmless pair, because neither completes anything sensitive. A matrix that flags every pair in every system gets ignored. One that flags the combinations that would let someone steal, divert medication, or grant themselves access gets attention.

Preventing and detecting

There are two moments to catch a toxic combination. A preventive check runs when access is requested or assigned, before the combination exists. A detective check looks for combinations that already exist, during access reviews or regular scans of who holds what.

Priya's request meets the preventive check. The identity system compares the requested entitlement, together with everything Priya already holds, against the conflict rules, and stops the request before it goes on to the approvers:

Request        REQ-26-03871
Requested by   Priya Nair, Billing
Entitlement    Approve supplier payments, billing
Check          Conflict with rule SOD-BIL-01
               Priya already holds Create suppliers, billing
               (granted 2026-04-06 for leave cover, no end date)
Options        1. Deny the request
               2. Remove Create suppliers, then grant
               3. Grant with an exception: owner, compensating
                  control, and end date required
Decided by     Finance director, owner of SOD-BIL-01
Decision       Option 2
Result         2026-10-14 11:20  Create suppliers removed, confirmed
               2026-10-14 11:21  Approve supplier payments granted,
                                 confirmed

The finance director chose the cleanest option. The leave cover ended months ago, so Priya no longer needs to create suppliers, and removing that entitlement resolves the conflict without any exception. Had Priya still needed both, the choice would have been between denying the request and approving an exception with conditions attached.

Preventive checks only see access that passes through them. Access granted directly inside an application, a role changed to include a new entitlement, or a conflict rule added after people already hold both entitlements can each create a combination that no request ever showed. Detective checks catch those. A monthly scan that finds two pharmacy staff holding both Order controlled medication and Receive controlled medication puts them in front of the pharmacy manager, and the next access review asks the same question.

Separation also comes in different strengths. Static separation means a person cannot hold both entitlements at all. That is what Harbor applies to Priya: approving payments and creating suppliers stay with different people. Dynamic separation lets a person hold both roles but not activate both in the same session, so a supervisor who signs in to create suppliers has to sign in again, under the other role, to approve payments. Per-item separation lets a person hold and use both, but never perform both steps on the same item. The billing system could let Priya create suppliers and approve payments, but refuse to let Priya approve a payment to a supplier Priya created, or a payment Priya entered.

The looser forms are more flexible, which helps small teams. Per-item separation is checked by the application at the moment of the decision, because only the application knows who did each step of each payment, and it has to record every step to do so. Administering roles safely shows a check like this written as a policy rule. Static separation can be checked from the list of who holds what.

When a small team cannot split the work

Some work cannot be split. Harbor's main site has one pharmacist on the night shift. When a ward needs controlled medication during the night, that pharmacist orders it from the clinic's central stock and receives it into the pharmacy when it arrives, because nobody else is there to do either.

Blocking the combination would stop the pharmacy from working at night. Ignoring it would leave exactly the risk the conflict rule exists to control. The answer is an exception with a compensating control: a different control that reduces the same risk when the preferred one is not possible. Here, a second pharmacist independently checks the night's controlled medication orders, receipts, and stock counts the next morning and signs the check. A diversion during the night would be visible within hours, to someone who was not involved.

Harbor records the exception like any other, with a named owner and an end date:

Exception      SOD-EXC-007
Rule           SOD-PHA-01, order and receive controlled medication
Applies to     Night pharmacist on duty, main site
Reason         Single pharmacist on the night shift
Owner          Pharmacy manager
Compensating   Day pharmacist checks the night's orders,
control        receipts, and stock counts by 10:00 and signs
               the check
Ends           2027-05-31, then decided again

The end date matters even though the night shift is not going away. Staffing changes, a second night role may be funded, and the compensating control itself can quietly stop happening. At each end date the owner decides again, with evidence that the morning checks were done. A review that finds unsigned checks treats the exception as broken, not merely overdue.

Separation in administration

The same thinking applies to the people who manage access, and it matters more there, because they can change the controls that apply to everyone else.

Administrators do not approve their own elevation. When Jordan Ellis requests EHR_ADMIN for a maintenance window, the approval comes from Morgan Hale, never from Jordan, and someone other than Jordan reviews the elevation afterwards, as Temporary, privileged, and emergency access described.

Editing roles and assigning roles are separate authorities. Someone who could do both could build a role with any permissions and give it to anyone, including themselves, and every step would look authorized. At Harbor, the owners of each application's roles maintain what those roles contain, while managers and the access team assign them, so a role change and an assignment each pass through a different person. And nobody edits a role they hold, because the edit would grant them the change directly.

Nobody can grant more than they hold. The pediatrics nurse manager can assign roles within the unit, which saves a request for every new starter. The identity system lets the manager assign only roles whose permissions the manager holds and is allowed to pass on. The manager can give a new nurse the Pediatrics registered nurse role, but not EHR_ADMIN, and not a custom role that happens to contain it. Without that limit, anyone who could assign roles could reach any permission in the system by assigning it to an account they control.

The conflict rules need protecting too. Someone who can switch off SOD-BIL-01 can make any combination acceptable. Changes to conflict rules and their exceptions are approved by the rule's owner and by someone outside the team that maintains them, and every change is recorded.

All of this has to be enforced by the systems, not only written in a policy. A policy that administrators must not approve their own elevation is only as strong as the identity system's refusal to send the request to them.

Whether these controls still hold months later is a question for the people who look at access again. Continue to Access reviews to see how those reviews are planned and decided.