5.2 Privacy by Design Principles & the SDLC
Key Takeaways
- Privacy by Design (PbD), developed by Dr. Ann Cavoukian and unanimously adopted by international Data Protection Commissioners in 2010, holds that privacy must be proactive and embedded, not reactive and bolted-on — a design requirement that shapes the system from the outset
- The 7 foundational principles are: (1) proactive not reactive, (2) privacy as the default, (3) privacy embedded into design, (4) full functionality positive-sum, (5) end-to-end security full lifecycle, (6) visibility and transparency, (7) respect for user privacy — the exam tests the distinction between Principle 2 (default settings) and Principle 3 (architecture placement)
- PbD applies to business processes, not just IT systems — marketing onboarding, vendor procurement, and HR intake must all have embedded privacy checkpoints, not a parallel privacy process that is routinely skipped
- Privacy must be integrated throughout every SDLC phase: requirements, design, build, test, deploy, operations, and decommission — it is a continuous thread, not a single DPIA gate
- Decommissioning is the most commonly neglected SDLC phase for privacy: secure deletion of personal data and derived models at feature retirement is essential to Principle 5 (end-to-end lifecycle protection)
The 7 Foundational Principles of Privacy by Design
Privacy by Design (PbD) is the framework developed by Dr. Ann Cavoukian, former Information and Privacy Commissioner of Ontario, Canada, and unanimously adopted by international Data Protection and Privacy Commissioners in 2010. The CIPM BoK (IV.B) expects the privacy manager to integrate the main principles of PbD throughout business processes and the System Development Life Cycle (SDLC).
The core insight of PbD is that privacy should be proactive and embedded, not reactive and bolted-on. Privacy is not a compliance overlay added after a system is built — it is a design requirement that shapes the system from the outset.
The 7 Foundational Principles
| # | Principle | Core Idea | Exam Application |
|---|---|---|---|
| 1 | Proactive not Reactive; Preventative not Remedial | Anticipate and prevent privacy risks before they materialize | Conduct DPIAs before building; design out risks rather than mitigating after launch |
| 2 | Privacy as the Default Setting | Personal data is automatically protected without any action by the user | Default to least-collection; opt-in defaults that favor privacy; no data sharing unless the user acts |
| 3 | Privacy Embedded into Design | Privacy is a core component of system architecture, not an add-on | Privacy requirements in the design specification; privacy reviewed at architecture sign-off |
| 4 | Full Functionality — Positive-Sum, not Zero-Sum | Privacy and other objectives (security, usability, business value) are both achievable | Reject privacy-vs.-security false trade-offs; design for both |
| 5 | End-to-End Security — Full Lifecycle Protection | Data is protected from collection through secure destruction | Retention enforcement, secure deletion, data-flow mapping across the entire lifecycle |
| 6 | Visibility and Transparency — Keep it Open | Stakeholders can verify that the system operates as promised | Independent audits, published privacy practices, accountable business practices |
| 7 | Respect for User Privacy — Keep it User-Centric | The individual's interests are paramount | Strong privacy defaults, clear notice, empowering user-friendly options |
A frequent exam trap is confusing Principle 2 (Privacy as the Default) with Principle 3 (Privacy Embedded into Design). Principle 2 is about default settings — what happens when the user does nothing. Principle 3 is about architecture — where privacy sits in the build process. A system can have privacy-protective defaults (Principle 2 satisfied) but still have privacy bolted on as an afterthought (Principle 3 violated), or vice versa.
Integrating Privacy Throughout the Business Process
PbD is not limited to IT systems. The BoK expects privacy to be integrated into business processes — the operational workflows that govern how personal data is collected, used, shared, and retained. Examples:
- Marketing onboarding — a new campaign workflow includes a privacy review checkpoint before launch, not after.
- Vendor procurement — a data protection agreement and transfer assessment are required before a vendor touches personal data, not as a post-signature cleanup.
- HR processes — employee data collection is minimized at the intake form, not after a retention audit finds overcollection years later.
The privacy manager's role is to embed privacy checkpoints into existing processes rather than create a parallel privacy process that runs alongside and is routinely skipped.
Integrating Privacy Throughout the SDLC
The System Development Life Cycle (SDLC) is the structured process by which systems are designed, built, and retired. The BoK explicitly requires integrating privacy throughout the SDLC.
SDLC Phases and PbD Mapping
| SDLC Phase | Privacy Activity | PbD Principles Applied |
|---|---|---|
| Requirements | Define privacy requirements (data elements, purposes, lawful basis, retention); identify applicable regulations | 1 (Proactive), 7 (User-centric) |
| Design | Privacy architecture review; data-flow diagrams; minimization in schema; choice of PETs; DPIA if high-risk | 3 (Embedded), 2 (Default), 4 (Positive-sum) |
| Build / Development | Implement access controls, encryption, logging; code reviews for privacy defects; no real personal data in test environments | 3 (Embedded), 5 (End-to-end security) |
| Test | Privacy test cases: defaults verification, access-control testing, data-minimization validation, secure-deletion testing | 6 (Visibility/Transparency), 5 (End-to-end) |
| Deploy | Privacy sign-off before go-live; configuration audit; notice publication; training for operators | 6 (Visibility), 1 (Proactive) |
| Operations / Maintenance | Ongoing monitoring; privacy-impact review of changes; retention enforcement; periodic DPIA refresh | 5 (Full lifecycle), 6 (Visibility) |
| Decommission | Secure data deletion; certificate of destruction; vendor data-return or destruction confirmation | 5 (End-to-end, cradle-to-grave) |
The exam-expected takeaway is that privacy is not a single gate (e.g., a DPIA at design only) but a continuous thread across every SDLC phase, including decommissioning. A DPIA conducted at design but never refreshed during operations, and with no plan for secure deletion at decommission, does not satisfy Principle 5.
Worked Scenario: PbD in a New Product Launch
A health-app company is building a new feature that uses wearable heart-rate data to infer stress levels and recommend content. The engineering team has built a prototype and is ready to ship. The privacy manager is brought in two days before launch to do the privacy review.
What PbD principles are violated?
- Principle 1 (Proactive not Reactive) — privacy is reviewed at the end, not before the build. Risks are being remediated, not prevented.
- Principle 3 (Privacy Embedded into Design) — privacy was not in the design or build phases; it is a bolt-on review days before launch.
- Principle 7 (User-Centric) — stress inference from heart-rate data is sensitive; the user should have been offered granular, opt-in choices from the outset, not a post-hoc notice.
- Principle 5 (End-to-End) — if retention for inferred stress data was not defined, the lifecycle is incomplete from the start.
What does correct PbD integration look like?
- At Requirements: define what heart-rate data is needed, for what purpose, with what retention, and on what lawful basis. Determine if stress inference is compatible with the original collection purpose.
- At Design: conduct a DPIA (high-risk processing involving health inference); select PETs (on-device inference, minimization); design opt-in consent for the stress feature.
- At Build: implement on-device processing where feasible; ensure no real heart-rate data in test environments; implement access controls.
- At Test: verify defaults (stress feature off by default — Principle 2); test consent flow; test deletion.
- At Deploy: privacy sign-off before launch; publish layered notice; train support staff on the new feature.
- At Decommission: define how stress-inference data and any derived models are securely deleted when the feature is retired.
A new mobile app launches with location tracking enabled by default. Users must navigate a settings menu three levels deep to turn it off. Which PbD principle is most directly violated?
A product team conducts a DPIA during the design phase, implements minimization in the database schema, verifies privacy defaults in testing, and requires privacy sign-off before go-live. At which SDLC phase is privacy integration most commonly missing in practice, leading to incomplete lifecycle protection under Principle 5?