Most companies treat GDPR compliance as something you bolt on after you've built your product. A privacy policy here. A cookie banner there. Some DSAR plumbing before you launch into the EU market.

This approach is expensive, technically disruptive, and often incomplete. It also misses the point of what GDPR actually requires.

GDPR Article 25 mandates "data protection by design and by default." This is not aspirational guidance - it is a legal obligation. It means privacy must be embedded into your product architecture, your engineering decisions, and your organisational processes from the very beginning. Not retrofitted in.

This guide is for product managers, engineers, and CTOs who want to build products that are genuinely GDPR-compliant from day one - and understand why that's also the right engineering decision.

‍

What privacy by design actually means

Privacy by design (PbD) was coined by Ann Cavoukian, the former Privacy Commissioner of Ontario, who established seven foundational principles. GDPR Article 25 codified the core of this philosophy into EU law.

The seven principles are:

1. ‍Proactive, not reactive - Anticipate and prevent privacy risks before they materialise
2. Privacy as the default - The most privacy-protective settings are the defaults; users must opt *in* to less protective settings, not opt out
3. Privacy embedded into design - Privacy is built into the product, not added later
4. Full functionality - Privacy and functionality are not a trade-off; you can have both
5. End-to-end security - Data is protected throughout its lifecycle, not just at rest
6. Visibility and transparency - Users and regulators can verify your privacy claims
7. Respect for user privacy - Keep it user-centric; exceed minimum legal requirements

Under GDPR Article 25, requirements 1, 2, 3, and 5 are effectively mandatory. The others are best practices that the regulation encourages.

‍

What GDPR Article 25 specifically requires

Article 25 creates two distinct legal obligations:

Data Protection 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 risks of varying likelihood and severity for rights and freedoms of natural persons posed by the processing, the controller shall, both at the time of the determination of the means for processing and at the time of the processing itself, implement appropriate technical and organisational measures."

In plain English: when you design features and systems that process personal data, you must actively think about and mitigate privacy risks. This applies from the moment you decide how you'll process data (architectural decisions) through to live operation.

Data Protection by Default (Article 25(2))

"The controller shall implement appropriate technical and organisational measures for ensuring that, by default, only personal data which are necessary for each specific purpose of the processing are processed."

In plain English: your default settings must be privacy-protective. Users should not have to do anything to protect their privacy - they should have to actively choose to share more, not to share less.

‍

Privacy by design in practice: Engineering decisions

Here's how privacy by design translates into real engineering choices:

Data minimisation at the collection layer

Collect only the data you actually need. This sounds obvious but is routinely violated. Before collecting any data point, ask: "Do we have a specific, documented reason to collect this? Would our product function adequately without it?"

Practical patterns:

• Avoid collecting full birth dates when a birth year suffices for age verification
• Don't store IP addresses longer than needed for abuse prevention
• Use device fingerprinting only when absolutely necessary, and document the justification
• Strip personally identifiable information from analytics events wherever possible

Purpose binding in data architecture

Personal data collected for one purpose should not be silently used for another. This is a technical as well as legal requirement.

Practical patterns:

• Tag data at collection with its purpose and retention policy
• Build database schemas that separate personal data collected for different purposes
• Implement controls that prevent cross-purpose data access (e.g., data collected for product analytics should not be accessible to marketing retargeting systems without explicit new consent)

Privacy-protective defaults in product settings

Every product feature that involves personal data should default to the most privacy-protective option. Users should have to actively choose to share more.

Examples:

• Social features default to private, not public
• Email notifications default to off (or essential only)
• Data sharing with third-party integrations requires explicit user action
• Profile information is not publicly visible by default

Pseudonymisation and Anonymisation

Where technically feasible, replace direct identifiers with pseudonyms or anonymise data for analytics, testing, and logging purposes.

Practical patterns:

• Use internal user IDs (not emails or names) in logging and analytics
• Generate separate identifiers for different contexts (a user ID for product analytics that cannot be linked to their billing ID without an internal lookup)
• Anonymise data in development and testing environments — never use production personal data in dev/test
• Apply differential privacy techniques for aggregate analytics reporting

Encryption and Security-by-Design

Encryption is a privacy by design measure as well as a security one. Key practices:

