Free checklist
User access review checklist for a small team
A teammate changes role, drops to part time or starts a new project. Here is how I'd review what they can still reach, in about 20 minutes, without locking anyone out.
Not a security audit or legal advice. This is a working checklist for small projects. It has no provider-specific menus, because they change. Check each provider's current help pages before you change access.
When to run a review
Run it when something about a person changes, not on a calendar alone. Good triggers:
- A teammate changes role, for example from developer to part-time adviser.
- Someone cuts their hours or pauses for a few months.
- A freelancer or contractor finishes a piece of work.
- You add a new paid tool, so access is now spread across one more place.
- Every quarter, as a fallback. Put the date in your decision log.
If the person is leaving the project entirely, use the handover checklist instead. A role change is smaller: nobody leaves, but what they need changes.
How is this different from the access audit?
The access audit asks one question: could one person lock the rest of you out? This checklist asks another: does each person still have the right amount of access for what they do now? You need both. Run the audit first, then this.
Before you change anything
Do the first step before the rest. It stops you removing the one person who can undo a mistake.
1. Make the list
2. Decide what the new role needs
3. Keep a second person in control
4. Change access, then test it
5. Record it
Ticks are saved in this browser only.
The review sheet
Download the CSV (opens in Google Sheets, Excel and Numbers). Or copy this table.
| Tool or account | Owner | Pays | Recovery held by | Person | Role now | Role needed | Change made on | Tested by |
|---|---|---|---|---|---|---|---|---|
A filled-in example (illustrative)
Two co-founders, A and B. B moves from full time to adviser. The tools, roles and dates are made up to show the method.
| Tool | Owner | Pays | Recovery held by | B's role now | B's role needed | Change |
|---|---|---|---|---|---|---|
| Domain registrar | A and B | Project card | Project email | Owner | Owner | None. B stays as the second person in control. |
| Code organisation | A and B | None (free plan) | Project email | Owner | Owner | None. Repos stay in the organisation. |
| Hosting | A | B's card | A's phone | Admin | Read-only | Move billing to the project card first, then lower B to read-only. |
| Ads account | A | B's card | B's email | Admin | None | Move recovery to the project email, change the card, then remove B. |
| Password vault | A and B | Project card | Two people | Owner | Member | Keep a second owner. Lower B only once A can recover everything. |
Two rows are unchanged on purpose. B can step back from daily work and still be the second person who can recover the domain and the code. Two rows had B's card or email in them, so billing and recovery moved before the role did.
Mistakes I'd avoid
- Lowering access before moving billing and recovery. That is how a card fails or a recovery email goes dead with nobody able to fix it.
- Reviewing only the person who changed role. Run the whole list once. You will usually find an old account nobody remembered.
- Treating it as a trust test. Say it is routine. Least access for the job is how you protect the person as well as the project.
- No test afterwards. If nobody signs in, you have not reviewed access, only changed settings.
Do it with AI
Draft your review sheet
Describe your tools and the role change. Do not paste passwords, codes or personal data.
I run a small project with a co-founder. One of us is changing role: [NEW ROLE IN ONE SENTENCE]. Our tools: [LIST THE TOOLS, WHO OWNS EACH, WHO PAYS, WHO HOLDS RECOVERY]. Make a review table with columns: tool, owner, who pays, recovery held by, person's role now, role needed for the new job, change to make, order of changes. Rules: keep at least two people in full control of every critical account; move billing and recovery before lowering anyone's role; one tool at a time; add a test step for each change. Do not invent menu names. Where you are unsure how a provider handles roles, say so and tell me to check its current help page.
Frequently asked questions
What is a user access review?
A check of who can reach which tools and accounts, and whether each person still needs that level of access for what they do now.
How often should a small team review access?
When a person's role or hours change, when you add a tool, and as a fallback once a quarter. The triggers matter more than the calendar.
Should I remove access or lower it?
Lower it to what the new role needs. Remove it only if the role needs nothing from that tool. If the person is leaving the project, use the handover checklist.
Do I need to tell the person?
Yes. Agree the changes first and ask them to test their new access. A silent change reads as distrust and is how people get locked out by mistake.
Is this the same as a compliance access review?
No. Larger organisations may have formal rules for access reviews. This checklist is a lightweight version for small projects and does not meet any specific standard.
Use it with
- Access audit: first check that no one person can lock the others out.
- Handover checklist: for when someone leaves the project.
- Decision log: record each role change and who agreed.
- Bus factor guide: why two people in control matters.
- All free tools and all guides
Keep the owner, payer and recovery contact for every account in one place, and see which ones depend on a single person.