Smart locks and video intercoms collect personal data — access logs, biometric templates, facial images. Under GDPR, property managers are data controllers for this data. Getting it wrong means fines up to 4% of annual turnover. This guide covers the key obligations and how to meet them with your access control infrastructure.

Is Access Log Data Personal Data?

Yes — in most deployment contexts. An access log recording "Card ID 00A4B7C2 opened Door 3B at 08:14:22 on 12 March 2026" is personal data under GDPR when the Card ID can be linked back to a named individual (a resident, employee, or guest). In most smart lock deployments, the credential-to-person mapping exists in the lock management system, so the log entries are personal data.

This triggers GDPR obligations: the property manager becomes the data controller; the lock manufacturer or cloud platform becomes the data processor. A Data Processing Agreement (DPA) must be in place between them before any personal data is processed.

The Five Key GDPR Obligations for Smart Lock Deployments

1. Legal Basis for Processing

You need a lawful basis to process access log data. For a workplace or rental property, legitimate interests (GDPR Article 6(1)(f)) is typically the appropriate basis — you have a legitimate security interest in knowing who accessed which area. For biometric data (fingerprint or face recognition), Article 9 applies — you need explicit consent from each individual, which must be freely given, specific, informed, and withdrawable without detriment.

2. Data Minimisation

Only collect what you need. If your security need is "was this door opened during a specific incident," a timestamped log with credential ID is sufficient — you don't need the full movement history of every resident every day. Configure your access control system to log the minimum events required. Avoid logging every door-open during normal operating hours if there is no security justification.

3. Storage Limitation (Retention Policy)

Access logs must not be kept longer than necessary. Most EU data protection authorities accept 30–90 days for general access logs in residential and commercial buildings. Security-incident investigation may justify up to 12 months. Biometric templates should be deleted immediately when the credential is revoked (e.g., when a resident moves out). Your lock management system must support automated retention/deletion policies.

4. Data Subject Rights

Residents and employees have the right to: access their access log data (right of access), request correction, request erasure (right to be forgotten), and object to processing. Your lock management system must allow you to export or delete records for a specific individual. Test this capability before deployment — not all cloud platforms make this easy.

5. Data Transfer outside the EU

If your smart lock uses a cloud platform with servers outside the EU (e.g., a Chinese cloud), access log data transferred to those servers is a third-country transfer under GDPR Chapter V. This requires appropriate safeguards — Standard Contractual Clauses (SCCs), or an adequacy decision for the destination country. Most Chinese cloud providers do not have EU adequacy decisions. The simplest solution: choose a lock system with an on-premise or EU-hosted backend.

Biometric Smart Locks: Special Category Data

Fingerprint and face recognition smart locks process biometric data, which is special category data under GDPR Article 9. This triggers heightened obligations:

  • Explicit informed consent required from each individual (not just a blanket clause in a tenancy agreement)
  • A Data Protection Impact Assessment (DPIA) is strongly recommended — and may be required by your national DPA
  • Biometric templates must be stored on-device when possible — not in a cloud database
  • Individuals must be able to use an alternative access method (PIN, RFID card) if they withdraw consent to biometric processing
Germany-specific: The German Federal Data Protection Commissioner (BfDI) and state-level DPAs have taken a strict position on biometric access in residential buildings. Several enforcement actions have been taken against landlords deploying fingerprint entry systems without adequate consent processes. German property managers should obtain specific legal advice before deploying biometric locks in MDU residential buildings.

On-Premise vs Cloud: GDPR Risk Comparison

The architectural choice — cloud-based lock management vs on-premise — has significant GDPR implications:

FactorCloud (Chinese server)Cloud (EU server)On-Premise
Third-country transfer riskHigh (SCCs required)NoneNone
DPA control over dataShared (manufacturer)Shared (EU provider)Full control
Data subject access requestsDepends on providerDepends on providerFull self-service
Retention policy enforcementDepends on platformDepends on platformFully configurable
IT complexityLowLowMedium

The Trudian CA-1000 Cloud Access Controller supports private cloud deployment (Docker/Kubernetes on your own infrastructure) — giving you EU-server or on-premise deployment with a modern cloud UI. This is the architecture we recommend for GDPR-sensitive deployments: co-working spaces, managed apartments, and any property with government or institutional tenants.

