Your block's financial records sit in this product, and some of that money is held on statutory trust for your leaseholders under section 42 of the Landlord and Tenant Act 1987. This page says what is in place, how to tell us about a problem, and where LevyBoard stands on external certification.
Reporting a vulnerability
Email security@levyboard.co.uk. Please include what you found, how to reproduce it, and how we can reach you.
- We will acknowledge within two working days.
- We will tell you what we intend to do, and when it is fixed.
- We will not take legal action against you for a good-faith report made under this policy — please do not access, modify or retain anyone else's data while investigating, and please give us a reasonable chance to fix it before disclosing.
- There is no paid bug bounty. We will credit you if you would like to be credited.
A machine-readable version of this contact is at /.well-known/security.txt, per RFC 9116.
What is in place
Tenant isolation is enforced by the database. Row-level security applies on every table holding customer data, keyed to organisation membership — so one block's records are unreachable from another account even if application code has a bug. Cross-organisation access is tested for read, insert, update and delete.
The issue record and the audit log cannot be changed by anyone, including us. This is enforced by database privileges, not by policy. Neither we nor anyone holding our administrative credentials can alter or remove a row. An evidence chain a vendor can quietly edit is not evidence.
Every issued document is fingerprinted, and the fingerprint is checked before the file is served. Each document is stored with a SHA-256 hash, the version of the statutory text it was generated from, and the version of the stored file. The hash is recorded at the moment the document is issued, and that record cannot afterwards be altered — see the paragraph above. The stored file itself sits behind that record: it is not immutable, and it is deliberately deleted once, at the end of the retention period. So every download re-hashes the stored file and compares it with the hash taken at issue; on any mismatch the file is not served and the mismatch is raised. We do not claim the file is beyond reach — we claim a change to it is detected before anyone relies on it. You can also recompute the hash of any document you hold and compare it with the one shown against that document in the audit trail.
Statutory wording is transcribed and byte-compared, never composed. The prescribed summary that must accompany a demand is copied verbatim from the source and checked byte-for-byte against the hash recorded when it was transcribed, before a document can be issued, with a deliberately-altered control that the check must fail. The comparison is against that recorded hash, not against a fresh fetch of the legislation website — so it proves the wording has not drifted since we transcribed it, and the transcription date is published on the methodology page so you can check it against the source yourself. This is a correctness control, but it is listed here because the failure mode is the same shape as a security one: an output that looks right and is not.
Card data never reaches us. Stripe handles payment details directly; we store a customer and a subscription reference.
Access control within your account is role-based — owner, director, viewer — and every write to money, apportionment or an issued document records who did it, when, and what it was before.
Rate limiting applies to sign-in and to mutating endpoints. Errors are monitored: before an error report leaves the system, 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. The monitoring provider removes IP addresses and location data on receipt. Backups run daily.
Certification and assurance
LevyBoard is not ISO 27001 certified and holds no SOC 2 report, so if your company's own policies require a certified supplier, we are not that supplier today. The controls above are covered by our own automated checks; no independent penetration test has been commissioned. Uptime is monitored automatically and errors raise an alert immediately, but a human response outside UK working hours is best-effort rather than contractual, and there is no SLA or published uptime figure. If any of that changes, this page changes with it and the date at the top moves.
Related
- Data Processing Agreement — including Schedule 2, the technical and organisational measures, and clause 7 on breach notification.
- Retention and Deletion — what is kept, for how long, and what enforces it.
- Sub-processors — every third party that touches your data.
LevyBoard is a product of Crocker Digital Ltd, company number 17008789, registered in England and Wales.