Who Has Access to What

Why the list is longer than you think

Access is granted in the moment, quickly, to solve something. A developer needs to fix a page. An employee needs to update the listing. A supplier needs to check something.

Each grant is reasonable. None of them is recorded, and removal depends on someone thinking of it weeks later when the relationship has ended and nothing is prompting them.

The result after a few years is a set of accounts with an unknown number of people holding credentials, some of whom the business no longer deals with and one or two of whom it may have parted with badly.

What to inventory

Most systems have a users or permissions screen listing this directly. The exercise is opening each one and reading it, which is duller than it is difficult.

The findings that recur

• A previous web designer still holding administrator access, sometimes from a project that ended years ago.
• Former employees with accounts nobody disabled.
• A shared login used by several people, where nobody can say who has it.
• Email forwarding rules sending copies somewhere nobody remembers setting up.
• The analytics property owned by an agency rather than the business, meaning the history is theirs.
• Recovery addresses pointing at people who have left, which is the one that turns a routine reset into a serious problem.

That last one deserves particular attention, because it is invisible until the day you need to recover an account and discover the code goes to somebody else.

The principle worth applying

Give the least access that lets someone do the job, for the shortest time they need it.

Most systems have roles below administrator, and most people given administrator access do not need it. A contractor updating pages needs editor access. A bookkeeper needs the accounts, not the hosting. Someone posting to a listing needs manager rather than owner.

The practical benefit is not distrust. It is that a compromised account with limited permissions is a contained problem rather than a total one.

Named accounts rather than shared logins

Where a system supports multiple users, use them, which most business platforms do at no extra cost.

Three benefits: you can see who did what, removing one person is one action, and you are not changing a password everyone relies on every time someone leaves. Shared logins fail on all three, which is why the leaving employee scenario is so consistently mishandled.

It also means two-factor authentication can be applied per person rather than being an obstacle to sharing, which resolves the tension described in two-factor authentication on the accounts that matter.

When somebody leaves

A short list, run the same way every time.

• Disable rather than delete first, so anything owned by that account is not lost.
• Remove them from every system on your inventory, which is why the inventory exists.
• Change any shared password they knew.
• Check recovery addresses and phone numbers that pointed at them.
• Reassign anything they owned, particularly analytics properties and listing ownership.
• Check for forwarding rules they may have set on their mailbox.

The same list applies to a supplier relationship ending, which is the case people forget because it does not feel like an offboarding.

Making it stick

One page listing each system, who has access, and at what level. Reviewed twice a year and whenever someone joins or leaves.

That document is the whole of it. Without it, access is reconstructed from memory each time, which is how a former designer keeps administrator rights for four years. With it, the review is twenty minutes and the offboarding is a checklist rather than a recollection.

Frequently asked questions

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.