• Encrypt personal data at rest and in transit (TLS 1.3 as a minimum standard)
• Encrypt especially sensitive data fields (health data, financial data, special category data) with field-level encryption where appropriate
• Implement key management practices that allow you to delete personal data cryptographically (by deleting the encryption keys)
• Log access to sensitive data, not just writes

Retention and Deletion Architecture

One of the most technically challenging aspects of GDPR compliance is the right to erasure. Build deletion into your architecture from the start, not as an afterthought.

Practical patterns:

• Define retention periods for every data type at collection time
• Build automated deletion pipelines that run on retention schedules
• Maintain a data deletion map: for any given user, every system that holds their data and the API call or procedure needed to delete it
• Test deletion workflows - "delete user" is often the most undertested code path in a product

Consent management architecture

If you rely on consent as your lawful basis for any processing, your system must be able to record, retrieve, and honour consent decisions reliably.

Practical patterns:

• Store consent as a first-class entity in your data model, with timestamp, version of consent text, and channel
• When consent is withdrawn, trigger downstream deletion or suppression immediately - don't rely on manual processes
• Link consent records to the specific processing they authorise
• Version your consent flows - when you change what you're asking consent for, existing consent records don't automatically cover the new purpose

‍

Organisational measures: Beyond the code

Privacy by design is not just an engineering discipline. The technical measures need to be supported by organisational processes:

Privacy reviews in the product development process
Add a privacy review step to your feature development workflow. Before any feature involving personal data goes to development, a designated reviewer should confirm: what data is being processed, the lawful basis, the data minimisation approach, and whether a DPIA is required.

Data Protection Impact Assessments (DPIAs)
For high-risk processing (large-scale data, sensitive categories, new technologies, automated decision-making), GDPR Article 35 requires a formal DPIA before development begins. Build this into your project lifecycle.

Training
Engineers and product managers need baseline GDPR literacy. Privacy decisions are made constantly in product development - by people who may not recognise them as privacy decisions. Regular training changes this.

Records of Processing Activities (RoPA)
GDPR Article 30 requires a written record of all processing activities. This is your internal data map. Keep it up to date as features are added or changed.

‍

How EU Presence supports Privacy by Design

Building privacy into your product is a technical endeavour. But the compliance infrastructure around it — your privacy policy, DSAR handling process, cookie consent management, and regulatory representatives — sits outside your product.

EU Presence Privacy Center is the external-facing layer of your privacy compliance: a public-facing privacy portal, automated DSAR handling, RoPA manager, and a trust hub that demonstrates your compliance posture to users and regulators.

GDPR Article 27 Representative services ensure you have an EU point of contact for data protection authorities, a mandatory requirement for non-EU companies operating in the EU.

‍

Frequently Asked Questions

Is privacy by design only required for new products, or does it apply to existing systems?
Article 25(1) specifies it applies "at the time of the determination of the means for processing" - which means new features and new systems. However, if you're operating systems that were built without privacy by design, supervisory authorities increasingly expect you to have a remediation roadmap. A complete redesign isn't always required, but documented progress is expected.

What's the difference between privacy by design and security by design?
They overlap significantly but are not identical. Security by design focuses on protecting data from unauthorised access (confidentiality and integrity). Privacy by design is broader — it also addresses data minimisation, purpose limitation, retention, and individual rights. Good security is a component of privacy by design, not a substitute for it.

Does privacy by design require specific technical standards?
GDPR does not mandate specific technologies. Article 25 requires "appropriate technical and organisational measures" taking into account "the state of the art" and the nature of the risks. What counts as appropriate evolves as technology and best practices develop.

How do supervisory authorities assess privacy by design compliance?
DPAs look for evidence that privacy was considered proactively in product development - via DPIAs, privacy review processes, documented data flows, and technical controls. The burden is on the company to demonstrate compliance, not on authorities to prove violation.

‍

Make privacy an engineering standard, not an afterthought

The companies that treat privacy by design as a competitive advantage - not a compliance burden - tend to win trust in regulated markets, close enterprise deals faster, and avoid the expensive remediation projects that their less diligent competitors face.

Book a demo with EU Presence to see how Privacy Center and our full suite of EU compliance services can support your privacy by design approach with the right external infrastructure.