Three weeks ago I was onsite at a storage facility in Alexandria, going through an access control upgrade with the site manager, when she asked me a question that stopped me for a second: “If something walked out of here tomorrow, who would actually go and look at the key log, and how?” She’d never had to find out. Most people haven’t. And that’s the problem, because the answer to that question usually gets worked out for the first time in the middle of an incident, which is the worst possible moment to be figuring out your own system.
The log exists, but nobody’s rehearsed reading it #
Electronic key logs sound simple on paper. Every tap of a fob, every PIN entry, every override gets timestamped and stored somewhere. In theory you’ve got a clean, defensible record of who was where and when. In practice, I’ve seen plenty of systems where the log is technically complete but functionally useless, because nobody at the site has ever had to extract it, filter it, or hand it to an investigator or a loss adjuster under pressure.
So when an incident actually happens, the first hour is usually spent not reading the log but finding out how to read it. Who has admin access to the software. Whether the export function still works after three firmware updates. Whether the person who set the system up five years ago is still contactable. That delay matters more than people think, because the value of a key log drops fast once you’re relying on someone’s memory of what they saw rather than the record itself.
Who actually pulls the log after something goes wrong #
In my experience it’s rarely the gallery director or collector who sits down and does this. It’s usually one of three people: the site’s security manager if there is one, the installer or monitoring company under a support contract, or, if police are involved, an investigator requesting a formal export. Insurers and their loss adjusters will ask for it too, though they’re relying on someone else to have already pulled it in a usable form.
This is where the gap between “we have a log” and “we have a usable log” opens up. A PDF export with fifteen thousand undifferentiated entries from every door on the site over six months isn’t evidence, it’s noise, and whoever’s reviewing it will want it filtered to the relevant door, the relevant time window, and cross-referenced against footage. If your access control platform can’t do that filtering natively, someone’s doing it by hand in a spreadsheet at 11pm, which is exactly what happened at one client site I worked with last year after a stock discrepancy in a consignment storage area.
What a usable log actually needs to contain #
A key log that survives scrutiny needs more than a timestamp and a name. It needs to record which credential was used, not just which person it’s registered to, because shared fobs and generic PINs are still common and they quietly wreck the evidentiary value of the whole system. It needs door-level granularity rather than zone-level, so you can tell the difference between someone entering the building and someone entering the specific room where the loss occurred. And it needs a record of failed attempts, not just successful ones, because a string of denied entries right before a successful one tells its own story.
None of this is exotic. It’s standard functionality on any decent access control platform, which is why I’d argue the real failure point usually isn’t the hardware, it’s configuration. Systems get installed correctly and then drift over time as staff turn over, generic codes get issued “just for now” and never removed, and nobody audits the credential list until there’s a reason to. If you’re weighing up what a proper system should even look like at the design stage, our page on access control covers the fundamentals worth getting right from day one.
Where the audit trail actually breaks down #
I’ll be honest, the weak point is almost never the software vendor’s fault. It’s retention settings. A lot of systems ship with a default log retention of somewhere between thirty and ninety days before older entries get overwritten to save storage. If nobody’s adjusted that, and an insurer or investigator comes asking about access from four months ago, the answer is simply that the data no longer exists. That’s not a conspiracy, it’s a default setting nobody thought to change.
The other common failure is treating the key log in isolation from CCTV. A timestamp saying someone entered a room at 2.14am is a fact. Whether that matches footage of who was actually holding the credential is a different fact, and the two need to line up for the log to mean much to anyone reviewing it after the event. We’ve written before about why most CCTV footage doesn’t actually help investigations after a break-in, and the same logic applies here, a system is only as good as its weakest linked component, not its best one. Worth a look if you haven’t already: CCTV that actually helps after a break-in.
Key logs versus general access control records #
People sometimes use these terms interchangeably and they’re not quite the same thing. A key log, in the strict sense, is the record tied to physical or electronic key use, whether that’s a mechanical key tracked through a key cabinet system or a credential logged through an electronic reader. Broader access control records can include things like door-forced alarms, tailgating detection, and system health logs that tell you whether the reader itself was even online at the time. If you’re only looking at one and not the other after an incident you’re missing half the picture, particularly in older buildings where wireless credential readers sometimes struggle with signal reliability against thick masonry, something we’ve covered in detail around why wireless sensors fail in old stone or brick gallery walls. A dropped reader that silently stops logging for twenty minutes is a gap in the record than most people never think to check for.
What insurers actually want to see, and what they don’t #
This is a point worth being precise about, because I still hear it repeated wrong at almost every site visit. An incomplete or missing key log does not automatically void an insurance claim. Under the Insurance Contracts Act 1984, specifically section 54, an insurer generally has to demonstrate that a failure to meet a security condition actually caused or contributed to the loss before they can rely on it to reduce or deny a claim. We’re not insurance brokers and this isn’t legal advice, it’s simply a point of law worth knowing before anyone panics about a gap in their logging. If you want a proper read on how security conditions and policy wording actually interact, our colleagues at Security & Your Policy go through it in more depth, and it’s genuinely worth a conversation with a broker who specialises in fine art cover, which is why we’ve also written on why a fine art insurance broker is worth finding early.
What insurers and adjusters do want, practically, is a log that’s contemporaneous, unedited, and cross-referenced. They’re less interested in whether your system is expensive and more interested in whether the record is credible. A cheap system with disciplined retention and clean credential management will hold up better under review than an expensive one nobody’s maintained.
Getting the log right before you ever need it #
The uncomfortable truth is that nobody checks their key logs properly until they have to, and by than the retention window may already have quietly closed. So my advice to every client, and it’s a genuinely simple ask, is to do a dry run. Pick a random door, pick a random week, and try to extract a clean, filtered, exportable record of who accessed it and when. Time how long it takes and note every point where you got stuck. That exercise, done once a year, tells you more about your actual security posture than any brochure ever will.
ASIAL’s published guidance for the security industry touches on this kind of operational discipline, and it’s worth a browse if you’re benchmarking your own site against what a properly maintained system should look like (asial.com.au). Standards Australia also maintains the broader framework installers work to when specifying access control hardware, which is a useful reference if you’re scoping an upgrade (standards.org.au). If your access setup was bolted onto an older building and you’re not confident it was specified properly in the first place, it’s also worth reading our piece on retrofitting a strongroom into an existing building, since the same retrofit issues that affect physical security often affect the electronics sitting on top of it.
None of this needs to be complicated. It just needs someone to have actually tried it once, before the day it matters.
– Priya Chandran, Security Systems Editor