uselatch

Subscriber Data Policy

How Latch handles data on behalf of paid subscribers. This policy supplements our Privacy Policy and outlines our obligations as a data processor.

Last updated: 5 May 2026

1. Introduction

This Subscriber Data Policy (“Data Policy”) describes how USELATCH LTD (trading as “Latch”, company number SC879051, registered in Scotland) processes personal data on behalf of subscribers to our paid plans (Pro and Enterprise). This policy supplements our Privacy Policy and should be read in conjunction with our Terms of Use and Subscriber Terms.

  • Where a subscriber (landlord or property manager) inputs personal data relating to their tenants, contractors, or other third parties into the Latch platform, the subscriber acts as the data controller for that data.
  • Latch acts as the data processor, processing such data on behalf of and under the instructions of the subscriber.
  • This policy sets out the terms upon which Latch processes subscriber data, in compliance with Article 28 of the UK General Data Protection Regulation (UK GDPR) and the Data Protection Act 2018.

2. Definitions

  • “Subscriber Data” means any personal data that a subscriber inputs, uploads, or transmits to the Latch platform relating to their tenants, contractors, suppliers, or other third parties.
  • “Data Controller” means the subscriber who determines the purposes and means of processing Subscriber Data.
  • “Data Processor” means USELATCH LTD, which processes Subscriber Data on behalf of the Data Controller.
  • “Sub-processor” means any third-party service provider engaged by Latch to assist in the processing of Subscriber Data, as listed on our List of Subprocessors page.
  • “UK GDPR” means the UK General Data Protection Regulation, as retained and adapted by the Data Protection, Privacy and Electronic Communications (Amendments etc) (EU Exit) Regulations 2019.

3. Types of Data Processed

Latch processes the following categories of Subscriber Data on behalf of data controllers:

Tenant Personal Data

Names, email addresses, phone numbers, instant messaging handles, company names, contact types (tenant, contractor, supplier, agent), and preferred contact methods.

Property Records

Property addresses, unit details, valuations, mortgage information, compliance certificates, property notes, tags, and inventory records.

Lease and Tenancy Data

Lease start and end dates, monthly rent amounts, deposit amounts, payment schedules, lease status, and special terms.

Financial Records

Payment amounts, types, methods, transaction references, outstanding balances, expense records, receipt uploads, and VAT calculations.

Document Data

Uploaded files, document metadata, AI-generated summaries, extracted data points, and file names.

Communication Data

Direct messages between landlords and tenants, viewing scheduling data, pre-screening questions and responses, and maintenance ticket details.

WhatsApp Communication Data

Where subscribers enable WhatsApp messaging: tenant phone numbers, WhatsApp message content (rent reminders, payment confirmations, and other landlord-tenant communications), Twilio message SIDs, delivery status records (queued, sent, delivered, read, failed), and tenant opt-in/opt-out consent records.

Invoice Data

Invoice details including invoice numbers, line items, amounts, VAT calculations, payment terms, due dates, payment status, recipient details (tenant name, email, property reference), generated PDF documents, and view tokens for unauthenticated invoice access by recipients.

HMRC Tax Data (MTD Integration)

Where subscribers enable the HMRC Making Tax Digital integration: encrypted National Insurance Numbers (NINOs), encrypted Unique Tax References (UTRs), HMRC Business IDs, OAuth authorisation tokens (encrypted), aggregated rental income and expense data compiled for HMRC submissions, HMRC submission records (including submission IDs, correlation IDs, obligation periods, and submission status), and expense category mappings between Latch categories and HMRC categories. This data is processed at the subscriber's instruction to facilitate their HMRC reporting obligations.

E-Signature Data

Signer names, email addresses, signature representations (typed, drawn, or uploaded), IP addresses, user-agent strings, signing timestamps, consent records, document hashes, and complete audit trails for all signature events.

Builder Marketplace Data

Business name, contact details, geographic coverage, trade categories, certifications, insurance details, portfolio content, job and bid data, and reviews/ratings.

Tenant Referencing Data

Tenant names, dates of birth, addresses submitted for screening, referencing type requested, status and outcome summaries from Canopy, Canopy reference IDs, and timestamps. Note: landlords must obtain explicit tenant consent before initiating referencing.

Compliance Portfolio Data

Gas Safety Certificates (CP12), EICRs, EPCs, Legionella risk assessments, fire risk assessments, smoke and CO alarm records, HMO licence details, Right to Rent records, landlord registration details (Scotland), Rent Smart Wales details, and any other compliance certificates, along with associated expiry dates and reminder settings.

Property Management Client Data

Landlord client names, contact details, NINOs, UTRs, VAT numbers, bank account details, management fee structures, owner statements, fee ledger entries, and payment records between property managers and their landlord clients.

