<!-- Markdown copy of https://citesheet.com/caiq/iam-09-segregation-of-privileged-access-roles/ -->

# CAIQ IAM-09: Segregation of privileged access roles

By The Citesheet team · Published October 20, 2026

Short answer

IAM-09 asks whether privileged roles are split so that administrative access to data, to encryption and key management, and to logging are distinct. The idea is that no single admin can read data, change the keys and erase the evidence. Public policies rarely prove the full split, so most small companies should answer Partially and describe the pieces they do have, such as logs that admins can't modify.

## What the control asks

**IAM-09.1:** Are processes, procedures and technical measures for the segregation of privileged access roles defined, implemented and evaluated, so that administrative data access, encryption and key management capabilities, and logging capabilities are distinct and separate?

This is [separation of duties](https://citesheet.com/caiq/iam-04-separation-of-duties/) applied to administrators. The worry is one admin account that can read customer data, change or export the encryption keys that protect it, and then edit the logs that would show it happened.

## Which policy usually proves it

It is usually split across documents:

* **Logging:** an audit logging policy that says logs can't be changed or deleted, and who can access them.
* **Keys:** an encryption or key management standard that names who administers keys (often your cloud provider's key service with its own permissions).
* **Data access:** the access control policy's rules for production and customer data.

Few companies have one sentence that says "these three roles are held separately," and auditors know that. They look for the pieces.

## Quoted evidence from public policies

GitLab's audit logging policy covers the logging piece:

> Logs must not be modified and or deleted.
> 
> Access to audit log data must be limited based on the principle of least privilege.
> 
> _GitLab Handbook, [GitLab Audit Logging Policy](https://handbook.gitlab.com/handbook/security/security-and-technology-policies/audit-logging-policy/), CC BY-SA 4.0._

Tailscale separates admin and everyday accounts, which is related but not the same thing:

> Personnel who have administrative system access must use other less powerful accounts for performing non-administrative tasks.
> 
> _Tailscale, [Access control policy](https://tailscale.com/security-policies/access-control), CC0._

**What we didn't find.** In the public policies of GitLab, Tailscale and PostHog that we use for testing, we found no sentence stating that key management administration is held by different people from data administration. GitLab still answered Yes (see below), so the evidence presumably lives in internal documents. From public documents alone, the honest result for the key management part is "No proof found."

## How GitLab answered

**Yes**, with no linked evidence, in its CAIQ v4.0.3 submission on the [CSA STAR Registry](https://cloudsecurityalliance.org/star/registry/services/gitlab).

## A good answer, if your documents support it

> **IAM-09.1: Partially.** Audit logs are written to \[log service\] where production administrators have read-only access and cannot delete or modify entries. Encryption keys are managed in \[cloud KMS\]; key administration permissions are limited to \[role\] and are separate from database administration roles. \[Name any part that is not yet separate, and the plan.\] See Audit Logging Policy and Encryption Standard.

Change "Partially" to "Yes" only if every part, including keys, is separated and written down.

## When N/A is honest

Possibly for one part: if you hold no encryption keys of your own (for example, you rely entirely on a managed service's default encryption with no customer-managed keys), the key management part may not apply. Say exactly that, and still answer for logging and data access. Don't mark the whole question N/A.

## Where answers usually go wrong

* **"We're too small" as N/A.** A small team is a reason for Partially with compensating controls, not N/A.
* **Root accounts.** A cloud root or owner account can usually do all three. Say who holds it, how it is protected (hardware key, no daily use) and that its use is logged.

## 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. [GitLab Handbook: GitLab Audit Logging Policy (CC BY-SA 4.0)](https://handbook.gitlab.com/handbook/security/security-and-technology-policies/audit-logging-policy/) (accessed October 20, 2026)
4. [Tailscale security policies: Access control policy (CC0)](https://tailscale.com/security-policies/access-control) (accessed October 20, 2026)

## Related

* [CAIQ IAM-04: Separation of dutiesCAIQ v4 control IAM-04 asks whether no one person can both make and approve a risky change. What proves it in a small company, quoted examples, and honest answers.](https://citesheet.com/caiq/iam-04-separation-of-duties/)
* [CAIQ IAM-10: Management of privileged access rolesCAIQ v4 control IAM-10 asks whether admin rights are granted for a limited time and can't quietly pile up. What proves it, what public policies show, and honest answers.](https://citesheet.com/caiq/iam-10-management-of-privileged-access-roles/)
* [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/)

## 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.
