---
name: access-review
description: Produces a user / role access review pack with scope, sampling plan, evidence list, reviewer instructions, and sign-off form for periodic certification.
version: 1.0.0
author: VantagePoint Networks
audience: IT Managers, Identity & Access Managers, Compliance Managers, Application Owners
output_format: Formatted Markdown access review pack with scope, sample sets, per-reviewer worksheets, exception register, and audit evidence bundle.
license: MIT
---

# Access Review

Periodic access certification done properly: scope defined, sample selected, reviewers briefed, exceptions tracked, and audit evidence produced automatically.

## How to use this skill

1. Download this `SKILL.md` file.
2. Place it in `~/.claude/commands/` (macOS/Linux) or `%USERPROFILE%\.claude\commands\` (Windows).
3. Run `/access-review` in Claude Code. Describe what you're reviewing (users of system X, admins of platform Y, quarterly all-privileged). Answer scope questions. Receive the full pack.

## When to use this

- Quarterly / half-yearly access reviews are due (ISO 27001 A.9, SOC 2 CC6, PCI-DSS 8.1).
- You've inherited an access review programme that's been rubber-stamped and you want to reset it to something defensible.
- You're about to onboard a new sensitive system and want the review baked in from day one.
- A recent incident (insider, phishing, mis-configuration) has exposed the cost of stale access and you're tightening.
- You're preparing evidence for an audit and need a repeatable, documentable pattern.

## What you'll get

- **Review scope** - systems, user groups, privilege tiers in and out of scope.
- **Sampling plan** - when 100% review is too expensive, a defensible sampling methodology.
- **Reviewer worksheet** - per reviewer, a list of their users/roles with decision columns (Keep / Change / Remove / Investigate).
- **Evidence list** - exactly what data to pull from each source system and how (tool, filter, date range).
- **Exception register** - emergency / break-glass accounts, service accounts, shared accounts - handled separately.
- **Instructions for reviewers** - what "Keep" means, when to mark "Investigate", escalation path.
- **Sign-off form** - reviewer confirms completion, any exceptions recorded, attested date.
- **Metrics summary** - coverage, changes, attestation rate, overdue.
- **Audit evidence bundle structure** - naming, retention, storage guidance.

## Clarifying questions I will ask you

1. **What's the trigger?** (Scheduled quarterly / annual / ad-hoc / post-incident)
2. **What systems are in scope?** (Name them or describe tier - e.g. "all production systems with PII")
3. **Who are the reviewers?** (Line managers / system owners / data owners / a mix)
4. **What review cadence does the control framework require?** (Quarterly for privileged, annual for standard, etc.)
5. **Which privilege tiers?** (Regular user / elevated / admin / break-glass)
6. **How many users / accounts total?** (Drives sampling decision)
7. **What's the identity system you'll pull evidence from?** (Entra ID, Okta, Active Directory, local system, vendor UI)
8. **Any joiners / movers / leavers in the period?** (Always highest-risk to review)
9. **Do you need to capture segregation of duties checks?** (e.g. user can't both create and approve payments)
10. **Regulatory framework alignment?** (ISO 27001, SOC 2, PCI-DSS, HIPAA, SOX)
11. **What's the deadline for reviewer sign-off?**
12. **Who approves the review overall?** (Head of Security, Head of IT, CISO)

## Output template

```markdown
# Access Review: <system or scope> - <period>

**Review ID:** AR-<YYYY-QN>
**Period covered:** YYYY-MM-DD to YYYY-MM-DD
**Triggered by:** Quarterly schedule / Audit / Incident <ID> / New system onboarding
**Review owner:** <name>
**Approver (final sign-off):** <name - typically CISO / Head of Security>
**Due date (reviewer sign-off):** YYYY-MM-DD
**Due date (approver sign-off):** YYYY-MM-DD
**Framework alignment:** <ISO 27001 A.9.2.5 / SOC 2 CC6.3 / etc.>

