Privacy by design is not a policy added before launch. It is a series of product decisions made while the service can still be changed without expensive rework.
In this article
Begin with purpose and necessity
State what the product needs personal information for and which outcome depends on it. If the team cannot explain the purpose clearly, collection is difficult to justify and harder to communicate.
Collect the minimum information needed for that purpose. Optional future uses should not quietly become part of the default design.
Map the information through its lifecycle
Record where information comes from, where it is stored, which suppliers receive it, who can access it and when it will be deleted. Include test, analytics and support environments as well as the main database.
Choose protective defaults
The ICO explains that data protection by default means limiting personal information to what is necessary for each purpose. Default visibility, retention and sharing should reflect that principle.
Give users understandable choices where choice is appropriate. Avoid preselected options or interface patterns that make the privacy-preserving path harder.
Assess risk before it is embedded
Consider misuse, unauthorised access, discrimination, unexpected disclosure and the consequences of inaccurate data. A data protection impact assessment may be required for processing likely to create high risk.
Bring legal, security, design, engineering and operational perspectives together early. Each sees a different failure mode.
Make privacy part of release and maintenance
- Verify access roles and logging
- Test deletion and correction journeys
- Review supplier terms and data locations
- Check that notices match the product
- Reassess when purpose or technology changes
Privacy by design continues after launch. Monitoring, incidents, user feedback and product changes should feed back into the controls.
English (UK) 
Français 