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.

What to actually do this month

None of this requires a project. It requires four answers you probably do not have yet.

Find out what your retention period is right now. Open the access control software, or ask whoever maintains it, and get a number. Then ask why that number. If nobody can say, you have found the decision that was never made.

Set a retention period on purpose. Pick a duration you can justify by reference to what you actually use the logs for — incident review, dispute resolution, whatever it genuinely is — and confirm the system enforces it rather than merely displaying it. A configured purge that has never run is not a retention policy.

Write the notification and use it. Two or three sentences covering what is recorded, why, and how long it is kept. For employees this is what the notify duty is asking for; for everyone else carrying a credential it is simply the decent version of the same conversation, and it costs nothing to extend it to them. This is the cheapest item on the list and the one most likely to be missing entirely.

Treat the controller as a data store. Firmware version, network segment, administrator account list. If you have an IT provider, this box should be on their inventory. In many buildings it is on nobody's.

None of that is a compliance certificate, and we are not offering one. It is the difference between a system that quietly accumulates a record of named people's movements with nobody accountable for it, and one where somebody in the building can say what is collected, why it is kept, how long for, and who can reach it.

That is a reasonable thing to be able to say about a system that knows who was in the building at 02:14.

Sources

  • Personal Information Protection Act (SBC 2003, c. 63), s.13 — https://www.bclaws.gov.bc.ca/civix/document/id/complete/statreg/03063_01
  • Personal Information Protection Act (SBC 2003, c. 63), s.16 — https://www.bclaws.gov.bc.ca/civix/document/id/complete/statreg/03063_01
  • Personal Information Protection Act (SBC 2003, c. 63), s.19 — https://www.bclaws.gov.bc.ca/civix/document/id/complete/statreg/03063_01
  • Personal Information Protection Act (SBC 2003, c. 63), s.34 — https://www.bclaws.gov.bc.ca/civix/document/id/complete/statreg/03063_01
  • Personal Information Protection Act (SBC 2003, c. 63), s.35 — https://www.bclaws.gov.bc.ca/civix/document/id/complete/statreg/03063_01