Bank Feed Data (Plaid Open Banking)

Where subscribers connect a bank account via our Plaid Open Banking integration: bank account and routing identifiers, account balances, transaction history (date, amount, description, merchant), and Plaid access tokens. Bank login credentials are entered into Plaid Link directly and are never seen, transmitted to, or stored by Latch.

Tenant Portal Account Data

Where a subscriber invites a tenant to create a tenant-portal account, the tenant's authentication data (email, password hash, login history, trusted-device cookies, 2FA codes) is processed by Latch as a joint controller for the tenant's own account credentials. The underlying tenancy data (name, lease, payments) remains processed under the subscriber's controller role.

AI Processing of Subscriber Data

Where a subscriber invokes an AI feature, the relevant Subscriber Data (prompts, attached file content, lease text, tenant notes, expense descriptions, document text, prior turns) may be transmitted to AI sub-processors (Google Gemini, Zhipu AI, Tavily) for processing. Each AI call is logged in our ai_feature_usage table for cost monitoring and abuse detection. Full prompt and response content is not retained in this log. See section 6.X below for the corresponding Article 28 instruction.

Listings, Prospects and Viewings Data

Where subscribers list properties or coordinate viewings via the platform: prospect names, email addresses, phone numbers, prescreening question responses, viewing schedule details, viewing reminders, viewing feedback, and AI-generated post-viewing follow-up tasks.

Bug Reports and Support Data

Where subscribers submit a bug report or open a support ticket: ticket content, attached screenshots or files, conversation messages, and ratings.

4. Tenant and Property Data Handling

  • All Subscriber Data is stored securely on Supabase infrastructure hosted on AWS in the EU region.
  • Row-level security (RLS) policies enforce strict multi-tenant isolation, ensuring that each subscriber can only access data belonging to their own account.
  • Account members can only access data within their assigned roles (Owner, Admin, PM, or Member).
  • PM (Property Manager) users manage properties on behalf of landlord clients, with access to client data, financial records, and owner statement generation.
  • Tenant portal users can only view data specifically assigned to them by their landlord.
  • Subscriber Data is logically separated from other subscribers' data at the database level through account-scoped queries.
  • HMRC-related sensitive data (NINOs, UTRs, and OAuth tokens) is encrypted at the application level using AES-256-GCM, providing an additional layer of protection beyond the database-level encryption at rest.

5. Data Processor Obligations

