Every period on this page is enforced by code, not by intention. A retention claim with nothing enforcing it is a UK GDPR Article 5(1)(e) exposure rather than a policy, so each row below names the mechanism that does the work.
What is kept, for how long, and what enforces it
| Data | Retention | What enforces it |
|---|---|---|
| Your organisation's operational records — developments, units, apportionments, budgets, ledger entries, demands, payments, consultations | Kept while your subscription is live. Deleted on request. | A single database function that removes them in the correct order. A direct delete is refused, because the unit-level references are deliberately non-cascading. |
| Your profile, after you ask for your account to be deleted | Soft-deleted immediately; hard-deleted after 30 days. | A scheduled monthly job. In the meantime every lookup reads through a pre-filtered view, so a soft-deleted person disappears from email and reminder eligibility straight away rather than depending on each query remembering to exclude them. |
| Your sign-in identity | Deleted immediately on request. | The account deletion endpoint removes the authentication record itself, not just the profile. |
| Record of product emails we sent you | 90 days, then deleted. | The same monthly job. |
| Issued demands, Section 20 notices and section 48 notices | ⛔ The record is never deleted. Seven years from issue it is anonymised and the stored file itself is destroyed. | A scheduled monthly job strips the file and the identifying columns, leaving the record, its hash, the statutory-text version and the elements asserted. |
| The audit log | Retained indefinitely. The actor is anonymised on an erasure request. | A dedicated function that also scans the recorded prior and new values for the person's name, email and identifier. |
| A testimonial you gave us | Deleted when your account is deleted, not just unlinked from it: your permission to publish it ends with your account. | A database trigger that runs whenever an account is deleted, whichever way it is deleted. |
| Payment-processor event records | Retained indefinitely. These are payment-provider event identifiers with no personal data. | — |
| Error-monitoring events | The monitoring provider's own default of 90 days. Before an error report is sent, our code removes the values of a fixed list of fields that hold personal data (such as leaseholder names, correspondence addresses and email addresses) and keeps no details of the signed-in user except an internal ID. It does not search free text, such as the wording of an error message, for personal data: there it removes only sign-in codes and tokens carried in web addresses, so a name or email address written into an error message could still be sent. IP addresses and location data are removed by the provider on receipt and not stored. | A scrubbing function in our code before transmission, and the provider's IP and location removal on receipt. |
| Website analytics | No personal data is collected, so there is nothing to retain. | GoatCounter sets no cookies. |
The seven-year retention, stated honestly
This is the part most worth reading, and it is the part a policy of this kind usually blurs.
An issued service charge demand contains the leaseholder's name and correspondence address because it is addressed to them and served on them. So the document cannot exist without personal data in it.
⚠️ Two different statutory duties get confused here, and an earlier version of this page confused them. Section 47 of the Landlord and Tenant Act 1987 requires the landlord's particulars on the face of a written demand — the landlord's "name and address", and, where that address is not in England and Wales, "an address in England and Wales at which notices (including notices in proceedings) may be served on the landlord by the tenant"; a demand that omits them is treated for all purposes as not being due. Section 48 is a separate duty: the landlord must give each tenant, by notice, an address in England and Wales for service, and until it has, rent and service charges are likewise treated as not being due. Neither section requires anything about the tenant's name or address. The leaseholder's details are on the demand because a demand must be addressed and served, and they are retained afterwards on the legitimate-interests basis set out below — not because a statute compels us to hold them.
We cannot both retain the issued document as evidence and tell you that all personal data is removed on request. Those two statements do not reconcile, and an earlier draft of this position tried to make them.
What is retained: the record, the file, its SHA-256 hash, the version of the statutory text it was built from, the statutory elements asserted, and the calculation snapshot.
Why we keep it at all: the document is the evidence that a statutory demand carried the particulars the law requires. Retaining it protects both sides of a dispute — a leaseholder challenging a demand needs the original as much as the company defending it does. Deleting it destroys the only proof that the demand was compliant.
Why seven years, and not six or twelve. The limitation period on a contractual claim under a lease runs to six years, or twelve years where the lease is executed as a deed. A residential long lease is normally granted as a deed, so the twelve-year case is the common one — which means the limitation period on its own would argue for twelve, not seven. Seven is the ordinary six-year period plus a year's margin, for a claim issued close to the deadline and served afterwards.
We have deliberately chosen not to hold leaseholder-identifying detail for the full twelve years. Holding a named individual's data for that long, against a dispute that is rare, is not proportionate, and data minimisation — Article 5(1)(c) UK GDPR — points the other way. The consequence is worth stating rather than burying: in a deed case the anonymised record outlasts the identifying detail. After year seven we can still show what was issued and that it was compliant; we can no longer show to whom.
Lawful basis: legitimate interests, for the establishment, exercise and defence of legal claims — Article 6(1)(f) UK GDPR.
After seven years: the record, hash, version and element set survive. The rendered file and the leaseholder-identifying columns are destroyed.
Everything else about that leaseholder is erasable — their unit record, their balances, their payment history, any note you recorded. The exception is the issued document alone.
Deletion, and what actually happens
Deleting your account performs three things. Missing any one of them would be an Article 17 failure on the first request, so all three run together:
- Your profile is soft-deleted and your memberships revoked. Every email and reminder lookup reads a pre-filtered view, so this takes effect immediately rather than relying on each consumer to remember a filter.
- Your sign-in identity is deleted. Soft-deleting the profile alone would leave your email address and authentication record in place.
- Your identity in the audit log is anonymised, including inside the recorded prior and new values.
If you are an owner of the organisation, you can also delete the organisation itself, which removes every operational record above. If you are its only owner, you must first either make another member an owner or delete the organisation along with your account. Only an owner can manage an organisation or end its subscription, so deleting your account will not leave one without an owner.
And it reaches the issued documents too, which is the part worth spelling out. Deleting the organisation cannot delete an issued demand — the database refuses that to anyone, including us. What it does instead is anonymise those documents immediately, rather than waiting for the seven-year point: the identifying columns are stripped and the rendered files are destroyed on the next scheduled sweep. The record, its hash, the statutory-text version and the elements asserted survive, so it stays provable that a compliant demand was issued — but no longer to whom. That is a deliberate choice: once you have asked us to erase, your erasure request outranks our own convenience in keeping the evidence complete.
What we cannot undo
Issued documents and the audit log are append-only, enforced by database privileges rather than by our own restraint. We cannot modify or delete a row in either, and neither can anyone holding our administrative credentials. That is the point: an evidence chain a vendor can quietly edit is not evidence.
The consequence for you is worth saying plainly — there is no "unsend" for an issued demand. Correcting one means issuing a corrected document, which is also recorded, and the original stays in the chain.
Backups
Managed daily backups. A deletion takes effect in the live database immediately and in backups as they roll off on their own cycle.
Asking
Email privacy@levyboard.co.uk, or use the export and delete controls in your account settings. If we are the processor rather than the controller — which is the case for your leaseholders' data — a leaseholder should contact your company, and we will point them there. See the Data Processing Agreement, clause 8.
LevyBoard is a product of Crocker Digital Ltd, company number 17008789, registered in England and Wales.