Before coding a new customer portal, the team decides data fields to collect, default encryption, and role-based access as design choices—not afterthoughts. Which GDPR concept do these choices best illustrate?
Select an answer to reveal the explanation.
Short Explanation
Building privacy into the blueprint—fewer fields, encryption on, tight roles—is like putting seatbelts in the car at the factory, not taping them on after the crash. That's privacy by design in everyday engineering talk.
Full Explanation
Deciding data fields, default encryption, and role-based access before coding a customer portal best illustrates data protection by design—minimisation, encryption, and access control built in early. Civic digital services protect people better when privacy is engineered into the blueprint rather than taped on after complaints. Treating adequacy decisions as replacing all security engineering fails by conflating transfer tools with PbD engineering choices. Claiming mandatory EDPS prior authorisation for every private portal fails: the EDPS supervises Union institutions, not routine private portal builds. Banning any authentication until processing has already begun fails operationally and conceptually—access control is a design measure, not something postponed until after processing starts. Exam caveat: data protection by design and by default is an ongoing duty under Article 25, not a one-time kickoff workshop; defaults should favour minimal disclosure. Operational check: require privacy design reviews in SDLC gates, set minimise-by-default field lists, enable encryption and RBAC before production data loads, document decisions, and re-check defaults when new features expand collection.