In accordance with Article 28 of the UK GDPR, Latch undertakes the following obligations as a data processor:

  • Process Subscriber Data only on documented instructions from the data controller, unless required to do so by applicable law.
  • Where a subscriber instructs Latch to submit data to HMRC via the MTD integration, Latch acts as the subscriber's processor in aggregating and transmitting the data. HMRC receives this data as an independent statutory authority and data controller. The subscriber's instruction to submit data to HMRC constitutes a documented processing instruction under Article 28(3)(a) of the UK GDPR.
  • Use of AI sub-processors on Subscriber Data: Where the subscriber invokes an AI-powered feature, the subscriber hereby instructs Latch to (a) transmit the relevant Subscriber Data (prompts, attached file content, contextual account data) to the AI sub-processors listed on our List of Subprocessors; (b) log the call in the ai_feature_usagetable for cost monitoring and abuse detection; and (c) refuse the call where a global or per-account cost or abuse threshold has been exceeded. The subscriber acknowledges that some AI sub-processors are located outside the United Kingdom (the United States, and — for Zhipu AI — the People's Republic of China). Latch relies on the UK International Data Transfer Agreement and EU Standard Contractual Clauses + UK Addendum, supported by a documented Transfer Risk Assessment for any non-adequate jurisdiction.
  • Agent actions:Where the subscriber enables AI agent actions, Latch will execute such actions strictly on the subscriber's account and will log every action (actor, timestamp, tool used, result) in an audit trail accessible to the subscriber.
  • Ensure that all persons authorised to process Subscriber Data are bound by appropriate confidentiality obligations.
  • Implement appropriate technical and organisational measures to ensure a level of security appropriate to the risk, as detailed in Section 6 below.
  • Not engage another processor (sub-processor) without prior general written authorisation of the data controller. The subscriber is deemed to have given general written authorisation for the sub-processors listed on our List of Subprocessors page.
  • Assist the data controller in responding to requests from data subjects exercising their rights under the UK GDPR.
  • Assist the data controller in ensuring compliance with Articles 32–36 of the UK GDPR (security, breach notification, impact assessments, and prior consultation).
  • At the choice of the data controller, delete or return all Subscriber Data upon termination of the service, and delete existing copies unless applicable law requires storage.
  • Make available to the data controller all information necessary to demonstrate compliance with Article 28 obligations, and allow for and contribute to audits and inspections.

6. Data Security Measures

Latch implements the following technical and organisational measures to protect Subscriber Data:

Technical Measures

  • All data in transit is encrypted using TLS 1.2 or higher
  • Data at rest is encrypted using AES-256 encryption within our database infrastructure
  • OAuth tokens for third-party integrations are encrypted using AES-256-GCM
  • API rate limiting prevents abuse and brute-force attacks
  • Device fingerprinting and risk-based authentication detect suspicious access attempts
  • Two-factor authentication (2FA) is available via email verification codes
  • Sensitive HMRC data (National Insurance Numbers, Unique Tax References, and HMRC OAuth tokens) is encrypted at the application level using AES-256-GCM in addition to infrastructure-level encryption at rest

Organisational Measures

  • Access to production data is restricted to authorised personnel on a need-to-know basis
  • Infrastructure hosted on Supabase (AWS) and Vercel, both SOC 2 compliant
  • Row-level security (RLS) policies enforce strict multi-tenant isolation at the database level
  • All sensitive administrative operations are recorded in audit logs
  • Regular security reviews and vulnerability assessments

AI-Specific Measures

  • AI provider isolation: each AI request is scoped to the subscriber's own account context; no cross-account data is shared between AI calls
  • Cost and abuse caps enforced before each AI call (global $200/month USD platform cap, plus per-account and per-user limits)
  • None of the AI sub-processors used for Latch (Google Gemini, Zhipu AI, Tavily) is authorised to use Subscriber Data to train their general-purpose models
  • The ai_feature_usage log records call metadata (token counts, cost, model, latency) but does not retain full prompt or response content

Document and File Storage Measures

  • Document files (including e-signature PDFs) are stored in segregated Cloudflare R2 buckets (documents, public, avatars, support, email_assets, csv) with bucket-level access policies
  • Documents bucket is served via signed URLs with limited time-to-live; direct public access is not permitted
  • E-signature integrity is protected via SHA-256 document hashes recorded at upload and signing

7. Data Breach Notification

  • In the event of a personal data breach affecting Subscriber Data, Latch will notify the affected subscriber (data controller) without undue delay and in any event within 72 hours of becoming aware of the breach.
  • The notification will include: the nature of the breach, the categories and approximate number of data subjects and records concerned, the likely consequences of the breach, and the measures taken or proposed to address the breach and mitigate its effects.
  • Latch will cooperate with the subscriber in fulfilling the subscriber's own breach notification obligations to the Information Commissioner's Office (ICO) under Article 33 of the UK GDPR.
  • Where a breach is likely to result in a high risk to the rights and freedoms of data subjects, Latch will assist the subscriber in notifying affected individuals under Article 34 of the UK GDPR.
  • Breach notification covers both incidents in Latch's own systems and incidents reported to us by our sub-processors (Supabase, Stripe, SendGrid, Twilio, Plaid, Cloudflare R2, Google, Zhipu, Vercel, Inngest, Langfuse, Microsoft, Canopy). Where a sub-processor reports a breach affecting Subscriber Data, we will pass that information to affected subscribers within the same 72-hour window, to the extent we have it.

8. Data Portability and Export

  • Subscribers may request a full export of their Subscriber Data at any time.
  • Data exports are provided in structured, commonly used, and machine-readable formats (JSON and/or CSV), in accordance with the right to data portability under Article 20 of the UK GDPR.
  • Export requests can be made by contacting [email protected].
  • We will fulfil export requests within one calendar month of receipt. A self-serve export endpoint is in development; until launch, exports are produced manually by our team in JSON and/or CSV.

9. Sub-Processing

  • Latch engages third-party sub-processors to assist in providing the Services. A complete and up-to-date list is maintained on our List of Subprocessors page.
  • The subscriber is deemed to have given general written authorisation for the engagement of sub-processors listed on that page at the time of entering into the subscription.
  • Latch will inform subscribers of any intended changes to sub-processors by updating the List of Subprocessors page and notifying affected subscribers via email.
  • Subscribers may object to a new sub-processor by contacting us within 30 days of notification. If the objection cannot be reasonably accommodated, the subscriber may terminate their subscription.
  • All sub-processors are bound by data processing agreements imposing equivalent data protection obligations.
  • Note regarding HMRC:HMRC is not a sub-processor of Latch. HMRC is a UK government statutory authority that acts as an independent data controller for all data submitted to it. When subscribers use the MTD integration, data is transmitted to HMRC at the subscriber's instruction. HMRC's processing of that data is governed by HMRC's own privacy notice and applicable tax legislation.
  • Note regarding Canopy (tenant referencing): Where a subscriber initiates tenant referencing through the platform, tenant personal data is shared with Canopy (RentalStep Ltd) for the purpose of conducting background screening. The subscriber (as data controller) is responsible for obtaining the tenant's explicit consent before initiating the referencing request. Canopy processes tenant data as an independent data controller for the purpose of conducting the checks. Refer to the List of Subprocessors page for full details.
  • Note regarding Twilio (WhatsApp messaging):Where subscribers enable WhatsApp messaging for rent reminders and tenant communications, tenant phone numbers and message content are processed by Twilio Inc. under Twilio’s data processing agreement. Twilio acts as a sub-processor for WhatsApp message delivery, delivery status tracking, and inbound message handling. Message content additionally traverses Meta's WhatsApp infrastructure as part of the WhatsApp Business API. Subscribers are responsible for ensuring that tenants have provided valid opt-in consent to receive WhatsApp communications in accordance with applicable data protection and electronic communications regulations.
  • Note regarding Plaid (Open Banking):Where subscribers link a bank account via Plaid for automatic transaction reconciliation, bank credentials are entered into Plaid Link directly on Plaid's domain and are never received by Latch. Plaid acts as a sub-processor for the resulting account identifiers, balances, and transaction history under its UK PSD2 licence and DPA. Bank-feed data is deleted within 90 days of the bank connection becoming inactive (or immediately on disconnect).
  • Note regarding Zhipu AI: Zhipu AI operates from the People's Republic of China. Where the subscriber invokes an AI feature routed to Zhipu, prompts and contextual account data are transferred under the UK International Data Transfer Agreement (IDTA), supported by a documented Transfer Risk Assessment that considers the PRC Cybersecurity Law 2017, Data Security Law 2021, and Personal Information Protection Law 2021. Categories of data sent are constrained per the AI section of our Privacy Policy.

10. Data Deletion Upon Termination

  • Upon termination or expiry of a subscription, the subscriber may request deletion of all Subscriber Data.
  • A 30-day soft-delete grace period applies, during which the subscriber may request account restoration.
  • After the grace period, all Subscriber Data will be permanently and irreversibly deleted from our systems and those of our sub-processors, except where retention is required by applicable law.
  • Audit logs may be retained for a minimum of 6 years in accordance with UK financial record-keeping requirements.
  • Stripe billing records are retained in accordance with applicable tax and accounting legislation (minimum 6 years).
  • Upon account deletion or HMRC disconnection, encrypted HMRC tokens, NINOs, and UTRs will be permanently deleted. However, MTD submission history records may be retained for the minimum 6-year period required by UK financial record-keeping regulations. Data previously submitted to HMRC cannot be deleted or modified by Latch, as it is held by HMRC as an independent data controller.
  • E-Signature audit trails: Retained for 6 years after the last signature event on a document, in line with the Limitation Act 1980, to provide evidence of signing events in the event of a legal dispute.
  • Property management client financial data: Retained for 6 years after the end of the management relationship, in line with HMRC record-keeping requirements, including owner statements, fee ledgers, and payment records.

11. Subscriber Audit Rights

  • Subscribers may request, no more than once per twelve (12) months, a written summary of Latch's technical and organisational security measures and the DPA / transfer-mechanism status of our sub-processors. Requests should be sent to [email protected] and we will respond within one calendar month.
  • In the case of a documented regulatory investigation or material security incident, we will cooperate with reasonable additional audit requests beyond the annual cadence above, subject to a confidentiality undertaking and reasonable scoping.

12. Governing Law

  • This Subscriber Data Policy shall be governed by and construed in accordance with the laws of Scotland.
  • This policy is intended to satisfy the requirements of Article 28 of the UK GDPR and the Data Protection Act 2018.
  • The courts of Scotland shall have exclusive jurisdiction over any dispute arising under this policy.

13. Contact

If you have any questions about this Subscriber Data Policy or wish to exercise your rights as a data controller, please contact us:

Privacy enquiries: [email protected]

General support: [email protected]

Company: USELATCH LTD

Company number: SC879051

Registered address: 5 Orrok Lane, Edinburgh, EH16 5HF

ICO Registration Number: 02450028338

14. Material Change History

  • 5 May 2026 (v2.0)— Added Plaid bank-feed, Tenant Portal, AI processing, Listings/prospects, and Bug Reports/Support sub-sections to §3; added Article-28 AI sub-processor instruction and agent-actions clause to §5; added AI-specific and document-storage security measures to §6; expanded §7 to cover sub-processor breach notification; added transitional “in-development” language to §8 portability; added Plaid and Zhipu AI clauses to §9; added new §11 Subscriber Audit Rights; renumbered subsequent sections.
  • 23 March 2026 (v1.0)— Initial publication.