Separation of Duties

You define which duties require separation, so define ones you can execute.

The requirement is silent on what must be separated, which hands you the power of definition. A general statement that duties are reasonably divided fails [a]. Name the specific pairs: change approval separated from change execution, log review separated from system administration, account creation separated from granting CUI access. CUI is the controlled unclassified information your contract requires you to protect. Never define a separation you cannot staff, because you will be assessed against your own definition.

Separate authorizing, doing, and auditing.

That three-way split is the pattern that satisfies [b] and [c] in nearly any structure. Whoever approves a change does not implement it, and whoever reviews the logs is not the only administrator generating them.

The purpose is visibility, not prevention.

Separation of duties does not stop a bad act so much as make it impossible to hide, because someone else sees the tracks. Aim the design at that: a second set of eyes on privileged activity beats an elaborate approval chain nobody follows.

A two- or three-person company can meet this without hiring.

Two administrators reviewing each other's activity meets the intent. Here is a three-person model that works. One person runs IT, a second approves changes, and a third reviews logs for everyone including the first. An outside consultant with even an hour a month of genuine log review creates real separation for the auditing leg.

Assigned authority must be real.

An assessor probes whether the person can exercise the duty, not just whether their name is on it. If the change approver says no and the change ships anyway, the separation exists on paper only. Show competence and authority: training records for the assigned duty, an example of a rejected change, log reviews signed by the reviewer.