Practical GDPR Checklist for Smart Lock Deployment

  • ☐ Identify legal basis for access log processing (legitimate interests or consent)
  • ☐ If biometric: obtain explicit consent from each individual; provide non-biometric alternative
  • ☐ Sign a Data Processing Agreement (DPA) with your lock platform/cloud provider
  • ☐ Confirm data is stored in EU (or on-premise) — or implement SCCs for third-country transfers
  • ☐ Configure retention policy: max 30–90 days for standard logs; immediate deletion on credential revocation
  • ☐ Test data subject access request workflow: can you export or delete one individual's records?
  • ☐ Update your privacy notice to disclose access control data processing
  • ☐ If high-risk: conduct a DPIA before deployment
FAQ

Frequently Asked Questions: GDPR and Access Control for Property Managers

Yes, if the log entries can be linked to an identified or identifiable individual. A log entry recording "Apartment 4B door unlocked at 09:14 on 12 March" is personal data if the credential used (RFID card, PIN, fingerprint) is registered to a named resident. Anonymous logs recording only door events without credential identity are not personal data. Most smart lock systems that associate credentials with named users produce personal data in their access logs. Property managers must apply GDPR data minimization, retention limitation, and data subject rights obligations to access log data as a result.

For residential property managers, the most appropriate legal basis is legitimate interest (Article 6(1)(f)) — building security and access management is a legitimate interest that generally overrides residents' privacy interests when proportionate measures are applied. This requires a Legitimate Interest Assessment (LIA) documenting the purpose, necessity, and proportionality of the processing. Consent (Article 6(1)(a)) is an alternative but is problematic in tenancy contexts where the power imbalance between landlord and tenant means consent may not be freely given. Contractual necessity (Article 6(1)(b)) can apply where access control is explicitly included in the tenancy agreement.

GDPR's storage limitation principle (Article 5(1)(e)) requires retention only as long as necessary for the stated purpose. For access control logs in residential properties, 30–90 days is typical for general security monitoring purposes. Logs retained for dispute resolution (damage claims, unauthorized access incidents) may be kept longer if there is an active or reasonably anticipated dispute. Biometric templates must be deleted immediately when a resident moves out or revokes consent. Document your retention policy in your privacy notice and configure your access control system to automatically delete logs beyond the retention period — manual deletion processes are error-prone and non-compliant.

Residents have the right to access (Article 15) — they can request a copy of all access log entries linked to their credentials. Right to erasure (Article 17) — they can request deletion of their personal data, including access logs and biometric templates, subject to legitimate retention grounds. Right to rectification (Article 16) — correction of inaccurate data. Right to restriction (Article 18) — limiting processing during disputes. Property managers must be able to respond to subject access requests within 30 days. Verify your access control system can export and delete individual user data on demand — systems without per-user data export and deletion capability are non-compliant by design.

Yes, if resident personal data is transferred to servers in China without adequate safeguards. China is not an EU adequacy decision country, meaning transfers to Chinese cloud infrastructure require Standard Contractual Clauses (SCCs) under GDPR Article 46, supplemented by a transfer impact assessment (TIA) evaluating Chinese law's impact on data protection. In practice, many Tuya and TTLock-based smart lock systems route data through Chinese cloud infrastructure by default. Mitigations: specify EU-region cloud servers in your OEM contract (Tuya offers Frankfurt region), or use on-premise lock management software that keeps data within the EU. Audit your smart lock vendor's data flow before deployment.

A DPIA is mandatory under Article 35 when processing is likely to result in high risk to individuals. Biometric smart locks (fingerprint, face recognition) in residential buildings require a DPIA — biometric data processing is explicitly listed as high-risk processing in Article 35(3)(b). Non-biometric smart locks (RFID, PIN, app-based) in residential buildings are lower risk and may not require a full DPIA if the number of residents is small and data is retained briefly. However, completing a lightweight DPIA for any cloud-connected access control system is good practice and demonstrates accountability under Article 5(2). Consult your Data Protection Officer or a GDPR advisor before deploying any smart lock system in an EU residential building.

A GDPR-compliant privacy notice for smart lock deployments must include: identity and contact details of the data controller (property manager or management company), purposes and legal basis for processing access log data, categories of personal data collected (credential type, access timestamps, door locations), retention period or criteria for determining retention, details of any third-party data processors (cloud platform vendor, system integrator), information on data transfers outside the EU and safeguards applied, and residents' rights and how to exercise them. Deliver the privacy notice to residents before the system goes live — ideally as part of the tenancy agreement or a separate GDPR information letter. Post a visible notice at access control points informing visitors that access data is recorded.

Need a GDPR-Compliant Access Control System?

Trudian CA-1000 supports private cloud Docker deployment — your data stays in your infrastructure. TLS 1.3, AES-256, SAML 2.0 SSO. CE certified. Ask about EU-compliant deployment options.

Request Compliance Quote CA-1000 Specifications