Independent thinking. Informed defence.

CISO Times

Intelligence for the people behind the defence.

The CISO Decision Brief

How do we…

How do we separate duties when there are only a few people?

7 decision pointsThe pack behind this answer: Security Exception, Waiver & Segregation of Duties

Add to board memo

The short answer

Recommendation
Separate the duties wherever you can, starting with the second approvals your bank and software already offer. Where you cannot, have someone outside the conflict check the work on a fixed schedule from data they obtain themselves, and record the conflict as an exception with an expiry date.
Reasoning
In a team of two or three most conflicts cannot be separated internally. They can almost always be covered. The aim is that no one person can make and hide an unauthorised change, payment or access grant without a second person seeing it. Separation removes the conflict and needs no exception. A covered conflict is only as good as its control: the reviewer must be independent and see data the person in conflict could not change. An auditor expects a small firm to know which duties are combined and to show that someone checked.
Considerations
  • The deadlines, review frequencies and approval levels are the defaults in the CISO Times exceptions pack. Your own standard may set different ones. In those defaults High conflicts are reviewed quarterly, Medium every six months and Low at the annual review of the conflict list.
  • Lower a conflict's rating only with a recorded reason and a review, shown to work, that would catch misuse. The conflict rating sets how often it is reviewed; the exception's score sets the approver and the longest duration.
  • A service provider can review your staff, but never its own engineers. Nobody reviews a conflict they hold, or approves an exception whose control they perform.
  • Where nobody outside the conflict can check the work, escalate to the risk owner and whoever approves High exceptions. A High conflict with no reviewed control counts as unmitigated in the management report.

The decision, step by step

Select any step for the reasoning behind it and where the pack covers it.

  • Start
  • Step
  • Decision
  • Outcome
  • Loop back
StartA small team holds duties that should be kept apartStepList who holds which duties, across every systemDecisionDoes one person hold a pair of duties on the list?OutcomeNo conflict: check again at each access reviewDecisionCould they act and hide it without anyone else seeing?StepAgree an interim check with the risk owner nowDecisionCan you separate the duties within 5 working days?OutcomeSeparate it, and confirm with a fresh access listingDecisionIs there someone outside the conflict who can check the work?OutcomeTake it to the risk owner: nobody can check the workStepPick a control that would catch the misuseStepSend the evidence where the person cannot change itStepRun it once, then raise an exception with an expiryDecisionDoes the approver for the exception's band accept it?OutcomeSeparate it by the date the approver setsStepReview it at the frequency its rating setsDecisionDid the control run every time, done by someone else?OutcomeTreat it as a failed control: re-score and tell the risk ownerDecisionCould the duties now be separated?OutcomeKnown, covered and checked: renew it at expiry

Keyboard: Tab to a step, arrow keys move along the flow, Enter pins its explanation, + and − zoom, 0 fits the diagram, Esc closes. The text version below has the same content.

Where a step quotes a number, it is the default in the CISO Times pack. Your own standard may set a different one.

Read as text

