What we process for you, and the two clauses that cannot be boilerplate.
Revision: Pre-Audit Candidate, 12 October 2026
Version 1.1, dated 12 October 2026 (Pre-Audit Candidate), replacing version 1 of 21 August 2026; it brings the page into line with the service as built, and every change is recorded in the project's change history. This is the addendum for a customer who is using hosted Haven to communicate with, or about, people whose personal data they are responsible for — a newsroom, a law firm, an NGO, a company. It supplements the terms of service, which govern everything else.
An individual on Personal or Family does not need this page. You are not a controller of somebody else's data by having a conversation with them, and nothing here improves your position; the privacy policy is the document for you.
This is a draft, and we are not lawyers
Everything on this page was written by the people who build Haven, from the code, in the same register as the rest of this site. It is not legal advice and it has not been reviewed by a solicitor. Before this business relies on it — and before you do — it needs a lawyer's pass, and the clauses that need one most are marked where they appear. We would rather ship an honest draft that says so than a confident boilerplate that says nothing.
Roles, and the unusual thing about ours
You are the controller. You decide who has an account on your subscription, who they talk to and why. We are the processor, acting on your documented instructions, which for this service means: run the instance, keep it available, apply the limits your plan carries, and nothing else.
The part that is not standard, and that a lawyer needs to see
We cannot process the content at all. Message bodies, file contents, filenames and new group names arrive already sealed under keys we have never held. There is no key escrow and no operator decryption path, so an instruction from you to produce, search, filter, scan, moderate or export the content of your users' messages is an instruction we cannot carry out, however it is worded and whoever sends it.
That is a strength for most controllers and a genuine problem for a few. If your regulator or your own policy requires message archiving, supervision or content review, Haven cannot provide it, and no plan or contract changes that. Find that out here rather than at an inspection.
What we do process on your behalf is the metadata around those messages, which is a real and substantial category and is enumerated in clause 3.
Subject matter, duration, nature, purpose, data and data subjects
The six things Article 28(3) requires an addendum to specify, answered from the schema rather than in the abstract.
| Required particular | What it is here |
|---|---|
| Subject matter | Operating a hosted end-to-end encrypted messenger for the accounts on your subscription. |
| Duration | For as long as the subscription runs, plus whatever a lapsed or cancelled state leaves in place — which is everything, because nothing is deleted on lapse. Financial records outlive the account deliberately; see clause 7. |
| Nature and purpose | Storage, relay and delivery. Storing ciphertext and wrapped key material; routing messages between accounts; delivering notifications where a user has opted in; relaying call media it cannot decrypt; billing. |
| Types of personal data — readable by us | Usernames; the complete conversation-membership graph, and a dated history of it in the retained key records — so when somebody joined or was removed is reconstructable; message timestamps to the second; attachment sizes; reply structure; reactions; read receipts; starred messages; blocks; status messages; suspension reasons; sign-in and last-seen times; session device labels; TOTP secrets where two-factor is on; push endpoints where notifications are on; the security-event log; the administration log, which names accounts and outlives their deletion; plan, seats, billing status and which accounts share a bill; a payment-processor customer handle and a hosted invoice link, each of which resolves at the processor to a billing name and address; and — for any account that has paid by card — the processor's raw notification bodies, stored verbatim so their signatures stay checkable, containing the email address, and depending on what the processor asked for the name, postal address and card last four digits. That last store is never swept and grows for the life of the instance. This row understated the position until an audit of the schema corrected it; a controller relying on it for an Article 30 record should re-read it. |
| Types of personal data — sealed to us | Message contents, file contents, filenames, MIME types, group names on groups created since names were sealed, and every conversation key. We hold these and cannot open them, so we cannot disclose them to you either. |
| Categories of data subject | The people you put on the subscription, and anybody they hold a conversation with on the instance — which includes people who are not your users and never agreed anything with you. That second group is the one controllers forget. |
| Special category data | Whatever your users choose to say is sealed and unknown to us. But who talks to whom is readable, and in some contexts association is itself special category data — a source, a patient, a member of a union. Assess that rather than assuming encryption answered it. |
Security measures, stated as what exists
- End-to-end encryption of message bodies, file contents, filenames, MIME types and new group names, performed in the browser with keys the server never holds.
- Message plaintext padded to fixed buckets before encryption, so a stored ciphertext leaks a range rather than a length.
- Private keys wrapped with a key derived from the user's password, PBKDF2-SHA256 at 600,000 iterations, never leaving the browser unwrapped.
- Per-message Ed25519 authorship signatures, checked in the recipient's browser against a key that browser pinned itself, plus a second signature over each message's position so a message removed from the middle of a transcript is visible rather than silent.
- Out-of-band verification with 60-digit safety numbers, and sending blocked — not merely warned — when a verified contact's key changes.
- Optional two-factor authentication, account lockout, per-device sessions that can be listed, revoked and remotely wiped, auto-lock, a panic key and a duress password.
- Relay-only calls with no public STUN fallback, so an instance with no relay reports calls unavailable rather than downgrading them.
- Append-only audit logging of every administrative action, with the operator's identity denormalised onto the row so it survives their account.
- Rate limits on every authentication, redemption and enquiry path, and a hard ceiling on unhandled enquiries.
- Subresource integrity pins on the vendored cryptography files, checked against the bytes on disk at boot, with the server refusing to start on a mismatch.
And the measures that do not exist, which belong in the same clause
No independent security audit. No certification of any kind — not ISO 27001, not SOC 2, not Cyber Essentials, and nothing else. No reproducible builds and no published bundle hashes, which is what would let a third party confirm the JavaScript we serve is the JavaScript in the repository. No signed native client. If your procurement process requires one of those, we do not have it and will not claim to, and a vendor questionnaire that gets a "yes" to any of them from us has been answered by somebody who did not read this page.
Sub-processors
You authorise the sub-processors listed on the sub-processors page, which is part of this addendum by reference and is the shortest such list you are likely to be handed: a payment processor, only when the instance is configured for cards; the browser vendors' push services, only for users who opt into notifications; and a hosting provider. There is no analytics vendor, no CDN, no font host, no error tracker, no support desk, no email provider and no data warehouse, because none of those exist in this product.
We will give notice before adding one. That notice cannot be an email, because we hold no address for anybody, and it cannot be a message in the app either, because there is no operator-to-customer notice channel in this product — it is a dated change to that page and nothing else. If you object to a new sub-processor, the remedy is to cancel and be refunded the unused portion of a prepaid term. The refunds page says how.
Helping you meet your own obligations
Data subject requests
Mostly self-serve, which is faster than anything we could do by hand: each account has a live disclosure panel, a full export, and password-confirmed deletion, all inside the app. Where a request needs us, ask through the contact form. Note the shape of the constraint: we cannot verify a data subject's identity, because we hold nothing to verify it against — the only proof of identity in this system is being able to sign in.
Breach notification
Without undue delay after we become aware, with what we know and what we do not. And the mechanism, stated plainly because it is worse than you are used to: we have no email address for you, and no way to push a message to you inside the product either. Notice is a dated notice on this site, and that is the whole of it: you find out by coming back and looking. Enterprise customers can name a channel in the contract, and if breach notification to a named person matters to your compliance position, that is a reason to be on Enterprise rather than a listed plan.
Impact assessments
The threat model and the privacy policy are written to be usable as source material for a DPIA, including the parts that count against us. If you need something specific answered, ask; we would rather answer it than have you infer it.
Audits and inspections
What we can offer today: the source, which is readable; the derived disclosure panel, which you can run against your own instance; and this documentation. What we cannot offer is a third-party audit report or a certification, because neither exists. An on-site or contracted audit right is an Enterprise conversation and belongs in a signed contract rather than in a page on a website.
Return and deletion at the end
On termination, and at your choice: the export tool returns each account's data in a machine-readable file, with sealed material carried as sealed material and every omission named inside the file; or accounts are deleted from the app, which removes their rows and unlinks their file blobs.
Two things deliberately survive and are named rather than buried: invoices and ledger entries, which carry no foreign key to an account precisely so they outlive it and a chargeback or a tax question can still be answered; and a username on an administrative audit row, wherever an administrator acted on that account, so the log can still say who did what. Both are disclosed on the account's own panel. Retaining them is a legal-obligation and legitimate-interest argument that a solicitor should confirm for your jurisdiction.
A third thing survives deletion, and only on a lawful order: data under a preservation order. If a court or other lawful authority orders us to preserve an account or a conversation, we place a legal hold on it. While the hold is in force, retention windows, disappearing messages, users' own deletions and edits (the overwritten version is kept), key retirement and account deletion all stop destroying what it covers, and that includes any deletion or return you instruct at the end of this agreement. What is kept is ciphertext and wrapped keys we cannot open. A hold is placed only by a named person on our side, from the server's command line, against a case reference, in a register that is never edited; when it is lifted, deletion resumes. Neither the account holder nor the subscription owner is notified by the product, and an account's data export does not show a hold.
We will notify you of a hold on your accounts wherever the order and the law allow it. You, the customer, are told — the subscription owner, not each account holder — in writing, as soon as we are permitted: when the hold is placed if nothing restricts us, or as soon as a restriction lapses if one does. We tell you the case reference, which accounts or conversations the hold covers, when it was placed, and when it is lifted. The channel is the one problem: we hold no contact address on your account. On Enterprise we use the channel your contract names. On a listed plan we use the contact details you give us for this purpose through the contact form (choose "Something else" and say it is a contact for preservation-order notices); if you have given us none, we have no private way to reach you, and we will answer any enquiry you make through that form truthfully, to the extent the order allows. Where an order forbids us to tell you, we will not, and we will not hint at it either. How that sits with your own obligations to data subjects is a question for a solicitor.
International transfers — the second clause that cannot be boilerplate
This is deliberately incomplete, and filling it in with a guess would be worse
Where the data sits depends on where the instance is hosted, and where it may travel depends on which sub-processors are live for you. The pattern is knowable — Stripe is a US company operating globally; push services are operated by US companies; the hosting provider is wherever the operator put the instance — but the transfer mechanism, the standard contractual clauses, the transfer risk assessment and the supervisory authority are all a function of two facts this page does not know: where the operator is established, and where you are.
A solicitor must complete this clause, together with governing law in the terms. Until then, ask us where your instance is hosted before you sign anything, and we will tell you.
Everything else in the terms of service applies to this addendum. If the two conflict on a matter of data protection, this page wins.