There is a table inside your access control system that almost nobody has opened since the day the system was commissioned. It is small — a list of dates, maybe a dozen rows. It has more authority than anything else in the schedule configuration, because its entire job is to overrule the rest of it.
It is the holiday table. And in our experience, when a building is behaving strangely on a day the building is closed, this is where the explanation lives.
What the holiday table is, and what it overrides
To see why this table matters, it helps to remember that access is not a property of a person. It is a property of a person, at a door, at a time. The time half of that is configured as schedules: named bands like "Business hours" or "Cleaning crew", attached to groups of people and groups of doors. A schedule is where the system is told that this credential works at this reader between these hours on these days of the week.
Days of the week is the important phrase. A schedule thinks in weekdays. It knows Tuesday. It does not know that this particular Tuesday is a statutory holiday and the building is dark.
That is what the holiday table is for. It is a separate list of specific calendar dates, and it carries a rule roughly of the form: on a date in this list, do not follow the weekday schedule — follow the holiday behaviour instead. Depending on the manufacturer this appears as holiday types, holiday groups, or a special-day exception band, but the concept is identical across every platform we work with. It is an override layer sitting on top of the normal week, and it exists precisely because the normal week is wrong on those days.
So the holiday table is not a nicety. It is the only mechanism the system has for knowing that a day is different. Take it away and the building has no concept of a closed day at all.
Two ways the table goes wrong, and both are silent
The table was almost certainly populated once, during commissioning, by the integrator who installed the system. That was the correct thing to do. The problem is what happens next, which is nothing.
The first failure is the moving date. Some statutory holidays fall on a fixed calendar date every year. Others are defined by a rule — a particular weekday of a particular month — so the actual date shifts from one year to the next. A holiday table does not store the rule. It stores the date. The integrator typed in the dates for the year the system went live, and those dates were right, once.
Every year after that, the moving ones are wrong. Not missing — wrong, which is worse. The table now names a date that is an ordinary working day, and it does not name the date that is actually the holiday. So the system applies holiday behaviour to a normal Tuesday when everyone is at work, and applies the ordinary weekday schedule to the day nobody is there.
The second failure is the expired table. Entries were loaded for one year, or two, or five. Then the list runs out. From that point every statutory holiday is, as far as the system is concerned, an unremarkable weekday. The override layer is still there, still enabled, still configured correctly in every respect except that it contains no rows that will ever match again.
Both failures share the property that makes them dangerous: the system does not consider either one to be an error. There is no fault, no supervision signal, no trouble light, no entry in the event log saying the holiday table has expired. The configuration is valid. The dates are legitimate dates. The system is doing exactly what it was told, and what it was told is stale. A monitoring platform can tell you a reader has stopped answering. Nothing tells you a table has stopped being true.
The day nobody is there
Follow the second failure through to what it actually produces on the ground.
The building is closed for a statutory holiday. Nobody is in it. The system, unaware that this day is different, runs the ordinary weekday programme it runs every week. That programme was written for a working day, so:
- Doors on an unlock schedule unlock themselves at the usual morning hour and stay unlocked until the usual evening hour.
- The intrusion alarm, if it is scheduled to disarm with the building's opening, disarms.
- Access levels that are meant to be live only during business hours become live — including for people whose access was scoped to working hours specifically because nobody wanted them in the building at other times.
- Cleaning, contractor, and delivery permissions all switch on for a day when none of those things are happening.
The building spends the entire day open, unarmed, and — this is the part that matters — unwatched. Every other day of the year, the compensating control for an unlocked front door is that there are people behind it. Reception is staffed. Somebody would notice a stranger walking through. On a statutory holiday that control is gone, and it is gone at exactly the moment the door decides to behave as though it were not.
That is the shape of the risk. Not a lock that fails. A lock that opens on schedule into an empty building, and does it for eight hours, and generates no alarm because it was told to.
Why auto-unlock makes it compound
If the building uses automatic unlock schedules, the two problems multiply rather than add.
A door on an unlock schedule is not an access-controlled door during those hours. It is an open door with a card reader on it. That is a deliberate and often correct decision for a lobby during trading hours, and we have written separately about what an unlock schedule really commits you to. The whole justification for it is that the door is unlocked only while the building is staffed and the reception desk is doing the work the lock is not.
A stale holiday table breaks precisely that justification, and only that one. It does not affect the doors that stay locked all the time — a card is still required, so the day being wrong changes very little. It lands its full weight on the doors whose safety argument depends on the building being occupied, on the one day in the year the building definitely is not.
There is a second-order version of this too. When the holiday table has moving dates that are wrong rather than missing, the system also applies holiday behaviour on a working day. The visible symptom is the opposite one: the front door does not unlock in the morning, staff queue outside, someone calls the integrator, and it gets fixed as a nuisance call. That version gets reported within ten minutes because it inconveniences people. The version that leaves the building open on a holiday inconveniences nobody, so it is never reported and can persist for years.
The failures that inconvenience people get fixed. The failures that only create risk do not. That asymmetry is the reason this item survives in buildings that are otherwise well run.
The most reliable annual maintenance item nobody owns
Most maintenance obligations in this field are conditional. Whether a particular door needs a particular test depends on what it is, where it sits, and what the code requires of it — genuinely a question for someone accountable for that opinion, which is why testing egress doors is its own subject with its own difficulties.
The holiday table is not like that. It is unconditional, it is identical in every building, it is knowable a year in advance, it takes minutes, it costs nothing, and it comes around on a perfectly predictable cycle. There is no judgment call and no trade to schedule.
And it is almost never assigned to anyone. The reason is structural rather than negligent. The integrator populated the table as part of commissioning, which makes it look like installation work rather than recurring work. The system administrator inherited a system that already had holidays in it and had no reason to think about them again. The property manager who took over three years later has never heard of the table. Nobody agreed not to do this. Nobody was ever asked to.
It also fails the ordinary detection routes. It is not a hardware fault, so it does not show up in a service visit. It is not a life-safety item, so it is not on an inspection schedule. It produces no alarms, so it is invisible to monitoring. Reviewing schedules on a working day looks entirely healthy, because on a working day it is.
The fix, and how to verify it
Four requirements, all of them boring.
A named person. Not a role, not a department, not "the property manager" as a concept — a person, with the task on their own calendar and a named backup. If this belongs to whoever happens to be looking after the system, it belongs to nobody.
An annual recurrence, done in advance. Set the reminder for late in the calendar year, before the next year begins, and load the whole of the coming year in one sitting. Doing it in advance is what turns this from a reaction into maintenance. Load two years if the platform allows it — but if you do, keep the annual reminder anyway, because a two-year load with no reminder is just a slower version of the same failure.
Every affected list, not just the dates. Adding dates is only half the job. Confirm that each holiday date is attached to the right holiday group or type, and that every schedule which should respect it actually references that group. A holiday entry that no schedule consults is a row in a table doing nothing. Include every system with an independent calendar — access control, intrusion, and any building automation that drives lighting or HVAC on the same assumption about which days are working days.
Verification by looking, not by asking. This is the part that gets skipped, and it is the only part that produces evidence. "Did someone update the holidays?" is not verification. It is a question about a person's memory, and the answer is yes almost regardless of the truth.
Verification means opening the system and reading the table: the dates for the coming year are present, each is mapped to the intended holiday behaviour, and the schedules that matter reference it. Then take one door that unlocks automatically, pick one holiday date, and confirm in the software what that door will do on that date. If your platform can simulate or report a door's state for a future date, use it. If it cannot, read the schedule and the override together and work it out on paper.
Record the result — date checked, who checked it, what the coming year contains. Next year's owner will not remember, and may not be the same person.
The one question to ask this week
Open your access control software and find the holiday calendar. Read the last date in it.
If that date is in the past, your building has been treating every statutory holiday since as an ordinary working day, and whatever your doors do on an ordinary working day is what they have been doing. If the last date is in the future, check whether the moving holidays in the coming year are on the dates they will actually fall on.
That is the whole audit. It takes a few minutes, it needs no vendor, and it is the highest return per minute of any maintenance task in this field.
