Data Processing Agreements (DPA) in Switzerland: When You Need One — With a Checklist

«Do we actually have a contract with our hosting provider about the data?» I ask Swiss SMEs this question regularly — and the most common answer is a shrug. Yet the Data Processing Agreement (DPA) is not a nice-to-have for large corporations. It is a legal obligation the moment a service provider processes personal data for you. Which, in practice, is almost always.

When you need a DPA, what belongs in it, and why you should never adopt a template from the internet unchecked — a practical guide with a checklist.

Two legal frameworks, one concept

First, some terminology. The Swiss Federal Act on Data Protection (FADP) covers the arrangement in Article 9, called «processing by processors»: a controller has personal data processed by a third party on its behalf. The European General Data Protection Regulation (GDPR) regulates the same concept in Article 28.

Both describe the identical constellation: you decide on the purpose and means of the data processing, and a third party carries it out on your instructions. The contract governing this relationship is the Data Processing Agreement — in German-speaking Switzerland usually called «Auftragsverarbeitungsvertrag» or AVV. Whoever searches for a Swiss DPA template means exactly the document that Article 9 FADP and Article 28 GDPR require.

When do you need a DPA?

The rule of thumb: as soon as an external provider processes personal data whose purpose you determine, a DPA is required. «Processing» is defined broadly — mere storage or technical access is enough.

Typical cases at Swiss SMEs:

• Hosting providers — your website with its contact form runs on third-party servers; the host stores personal data for you.
• Newsletter tools (Brevo, Mailchimp) — your subscribers' email addresses live with the provider.
• Cloud storage and office suites (Microsoft 365, Google Workspace) — client files, HR documents, email traffic.
• CRM and accounting software — customer data, payment information.
• Web agencies with maintenance access — anyone with access to your live database for updates processes personal data on your behalf.
• Cookie consent providers — often overlooked: the logged consents contain timestamps and technical identifiers. Your consent tool is a processor too.

The list shows: an average SME has not one but five to fifteen processors. Each one needs a contract.

When do you not need a DPA?

The delimitation matters just as much. No DPA is needed with parties that process personal data under their own responsibility — deciding on purpose and means themselves. Classic examples: the bank handling payments, the postal service delivering mail, the lawyer acting under a mandate, the auditors reviewing your books. These are controllers in their own right, not processors.

Equally, no DPA is needed for services that never touch personal data — say, a licensing provider for fonts you embed locally. When in doubt, ask the control question: «Could this provider theoretically access personal data I am responsible for?» If yes, talk about a DPA.

One special case that concerns web agencies in particular: the same company can hold both roles at once. The agency maintaining websites for its clients acts as a processor — but for its own customer records and invoicing it is a controller in its own right. What counts is always the specific processing activity, not the company sign. Agencies handling client projects should therefore proactively offer every client a DPA — by now that is simply a mark of professionalism.

What Article 9 FADP actually requires

The Swiss act is refreshingly compact on this topic. Article 9 FADP sets four conditions:

1. The processing may only be carried out in a way you would be permitted to do yourself.
2. No statutory or contractual duty of confidentiality may prohibit the outsourcing.
3. The basis is a contract or the law — this is where the DPA comes in.
4. The processor may only delegate the processing to a third party with your prior approval — the sub-processor issue.

Added to this is the general duty of data security (Article 8 FADP): you must satisfy yourself that the provider protects the data adequately. Article 28 GDPR follows the same logic but in far more detail — it prescribes a catalogue of minimum contract contents. If you have customers in the EU, it therefore makes sense to follow the stricter GDPR standard, which covers the FADP at the same time.

The checklist: what belongs in every DPA

Whether you are reviewing a provider's DPA or starting from a template — these points must be covered:

