Every time a resident taps a fob, the building learns something about them. Multiply that by hundreds of residents and thousands of entries a month and a residential block is quietly running one of the most detailed personal-data sets in its operation. UK GDPR has always applied to that data; what has changed is how seriously regulators, leaseholders and insurers now expect property managers to treat it.
Why audit trails are personal data
An entry log that says “Flat 12B, fob 0042, 23:14, north lobby reader” is personal data the moment it can be linked to a named resident — which, in any managed block, it always can. According to the Information Commissioner’s Office, pseudonymised data still falls within UK GDPR if the controller holds the key. The fob register is that key.
That has practical consequences. Residents have rights over the data, the controller must have a lawful basis to hold it, and the building’s access control systems need to support export, deletion and rectification — not just unlocking doors. An audit trail is a security feature and a data-protection liability at the same time, and the policy has to treat it as both.
Lawful basis: getting the foundation right
The most common mistake property managers make is defaulting to consent. Consent is the weakest lawful basis for routine building security because it can be withdrawn at any time, and you cannot run a secure building where some residents have opted out of being logged. Legitimate interest, properly assessed, is almost always the better foundation.
According to ICO guidance on lawful basis, legitimate interest requires a three-part test: a genuine purpose, necessity of the processing, and a balancing exercise against resident rights. Building security passes all three for entry logs, provided the data is minimised and retention is proportionate. Contract is a useful secondary basis where access is a condition of the tenancy or lease.
| Lawful basis | When it fits | When it doesn’t |
|---|---|---|
| Legitimate interest | Routine entry logs, audit trails | Marketing, profiling, sharing externally |
| Contract | Access tied to tenancy terms | Visitors, guests, contractors |
| Legal obligation | Statutory requests (police, courts) | General building management |
| Consent | One-off optional services | Core security operations |
| Vital interests | Emergencies, life-safety events | Routine processing |
Consent is rarely the right basis for residential access control, and labelling it as such on the privacy notice usually creates more problems than it solves.
Retention periods that actually hold up
Indefinite retention is the default setting on too many access control platforms, and it is indefensible under UK GDPR. The principle is storage limitation: keep data no longer than necessary for the purpose. For residential entry logs, “necessary” is usually measured in months, not years.
According to the British Security Industry Association, most residential schemes settle on 30–90 days for routine entry data, extended only where an incident is under active investigation. That matches the typical CCTV retention period and gives the building a coherent story when a subject access request arrives.
| Data category | Suggested retention | Trigger to extend |
|---|---|---|
| Routine entry events | 30–90 days | Live incident investigation |
| Failed access attempts | 90 days | Pattern suggesting tailgating |
| Credential issue / revocation | 24 months | Dispute or litigation hold |
| Visitor logs | 90 days | Specific incident |
| Subject access correspondence | 3 years | Regulatory complaint open |
The retention schedule has to be written down, applied automatically by the platform where possible, and reviewed annually. A retention policy that lives only in a Word document on someone’s laptop is not a policy.
Subject access requests and what residents can ask for
A resident can ask for a copy of every entry log that relates to them. They can ask for it to be corrected if it is wrong, and they can ask for it to be deleted if the legitimate interest no longer applies. According to the ICO’s right of access guidance, controllers have one calendar month to respond, extendable by two further months for complex requests.
The practical challenge is extraction. A modern cloud access control platform should let a property manager filter by credential ID and export a clean CSV of entries within minutes. Older on-premises systems often cannot, and the gap shows up the moment a SAR arrives.
A workable SAR workflow:
- Log the request with a timestamp and acknowledge within 72 hours.
- Verify the requester’s identity (tenancy reference plus photo ID).
- Extract entry data for the credential(s) linked to the resident.
- Redact third-party data (other residents’ fob IDs visible on shared logs).
- Deliver via secure channel within 30 days.
Cloud platforms and processor obligations
When a building runs access control in the cloud, the platform vendor is almost always a data processor and the managing agent (or freeholder) is the controller. That distinction matters because it dictates who is responsible for what under UK GDPR.
According to ICO guidance on controllers and processors, the controller must have a written contract with each processor covering the subject matter of the processing, retention, security measures, sub-processor approvals and breach notification timelines. A standard SaaS terms-of-service page is not usually enough.
Things to check on any cloud access control contract:
- Data residency: where servers and backups sit (UK or EEA preferred).
- Sub-processors: named, with notification of changes.
- Security: ISO 27001 or equivalent third-party assurance.
- Breach notification: contractual SLA of 24–72 hours.
- Exit terms: data return and deletion on contract end.
Security, breaches and incident response
A lost laptop with an exported entry log is a notifiable breach. A misconfigured cloud bucket exposing fob IDs and flat numbers is a notifiable breach. According to the ICO’s breach reporting guidance, controllers must notify the regulator within 72 hours where the breach is likely to result in a risk to individuals’ rights and freedoms.
The mitigation is boring but effective: role-based access to the management platform, mandatory two-factor authentication for staff accounts, encrypted exports, and a written incident-response plan that names the person who picks up the phone at 9pm on a Sunday. A documented incident-response plan is the difference between a managed event and a regulatory finding.
FAQs
Do we need consent from residents to keep entry logs? No. Legitimate interest is the appropriate lawful basis for routine residential entry logs, supported by contract where access is a tenancy condition. Consent is generally the wrong basis because it can be withdrawn.
How long can we keep access control data? There is no fixed period in law. The UK GDPR storage-limitation principle requires data to be kept no longer than necessary. Most residential schemes use 30–90 days for routine entry logs and longer for credential records.
Can a resident ask to see every time they used their fob? Yes. Under the right of access, residents can request a copy of all personal data held about them, including entry logs. The controller has one calendar month to respond, with extensions possible for complex requests.
Is a cloud access control platform a data processor? In most cases yes — the property manager or freeholder is the controller, and the platform vendor is the processor. A written contract under Article 28 of UK GDPR is required.
What counts as a notifiable data breach? Any incident where personal data is lost, exposed or accessed without authorisation, and where there is a likely risk to residents’ rights and freedoms. Notification to the ICO must happen within 72 hours of becoming aware.
