Privacy policy

Status: draft, accurate as of 2026-08-20. This describes what the Leasebook software actually stores and does today, not an aspiration. Where a control is not built yet, this document says so plainly and points at the readiness item that would build it, rather than implying it exists.

Who this is about

Leasebook is software a letting or management agency (the agency) runs to manage a property portfolio. The agency decides what data goes in, who sees it, and how long it is kept — in data-protection terms, the agency is the controller. Leasebook is the processor: we hold the data on the agency's instructions. This document is written for that relationship. If you are a tenant or owner-client wondering how your data is used, the agency you deal with is who to ask; see DPA.md for how we support them in answering you.

Three kinds of person appear in the system, and this document treats them separately because the controls that apply to each differ:

The agency's own staff and owners — people with a login (an "account").
Owner-clients — the property owners the agency acts for. Usually held as a contact record, sometimes also as a login if the agency grants one.
Tenants — the people living in a managed property. Usually held as a contact record and a tenancy record; sometimes also as a login.

What personal data the software stores

This list is grounded in business-store.mjs's table definitions — nothing here is inferred.

Data	Table	About whom
Name, role, company, email, phone, free-text notes	`organisation_contacts`	Anyone in the agency's contact book — owner-clients, tenants, solicitors, contractors, utility desks
Tenancy dates, rent amount, deposit amount, RTB registration number and date	`tenancies`	A named tenant
Rent due/received amounts, dates, payment references	`rent_entries`	A named tenant, via their tenancy
Messages sent through the tenancy channel	`tenancy_messages`	Whoever sent or received the message
A logged call, meeting or note about a contact	`contact_activities`	Whoever the note is about
Fee agreements (percentage or flat fee, VAT rate, agreement dates)	`client_engagements`	An owner-client
Uploaded documents (leases, certificates, compliance evidence) — file metadata and a hash; the file body lives in the artifact store, not this table	`property_documents`	Whoever the document names or concerns
Work order details, assignee, contractor, cost	`work_orders`	Contractor and any tenant/property named in it
Every outbound notification attempt: kind, recipient class, recipient email address, outcome	`notification_log`	Whoever the notification was addressed to. Deliberately no message body column — this table exists to prove a send was attempted or suppressed, not to duplicate tenant correspondence into a second, less-visible copy
Actor, action kind, and a JSON detail blob for privileged actions	`audit_events`	Primarily agency staff (the actor); the detail blob can incidentally name a tenant or owner-client the action concerned
Pending invitations: email address, role, property scope	`invitations`	Whoever the agency is inviting
Bank statement lines imported for reconciliation: date, amount, description, counterparty	`bank_transactions`	Whoever the counterparty is (often a tenant's name as it appears on a bank statement)

Address-lookup requests (see "What leaves the deployment" below) send an address string to Google's Address Validation / Places APIs; the response is kept only as a validated address, postcode and coordinates on the property record — no separate copy of the raw request is retained (address-verification.mjs).

What is not stored

No payment credentials, card numbers, or bank account access. Property OS has no payment integration at all; imported bank transactions are statement lines for reconciliation, not a connection to a bank account.
No message bodies in the notification log — see above.
No tenant photograph is ever sent to a cloud AI model. Photo classification, if it existed, would need a consent story and a budget decision before it needed code; that decision has not been made, so photos stay local and are analysed only by text description, never by a model reading the image itself (docs/SECURITY.md, "Photographs are the sharpest edge").

Where the data lives

Today, a customer's data lives on a single self-hosted server (k8s/property-os.yaml, node kucni), on a persistent volume backed up nightly to a separate volume on the same physical host, retained 14 days (docs/OPERATIONS.md, "Backup and restore drill"). There is currently no off-site or geographically redundant backup copy — a failure of that host's storage, not only the primary disk, is a scenario the current backup design does not cover.

The service is served over plain HTTP, not HTTPS, at its current LAN address. There is no TLS termination in front of the application today. The session cookie is HttpOnly; SameSite=Lax and only gains the Secure flag if COOKIE_SECURE=true is set, which it is not in the current deployment. Terminating TLS, setting COOKIE_SECURE=true and moving to a real hostname is a named precondition for any exposure beyond the current LAN (docs/OPERATIONS.md, "TLS activation gate") and is tracked as a commercial readiness item (docs/SALES-READINESS.md item 2.1) — it is not done yet, and this document will not claim otherwise. An agency evaluating us for production tenant data should treat this as an open item to resolve before go-live, not a detail to discover later.

All data is currently hosted in a single location; there is no international transfer of personal data out of that location today, because there is nowhere else the data goes except the sub-processors listed in SUB-PROCESSORS.md.

What leaves the deployment, and under what consent

See SUB-PROCESSORS.md for the full list. In summary:

Local AI extraction (Ollama) runs on the same server, is operator-configured, and is never directed by request input. Only minimised context reaches it — an address is deliberately withheld from what the model sees (docs/SECURITY.md). It does not leave the deployment.
Cloud AI gap-fill/validation exists as an optional, consent-gated path for public research enrichment (property research, not tenant or contact data) and is off by default — the provider defaults to "disabled" (public-export-policy.mjs) and only activates on an explicit, per-run consent decision with an operator-set cost budget. Tenant personal data (contacts, tenancies, rent, uploaded documents) is explicitly excluded from what this path can send, by design (docs/MVP-PLAN.md, Pipeline v13).
Address validation (Google) — a property address is sent to Google's Address Validation and Places APIs to resolve it to a canonical address, postcode and coordinates. This is a first-party Google API call, not a data broker.
Weather (Open-Meteo) — a property's coordinates are sent to Open-Meteo to retrieve weather-related context. No tenant or contact data is sent.
Email delivery — see SUB-PROCESSORS.md; in the current deployment this is a development mail-catcher, not a live relay to real inboxes.

Nothing else reaches the network from a user-supplied or request-influenced URL except through the guarded fetch path described in docs/SECURITY.md ("Outbound fetch (SSRF) threat model"), which restricts targets, blocks private/internal address ranges, and caps response size and time.

Retention

There is no automatic, time-based deletion of tenancy, rent, contact or document records today — the product is a system of record, and an agency's own regulatory obligations (RTB registration history, statements issued to owners) generally require it to keep this data, not delete it on a timer. Backups are retained 14 days on a rolling basis and then pruned automatically (docs/OPERATIONS.md). There is currently no separate, configurable retention policy per data category beyond that.

Access, correction, and erasure

Access and correction: agency staff can view and edit records through the product directly (contacts, tenancies, documents). There is no self-service "download everything about me" export today for a tenant or owner-client; a request for one is handled by the agency asking us.
Account erasure (eraseAccount in business-store.mjs, invoked by DELETE /api/account and the admin-triggered equivalent) removes a login's own personal-account data — profile, sessions, uploaded intelligence, address-verification history — and, if that login was the organisation's last remaining business_owner, the entire organisation and everything in it cascades away with it (memberships, portfolio, tenancies, contacts, documents, statements). If other owners remain, only that person's membership is removed; the organisation's records are unaffected, because they belong to the agency, not to the departing login.
Tenant/owner-client erasure (eraseContactPersonalData in business-store.mjs, POST /api/v2/organisations/:id/contacts/:contactId/erase, restricted to a business_owner or business_admin) erases a single person's reachability and free text out of an organisation's records: their organisation_contacts row's name, company, email, phone and notes are cleared, their logged contact_activities (call/email/meeting/note bodies) are deleted, and any notification_log row addressed to them has its recipient email address blanked. This is deliberately not a blanket delete. The tenancy record itself — including tenant_name — is retained: it is the legal record of the tenancy, and an Irish agency has RTB and Revenue recordkeeping obligations for it that erasure does not override. The notification log row also survives, with only the address removed: the fact that a message was sent (to whom, when, what outcome) is audit evidence for the agency; the address itself is the personal data. The contact row is likewise retained rather than deleted, empty of reachability data, because a tenancy's link to its contact (tenancy_contacts) must survive alongside the tenancy it names. Every erasure is itself audited, recording counts and the contact id — never the values erased, so the audit trail cannot itself leak what erasure removed.

Breach notification

There is no automated breach-detection or notification tooling today. In the event of a suspected breach, we notify the affected agency directly and work with them on their own regulatory notification obligations; this is a commitment, not something the software currently automates or logs.

Security controls in brief

For the full picture see docs/SECURITY.md. In summary: role-based access control is enforced server-side (not just hidden in the UI), a tenant seat cannot read another tenant's records, deal room and job-report links use random tokens with only a hash stored server-side, and every privileged action is written to an audit log. What is not yet true: TLS in transit (see "Where the data lives" above).

Changes to this policy

This document is maintained alongside the product in the same repository as the code it describes, and is updated as the underlying capabilities change — in particular when docs/SALES-READINESS.md item 2.1 (hosting/TLS) is completed.

← Leasebook