Do You Need a Data Processing Agreement for Your Form Tool?

«Is there a data processing agreement available?» is one of the first questions a procurement or compliance reviewer asks a form vendor, and it deserves a better answer than «yes, here is a PDF». The short version: if a tool stores or transmits responses on your behalf, it is your processor, you are the controller, and you need a contract governing that relationship. The longer and more useful version is that the Swiss requirement is considerably thinner than the European one, that most Swiss organisations are governed by both at once, and that a signed agreement fixes fewer of the real risks than the person collecting signatures usually believes.

This article is the practical companion to our nFADP compliance guide for online forms. That one covers the whole obligation set; this one goes deep on the single document everyone asks for, and on the gap between what it says and what it achieves.

What Is a Data Processing Agreement — and What Is It Called in Switzerland?

It is the contract that governs a provider processing personal data on your instructions. The names differ by jurisdiction and language, which is itself a source of confusion in Swiss procurement, where a single file may need to satisfy reviewers in four languages:

• EN — data processing agreement (DPA), sometimes data processing addendum, which is why vendors abbreviate both as DPA.
• DE (EU usage) — Auftragsverarbeitungsvertrag, universally shortened to AVV. This is the term German-speaking buyers search for and the one most Swiss vendors put on the file.
• DE (Swiss statute) — the nFADP calls the party an Auftragsbearbeiter, not an Auftragsverarbeiter, so the strictly correct Swiss term is Auftragsbearbeitungsvertrag. Both are understood; the AVV label is more findable.
• FR — contrat de sous-traitance, the provider being the sous-traitant.
• IT — contratto sul trattamento dei dati; the nLPD calls the provider the responsabile del trattamento and you the titolare del trattamento.

Do You Need a DPA for Your Form Tool?

Almost certainly yes. The test is not the size of your organisation or the sensitivity of the data — it is the structure of the relationship. Art. 5 lit. j nFADP defines the controller as the person who decides on the purpose and means of the processing; lit. k defines the processor as the one who processes personal data on the controller's behalf. You chose the questions, you decide who the responses are for, you decide when they are deleted. That makes you the controller of every submission, even on a free plan.

When the tool is not your processor at all

There is one important exception, and it is worse rather than better. A provider that uses the data for its own purposes — profiling respondents, training models on submissions, enriching an advertising graph, selling aggregate insights — is not acting solely on your instructions for those purposes. To that extent it is a controller in its own right, and what you are doing is not delegation but disclosure of personal data to a third party, with a different legal basis, a different entry in your privacy notice, and a different conversation with your respondents. This is one of the concrete costs behind our post on the hidden cost of free form tools: the free tier is often free because the processing is not purely on your behalf.

The processors hiding behind the form tool

The form platform is rarely the only one. A typical form stack also involves an email service that sends the notification containing the answers, an object store holding uploaded files, a spreadsheet or CRM the responses are exported to, and increasingly an AI provider behind a summarisation or translation feature. Each is either a subprocessor of your form vendor or a processor of yours directly. The DPA question is not «did the vendor send me a PDF» but «is every party that touches this data covered by something».

What Art. 9 nFADP Actually Requires

Less than most people expect, and the surprise usually runs in the direction of «is that really all?». Art. 9 para. 1 nFADP permits processing to be delegated to a processor by contract or by legislation, provided the data is processed only as the controller itself would be permitted to process it, and provided no statutory or contractual duty of confidentiality prohibits the delegation. Art. 9 para. 2 requires the controller to satisfy itself in particular that the processor is able to guarantee data security. Art. 9 para. 3 requires the controller's prior authorisation before the processor delegates onward to a third party. Art. 9 para. 4 lets the processor invoke the same justifications as the controller.

That is the entire provision. There is no statutory list of mandatory clauses in Swiss law, and no express written-form requirement — a delegation can in principle rest on an ordinary contract. Do not read that as permission to skip the document. Art. 61 lit. b nFADP makes it punishable, on complaint and with a fine of up to CHF 250,000 against the responsible natural person, to hand processing to a processor without meeting the conditions of Art. 9 paras. 1 and 2. When a supervisory authority or an opposing party asks how you satisfied yourself about data security, a written agreement plus a security annex is the only answer that survives contact.

What Art. 28 GDPR Adds — and Why It Usually Governs Anyway

The GDPR is far more prescriptive. Art. 28 para. 3 requires a contract, binding on the processor, that sets out the subject matter and duration of the processing, its nature and purpose, the type of personal data and the categories of data subjects, and the obligations and rights of the controller — and that imposes eight specific duties on the processor. Art. 28 para. 9 requires it in writing, including electronic form. Art. 28 para. 2 governs subprocessors, and Art. 28 para. 4 makes the first processor fully liable to you for a subprocessor's failures.

