A product team launches a personal-data feature and only afterward adds a privacy banner, calling that ‘data protection by design.’ Which correction is required?
Select an answer to reveal the explanation.
Short Explanation
Slapping a privacy sticker on a finished gadget is not ‘by design’ — that phrase means baking protection into the blueprint from the start. A late banner might help transparency, but it does not rewrite Article 25. Wait-for-breach encryption shopping is also too late as the whole story.
Full Explanation
Article 25 data protection by design requires integrating appropriate measures into the determination of means of processing and into the processing itself, in a way that implements principles effectively and integrates necessary safeguards. Adding a privacy banner only after launching a personal-data feature treats privacy as cosmetics rather than design. Engineering teams and civic digital-delivery programmes should embed minimisation, purpose limitation, security, and transparency into build pipelines before production personal data are touched.
Banners alone are not full Article 25 compliance regardless of when they appear. Limiting privacy by design to encryption algorithms chosen after the first breach is both too late and too narrow. Privacy by design is a binding controller duty, not optional guidance that never binds.
Exam caveat: design and default duties connect to DPIAs, threat modelling, and default settings—not merely UI chrome. Late banners may also fail transparency timing under Articles 12 and 13 if collection already occurred.
Operational check: add privacy design reviews to the development lifecycle, require DPIA or legitimate-interest assessment gates for new personal-data features, ship notices and controls before collection starts, and reject tickets that say “launch now, privacy later.”