What does privacy by design actually require in practice?

Why this matters for the AIGP exam

Privacy by design questions on the AIGP exam typically take one of two forms: identifying whether a described approach genuinely satisfies PbD requirements, or selecting the most accurate statement about what PbD requires. The challenge is that PbD is often described in vague, aspirational terms that can sound compliant without actually being so.

Exam questions exploit this gap by presenting options that describe documentation of privacy intentions rather than implementation of privacy protections. Understanding the substance of each foundational principle helps distinguish real PbD from compliance theater.

The legal requirement

Article 25 GDPR requires data controllers to implement appropriate technical and organizational measures both at the time of determining the means of processing (privacy by design) and at the time of processing itself (privacy by default). The requirement applies both to new systems being designed and to existing systems being significantly modified.

Privacy by default means that, by default, only personal data that is necessary for each specific purpose of the processing is processed. This applies to the amount of data collected, the extent of processing, the period of storage, and the accessibility of the data.

The seven foundational principles

The seven foundational principles of privacy by design were developed by Ann Cavoukian and are reflected in GDPR's approach to Article 25:

1. Proactive, not reactive: Privacy risks are anticipated and prevented before they occur, not addressed after a breach.
2. Privacy as the default setting: The system defaults to the most privacy-protective configuration. Users should not have to opt out of privacy; they should have to opt in to less privacy.
3. Privacy embedded into design: Privacy is built into the system architecture, not added as a layer on top of a finished system.
4. Full functionality: Privacy and functionality are not traded off against each other. A privacy-by-design approach should achieve both.
5. End-to-end security: Privacy protections extend throughout the full lifecycle of the data, from collection through deletion.
6. Visibility and transparency: The system operates as described. Privacy notices and data practices are accurate and verifiable.
7. Respect for user privacy: The system is designed around the data subject's interests, keeping data accurate and accessible to those who have the right to it.

Scenario example

A product team is designing a new mobile application that allows users to share their location with friends. The privacy team is asked to review the design before development begins.

A privacy-by-design approach to this scenario would include: collecting location data only when the app is actively in use and the user has explicitly enabled sharing (data minimization and default privacy), not retaining precise location history beyond what the feature requires (purpose limitation), and building location sharing as an opt-in feature that defaults to off (privacy as default setting).

A non-compliant approach might be to design the app to collect continuous background location by default, then add a privacy notice explaining this collection. The notice documents the practice but does not embed privacy into the design.

Common confusion and exam trap

The most frequent exam trap involves confusing a privacy notice with privacy by design. Writing a privacy policy that accurately describes data collection is a transparency obligation, not a privacy-by-design measure. PbD requires the collection itself to be designed with privacy protections built in.

A second trap is misapplying the full functionality principle. Some candidates interpret this as meaning that privacy concerns should not limit app functionality. The correct interpretation is that privacy and functionality can both be achieved through thoughtful design, not that functionality always wins when the two conflict.

A third trap concerns timing. Article 25 requires that privacy be considered at the time of determining the means of processing, which is before development begins. A post-development privacy review is not PbD, even if it identifies and mitigates some risks.