List every system, list who can reach each, and remove anybody who no longer needs it. Include suppliers, former staff, and accounts nobody remembers creating.

Why the list only grows

Somebody needs access to do something, so they are given it.

The task ends, the project finishes, the person leaves, and nothing triggers the reverse.

Removal requires somebody to remember, at a moment when nobody is thinking about it, which means it does not happen.

After three or four years the set of people who can reach your systems is meaningfully larger than the set of people involved with your business, and nobody has a list of either.

What to review

The last is on the list deliberately. A digital access review that ignores who still has a key is answering half the question.

Four groups to look for

The categories that account for almost everything you will find.

Former staff, who are the obvious ones and frequently still have more than expected.

Former suppliers: an agency, a developer, a bookkeeper, or a consultant whose engagement ended.

Current suppliers with more access than they need, which is common because access is granted broadly to avoid a second request.

And accounts nobody recognises, which are usually legitimate and forgotten rather than sinister, and are worth resolving either way.

Check the routes that survive removal

The part that a simple user list will not show, and where access actually persists.

Email forwarding rules and delegated mailbox access, which continue after a password change and after an account is removed from a group.

Connected applications and integrations authorised at some point and never reviewed, each holding access on somebody's behalf.

Recovery email addresses and phone numbers pointing at people who have left, which allow an account to be recovered by somebody who should not be able to.

And shared logins, where removing a person changes nothing because the credential is the same one everybody uses.

Those four are where a review that only looks at user lists misses the actual exposure.

A worked example

A firm with four staff reviewed access for the first time and produced a list of eighteen people and services with some form of access.

Two were former employees, one of whom had left in 2018 and still had administrative access to the website.

Three were former suppliers, including a developer whose engagement had ended two years earlier.

Two connected applications had been authorised by somebody nobody could identify.

And the recovery address on one important account was a personal address belonging to somebody who had left.

Removing all of it took about two hours, and the recovery address was the item that concerned them most, because it was the one that would have allowed an account takeover with no password required.

Shared logins are the underlying problem

Worth naming, because they make a proper review impossible.

Where five people use one login, there is no user list to review, no record of who did what, and no way to remove one person's access without disrupting everybody.

The remedy is individual accounts wherever the service supports them, which most now do, even if that means paying for an additional seat.

Where a service genuinely does not support multiple users, the credential lives in a shared vault and is changed when anybody with access leaves.

That is the only version of a shared login that can be managed, and it converts an unanswerable question into a routine task.

Do it as part of leaving

The change that stops this accumulating again.

Whatever list you already follow when somebody leaves should include removing access, transferring ownership of anything they created, changing any shared credentials they knew, and checking recovery details that point at them.

Add it to the list that covers keys and the final payslip, since that list gets followed and a separate one will not.

The same applies when a supplier engagement ends, which is the version nobody has a process for at all.

Doing it at the time takes ten minutes. Doing it three years later takes two hours and produces the findings above.

Reduce what needs reviewing

A structural point that makes future reviews shorter.

Grant the minimum level rather than the maximum: a manager rather than an owner, view rather than edit, one folder rather than the drive.

Give suppliers their own account rather than sharing yours, so removal is one action rather than a password change affecting everybody.

And keep ownership of the important accounts with the business rather than with an individual, which is the item that causes the worst problems when somebody leaves unexpectedly.

Each of those decisions is made once and saves the same work every year afterwards.

Do it kindly

A note about tone, because this review involves people who mostly left on good terms.

Removing a former colleague's access is not an accusation and should not be conducted as one, and the same applies to a supplier whose engagement simply ended.

Where you need something from them, such as transferring ownership of a file or an account they created, ask directly and explain why, since almost everybody helps when asked plainly.

Do it soon after they leave rather than years later, when the request arrives out of nowhere and reads as suspicion.

And tell current staff that the review happens annually and applies to everybody, so nobody reads a permissions change as a judgement about them.

The counter-case

Access reviews can be applied too enthusiastically.

Stripping people down to minimal permissions in a four-person business produces daily requests, delays, and workarounds, and the workarounds are usually less secure than the access you removed.

There is also a difference between somebody who has left and somebody who is simply not currently working on something, and removing the second creates friction for no benefit.

And for a very small business where everybody does everything, broad internal access is the correct arrangement and the review should focus on former people and outside suppliers.

Remove the people who are gone. Reduce what outsiders hold. Leave the working arrangements alone.

The two hours

  1. List every system, including physical access.
  2. List who can reach each.
  3. Remove former staff and suppliers.
  4. Check forwarding, delegation and connected apps.
  5. Fix recovery addresses pointing at people who left.
  6. Replace shared logins with individual accounts.
  7. Add access removal to your leaving process.

Step five is the one with the worst consequence if missed, since a recovery address is a way in that no password protects.

Folder permissions specifically are covered in who can see the shared drive.


Frequently asked questions

Why does access accumulate?

Because it is granted whenever somebody needs something and removal requires a person to remember at a moment nobody is thinking about it.

What should the review cover?

Email, the website, hosting and the registrar, your listing and social accounts, accounting and banking, shared drives, advertising accounts, and physical keys and codes.

What does a user list miss?

Email forwarding and delegation, connected applications authorised long ago, recovery addresses pointing at people who left, and shared logins where removing a person changes nothing.

Why are recovery addresses so important?

Because they allow an account to be recovered by somebody who should not be able to, with no password required. It is the item with the worst consequence if missed.

What makes reviews impossible?

Shared logins. There is no user list, no record of who did what, and no way to remove one person without disrupting everybody. Use individual accounts wherever supported.

Can this be overdone?

Yes. Stripping a four-person business to minimal permissions produces workarounds that are less secure than the access removed. Focus on former people and outside suppliers.

West Coast Media Solutions Inc. provides web design, web development, hosting, digital marketing, and business consulting to organisations across Canada, drawing on more than twenty-five years in the field.

Never listed who can get in?

Start with recovery addresses and connected applications. Those are where access survives everything else you would think to check.

Start a Conversation