Encrypted forms

Most "secure" forms encrypt data in transit (TLS) and on our disks — but the server still sees your responses in the clear. Encrypted forms are different: the data is encrypted on the respondent's device before it ever leaves their browser, using your public key. It reaches us already sealed. There is no point at which our servers, our staff, or anyone who compromised them could read a submission.

We didn't invent our own crypto. Encrypted forms use OpenPGP — the open, standardised, decades-scrutinised protocol behind PGP and GnuPG (RFC 9580). The encryption runs in your browser via the audited OpenPGP.js library, with modern Curve25519 elliptic-curve keys selected by default. Your keys are real OpenPGP keys: you can decrypt your responses with GnuPG or any other OpenPGP tool, not just with us.

In 1991, Phil Zimmermann wrote Pretty Good Privacy — the first strong, freely available encryption for ordinary people — and released it to the world. He built it so that human-rights activists, journalists, and dissidents could communicate without their governments reading along.

At the time, strong cryptography was classed as a munition under US export law. When PGP spread overseas, Zimmermann became the target of a three-year criminal investigation for "exporting munitions without a license." In a now-famous act of protest, the entire PGP source code was printed as a book and shipped abroad — because exporting a book was protected speech under the First Amendment, even when exporting the same bytes was not. The case was dropped in 1996, a pivotal moment in the "crypto wars" that won everyday people the right to real privacy.

PGP's format was later standardised as OpenPGP so anyone could implement it openly. Thirty years on, that same standard quietly secures the most sensitive submissions to your forms.

1. Turn on encryption for a form and generate a keypair — right in your browser.
2. Download and safely store your private key. We only ever receive the public half.
3. Share your form. Every visitor's browser encrypts their answers to your public key.
4. We store the sealed ciphertext. Notifications and integrations carry no readable content.
5. To read a response, unlock it in your dashboard with your private key. Decryption happens locally — your key never touches our servers.

Attachments are encrypted in the browser the same way before upload. We store only the ciphertext, under a random name, with no readable filename or type. You decrypt and download them locally when you review the response.

This is the whole point — and the responsibility. If you lose your private key, your form's responses are gone for good. We cannot reset it, recover it, or read around it, because we never had it. Store your key the way you'd store the keys to a safe.

Client intake, witness statements, and conflict checks arrive as ciphertext, sealed in the respondent's browser to your firm's public key — our infrastructure never receives readable content, and your private key stays in your hands. It's a concrete way to support the reasonable efforts to prevent unauthorized access that ABA Model Rule 1.6(c) asks of you, and it leaves a vendor with nothing readable to hand to a subpoena. Whether any given incident triggers notification remains your judgment under ABA Formal Opinion 483 — the decision stays with you.

Intake forms, PHQ-9 and GAD-7 scores, and history questionnaires are among the most sensitive records a practice holds — and under the HIPAA Breach Notification Rule, you are the one who must notify patients and OCR if they leak. Each response is encrypted in the respondent's browser to your public key, so we store only ciphertext and never hold the means to read it — designed to help your data meet HHS's standard for secured PHI, the difference between a quiet non-event and a reportable breach. A vendor that stores your encrypted responses is still a business associate, so you'll still need a signed BAA in place.

Under the EU Whistleblower Directive (2019/1937), a reporter's identity — and any detail it could be deduced from — may not reach anyone beyond your authorised compliance handlers without their consent. Each submission is sealed in the reporter's browser to your team's public key, so we store only ciphertext and never hold a key that could open it. That keeps the circle of people who can read a report limited to exactly the staff the law intends, helping you meet your confidentiality duty and reduce the retaliation risk that follows a leak.

Protecting a source is a promise you may one day have to keep in front of a judge. When tips are encrypted in the source's browser to your newsroom's public key, the form vendor only ever holds ciphertext — so a subpoena or seizure served on the vendor produces nothing readable, and the decision to fight stays where it belongs: with you. That matters more than ever, with federal shield protections still unsettled and the Justice Department's 2025 rollback of internal limits on subpoenaing journalists' records. End-to-end protects what a source writes, not their network identity — for full source anonymity, pair it with a tool like SecureDrop.

If you collect Social Security numbers, bank details, and KYC documents, the FTC Safeguards Rule expects you to encrypt customer information in transit and at rest, and your written security program commits you to keeping it confidential. Every submission is encrypted in the client's browser to your public key, so we store ciphertext we can't decrypt and the only readable copy lives behind the one private key you hold. A breach of our systems is not a reportable exposure of your clients' data — though once you decrypt and store submissions in your own systems, protecting that copy remains your responsibility.

For human rights monitors, crisis advocates, and refugee caseworkers, a data breach is not a compliance footnote — it can put a real person in front of the people they fled. Most secure forms encrypt submissions on the vendor's servers, which means the vendor still holds the keys and can be hacked, subpoenaed, or pressured into producing plaintext. We encrypt every response in the respondent's browser to your public key and store only the ciphertext, so we have nothing readable to surrender — helping you uphold confidentiality duties under frameworks like VAWA, FVPSA, and UNHCR's data-protection policy, while keeping the decision about who ever reads a testimony entirely in your hands.

An unpatched vulnerability and a working proof-of-concept stay dangerous until the fix ships, so the intake channel has to be at least as trustworthy as the team receiving it. A form whose vendor can read submissions quietly aggregates every inbound exploit, credential, and incident detail into someone else's database — exactly the target an attacker would choose. We encrypt each response in the reporter's browser to your public key, so we only ever store ciphertext and you hold the only key that opens it — a confidential channel by design, consistent with RFC 9116's encryption field and ISO/IEC 29147's call for a secure communication option, without asking researchers to wrangle PGP first.

Accommodation requests, harassment and grievance reports, and diversity self-ID collect exactly the data the law treats as most sensitive — health, ethnicity, and protected-class details that fall under GDPR Article 9 as special-category data. Sealing each submission in the employee's browser to your team's public key keeps it out of vendor-readable storage and narrows who inside the organization can ever open it — reducing both your breach exposure and the trust you're asking employees to extend when they disclose something difficult.