Organisational Structure and Segregation of Duties

Organisational structure and segregation of duties. This lesson is about arranging an organisation so that no single person can both make a mistake, or commit a fraud, and then hide it.

Start with a change that went wrong in production. You trace it back and find that one engineer requested it, approved it, wrote it, deployed it, and signed off the post-implementation review. Every box on the form is ticked. And every box was ticked by the same person.

Nothing detected the problem, because there was never anyone in a position to. That is what segregation of duties prevents. When one person holds two of the key duties over the same transaction, the control weakens. When one person holds all four, there is effectively no control at all.

So which duties should separate? Four of them, and the exam expects the set: authorisation, custody, recording and verification. When one person holds two or more of these over the same transaction, you have a segregation problem.

First, authorisation, approving that something should happen. This is the permission to act, and it should sit apart from the doing.

Then custody, holding or controlling the asset, for example access to production. And recording, creating the record of what happened. Keep the person who controls the asset apart from the person who writes the record of it.

And fourth, verification, independently checking that it was done correctly. Authorisation, custody, recording, verification. Hold two over the same transaction and the control weakens. Hold all four, and you are back to our engineer.

The most heavily tested I-T conflict is developing a change and promoting it to production. If the same person can both build code and deploy it, they can move untested or unauthorised code into the live environment with nobody in between. This is why development and production access are separated as a matter of course.

And watch for the reporting-line trap, because it returns here. The person who creates a user account should not also approve the access. The person who runs a system should not be the only one who reviews its logs. And the security function should not report to the operations it is meant to challenge. Oversight cannot report to what it oversees, exactly as with the audit function in Domain 1.

Real teams are sometimes too small to split every duty, and the exam knows this. What it will not accept is treating small size as a reason to abandon the control. The expected answer is a compensating control, and the standard one for segregation is independent oversight: someone who is not the administrator reviews the activity logs.

That review does not prevent an improper action the way separation would, but it makes one detectable by a party with no stake in hiding it. That is the trade a compensating control makes, detection in place of prevention. But it only works if the reviewer is genuinely independent. Self-documentation fails, because the person creating the record is the very person you need assurance over.

So carry two things away. A small team does not remove the need to compensate, it just changes how. And a compensating control that relies on the conflicted person is not a control, it is the conflict restated.