# Website Privacy Policy Switzerland: Template + Implementation Guide > Embedding the privacy policy on your website: accessibility, implementation in the CMS, cookie banner, multilingual versions and versioning. - Source: https://www.sidd.swiss/en/insights/website-privacy-policy-switzerland/ - Language: en - Published: 2026-05-24 - Last updated: 2026-05-24 - Author: Marc Grob - Publisher: SIDD Institute for Data Protection and Data Security, a brand of Priverion GmbH, Zugerstrasse 32, 6340 Baar (ZG), Switzerland ## Introduction A privacy policy with correct content misses its purpose if it is poorly embedded on the website: not reachable from every sub-page, missing in some language versions, not aligned with the cookie banner, without a stable URL and without a version stamp. This article addresses web managers and external agencies who need to embed an DSG-compliant privacy policy in CMS systems such as WordPress, Webflow, Wix or Shopify, including cookie-banner integration, multilingual maintenance and evidenced versioning. Topics covered: - the five reachability requirements for a privacy policy under Art. 19 DSG; - CMS-specific embedding in WordPress, Webflow, Wix and Shopify; - consistency between cookie banner, consent management platform and policy; - multilingualism DE/FR/IT/EN with synchronised content and stable language URLs; - stable URL and anchor structure for deep links from e-mails and terms; - versioning with effective date and archiving of previous versions as evidence; - duty to update on every new tool or processor. The aim is a privacy policy that grows with every functional change to the website, and which, in an FDPIC procedure, can be evidenced to have been in today's wording at the time of the data collection. ## Reachability and footer embedding Art. 19 para. 1 DSG requires "adequate" information. In FDPIC interpretation this includes reachability: the privacy policy must be reachable from every sub-page with a maximum of one click. Practically that means: a link in the persistent footer, visible without scrolling, in a clear font size (at least 12 px), unambiguously labelled "Privacy policy" or "Privacy". "Imprint" or "Legal" as the sole label is not unambiguous. Best practice covers five requirements: 1. **Persistent footer** on every page, every language and inside the checkout flow. 2. **Stable URL** such as /datenschutz or /privacy that will still be valid in five years. Permanent (301) redirects on path changes. 3. **Anchors in the document** (#purposes, #recipients, #third-countries) so confirmation e-mails and terms can deep-link. 4. **Crawler clearance**, the privacy policy should remain indexable, not blocked in robots.txt. 5. **Print stylesheet**, so access requests can be answered with a printable snapshot. In checkout flows (e-commerce, application forms, newsletter signup) a notice with a link to the relevant section of the privacy policy is additionally needed at the point of data collection, Art. 19 para. 1 DSG requires information "at collection". ## CMS-specific embedding **WordPress**: create a dedicated "Page" and mark it in the Customizer as "Privacy Policy Page" (Settings > Privacy). This activates the native WP hook for plugins that document their own data processing (Contact Form 7, WooCommerce). Footer link via the theme Customizer or block editor. Caution: caching plugins must be configured so that updates to the privacy policy are immediately visible, delayed delivery counts as outdated information. **Webflow**: a CMS collection "Legal Pages" with fields Title, Slug, Body and Effective Date. Footer link via the global layout. Localisation via Webflow Localization (DE/FR/IT/EN), important: maintain the effective date as a custom field, not via the default "Updated" field, because the latter changes on every save. **Wix / Squarespace**: a dedicated "Privacy Policy" page, listed in the site navigation as a footer entry. Multilingualism via the multilingual module, on Wix language URLs are structured as /de/datenschutz, which is fine for search-engine indexing. **Shopify**: the native "Legal" page (Settings > Policies > Privacy policy), automatically linked in checkout. Anyone running a Shopify site for Switzerland should replace the pre-loaded GDPR text with an DSG-compliant version, the default template is GDPR-centric and has DSG gaps on third-country transfers and profiling. Detailed CMS notes are in our articles [Shopify privacy policy Switzerland](https://www.sidd.swiss/einblicke/shopify-datenschutzerklaerung-schweiz) and [Wix privacy policy Switzerland](https://www.sidd.swiss/einblicke/wix-datenschutzerklaerung-schweiz). ## Cookie banner and consent management The privacy policy and the cookie banner belong together substantively. Inconsistencies, the banner lists a tool missing from the policy, or vice versa, are regularly the first finding in FDPIC procedures. In Switzerland, the banner must be transparent under Art. 45c lit. b of the Telecommunications Act and offer an objection option; active consent ("opt-in") is mandatory only for advertising tracking cookies with an EU nexus under GDPR/ePrivacy. An integrated architecture covers: - **Consent management platform (CMP)** such as Cookiebot, Usercentrics or Iubenda that automatically scans all set cookies and their providers and maintains a versioned consent log. - **Cookie table inside the privacy policy**, exported from the CMP and identical to the list shown in the banner. - **Granular categories** (Necessary / Statistics / Marketing / External media), not only "Accept all" and "Necessary". - **Easy re-invocation** of the banner (footer link "Cookie settings") so consent can be withdrawn at any time. For tools with US back-ends (Google Analytics, HubSpot, Meta Pixel) the third-country transfer belongs in the policy, with a note on Swiss-U.S. DPF certification or standard contractual clauses. Detailed banner templates: [Cookie banner Switzerland](https://www.sidd.swiss/einblicke/cookie-banner-schweiz). ## Multilingualism and language URLs Anyone running a multilingual Swiss website must hold the privacy policy in every published language, not only in the official languages at the seat, but in every language the offer is actually marketed in. In language versions where the policy is missing, the information is not "adequate" within the meaning of Art. 19 para. 1 DSG. Three architectural decisions: 1. **Stable language URLs** such as /datenschutz, /fr/protection-des-donnees, /it/protezione-dei-dati, /en/privacy. With hreflang annotations for search engines. 2. **Synchronised content**: a change in one language version requires the others to follow. A documented review process ("language sync before publication") is standard. In disputes the contract-language version prevails, for Swiss SMEs typically German. 3. **Language-specific contacts** only where they make sense, e.g. a French-language mailbox for Romandie customers. Where no language-specific desk exists, name the central address in each language version rather than fabricating a local one. When working with translation providers, explicitly mark the privacy policy as a "legally relevant document", the standard marketing translation path is not enough because legal terminology (e.g. "recipient" vs. "category of recipients") must be precise. ## Versioning, effective date, archiving A privacy policy without a visible version reference is hard to defend in a damage case. The standard is a version stamp at the end of the policy ("Version 3.2, in force since 1 March 2026") and an internal archive path that preserves each previous version as a PDF snapshot for at least 10 years, analogous to retention duties under Art. 958f CO for business records. Operational recommendations: - For material changes (new data category, new processor, new third-country recipient, new profiling), actively inform registered users by e-mail and respect a 14-30 day transition window. - For purely editorial changes without new mandatory items, silent publication with a new version stamp is enough. - Generate PDF archive snapshots automatically on the publish event, signed with a timestamp, qualified timestamps under ZertES are persuasive in proceedings; simple UTC timestamps suffice in the majority of cases. - An internal change log with diff against the previous version and the reason for the change, as evidence of orderly maintenance in any FDPIC procedure under Art. 49-53 DSG. Anyone maintaining the privacy policy manually should run a semi-annual plausibility check against the records of processing (Art. 12 DSG). ## Update triggers and maintenance cycles The privacy policy must mirror actual processing at every point in time. From more than 200 SIDD audits in 2024-2025, seven update triggers stand out: 1. **New processor** (e.g. switch of the newsletter tool, new CRM provider, new helpdesk system). 2. **New recipient category** (e.g. first-time handover to a debt-collection agency). 3. **New third-country transfer** (e.g. migration from an EU to a US cloud provider). 4. **New data category** or first-time processing of specially protected personal data (Art. 5 lit. c DSG). 5. **New purpose** (e.g. launch of a loyalty programme, new marketing channel). 6. **New automated decision system** or profiling (Art. 21 DSG, possibly with a DPIA duty under Art. 22 DSG). 7. **Material legal change** (e.g. new FDPIC guidance, new EDPB guidelines, new Swiss SCCs). A documented maintenance procedure, typically as a RACI matrix between marketing, IT, legal and DPO, prevents the privacy policy from drifting from the actual processing state after 12-18 months. ## How SIDD supports you SIDD takes on the drafting and ongoing maintenance of the privacy policy typically as part of a [DSB mandate](https://www.sidd.swiss/en/services/data-protection-advisor-switzerland). Operational maintenance runs through the [Priverion platform](https://www.sidd.swiss/en/priverion-platform), which holds records of processing, DPA inventory and privacy policy in one data model, changes to the processor master propagate automatically to the published policy. For Webflow and WordPress sites we offer pre-built integration packages with automatic language sync. For the cookie-banner side we support CMP selection and configuration as well as alignment between banner and policy. Companies that are additionally GDPR-bound get [GDPR DPO services](https://www.sidd.swiss/en/services/data-protection-officer-eu) and an [EU representative](https://www.sidd.swiss/en/services/eu-representative). An audit of your current website embedding (footer, cookie banner, language versions, versioning) typically takes 90 minutes, request via [our contact form](https://www.sidd.swiss/en/contact); for a concrete fixed-price mandate covering drafting and integration, use the [quote request](https://www.sidd.swiss/en/quote). --- This document is the Markdown rendition of the page linked above. Please cite the HTML URL.