Big companies regularly become the center of media attention when it comes to privacy infringements. The 2014 Yahoo data breach that became public only in 2016, the Facebook / Cambridge Analytica scandal combining a breach and political manipulation, leading to a publicity storm in early 2018, the LinkedIn breach that leaked more than 100 million user names and passwords in 2012. All these are examples of misuses of personal data backfiring to the organisations that allegedly caused them or tried to cover them up.
We regularly get comments on our own privacy compliance. Some of them are clearly false (comments suggesting that our newsletter tickbox is on by default, which it isn’t), but other comments concern things we want to address more elaborately, such as the tracking technology that is used by default in Mailchimp. We sum up a few guidelines that we try to adhere to as much as possible, and might be useful for your organisation as well.
Our first public website did not have cookies. None. We did not even know how many visitors the site attracted - only if someone filled in one of the forms we could follow up. Whereas it’s great to have an extremely privacy-friendly website, it’s also a serious threat to business. So we decided that we really needed to know more of our visitors. So we started to use analytics software to learn about visit patterns.
However, we thoroughly evaluate any tool for its GDPR compliance before we use it. For instance, we rejected an otherwise excellent chat tool because it basically collects any data it could get from a user. We decided to use Mailchimp - despite its ‘liberal’ use of tracking technologies - because it’s a de facto standard, but we’re still working on the communication about it. And we’re currently considering to use visitor tracking technologies for retargeting purposes. Do we want this? And if so, what will be the impact on the user’s privacy? In every decision, we take we have to balance our business objectives and the ways to safeguard the data privacy of our website users.
Waiting for the first data breach or data subject request to occur is not a good strategy. Remember that your organisation needs an overview (according to article 30 GDPR) of what happens where in the organisation with personal data in order to respond to most of the rights and obligations imposed. This register is the backbone of your privacy governance. If you have your register in place, combined with an action plan for actual breach situations (see our whitepaper here), you can take appropriate action in case it’s needed.
Also, be aware that data subject requests can quickly become the real world analogy of a ‘distributed denial of service attack’. When you have hundreds of thousands of customers, and only a very small percentage of them asks you to deliver the personal data you store of them, you still might have a massive problem for your organisation. Again, the article 30 register will help here, but it doesn’t save you from the necessity of collecting real data for real individuals.