# CAIQ IAM-06: User access provisioning By The Citesheet team · Published October 20, 2026 Short answer IAM-06 asks whether you have a defined process for giving people access that authorizes, records and communicates each change. The usual proof is an access request rule in your access control policy: every new or changed access goes through a request, someone other than the requester approves it before it is granted, and the request is kept as the record. ## What the control asks **IAM-06.1:** Is a user access provisioning process defined and implemented which authorizes, records and communicates data and asset access changes? Three things have to be true for a full Yes: 1. **Authorizes:** someone with the authority to do so approves the access _before_ it is granted. 2. **Records:** there is a lasting record of the request and approval. 3. **Communicates:** the people who need to know (the requester, the system owner, sometimes security) are told. ## Which policy usually proves it The _Access Control Policy_, in its access request section. The tool that runs the process (a ticket queue, an access request form, your identity provider's approval workflow) is supporting evidence, and some buyers will ask to see a sample ticket. ## Quoted evidence from public policies GitLab's policy covers authorization and records in three lines: > Access requests are opened for all new or changing access. > > 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 names who approves: > 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 line says in so many words that the change is _communicated_. A ticket that the requester and approver both see usually covers it in practice. If a buyer reads the question strictly, one sentence in your policy ("the requester and system owner are notified when access is granted") closes the gap. ## How GitLab answered **Yes.** Its explanation in the CAIQ v4.0.3 submission on the [CSA STAR Registry](https://cloudsecurityalliance.org/star/registry/services/gitlab) says an access request must be filled out and approved by management before access is granted, mentions quarterly access reviews, and links the Access Management Policy. ## A good answer, if your policy supports it > **IAM-06.1: Yes.** All new or changed access is requested through \[tool\]. The requester's manager or the security owner approves before access is granted; requesters cannot approve their own requests. The ticket is the record and notifies the requester and system owner. See Access Control Policy, "Access requests". ## When N/A is honest Not for your own staff. If the question is read as covering your customers' users, provisioning inside your product is the customer's job; say so in the ownership column and answer for your own staff. ## Where answers usually go wrong * **Slack approvals.** A message saying "sure, added you" is an approval, but rarely a record anyone can find later. If that is your process, write it down and keep the thread, or move to tickets. * **Joiners covered, changes missed.** The question says "access changes," not only new access. Promotions and team moves count; see [IAM-07](https://citesheet.com/caiq/iam-07-user-access-changes-and-revocation/). ## 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-03: Identity inventoryCAIQ v4 control IAM-03 asks whether you keep and review a record of who has which access. What proves it, quoted examples, and where policies fall short.](https://citesheet.com/caiq/iam-03-identity-inventory/) * [CAIQ IAM-07: User access changes and revocationCAIQ v4 control IAM-07 asks whether leavers and movers lose access in a timely manner. Why "timely" needs a number, quoted examples, and sample answers.](https://citesheet.com/caiq/iam-07-user-access-changes-and-revocation/) * [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/) ## 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.