The User Audit: Who Still Has a Login?

There is a moment in every user access audit that changes the temperature of the room. Someone exports the user list from the ERP, sorts it by last login, and finds an account that was used three weeks ago belonging to a person who left the business in 2024. Nobody in the room knows who used it. That is not a dramatic story invented to sell security services — it is the ordinary outcome of granting access urgently and revoking it never.

A user audit is simply the act of asking every system who it thinks works here, and comparing the answer to the payroll. It is unglamorous, it takes about a week, and it is the highest-yield security exercise most businesses have never run.

What a user audit actually is

Three steps, and none of them are technical:

1. Inventory the systems. Every place a person can log in. Not just the ERP and email — the supplier portals, the courier booking site, the CCTV app, the bank, the accounting package, the WhatsApp groups, the shared drive, the Wi-Fi, the alarm.
2. Export the users from each one. Username, full name, role or permission level, date created, last login, and whether the account is active.
3. Reconcile against HR. The payroll list is your source of truth for who works here. Every account that does not map to a current employee, a named contractor, or a documented service account is a finding.

That is the whole method. The value is not in cleverness; it is in the fact that nobody has ever put those two lists side by side.

What you find, in order of how often

• Leavers who are still active. The headline finding. Email is usually closed promptly because it is visible; the ERP, the supplier portal and the accounting package are usually not, because closing them requires knowing they exist.
• Movers carrying old access. Far more common than leavers, and quieter. The person who moved from sales to dispatch eighteen months ago still has the sales permissions, plus the dispatch ones. Repeat over a few years and someone in a junior role has accumulated the combined rights of four departments.
• Orphaned service accounts. "sqlservice", "backup_user", "integration". Real accounts with real passwords, usually never rotated, frequently over-privileged, and owned by nobody. The person who created one left in 2022.
• Shared logins. The "warehouse" account four people use. Not a security failure in itself, but it destroys attribution: no action taken through that login can ever be traced to a person.
• Contractors and vendors. The support partner who needed remote access for a go-live three years ago and never had it removed. Often with administrator rights.
• Administrator creep. Count the accounts with full administrative rights in each system. The number is almost always larger than anyone expects, and rarely defensible.
• Licences with nobody behind them. Accounts that have never logged in, or not in a year, sitting on paid seats every month.

An account nobody owns is an account nobody notices. That is precisely what makes it valuable to an attacker and invisible to you.

Why "still active two years later" matters more than it sounds

The instinctive response is that the person was decent and would never misuse it. That is usually true, and it is also beside the point, because the risk does not depend on their intentions.

The credential outlives the relationship. That password was very likely reused on a personal account somewhere. When that other service is breached — not if — the username and password appear in a public dump, and an automated attempt against your systems succeeds. The former employee did nothing wrong and your ERP is open.

Nothing is watching it. A dormant account is the ideal foothold precisely because no one will notice unusual behaviour on it. There is no colleague to say "that's odd, why was Thandi in the system at midnight" — Thandi left.

You cannot answer the POPIA question. POPIA asks you to secure personal information and to be accountable for who can access it. "We are not certain who has access" is not a defensible position, and the audit is what turns it into a document instead of a shrug.

Attribution disappears. If a credit note is raised improperly and the account belongs to someone who left, your audit trail records an action by a person who was not there. Attribution protects your staff as much as it protects the business, and dormant accounts destroy it.

And it costs money. Which is usually the finding that gets the project approved.

How to run one in a week

This does not need a tool or a consultant. It needs a spreadsheet and someone who will finish it.

1. Monday — list the systems. Ask each department head what they log into, then check the card statement and the supplier invoices for the things they forgot. The invoice list is always longer than the memory list.
2. Tuesday — pull the exports. One tab per system. Include last-login dates wherever the system offers them; they do most of the work for you.
3. Wednesday — reconcile. Match against the payroll list. Everything unmatched goes into one of four buckets: leaver, service account, contractor, or unknown.
4. Thursday — decide, with the business. This is not an IT decision. The manager of each area confirms who should have access and at what level. Expect the "unknown" bucket to be the most interesting conversation of the week.
5. Friday — act, and write it down. Disable, downgrade, reassign or document every line. Nothing stays undecided.

Disable, do not delete

Switch the account off first and leave it off for a defined period — sixty to ninety days is typical. Deleting immediately can orphan records, break historical reports, and destroy the link between a transaction and the person who made it. Before deleting anything, transfer ownership of files, documents and scheduled jobs to a named colleague. Then delete on a schedule, not on impulse.

Service accounts need a different treatment: do not disable one until you know what it does, because that is how a nightly integration silently stops running. Find the owner, document the purpose, rotate the password, reduce its privileges to what it actually needs, and record the next rotation date.

Making it stick, so you never do it cold again

The audit is the easy part. Businesses that only ever audit end up doing exactly the same exercise, with the same surprises, three years later. Four habits prevent that:

• An access register. One page per person: every system they can reach, the level, who approved it, when. Written at the moment access is granted, not reconstructed afterwards. You cannot revoke what you never recorded.
• A quarterly review that takes an hour. Each manager reads their team's page and confirms it is still right. Quarterly is enough; annually is not, because roles drift faster than that.
• A leaver checklist that is actually run. Tied to the HR process rather than a favour someone does IT. The joiner-mover-leaver routine is what stops the backlog re-forming.
• One identity where possible. The structural fix is to stop having eight lists. Connecting your systems to your directory means disabling one account closes them all, and the quarterly review becomes a review of groups rather than of every system in turn.

Start with two people

If a week sounds like more than you can commit to, do the small version this afternoon. Take the last two people who left. For each, try to log into email, try one shared password they knew, and check whether their account still exists in your main business system. Thirty minutes.

If everything is properly closed, you have a process and you can schedule the full audit calmly. If anything still works, you have your answer about how urgent this is — and you now have a finding specific enough to get the time approved.