# User access review runbook

A working checklist for running a quarterly user access review that produces
evidence an auditor will accept. Adapt the systems list to your environment.

Framework references: SOC 2 CC6.2 / CC6.3 · ISO 27001 A.5.15 / A.5.18 ·
HIPAA §164.308(a)(4)

---

## Before the review

- [ ] Confirm the in-scope system list is current. Add anything introduced since
      the last review.
- [ ] Confirm the reviewer for each system. It should be someone who can
      actually judge whether access is appropriate, usually the system owner,
      not the security team.
- [ ] Note the review date. Everything below is a claim about this date.

**In-scope test.** Include a system if compromise of an account in it would
directly expose customer data, production infrastructure, or the ability to
change either.

Typical list:

- [ ] Identity provider
- [ ] Cloud provider consoles / production infrastructure
- [ ] Production databases and data warehouses
- [ ] Source control and anything with deploy rights
- [ ] Customer support tooling that can read customer data

---

## Step 1. Capture the population

For each in-scope system:

- [ ] Export the complete account list **from the system itself**, not from a
      maintained spreadsheet.
- [ ] Include, per account: identifier, owner, role or permission set, status,
      and last sign-in where available.
- [ ] Record the export timestamp and who ran it.
- [ ] Store the raw export unedited. This is the artefact.

> The population export is the most commonly skipped step and the only one that
> cannot be recreated afterwards. Pulling the list in October tells you nothing
> about who had access in June.

---

## Step 2. Review

For each account, the reviewer records one of:

- [ ] **Retain**: access is appropriate for the current role
- [ ] **Modify**: access should be reduced; state the target permission
- [ ] **Revoke**: access is no longer required

Also check, per system:

- [ ] Service accounts: owned, justified, and credentials rotated
- [ ] Accounts belonging to people who have left
- [ ] Accounts belonging to people who changed role since the last review
- [ ] Administrative access: is the list as short as it should be?
- [ ] MFA enforced where the system supports it

Record the reviewer's name and the date they completed the review.

---

## Step 3. Remediate

- [ ] Raise a ticket for every Modify and Revoke decision.
- [ ] Link each ticket to the review and to the specific account.
- [ ] Set a completion target. Anything privileged should be same-day.

---

## Step 4. Close

- [ ] Confirm each change was made, **from the system**, not from the ticket
      status.
- [ ] Attach the confirmation to the ticket.
- [ ] Record the review as complete, with its date.

---

## The four artefacts

A review that survives audit sampling produces all four of these, dated:

| # | Artefact | Common failure |
|---|----------|----------------|
| 1 | Population export | Never captured; cannot be recreated |
| 2 | Reviewer decisions | No named reviewer or no date |
| 3 | Remediation tickets | Not linked to the review |
| 4 | Closure confirmation | Taken from the ticket rather than the system |

---

## Track over time

Record findings per review. A falling trend is the clearest evidence that your
joiner-mover-leaver process improved, and it is a better story for an auditor
than a single clean review.

If a review consistently finds nothing, verify the population is complete before
concluding the process is working.