Most Swiss organisations cannot treat this as somebody else's problem. If your form is offered to respondents in the EU — an event registration open to participants across the border, a careers page, a customer survey with German or French clients — the GDPR can apply to you directly by virtue of its targeting rule, alongside the nFADP. The practical consequence is simple and worth stating plainly: draft to Art. 28 and you satisfy Art. 9 as a subset. One document, both regimes. Our side-by-side comparison of GDPR and nFADP for form data covers where else the two diverge.

What Must Be in the DPA? A Checklist

Work through a vendor's document against this list. The first six items are the Art. 28 core; the rest are the ones that decide whether the agreement is any use to you in practice rather than merely present in the file.

1. Scope description. Subject matter, duration, nature and purpose of the processing, categories of personal data and of data subjects. Generic wording like «customer data» is a sign the annex was never adapted to a form product — file uploads and free-text answers deserve their own mention.
2. Processing only on documented instructions, including for any transfer to a third country, with a duty to tell you if the provider believes an instruction breaches the law.
3. Confidentiality: everyone the provider authorises to process the data is bound by confidentiality, contractually or by statute.
4. Security measures, described concretely enough to be assessed — encryption in transit and at rest, key management, access control, tenant separation, backup and restore, penetration-testing cadence. «Industry-standard measures» is not a security annex.
5. Subprocessors: named or listed, with a change-notification mechanism and a right to object.
6. Assistance: with data subject requests, with security incidents, and with impact assessments — with the response times spelled out.
7. Deletion or return at the end of the contract, at your choice, covering backups and a stated backup expiry window. Ask specifically how long deleted responses survive in backups.
8. Audit and information rights, and what the provider offers in practice instead of an on-site audit — a current report, a certification scope, or a completed security questionnaire.
9. Breach notification to you, with a deadline that leaves you able to meet your own. Under Art. 24 para. 1 nFADP you must notify the FDPIC as soon as possible where a breach is likely to result in a high risk; under Art. 33 GDPR you have 72 hours. A vendor promising notice «without undue delay» and nothing more has pushed its problem onto your clock.
10. Locations of processing and the legal basis for any transfer abroad — which is a separate question from this contract, and one our cross-border transfer guide treats in full.
11. Governing law and jurisdiction. For a Swiss controller, Swiss law and a Swiss forum are worth negotiating for, and are one of the concrete wins Swiss framework agreements have achieved with large vendors.
12. Liability and its carve-outs. Read what happens to the liability cap when the failure is a data protection failure; a cap set at one month of fees makes the audit rights above the only real remedy.

The Duties Swiss Law Puts on the Provider Directly

Here is the part that is genuinely different in Switzerland, and that neither party usually mentions in the negotiation: several duties bind the processor by force of law, whether or not your contract repeats them. Under Art. 8 nFADP the controller and the processor must ensure appropriate security through technical and organisational measures. The Data Protection Ordinance then makes that concrete for both of them:

• Art. 1 DPO — the controller and the processor must determine the protection needs of the data and define measures appropriate to the risk, assessed against stated criteria.
• Art. 2 DPO — the measures must deliver confidentiality, availability, integrity and traceability.
• Art. 3 DPO — specific controls are named: access control, entry control, user control, and further measures for availability and integrity.
• Art. 4 DPO — logging of storage, modification, reading, disclosure, deletion and destruction is required where sensitive personal data is processed automatically on a large scale, or high-risk profiling is carried out, and preventive measures cannot ensure protection.
• Art. 5 DPO — a private controller and its private processor must maintain processing regulations for automated processing where they process sensitive personal data on a large scale or carry out high-risk profiling.
• Art. 12 para. 3 nFADP — the processor keeps its own record of processing activities, naming itself and you, the categories of processing carried out on your behalf, its security measures and any transfers abroad.
• Art. 24 para. 3 nFADP — the processor must report a data security breach to the controller as soon as possible. This one is statutory, not merely contractual.

Subprocessors: The Annex Everyone Accepts Without Reading

Art. 9 para. 3 nFADP requires the controller's prior authorisation before a processor passes the work on. Art. 28 para. 2 GDPR allows that authorisation to be specific or general, and where it is general the processor must inform you of intended additions or replacements so that you can object. In practice, hosted form tools are assembled from other people's services, so the list is never empty: cloud infrastructure, object storage, transactional email, error monitoring, support ticketing, and — the newest entrant — a model provider behind any AI feature.

