Privacy by Design became an explicit legal obligation in Switzerland with the revised Federal Act on Data Protection (DSG), in force since 1 September 2023. Art. 7 DSG requires the controller to put technical and organizational measures in place from the planning phase of any processing activity, and to ensure through privacy-friendly default settings (Privacy by Default) that only personal data necessary for the respective purpose is processed. The norm is closely modeled on Art. 25 GDPR; the Federal Council's implementing Data Protection Ordinance (DSV) deliberately avoids prescriptive technical mandates and instead follows a risk-based approach.

This article covers:

• Ann Cavoukian's seven Foundational Principles (Information & Privacy Commissioner Ontario, 2009) as the conceptual scaffolding
• A mapping of each principle to Art. 7 DSG and Art. 25 GDPR
• Concrete engineering and product checkpoints (PRD, design review, code review, threat modeling)
• Evidence artifacts that supervisory authorities such as the FDPIC (EDÖB) expect in inquiry or enforcement proceedings
• Typical findings from our audits that consistently trigger corrective action

The intended audience is product owners, CTOs, and data protection advisors who want to operationalize Privacy by Design not as a buzzword but as an auditable procedure embedded in the Software Development Lifecycle (SDLC).

Art. 7(1) DSG obliges the controller to design data processing, both technically and organizationally, so that the processing principles in Art. 6 DSG are upheld. The relevant factors are the state of the art, the nature and scope of processing, and the risk to the data subjects. Art. 7(3) DSG adds the obligation to apply privacy-friendly defaults, Privacy by Default. Anyone designing a system that collects all optional fields by default, exposes all recipients, or sets tracking cookies before consent violates this provision.

Art. 25 GDPR phrases the same duty along two axes: Privacy by Design (para. 1, at the time the means of processing are determined) and Privacy by Default (para. 2, limited to what is necessary for each purpose). Unlike the DSG, Art. 83(4)(a) GDPR exposes infringements to administrative fines of up to EUR 10 million or 2 % of global annual turnover. In Switzerland, personal criminal liability under Art. 60–61 DSG applies where minimum measures are willfully omitted.

In practice: any Swiss company processing personal data within the EU must satisfy both regimes cumulatively. A clean Privacy-by-Design architecture is the most efficient solution because it eliminates redundant compliance layers.

Proactive not Reactive; Preventative not Remedial. Privacy risks are addressed before they materialize, not after. In practice, every new processing activity goes through a pre-assessment before go-live. Where the risk is high, a full Data Protection Impact Assessment (DPIA) under Art. 22 DSG or Art. 35 GDPR is mandatory. The decisive maturity indicator: the security team is involved already at the Product Requirements Document (PRD) stage, not at a security review two weeks before release.

Privacy as the Default Setting. If the data subject does nothing, their data must be protected. Concrete checkpoints: cookie banners with equally weighted buttons (Accept / Reject on the same level), newsletter checkboxes as opt-in, profile visibility set to private by default, telemetry opt-in rather than opt-out, geolocation disabled until explicit consent. The FDPIC's 2024 cookie-banner guidance and the EDPB Guidelines 4/2019 on Art. 25 GDPR set the benchmark here.

Evidence artifact: a Default-Settings inventory inside the record of processing activities (Art. 12 DSG) that documents per feature which default was chosen and on what reasoning.

Privacy Embedded into Design. Privacy is not an add-on but a component of the system architecture. Architectural patterns include separating personal and non-personal data stores, pseudonymization at the persistence layer, tenant isolation through row-level security, and event logging without cleartext personal data. Threat-modeling frameworks such as LINDDUN (Linkability, Identifiability, Non-repudiation, Detectability, Disclosure, Unawareness, Non-compliance) complement STRIDE with privacy-specific risks and feed structured input into the architecture review.

Full Functionality, Positive-Sum, not Zero-Sum. Cavoukian insists that privacy and functionality are achievable simultaneously. Pseudonymization allows product analytics without identifiable profiles. Differential privacy enables aggregated reporting without reconstruction. Confidential computing (Intel SGX, AMD SEV-SNP) processes encrypted data in the cloud without the provider seeing cleartext. Teams that work positive-sum in the design phase avoid the later argument that cleartext is needed for performance.

