Most access sprawl doesn’t happen in one careless moment. It accumulates — a contractor added for a two-week project, an API key generated for a demo, a shared login handed to a collaborator who left the team eight months ago. None of it was wrong at the time. The problem is that almost nobody goes back and closes the door.
An access audit is the practice of going back. It doesn’t require new tooling or a security team — just an hour, a checklist, and the discipline to actually revoke what you find. Here’s how to run one.
1. List every place you grant access#
Before you can audit anything, you need the full surface area. Write down every system where you or your team can add a person, a key, or a token:
- Cloud provider consoles (AWS, GCP, Azure IAM users and roles)
- Git hosting (GitHub/GitLab org members, deploy keys, personal access tokens)
- CI/CD and hosting platforms (Vercel, Netlify, Cloudflare, CircleCI)
- Payment and billing dashboards (Stripe, banking, accounting software)
- Internal tools (admin panels, databases, VPN)
- Shared password vaults and the individual entries inside them
If this list takes longer than five minutes to write, that’s useful information on its own — it tells you how many separate places “access” currently lives.
2. Pull the current member and key list from each one#
For every system above, open its members/users page and its API keys or tokens page. Most platforms have both, and they’re rarely audited together. A contractor’s user account might be gone while the personal access token they generated is still valid — tokens routinely outlive the people who made them.
3. Ask three questions per entry#
For each person, key, or token you find, ask:
- Do I know why this still exists? If you can’t immediately explain the business reason, that’s a signal, not proof of a problem — go verify it.
- Is the person still working with you, in a role that needs this? Contractors who finished a project, past collaborators, and former employees are the most common source of orphaned access.
- Does the scope match the need? A key issued for read-only reporting that somehow has write access is worth narrowing even if the person is still active.
Anything that fails one of these gets flagged for revocation, not maybe. “I’ll deal with it later” is how the same key ends up on next year’s audit.
4. Revoke, don’t just disable#
Where the platform distinguishes between disabling and deleting/revoking, prefer the permanent option once you’re confident the access isn’t needed. Disabled accounts and paused keys have a way of getting silently re-enabled during a later cleanup pass by someone who doesn’t have the context you do right now.
5. Rotate anything that was ever shared informally#
If a credential was ever sent over email, Slack, or text — rather than issued through a proper access system — rotate it during this audit even if the recipient still needs access. A copy in a chat log or an inbox is access you can no longer see or revoke individually.
6. Put a date on the next one#
An audit that happens once catches today’s sprawl but not next quarter’s. Pick a cadence — quarterly is reasonable for a small team — and put it on a calendar, not a to-do list you might not reopen.
Making the next one faster#
The reason this kind of audit feels tedious is almost always the same: the list of who-has-access-to-what lives in a dozen different places, and building it means logging into each one separately. Keeping credentials and shared access centralized in one place — which is the problem we work on at CentralizeMe — turns this from an afternoon of tab-switching into a five-minute review, because the list already exists. Either way, the audit itself is what matters. Run it before the forgotten key becomes someone else’s incident.