# It Access Review > Runs user access reviews and joiner-mover-leaver processing: reconciles entitlements against an authoritative people source, routes each item to the right approver, and closes the loop on revocations with evidence. Use when a periodic access recertification is due, when someone joins, changes role, or leaves, when an auditor asks who has access to a system, or when orphaned and privileged accounts need sweeping. Trigger on 'access review', 'user access recertification', 'joiner mover leaver', 'offboarding checklist', 'who has admin on X', 'orphaned accounts', 'entitlement review'. Not for granting a single new permission on request — that is it-service-desk-triage; not for deciding what a role should be entitled to in the first place, which is the role design that precedes this. - Skill: `alihusains/it-access-review` (Agent Skill) - Install (CLI): `npx skillmds@latest add alihusains/it-access-review` - Raw SKILL.md: https://api.skillmd.com/api/skills/alihusains/it-access-review/raw - Safety review: pending - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: Coding & Dev Tools - Author: alihusains (https://skillmd.com/u/alihusains) - Updated: 2026-09-17 - Page: https://skillmd.com/skills/alihusains/it-access-review --- # Access review and joiner-mover-leaver ## Purpose Access accumulates. People change roles and keep the old entitlements, contractors finish and their accounts persist, service accounts outlive the system they were created for, and the review that is supposed to catch this becomes an exercise in managers approving lists they do not understand. This skill makes the review produce actual revocations by fixing the authoritative source, routing each item to someone who can genuinely judge it, and tracking revocations to evidence rather than to an approval click. ## Prerequisites - **Inputs:** an authoritative people list from the HR system (identity, status, manager, department, employment type, start/end dates); an entitlement export per in-scope system (account identifier, linked person, entitlement or group, last login, privileged yes/no); the previous review's outcomes. - **Access:** read on the identity provider and each in-scope system; ability to raise revocation tickets; the approver list. If the HR export and the entitlement exports cannot be joined on a common identifier, stop and fix the identifier problem first. A review run on name-matching produces false pairs and misses exactly the accounts that matter — the ones with no owner. ## Procedure 1. **Set scope by system criticality, not by convenience.** Systems handling money, personal data, production infrastructure, or the identity provider itself are in every cycle. Everything else can be annual. Record what was excluded and why — an unstated scope gap is the finding an auditor will raise. 2. **Reconcile accounts to people before showing anything to an approver.** Every account lands in exactly one bucket, and the buckets have different handling: | Bucket | Definition | Handling | | --- | --- | --- | | Matched active | Account maps to a current employee/contractor | Goes to the manager for recertification | | Leaver | Account maps to a person whose end date has passed | Revoke immediately; do not send for approval | | Mover | Person's department or role changed since last review | Revoke prior-role entitlements by default; manager must re-request | | Orphan | No matching person | Escalate to system owner; disable pending identification | | Service/non-human | Declared non-human account | Route to the named technical owner, not a manager | | Unowned service account | Non-human with no named owner | Treat as the highest-priority finding; disable-after-notice | Leavers and orphans are actioned, not approved. Sending them to a manager to confirm is how a review takes six weeks and revokes nothing. 3. **Apply the mover rule strictly: additive access is the default failure.** When someone changes role, the correct action is to remove the old entitlements and have the new manager request what is needed. Asking "should they keep this?" reliably yields yes. Role change is the single largest source of accumulated over-entitlement. 4. **Route each item to an approver who can actually judge it.** | Item | Approver | | --- | --- | | Standard business entitlement | The person's current line manager | | Privileged/admin entitlement | System owner AND the manager, both required | | Access to personal or financial data | System owner plus the data owner | | Non-human account | Named technical owner | | Approver's own access | That approver's manager — never self-approval | Self-approval anywhere in the chain invalidates the review for the whole system, not just that line. 5. **Give approvers decision context, not a list.** Each line shows: entitlement, what it permits in plain words, when it was granted, when it was last used, and whether it is privileged. An entitlement unused for 90+ days should be pre-flagged as revoke-by-default so the approver has to argue to keep it. The plain-words column is what separates a real review from a rubber stamp — most managers cannot map a group name to a capability. 6. **Track revocations to evidence.** An approver marking "revoke" is the start, not the end. Each revocation carries a ticket, an executor, and a verification: a re-export from the system showing the entitlement gone. Close the review only when re-export confirms it. Reviews that count approvals as completion routinely leave a third of revocations unexecuted. 7. **Handle non-responders with a default, decided before the cycle starts.** Publish the deadline and the consequence — typically: non-privileged access escalates to the approver's manager, privileged access is revoked. A review with no non-response default stalls indefinitely on the busiest approvers. 8. **Produce the evidence pack.** Scope and exclusions with rationale, population counts per bucket, approver coverage, revocations requested versus verified, exceptions granted with owner and expiry, and unresolved items with dates. Retain the raw exports used — a review whose input data cannot be reproduced cannot be relied on later. ### Joiner-mover-leaver timing | Event | Action | Timing driver | | --- | --- | --- | | Joiner | Provision from role template only; no cloning of a colleague's account | Cloning propagates over-entitlement invisibly | | Mover | Revoke old, then grant new — in that order | Doing it in reverse leaves the union in place if step two stalls | | Leaver (planned) | Disable at end of last working day; revoke tokens/sessions/keys, not just the password | Sessions and API tokens survive a password change | | Leaver (immediate) | Disable before notification, including remote access and shared credentials they knew | Shared credentials must be rotated, not just re-permissioned | | Contractor end date | Automatic expiry set at provisioning | Contractors without an expiry date are the most common orphan source | ## Failure modes this skill exists to prevent - **Bulk approval.** An approver clicks approve-all in one action. Detect it: identical timestamps across an approver's whole list is a red flag; re-run that approver's set with the unused-access flags surfaced. - **Name-matched reconciliation.** Two people with the same name, or an account under a maiden name, silently matches wrong. Join on an identifier or don't join. - **Password-only offboarding.** Account disabled, but API keys, SSH keys, OAuth grants, and shared credentials still work. - **Permanent exceptions.** An exception with no expiry becomes policy. Every exception needs an owner and a date, and expired ones return to the next cycle. ## Data handling Classification: **Confidential**. Access review data links named individuals to systems and permissions and is itself an attack map. Distribute only to reviewers and the audit function; never paste full entitlement exports into shared chat or into a model context alongside unrelated work. If a user supplies real employee identifiers, account numbers, or credentials in conversation, flag it and do not proceed until they are removed or the work moves to an approved system. ## Boundaries - A single new access request from one person — `it-service-desk-triage` handles the request path; this skill only governs periodic and lifecycle review. - Designing what a role should be entitled to (role mining, least-privilege modelling) is upstream of this skill; do that before the first cycle or the review just recertifies a bad model. - A change to the access control system itself needs `it-change-management`. - Investigating suspected misuse of an account is a security investigation, not a review — escalate rather than handling it here. ## Hand-offs - **Receives from:** `it-service-desk-triage` (access requests granted since the last cycle, which this review validates). - **Routes to:** `it-change-management` for bulk revocation windows; `data-analytics-report-qa` when review coverage statistics are reported to a board or auditor and the numbers must be verified before circulation.