## 1. Scope

### In scope
| System | Privilege tiers reviewed | User / account count | Owner |
|---|---|---|---|
| <System A> | Admin, elevated | <count> | <name> |
| <System B> | All user roles | <count> | <name> |
| <System C> | Privileged only | <count> | <name> |

### Out of scope (and why)
- <System> - next scheduled for <period>, not this cycle
- <System> - reviewed separately under <other control>

### Joiners / Movers / Leavers in period
| Category | Count | Reviewed this cycle? |
|---|---|---|
| Joiners | N | Yes - new account review |
| Movers (role changes) | N | Yes - mandatory review |
| Leavers | N | Yes - confirm full deprovisioning |

## 2. Sampling Plan (if not 100%)
### When 100% review is appropriate
- Privileged / admin accounts
- Any system in PCI / HIPAA / SOX scope
- All joiner / mover / leaver cases

### Sampling approach for large populations
- **Population:** <total count>
- **Sample size:** <count> - calculated to <confidence level> confidence, <margin>
- **Sampling method:** Random / Stratified by <role> / Risk-based (privileged first)
- **Re-sampling rule:** If exception rate in sample > <threshold>, expand to 100%

## 3. Reviewer Assignment
Each account maps to one reviewer. Reviewer is the named manager or system owner with authority to approve continued access.

| Reviewer | Role | Accounts assigned | Due date |
|---|---|---|---|
| <name> | <line manager / system owner> | <count> | YYYY-MM-DD |

## 4. Reviewer Worksheet (per reviewer)

**To:** <reviewer name>
**Your accounts for review:** <count>

For each account, choose one decision:
- **Keep** - access remains appropriate and necessary
- **Change** - access remains, but scope needs adjusting (note new scope)
- **Remove** - access no longer required; remove
- **Investigate** - something doesn't look right; escalate before decision

| User | Role / Group | System | Last logon | Reason for access | Decision | Notes |
|---|---|---|---|---|---|---|
| <username> | <role> | <system> | YYYY-MM-DD | <stated reason at grant> | Keep / Change / Remove / Investigate | <> |

### Reviewer instructions
- **Keep** = "I have confirmed this person still needs this access for their current role." Not "probably fine."
- **Last logon > 90 days** defaults to Remove unless you have a specific reason.
- **Contractor accounts** require active contract date - if expired, Remove.
- **Service accounts / shared accounts** are handled in the exception register (section 6) - do not tick Keep on your worksheet, escalate to system owner.
- **Investigate** goes to <IAM team / Security> with a note explaining why.

**Sign-off:**
> I confirm I have reviewed all accounts on this worksheet and made a deliberate decision for each. I understand the security implications of my attestation.
>
> Reviewer: <name>
> Date: YYYY-MM-DD
> Signature / system attestation: <>

## 5. Evidence List
| Evidence item | Source system | How to pull | Retention |
|---|---|---|---|
| User list with roles and last-logon | <Entra ID / Okta / AD> | <report name / tool / filter> | 7 years |
| Privileged user list | <PAM tool / system admin console> | <report name> | 7 years |
| Joiner records | HRIS | <report name, date range> | 7 years |
| Leaver records | HRIS | <report name, date range> | 7 years |
| Mover records | HRIS | <report name, date range> | 7 years |
| Group membership snapshots | <identity system> | <method> | 7 years |
| Change tickets for access changes | <service management tool> | <query> | 7 years |

## 6. Exception Register
Accounts that cannot be reviewed by a normal line manager or do not fit the standard process.

| Account | Type | Purpose | Owner | Controls | Review method | Next review |
|---|---|---|---|---|---|---|
| <svc-*> | Service | <system integration> | <named person> | <secret rotation every N days, no interactive login> | System owner attestation | <date> |
| <break-glass-01> | Emergency | <last-resort admin> | <named person> | <credential in vault, use triggers alert> | SIEM-logged use review | <date> |
| <shared-nvr> | Shared | <CCTV viewing> | <facilities lead> | <2FA at access point, usage logged> | Camera location review | <date> |

