# Privacy Policy for Swiss Websites (revFADP): what needs to go in What a privacy policy in Switzerland must contain under the revFADP, when the GDPR applies on top, and how I handle this during a website project. Source: https://thomasgaechter.ch/en/blog/privacy-policy-website-switzerland/ Published: 2026-06-08 Updated: 2026-06-08 --- ## Does my Swiss website need a privacy policy? Yes, as soon as your website processes personal data. That happens almost always, since even a server log file with an IP address, a contact form, or embedded Google Analytics counts. The revised Swiss Data Protection Act (revFADP/revDSG) has applied since 1 September 2023 and requires you to inform people clearly about who processes which data for which purpose. Personal data here means any information relating to an identifiable person. An IP address counts, a name in a form certainly does. In practice, every business website therefore has this obligation. Whether it is a business-card page or an online shop makes no difference; only the scope of the policy varies. ## What must go into the privacy policy? The revFADP does not prescribe a fixed template, but the duty to inform sets out what the data subject must learn. These points belong in it: - **Responsible body.** Who operates the website, with company name, address, and a way to make contact. In my case that is tomventures GmbH in Windisch AG. - **Data processed and purpose.** Which data you collect and what for. Example: contact form entries, to answer enquiries. Server logs, to keep the operation secure. - **Third-party services.** Every external tool that receives data. More on that shortly. - **Disclosure abroad.** If data goes to servers outside Switzerland, for example to the US, that must be stated. - **Rights of the data subjects.** Access, correction, deletion, and a reference to the Federal Data Protection and Information Commissioner (FDPIC) as the supervisory authority. - **Retention period**, as far as it can sensibly be given. - **Profiling and automated individual decisions**, if you use anything of the kind. For a normal SMB website usually not. The most common mistake is not a missing policy, but one that hides the embedded third-party services. ## Which third-party services do I have to list? Anything that sends data to a third party when your page loads. These four come up most often, and each of them belongs in the policy: | Service | What it processes | Why it must go in | | --- | --- | --- | | Google Analytics | Usage data, IP (truncated) | Data goes to Google, partly to the US | | Google Fonts (loaded externally) | IP address when fonts are fetched | Avoidable by hosting the fonts locally | | Google Maps (embedded) | IP, location data | Loads from Google when the page opens | | Contact form / newsletter | Name, email, content | Data ends up with you and with the tool provider | My standard advice: host fonts locally instead of loading them from Google, then that data flow disappears. Load Maps only on click. Both make the policy shorter and the site faster. ## revFADP or GDPR, when does which apply? The revFADP is the Swiss law, the GDPR the EU one. They do not exclude each other; sometimes both apply. The key differences: | Topic | revFADP (Switzerland) | GDPR (EU) | | --- | --- | --- | | In force | since 1 Sept 2023 | since 25 May 2018 | | Cookie consent banner | not required | required for non-essential cookies | | Privacy policy | mandatory (duty to inform) | mandatory | | Fine hits | responsible person | company | | Fine level | up to CHF 250,000 | up to EUR 20m / 4% of turnover | | Representative | usually not needed | EU representative may be needed | The practically most important difference: the revFADP does not require a cookie banner, only the information. Anyone based in Switzerland serving a Swiss audience often gets by without a banner. More on that in the article [the revFADP and the cookie banner](/en/blog/revdsg-cookie-banner-switzerland/). The second difference is easily overlooked: the revFADP fine does not hit the GmbH, but the responsible natural person behind it. That is one reason not to put the topic off. ## When do I also need a GDPR policy? As soon as you specifically target people in the EU. That is the case if your shop delivers to the EU, if you aim content or prices in euros at EU customers, or if you actively advertise in the EU. A few random visitors from Germany are not enough; it is about how your offering is directed. When the GDPR applies, quite a bit gets added: a legal basis for each processing activity, a cookie consent banner for non-essential cookies, and often a record of processing activities. In that case it pays to consult a lawyer, especially for a shop. A technical point regardless of location: anyone using Google Ads or Google Analytics has needed Consent Mode v2 since March 2024. Without it, Google no longer delivers complete data in the EU. That is a measurement and advertising question, not a purely legal one, but it belongs to the same building site. ## Is a generator from the web enough? As a scaffold yes, as a finished product rarely. A generator does not know your specific tools. It does not know whether you use Analytics, whether your fonts are hosted locally, or whether your form runs through an external provider. It is exactly these details that make the policy correct or wrong. I do not create legal texts and I am not a lawyer. What I do during a website project: I list cleanly which services your site technically embeds and which data flows arise. On that basis you fill in a generator correctly or have the text checked by a lawyer. For a simple SMB site the first route is usually enough. Binding information and up-to-date templates are provided by the FDPIC at edoeb.admin.ch. That is the official source, not me. ## How do I keep the policy up to date? A privacy policy is not a document you write once and forget. It changes as soon as the technology changes. If you embed a new tool, such as a chat widget, a booking calendar, or a newsletter system, it has to go in. If you switch hosts, the server location may shift. My approach: with every larger change to the website I review the policy alongside it. Anyone with [maintenance](/en/maintenance/) gets this kept up automatically. Anyone tinkering themselves should go through once a year which services are actually still active. You often find an old script that nobody needs anymore and that you can safely remove. ## In short Every business website in Switzerland needs a privacy policy. It names the responsible body, the purpose and data, all third-party services, any disclosure abroad, and the rights of the data subjects. The revFADP does not require a cookie banner; the GDPR does, as soon as you specifically serve EU customers. Keep the document in sync with the technology, otherwise it no longer fits after the next tool change. During a [website project](/en/webdesign/) I build the data groundwork cleanly from the start, so that your policy matches the technology in use. The legally binding text is then provided by a generator or the lawyer, not by me.