How to write a good privacy policy

Openli webinar

This webinar has already been held, but you can watch it on demand by filling in the form below

How to write a good privacy policy

Date: The 24th of November

Time: 12:00 PM - 1:00 PM

Deep dive into privacy policy. You need to have a privacy policy on your website and in your apps - but what should be in it?

In this webinar, we'll go through each point you need to cover in your privacy policy and give you concrete suggestions on specific headlines that should be included.

Webinar speakers


Stine Mangor Tornmark

CEO, Openli

Lawyer specialised in privacy and marketing law, with six years experience from Plesner and six years as VP for Legal and Compliance at Trustpilot.


Hi, I hope the sound is going okay, mine is coming through. We'll just get started in a few seconds. Today's webinar is about a good privacy policy and how to actually draft it. I will share my screen in a second, and then we'll get going. If you have any questions, just ask along the way. It makes it way more fun, and it's also then maybe more beneficial for you guys because we're actually covering some of the things that you might have in terms of questions or comments, or if you guys have any concerns.

I'm sharing my screen now, and hopefully you will be able to see it. Then I'm going to jump over here and present. So hopefully now you will be able to see my screen, and today's subject is privacy policies. Before we dig into the privacy policy, a little bit about myself. My background is as an attorney from one of Denmark's largest law firms, where I very much focus on compliance, privacy, e-commerce. And had big clients like Google and Netflix, and HBO, then moved over, were in-house as an attorney. And now I am part of a Danish legal tech company who have this focus area of helping companies to be compliant.

So more about the details for this webinar, just ask questions. It's a bit difficult for me to see all of them while I'm doing the presentation, but I will definitely try to cover them at the end. We'll record the webinar, and if you guys have any questions that I don't answer, you're also free to maybe share it in an email and I'll respond to it. We're going to be sending you an email afterwards, just to get your feedback and see how we can make it even better, or if there's any kind of subject you want us to cover.

So let's get started. The biggest mistakes related to actually having a privacy policy. I'll start there, it's more just to set the scene and get you guys on board with what I'm talking about. Well, the biggest one and the worst of them all is just copying the next door's website. Like you're covering... Like you take the terms and you just say, "Oh, they are similar to my type of company. I'm going to do the same, pretty much. They are in the same line of industry, so it'll probably match fine."

The thing is, it actually never does. You might use another system. You might use it for other purposes. You might actually collect different types of data, or you might not even do the same. Even though you're in the same line of industry, you might not be offering the same types of services. So the biggest mistakes would be to copy other people's terms.

Another one is not understanding your data and what you do with it. This is kind of core for building a good privacy policy. I'll come back to it because it needs to be included in your privacy policy. Before you then can actually start drafting your privacy policy, you need to take a step back and think a little bit about the type of data you'll collect. You also need to think about what systems do you use? What's kind of the ecosystem of your company? It might actually be a good idea to go on a a whiteboard, that's what I would recommend. Start building out. "Okay, I have this customer, where am I meeting my customer?"

Okay. There you might have a sign up form, they might be signing up to a newsletter, they might be joining you on a webinar, they might be accepting your cookies. Okay, so you take that customer and you find that, where do you actually collect the data about them? Then you take a step further back and say, "Okay, why am I actually collecting that data from these people? What do I want to use it for?" And you draw out this little map. What you should be doing is also documenting that drawing, because that's kind of like showing how the data is collected, what you use it for and the ecosystem.

Store it, save it, and make sure you update it, because that is also helping you along the way of becoming GDPR compliant, if that's one of the requirements you need to have. What do you need to have? Well, a data flow chart, and this could be a good way for you guys to start, if you haven't done it already.

And then it's not understanding if, and when you need to get consent from people to process their data. As a main rule, my recommendation would be not to rely on consent from your users to process their data, if you can find another legal basis, the reason why I'm saying this is because people can withdraw their consent. And if they withdraw it, let's say that they've signed up to your service and you're like, "They are your subscriber." If they've said, "You're not allowed to process my data, I'm retracting my consent," well, then you need to actually stop processing that data. And that means all of a sudden, it might be very difficult for you to actually have them as a subscriber to your service. So in those types of instances, you would use another legal basis for processing people's data instead of consent. We'll cover that because that actually also needs to be included in your privacy policy.

