The idea behind privacy by design is to build systems and processes in which data doesn’t need protecting. This is achieved through ‘data minimization.’ Essentially, we want to build systems where we don’t capture or retain personal data when we don’t need to.
There are myriad ways in which this can be achieved.
The most obvious is data minimisation from the outset - simply asking at the earliest stages of system and process design ‘do we really need this information’ and designing your systems accordingly.
Slightly less obvious, but also easy, is pragmatic data retention – deleting or anonymising data as soon as you’re done with it. There may be people in your organisation (maybe even you) that want to hold on to data ‘just in case.’ Just in case you want to add features, just in case you need it for something later, just in case you want to re-market... no. This is ‘the old way’ and we need to move forward with our thinking. If we come up with something down the line that needs user data, we will ask them if that’s a service they want (if applicable) and gather the data we need to sign them up. It’s easier to ask for details at a later date, than to explain to the courts how you unnecessarily jeopardised and lost the data of your users.
Other, more sophisticated approaches include token based identifiers (setting up / verifying the user initially then assigning a random token to be used for further communication) to replace email or usernames, third party or single sign on solutions so you don’t ever have to store identifiable personal data.
However you choose to implement it, privacy by design should be at the core of all your projects and systems (if it isn’t already), and you should have documentation and processes in place to explain and demonstrate how this is the case if/when you’re asked.