## 7. Segregation of Duties (SoD) Checks
For systems where SoD matters:
- <check 1 - e.g. "no user has both 'Create invoice' and 'Approve payment' in the finance system">
- <check 2 - e.g. "no user has both 'Production deploy' and 'Production database access'">

**Findings:** <list, with owner and remediation>

## 8. Findings & Remediation
| # | Finding | Severity | Owner | Remediation | Due | Status |
|---|---|---|---|---|---|---|
| F1 | <e.g. 12 dormant accounts > 180 days> | High | IAM | Disable, then delete after 90d | YYYY-MM-DD | Open |
| F2 | <e.g. 3 contractor accounts past contract end> | Critical | IAM + HR | Disable today | YYYY-MM-DD | Open |

## 9. Metrics Summary
| Metric | This cycle | Target |
|---|---|---|
| Accounts in scope | N | - |
| Accounts reviewed | N | 100% |
| Reviewer attestation rate | % | 100% |
| Accounts flagged Remove | N | - |
| Accounts flagged Investigate | N | - |
| Accounts with last logon > 90 days | N | Trend down |
| Privileged account count | N | Monitor |
| SoD violations found | N | 0 |

## 10. Overall Attestation (Approver)
> I have reviewed the Access Review pack for <period>, including reviewer attestations, exception register, and findings. I confirm the review was conducted in accordance with <policy reference>. Remediation actions for open findings have been assigned with named owners and due dates.
>
> Approver: <name, role>
> Date: YYYY-MM-DD

## 11. Audit Evidence Bundle Structure
For storage / retrieval when the auditor asks:

```
AR-YYYY-QN/
  01-scope.md (this document)
  02-worksheets/
    <reviewer-1>.csv
    <reviewer-2>.csv
    ...
  03-evidence/
    entra-user-export-YYYY-MM-DD.csv
    joiners-leavers-YYYY-MM-DD.csv
    privileged-snapshot-YYYY-MM-DD.csv
  04-findings.md
  05-attestation-approver.pdf
```

**Retention:** 7 years (or per policy).
**Storage location:** <secure repository>
**Access:** <restricted to Audit / Compliance / Security lead>
```

## Example invocation

**User:** "/access-review - quarterly privileged-access review across our M365 admin roles, Okta admin roles, and AWS Organization accounts. About 18 accounts in total. Need to be done by end of month."

**What the skill will do:**
1. Confirm review = 100% given the small privileged population (sampling isn't appropriate here).
2. Ask who the reviewer is for each system (probably different: M365 = Head of IT; Okta = Identity lead; AWS = Cloud Platform lead).
3. Produce a worksheet per reviewer with the account list template, with instructions tailored to privileged-access concerns (last-logon > 30 days defaults to Remove for admin roles, not 90).
4. Pre-populate the SoD section with common M365/AWS SoD rules to check.
5. Include a break-glass section treating any emergency admin accounts separately with their own attestation flow.

## Notes for the requester

- **100% for privileged, sample for standard.** The cost/benefit flips for admin accounts - one missed admin account is usually worse than 100 missed regular accounts.
- **Reviewer must have authority.** "Keep" from a reviewer who can't actually assess appropriateness is a tick-box, not a control. Pick reviewers who know the role.
- **Last-logon is a proxy, not truth.** Some service accounts never log in interactively. Some users access via API. Check evidence, not just "days since logon".
- **Shared and service accounts need a separate process.** Don't let reviewers tick them off on a worksheet - they need a system owner attesting to the control posture.
- **Findings with no due date aren't findings.** Every finding = owner + due + status. A list without these is just observations.
- **"Good" looks like:** an auditor reviews the pack and cannot find a single account that wasn't touched. Reviewers can explain their decisions if asked. The exception register shows thought, not convenience.