• Subject matter and duration — What service is provided, how long does the contract run, what happens on termination?
• Nature and purpose of the processing — Data categories and the groups of data subjects (customers, employees, website visitors).
• Processing on documented instructions — The provider processes data exclusively on your documented instructions, never for its own purposes.
• Confidentiality — Everyone with data access is bound to secrecy.
• Technical and organisational measures — Encryption, access control, backups; described concretely, not just «appropriate security» as a stock phrase.
• Sub-processors — A list of the subcontractors used, an approval mechanism and a duty to notify changes.
• Assistance duties — The provider supports you with data subject requests and reports data breaches without delay.
• Deletion and return — After the contract ends, data is returned or verifiably deleted.
• Audit rights — You may verify compliance or request recognised evidence (certifications, audit reports).
• Data transfers abroad — Where are the servers, and which safeguards cover a transfer (for instance standard contractual clauses)?

If one of these points is missing, the contract has a gap — and in a dispute, the burden of proof is on you.

Does a GDPR DPA also work for the Swiss FADP?

The question comes up in every consultation: the US cloud provider presents a GDPR contract — is that enough for Switzerland? The short answer: in substance almost always; formally, two points deserve a look.

First, the contract should explicitly include Swiss data protection law — many international providers have added a Switzerland clause to their DPAs by now. Second, Article 9 paragraph 3 FADP requires prior approval of sub-processors; a pure objection mechanism, as some GDPR contracts provide, should therefore be cleanly framed as a general authorisation with a duty to inform. If both points are covered, a GDPR contract serves you well under the FADP too.

Why we do not offer a copy-paste template here

A word on expectations: you will deliberately not find a contract text to copy out of this article. A DPA governs liability — and a template that does not match your constellation creates more risk than it removes. Who guarantees, in a dispute, that the copied technical and organisational measures actually exist at your specific provider?

You can recognise a serious Swiss DPA template by three things: it covers all ten points of the checklist above, it names the FADP explicitly, and it leaves room for the concrete details — data categories, sub-processors, server locations. Those gaps are yours to fill. Otherwise the template is legally worthless, just like privacy policies taken straight from a boilerplate.

How to build your DPA inventory

Before you review contracts, you need the overview: which providers actually process personal data for you? Three sources produce the list within an hour:

1. Your own privacy policy — all recipients of personal data should already be listed there. If it is up to date, it is your best inventory.
2. A cookie scan of your website — it shows which third-party services are actually embedded, including the tools nobody had on the radar anymore.
3. Your accounts payable — every recurring software invoice is a candidate. If you pay monthly, data is very likely being processed.

For each entry, record: is there a DPA, in which version, dated when — and where is it stored? In an audit, this simple table is worth more than any folder full of unread contract PDFs. For providers with servers outside Switzerland and the EU, also note the transfer basis — usually the standard contractual clauses with the Swiss amendments.

Three mistakes from practice

Mistake 1 — Forgetting the «small» tools. The DPA with Microsoft is signed, but the appointment booking tool, the chat widget provider and the consent tool run without a contract. It is precisely the small services that audits find first.

Mistake 2 — Sign and file away. The DPA was concluded in 2023; since then the provider has changed its sub-processor list three times. Ignoring those change notifications means approving blindly — and neglecting your own duty to review.

Mistake 3 — No proof. When things go wrong, the Federal Data Protection and Information Commissioner (FDPIC) or the opposing counsel asks: «Which contract version was in force on the day of the breach?» A PDF somewhere in the mail archive, without version and signing date, is weak evidence.

How Aiara solves this for its customers

As a cookie consent provider, Aiara is itself a processor for its customers — the consent logs are personal data. That is why Aiara offers the DPA as a self-service in its Trust Center: you conclude the contract digitally, in German, French, Italian or English. Every conclusion is sealed with a SHA-256 hash — a cryptographic fingerprint of the document that proves at any time which contract version you accepted, and when. No paperwork, no email ping-pong, and the audit evidence remains permanently retrievable.

That is how concluding a DPA should work in 2026, with every one of your providers. Where it does not, you now know what to ask for — the checklist above is your review grid.