Security
How we protect your documents
What is in place today, and what is not.
How to read this page
Every claim below is marked either in place today or planned, not yet built. Nothing is described in the present tense unless it runs in the software you are using right now, and every badge on this page is checked against our own build before each release rather than typed by hand.
This is not modesty. A security page that promises protections it does not have is how somebody uploads a document they would otherwise have posted by hand — and the whole value of the page is that you can act on it.
What gets written down when staff act
In place today
Every privileged action writes an audit record naming who did it, what changed, and why. That record is written in its own transaction, so an action that gets rolled back cannot erase the trail that somebody tried it.
In place today
The audit table itself refuses to be changed: the application's own database user is granted only to insert and read it, so the trail cannot be edited or deleted even by the software that writes it.
A refused action is recorded the other way round, on purpose: it commits on its own. When the outcome is a refusal, joining the transaction would erase the one row worth keeping — the record that somebody tried.
Money has a second control on top of the trail. A refund is requested by one person and approved by another, the same person cannot do both, and no payment provider is called until the approval commits.
How sensitive fields are stored in the database
In place today
A beneficiary's allergies, medications and medical notes, and a vault document's own document number, are stored as ciphertext in the database — not as text a stolen backup or a direct SQL query could read. A principal without the decrypt permission is shown a masked value, and the denial is itself audited.
Planned, not yet built
What is planned, not yet built, is separating the key policy itself — so that decrypting these fields needs a permission narrower than the general access a staff role already carries, rather than the same permission that lets a role read the record at all.
This is separate from a file you upload — see the next section for how a document itself is stored. This is about the handful of fields a database export or a stolen backup could otherwise read as plain text: a beneficiary’s medical details, and a vault document’s own recorded number.
What happens to a file when you upload it
In place today
A new file is held unreadable and unattachable until it has passed a gate that checks its actual bytes' type against what was declared and runs a malware check. A file that fails is quarantined, unlinked from every order it was attached to, and never made available; the check runs before storage on every upload door in the product, not on a subset of them.
- A new file is held unreadable and unattachable until it has been through the scan gate. It cannot be opened, downloaded or linked to an order while it waits.
- A file that fails is moved out of the servable area rather than deleted, and every order it was attached to is unlinked. It is kept because an infected upload is evidence — somebody either has a compromised machine or is attacking the family they share a vault with, and destroying the only copy destroys the ability to know which.
- The storage path is built by the server. Only the file name comes from you and it is reduced to a flat token, so a name crafted to escape the storage area does not.
- Every version stores a cryptographic hash of its contents, so a file that was altered or replaced underneath the record is detectable rather than silently wrong.
- Uploads are capped at 20 MB. Scans are documents, not archives.
The scanner is not an antivirus, and you should know that
There is no scanning engine in this deployment — no daemon, no vendor API. What runs today detects the standard antimalware test signature and refuses formats that are executable by construction. A pass means “not that, and not obviously a program”. It does not mean the file is safe.
The gate around it is real and is the part that protects you. Putting a genuine engine behind the gate is a single replacement and changes nothing else.
What gets written down when a document is opened
In place today
Opening a vault document writes an access log row — who, their role, when, which order, and from where — committed before a single byte is served, not after. A door with no working log write serves no bytes either.
In place today
Photographs and videos shown in your order’s evidence feed are served through signed links that stop working 15 minutes after they are issued; an unsigned or expired request to the same path is refused outright.
Today that access log is written for vault documents specifically. A document attached to an order through the generated staff tooling rather than through the vault is recorded on the audit trail above instead of on this log — a differently shaped record, not a missing one.
Encryption in transit
Planned, not yet built
Planned, not fully in force: the load-balancer TLS listener policy, its cipher suite, and the HTTP-to-HTTPS redirect all live outside this application and are not yet provisioned. The application already sends the browser instruction that forces future visits onto HTTPS, blocks MIME-sniffing, trims what referrer headers leak, and switches off camera and microphone access for the page — but that half being tested does not make the requirement shipped while the deployment half is not.
Encryption at rest
Planned, not yet built
Planned, not yet built: uploaded files written to storage under a key we control, with an unencrypted object refused by policy rather than merely discouraged. Today, files are written to ordinary disk storage with no encryption layer of our own.
The intended arrangement is database, snapshot and file storage all encrypted under a key we control, with an unencrypted object refused by policy. This is the largest remaining gap on this page.
Private storage and expiring links
Planned, not yet built
Planned, not yet built: a signed, short-lived link for every vault document download, issued from a storage bucket that blocks public access entirely. Today a vault document’s bytes are served from the application’s own origin rather than through a presigned storage URL, so this control has no download-URL endpoint to point at yet.
Sharing a document outward is likewise not built: the ability to expire and revoke a share is designed and recorded in the data model, and nothing enforces it yet, so there is no customer-facing share link to rely on.
Nothing behind your login is given a preview
In place today
Pages that may generate a link preview are an explicit, reviewed list — orders, evidence, the vault, family and care-wall pages are not on it, and emit no preview data at all. A new authenticated route is unshareable until somebody deliberately adds it, so forgetting is safe in the direction that matters.
When a link is pasted into a messaging app, that app fetches the page — signed out — and reads the title, description and image it advertises. Any page holding an order, a document, a family or a person publishes none of those, and asks search engines not to index or follow it.
Keeping and deleting
In place today
A nightly job removes or anonymises records that have passed their retention period, skips anything under legal hold and reports the skip, and a dry run lists exactly what a live run immediately after would affect.
In place today
A beneficiary's medical notes, allergies and medications are anonymised 24 months after the last care order that needed them.
Planned, not yet built
Planned, not yet final: the full schedule — a named period for every class of data — is drafted but not yet signed off by counsel, and three classes (financial records, the audit trail, evidence media) cannot be purged at all today because their tables refuse deletion outright; the job counts and reports them rather than acting on them.
A record under legal hold is skipped rather than purged. Evidence keeps its ledger entry when its contents are purged, so a purge reads as a purge rather than as a gap in the chain. To ask what we hold about you, or for its deletion, see the privacy policy’s rights section — that is the route to raise either request today, whether or not you have an account.
Reporting a vulnerability
If you have found a way to reach data you should not, tell us before you tell anybody else and we will not pursue you for having looked. Please include what you did, what you saw, and roughly when.
A dedicated disclosure address has not been published yet — this deploy has no NEXT_PUBLIC_SECURITY_EMAIL set. Until it is, use the routes on the contact page and say in the first line that it is a security report, so it is escalated rather than queued.
Related: Privacy policy — what is collected, why, and how to ask for a copy or a deletion. Terms of service. Grievance officer.