Privacy by design + by default documentation

Description

Privacy by design and by default is the GDPR Article 25 obligation that privacy considerations be built into product development from the outset rather than retrofitted before launch. The Article has two halves, and the second half is the one that more often produces enforcement attention. Privacy by design is the first half: the process obligation to consider privacy in the design of any new product or feature, and to choose the technical and organizational measures that implement the data-protection principles (data minimization, purpose limitation, accuracy, storage limitation, integrity and confidentiality) in a manner appropriate to the risk. Privacy by default is the second half: the substantive obligation that the most privacy-protective configuration be the out-of-the-box state for any given setting, so that a user who never visits the privacy settings still has the protective configuration. The substantive consequence is mostly process. Privacy considerations enter the design review, typically as a structured checklist or as a privacy-impact assessment proportional to the data sensitivity (a low-stakes feature gets a short checklist; a high-stakes feature gets a full DPIA under Article 35). The engineering team selects the technical option that minimizes data collection consistent with the product purpose: pseudonymization where feasible, aggregation rather than per-user retention, retention windows scoped to the disclosed purpose, encryption at rest, role-based access controls, and the other measures that the EDPB has cited as appropriate in its Article 25 guidelines. The default settings on configurable privacy controls start at the most privacy-protective option rather than the most engagement-maximizing one. And the design-review notes capture the privacy analysis at the moment the decisions were made, retained long enough to support any later inquiry into how the product reached its current shape. Article 25 is not prescriptive about which technical choices are right. The Article requires that the choices be considered, documented, and proportional to the risk, with the proportionality assessment running against the state of the art at the time the decision was made and against the cost of implementation. The EDPB's Article 25 guidelines and the supervisory authorities' enforcement decisions have developed a body of practice around what counts as appropriate, with retention-window calibration, default-public-versus-private setting choices, the use of unique identifiers, and the design of consent flows being the recurring battlegrounds. The UK AADC Standard 1 carries an analogous obligation specific to services likely to be accessed by children, framed as best-interests-of-the-child-by-design. The defensibility argument is the artifact set. Design-review notes showing privacy was on the agenda at the moment the design decisions were made. DPIAs for high-risk processing, with the necessity-and-proportionality analysis captured rather than gestured at. Change-history showing that the privacy analysis carried through implementation rather than being completed and then ignored. And periodic audits showing that the default settings have not drifted over time as feature flags have moved and configuration tables have been edited. The thing that surfaces in enforcement is the by-default question. Marketing and growth instincts pull the opposite way from privacy-by-default: the engagement-maximizing default is rarely the privacy-protective default, and the platforms that have arrived at by-default-public for new content surfaces, by-default-personalized for advertising, and by-default-discoverable for new profiles have generally done so under product-team pressure rather than through deliberate privacy design. The documented design-review record is what shows the choice was deliberate rather than drift; in the cases where the choice cannot be defended on substantive grounds, the operator usually finds it cheaper to flip the default to the privacy-protective option than to litigate the Article 25 finding. The Norwegian DPA's Grindr decision, the French CNIL's Google decisions on default-tracking, and the Irish DPC's TikTok decisions all developed substantially around the by-default question rather than around the design-process question.

Required by (2 regulations)

• GDPR

  Article 25 — data protection by design and by default.

  Regulation (EU) 2016/679 of the European Parliament and of the Council

• UK AADC

  Standard 1 — best interests of the child by design.

  Data Protection Act 2018, s.123; Age Appropriate Design: A Code of Practice for Online Services (ICO, 2020)

Fulfilled by (1)

• In-house build · medium effort

Magist does not accept payment from vendors. Methodology.

Evidence formats

• design review records
• default-settings audit
• pseudonymization design notes