GDPR for PropTech Companies: Tenant Data, Smart Building Systems, and Property Platform Compliance
PropTech platforms hold tenant profiles, credit data, access logs, and smart building sensor data. Here's how to handle it all under GDPR.
Date: March 27, 2026
Read time: 9 min read
Tags: GDPR, PropTech, Real Estate
Why PropTech Is a Fast-Growing GDPR Risk Sector
Property technology sits at the intersection of two sectors that have historically been slow to take data protection seriously: real estate and construction. That combination, plus the rapid adoption of cloud-based landlord platforms, smart building IoT, and automated tenant referencing, has created a sector with significant GDPR exposure and regulatory attention increasing fast.
PropTech companies process personal data at scale. A mid-sized rental platform may hold profiles on tens of thousands of tenants. A smart building operator may collect real-time sensor data from hundreds of residents. A referencing platform may process credit, financial, and identity data on every applicant in the country. The ICO has been clear that the property sector is on its radar — and regulators across the EU have already begun investigating PropTech operators.
The legal landscape is also unusually complex for PropTech. Tenancy law, credit regulation, right to rent requirements, and landlord-tenant duties all create data retention obligations that sit alongside — and sometimes in tension with — GDPR's storage limitation principle. Getting this right requires understanding both frameworks.
Types of Data PropTech Platforms Hold
Before you can comply, you need to know what you hold. PropTech platforms typically process several distinct categories of personal data:
Tenant application data: Names, addresses, dates of birth, employment details, income information, bank statements, proof of identity documents (passports, driving licences), rental history, previous landlord references.
Credit reference data: Credit scores, county court judgements, bankruptcy records, affordability assessments. This data is typically obtained via credit reference agencies (CRAs) such as Experian, Equifax, or TransUnion.
Tenancy data: Tenancy agreement terms, rent payment records, deposit details, repair requests, correspondence between landlord and tenant.
Right to rent documentation: Copies of passports, visas, biometric residence permits, and other immigration documents required under the UK's right to rent scheme.
Smart building data: Access fob logs, CCTV footage, occupancy sensor readings, energy consumption data tied to individual units, smart lock entry and exit logs.
Maintenance and contractor data: Repair request details, access arrangements, contractor attendance records, inspection reports.
Each of these categories carries different lawful bases, retention obligations, and subject rights implications. Treating them all as a single undifferentiated blob of "tenant data" is a compliance failure.
Lawful Bases for Tenant Data Processing
Most PropTech platforms rely on a mixture of lawful bases under Article 6 GDPR. Getting this right matters because the lawful basis determines what rights the data subject has and what you can do with the data.
Contract (Article 6(1)(b)): Processing necessary for the performance of a contract, or steps prior to entering into a contract. This covers processing tenant application data to assess a prospective tenancy, and ongoing tenancy data to manage the landlord-tenant relationship.
Legal obligation (Article 6(1)(c)): Processing required by law. Right to rent checks are a legal requirement under the Immigration Act 2014. Certain record-keeping obligations fall here.
Legitimate interests (Article 6(1)(f)): Processing where the platform or a third party has a legitimate interest that is not overridden by the data subject's rights. Fraud prevention across a tenancy platform may fall here, but it requires a legitimate interests assessment (LIA) — you cannot simply assert legitimate interests without documenting the balancing test.
Consent (Article 6(1)(a)): Required for processing that goes beyond the other lawful bases. Sending marketing emails to previous tenants, sharing data with third parties for their own commercial purposes, or using tenant data to build risk scoring models all typically require consent.
Note: financial data and immigration documents may also require a UK GDPR Schedule 1 condition for special category processing in certain contexts. Seek legal advice on the specific circumstances.
Credit Reference Agency Data and Lawful Basis
Credit checks are one of the highest-risk processing activities for PropTech platforms. Credit reference data is processed under the legitimate interests lawful basis in most cases — the landlord has a legitimate interest in assessing a prospective tenant's financial reliability, and the tenant has a reasonable expectation that a credit check will be conducted as part of a rental application.
However, legitimate interests is not a free pass. You must:
- Conduct and document a Legitimate Interests Assessment (LIA)
- Inform applicants clearly that a credit check will be conducted and with which CRA
- Not use credit data for any purpose beyond the specific tenancy assessment
- Delete credit reference data after the purpose is fulfilled — either the tenancy begins, or the application is declined
A common mistake is retaining credit check data indefinitely "in case the applicant reapplies." This is a storage limitation violation. Credit data should be deleted within a reasonable period after the application process concludes — typically 30 to 90 days, unless the applicant becomes a tenant and the data is needed for ongoing tenancy management.
Right to Rent Checks and Document Retention
Right to rent checks require landlords (and by extension, platforms that conduct checks on their behalf) to inspect and retain copies of immigration documents. This creates a specific tension with GDPR.
The Home Office prescribes which documents must be checked and that follow-up checks must be conducted for time-limited permissions. The lawful basis for this processing is legal obligation under Article 6(1)(c).
However, the Home Office guidance does not require indefinite retention. The statutory requirement is to retain documents for the duration of the tenancy plus one year. Retaining right to rent documents beyond this period is a GDPR violation — the legal obligation that justified the processing no longer applies.
Practical steps:
- Document your right to rent check procedure in your Records of Processing Activities (ROPA)
- Set automated deletion or review triggers linked to tenancy end dates
- Ensure that copies of passports and biometric documents are stored securely and access-controlled — these are high-value targets in a data breach
Tenancy Agreement Data vs Application Data: Retention Periods
Not all tenant data has the same retention lifecycle. Treating all data from an application as having the same retention period is one of the most common compliance failures in PropTech.
Application data for unsuccessful applicants: Should be deleted within a reasonable period after the application is declined. 30 to 60 days is appropriate for most platforms. There is no ongoing purpose that justifies long-term retention.
Application data for tenants: Retained for the duration of the tenancy and for a reasonable period afterward to manage end-of-tenancy disputes, deposit returns, and references. 3 to 6 years post-tenancy is defensible for some records given the limitation period for contract disputes; shorter periods are appropriate for data that isn't relevant to potential disputes.
Tenancy agreement data: As a legal contract, the tenancy agreement may be retained for the duration of any applicable limitation period — typically 6 years (12 years for deeds). However, personal data within the agreement (such as tenant dates of birth or bank details) should be considered separately and may not require retention for the full limitation period.
Document your retention schedule per data category and per processing purpose. A blanket "we keep everything for 7 years" policy does not comply with GDPR's storage limitation principle.
Landlord Platforms: Controller or Processor?
This question needs careful analysis and most PropTech operators get it wrong. The answer depends on the specific platform model.
Pure marketplace platforms (connecting landlords and tenants, with the landlord managing the relationship) are typically data processors for tenant data processed on behalf of the landlord, and data controllers for their own user account and marketing data.
Full management platforms (where the platform makes decisions about how tenant data is used, which CRAs to query, how referencing is conducted) may be data controllers in their own right for some or all of that processing.
Mixed platforms are common — controller for some activities, processor for others.
Why does this matter? Because if you're a data processor, you need a Data Processing Agreement (DPA) with every landlord who uses your platform. You can only process data on documented instructions from the controller (the landlord). You cannot use tenant data for your own analytics, product development, or commercial purposes without the controller's authorisation.
Many PropTech platforms operate as de facto controllers (making independent decisions about referencing processes, data sharing with third parties, retention periods) while claiming to be processors and neglecting to document any of it.
Sharing Tenant Data with Landlords
When a PropTech platform shares tenant data with a landlord, the following questions must be answered:
What is the lawful basis for the share? If the platform is a processor acting on the landlord's instructions, the landlord is the controller and the basis exists at their level. If the platform is a controller, it needs its own lawful basis for the disclosure.
Has the tenant been informed? The privacy notice presented to tenants during the application process must clearly describe who their data will be shared with and for what purpose.
Is the data proportionate? Sharing all application data with every landlord who enquires about a property before an application is accepted is unlikely to be proportionate. Staged disclosure — summary information first, detailed application data only once a tenancy offer is made — is better practice.
Can the data be used by the landlord for other purposes? No. A landlord cannot use data provided by your platform to market other services, share with third parties, or use beyond the tenancy management purpose. Your DPA with the landlord should make this explicit.
Maintenance Requests and Contractors as Processors
When a tenant submits a maintenance request, personal data is created: the tenant's identity, their unit, the nature of the problem, their availability, and potentially sensitive information about their home or personal circumstances.
When that request is routed to a third-party contractor, the contractor becomes a data processor (assuming they process the data on instructions from your platform or the landlord). This means:
- A Data Processing Agreement must be in place with every contractor who receives tenant data
- Contractors must not use tenant data for any purpose beyond completing the repair
- Personal data shared with contractors (including access arrangements, phone numbers, and home details) should be the minimum necessary for the task
- Tenant data shared with contractors should be deleted after the job is complete
This is operationally inconvenient, but it is a legal requirement. A contractor who misuses tenant data — whether for marketing, identity fraud, or simply retaining it inappropriately — creates liability for the platform that shared it without adequate contractual protections.
Smart Lock and Keyless Entry Systems: Access Logs as Personal Data
Smart building technology is where PropTech's GDPR obligations become most technically complex.
Access logs from keyless entry systems — recording when a specific fob, card, or phone unlocked a specific door — are personal data. They reveal the movements of identified individuals within and around a property. Aggregated over time, they can reveal detailed behavioural patterns: working hours, overnight absences, visitor habits.
CCTV footage is personal data. Occupancy sensors that track whether a specific unit is occupied can constitute personal data when linked to an identified resident. Energy monitoring data at the individual unit level is personal data when it can reveal information about occupancy and behaviour.
For smart building data, consider:
Lawful basis: Legitimate interests is the most commonly used basis for building access systems, but requires an LIA. Security and property protection are likely to pass the balancing test; commercial exploitation of movement data is not.
Data minimisation: Do you need to retain individual access log entries, or would aggregate counts (number of entries per day) serve the security purpose? Where individual-level data isn't necessary for the purpose, use aggregate data.
Retention: Access logs for security purposes do not need indefinite retention. 30 to 90 days is appropriate for most access log data. CCTV footage is typically retained for 31 days under ICO guidance for non-high-risk environments.
Transparency: Residents must be informed about smart building data collection in your privacy notice. Signage is required for CCTV under GDPR.
Referencing Platforms and Data Sharing
Referencing platforms such as HomeLet, Canopy, and OpenRent occupy a particular position in the PropTech data supply chain. They collect personal, financial, and identity data from tenants and provide referencing reports to landlords.
Under GDPR, referencing platforms are typically data controllers — they determine the purposes and means of processing applicant data. This means:
- They must provide applicants with a compliant privacy notice at the point of data collection
- Applicants have the right to access their referencing data (Article 15 DSAR)
- Inaccurate referencing data must be corrected (Article 16 right to rectification)
- Applicants may challenge automated referencing decisions (Article 22, where decisions are based solely on automated processing including profiling)
- Data sharing with landlords must be documented and lawful
Where a PropTech platform integrates with a referencing provider, the data sharing between them must be governed by appropriate contractual arrangements, and each party's role as controller or processor must be clearly established.
DSARs from Tenants: What Records You Must Produce
Tenants are increasingly aware of their GDPR rights, and subject access requests in the property sector are becoming more common — particularly in dispute contexts (deposit deductions, eviction proceedings, discrimination claims).
A compliant DSAR response from a PropTech platform must include:
- The tenant's personal data held in your system (all fields, not just a summary)
- Any referencing or credit data you hold or have received
- Correspondence relating to the tenant
- Access logs relating to the tenant (smart building systems)
- Any notes or annotations made by landlords or platform staff about the tenant
- Details of who the tenant's data has been shared with and on what basis
- The retention period applicable to the data
DSARs must be responded to within 30 days. In complex cases, a one-month extension is available if you notify the requester within the initial 30-day period.
A DSAR in a dispute context may be used as evidence in subsequent legal proceedings. Incomplete or misleading DSAR responses create significant legal risk beyond the GDPR compliance issue.
10 Common GDPR Mistakes PropTech Companies Make
No DPA with landlord customers. Operating as a processor without a compliant Article 28 DPA in place with each landlord is one of the most common and most easily remedied gaps.
Credit check data retained after application conclusion. Holding credit reference data for unsuccessful applicants indefinitely, or carrying it forward without a documented purpose.
Right to rent documents retained beyond the statutory period. Keeping copies of passports and visas after the tenancy has ended plus one year.
Smart building data retained without a policy. Access logs and CCTV footage accumulated with no defined retention period or deletion process.
Controller/processor status not documented. No analysis of which processing activities make the platform a controller vs a processor, with consequent gaps in DPAs and privacy notices.
Privacy notices that don't disclose data sharing with landlords and referencing platforms. Tenants are not informed at the point of data collection who their data will be shared with.
No LIA for legitimate interests processing. Using legitimate interests as a lawful basis without conducting or documenting the required balancing test.
Contractors receiving tenant data without DPAs. Maintenance contractors and other third parties receiving personal data without contractual data processing protections.
DSAR process not covering all data stores. Responding to DSARs from the main application database but missing access logs, email correspondence, CRM notes, and third-party referencing data.
No data retention schedule. Applying a single blanket retention period to all tenant data regardless of the processing purpose or data category.
Check Your PropTech Platform's Compliance Baseline
The starting point for any PropTech GDPR programme is understanding what your platform is actually collecting and sharing. Custodia's free website scanner identifies trackers, third-party data connections, and missing consent mechanisms — the front-end compliance layer that regulators check first.
Last updated: March 2026
Top comments (0)