GDPR update – some specifics

There are a few things which have cropped up in various places since I wrote my article on GDPR, so thought a blog post was due…

Google Analytics

If you have a Google Analytics account, you may well have received a couple of emails recently relating to GDPR. Some of you have asked me what action you need to take. Here’s a summary:

Email 1: “Important updates on Google Analytics Data Retention and the General Data Protection Regulation (GDPR)”

• Google have introduced data retention controls, allowing you to specify how long user and event data is held for, with a minimum setting of 14 months. As I understand it, this isn’t going to affect your standard Analytics reporting; to quote Google – ‘the user and event data managed by this setting is needed only when you use certain advanced features like applying custom segments to reports or creating unusual custom reports.’ I set mine to the minimum of 14 months. To do this, go to Analytics, then Admin (cog, bottom left) -> In the Property column, click Tracking Info -> Data Retention. More details here: https://support.google.com/analytics/answer/7667196. If Hexagon has done a GDPR audit for your website, let me know if you’d like me to sort this for you. In many cases, we will already have prevented Analytics from storing IP addresses; this may mean that these settings are not going to change anything, although I confess I’m not 100% clued up on this so recommend setting the minimum anyway.
• If you use Google Analytics advertising features, you need to ensure you are compliant with the Google’s updated EU User Consent Policy (https://www.google.com/about/company/consentstaging.html). As this doesn’t apply to any of my clients as far as I’m aware, I’m not going to cover in detail here.

Email 2: “Data processing terms for the General Data Protection Regulation (GDPR) available for review/acceptance”

• Google have introduced some updated data processing terms (the Data Processing Amendment, or DPA) for people in the EU. You can review and accept this amendment within your account (go to Analytics, then Admin (cog, bottom left) -> Account -> Account Settings -> scroll to bottom of page) and look for ‘Data Processing Amendment’.
• More recently, they have also added a ‘Manage DPA Details’ section, where one adds an organisation name and contact details. Presumably this is because the DPA is not valid without specifying a legal entity/contact details. Click on the ‘Manage DPA Details’ link (you’ll find it in the same place as above), then add your legal entity and contact details.

If you contracted Hexagon to do a GDPR website audit, let me know if you’d like me to sort this out for you. You will need to send me your legal entity name, contact name and email address.

3rd Party Contracts

This is one I’m just going to mention here, without going into huge amounts of detail. The GDPR stipulates that whenever a data controller uses a data processor it needs to have a written contract in place. In theory this means, for example, that if you are contracting me to manage a website that contains personal data – which you are the data controller for – you should be asking me to sign a contract stipulating:

• the subject matter and duration of the processing;
• the nature and purpose of the processing;
• the type of personal data and categories of data subject; and
• the obligations and rights of the controller.

There’s some useful information in the ICO GDPR Accountability and Governance section.

Best Practice: Layered Privacy Notices

A couple of points on items which are considered ‘best practice’ under GDPR, according to the ICO. I take it that this means they are things that are not legally required, but are good to have if possible and appropriate to your situation.

The first is the idea of a layered privacy notice. Under GDPR, individuals have a right to be informed – this normally translates into a Privacy Policy or Privacy Information Notice. Importantly, privacy information should be provided in a way which is concise; transparent; intelligible; easily accessible; and uses clear and plain language.

Often privacy notices are fairly lengthy, and this is where the idea of a layered privacy notice comes in. The idea is to present information to the user in layers, rather than overwhelming them with the whole lot at once. So you could provide people with a summary of each section of your privacy notice, and then link down to the full text for those that want to read it. I gave it a go on my own privacy notice to figure out how this could work in WordPress – see here: https://hexagonwebworks.com/privacy/. This is only a very basic example, but you can see how it aids the user in providing a summary upfront, but still allowing them to drill down to further detail if they wish.

There are other devices that are mentioned in the ICO guidance too – things like privacy dashboards, just-in-time notices, etc. Even if it’s not feasible or appropriate to implement these in your organisation/context, it’s good to be aware of them, so you can make a judgement as to what is/isn’t appropriate.

Best Practice: Re-seeking consent every X years

You will no doubt have been the recipient of some delightful emails asking you to give your consent for XYZ Widget Company et al to continue sending you their newsletter/marketing emails/etc. This is because under GDPR, if you are using consent as your lawful basis for processing a set of data, you need to ensure you have a record of that consent.

Taking that one step further, it has been suggested that the process needs to repeated every X years – i.e. you need to re-seek consent at regular intervals. The ICO guidance says ‘Keep consent under review, and refresh it if anything changes’. Their checklist contains the following checkpoints:

• We regularly review consents to check that the relationship, the processing and the purposes have not changed.
• We have processes in place to refresh consent at appropriate intervals, including any parental consents.

The WP29 Guidelines on consent (p21, linked from ICO consent guidance) state the following:

“There is no specific time limit in the GDPR for how long consent will last. How long consent lasts will depend on the context, the scope of the original consent and the expectations of the data subject. If the processing operations change or evolve considerably then the original consent is no longer valid. If this is the case, then new consent needs to be obtained. WP29 recommends as a best practice that consent should be refreshed at appropriate intervals. Providing all the information again helps to ensure the data subject remains well informed about how their data is being used and how to exercise their rights.”

As the guidance says, if your processing changes, then you need to re-seek consent. But what if it remains the same? Again, following the guidance, one has to take into account the context and the expectations of the individuals in question. I think one would have to weigh up the need for re-consent/levels of engagement with the inconvenience of bothering people with a re-consent email. To me, it seems that it will depend very much on the circumstances and the relationship you have with the individuals in question.

WordPress & GDPR

Finally, just a note to say that the next version of WordPress should contain some GDPR-related updates. From what I read a few weeks back, I’m not totally convinced that the issue of consent (& when it is and isn’t needed) has been totally grasped, but things may have changed since then. It’s certainly a positive that it’s been taken seriously within the WordPress community and the updates should help those who are behind in the GDPR race to catch up a little…