Offboarding is not access control
Most stores have some version of a leaving process. Somebody resigns, and in the following week their accounts get removed, more or less. It is imperfect but it exists, and it catches the obvious case.
The problem is that leaving is only one of the ways access becomes wrong, and it is not the most common one. Far more access is stale because a project ended, a role changed, somebody covered for a colleague and never had the cover removed, or an agency was given a login for one afternoon in March and nobody thought about it again.
None of those trigger a review, because nothing happened. That is the whole issue: the most common cause of excessive access is the absence of an event.
So the mechanism has to be calendar-driven rather than event-driven. Once a quarter, somebody looks at everything, regardless of whether anything has changed.
What accumulates, in rough order of frequency
- Cover that never ended. Someone was given wider access because a colleague was away. The colleague came back. The access stayed. This is the single most common form of drift and the least visible, because the person did nothing wrong at any point.
- Finished projects. A developer, a migration consultant, a photographer who needed product access. The engagement ended and the invoice was paid, which feels like closure and is not.
- Role changes. Somebody moved from fulfilment to customer service and kept both sets of permissions, because adding is a deliberate act and removing is not.
- Apps installed for a trial. Installed to try, never uninstalled, still holding whatever scopes they were granted.
- Shared logins whose members have changed. The worst category, because you cannot even enumerate who has access without asking around.
Running the review in under an hour
The review fails when it is designed as an audit. It succeeds when it is designed as a short list of yes-or-no questions.
- List every human with a login. Staff accounts, workspace members, anything with a password.
- For each, answer one question: does this person still do the job this access was granted for? Not whether they are trustworthy. Not whether they might need it later. Whether the reason still exists.
- List every app. Same question: is this still in use?
- Find anything you cannot attribute to one named person. Shared logins go on a separate list and get fixed properly rather than reviewed.
- Remove what failed the question. Today, in the same sitting, not as a follow-up task.
That last point is the one that determines whether the review is real. A review producing a list of things to remove later produces nothing, because next quarter's review will find the same list with additions.
The objection you will feel, and why it is wrong
Removing access from somebody who has not done anything wrong feels like an accusation, and in a small team where everyone knows each other, it feels rude. That instinct is why these reviews do not happen.
The reframe that helps: access is not a statement about trust, it is a statement about current responsibilities. Removing it from someone whose responsibilities changed is bookkeeping, not suspicion. It is much easier to say so in advance, as a standing quarterly thing everyone knows about, than to explain it the first time you do it to one person.
Announcing the cadence once, when you start, removes almost all of the awkwardness. "We look at this every quarter, it is not about you" is a sentence that only sounds defensive if you say it for the first time while removing somebody's access.
What to check beyond logins
Access is broader than accounts, and the non-account kind is what people forget entirely.
- Shared documents and drives where link sharing was turned on for convenience and left on.
- Group chats containing people who no longer work with you. Former contractors sitting quietly in a WhatsApp group is extremely common and nobody notices, because leaving a group is a visible act nobody wants to perform on somebody else.
- Saved payment methods and supplier portals, which usually have one login shared by whoever needs it.
- Email forwarding rules set up during somebody's absence, still forwarding.
Making the next one easier
The first review is the long one, because it is clearing years of accumulation. Two habits make every subsequent one short.
Write the reason next to the access. When somebody is granted something, note in one line why. "Theme project, ends October." Next quarter the review is reading a list rather than reconstructing history from memory, and that difference is the difference between a review that happens and one that does not.
Give external access an end date at creation. Not a reminder to review it, an actual date at which it is removed unless renewed. The default should be off, which inverts the work: instead of remembering to remove, somebody has to remember to extend, and people are much better at asking for what they need than at surrendering what they have.
Dealing with the shared logins you find
Shared logins will not survive a review as a yes-or-no question, because the honest answer to "does this person still need it" is that you do not know who this person is. They need separating rather than reviewing, and that is a project rather than a decision.
The blocker is almost never technical. It is that separating a shared login usually means somebody has to pay for another seat, or somebody has to admit they have been using an account that is not theirs. Both are awkward, which is why shared logins persist through several reviews unchallenged.
The sequence that works: find out who actually uses it, which takes one conversation and is usually more people than you expected. Decide which of them genuinely need their own access and which only needed information. Give real accounts to the first group, something else to the second, and change the password on the original the day the last person is migrated. Not before, and not a fortnight after, because the gap is where it quietly continues.
The half-hour version
If an hour a quarter is more than you will actually commit to, do a shorter version rather than skipping it. The short version catches most of the risk because risk is not evenly distributed.
- Every external account. Agencies, freelancers, contractors, anybody not on your payroll. This is where stale access concentrates, and it is usually a list of four or five.
- Anything you cannot attribute to exactly one named person.
- Anyone who changed role in the last quarter. You will remember who without needing a list.
That covers the large majority of what a full review would find, in a fraction of the time. Internal staff whose roles have not changed are the lowest-risk group and the slowest to check, so they are the right thing to drop when time is short.
Writing down what you did
Keep a two-line record of each review: the date, and what you removed. It takes a minute and it does two things.
It tells you next quarter whether the review is working. A review that removes something every time is catching real drift. A review that finds nothing three times running either means your granting habits have got good, which is worth knowing, or that the review has quietly become a rubber stamp, which is worth knowing sooner.
It also matters if anyone ever asks how you manage access, which happens more often than small stores expect: a larger wholesale partner, an insurer, or a platform doing due diligence. A dated list of reviews is a far better answer than a description of good intentions.
Related reading: offboarding contractor access covers the event-driven half, and scoping freelancer access covers granting the right amount in the first place.
Common questions
How often should we review access?
Quarterly is enough for most small stores. Monthly becomes a chore that gets skipped, and annually allows too much accumulation for the review to be quick, which is what makes it get skipped too.
Is it rude to remove access from someone still working with us?
It reads that way if it is a one-off. It does not if it is a known quarterly routine, which is the main argument for announcing the cadence before your first review rather than explaining it afterwards.
What is the most common stale access?
Cover that never ended. Somebody was given wider access while a colleague was away, the colleague returned, and nothing triggered a removal because nothing happened. Nobody did anything wrong, which is why it stays.
Should we review apps as well as people?
Yes. Apps installed for a trial and never uninstalled are common, and they hold whatever permissions they were granted for as long as they stay installed.
How do we make the review quicker next time?
Write the reason beside the access when granting it, and give external access an end date at creation. Then the review is reading a list rather than reconstructing why someone has a login.