The same flow written out: each step, its reasoning and where the pack covers it. 20 steps.

  1. Start

    A small team holds duties that should be kept apart

    In a team of two or three, most conflicts cannot be separated internally. They can almost always be covered. The aim is that no one person can make and hide an unauthorised change, payment or access grant without a second person seeing it.

    In the pack

  2. Step

    List who holds which duties, across every system

    Export users and roles from each system in scope and compare them with the list of conflicting duty pairs. Include service provider, shared and administrator accounts. The conflict often spans two systems, such as the accounting package and the bank portal. Look again whenever someone leaves or is off long-term, because their duties drift to whoever is left. A spreadsheet and a lookup are enough.

    In the pack

  3. Decision

    Does one person hold a pair of duties on the list?

    Typical pairs: setting up a supplier and approving its payment, administering a system and reviewing its logs, writing code and deploying it, granting access and reviewing it. Count a person who could hold both, not only one who does today. If you have not yet checked a system, treat it as a yes until you have.

    In the pack

  4. Outcome

    No conflict: check again at each access review

    Keep the check in your joiner and mover process: before anyone gets new access, compare it with the list. Run the full comparison again at each periodic access review, and after any restructure or new core system.

    In the pack

  5. Decision

    Could they act and hide it without anyone else seeing?

    That is a High conflict: for example, adding a supplier and paying it when nobody else sees the bank statements. Medium means another control would probably, but not certainly, catch it later. Low means small damage, or caught quickly by routine checks. Start from the list's default rating and raise it for your circumstances. Lower it only with a recorded reason and a review, shown to work, that would catch misuse.

    In the pack

  6. Step

    Agree an interim check with the risk owner now

    A High conflict with nothing in place is the gap a fraud uses. If no control is running yet, the pack's default is to report it to the risk owner and the person's line manager within 2 working days, and agree a stopgap straight away, such as a second person checking every payment until a proper control is running.

    In the pack

  7. Decision

    Can you separate the duties within 5 working days?

    Try in this order: remove access the person does not truly need; give one duty to someone else; make the system require a second person; move one duty to a provider or other outside party. Dual payment authorisation at the bank, approval rules in the accounting system and required reviews in the code platform are the cheapest separation there is. Switch them on before designing a manual review.

    In the pack

  8. Outcome

    Separate it, and confirm with a fresh access listing

    Make the change, then prove it: a new export or screenshot showing the combination has gone. A manager's statement is not enough. The conflict is then closed and needs no exception.

    In the pack

  9. Decision

    Is there someone outside the conflict who can check the work?

    The owner or managing director, a non-executive director, the external accountant or the outsourced IT provider can each do it. They need access to reports, not to the systems. They must not be the person in conflict, and should not report to them. A provider can check your staff, but never its own engineers.

    In the pack

  10. Outcome

    Take it to the risk owner: nobody can check the work

    The Standard lets a conflict stay only if someone without it performs a compensating control. With nobody to do that, escalate to the risk owner and to whoever approves High exceptions. A High conflict with no control counts as unmitigated in the management report. One option is to bring in an outside reviewer, such as your external accountant or an adviser.

    In the pack

  11. Step

    Pick a control that would catch the misuse

    Prefer one that prevents over one that detects later, and one the system generates over one that relies on memory. The options are a second approval, an independent review of logs or transactions, automated alerts to someone else, a reconciliation by someone else, or a week's mandatory leave while another person does the work. Keep it short and fixed: a 30-minute monthly slot with the report already in the reviewer's inbox actually happens.

    In the pack

  12. Step

    Send the evidence where the person cannot change it

    The commonest failure is a reviewer checking a report prepared by the person being reviewed. Forward logs to a service where the person in conflict has read-only rights, and have bank statements or system reports go straight to the reviewer.

    In the pack

  13. Step

    Run it once, then raise an exception with an expiry

    Run the control once and keep the evidence, because an untested control does not lower the score. Then raise an exception, in the pack's defaults within 5 working days of finding the conflict. Its score sets the approver and the longest duration. If separation is coming later, make it the remediation plan. A conflict that lasts as long as you stay small still gets an expiry date.

    In the pack

    See also

  14. Decision

    Does the approver for the exception's band accept it?

    In the pack's defaults, a Low exception is decided by the control owner, Medium by the head of information security, High by that head and the accountable executive together. Critical goes to the board or a board risk committee it has delegated to; the management board in a two-tier structure; executive management where there is no board. Nobody decides an exception they requested or whose control they perform: it goes a level up.

    In the pack

    See also

  15. Outcome

    Separate it by the date the approver sets

    A refused conflict is separated by the date the approver sets. Go back to the separation options, including moving one of the duties to a service provider or other outside party.

    In the pack

  16. Step

    Review it at the frequency its rating sets

    In the pack's defaults: High conflicts quarterly, Medium every six months, Low at the annual review of the conflict list. A small firm can combine these into one short meeting. Collect the evidence that the control ran every time it should have since the last review.

    In the pack

  17. Decision

    Did the control run every time, done by someone else?

    Check the right person did it, from data they pulled themselves, and followed up anything unusual. A review that never finds anything does not prove it works: once a year, walk one real item through from start to finish. If you cannot show the runs, treat the answer as no.

    In the pack

  18. Outcome

    Treat it as a failed control: re-score and tell the risk owner

    A missed run, or a run done by the person in conflict, is a failed control. Score the exception again at once without it, which may move it to a higher approver, and report the conflict to the risk owner. Then fix the control or separate the duties.

    In the pack

  19. Decision

    Could the duties now be separated?

    Ask at every review. A new hire, a new system feature or a provider may make separation possible where it was not before. If so, go back and separate.

    In the pack

  20. Outcome

    Known, covered and checked: renew it at expiry

    Record the result and the next review date in your register. At expiry the exception is scored again and renewed. When its renewals run out it goes to the next approval level up. That is deliberate: management should see, at least once a year, the duties it has chosen not to separate.

    In the pack

    See also

Practical checklist

  1. Export users and roles from every system in scope, including provider, shared and administrator accounts, and compare them with your list of conflicting duty pairs.
  2. Rate each conflict from the list's default, and raise it where one person could act and hide it.
  3. For a High conflict with no control, tell the risk owner and line manager within 2 working days in the pack's default, and agree a stopgap at once.
  4. Try to separate first: remove unneeded access, reassign a duty, switch on a system's second approval, or move a duty to an outside party.
  5. Where you cannot, choose a control someone outside the conflict performs, with the evidence sent where the person in conflict cannot change it.
  6. Run the control once, keep the evidence, and raise an exception within 5 working days of finding the conflict.
  7. At each review, check the control ran every time, done by the right person from data they pulled themselves.
  8. Treat a missed or self-run control as failed: score the exception again without it and tell the risk owner.

Evidence to have ready

  • The access exports and comparison that found each conflict, with its rating and the reason for any change from the default.
  • For a separated conflict, the access change record and a current access listing showing the combination has gone.
  • For a covered conflict, the approved exception with its expiry, and evidence of every run: signed reviews, alerts, second approvals or reconciliations.
  • The dated review records, and the yearly walk-through of one real item from start to finish.

Assumptions

  • You have, or will adopt, a list of duty pairs that should not sit with one person, such as the conflict matrix in the CISO Times exceptions pack.
  • Deadlines, review frequencies and approval levels shown are the pack's defaults. Your own standard may set different ones.

Not covered here