Subpoenas & Warrants: What Happens to Your Form Data

Every business running online forms with sensitive content will, at some point, face a variant of this question: what happens if a court, a prosecutor, a tax authority, or a foreign government asks our form vendor to hand over a user's submissions? Most businesses never think about it until the day it happens. By that point, the architectural choice that determines the answer — what the vendor actually has, and in what form — has already been made, years earlier, often without anyone on the business side realising it was a choice at all.

This article walks through what legal process against a form vendor actually looks like, what can and cannot be extracted from the vendor by compulsion, how cross-border orders complicate the picture, and how zero-knowledge architecture fundamentally changes the answer. It is not legal advice — see the disclaimer at the bottom — but it is enough of a map that a privacy officer, general counsel, or privacy-conscious operator can understand the terrain.

What 'Legal Process' Actually Means

'Subpoena' is a US-specific term; elsewhere the vocabulary differs. In Switzerland a prosecutor may issue an Editionsverfügung (order to produce documents); a court may issue a Durchsuchungs- und Beschlagnahmebefehl (search-and-seizure warrant); a tax authority may issue an Auskunftsverfügung; a civil court may compel document production via procedural orders. In EU member states, analogous instruments exist under criminal procedure codes, civil procedure codes, and sector-specific laws (AML, tax, telecoms). At the EU level, European Investigation Orders (EIOs) and the new EU e-Evidence Regulation create cross-border mechanisms. And the US extends its own process abroad through the Stored Communications Act and the CLOUD Act.

The shared shape of these instruments is consistent enough that a single mental model covers most of them:

• A public authority — court, prosecutor, regulator, sometimes a civil litigant — issues a formal demand to the form vendor for specific data about a specific user, account, form, or set of submissions
• The demand is backed by some level of judicial or quasi-judicial process; the vendor does not have unlimited freedom to refuse, but does usually have grounds to challenge
• The demand typically includes a gag clause or non-disclosure obligation preventing the vendor from telling the affected user, at least for a defined period
• The vendor produces what it has, in the form it has it. A well-run vendor pushes back against overbroad demands, asks for narrowing, and exhausts its own objection mechanisms. A less-run-well vendor complies with less scrutiny
• What leaves the door is exactly what the vendor's systems contained — no more, no less

That last bullet is the single most important sentence in this article. Everything else follows from it.

What the Vendor Can Actually Produce

The vendor can only produce what is in its systems. For a typical SaaS form tool, that is typically a lot: the content of every submission, metadata about who submitted what and when, the IP addresses that accessed the form, support tickets that referenced the account, administrative-audit logs, and in some cases the keys and configuration of any encryption the vendor applied at rest. None of this requires breaking a cryptographic system — all of it is sitting in a database the vendor's staff can query.

A zero-knowledge form vendor, by contrast, is structurally in a different place. If the vendor never receives plain-text submissions — if every form answer and every attachment was encrypted in the user's browser against a public key whose private counterpart the vendor never holds — then the vendor's database contains ciphertext only. An order compelling production can still be served and still complied with; what leaves the door is ciphertext with no way to decrypt it. The legal demand is satisfied formally; the operational effect on the affected user's confidentiality is dramatically reduced.

Swiss, EU, and Cross-Border Legal Process

Swiss process against a Swiss vendor

When a Swiss prosecutor or court serves an order on a Swiss-based form vendor, the process stays within Swiss law. The legal basis comes from the Swiss Criminal Procedure Code (StPO/CPP), tax and administrative statutes, and civil procedure. Data-protection rights under the nFADP continue to apply; the data subject may in some cases be informed after a statutory delay, subject to the authority's own disclosure rules. Swiss law also recognises specific privilege categories (legal, medical, religious) that restrict what may be seized. A Swiss vendor operating in good faith scrutinises orders for overbreadth and invokes applicable privileges where relevant.

EU process against an EU vendor

Within the EU, Member-State criminal, tax, and civil procedures govern compelled production. For cross-border criminal investigations, European Investigation Orders (EIOs) allow one Member State's authorities to request evidence held in another. The forthcoming EU e-Evidence Regulation (Regulation (EU) 2023/1543) further streamlines cross-border requests for electronic evidence, including production and preservation orders that can be issued directly to service providers in other Member States.

US process reaching abroad: CLOUD Act

The US Clarifying Lawful Overseas Use of Data (CLOUD) Act, signed in 2018, explicitly extends US legal process to data held by US-based service providers wherever that data is stored — including in the EU and Switzerland. A US prosecutor can serve a warrant on a US-incorporated form vendor and compel production of a Swiss user's form data even if the data itself resides in a Swiss data centre. The CLOUD Act also created an executive-agreement framework under which certain foreign authorities can serve demands directly on US providers; the UK and Australia have such agreements in force.