So now it's just kind of the outline. What are some of the biggest mistakes? Let's take them and look and why do we even need a privacy policy, and what is it? Well, everybody has this privacy policy on their website. We do, you also probably do, because we all get data about people. We get data about our customers, our website visitors, our employees, our clients, our business contacts, our partners. And if your company is collecting this information, you need a privacy policy. Some also call them a privacy notice or privacy information.

What the information is doing and why you need it is because you're legally obligated to tell people how you're processing their data. This is directly specified in GDPR Article 13, where you have a right to give people information about what data you collect, what you use it for and why. And it should be noted that a privacy policy is for people. That means that it can be a business contact, but it can also be a consumer. It can also be about your employees and it is also relevant for when you have candidates. So people applying for a job at your company, all these people need to be informed about how you're handling their data, and that's why you have the privacy policy.

So before we start actually talking a little bit about what should go into the privacy policy, we should be talking a little bit about what is actually personal data. Personal data, the more classic, and we all know it, is the name in the email. It's the address of the person, but it's also their IP address. It could be a photo, it could also be an invoice that you're sending to a customer, and where you also, then all of a sudden, have information about their shoe sizes because they bought a pair of shoes from your company. Or it could be that they're subscribing to a newsletter, just as an example.

It could also be their license number on their car because you would actually be able to find out who that person owning that car is, and therefore it could be personal information. And then it is also social security numbers. It is actually way more than that, but it's just to give you an idea. But it actually means that all companies around the world are processing data about people, and therefore should have a privacy policy.

So what do you need to include in that privacy policy? Well, first item is figuring out the types of people you will collect data from. So these are the website visitors, it's your customers, the clients, your users, and maybe also candidates, just as an example. You need to start actually outlining in your privacy policy the different types of people you collect data from. The reason is that you don't get the same data from these types of groups. It's very different if you say, "Okay, what am I capturing about my website visitors compared to what you're capturing about your employees?"

So that's important, and that's why the first thing you should do is check in a few minutes and think a little bit about, "Okay, when I'm looking at my website, when I'm looking in the apps that I have, when I'm thinking a little bit about when I'm capturing data about people, who are those people? And that needs to be described.

Then you also then need to think a bit about the type of data you collect from each of these groups. Let's take an example. So your website visitors, here you're capturing the IP address, the user's browser, their user agent, information about the pages that they visited, the date and time of their visit. And you might also capture their cookie consent. When they gave it, did they reject it?

So all this information needs to be captured in your privacy policy. So the first is in section one, you will tell about the types of people. In section two, you would then say, "For group one, I'm collecting this type of data. For group two, I'm collecting this type of data. And for group three, I'm collecting this type of data." Just as an example.

Then, you need to also explain what you use the data for. You probably use it for many different things. And what people normally think about is, "Okay, I'm using it to actually provide my service, that's fine. I'm also using it to send out newsletters and people joining events and webinars." But you should also think about the fact that you would get data when people complain to your support team. You would also get data when they are browsing your site. You also of course, get data when people are applying for a job.

So all these types of purposes, and what you use this data for needs to be explained in your privacy policy. And that's why it's important that you do the data mapping that I just talked a little bit about in the beginning, where I kind of take that diagram and figure out what are you using the different types of data for? So for our customers, it would be for handling support tickets or complaints. It would be to handle refunds. It could be to charge the credit card because they purchased something. It could also be to have them in your CRM database. So you would be able to, maybe at a later stage if they sign up for newsletters, to send them relevant information.

So take some time to describe these purposes. And the reason for it is if you hadn't outlined what you use the data for, you can't use it for... Let me rephrase. You can only use the data for the purposes that you've described. So if you haven't described a purpose, you can't the data for it. This is super important, and this is actually where many companies are putting limits on themselves.

