Attribution in the age of GDPR: What you need to know about data privacy

Attribution GDPR data privacy dreamdata

The recently announced rulings against using Google Analytics in the EU has sent alarm bells ringing across the SaaS space. In this guest post, Openli is sharing 10 GDPR obligations every business needs to be aware of.


Data privacy matters. And not just because European regulators are tightening the rope around the issue, but because we owe it to customers and ourselves to keep data from unwanted eyes. That’s what motivated the GDPR push in the first place.

At Dreamdata we really care about data privacy. Data privacy shouldn’t be an afterthought, especially in the attribution and analytics space - which relies on collecting and processing large amounts of customer data from across sources.

With the spotlight fixed on the question of data privacy, there’s been growing concern on how to go about handling your data - and in particular which vendors you can rely on sharing your data with.

But data obligations can be difficult to understand.

 
stine openli


So we’ve invited Stine Mangor Tornmark, CEO at Openli to share 10 GDPR obligations that you (and your vendors) should be fulfilling.

 

10 obligations of GDPR compliant SaaS operations


Data is essential for all companies. It's critical to know how people use your product and services, how your customers are, what funnels work. Your entire CRM system and marketing tech stack are dependent on data about people. 

Therefore, GDPR (The General Data Protection Regulation) is a critical piece of legislation for all companies to know. 

Most companies know about the GDPR in broad terms, but it can be challenging to understand your specific obligations when you process personal data about people.

Did you, for example, know that there is an obligation to keep track of all the vendors you use and share personal data with

In the following, we've outlined some of the obligations that you should be aware of and remember: 


  1. Have a privacy policy - available everywhere, and every time you collect data about people


A privacy policy is a legal document required by the GDPR. The policy needs to explain how and why you collect people's data. It needs to be available to people when their data is collected.

The information that needs to be in the privacy policy is outlined by Art. 13 and 14 of the GDPR. As a company that handles personal data, you must, e.g., tell people what they use people's data for, who they share it with, how they protect it, why they are allowed to process it, and what rights people have. 

2. Have all the necessary documents & agreements in place with your vendors


It is an essential part of the GDPR that you only share data with companies that can sufficiently guarantee that the processing meets the requirements of the GDPR. By having a contract in place with the required terms, you ensure that your vendors comply with the GDPR, that the personal data of your customers, users, and staff is protected, and that both parties are clear about their roles and obligations.

