# Privacy by Design im Schweizer Recht – 7 Prinzipien > Privacy by Design und by Default nach Art. 7 DSG und Art. 25 DSGVO: die sieben Prinzipien und wie sie im Entwicklungsprozess umgesetzt werden. - Quelle: https://www.sidd.swiss/einblicke/privacy-by-design-schweiz/ - Sprache: de-CH - Veröffentlicht: 2026-05-24 - Stand: 2026-05-24 - Autor:in: Marc Grob - Herausgeber: SIDD Institut für Datenschutz und Datensicherheit, eine Marke der Priverion GmbH, Zugerstrasse 32, 6340 Baar (ZG), Schweiz ## Einleitung Privacy by Design ist mit dem revidierten Datenschutzgesetz (DSG) seit dem 1. September 2023 in der Schweiz erstmals explizite Rechtspflicht. Art. 7 DSG verlangt vom Verantwortlichen, technische und organisatorische Massnahmen bereits in der Planungsphase einer Bearbeitung vorzusehen und durch datenschutzfreundliche Voreinstellungen (Privacy by Default) sicherzustellen, dass nur die für den jeweiligen Zweck notwendigen Personendaten bearbeitet werden. Inhaltlich knüpft die Norm an Art. 25 DSGVO an, wobei der Bundesrat in der DSV (Datenschutzverordnung) keine detaillierten technischen Vorgaben macht, sondern dem Risikoansatz folgt. **Dieser Beitrag behandelt:** - Die sieben Foundational Principles von Ann Cavoukian (Information & Privacy Commissioner Ontario, 2009) als konzeptionelles Gerüst - Die Abbildung jedes Prinzips auf Art. 7 DSG und Art. 25 DSGVO - Konkrete Entwicklungs- und Produkt-Checkpoints (PRD, Design-Review, Code-Review, Threat Modeling) - Nachweisartefakte, die Aufsichtsbehörden wie der EDÖB im Auskunfts- oder Sanktionsverfahren erwarten - Typische Befunde, die in unseren Audits regelmässig zu Korrekturmassnahmen führen Die Zielgruppe sind Product Owner, CTOs und Datenschutzberater, die Privacy by Design nicht als abstraktes Schlagwort, sondern als prüfbares Verfahren in den Software Development Lifecycle (SDLC) integrieren wollen. ## Rechtsrahmen Schweiz und EU Art. 7 Abs. 1 DSG verpflichtet den Verantwortlichen, die Datenbearbeitung technisch und organisatorisch so auszugestalten, dass die Datenschutzvorschriften eingehalten werden, namentlich die Grundsätze nach Art. 6 DSG. Massgebend sind Stand der Technik, Art und Umfang der Bearbeitung sowie das Risiko für die betroffenen Personen. Art. 7 Abs. 3 DSG ergänzt dies durch die Pflicht zu datenschutzfreundlichen Voreinstellungen, also Privacy by Default. Wer ein Bearbeitungssystem entwirft, das standardmässig alle optionalen Felder erhebt, alle Empfänger anzeigt oder Tracking-Cookies vor Einwilligung setzt, verletzt diese Norm. Art. 25 DSGVO formuliert dieselbe Pflicht mit zwei Stossrichtungen: Privacy by Design (Abs. 1, zum Zeitpunkt der Festlegung der Mittel) und Privacy by Default (Abs. 2, beschränkt auf das für den jeweiligen Zweck Erforderliche). Anders als das DSG sieht Art. 83 Abs. 4 lit. a DSGVO bei Verstoss Bussen bis zu 10 Mio. EUR oder 2 % des weltweiten Jahresumsatzes vor. In der Schweiz greift die persönliche Strafnorm von Art. 60–61 DSG, wenn Mindestmassnahmen vorsätzlich unterlassen werden. Praktisch bedeutet das: Wer als Schweizer Unternehmen in der EU Personendaten bearbeitet, muss beide Regime kumulativ erfüllen. Eine saubere Privacy-by-Design-Architektur ist die wirtschaftlichste Lösung, weil sie redundante Compliance-Layer einspart. ## Prinzip 1 und 2 – Proaktiv und als Voreinstellung **Proactive not Reactive; Preventative not Remedial.** Datenschutz wird vor Eintritt eines Risikos adressiert, nicht erst nach einem Vorfall. In der Praxis heisst das: Jede neue Verarbeitungstätigkeit durchläuft vor Go-Live eine Vorabschätzung. Bei hohem Risiko ist eine vollständige Datenschutz-Folgenabschätzung (DSFA) nach Art. 22 DSG bzw. Art. 35 DSGVO Pflicht. Der entscheidende Reifegrad-Indikator: Das Sicherheitsteam wird bereits beim Product Requirements Document (PRD) eingebunden, nicht erst beim Security-Review zwei Wochen vor Release. **Privacy as the Default Setting.** Wenn die betroffene Person nichts tut, müssen ihre Daten geschützt sein. Konkrete Checkpoints: Cookie-Banner mit gleichwertigen Buttons (Akzeptieren / Ablehnen auf einer Ebene), Newsletter-Felder als Opt-in, Profil-Sichtbarkeit standardmässig auf *privat*, Telemetrie-Opt-in statt Opt-out, Geolokalisierung deaktiviert bis zur expliziten Zustimmung. Die EDÖB-Empfehlungen zu Cookie-Bannern (Stand 2024) und die EDSA-Guidelines 4/2019 zu Art. 25 DSGVO geben hier den Massstab. Nachweisartefakt: Ein Default-Settings-Inventar im Verzeichnis der Bearbeitungstätigkeiten (Art. 12 DSG), das pro Feature dokumentiert, welche Voreinstellung gewählt wurde und mit welcher Begründung. ## Prinzip 3 und 4 – Eingebettet und positiv-summativ **Privacy Embedded into Design.** Datenschutz ist nicht Add-on, sondern Bestandteil der Systemarchitektur. Architekturmuster: getrennte Datenspeicher für personenbezogene und nicht-personenbezogene Daten, Pseudonymisierung an der Persistence-Layer, Mandantentrennung durch Row-Level-Security, Ereignis-Logging ohne Klardaten. Threat-Modeling-Frameworks wie LINDDUN (Linkability, Identifiability, Non-repudiation, Detectability, Disclosure, Unawareness, Non-compliance) ergänzen STRIDE um Datenschutz-Risiken und liefern strukturierte Eingaben für die Architektur-Review. **Full Functionality – Positive-Sum, not Zero-Sum.** Cavoukian betont, dass Privacy und Funktionalität gleichzeitig erreichbar sind. Pseudonymisierung ermöglicht Produktanalytik, ohne identifizierbare Profile zu schaffen. Differential Privacy ermöglicht aggregierte Auswertungen ohne Rekonstruktion. Confidential Computing (Intel SGX, AMD SEV-SNP) erlaubt Verarbeitung verschlüsselter Daten in der Cloud, ohne dass der Provider Klartext sieht. Wer in der Design-Phase nach dem Positive-Sum-Prinzip arbeitet, vermeidet das spätere Argument: aus Performance-Gründen brauchen wir Klardaten. Audit-Frage des EDÖB im Sanktionsverfahren: Welche Architektur-Alternativen wurden geprüft, und warum wurde die gewählte als grundrechtsschonendste eingestuft? Wer diese Frage nicht beantworten kann, hat Art. 7 DSG nicht erfüllt. ## Prinzip 5 und 6 – Lifecycle-Schutz und Transparenz **End-to-End Security – Full Lifecycle Protection.** Personendaten sind während des gesamten Lebenszyklus geschützt: Erhebung, Übermittlung, Verarbeitung, Speicherung, Löschung. Konkret bedeutet das Verschlüsselung in transit (TLS 1.2+, mTLS bei API-zu-API), Verschlüsselung at rest (AES-256 mit Schlüsselrotation), Backup-Verschlüsselung, sichere Schlüsselverwaltung (KMS / HSM, idealerweise Customer-Managed Keys bei Cloud-Anbietern) sowie verifizierbare Löschverfahren. Die Löschpflicht aus Art. 6 Abs. 4 DSG (Verhältnismässigkeit, Zweckbindung) wird nur erfüllt, wenn das System Aufbewahrungsfristen technisch durchsetzt – nicht durch organisatorische Erinnerung. **Visibility and Transparency.** Die Verarbeitung muss nachprüfbar sein. Das schweizerische Pendant findet sich in Art. 19–21 DSG (Informationspflicht), Art. 25 DSG (Auskunftsrecht) und Art. 28 DSG (Datenherausgabe). Privacy by Design heisst hier: Die Datenschutzerklärung wird aus dem Verzeichnis der Bearbeitungstätigkeiten generiert und nicht manuell gepflegt, Auskunftsbegehren werden durch Self-Service-Portale unterstützt, und das System protokolliert, wer wann auf welche Personendaten zugegriffen hat (Access Logs mit Begründungsfeld bei sensitiven Daten nach Art. 5 lit. c DSG). Nachweisartefakt: Ein Data-Lineage-Diagramm, das für jede Datenkategorie zeigt, wo sie entsteht, durch welche Systeme sie fliesst und wo sie persistiert wird. ## Prinzip 7 – Respekt vor der betroffenen Person **Respect for User Privacy – Keep It User-Centric.** Das siebte Prinzip operationalisiert die Betroffenenrechte aus Art. 25–32 DSG bzw. Art. 12–22 DSGVO im Produktdesign. Konkrete Checkpoints im SDLC: - **Auskunftsrecht (Art. 25 DSG):** Self-Service-Export im Standardformat (JSON / CSV), nicht nur ein PDF-Download eines unstrukturierten Reports. - **Berichtigungsrecht (Art. 32 Abs. 1 DSG):** Profil-Editor mit Audit-Trail, automatische Propagation in nachgelagerte Systeme. - **Löschungsrecht (Art. 32 Abs. 2 lit. c DSG):** Konto-Löschung mit kaskadierter Löschung in Datenbanken, Backups (nach Rotationszyklus), Logs und SaaS-Subprozessoren. - **Datenportabilität (Art. 28 DSG, Art. 20 DSGVO):** Strukturierter Export, maschinenlesbar, dokumentiertes Schema. - **Widerspruchsrecht (Art. 30 Abs. 2 lit. b DSG):** Granulare Einwilligungs- und Widerspruchs-Einstellungen pro Verarbeitungszweck. - **Verbot automatisierter Einzelentscheidungen (Art. 21 DSG):** Hinweis im Interface, Mechanismus zur Anforderung menschlicher Überprüfung. Wer diese Rechte erst nach Vertragsabschluss in Excel-Listen abwickelt, hat Privacy by Design verfehlt – unabhängig davon, wie elegant die Backend-Verschlüsselung ist. ## Operationalisierung im SDLC Die sieben Prinzipien werden nur dann wirksam, wenn sie als Pflicht-Checkpoints im Software Development Lifecycle verankert sind. Wir empfehlen vier Gates: 1. **Discovery-Gate (PRD-Review):** Vorabschätzung gemäss Art. 22 DSG. Datenschutzbeauftragte oder Privacy Engineer prüfen, ob neue Personendaten erhoben werden, ob eine neue Bearbeitungstätigkeit entsteht und ob eine DSFA erforderlich ist. 2. **Design-Gate (Architektur-Review):** Threat Modeling mit LINDDUN, Datenminimierung dokumentiert, Default-Settings festgelegt, Datenfluss-Diagramm mit Rechtsgrundlage je Verarbeitungsschritt. 3. **Build-Gate (Code-Review & SAST):** Statische Analyse auf hartkodierte Geheimnisse, fehlende Verschlüsselung, übermässige Log-Inhalte. Pull-Request-Templates mit Privacy-Checklist. 4. **Release-Gate (Pre-Prod-Audit):** Verifikation der Default-Settings im Live-System, Penetrationstest bei hohem Risiko, finale Aktualisierung des Verzeichnisses der Bearbeitungstätigkeiten und der Datenschutzerklärung. Diese Gates kosten initial Velocity, sparen aber im Schnitt 40–60 % der Remediation-Kosten, die nachträgliche Privacy-Fixes verursachen. Bei einer DSFA, die nach Go-Live ein hohes Restrisiko aufdeckt, ist die Konsultation des EDÖB nach Art. 23 DSG vor weiterer Bearbeitung verpflichtend – ein Termin, den keine Geschäftsleitung möchte. Wir empfehlen, die vier Gates im internen Kontrollsystem (IKS) als verbindliche Stage-Gates abzubilden und ihre Durchführung im Verzeichnis der Bearbeitungstätigkeiten als Beweis aufzubewahren. ## Wie SIDD unterstützt SIDD begleitet Schweizer Unternehmen bei der Integration von Privacy by Design in den Produkt- und Software-Entwicklungsprozess. Unsere [Datenschutzberatung Schweiz](https://www.sidd.swiss/leistungen/datenschutzberater-schweiz) umfasst die Erstvermessung Ihres SDLC gegen Art. 7 DSG und Art. 25 DSGVO, die Definition der vier Privacy-Gates, die Erstellung Threat-Modeling- und DSFA-Vorlagen sowie das Coaching Ihrer Product Owner und Privacy Engineers. Für Unternehmen, die parallel ein Informationssicherheits-Managementsystem aufbauen, koppeln wir die Privacy-Gates mit der [ISO 27001 / ISMS-Implementierung](https://www.sidd.swiss/leistungen/isms-iso27001), sodass Sicherheits- und Datenschutzkontrollen aus einem Guss umgesetzt werden. Bei DSGVO-Pflicht ergänzen wir den Mandatsumfang um einen [externen Datenschutzbeauftragten (DSGVO-DPO)](https://www.sidd.swiss/leistungen/datenschutzbeauftragter-eu) und übernehmen die Rolle des [EU-Vertreters nach Art. 27 DSGVO](https://www.sidd.swiss/leistungen/eu-vertreter), wenn Sie keine Niederlassung in der Union haben. Für die laufende Compliance steht die [Priverion-Plattform](https://www.sidd.swiss/priverion-plattform) zur Verfügung – mit Verzeichnis der Bearbeitungstätigkeiten, DSFA-Modul und Betroffenenrechts-Workflow. Vereinbaren Sie ein unverbindliches Erstgespräch über das [Kontaktformular](https://www.sidd.swiss/kontakt) oder fordern Sie direkt eine [Offerte](https://www.sidd.swiss/offerte) an. Wir antworten in der Regel innert 24 Stunden mit einem Vorschlag für den nächsten Schritt. --- Dieses Dokument ist die Markdown-Fassung der oben verlinkten Seite. Zitieren Sie bitte die HTML-URL.