So do a bit of groundwork and figure out what you use it for. But also remember, you can't just put all types of purposes in the world, because the GDPR also has some principles that we need to make sure that you've covered as well. Because you can't get excessive amount of data and use it for every purpose in the world. That wouldn't be lawful because that would go against it, like the core principles, that you should only get data on a need-to-know basis and not a nice to know basis, okay?

Then what you'd also need to do, and this is specifically for example if you're selling online, is explain... And by the way, you need to explain always why you're getting the data and the legal grounds. But this example that I'm giving is for selling online. You need to explain to people what grounds you have for capturing and processing their data. It can be that they, for example, gave consent to receive email marketing. If that's the case, well then of course you're allowed to have the data because they said yes to it, and to send them those types of emails.

You could also be contractually obligated, and this is really relevant if you're selling online, because you need to abide by the contract that the user and you entered into. You need to be able to send the goods to the user when they paid, and you are contractually obligated. So that's one of the classic and also recommendable legal basis to include in your privacy policy when you're selling online. You could also be because you're performing a public task.

Then there is the interest clause, which is more if you're interested in capturing the data, where it's more than from the user's perspective. This is kind of a wobbly legal basis. Many companies are using it, but you just need to be very mindful and think a little bit about it, if that's the one you're using. You can use more purposes for capturing data. So you might in your privacy policy, and I have in ours for example, said that in some cases we're processing data on behalf of consents that's primarily only related to email marketing and cookies.

For the majority of all the users we're getting to subscribe to our service, well, we have a contractual obligation to capture the data so we can lock them as a customer and give them access to our product. We also need to defend ourselves against legal claims. So for our service work, helping companies to collect direct consents, right? It means we're able to prove that we actually did that. We helped the company and the user to collect those consents. And we needed to capture that information for a longer period of time, because it might be that our customers would get sued or might get a claim from a data protection authority. And here then, we would help them being able to defend themselves.

And if you are processing data on the basis of consent, you need to tell people that they can draw their consent at any time. So that means if people are giving you consent, at the same sentence you should be telling them how to withdraw it. And only also include that information in my public privacy policy, and I will recommend it you do the same.

Then you also need to tell them for how long you're keeping their data. That can be really difficult to do if you don't have a private data retention policy. So the first thing you should be doing is saying, "All the data that I'm collecting..." Like you do in a spreadsheet, there are also tools out there that can help you. But simply say, "Okay, I'm capturing consents. For how long do I keep them?" And that's the column you would have. "And then when would I delete them?" The same for, let's say invoices that could contain personal information as well.

So as in Denmark, you would be able to retain an invoice for five years due to the Bookkeeping Act. So you're required according to Danish bookkeeping rules, that to document and be able to document that people bought from you five years later. You need to have it for five years, but after that, you no longer have a legal basis for keeping that data, meaning it should be deleted.

This type of information also needs to be in your privacy policy. And you should tell about the retention of that data in regards to the different types of data you're collecting. And then as I also already have mentioned, remember that requested data, it is a nice... It's not a nice to have principle, it's a need to have principle. So it can't just keep data forever and ever, you can only keep it for as long as you have a need to have basis for it.

One of the finds that we've seen from different data protection agencies including in Denmark, has been around data retention, because there is so many companies out there that still do not have a data retention policy. And then there are many that have a data retention policy, but actually don't delete the data. So what the regulators have been doing is actually going out to companies and knocking on the door and say, "Okay guys, we're from, let's say the Danish Data Protection Agency. We would like to see your data retention policy."

And then you would go in, you would find it. And then they would say, "Okay, great. I can see in your CRM system, you're locking that you would keep account information for..." I'm just saying something random, "Five years." This would be too long in some cases and other cases, by the way. And then you would go in and then the agency would say, "Okay, give me... Just open up four different accounts in your CRM system."

