What to consider for your privacy policy

It’s old news that the GDPR has significantly changed data privacy laws in the UK and EU. One thing that changed was the introduction of the privacy policy. This is the link on the bottom of a webpage setting out what will happen to personal data entrusted or acquired by the website owner.

In GDPR-speak, the website owner is the data controller and the privacy policy is there to meet the obligation under Article 5(1)(a) that “personal data shall be processed lawfully, fairly and in a transparent matter in relation to the data subject.”

A website is a pragmatic and useful publication platform for such obligations to inform. Privacy policies are not necessarily long documents, and they should be drafted in plain and accessible language (again transparent; as in understandable.) But drafting a privacy policy is not a tick-box exercise.

As a new business (or an established one catching up on admin) it is tempting to copy a privacy policy from another website or download a basic template. Whilst a privacy policy may generalise and deal with categories of personal data, it must not be misleading or wrong, which is why a templated approach is risky. Like the classic iceberg analogy – 90% of the work of preparing a privacy policy is under the surface. The privacy policy draft is the outcome of a larger body of work reviewing systems and processes in order to understand what personal data is being collected, what purpose the data is used for and whether that purpose is legal. New business model owners need to really think about what they are doing with personal data before starting to write and this will be all the more pertinent for new metaverse models, where a personalised and collaborative experience is at the heart of trend.

When asked to support the process of data audit, almost always it transpires that some personal data is collected for no purpose at all and may never be processed. For example, is it functionally important to know the age of an online training event attendee? No (assuming they are an adult.)

The analysis does not end there. Once the correct data and its purpose is identified, the data controller should be able to identify the legal basis for collecting it. There are only 4 that are of general application to businesses. For example, is it functionally important to know the gender of the purchaser of an umbrella? No, but it may be useful for segmenting a marketing campaign. As such, the legal basis for processing the gender of the purchaser is not to “fulfil the contract,” but instead “legitimate interests” – in this case to market and grow the business.

How long will any particular piece of personal data be stored for? Financial records need to be kept for 6 years of more, but the underlying credit card data is not useful after a few months. A data controller needs to be specific on each data point and be able to justify their choice of retention period, if a query is raised.

Much of this analytical information will not find its way into the privacy policy. Instead, the data audit feeds the preparation of a data protection impact assessment (DPIA.) The DPIA is an internal document, where the arguments are rehearsed about what impact the data processing activities have on data subjects. Collecting names and email addresses of business contacts will have a very limited impact on the data subjects – many business people are actively marketing their contact details, but collecting credit history information of private individuals is very different and lives can be blighted by poor credit scores and identity theft. In order to comply with the GDPR, the risks to data subjects and the steps taken to mitigate those risks need to be set out in the DPIA. In some cases, a data controller that cannot adequately mitigate risks may need to stop processing, or at the very least, substantially rethink their approach.

Privacy policies also need to set-out the specifics of any technology or partnerships that the data controller is relying on in order to complete its processing. These are unique to the data controller and cannot be copied from somewhere else. The data controller will need to understand and communicate whether any personal data is being shared with processors (perhaps an email marketing provider) and whether personal data is being cross-referenced with third party sources (such as address verification software) and to be open about any tracking or monitoring that is taking place using cookies or other adtech.

Finally, there are complexities around international processing of personal data. The data controller will need to explain where in the world processing takes place and if this is in a so-called “third country,” to explain to data subjects how the personal data is safeguarded. This will be different for each data controller depending on their choices of suppliers and the nature of the processing they are performing.

Checklist for preparing a privacy policy

• Data audit – what is being collected and why? How long do you need it?
• Lawful basis – what is the lawful basis for each data point?
• Risk analysis drafted as a data protection impact assessment: the ICO’s suggested format is here.
• Technology partnerships and international processing analysis
• Draft the privacy policy as a summary

Please get in touch if you would like help preparing a privacy policy or to discuss data protection law compliance in any further detail.