Privacy-by-Design Framework
Privacy by Design says you build privacy into a system's architecture from the first sketch, not bolt it on after launch - seven principles for engineering trust in rather than inspecting it in later.
Seven cards sit side by side, each naming one principle you weave in from day one.
Reach for this when…
- You're speccing a new product and privacy is on the 'later' list.
- A feature only works by defaulting users into sharing more than they need to.
- Legal keeps getting looped in after the build, not before it.
How to run it
- Design for the risk before it happens, not after a breach.
- Set the most private setting as the default, not an opt-in.
- Build privacy controls into the architecture, not a bolt-on module.
- Refuse false trade-offs - security or privacy, privacy or usability.
- Protect data across its whole life, not just at collection.
- Publish what you do with data in language a user can read.
- Keep the user's own interests front and centre, not just the organisation's.
A worked example
Situation. Ayesha Malik's fintech app HisaabPay, in Lahore, Pakistan, defaulted new users into sharing full transaction history with a marketing partner.
Applied. She ran the build against Cavoukian's seven principles and reset the sharing toggle to off by default, moving consent into the onboarding flow itself.
Result. Opt-in sharing rates fell to 12%, support tickets about surprise data sharing dropped with them, and the next regulatory review took a fraction of the time.
The catch
The principles are aspirational and none of them tell you how to trade off a genuine engineering constraint against a privacy ideal - 'full functionality, no zero-sum' is often exactly the trade-off you're stuck making. It also assumes you control the whole stack, which is rarely true once you're plugging into third-party APIs and ad networks.
Privacy by design retrofitted after the architecture is set is privacy by apology.
Origin: Ann Cavoukian