# CAIQ IAM-03: Identity inventory By The Citesheet team · Published October 20, 2026 Short answer IAM-03 asks whether you manage, store and review information about system identities and their level of access: in practice, a list of who has which account and role, kept up to date and checked. A policy sentence that access requests and reviews are documented is the usual written proof. The strongest answer also names where the record lives, such as your identity provider or ticketing system. ## What the control asks **IAM-03.1:** Is system identity information, and the level of access each identity has, managed, stored and reviewed? "System identities" means every account that can reach your systems: staff, contractors, service accounts and API keys. The question has three verbs, and a careful reviewer reads all three: * **managed:** accounts are created and changed through a process, not ad hoc * **stored:** there is a record of who has what * **reviewed:** someone checks that record (the review itself is [IAM-08](https://citesheet.com/caiq/iam-08-user-access-review/)) ## Which policy usually proves it The _Access Control Policy_, in the section on access requests and records. Many small companies have the practice (their identity provider _is_ the inventory) but never wrote it down. One sentence fixes that: "Our identity provider is the system of record for all staff accounts and their group memberships." ## Quoted evidence from public policies GitLab covers "managed" and "stored" in two short lines: > Access requests are approved prior to making access changes. > > Access requests and reviews are documented. > > _GitLab Handbook, [Access Management Policy](https://handbook.gitlab.com/handbook/security/security-and-technology-policies/access-management-policy/), CC BY-SA 4.0._ Tailscale describes where the record comes from (a ticket for each request): > Personnel that require access to systems must submit a ticket for review and approval by a manager or a member of the Security Team to provision access. > > _Tailscale, [Access control policy](https://tailscale.com/security-policies/access-control), CC0._ Neither public policy names the inventory system itself. That detail usually sits in an internal standard; GitLab's policy links to an internal Access Management Standard for it. ## How GitLab answered **Yes**, citing its Access Management Policy, 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-03.1: Yes.** \[Identity provider\] is the system of record for staff accounts and group-based access. Every access change goes through an approved request in \[ticketing tool\], which records who asked, who approved and what changed. Access is reviewed \[quarterly\]. See Access Control Policy, sections 3 and 5. Only include the review frequency if a document states it. ## When N/A is honest Not for a SaaS provider. Every service has identities. If customers manage their own users inside your product, that is their side of the shared responsibility model (the CAIQ's "CSC-owned" column), but your own staff and service accounts still count. ## Where answers usually go wrong * **Forgetting non-human identities.** API keys, CI tokens and service accounts are identities too. If your inventory covers people only, say so, or mark the answer _Partially_. * **Over-reading the evidence.** "Access requests are documented" proves a record exists. It does not prove a complete inventory of every identity. Whether that is enough is a judgment call. ## How Citesheet handled this one This is a real judgment call, and our own test shows it. In our [benchmark](https://citesheet.com/benchmark/), Citesheet answered IAM-03.1 "Yes" from GitLab's policy where our label said "Partial". We then set a rule: standard policy wording counts as proof of that wording, while specific conditions (frequencies, "all", named systems) still need their own proof. Under that rule the label became "Yes". We show both, because a buyer's reviewer could reasonably read it either way. ## 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: Access Management Policy (CC BY-SA 4.0)](https://handbook.gitlab.com/handbook/security/security-and-technology-policies/access-management-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-06: User access provisioningCAIQ v4 control IAM-06 asks whether access is granted through a process that approves, records and communicates each change. Quoted examples and sample answers.](https://citesheet.com/caiq/iam-06-user-access-provisioning/) * [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/) * [We tested Citesheet on GitLab's public CAIQHow Citesheet did on a 261-question CAIQ filled only from GitLab's public policies: what matched, what it refused, what it got wrong, and the limits.](https://citesheet.com/benchmark/) ## 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.