Why Encryption Matters for Form Data
Most online form tools store submissions in plain text. Learn why end-to-end encryption and zero-knowledge architecture are the only way to truly protect sensitive form data.
Every day, millions of people submit sensitive information through online forms — medical histories, financial details, employee feedback, legal documents, and personal identifiers. Behind the scenes, most of that data sits in plain text on a database server, protected by little more than a login password and a promise.
For organisations that collect this data, the question is no longer whether a breach could happen, but when. In this article, we break down why traditional form tools leave your data exposed, how end-to-end encryption changes the equation, and what zero-knowledge architecture actually means in practice.
The Hidden Risk of Plain-Text Form Data
When a respondent clicks "Submit" on a typical form tool, the data travels over an HTTPS connection to the provider's server. HTTPS encrypts data in transit — but once it arrives, the server decrypts it and stores it in plain text. At that point, anyone with database access can read it.
This is not a theoretical vulnerability. It is the default architecture of virtually every mainstream form builder, from free tools to enterprise platforms. The data is readable by:
- The form provider's employees — engineers, support staff, database administrators
- Attackers who gain access through a server breach, misconfigured API, or compromised credential
- Government agencies that issue subpoenas or data requests to the provider
- Third-party services connected via integrations, webhooks, or analytics pipelines
The scale of the problem
According to the IBM Cost of a Data Breach Report 2024, the average cost of a data breach reached USD 4.88 million globally — the highest figure ever recorded. Healthcare breaches averaged USD 9.77 million, making it the most expensive industry for the fourteenth consecutive year.
HTTPS protects data while it moves. It does nothing to protect data where it lives. If your form provider can read your submissions, so can anyone who compromises their infrastructure.
What End-to-End Encryption Actually Means
End-to-end encryption (E2EE) is a model where data is encrypted on the sender's device and can only be decrypted by the intended recipient. No intermediary — including the service provider — can access the plain-text content at any point.
In the context of online forms, this means:
- The respondent's browser encrypts the form data before it leaves their device
- The encrypted payload is transmitted over HTTPS and stored on the server as ciphertext
- The server never possesses the decryption key — it stores data it cannot read
- Only the form owner, using their private key, can decrypt and view the submissions
This is fundamentally different from "encryption at rest", where the server encrypts data with its own key after receiving it in plain text. With encryption at rest, the server still has the key — the protection is against someone stealing the physical disk, not against a software breach or insider access.
E2EE vs encryption at rest
Encryption at rest protects data from physical theft of hardware. End-to-end encryption protects data from everyone except the intended recipient — including the platform operator. They solve different problems.
Zero-Knowledge Architecture: Trust by Design
A zero-knowledge architecture takes E2EE a step further. The system is designed so that the service provider never has the technical ability to access your data — not by policy, but by cryptographic design. There is no master key, no admin backdoor, and no way for support staff to "look up" a submission.
This matters because trust-based security is fragile. Policies change, employees make mistakes, and companies get acquired. Cryptographic guarantees are not subject to any of these risks.
| Approach | Server can read data? | Protection scope |
|---|---|---|
| Plain text (most form tools) | Yes — full access | None beyond access control |
| Encryption at rest | Yes — server holds the key | Physical disk theft only |
| End-to-end encryption | No — only the recipient can decrypt | Breaches, insider access, subpoenas |
| Zero-knowledge E2EE | No — provider cannot decrypt by design | All of the above + provider compromise |
Why It Matters for Compliance
Privacy regulations worldwide are tightening, and many now either require or strongly favour encryption of personal data. If your organisation collects data from individuals in regulated jurisdictions, the encryption model you choose has direct compliance implications.
- Switzerland's nFADP (new Federal Act on Data Protection) requires appropriate technical measures to protect personal data — encryption is explicitly cited as a recommended safeguard
- The EU's GDPR (Article 32) lists encryption as an appropriate technical measure and recognises it as a factor that can reduce the impact of a breach notification obligation
- HIPAA (US healthcare) requires encryption for electronic protected health information (ePHI) in both transit and rest — end-to-end encryption satisfies both
- PCI DSS mandates encryption for cardholder data, and zero-knowledge models eliminate the provider from scope entirely
Reduced breach impact
Under both GDPR and nFADP, encrypted data that is rendered unintelligible to any unauthorised party may not require individual notification in the event of a breach — significantly reducing legal, financial, and reputational exposure.
How Schweizerform Implements This
Schweizerform is built from the ground up on a zero-knowledge, end-to-end encrypted architecture. There is no mode to toggle and no premium tier to unlock — encryption is the default for every form, on every plan.
The encryption flow, step by step
Form creation
When you create a form, your browser generates a unique AES-256 form key and an RSA-OAEP key pair. The private key is encrypted with your Access Code and stored — the server never sees the plain-text private key.
Respondent submission
When someone fills out your form, their browser generates a one-time AES-256-GCM symmetric key, encrypts all answers and file attachments client-side, then wraps the symmetric key with your form's public RSA key.
Server storage
Our servers receive and store only the encrypted ciphertext. The encrypted payload is bound to the specific form and submission using authenticated additional data (AAD), preventing cross-submission tampering.
Owner decryption
When you view submissions, your browser uses your Access Code to derive your master key, unwraps the form's private key, decrypts the submission's symmetric key, and finally decrypts the answers — all in the browser. The server is never involved in decryption.
What this means in practice
- A server breach exposes zero plain-text form data
- Schweizerform employees cannot read your submissions — even if they wanted to
- A government subpoena to Schweizerform yields only encrypted ciphertext
- File attachments are encrypted in the browser before upload — filenames are randomised server-side
- No decryption keys are ever transmitted over the network
Common Objections — and Why They Don't Hold Up
"We already use HTTPS"
HTTPS encrypts the connection between the browser and the server. Once data arrives at the server, it is decrypted and stored in plain text. HTTPS is necessary, but it is not sufficient. It protects data in transit — not at rest, and not from the server operator.
"Our provider encrypts data at rest"
Encryption at rest means the provider encrypts your data on their disk using a key they control. If the provider is breached at the application level (which is how most breaches happen), the attacker gets the key along with the data. Encryption at rest protects against physical disk theft — a relatively rare attack vector compared to software vulnerabilities.
"We trust our form provider"
Trust is not a security model. Employees change, companies get acquired, policies evolve, and mistakes happen. Zero-knowledge encryption removes trust from the equation entirely. Your data is protected by mathematics, not promises.
The only truly secure system is one that doesn't require you to trust the operator. If your form tool can read your data, your data is only as safe as that company's weakest link.
Who Should Be Using Encrypted Forms?
If you collect any of the following through online forms, you should be using end-to-end encryption:
- Patient intake forms, medical questionnaires, or health assessments
- Employee feedback, HR complaints, or whistleblower reports
- Legal client intake, case details, or confidential disclosures
- Financial information, tax details, or insurance claims
- Customer data subject to GDPR, nFADP, HIPAA, or other regulations
- Internal surveys where anonymity and confidentiality are expected
The common thread is simple: if the data would cause harm if exposed, it should never exist in plain text on someone else's server.
The Bottom Line
Encryption is not a premium feature — it is a baseline requirement for any tool that handles sensitive data. The distinction between "encrypted in transit" and "end-to-end encrypted" is the difference between hoping your data is safe and knowing it is.
Schweizerform exists because we believe form data deserves the same level of protection as your banking credentials and private messages. Zero-knowledge, end-to-end encryption, Swiss hosting, and full compliance with nFADP — not as add-ons, but as the foundation.
Schweizerform offers end-to-end encryption on every plan, including the free tier. No credit card required to get started.