And what has actually been the problem in these cases is that it was so easy to see that there were actually accounts that were way above five years. Meaning they didn't live up to the data retention policy that they actually created, meaning they were in violation of their privacy policy. It's the same, it's super easy also to see in your privacy policy whether or not you have data attention included, and whether or not it's with okay length, in terms of how long you're going to keep the data.

Then your privacy policy needs to include information about how you keep data secure and safe. In the GDPR, there is a requirement as a data controller, but also as a data processor, that you need to make sure that you have the right security measures in place. So therefore, that needs also to be described in your privacy policy, because you're giving people the privacy policy at the point in time to read by the way, when you're capturing their data. Meaning that's the right thing and the right moment to give that information, so therefore, include it in your privacy policy.

What I normally recommend and suggest that you do is kind of have a document on your website describing why you guys have secure practices in place. It could be some kind of white paper or a data practice document. That's what we have, and it actually works really well because instead of them having to go in and update your privacy policy all the time, you would update your privacy practice documents so that it contains all the right information. And you can also use it, especially if you're in B2B sales, in your sales process.

I would include it on my website so that people would have access to it and they could read it. You could also send it to them, but that's more tricky if people are signing up to services online. So therefore, this is just a recommendation, it's not a requirement.

You also need to include information about who you share the data with. This could be made in brackets or maybe in groups as well. And you can also, if you choose to, have it outlined specifically for each vendor, but that is actually not a specific requirement. Then you need to tell people about their rights. You need to tell them about how they can get access to the information you have about them. You need to tell them about their right to request that their data is deleted. And by the way, you don't always have to delete the data just because a user asked you to, because you might be legally obligated to store that data for a longer period of time.

The perfect example, again, back to the invoices. You are required according to Danish Bookkeeping Act, to be able to document the goods that you've sold. So if your user wants to be deleted and that require... Because the name is on the invoice, that will require that the invoice is also deleted. That isn't something that the user can require, because that would mean that you would be in violation of your other obligations. But it doesn't mean that you shouldn't be deleting other types of data, data where you don't have a legal obligation to keep it.

Then you should be telling people about the fact that they have a right to get their data restricted for processing, how their data can be edited, and also in some cases, the right to data portability. Data portability is for example, very much related to when you're signing up to different types of platforms. Facebook could be a good example. Here, you have a right to data portability, which means that you can request Facebook to, in an easy way check with some technical software for example, to take the data you have at Facebook, and then transfer it to another platform if that's something you would like. Or actually, just have it on your laptop.

When we're talking about these data protection rights, you need to remember you have only a month to respond to the user. So when a user is asking you to tell him or her about what data you have about them, you need to actually respond within a month, this is super important. What I recommend is actually, you do kind of like a little drill. What works really nicely is that if you for example, have a support team, you could send a fake type of request and say, "I would like to get access to my data. Tell me what you have?" And then the support team, we need to build a process around how to actually handle those types of requests. What system should they be looking into? Where could they actually find the information? And actually make it in a format where the user would be able to see the data that you're capturing.

Then your privacy policy needs to include information about who people can complain to. So they cannot, of course, complain to your company. Here, you should include information about what emails should they be writing to, could they call you, and what's the process? But you should also, and this is a requirement, include information about the data protection agency that you're regulated by, and information to the agency. So that would, for example, include an address, a phone number and a link to the agency's website.

And then you also need to, of course, include your business contact details. So that's your company name, your address, email, phone number, web address. And then remember, this is also super important and something companies often forget, is to include the date of when you actually went live with your privacy policy. And if you're updated, you also need to make sure that people are informed about the updated privacy policy before it actually takes effect.

So some of the more formal requirements is that you need to make sure that your privacy policy is accessible when you collect your user's information. You need to make sure that your privacy policy is easy to understand and easy to read. Many companies might get their privacy policy from a lawyer, and therefore it's written in a way that the majority of people have very little understanding of what it actually means. The right to data portability can be difficult maybe, for some to understand. So maybe if you have that type of headline, describe what it actually means afterwards. And then make sure that you can prove that you gave users access to your privacy policy, before they gave you their information.

