A smart lock is also a logbook. Each entry can record which credential opened the door, when, by what method, and whether it was accepted or refused. That record is exactly what makes the lock useful for managing access — and it is worth knowing where the record sits, who can reach it, and what it reveals before you put one on a door where people live or stay.
What a lock can record
The typical event captures more than "the door opened." A complete entry holds the identifier of the credential used, a timestamp, the method (passcode, card, fingerprint, app), and the outcome, including denied attempts. If the lock is wired to a door sensor, it may also store open and close times and how long the door stood open. Management actions sit alongside user events: who enrolled or revoked a credential, and when, is usually logged too, because the whole point of per-person credentials is being able to trace a change back to a person.
Not every lock records all of this, and that is the first thing worth checking. Some keep only the last handful of events locally; others forward every event to a platform that retains years.
Where the data lives
The storage location matters as much as the content, because it determines who can reach the record and how.
On a purely offline lock, events live inside the lock and only leave it when someone connects — usually over Bluetooth — and pulls them down. A lock that is not connected to anything cannot be breached over the internet, and its log cannot be read remotely. The trade-offs of that isolation are part of why offline and cloud designs behave so differently on security as well as convenience.
A gateway-bridged lock sends events through a gateway to a cloud platform, which is usually where the richest store builds up: every door, every credential, months or years of history, behind the account you log into. The cloud is what makes remote management and audit possible at scale, and it is also the place the most data accumulates.
Who can actually see it
Several parties can reach the record, under very different conditions.
The account owner or property manager sees the full picture. Staff and sub-users see whatever their role grants, which is why role-based access matters — a front-desk user should not necessarily read every door's complete history. The platform vendor that operates the cloud has technical access to the data, bounded by their published policy and by the law of the jurisdictions involved. Law enforcement can compel records through lawful process. And anyone who compromises the account — through a reused password or a missing second factor — reads the log as if they were the owner. This last path is why strong authentication on the managing account is a privacy control, not just a security one, and it is covered directly in the access control security best practices.
What to check before you trust a lock with the data
A short list of questions separates a thoughtful deployment from a careless one. Does the platform publish how long it keeps logs, and can you export and delete them? Is traffic encrypted end to end, including the hop from gateway to cloud, and how are the credentials themselves stored? Does the system give you role-based access, so a staff member sees only the doors they manage? In a rental or hospitality setting, entry logs reveal occupancy patterns — when a guest is in, when they are out — so guests should be informed, and deletion requests honoured. Per-stay codes, like the ones in temporary access codes for guests, help here because they tie a credential to a booking rather than to a person's long-term pattern.
Reducing what you store
The most reliable privacy measure is collecting less in the first place. Shorten the retention window wherever the platform allows it. Prefer per-person credentials over shared codes, because revocable per-person access needs fewer blanket logs to be useful. And match the granularity of what you collect to what you actually need: a door that must prove who entered, for compliance reasons, justifies a detailed log; a utility cupboard does not.
Privacy and security pull the same direction here
There is a temptation to frame privacy and security as opposing pressures — one wanting more logging, the other less. On a door they mostly agree. Strong authentication protects privacy by keeping the log out of the wrong hands. Encrypted transport protects both. Thoughtful retention protects both. The failure classes that expose a lock, catalogued in smart lock vulnerabilities, are largely the same ones that would expose the data the lock holds.
| Where the record lives | Who can read it | Remote reach |
|---|---|---|
| Inside the lock (offline) | Whoever physically connects | None while disconnected |
| On the gateway (buffered) | Gateway / account owner | Only through the gateway |
| Cloud platform | Owner, roles, vendor, lawful process | Yes, behind the account |
A lock that logs who came and went is doing its job; the part to manage deliberately is where those logs end up and who holds the key to them. The mechanics underneath — how a credential becomes a logged event — are in how smart locks work, and how that record feeds a booking or property system is where integration questions begin.