how to do a basic access review quarterly

how to do a basic access review quarterly

TL;DR

Every quarter, pull the user list from each system, check that every person still needs what they have, and remove what they do not. Departures, role changes, and dormant accounts are where access goes stale. The review is boring, which is exactly why it catches things.

how to do a basic access review quarterly

Use this when

• It has been more than three months since anyone checked who can access what
• An auditor, customer, or framework asks for periodic access reviews
• Someone left and you are not sure everything got revoked
• You suspect permission creep: people accumulating access they no longer need

Not for this skill when

• You need real-time deprovisioning when someone leaves (that is offboarding, do it immediately)
• You are designing the initial permission model (do that first, then review it)
• You need to review what data people saw, not what they can access (that is a different audit)

Steps

1. Pull the full user list from each system.

Identity provider, GitHub org, cloud console, databases, SaaS apps with sensitive data. One list per system, with last-login dates and roles. If you cannot pull the list, that system is already a finding.

idpctl users list --inactive-days 90

Expected: per-system user lists including dormant accounts nobody remembers.

2. Match every person to their current role.

For each name, ask: still employed, still on this team, still needs this level of access. Use the HR roster or team list as ground truth, not memory. Contractors and service accounts get the same treatment.

Expected: every account maps to a real person (or a documented service purpose) and a current role.

3. Flag departures, role changes, and dormant accounts.

Anyone who left, changed teams, or has not logged in for 90 days goes on the action list. Dormant accounts are attacker favorites because nobody notices them being used.

Expected: an action list with names, systems, and whether to remove or downgrade.

4. Revoke or downgrade, then verify.

Remove the access, then pull the list again to confirm it is gone. "I asked IT to remove it" without verification is how stale access survives three quarters in a row.

Expected: a second pull showing the flagged accounts gone or downgraded.

5. Get a sign-off from whoever owns the system.

A manager or system owner confirms the remaining access list is correct. The sign-off is the evidence auditors want, and it forces someone with context to actually look.

Expected: a dated sign-off per system: "reviewed, these people should have this access."

6. File the evidence and schedule the next one.

Store the before and after lists, the action log, and the sign-offs together. Put the next review on the calendar now, or it will slip.

Expected: one folder per quarter with everything an auditor would ask for.

Variant: user access review process

This skill is the process. The two habits that make it stick: pull lists from the systems (never from memory), and verify removals with a second pull.

Variant: quarterly access recertification

"Recertification" is the formal name auditors use. Same steps, slightly fancier paperwork. The sign-off in step 5 is the recertification.

Variant: how to find stale accounts

Sort every user list by last login date and start at the bottom. Service accounts with no owner documented go on the list too. Stale is stale regardless of account type.

Variant: IAM review checklist

Identity provider, cloud IAM, GitHub, databases, VPN, SaaS admins, CI secrets access. If a system holds production data or can change production, it is in scope.

Why this happens

Access only ever grows. People join projects, get temporary grants that become permanent, change teams without losing old permissions, and leave without full deprovisioning. Nobody sets out to create a stale admin account; it happens one unreviewed quarter at a time. The review is the ratchet that pushes back.

Edge cases and pitfalls

• Shared accounts: you cannot review who uses them. Migrate to named accounts first, or at least document who knows the credentials and rotate them during the review.
• Service accounts with no owner: assign an owner or delete them. An ownerless service account with broad permissions is a liability with no one to page.
• The reviewer rubber-stamps: rotate reviewers or have a second pair of eyes on privileged access. A sign-off nobody read is theater.
• SaaS apps outside IT's view: shadow IT is the classic gap. Ask teams what they use, check expense reports for SaaS charges, and pull those into scope.
• Contractors with open-ended access: give contractors expiry dates on access from day one. The review then just confirms the expiries worked.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_byciIEdqPKLpOxVEvG4J6w