# CAIQ IAM-04: Separation of duties By The Citesheet team · Published October 20, 2026 Short answer IAM-04 asks whether you apply the separation of duties principle when you grant access: no single person should be able to carry out and approve a sensitive action alone. In a software company the usual proof is a change management rule that every change is reviewed and approved by someone other than its author. Very small teams can answer honestly with a two-person rule plus logging, or say Partially. ## 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](https://csrc.nist.gov/glossary/term/separation%5Fof%5Fduty) 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](https://tailscale.com/security-policies/change-management), 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](https://tailscale.com/security-policies/change-management), 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](https://handbook.gitlab.com/handbook/security/security-and-technology-policies/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](https://cloudsecurityalliance.org/star/registry/services/gitlab). ## 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](https://citesheet.com/caiq/iam-09-segregation-of-privileged-access-roles/)). ## 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. ## Sources 1. [Cloud Security Alliance: Cloud Controls Matrix (CCM)](https://cloudsecurityalliance.org/ccm/) (accessed October 20, 2026) 2. [CSA STAR Registry: GitLab.com (CAIQ v4.0.3 submission, 2025-03-25)](https://cloudsecurityalliance.org/star/registry/services/gitlab) (accessed October 20, 2026) 3. [NIST CSRC Glossary: separation of duty](https://csrc.nist.gov/glossary/term/separation%5Fof%5Fduty) (accessed October 20, 2026) 4. [Tailscale security policies: Change management policy (CC0)](https://tailscale.com/security-policies/change-management) (accessed October 20, 2026) 5. [GitLab Handbook: Change Management Policy (CC BY-SA 4.0)](https://handbook.gitlab.com/handbook/security/security-and-technology-policies/change-management-policy/) (accessed October 20, 2026) ## Related * [CAIQ IAM-05: Least privilegeCAIQ v4 control IAM-05 asks whether people and systems get only the access they need. What proves it, quoted examples from Tailscale, GitLab and PostHog, and gaps.](https://citesheet.com/caiq/iam-05-least-privilege/) * [CAIQ IAM-09: Segregation of privileged access rolesCAIQ v4 control IAM-09 asks whether admin access to data, encryption keys and logs is held by separate roles. What proves it, what public policies show, and honest answers.](https://citesheet.com/caiq/iam-09-segregation-of-privileged-access-roles/) * [How to answer a security questionnaire without SOC 2No SOC 2 yet? Answer the questionnaire honestly: say No where it's true, show what you do have, and give a dated plan. Sample wording included.](https://citesheet.com/guides/security-questionnaire-without-soc-2/) ## Send one questionnaire. See the proof. First questionnaire free. Same-day turnaround. Tell us where to send it back and we'll reply with next steps. Send your first questionnaire free Takes about 15 seconds. Or email [hello@citesheet.com](mailto:hello@citesheet.com). Need an NDA first? Ask, and we'll sign before you send anything.