Encryption & HIPAA, honestly
What Brun does about HIPAA — and what it doesn’t do.
Brun is a secure intake form and lead board: website inquiries are encrypted in the browser before they send, stored as ciphertext we can’t read, with no plaintext inquiry content in our database. That’s true today, and it removes the riskiest part of catching sensitive inquiries online.
But encryption is a security property, not a compliance status. Brun is not a HIPAA-compliant service, we do not sign Business Associate Agreements, and our Terms currently prohibit storing PHI. If you handle PHI and need a BAA-backed system of record, Brun isn’t the right tool. This page explains exactly where the line is.
What does Brun actually do to protect a sensitive inquiry?
Today, every inquiry is encrypted in the visitor’s browser with AES-256 before it reaches Brun, and we store only ciphertext we have no key to open. No plaintext inquiry content from the intake-to-lead-to-note path lands in our database — a property a test in our CI pipeline checks on every change. These are architectural facts you can rely on. They are not, on their own, HIPAA compliance.
Sealed in their browser.
You keep the contact or intake form you already have. The moment the visitor hits submit, their browser encrypts every field with AES-256 before anything leaves the device.
Act II — at our door
Screened. Never opened.
What reaches our servers is an opaque ciphertext envelope. Our server verifies the envelope is well-formed, but it has no key and cannot decrypt a single field.
No plaintext lands here.
stored on our serversEncrypted so we can’t read it: every inquiry, lead, and note. Server-readable to run the service: your account and team email addresses, billing status, seat counts, timestamps, and any support messages you send us.
Unlocked on your board.
Inside your team’s browser, the inquiry is unwrapped with a key only your team holds, and becomes a lead on a simple board — notes, status, follow-up. Still encrypted at rest the whole time.
How does Brun’s encryption reduce exposure?
Good data hygiene means encrypting sensitive content, limiting who can read it, and keeping readable copies off vendor servers. Here is how Brun’s architecture lines up with each of those — every row below is true today. None of it is a substitute for a HIPAA compliance program or a signed BAA.
| Good data hygiene asks you to… | What Brun does today |
|---|---|
| Encrypt sensitive content in transit and at rest | Each inquiry is AES-256 encrypted in the visitor’s browser before it sends; it sits in our database as ciphertext. |
| Limit who can read the content | Decryption keys live only in your team’s browsers. Brun staff, attackers, and subpoenas all see the same ciphertext. |
| Keep readable content off the vendor’s servers | No plaintext inquiry content lands in our database on the intake-to-lead-to-note path — a property enforced by an automated test in CI. |
| Shrink what a database breach exposes | A breach of our database exposes your inquiry and lead content only as ciphertext — an envelope no one can open without your key. |
| Keep sensitive content out of downstream services | Notification emails say only “you have a new lead” — no inquiry content — so our email provider never receives it. |
A breach here exposes ciphertext.
Your inquiry and lead content would stay ciphertext. HIPAA’s breach-notification rule has an encryption “safe harbor”: PHI encrypted to NIST standards with keys the vendor never holds is treated as secured. Whether any specific incident is reportable is always a per-incident legal determination you make with your counsel — we don’t make that call for you. What we can state as fact is the architecture: Brun stores AES-256 ciphertext and never holds your keys, so a breach of our database would expose envelopes no one can open.
- Encrypted to NIST standards.AES-256 (per NIST SP 800-111) on every inquiry, encrypted before it leaves the visitor’s browser.
- Keys Brun never holds.The decryption keys exist only in your team’s browsers, so the content we store is ciphertext we cannot open.
- A breach exposes only ciphertext.What an attacker would get for your inquiry and lead content is unreadable envelopes — not readable records.
Does Brun sign a BAA or accept PHI?
No to both. When a vendor holds PHI it becomes a Business Associate that needs a signed BAA — even when the vendor can’t read the data, because encrypted PHI is still PHI. Brun does not sign BAAs, so rather than pretend encryption makes the obligation disappear, our Terms keep PHI out of the Service. Encryption lowers your breach risk on the sensitive inquiries you are permitted to store; it does not turn Brun into a HIPAA solution.
Encryption and HIPAA questions, answered.
Is Brun HIPAA compliant?
No. Brun does not present itself as a HIPAA-compliant service, does not sign Business Associate Agreements (BAAs), and our Acceptable Use Policy currently prohibits storing Protected Health Information (PHI) in the Service. What Brun offers is a security property, not a compliance status: client-side AES-256 encryption, zero-knowledge storage, and no plaintext inquiry content in our database. That reduces the exposure of sensitive first-contact inquiries — but it is not a substitute for a HIPAA-compliant, BAA-backed system of record.
Do you sign a BAA?
No. Brun does not sign Business Associate Agreements at this time. Because a covered entity needs a signed BAA with any vendor that handles PHI, and because we do not offer one, our Terms prohibit routing PHI through Brun. If you need a BAA-backed tool for PHI, Brun is not the right fit today.
Is encrypted PHI still covered by HIPAA?
Yes. Encrypted PHI is still PHI, and a vendor that stores it is still a Business Associate — encryption is not a HIPAA exemption. This is one reason Brun does not position itself as a PHI tool: we do not sign BAAs, so our Terms keep PHI out of the Service. Encryption reduces breach exposure; it does not remove HIPAA obligations or replace the paperwork HIPAA requires.
Can Brun read the inquiries submitted through my form?
No. Every inquiry is encrypted in the visitor’s browser before it sends, and Brun stores only ciphertext it has no key to open. Our staff, our infrastructure, and anyone who subpoenas us see the same thing: an unreadable envelope. Only your team’s browsers hold the keys. (Account data we need to run the service — your account email and billing status — is server-readable; the inquiry content is not.)
What about your notification emails and billing?
Neither touches inquiry content. New-lead emails carry only a generic “you have a new lead” notice and a sign-in link, so our email provider never receives the message a visitor submitted. Billing through Stripe sees plan and subscription data only — never lead content.
Does encryption mean HIPAA doesn’t apply?
No — that’s a common myth. Encryption lowers breach risk, but holding PHI would still make a vendor a Business Associate needing a signed BAA. Since Brun does not sign BAAs, our Terms prohibit storing PHI rather than pretending encryption makes the obligation disappear.
More on how the encryption works.
New to zero-knowledge intake? Start with why your intake and CRM must be encrypted, see the mechanics on secure intake, weigh Brun against the alternatives on the comparison page, or head back to the overview.
Not legal advice
This page describes Brun’s architecture and how it relates to HIPAA; it is not legal advice and does not create a Business Associate Agreement. HIPAA obligations depend on your specific practice and data. Because Brun does not sign BAAs and its Terms prohibit storing PHI, confirm your compliance posture with qualified counsel and do not route PHI through Brun.
Intake nobody can read, not even us
Reduce the exposure of sensitive inquiries.
Keep the intake form you already have, encrypt every submission in the visitor’s browser, and work inquiries as leads only your team can open. It won’t make you HIPAA compliant — but for the sensitive inquiries you can store, it removes the readable copy from our side entirely.