Someone in your building taps a fob at 02:14 on a Saturday. The door opens. Nobody is watching, nothing goes wrong, and the moment passes without a single person thinking about it.
Except your system thought about it. It wrote a row: credential number, door, date, time, granted. That credential number is tied to a name in the cardholder database, because it has to be — that link is the entire point of access control. So what your system actually wrote was this named person was at this door at 02:14.
Do that a few hundred times a day for two years and you are no longer running a door system. You are running a searchable history of where named individuals were and when, which you can query months later against any name, any door, any date range. Most BC employers, strata councils and property managers have never framed it that way. Their access control lives in the same mental category as the lighting or the elevators — building infrastructure, installed once, maintained rarely.
It belongs in a different category. In British Columbia, information about an identifiable individual, held by an organization, is governed by the Personal Information Protection Act. Access logs are exactly that. Which means the Act has things to say about your door system, and almost nobody who owns one has read them.
The realisation, stated plainly
Here is the test that usually lands.
Imagine a dispute six months from now — an employment matter, a strata conflict, an insurance claim, a lawsuit between two parties who both work in your building. Someone's lawyer asks what your access control system can tell them about a particular person on a particular night.
You can answer that question. That is the uncomfortable part. Not that your system might fail — that it will succeed, precisely and in writing, about a named individual, long after everyone has forgotten the night in question.
And the same capability points the other way. The person in those logs can ask you what you are holding about them. Their movements are their personal information, sitting in your custody.
If that feels like a lot of responsibility to be carrying by accident, it is. Nobody signed up for it. It arrived with the readers.
Where the Act touches your system
Three things in PIPA bear directly on access control, and they are unglamorous in a useful way.
You are expected to tell people. Sections 13, 16 and 19 of the Act deal with employee personal information — its collection, its use, and its disclosure — and each one carries a duty to notify the individual about what the organization is doing and the purposes for doing it. Not a poster in the lobby. Not a line buried on page nine of a fob agreement nobody reads. An actual statement: this system records which doors you open and when, we keep those records for this long, and here is what we use them for.
Ask yourself when you last handed a new employee a fob. Was anything said at all? In most buildings the entire conversation is "tap it here, don't lose it." That is a system collecting personal information from someone who has not been told it is happening.
Two limits on the above, both worth stating plainly rather than bluffing past.
The first is that the notify duty is the price of a particular route. Those sections let an employer collect, use and disclose employee personal information without consent where it is reasonable for establishing, managing or terminating the employment relationship — and the duty to notify is what the Act asks in return. Each section then carries its own exception one subsection later, where a different provision is the authority for the collection. An access control log is the ordinary employment-relationship case, which is why the duty lands on it; but the duty is a qualified one, not a free-floating rule, and anyone telling you otherwise has not read to the end of the section.
The second is that these sections govern employee personal information. Tenants, strata residents, contractors and visitors carrying a fob are not employees, and a different part of the Act governs them. We are deliberately not summarizing that part here, because doing it properly needs more room than this article has. If your cardholders are not all employees, the notification question does not go away — it changes shape, and it is worth asking about specifically.
You are expected to protect it. Section 34 is one sentence, and it is the most quotable line in the Act for anyone who owns a controller:
"An organization must protect personal information in its custody or under its control by making reasonable security arrangements to prevent unauthorized access, collection, use, disclosure, copying, modification or disposal or similar risks."
Read "reasonable security arrangements" while picturing the actual box. In a great many BC buildings the access control controller is a small unit in an electrical room, running firmware from the year it was installed, sitting on the same flat network as everything else in the building, reachable by anyone who can get to a network jack, with an administrator password that was set by the installer and never changed. It holds two years of named movement data.
That is the machine section 34 is describing. Not an abstraction — that box. Physical security people are usually comfortable talking about the door and uncomfortable talking about the head end, but the head end is where the personal information lives. An unpatched controller is not merely an IT hygiene problem; it is the storage location for the record of everyone's movements.
The practical version of section 34 for access control is short. Know where the controller is and what it is running. Know who can reach it over the network and narrow that list. Know who holds administrator credentials on the software and remove the ones who have left. Know whether the log data is backed up, and if it is, know that the backup is a second copy of the same personal information, deserving the same treatment.
You are expected to have decided how long to keep it. Section 35 is the one almost nobody has considered, and it cuts in both directions at once.
On one side, the Act requires that where an organization uses someone's personal information to make a decision that directly affects them, it must retain that information for at least one year after using it, so the individual has a reasonable opportunity to obtain access to it. If a door log contributed to a decision about a person, throwing it away quickly is not the safe option it might feel like.
On the other side, the Act requires an organization to destroy documents containing personal information — or remove the means by which the information can be associated with particular individuals — as soon as it is reasonable to assume that the purpose it was collected for is no longer served by keeping it, and that retention is no longer necessary for legal or business purposes.
Put those together and you get a genuine obligation to think. Keep too little and you cannot answer a question about an incident, and you may have destroyed something the Act said to keep. Keep everything forever and you are holding personal information long past the purpose it was gathered for, on a controller in an electrical room.
Now here is the part that should sting slightly: your retention period was set on install day, by default, by whoever configured the software. Maybe it is ninety days. Maybe it is until the database fills. Maybe there is no purge routine at all and the system has been accumulating since 2014. That was a decision with legal weight, made by a technician who was not asked to make it, and it has never been revisited.