CAIQ IAM-04: Separation of duties

What the control asks

IAM-04.1: Is the separation of duties principle employed when implementing information system access?

NIST's glossary describes separation of duty as the principle "that no user should be given enough privileges to misuse the system on their own." The classic example is finance: the person who approves a payment should not also be able to send it. In a SaaS company the risky actions are usually shipping code to production, changing infrastructure, granting access and touching customer data.

Which policy usually proves it

Rarely a policy called "separation of duties." The proof is usually spread across:

• the Change Management Policy (a second person reviews and approves changes)
• the Access Control Policy (access requests are approved by a manager or security, not by the requester)
• branch protection or deployment settings that enforce the review in code

Quoted evidence from public policies

Tailscale's change policy is the clearest public example of separation of duties in a small company:

Changes to code in Tailscale’s environment made by an employee or contractor must be tested and approved by another employee prior to being merged and rolled out.

Tailscale, Change management policy, CC0.

It also says how the rule is enforced, and what happens in an emergency:

Exceptionally, employees can push changes without a second review where they are required to mitigate an incident. Changes pushed without prior approval are tagged and audited after the fact, within 2 business days.

Tailscale, Change management policy, CC0.

GitLab's public change policy is shorter and points to an internal standard for the details:

Changes are approved by appropriate stakeholders.

GitLab Handbook, Change Management Policy, CC BY-SA 4.0.

On its own, "appropriate stakeholders" does not say the approver is a different person from the author. A careful reviewer would want that stated.

How GitLab answered

Yes, with no linked evidence in the explanation column, in its CAIQ v4.0.3 submission on the CSA STAR Registry.

A good answer, if your policy supports it

IAM-04.1: Yes. Production changes require review and approval by a second engineer before merge, enforced by branch protection. Access requests are approved by a manager or the security owner, never by the requester. Emergency changes without review are logged and reviewed within [N] business days. See Change Management Policy, section 2, and Access Control Policy, section 3.

When N/A is honest

Not for a provider with staff. But a two- or three-person company can't separate every duty, and buyers know it. Don't answer N/A. Answer Partially, and describe your compensating controls: a second person reviews every production change, admin actions are logged, and logs go somewhere the admin can't delete (see IAM-09).

Where answers usually go wrong

• A founder who can do everything. If one person holds the cloud root account, approves their own pull requests and administers the identity provider, the honest answer is Partially, with a plan.
• Review that can be skipped. "Changes are reviewed" is weaker than "changes cannot be merged without a second approval." If your tooling allows bypass, say what happens when someone uses it, as Tailscale does.