The practical implication for a Swiss business is straightforward: if your form vendor is incorporated in the US or is a US-majority-owned subsidiary, the data is in the CLOUD Act's reach, regardless of where it is physically stored, and regardless of whether the user is Swiss, German, or French. EU and Swiss data-protection law does not override US jurisdictional reach over a US provider; it only affects what the provider is legally permitted to do under Swiss/EU law, and whether they can defy one law without breaching the other.

Switzerland ↔ foreign jurisdictions: mutual legal assistance

A foreign authority wishing to obtain data held by a Swiss vendor without going through the CLOUD Act (because the Swiss vendor is not US-owned) has one main route: a mutual legal assistance (MLA) request under the Swiss Federal Act on International Mutual Assistance in Criminal Matters (IRSG / IMAC) or a tax-information-exchange agreement. Swiss authorities assess the request, notify the affected person in many cases, and only then compel production. This process is slower, more scrutinised, and more protective of the affected user than a direct domestic warrant would be.

What Happens to the Affected User

When a legal demand targets a user's form submissions, the user typically does not know at the moment the demand is served. Most legal-process instruments include a non-disclosure obligation that prevents the vendor from notifying the user for a defined period, often extendable by further court order. This is designed to preserve the integrity of investigations, and it is also the single reason that 'I trust my vendor to tell me if something like this happens' is generally not a defensible posture — even well-intentioned vendors are often legally prohibited from telling.

After the non-disclosure window ends, vendors with strong privacy practices notify affected users. Some publish annual transparency reports listing aggregate numbers of requests, jurisdictions, and compliance outcomes. Swiss law and many EU laws require some form of eventual notification to the data subject in most cases, once the investigation's secrecy requirements permit. None of this retroactively protects data that was produced in plain text during the window.

What zero-knowledge changes for the user

In a zero-knowledge architecture, the user's submission content is protected from production independent of the vendor's notification practices. Even if the non-disclosure window is open, even if the user never finds out, even if the vendor complies fully and promptly, what the authority receives is ciphertext. For a user who cares about confidentiality — a whistleblower, a patient, a client of a law firm, a political refugee filling in an asylum form — that property is the guarantee that matters, because it does not depend on the vendor's staff, procedures, or legal resources.

What a Zero-Knowledge Architecture Cannot Do

Honesty about limits matters; otherwise the argument shades into marketing. Zero-knowledge encryption has specific properties, and specific gaps.

• It does not hide metadata. Form IDs, submission timestamps, payload sizes, and IP addresses recorded by the hosting provider can all be subject to legal process
• It does not cover account-level data — email addresses of the form owner, billing information, subscription records — unless the vendor applies equivalent controls to those systems
• It does not prevent forward-looking demands. A court can compel a vendor to modify a form going forward, log additional fields, or silently deliver a new payload to a specific user's browser. Jurisdictions vary on whether this is lawful, but it is not blocked by encryption of past data
• It does not protect against a compromise of the key-holder — if the form owner's Access Code is itself compromised, subpoenaed, or given under compulsion, the ciphertext can be decrypted
• It does not replace operational security for high-risk users. A whistleblower submitting via a work device on a corporate network is still identifiable through that device and network, regardless of how strong the form's encryption is

The honest framing is: zero-knowledge architecture ensures that the vendor cannot be compelled to produce readable form-submission content, because the vendor does not have readable form-submission content. That is a significant, specific protection. It is not a universal shield against state power.

Checklist: Evaluating Your Form Vendor's Legal-Process Posture

How Schweizerform Fits This Picture

Schweizerform is incorporated in Switzerland, hosts submission payloads on Swiss infrastructure, and applies zero-knowledge end-to-end encryption to every form submission. Concretely, this means:

• Form submission content and uploaded files are encrypted in the submitter's browser before leaving the device, using keys only the form owner controls — we cannot read them
• A legal demand served on Schweizerform for submission content can be answered only with ciphertext; we do not hold the Access Code and cannot produce it
• Swiss corporate jurisdiction keeps us outside CLOUD Act reach; foreign authorities must route through mutual legal assistance and Swiss review
• We publish clear statements on what we can and cannot produce under legal process, and we challenge overbroad orders where Swiss law permits
• Metadata retention is minimised by default; what we retain is documented in our data-processing policy

This does not make us — or any vendor — a guarantee against all forms of state power. It means that on the specific axis of 'what leaves the door when an order arrives', the architecture is designed to produce the outcome that most people quietly expect when they use an encrypted form: our ability to hand over your users' content is bounded by cryptography, not by our goodwill.

Bottom Line

Legal process against form vendors is routine, quiet, and almost never visible to the users whose data is involved. Whether that process ends with plain-text submissions crossing the threshold of a vendor's office or with useless ciphertext is determined not by the vendor's privacy-policy language but by the vendor's architecture — and by which jurisdiction has the easiest path to compel that architecture.

If the content your users submit is sensitive enough that you would not be comfortable with it surfacing in a court file, the evaluation question is not whether your vendor 'cares about privacy'. It is whether the vendor can physically read the submission and whether the vendor sits in a jurisdiction where that readability is one domestic-court order away from being delivered to a third party. Everything else follows from those two facts.