# CAIQ IAM-10: Management of privileged access roles By The Citesheet team · Published October 20, 2026 Short answer IAM-10 asks two things: are privileged (admin) roles and rights granted only for a limited period, and do you stop segregated privileges from accumulating in one person? Just-in-time admin access, expiring elevated sessions and regular admin reviews prove it. Many small companies have standing admin access instead, and the honest answer is then No or Partially with a plan. ## 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](https://citesheet.com/caiq/iam-08-user-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](https://tailscale.com/security-policies/change-management), 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](https://posthog.com/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](https://cloudsecurityalliance.org/star/registry/services/gitlab). ## 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. ## 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. [Tailscale security policies: Change management policy (CC0)](https://tailscale.com/security-policies/change-management) (accessed October 20, 2026) 4. [PostHog Handbook: Engineering security (MIT)](https://posthog.com/handbook/engineering/security) (accessed October 20, 2026) ## Related * [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/) * [CAIQ IAM-08: User access reviewCAIQ v4 control IAM-08 asks whether you regularly re-check who has access. What proves it, why the frequency matters, quoted examples, and sample answers.](https://citesheet.com/caiq/iam-08-user-access-review/) * [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.