The contract is called a data processing agreement (DPA). A DPA is a contract between you and the company that you share data with. The DPA must lay out the roles and obligations between you concerning the processing of personal data. It needs to describe the purpose of the processing, the personal data processed, and the types of people subject to the processing (customers, employees, customer's employees, etc.) 

Both the Danish Data Protection Agency and European Commission have made templates that you can use for your DPA. The template created by the Danish Data Protection Agency and the template created by the European Commission are both available online. 


3. Know what to look for in a data processing agreement


Article 28 of the GDPR sets out specific terms that a Data Processing Agreement must include:                                   

  • What data is processed,

  • Who the data subjects are,

  • What the nature of the processing is,

  • The purpose for the processing of data,

  • The security information,

  • The subprocessors,

  • The transfer mechanisms.

It's always good to have a signed DPA in place with your vendors. It shows that you have reviewed it and not downloaded it from a website just before a customer or an authority body, e.g., a data protection agency, asked for it.

Having a signed version in place also makes it harder for the vendor to change the terms at will. Many prominent vendors often update their terms and conditions and DPA. If you don't have previous versions on file, it can be complicated to see what they have changed, e.g., if they added new subprocessors or altered the types of data they are processing, etc. So, when you make sure that you have a signed version in place, it's much easier to review and see your rights and responsibilities.

Usually, you'll also find a section about the vendor's security measures. It's important as the vendor needs to have appropriate security in place and comply with it. Many vendors have different security certifications like ISO27001, SOC2, and ISAE 3000 reports. It is always a good idea to receive a copy of your vendor's security certificate(s), so you can show that they comply with the GDPR.

4. Do you know who your vendors are? 

Attribution data privacy

When we are talking about vendors, we are talking about:    

  • The systems, platforms, and tools you are using in your organisation, e.g., payroll, HR, finance, marketing, sales and so on.                

  • The solutions that help you with invoicing, expenses, surveys, personality tests, recruitment, ERP systems, tracking of website visitors, newsletters, and webinars, e.g., Pleo, Economic, Platypus, Unit4, Bamboo, etc.        

  • The consultants you hire, e.g., to help with budgets, payroll, recruiters, office management, etc.                    

  • The hosting platforms that you are using, e.g., Google Cloud, Amazon Web Services, Microsoft Azure, etc.                                                                         


Many think that Google is their vendor, but that's not always enough. As an example, your vendor could be Google LLC or Google Ireland. Similarly, Mailchimp isn't a vendor you are using if you are using the mail service. The actual name is the Rocket Science Group, and they have a service called Mailchimp. It's not enough to know the full company name of the vendor. You also need to have the company's contact details, such as the address and country of the vendor, the contact details of the privacy team, and the company registration number if possible. 

Let's say that your company uses a third-party vendor to help you with CRM, then that third party will be processing data on your behalf as a data processor (you are then a data controller). It's actually a legal requirement under the GDPR Art. 28 that you have an agreement with your vendors and that you can make sure that your vendors have the appropriate organisational and security measures in place.

5. Know your subprocessors


Vendors like Salesforce, HubSpot, Slack, and Datadog all use subprocessors to deliver their services to their customers. A subprocessor is a data processor handling data on behalf of a vendor that is also acting as a data processor. 

Here's an example: 

Datadog uses Atlassian to deliver its service. This means that Atlassian is processing data on behalf of Datadog's customers. So if Openli were using Datadog as a processor, Atlassian would be regarded as a sub-processor.

In the data processing agreement between Openli and Datadog, Atlassian should be listed as a sub-processor as they would be handling data about Openli's customers.

As stated above, If you are using a vendor that processes personal data on your behalf, you're responsible for ensuring that the vendor - and the vendor's processors, i.e., your subprocessors - complies with the GDPR. 


6. Know if you or your vendors transfer personal data outside Europe 


Part of the assessment of your vendors includes knowing where your data is stored and processed. If your vendor is transferring your data outside of the EU, you need to ensure that legal agreements are in place. The reason is that other countries outside the EU don't offer the same level of protection when it comes to data protection and privacy.

If your vendor is transferring data outside the EU, many vendors rely on something called a "SCC". SCCs are standard contractual terms from the EU that contain obligations regarding data protection. 

If you use a vendor outside the EU, you can use the SCC to ensure that the non-EU vendor complies with the GDPR. SCC's can be a stand-alone legal contract or incorporated into the Data Processing Agreement.

7. Schrems II and what it means


Schrems II refers to a European Court of Justice case. The case was brought to the Court based on a complaint from the Austrian citizen, Maximillian Schrems.

The complaint concerned the transfer of his data from Facebook Ireland to the company's parent company Facebook Inc. Schrems argued that Facebook Inc. did not sufficiently protect his data. He also argued that the transfer was in breach of his EU rights as the law enforcement authorities in the U.S. had access to his and other Facebook user's data.

The Schrems II verdict is essential because the Court of Justice declared that companies must ensure sufficient protection when data is sent outside the EU. For EU companies overall, this means to know who you are sharing data with abroad and what security steps they take to ensure that data is well protected.

8. Transfer Impact Assessment


Recently, marketers and SaaS companies have been talking a lot about how Google Analytics (GA) has been deemed unlawful. The problem was that GA was found to be in violation of the GDPR due to website visitors' data being sent to the US without the proper security in place.

However, this issue does not only relate to Google, as every US vendor that you use needs to be assessed. This is what in GDPR-terms are called to do a transfer impact assessment or a "TIA". 

Doing a TIA is probably one of the most complicated procedures under the GDPR - and a full description would need its own article. In short, part of doing a TIA is to know your transfers, identify the basis for your transfers, assess whether the basis is effective, and apply the technical, contractual, and organisational measures needed to protect the transferred data. It's important that you do an individual assessment of each non-European vendor that you use.

9. A record of processing 


If your company is handling personal data, you are required by the GDPR to keep and maintain an up-to-date record of your data processing activities. 

Article 30 of the GDPR lists what you need to document as a company handling data. This includes, but is not limited to: 

  • The contact details of your privacy team. 

  • The purposes of the processing – why you use personal data, e.g., customer management, marketing, recruitment. 

  • The categories of individuals – the different types of people whose personal data is processed, e.g., employees, customers, members. 

  • The categories of personal data you process – the different types of information you process about people, e.g. contact details, financial information, health data. 

  • The name of any countries or international organisations that you transfer personal data to outside the EU. 


10. Check if you need a DPO 

That GDPR requires that you appoint a data protection officer (DPO) if your core activities require you to handle sensitive data or large-scale, regular, and systematic monitoring of people (for example, website tracking). Many companies that handle personal data won't be required to appoint a DPO, but it can nevertheless be a good idea. 

The primary role of the DPO is to ensure that the organisation processes the personal data of its staff, customers, providers, or any other individuals in compliance with the GDPR. The DPO can be an integral part of the company and may also have other tasks, as long as they don't conflict with the primary responsibilities of the DPO.

Previous
Previous

We tested self-reported attribution. Here’s what we learned.

Next
Next

Announcing new product: Content Analytics