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

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.