CAIQ IAM-09: Segregation of privileged access roles
By The Citesheet team · Published
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 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, 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, 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.
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.