Review who has access to what

The purpose is a document somebody can act on: not "we have 43 users in GitHub" but "these four people left and three still have production access". Everything below is read-only until the final step, which is somebody else's to approve.

Gather

For each system in scope, list the accounts with access, the level, and the last sign-in:

• The identity provider — Okta or Entra ID — for the roster of people who should exist at all.
• Source control: repository collaborators and organisation owners, plus anything with admin.
• Cloud and hosting: the accounts and roles on the platforms that can deploy or reach production.
• Data: the warehouse, the databases, the analytics tools, separating read from write.
• Money and messaging: payments, email sending, anything that can spend or send in the company's name.
• Machine accounts and tokens, which are the ones reviews forget. A personal access token outlives the person.

Compare

Join each list against the identity provider's roster and mark:

• Accounts with no matching person. Former employees, contractors past their end date, and shared logins.
• Access nobody uses. No sign-in for ninety days is a candidate for removal whether or not the person is still here.
• Access wider than the role needs, most importantly admin and production write held by people who do not deploy.
• Anything not behind single sign-on, which is where an offboarding silently fails.

Report

One table per system, then a short list of what to remove, ordered by risk: production write and money first. Every row names the account and what it can do, not just that it exists.

Never do the removals yourself

Propose them. Removal is somebody's job to approve, and revoking the wrong account during a review is an outage with an embarrassing cause. Hand the list to whoever owns each system.