Privacy by Design: Cheaper to Prevent Than to Remediate

Privacy by design and by default is a legally binding obligation under Article 25 of the EU General Data Protection Regulation (GDPR, Regulation 2016/679), which requires controllers to implement appropriate technical and organisational measures designed to give effect to data protection principles — such as data minimisation, purpose limitation, and storage limitation — both at the time of designing the processing and at the time of the processing itself. "Privacy by default" additionally requires that, by default, only personal data necessary for each specific purpose is processed. Failure to implement privacy by design and by default is a sanctionable GDPR infringement, independent of whether a data breach has occurred, and the AEPD has issued fines specifically for this violation.

Privacy by design is not a voluntary best practice — it is a legal obligation under Article 25 of the GDPR that creates liability for controllers who fail to implement it. And yet the majority of organisations continue to treat privacy as a post-development remediation exercise rather than a design requirement present from the earliest architectural decisions.

The True Cost of Getting the Sequence Wrong

The cost of the incorrect sequence is systematically underestimated. An architectural change that would have taken hours at the design stage — separating identification data from functional data, applying pseudonymisation from the source, implementing retention policies in the data model — can take weeks or months of engineering work when the system is already in production, with live data, dependent processes, and third-party contracts that constrain every change.

Beyond the direct engineering cost, post-launch privacy remediation is frequently incomplete. An architecture not designed for data minimisation cannot be made minimalist without rebuilding the data model. A system without audit logging cannot retroactively produce the access records that accountability requires. These structural deficiencies are visible to the AEPD in an inspection and are treated as evidence that privacy was not, in fact, built into the design.

Integration Without Bureaucracy

Our integration into product and engineering teams is structured around a lightweight process that generates real protections without bureaucratic overhead. For each new feature or product with a personal data component, we work with the team to answer four questions at the design stage: what data is collected and why, on what legal basis, for how long it is retained, and who has access. This exercise, conducted during design, rarely requires more than an hour. Conducted after launch, it can require weeks of audit and months of remediation.

The sprint review integration — where a privacy advisor reviews product demos when data processing changes are involved — is the mechanism that catches compliance issues when they are still inexpensive to address. A data field added to a user record, a new third-party integration, or a change to the analytics model can each trigger GDPR implications that are visible in a demo but invisible in a code review.

Privacy by Design for AI Systems

For artificial intelligence systems, data protection impact assessments and privacy by design are especially critical because the architecture decisions made at model design time determine whether the system can be GDPR-compliant in a structural sense. A model trained without data minimisation cannot be made minimalist retrospectively without complete retraining. Differential privacy, federated learning, pseudonymised training datasets, and explainable AI (XAI) design are tools that must be chosen at the outset — not added after the model is in production.

Privacy by default in the user experience is a component that product teams frequently underestimate. The product’s default privacy configuration is not just a legal requirement — it is also a signal to users of the organisation’s genuine commitment to their data. Platforms that share data with third parties by default, that activate advertising tracking without consent, or that make privacy controls difficult to find generate greater distrust and greater regulatory exposure than those that adopt the opposite model.

The Cost of Retrofitting Privacy: Why Design Stage is the Right Moment

The cost differential between embedding privacy requirements at design stage versus retrofitting compliance after launch is consistently underestimated by product teams and CTOs. A data architecture change that would take hours during design — separating identification data from functional data, applying pseudonymisation from the origin, implementing retention policies in the data model — can take weeks or months of engineering work when the system is already in production, with real data, dependent processes, and third-party contracts conditioning every change.

The practical implication is that privacy by design is not just a legal compliance requirement — it is also a cost management discipline. The AEPD’s guidance on privacy by design in digital products and AI systems is the reference standard in Spain, and the sanction for non-compliance with Article 25 GDPR can reach EUR 10 million or 2% of global turnover. But the business case for early privacy integration is economic before it is legal.

Our integration into product and development teams is structured around a lightweight process that does not generate disproportionate bureaucracy but does deliver real guarantees. For each new feature or product with a personal data component, we help the team answer four questions at the design stage: what data is collected and why, on what legal basis, how long is it retained, and who has access. When answered at design stage, this exercise rarely takes more than an hour. When answered post-launch, it can require weeks of audit and months of remediation.

Data Protection Impact Assessments (DPIAs) as a Design Prerequisite

The Data Protection Impact Assessment (DPIA, or EIPD in Spanish regulatory terminology) is a mandatory step under Article 35 GDPR before implementing any processing activity that is likely to result in a high risk to the rights and freedoms of individuals. The AEPD has published a list of processing activities that require a DPIA, including: large-scale processing of sensitive data, systematic monitoring of publicly accessible spaces, profiling that produces legal or similarly significant effects, processing of biometric data for identification, and processing involving AI or new technologies.

The DPIA is not a bureaucratic formality — it is a structured risk management exercise that identifies the data protection risks of a processing activity and the measures available to mitigate them. A well-conducted DPIA at design stage can avoid the regulatory crisis of launching a product that creates high privacy risk without appropriate safeguards. Our outsourced DPO service includes DPIA supervision as a standard function, ensuring that impact assessments are conducted before irreversible design decisions are made, are documented in a format that withstands supervisory scrutiny, and are updated when the processing activity changes materially.