The compliant pattern is unglamorous. Accept the general authorisation, download the subprocessor list on the day you sign, store it with the agreement, and subscribe to the change notifications. The point of keeping the copy is that it establishes what you approved; without it, «we authorised the list» refers to a document that has since changed. The failure pattern is equally consistent: nobody reads the list, an AI feature ships eighteen months later, submissions start reaching a model provider in another jurisdiction, and nothing in the paperwork records that anyone agreed to it.

What a Signed DPA Does Not Buy You

This is the section that matters most, because a DPA is the compliance artefact most likely to be mistaken for a solution. It allocates responsibility between two companies. It does not change what is technically possible, and four gaps in particular survive every signature:

• It does not stop the provider reading your submissions. If responses are stored in a form the provider can decrypt, then support staff, administrators, automated systems and anyone who compromises them can read the content. The contract makes that a breach of contract rather than an impossibility. Encryption at rest does not change this, because the provider holds the keys.
• It does not release you from a secrecy duty. Art. 9 para. 1 lit. b blocks the delegation itself where confidentiality law prohibits it, and Art. 321 of the Criminal Code binds you personally regardless of what your vendor signed.
• It does not make a cross-border transfer lawful. The processor question and the transfer question are separate tests. A perfect Art. 28 contract with a provider in a country without adequate protection still needs standard contractual clauses recognised by the FDPIC and a transfer assessment.
• It does not move liability away from you in the eyes of the data subject. You remain the controller. A contractual indemnity may help you recover from the vendor afterwards; it does not answer the respondent whose data was exposed, and it does not answer the supervisory authority.

A data processing agreement records who is answerable for what. It cannot record who is able to do what — that is decided by the architecture, before anyone reaches for a pen.

Does End-to-End Encryption Remove the Need for a DPA?

No — and any vendor that tells you otherwise is overselling, including us. Even with zero-knowledge encryption, the provider still processes personal data on your behalf: account details, form metadata, submission timestamps, IP-level logs, and the ciphertext itself, which remains personal data as long as someone holds a key to it. You are still the controller, the provider is still your processor, Art. 9 nFADP and Art. 28 GDPR still apply, and you still owe the record of processing under Art. 12 and the privacy notice under Art. 19.

What end-to-end encryption changes is not the existence of the contract but the size of the risk the contract is being asked to carry. When the provider has no usable key, the confidentiality of the answers no longer rests on the provider's staff discipline, its access controls or its subprocessors' behaviour. The Art. 9 para. 1 lit. b obstacle — a confidentiality duty prohibiting delegation — is answered architecturally, because there is no secret to disclose. And the breach analysis shifts: a provider-side incident exposes ciphertext, which is a materially different notification conversation under Art. 24 nFADP, as covered in our post on breach notification and encryption.

How to Get and Keep a DPA From a Form Vendor

Getting the document is the easy half. Keeping it usable — findable, current, and matched to what you actually deployed — is what fails an audit two years later.

Red Flags in a Vendor's Data Processing Agreement

• No DPA at all on the free or entry plan. Common, and disqualifying if you collect other people's personal data on that plan.
• The security annex is a paragraph of adjectives. «State-of-the-art», «bank-grade», «military-grade encryption» — none of these is a control.
• No subprocessor list, or a list with no change-notification commitment.
• Silence on deletion, or deletion promised for the live system with no statement about backups.
• Breach notification «as soon as reasonably practicable» with no outer limit, when your own clock under Art. 24 nFADP and Art. 33 GDPR starts running immediately.
• Unilateral amendment rights over the entire agreement, including the security annex, without notice.
• A Swiss-marketed product whose agreement mentions only the GDPR. Not fatal — Art. 28 wording covers Art. 9 — but it tells you the Swiss review was never done, and Art. 61 nFADP is a Swiss provision.

Bottom Line: Do You Need a Data Processing Agreement for Your Form Tool?

Yes. Any hosted form tool processes personal data on your behalf, which makes it your processor and makes the contract a legal requirement — under Art. 9 nFADP with a fine of up to CHF 250,000 attached to getting it wrong, and under Art. 28 GDPR with a mandatory clause list whenever the European regime reaches you. Draft to Art. 28, keep the subprocessor list, file the agreement with your record of processing, and review it when features change.

Then be clear with yourself about what you have bought. The agreement establishes who is answerable when something goes wrong. It does not determine who can read your submissions — that is decided by the encryption model, and no amount of contractual language changes it. For ordinary form data, a solid DPA with a competent provider is a proportionate answer. For submissions covered by professional secrecy, or where the honest requirement is that nobody outside your organisation can ever read the content, the contract is the second question and the architecture is the first.