<!-- Markdown copy of https://citesheet.com/caiq/iam-07-user-access-changes-and-revocation/ -->

# CAIQ IAM-07: User access changes and revocation

By The Citesheet team · Published October 20, 2026

Short answer

IAM-07 asks whether you remove or change access in a timely manner when people leave, change roles, or when a system identity changes. Your access control or offboarding policy proves it. The word to watch is "timely": a policy that says access is removed on termination is good, and one that gives a deadline, such as within one business day, is better.

## What the control asks

**IAM-07.1:** Is there a process to de-provision or modify access, in a timely manner, for movers and leavers or when a system identity changes?

"Movers" are people who change role or team. "Leavers" are people who leave the company. "System identity changes" covers things like rotating a service account when the person who set it up leaves.

## Which policy usually proves it

The _Access Control Policy_, in a section on termination and transfers, or an _Offboarding procedure_. HR checklists count as supporting evidence if they include an access removal step.

## Quoted evidence from public policies

GitLab's policy has one line for leavers and one for movers:

> Access is deprovisioned upon cessation of employment.
> 
> Access is deprovisioned or provisioned upon job transfer, as appropriate for the transfer.
> 
> _GitLab Handbook, [Access Management Policy](https://handbook.gitlab.com/handbook/security/security-and-technology-policies/access-management-policy/), CC BY-SA 4.0._

Tailscale adds a deadline, which is what makes "timely" provable:

> Terminated employees must have their accounts disabled within 1 business day of transfer or termination.
> 
> _Tailscale, [Access control policy](https://tailscale.com/security-policies/access-control), CC0._

and backs it up with reviews for the cases that slip through:

> Transferred employee access is reviewed and adjusted as found necessary. Since there could be delays in reporting changes in user responsibilities, periodic user access reviews are conducted by the Security Review Team.
> 
> _Tailscale, [Access control policy](https://tailscale.com/security-policies/access-control), CC0._

## How GitLab answered

**Yes**, in its CAIQ v4.0.3 submission on the [CSA STAR Registry](https://cloudsecurityalliance.org/star/registry/services/gitlab). GitLab's public policy does not give a deadline; it refers to an internal Access Management Standard for details.

## A good answer, if your policy supports it

> **IAM-07.1: Yes.** Leavers' accounts are disabled in \[identity provider\] within \[1 business day\] of their last day, which removes access to all SSO-connected systems; non-SSO systems are removed from the offboarding checklist. When someone changes role, their access is adjusted through an access request. Service account credentials owned by a leaver are rotated. See Access Control Policy, "Termination and transfers".

## When N/A is honest

Never for a company with staff or contractors. A solo founder with no one else on any system can explain that, but should still describe what would happen when the first person joins or leaves.

## Where answers usually go wrong

* **"Timely" without a number.** Reviewers may ask "how quickly?" If your policy has no deadline, treat "timely" as unproven and decide what your real number is before you write Yes.
* **Non-SSO systems.** Disabling the identity provider account doesn't remove local accounts, shared passwords or API keys the person created. Name how those are handled.
* **Movers.** Many policies cover leavers only. Role changes are where access quietly piles up.

## 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.
