Ask anyone who administers a computer network what least privilege means and you will get a clean answer. Give each account the minimum access it needs to do the job, for the minimum time it needs it, and take the access away when the need ends. It is not controversial. It is not clever. It has been the default posture of competent IT for decades.
Now walk down the hall and ask the same question about the doors.
In most buildings there is no answer, because nobody has ever framed doors as an access control problem in the sense IT means it. The fob is a convenience. It is issued when someone starts, it opens what it needs to open, and after that it is nobody's file. Nothing about the arrangement is negligent. It simply has no review step in it, and a system with no review step does not stay where you put it.
Access accumulates. That is the whole problem.
Here is what actually happens over a few years in a building nobody is watching closely.
Somebody moves from one department to another and gets the access the new role requires. Nobody removes the access the old role required, because removing it would take a conversation with a person who is not asking for it, and the request that arrived was to add. So the second set of doors joins the first.
A contractor arrives for a fortnight of work in a mechanical room and needs to get in before anyone is on site. Issuing a credential that expires on a particular date takes extra clicks and requires somebody to know the end date, which nobody does with confidence. So a permanent credential goes out, to be retrieved later. It is not retrieved — the retrieval was never anyone's named task.
Somebody senior needs to get into a handful of rooms at odd hours, and the person configuring the system is under time pressure. The master profile already exists and works instantly; building a narrower one means thinking about which doors and which hours. The master gets applied. It is still applied.
None of that is misconduct. Every step was a small, reasonable local decision, and added together over years they produce a building where access rights are far wider than anyone intends and nobody can describe their shape. That is drift, and drift is the ordinary condition of an unaudited system, not a scandal.
This matters enormously for how you run the audit. If you open it as a hunt for who has been getting away with something, you will get defensiveness, slow answers and quiet obstruction, and you will not finish. If you open it as this system has never been reviewed and we are going to find things that look bad and mostly are not, people will help you, because you have told them the truth in advance.
Before you start: this audit reads personal information
One thing to settle before you open the software.
An access audit means pulling cardholder lists and credential use history and putting names beside doors and dates. In British Columbia, that is personal information about identifiable individuals, held by your organization, and the Personal Information Protection Act governs it. The Act's employee provisions — s.13 on collection, s.16 on use and s.19 on disclosure — let an employer handle employee personal information without consent where it is reasonable for purposes of the employment relationship, and each carries a duty to notify the individual about the purposes. Section 34 requires reasonable security arrangements for what you hold, which now includes the spreadsheet you are about to create. Section 35 governs how long any of it is kept.
The practical version is short. Decide your purpose before you pull the data and write it down in a sentence: we are reviewing who holds credentials to which spaces, to remove access that is no longer needed. Tell people that is happening. Keep the working files somewhere access-controlled rather than on a shared drive everyone can read, and delete them when the review is finished — an audit extract is a second copy of exactly the personal information the original system holds. If your cardholders include tenants, residents or contractors rather than employees, a different part of the Act applies to them and the notification question changes shape rather than disappearing. The full treatment is in your door logs are personal information, worth reading before you start rather than after.
The five questions
Each of these is answerable this week with the software you already own. None requires a consultant. What they require is that somebody sits down and refuses to accept a vague answer.
1. Who can open your most sensitive space, and can you justify each one by name?
Pick one space. Not the whole building — one room where a problem would genuinely hurt. The server room, the pharmacy, the cash office, the records room.
Pull the list of every credential that opens it and turn each entry into a human name. Then go down the list out loud and say why that person needs it. Not they're in facilities — that is a category, not a justification. Say what they do in that room and roughly how often.
The names you cannot finish a sentence about are the finding. In a typical first pass the list is longer than the person running the audit expected, and a meaningful share of it is people who needed the room once, people who inherited it with a profile, and people who left the team but not the organization.
The question works because it is small enough to finish and uncomfortable in a productive way: reading names aloud turns an abstract list into specific decisions somebody has to own.
2. How many credentials are active, and how many people work here?
Two numbers. Get them from different places: the credential count from the access system, the headcount from payroll or HR.
They will not match, and the gap is not automatically wrong. Some people legitimately carry two credentials. Vehicles, deliveries, cleaning contractors and after-hours trades all hold cards that correspond to no one on payroll. The point is not that the numbers should be equal. The point is that you should be able to explain the difference, and the explanation should be made of categories you can name and count, not a shrug.
This question earns its keep at the extremes. A credential population dramatically larger than the population of humans with any business in the building is a system that has never had anything removed from it — a quick measurement that tells you whether the rest of the audit is a tidy-up or a project.
3. Which credentials have not been used in a long time?
This is the single highest-yield query in the whole exercise, and most systems will produce it directly. Ask for last-use dates across all active credentials and sort ascending.
A credential that opens doors and has not opened one in many months is one of a small number of things: a person who has left and whose record was never disabled, a contractor whose job ended, a spare card issued and forgotten, a card that was lost and quietly replaced without the original ever being voided, or a genuine occasional user like a board member or an after-hours trade. The first four should be closed. The fifth should be labelled so that next year's review recognizes it immediately.
Set a threshold you can defend rather than agonizing over the perfect one. Whatever period you choose, every credential past it needs a name beside it and a decision — keep with a written reason, or disable. Do not delete cardholder records reflexively; disabling preserves the history you may need, and what you keep and for how long is a s.35 question worth deciding deliberately rather than by default.
If pulling this report is harder than it should be, that is its own finding. The four reports your access system should be giving you covers what a system ought to hand you without a fight.
4. Who can grant access, and who reviews what they granted?
Move up a level. Question one asked who can open a door. This asks who can decide who opens a door.
List every person who holds administrator or operator rights in the access control software, including the installer's account, any integrator remote-access account, and any shared login. Then ask the second half, which is the half that is almost always missing: when one of those people grants somebody access, who sees that it happened?
In most buildings the honest answer is nobody. Grants are made by the person with the software open, in response to a request from someone who needed something, and no one reviews the result. That is how a two-week contractor ends up with a permanent credential — not because anyone decided to give one, but because no second pair of eyes ever looked at the decision.
The fix is not heavy. A monthly list of what changed, read by somebody other than the person who made the changes, is enough to catch nearly everything this question is designed to find. Shared administrator logins should also come out of the arrangement: if two people use one account, the record cannot tell you which of them acted, and you have lost the accountability the log exists to provide.
While you are here, look at how access is structured rather than just who holds it. Broad profiles applied because they were quicker than thinking are the mechanism by which access spreads, and the two-question rule for access levels is the way to stop creating them.
5. What happens on the day someone leaves — and who does it?
The last question is the one that determines whether the other four stay answered.
Ask it precisely. Not do we remove access when people leave, which everyone says yes to. Ask: on the day a person's employment or contract ends, what specific steps happen in the access control system, who performs them, how are they notified that it is time, and how would you know a month later whether it was done?
Common failure shapes: the notification is verbal and arrives late; the responsibility sits with someone who is not always available and has no backup; the credential is collected but the cardholder record stays active, so a copied or cloned card still works; the departure is a contractor finishing rather than an employee resigning, so it never enters the HR process that triggers anything at all.
The test of a working answer is that you can name a person and a trigger. If the answer is a department rather than a role, or a practice rather than a step, it will hold right up until the departure that matters is messy — which is precisely the departure where it needs to hold.
Running it without poisoning it
Say the framing out loud at the start, to whoever is helping: we expect to find things that look bad. They are almost certainly drift and inherited practice, not wrongdoing, and we are fixing the system rather than finding a culprit. Say it even if you think it is obvious. Somebody in the room is worried that a decision they made two years ago under time pressure is about to be held up as an error, and that person is often the one who knows where everything is.
Then keep the output boring. A list of credentials disabled, a list kept with reasons, the two counts from question two, the administrator list, and the named person who acts on departures. Date it, keep it somewhere protected, and put a note in the calendar to do it again. An audit that happens once tells you where you were on one afternoon; the value is in having a baseline to compare against next time.
None of this makes a building secure by itself. It makes the building's access legible — someone can say who can open what, and why — which is the precondition for every other decision you will make about doors, including the hardware ones covered in how access control actually works and the wire between your card reader and the door.
Least privilege was never a technology. It is the habit of asking whether an access right is still earning its place. Your network has that habit. Your doors probably do not, and five questions is a reasonable price to find out.