If you’ve got Google Analytics you’ve probably just received an email from Google giving you some information about how they will help you conform to GDPR in Google Analytics.
Lets have a look at what that means, and what you need to do.
The email says:
|Dear Google Analytics Administrator,|
|Over the past year we’ve shared how we are preparing to meet the requirements of the GDPR, the new data protection law coming into force on May 25, 2018. Today we are sharing more about important product changes that may impact your Google Analytics data, and other updates in preparation for the GDPR. This e-mail requires your attention and action even if your users are not based in the European Economic Area (EEA).|
|Today we introduced granular data retention controls that allow you to manage how long your user and event data is held on our servers. Starting May 25, 2018, user and event data will be retained according to these settings; Google Analytics will automatically delete user and event data that is older than the retention period you select. Note that these settings will not affect reports based on aggregated data.|
|Action: Please review these data retention settings and modify as needed.|
|Before May 25, we will also introduce a new user deletion tool that allows you to manage the deletion of all data associated with an individual user (e.g. site visitor) from your Google Analytics and/or Analytics 360 properties. This new automated tool will work based on any of the common identifiers sent to Analytics Client ID (i.e. standard Google Analytics first party cookie), User ID (if enabled), or App Instance ID (if using Google Analytics for Firebase). Details will be available on our Developers site shortly.|
|As always, we remain committed to providing ways to safeguard your data. Google Analytics and Analytics 360 will continue to offer a number of other features and policies around data collection, use, and retention to assist you in safeguarding your data. For example, features for customizable cookie settings, privacy controls, data sharing settings, data deletion on account termination, and IP anonymization may prove useful as you evaluate the impact of the GDPR for your company’s unique situation and Analytics implementation.|
|Contract And User Consent Related Updates|
|Google has been rolling out updates to our contractual terms for many products since last August, reflecting Google’s status as either data processor or data controller under the new law (see full classification of our Ads products). The new GDPR terms will supplement your current contract with Google and will come into force on May 25, 2018.|
|In both Google Analytics and Analytics 360, Google operates as a processor of personal data that is handled in the service.|
|Updated EU User Consent Policy|
|Per our advertising features policy, both Google Analytics and Analytics 360 customers using advertising features must comply with Google’s EU User Consent Policy. Google’s EU User Consent Policy is being updated to reflect new legal requirements of the GDPR. It sets out your responsibilities for making disclosures to, and obtaining consent from, end users of your sites and apps in the EEA.|
|Action: Even if you are not based in the EEA, please consider together with your legal department or advisors, whether your business will be in scope of the GDPR when using Google Analytics and Analytics 360 and review/accept the updated data processing terms as well as define your path for compliance with the EU User Consent Policy.|
|Find Out More|
|You can refer to privacy.google.com/businesses to learn more about Google’s data privacy policies and approach, as well as view our data processing terms.|
|We will continue to share further information on our plans in the coming weeks and will update relevant developer and help center documentation where necessary.|
|The Google Analytics Team|
Google Analytics is never really going to be the same again. And once they introduce the data deletion controls and people start requesting their data is deleted, we’re probably going to find Google Analytics data less and less valuable from a historic perspective. I always say to people “Google Analytics data isn’t perfect but at least it’s consistently inconsistent.” From this point on Google Analytics data will be less reliable and will now be “inconsistently inconsistent.”
“We just finished our GDPR compliance process. Here are some off the cuff notes:
- Start by making sure you understand GDPR
- Determine if you need to assign a Data Protection Officer. You probably do (large scale/systemic data processing), so assign one anyway.
- Create a spreadsheet and call it your “GDPR Dashboard”
- Google search for “Microsoft GDPR Checklist Excel”, add that to your spreadsheet
- Internally document (GDPR Dashboard is a good place) every piece of personal data you collect, AND their locations (which databases, which columns, which exports, etc). Personal data is any data related to an identifiable naturalized person. An instagram handle is personal data. A user’s email is personal data. A user’s blog URL is personal data.
- For each piece of personal data, establish the legal basis for processing that data. This will be either “explicit consent”, or “legitimate business interest”.
- For each piece of personal data, classify the “identifiability” of that data. A user’s name or street address is directly identifiable. A user’s blog URL or Instagram handle is indirectly identifiable. The # of Instagram posts a user has is non-identifiable.
- For each piece of personal data, classify the risk to the personal rights of the data subject (name/address/email leak = high risk; instagram handle leak = moderate risk; # of Instagram posts leak = no risk)
- For each piece of personal data, determine the “protection class” of that data, i.e., how strictly it must be protected in your internal system. eg: street address = highest protection; email address = moderate protection; # of instagram posts = no protection. These protection classes should map to internally consistent processes (eg, highest protection must be encrypted at rest, moderate protection may not be exported)
- Determine if you handle any “sensitive data” as defined by GDPR Article 9
- Add a new worksheet outlining all your “data processing activities”, ie the specific processing tasks that operates on personal data. eg: “capture instagram followers count”, “export users to spreadsheet”
- For each data processing activity, determine the legal basis for that activity (eg explicit; legitimate interest)
- For each data processing activity, determine whether you have clear, revocable consent for that activity from the data subject
- For each data processing activity, determine the risk to the data subject’s personal rights and freedoms. This is called a “data protection impact assessment” (DPIA):
- For each DPIA, record the types of data involved in the processing activity
- For each DPIA, list any steps that must be taken to minimize the risk to the personal rights of the data subject (eg, encrypt-at-rest; automatically delete after 90 days; obfuscate data, etc)
- Add a new worksheet to your GDPR Dashboard called “Audit Schedules”. Write down a list of various audits (automated and manual) that must be carried out at regular intervals. These may include: “check for clear consent controls”, “check for data portability”, “check for right to erasure”, “automated virus/malware scan”, “automated firewall scan”. Record the frequency at which the audit must occur, the last audit date, who ran the audit, the results of the audit, and the next audit date
- Add a new worksheet called “Third Party Processors”. Write a list of any data processor who handles personal data on your behalf, record which data and processing activities are relevant to them, record how you ensure correctness of the data, record whether they are GDPR compliant, and so on
- Add a new worksheet called “Technology Assets” where you record your various server and database types, what data they store, how protected they are, what the risk and potential damage for breaches are
- Add a new worksheet called “Risk Matrix” where you record various risks to your organization, how likely the event is to occur, what the damage is, and how you are protecting against that risk. Include things like “DDOS attack”, and “database breach” and “unauthorized export of data” and “administrator improperly accessed data” and things like that.
Now start working on your documentation, policies, procedures, and product:
- Create a formal Data Protection Policy (sometimes called an Information Security Policy) that outlines your data classifications, protection levels, audit procedures, access control rules, data retention policies, software development procedures (include how you handle “privacy by design”), data breach notification policy
- Create a formal way for data subjects to request information about the data you have on them and how you are using it. This can just be an email address that you give to users
- Update your product with “clear, concise consent notifications”. ie, if your user connects an Instagram account, make sure there’s some help text that tells them what they are agreeing to and how you will use that data. These should map to your “Data Processing Activities” from your GDPR dashboard. This also includes making sure there are no “dark patterns”, ie, processing activities should be opt-in not opt-out
- Make sure you are only storing and processing data you need. If you are analyzing Instagram accounts and only need basic profile info, make sure you are not also storing Instagram post history, for instance.
- Make sure consent to data processing activities can be revoked as easily as it can be granted. If consent is revoked, make sure the data involved is deleted in a timely manner as per your formal data retention policy
- Update your product with a “data portability” control so that your users can easily export all the personal data you have on them. This can be a simple JSON export of your user record and related data.
- Make sure there is an easy way for users to correct potential inaccuracies in their data
- Make sure there is an easy way for users to delete their accounts
Finally, wrap everything up:
- Automatically revoke any consent for data processing activities that never had explicit consent in the first place
- Look through your DB (informed by your DPIAs) and remove any extraneous/unnecessary data
- Start enforcing data retention, obfuscation and encryption/protection policies
- Make sure all documentation, policies, procedures, are readily accessible in a centralized location
I may have missed something. As you can tell I’ve been deep in this for a while. If you do all of the above you’ll be in better shape than 95% of data processors.”
If you’ve not yet come up with a GDPR strategy then it’s something you really need to be thinking about. If you handle lots of data then it’s something you need to be worried about. You can’t be complacent about this. If you’re a smaller website, a brochure website then you might be able to take a bit more time to see what everyone else is doing. But you do need to make sure you’ve got the basics in place by the 25th May.