How to Create a Privacy Policy: Template and Practical Guide for Swiss Websites

"Could you briefly review our privacy policy? It's a standard template." I get this request about five times a month. And in 80% of cases the privacy policy is not only formally incomplete but substantively wrong — because the template doesn't match the actual data processing.

What a correct privacy policy must contain in 2026, which mistakes I regularly see, and when a generator beats a template — a practical guide.

The legal basis

The revised FADP (Art. 19 ff.) obliges anyone processing personal data to inform the data subjects. This applies regardless of whether you operate a small website or a large platform. For a website, the privacy policy is the usual form of this information.

Important: information must be available before processing, in easily accessible form, and it must be complete. A hidden policy in tiny footer font already doesn't quite meet that.

The 12 building blocks of a correct privacy policy

If you structure the policy according to FADP and (for DACH business) GDPR requirements, you get the following structure:

1. Identity of the controller — company name, address, contact person
2. Contact for data protection inquiries — email or postal address
3. EU representative — if GDPR applies (Art. 27)
4. Which data is processed — categories, not every single data point
5. Purpose of processing — per category
6. Legal basis — consent, contract performance, legitimate interest
7. Retention period — per category, ideally with justification
8. Recipients of data — processors (hoster, CRM, email sender), but also ad networks
9. Cross-border transfers — country, mechanism (standard contractual clauses, adequacy decision)
10. Rights of data subjects — access, rectification, deletion, objection
11. Cookie list — when using tracking
12. Status and versioning — date of last change

In this order or similar logic, every privacy policy should be structured. A pure listing "we use Google Analytics" without this structuring is not a privacy policy — it's a claim.

Three common mistakes at Swiss SMEs

Mistake 1 — Outdated template. The policy was created in 2021 by the IT service provider. Since then: three new tools (HubSpot, Calendly, Vimeo), no policy update. Result: the policy lists three tools, the website uses six. In an FDPIC random check, that's a documented violation.

Mistake 2 — Generic template. "This website uses cookies necessary for function." Which cookies? What purpose? What retention period? Mandatory information missing, the policy is legally incomplete.

Mistake 3 — Hidden US data export. Mailchimp is named without the note that data flows to the US and which mechanism legitimises the export (standard contractual clauses). A reference to the EU-US Data Privacy Framework would also be helpful here.

Generator vs. lawyer — the honest assessment

Generator (Aiara, datenschutzgenerator.de, etc.):

• Pro: cheap (CHF 200-600/year), automatic updates on legal changes, cookie scanner integration
• Con: standard wording, less legal depth for special cases
• Suitable for: standard websites, SMEs, web agencies with many clients

Lawyer (Swiss commercial law firm):

• Pro: tailored, advisory, covers special cases
• Con: expensive (CHF 1,000-3,000 initial effort, annual updates extra), unwieldy for tool updates
• Suitable for: complex B2B data processing, industries with specific compliance requirements (health, finance)

In practice: 90% of SMEs are better served by a good generator. Anyone with complex data processing (such as medical data, financial transactions, HR decisions with algorithms) should go the lawyer route.

The most common third-party tools — and how to mention them

A short list of what occurs at most Swiss SMEs:

• Google Analytics 4 / Google Ads — Recipient: Google Ireland; data export USA with standard contractual clauses; purpose: website statistics / ad optimisation; retention: 14 months (GA4 default).
• Meta Pixel — Recipient: Meta Platforms Ireland; export USA; purpose: ad targeting; retention: 90 days (default).
• HubSpot / Salesforce — Recipient: HubSpot/Salesforce; export USA/EU; purpose: CRM and marketing automation; retention: until end of business relationship.
• Mailchimp / Brevo — Recipient: provider; export depending on provider (Brevo EU, Mailchimp USA); purpose: newsletter distribution; retention: until unsubscribe.
• Calendly — Recipient: Calendly Inc.; export USA; purpose: appointment booking; retention: time-limited after appointment completion.

For each tool you should make these five disclosures in the policy. Generic "we use third-party providers" without specification is not permissible.

Multilingualism — the often forgotten topic

A German-language privacy policy on a DE/FR/IT website is a classic compliance gap. The FADP doesn't explicitly require multilingualism, but "easy accessibility" practically means information must be understandable for the target audience.

In practice: if you have a multilingual website, you need a multilingual privacy policy. With Aiara this happens automatically — when setting up the generator, the policy is created in all four languages DE/FR/IT/EN in parallel and kept in sync.

Practical checklist

Before every major website update:

• Does the privacy policy update in sync with the tools?
• Are all currently used third-party providers named?
• Is the date of last update visible?
• Are all cross-border transfers disclosed with mechanism?
• Is the policy available in all languages of the website?
• Is there an access process with clearly defined recipient?

What Aiara does concretely here

Aiara generates the privacy policy based on your cookie scan and your inputs in the questionnaire. The system knows the most common third-party tools and automatically fills in the mandatory information. On cookie changes on the website, the policy adapts. Versioning is built in — earlier versions remain accessible, which is gold worth at access requests or audits.