CAIQ IAM-10: Management of privileged access roles

What the control asks

• IAM-10.1: Is an access process defined and implemented so that privileged access roles and rights are granted for a limited period?
• IAM-10.2: Are procedures implemented to prevent the "culmination" of segregated privileged access? In plain English: can one person end up holding several admin roles that were meant to be kept apart?

This is the "just-in-time" idea: nobody holds admin rights all the time. You request elevated access for a task, it is approved, and it expires.

Which policy usually proves it

An Access Control Policy section on privileged access, or a Privileged Access Standard. Technical evidence matters a lot here: an access broker or cloud role that grants time-boxed sessions, with an approval step and a log. For IAM-10.2, the proof is usually the access review checking admin roles specifically.

Quoted evidence from public policies

This is one of the controls where public policies say least. The closest examples we found are about limiting standing privileges and auditing exceptions, not about time limits.

Tailscale audits emergency changes made outside the normal approval path:

Changes pushed without prior approval are tagged and audited after the fact, within 2 business days.

Tailscale, Change management policy, CC0.

PostHog avoids long-lived personal tokens with broad rights:

Fine-grained PATs require approval and are generally not approved, because they are tied to an individual user and break when that user leaves PostHog.

PostHog Handbook, Engineering security, MIT.

Neither of these proves IAM-10.1. What we didn't find: in the public GitLab, Tailscale and PostHog policies we use for testing, there is no sentence stating that admin rights expire after a set time. From those documents alone, the honest result for IAM-10 is "No proof found." GitLab answered Yes, so its evidence is presumably internal.

How GitLab answered

Yes to both IAM-10.1 and IAM-10.2, 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-10.1: Yes. Production admin access is not standing. Engineers request elevation through [tool]; a second person approves; sessions expire after [N hours]; every elevation is logged. See Privileged Access Standard, section 2.

IAM-10.2: Yes. Admin role assignments are reviewed [quarterly] as part of the access review, and conflicting admin roles (for example key administration and log administration) are not assigned to the same person.

And the honest version for a team with standing admin access:

IAM-10.1: No. Two named engineers hold standing production admin access, protected by hardware security keys; all admin actions are logged to [service]. We plan to move to time-limited elevation by [date].

When N/A is honest

Only if your service has no privileged roles at all, which is unusual. A fully managed setup where you have no infrastructure admin access still has admin roles in your cloud console and identity provider.

Where answers usually go wrong

• Writing Yes because SSO exists. Single sign-on controls who can sign in. It doesn't limit how long admin rights last.
• Forgetting break-glass accounts. Emergency admin accounts are standing privilege by design. Say how they are stored, who can use them and how use is reviewed.