A question the FDPIC will ask in an enforcement procedure: which architectural alternatives were assessed, and why was the chosen design considered the least rights-intrusive? An answer-free record means Art. 7 DSG has not been satisfied.

End-to-End Security, Full Lifecycle Protection. Personal data is protected throughout its lifecycle: collection, transmission, processing, storage, deletion. Concretely this means encryption in transit (TLS 1.2+, mTLS for service-to-service), encryption at rest (AES-256 with key rotation), encrypted backups, robust key management (KMS / HSM, ideally customer-managed keys for cloud providers), and verifiable deletion procedures. The deletion duty under Art. 6(4) DSG (proportionality, purpose limitation) is only fulfilled if retention periods are technically enforced, not merely tracked through organizational reminders.

Visibility and Transparency. The processing must be verifiable. The Swiss counterparts are Art. 19–21 DSG (information duty), Art. 25 DSG (right of access), and Art. 28 DSG (data portability). Privacy by Design here means: the privacy policy is generated from the record of processing activities rather than hand-maintained, access requests are supported by self-service portals, and the system logs who accessed which personal data at which time (access logs with a justification field for sensitive data under Art. 5(c) DSG).

Evidence artifact: a data-lineage diagram showing per data category where it originates, which systems it flows through, and where it is persisted.

Respect for User Privacy, Keep It User-Centric. The seventh principle operationalizes data subject rights under Art. 25–32 DSG and Art. 12–22 GDPR into the product. Concrete SDLC checkpoints:

• Right of access (Art. 25 DSG): self-service export in a standard format (JSON / CSV), not just a PDF dump of an unstructured report.
• Right of rectification (Art. 32(1) DSG): profile editor with audit trail and automatic propagation to downstream systems.
• Right of erasure (Art. 32(2)(c) DSG): account deletion with cascaded deletion in databases, backups (per rotation cycle), logs, and SaaS sub-processors.
• Right to data portability (Art. 28 DSG, Art. 20 GDPR): structured, machine-readable export with documented schema.
• Right to object (Art. 30(2)(b) DSG): granular consent and objection settings per processing purpose.
• Prohibition of automated individual decisions (Art. 21 DSG): in-product notice and mechanism to request human review.

If these rights are handled only post-contract through Excel sheets, Privacy by Design has failed, irrespective of how elegant the backend encryption is.

The seven principles are only effective once they are anchored as mandatory checkpoints in the Software Development Lifecycle. We recommend four gates:

1. Discovery gate (PRD review): pre-assessment pursuant to Art. 22 DSG. The Data Protection Officer or Privacy Engineer determines whether new personal data is collected, whether a new processing activity arises, and whether a DPIA is required.
2. Design gate (architecture review): threat modeling with LINDDUN, data minimization documented, default settings agreed, data-flow diagram with a legal basis identified per processing step.
3. Build gate (code review & SAST): static analysis for hardcoded secrets, missing encryption, excessive logging. Pull-request templates with a privacy checklist.
4. Release gate (pre-prod audit): verification of default settings in the live system, penetration test where the risk is high, final update of the record of processing activities and the privacy policy.

These gates initially reduce velocity but, on average, save 40–60 % of the remediation costs caused by retrofitted privacy fixes. Where a DPIA reveals a residual high risk only after go-live, prior consultation of the FDPIC under Art. 23 DSG becomes mandatory before further processing, a meeting no management team wants. We recommend embedding the four gates as binding stage gates in the internal control system (ICS) and storing evidence of their execution in the record of processing activities.

SIDD supports Swiss companies in embedding Privacy by Design into their product and software-engineering processes. Our Swiss data protection advisory practice covers an initial assessment of your SDLC against Art. 7 DSG and Art. 25 GDPR, the definition of the four privacy gates, the creation of threat-modeling and DPIA templates, and the coaching of your product owners and privacy engineers. For organizations building an information security management system in parallel, we couple the privacy gates with the ISO 27001 / ISMS implementation, so that security and privacy controls are delivered as one coherent body of work.

Where GDPR applies, we extend the mandate with an external Data Protection Officer (GDPR DPO) and act as your EU representative under Art. 27 GDPR if you have no establishment in the Union. For ongoing compliance, the Priverion platform is available, with record of processing, DPIA module, and data-subject-rights workflow.

Schedule a no-obligation initial conversation via our contact form or request a quote directly. We usually respond within 24 hours with a proposed next step.