GDPR Article 25 — Privacy by Design and by Default

Article 25 of the General Data Protection Regulation (EU) 2016/679 imposes two distinct obligations on controllers: Privacy by Design (Article 25(1)) — taking into account the state of the art, the cost of implementation, and the nature, scope, context, and purposes of processing, as well as the likelihood and severity of risks to natural persons, to implement appropriate technical and organizational measures designed to implement data protection principles such as data minimisation effectively; and Privacy by Default (Article 25(2)) — implementing appropriate technical and organizational measures to ensure that by default only personal data necessary for each specific purpose is processed. The European Data Protection Board (EDPB) published Guidelines 4/2019 on Article 25 ("Data Protection by Design and by Default"), providing authoritative interpretation of these requirements.

Engineering implementation of Privacy by Design requires operationalizing all seven GDPR principles (Article 5) at the system architecture level. Data minimization (Article 5(1)(c)) means schema design that captures only fields necessary for the specific processing purpose, with separate purpose-bound data stores rather than a single omnibus user record. Purpose limitation (Article 5(1)(b)) means technical enforcement of data use restriction — for example, using data compartmentalization, attribute-based access control, or differential privacy mechanisms to prevent analytics workloads from accessing data collected for a different purpose. Storage limitation (Article 5(1)(e)) requires automated retention enforcement: not a policy document but actual TTL-based deletion, partition dropping, or pseudonymization at defined retention boundaries. The EDPB's Guidelines specifically list pseudonymization, data minimization at collection, and granular purpose-bound access control as concrete Privacy by Design measures.

Privacy by Default has direct product design implications. The EDPB's Guidelines establish that privacy settings must be set to the most privacy-protective option by default; the data subject must take an affirmative action to enable less protective settings. This means: opt-in (not opt-out) for data sharing with third parties; minimal data collection in onboarding flows with optional additional fields clearly labeled; analytical tracking disabled by default; and marketing communications requiring explicit consent before enrollment. Regulators have imposed significant fines for Article 25 violations: the Austrian DPA fined Google Analytics users for unlawful data transfers to the US in a decision that implicated Article 25 default configurations; the German DPAs have cited Article 25 in enforcement against dark patterns that make privacy settings difficult to access. The Spanish AEPD (Agencia Española de Protección de Datos) published a guide specifically on Privacy by Design that engineering teams should reference for sector-specific implementation patterns.

We conduct Privacy by Design architecture reviews that map every data field in a system against a defined processing purpose and legal basis, identify over-collection and purpose creep, and produce a data minimization remediation plan. We implement technical Privacy by Default controls — including automated retention enforcement, purpose-bound access control, and opt-in default configurations — and integrate DPIA triggers into the product development lifecycle so Article 25 review occurs before system design is finalized.

Compliance-Native Architecture Guide

Design principles and a structured checklist for building software that is compliant by default — not compliant by retrofit. Covers data architecture, access controls, audit trails, and vendor due diligence.