Finally, remember to actually do a review of your privacy policy once in a while. It is with 99% certainty that if your privacy policy is from 2019, that's the last time you updated it, that something has changed. You have either captured new types of data, you might be using it for different purposes. You might be having different security settings. You might be using vendors in other countries, you might have new data retention policies. So you need to make sure that you take a look at your privacy policy once in a while.

I would, for example, do an annual reel where you're just simply updating it and make sure that, that is up to date. But what's also important is to remember that the legislation might have changed. So it's not just taking a look at the type of data you use, but it's also taking a look in regards to the legal landscape. Are there new rules? Are there new guidelines? So that, that is also included and taken into consideration when you're updating your privacy policy.

Just to sum up. Normally, I would always recommend that you don't rely on processing of people's data on the basis of consent. On this, we're talking about cookies and email marketing. And then you in your signup form, inform people about your privacy policy. So here you can see, this is a signup form, and we'll tell people that we're processing your data in accordance with our privacy policy, at the point in time where they're giving us the information. And remember, this is not a consent. That's why there's no tick box here. It's an information requirement pursuant to the GDPR that we're hereby giving people the right to, and thereby also complying with our obligations according to the GDPR.

So that was kind of like the next steps for you to consider, and for you to take into hopefully your little internal checkbox. I'm just going to stop sharing my screen. So I have a question. So Anders is asking, "So easy to understand and easy to read, or are there any specific requirements according to the authorities?" Actually, it's a good question. So the BBC actually made a survey a year ago, and found that the licks numbers in privacy policies were way beyond any other types of documents, and other types of articles that you would read online, meaning they were almost impossible to read.

So if you go to the ICO, the ICO is the UK data protection authority. They have some really good guidelines and some really good explanations on drafting a good privacy policy. But what you should keep in mind is the type of people you are selling your products to, and who you are capturing data about. You should speak at the same level as they are at, or the same type of way to communicate. I would always say that make it in everyday language. Don't use terms that come from the GDPR necessarily. Well, that's fine too, but use something that people actually understand. Like personal data, that's the word I use, could also be a personal identifiable information, PII, but that's a long word and it's not very easy to understand.

Then Anders has another question. "Are there any legal requirements, whether your privacy policies should be in your mother tongue?" The legal requirements are that the privacy policies should be in the same language as your website. So if your website is in Danish, I would recommend having the privacy policy in Danish. You should always make sure that if, for example, you're in Germany and you have a German website, it needs to be in German. The same goes for Spain. So yes, you need actually to make sure that the privacy policy meets and fits with your website and the way that you're normally communicating with people.

Yeah. Any other questions? I have another one. "How do you inform people before you change your information policy? We are a transport company. How do you inform all potential passengers before you change?" Well, that's such a really good question. So normally, lot of the privacy policies are of course, easy to implement when you have sign up forms. If you have an app that people... Let's say you're a transport company and you are... Let's say you're running trains. And people could through their app, buy the tickets. Well, in the app, you would then inform about the new upcoming privacy policy.

If you don't have that, and you're actually a transport company, you would actually have to send something as ordinary, for example, as a letter that doesn't really scale, I know. And if you have... Let's say 4,000,000 users, it's definitely not ideal. Then you might have newsletters. Then I would say, send maybe a newsletter. That's always a good thing, where you're telling people, "By the way, we've updated our privacy policy so that it is again, up to date with how we'll like to process your information. This will take effect, just as an example, on January 1st, you can read it here." And then that's the way that you communicate to people.

And by the way, what I've seen is that if you do a really nice email, it can actually also be a gateway for you to get good dialogues with customers, and use it as a way to get them engaged in your product or with your service.

Are there any other questions? If not, we are actually perfectly on time. So I will send you out an email afterwards, and I want to thank you for taking the time and enjoying the lunch with me maybe, and see you guys soon. Take care, bye,