Everything You Wanted to Ask a GDPR Expert but Were Afraid to Ask

If you’re like 99.9% of developers, site managers, agencies and freelancers, the last thing on your list of priorities for the past 2 years has been GDPR compliance. You have a million other tasks on your plate and dumping energy into government regulated data protection laws seems like a complete waste of energy. Especially when you’re not living inside the European Union…those laws don’t affect you, right?!

Think again.

If you follow WordPress news, GDPR compliance is starting to consume just as much screen real estate as the controversial new post editor, Gutenberg. And rightly so.

May 25th marks the deadline for compliance to the General Data Protection Regulation and these new rules apply to any online presence collecting information from residents inside the European Union – and compliance is the responsibility of the site owner.

Needless to say this has massive implications for WordPress users around the world.

But have no fear, some forward thinking members of the WordPress community have been preparing for some time and even started working on core compliance, hooks and resources for the rest of us to learn from and implement.

We asked one of these amazing and generous contributors to break from his busy schedule and provide insight to our team, members and readers. Without hesitation he agreed and his input has been invaluable to our team. GDPR may have more implication on the sites you manage than you think.

So without further ado, we welcome Kåre Mulvad Steffensen perhaps better known as @dejliglama to the WPMU DEV blog.

We sat down with WordPress.org GDPR expert Kåre Mulvad Steffensen.

Joshua: Thank you for taking the time Kåre! Tell us a little bit about yourself, your work and your role with WordPress.org.

Kåre: I’m a developer, turned project manager and to some extent product owner over the years. After a long stretch in my own company working with WordPress full-time since 2009, I’ve recently joined the fastest growing WordPress crew in Denmark at Peytz.dk, where my role is digital consultancy – of course with a huge and overshadowing focus on WordPress. ;)

Peytz presented an opportunity for me to further my involvement in the WordPress community. I’ve been co-organizing the danish WordCamp for some years, and in the shift from self-employed, I found time to read the EU General Data Protection Regulation and started asking around on the WordPress Slack channel to see what was being done. Not much was going on publicly, so together with Peter Suhm from WPPusher.com, I created the gdprwp.com project which I then brought with me into Peytz.

Joshua: Why is this specific topic (GDPR compliance) so important to you?

Kåre: Living in the EU and being quite invested in WordPress (and inhabiting a natural tendency to ask simple questions about what GDPR will mean for both end users and WordPress site owners running any combination of plugins) with my initial poking around in the community, I realised that this was a good place for me to get involved.

I’m not saying that I should build it, nor take the credit for what is being built. I have no coding-hand in that at all. I’m quite happy with the fact that some of our ideas are now being baked into WP core by both core developers as well as developers from around the community.

Our involvement has also given us at Peytz the opportunity to bring our developer Jesper V Nielsen (@jesperher) closer to some of the people behind WooCommerce which he is focused on internally. I believe working close to the WP community and people behind the plugins you use is always a good thing.

Joshua: What do plugin and theme authors need to know or include in their plugins to help those that use them be compliant?

Kåre: First of all, you need to answer YES to the following question: Does your plugin collect or handle personal information? I know that personal information in itself can be confusing, what is that anyway? The one-line answer is any piece of data that by itself or in combination with other pieces of data, can identify a natural being.

  • Name; yes
  • E-mail; yes
  • City; well if it’s a small enough city and you store it in combination with a name then yes!
  • Comments; yes

Specifically on how to make your plugin compliant, Allen Snook @Allendav has written a guide. It is a work in progress and will land somewhere on Make WordPress when we get closer to a first release. For now, it lives here: https://github.com/allendav/wp-privacy-requests/blob/master/EXPORT.md

In more general terms, Heather Burns @webdevlaw and Pascal @casiepa is doing a good job collecting and documenting what you need to know on GDPR here: https://github.com/gdpr-compliance/info

I think it’s vital to mention that a WordPress installation does not become GDPR compliant by simply upgrading to the WP version containing the GDPR hooks and filters. Using plugins with these hooks and filters, you could still miss pieces of personal data that are being stored on your site. It is the owner of the website who is responsible for a GDPR compliant website. We’re simply providing the tools to make this work feasible to handle in a day-to-day scenario with users asking for their data, ratification of data or the “dreaded” and misunderstood right to be forgotten.

Joshua: I know that Automattic’s privacy policy is licensed under Creative Commons. Are they happy for site owners to use that as a basis for their own policy (not sure you know the answer to this.) If not do you have any resources you can suggest for a privacy policy that is compliant?

Kåre: As a rule, you should not copy and paste policy text. With that said, the team is working on getting GDPR into core and is working on a general guide for what should be added into your policy text.

This is one of our focuses right now. We want to create simple functionality for easily putting together a privacy policy: https://make.wordpress.org/core/2018/03/28/roadmap-tools-for-gdpr-compliance/

The idea is to have a page type, like the “frontpage” and “blog” page, that will collect policy texts from WordPress core and plugins that may provide policy text. Any plugin that handles personal data will be able to write a plain text explanation of how their plugin handles personal data. @melchoyce has made some great designs for the tool that will gather the plain text for policy text. https://core.trac.wordpress.org/ticket/43620

Joshua: Perhaps to some extent it already is, but do we think that being GDPR compliant or subscribing to certain privacy practices could be part of plugin and theme reviews for WordPress.org? Sort of like Accessibility-ready themes.

Kåre: Personally YES! I think this extends beyond EU and should be part of any code review. Privacy by design is nothing new, and GDPR simply puts focus on something we should already do. If a review team spots personal data being handled in a plugin or theme, the next step would be to see if the WordPress core GDPR tools are correctly implemented and if they cover all personal data handled by the plugin or theme.

Joshua: Many of our readers manage multiple (often hundreds) of sites. What types of plugins, services have you seen to be the biggest offenders of the new laws that site managers should be on the lookout for in their own sites.

Kåre: Thankfully the major plugins that handle data such as WooCommerce, MailPoet, Gravity Forms and Ninja Forms all realize that their plugins can be used to handle personal data, and are actively looking into what WordPress core is doing – all at their own pace. I’ve had great talks with many of the authors behind these plugins, as well as frameworks such as Redux which is a place we also need to look.

As long as we haven’t got a “GDPR compliance badge” on the plugin repo (or on your website admin plugins page as a site manager) be aware how each plugin on your site is storing, collecting and managing data. again, this is not new. Get in contact with plugin support and ask, if you’re not sure.

Part of the WordPress success in becoming GDPR ready, is to have the entire community of developers embrace the GDPR functionality, and this happens if people ask for it in the plugins they use.

Joshua: Can you think of anything that could easily be overlooked when preparing for GDPR?

Kåre: Things that can be overlooked when preparing for GDPR is data that, when you look at it, is out of context from the bigger picture. The city example from earlier could seem harmless at first, but given that I’m the only one named Kåre in the city that I grew up in – the combination of data makes city personal.

The problem for plugin and theme developers is that that might not be obvious when you look at the plugin isolated, but together with other plugins, that data might be something you would need to put into a WordPress GDPR hook or filter.

Joshua: Are there any site owner/manager checklists you can suggest to our readers that could help them prepare in a systematic way?

Kåre: I’ve seen many checklists, most of them looking at GDPR from a legal standpoint, and few looking at it from a technical one. I don’t think checklists are the solution, so my answer would be no.

Don’t look at this as something you can tick off, but rather ask yourself the simple question; what personal data, alone or in combination with other data, does my WordPress installation handle. Where does it go, and for what reason?

  • What data
  • Where is it stored
  • For what purpose
  • For how long

Joshua: This has been extremely insightful and we really appreciate your time! Is there anything I missed?

Kåre: Lol, well – will the tools in WordPress be ready in time for 25th of May?
I’d like to think so. I mean, I believe that we will have the technical parts ready for a first version. Obviously, there can be more time put into fine tuning and adding solutions in a second version.

We must not forget that the regulatory is new to the world, and we will see legal cases that will shape how we best comply with the law, and therefore we will need to adapt after the 25th of May.

My biggest concern is that new functionality of this magnitude normally goes into major releases, but the next major release is destined to be Gutenberg. So how GDPR and Gutenberg release plans coincide is something that I’d like us to be clear about soon.

On a personal level, I’m happy with where the GDPR tools of this first release are going, and I’ve started to look into some of the tools that should go into a second release – probably after 25th of May ;)

Joshua: Thanks again! This has been really valuable for our team and we are committed to working with the core team to get WPMU DEV products ready for our users. Thank you for your time and contribution to the WordPress Community.

Joshua
We're working hard to make sure our plugins and services are GDPR compliant. As hooks and information is being made available our developers are hard at work implementing the new tools. What are you doing to prepare? We would love to hear from you in the comments.

16 Responses

  • Design Lord, Child of Thor

    I’ve just started auditing my plugins for GDPR compliance, but it’s quite an onerous task at the moment. Lots of checking of privacy policies! A lot of companies are leaving it quite late to announce their approach to GDPR compliance.

    In some cases, it’s hard to tell what personal information may be collected and stored by a plugin without checking the source code itself – how many of us have the time and inclination to do that?

    The GDPR for WP project looks like a great step in the right direction. It would be great to have a list for each plugin to see what personal data is collected, where it goes and what controls site admins and users have over that data.

    • Author

      Thanks for sharing your input Claire! I agree . We’ve started auditing all of our tools and are doing the best we can to prepare. With core integrations still in the works our goal is to ready ourselves (massive undertaking by our plugin development team already being done behind the scenes) and implement when the hooks land.

      The big take away here for me was the reminder that data protection will continue far past May 25th. I was reminded again, that dealing with peoples personal data is a privilege we should never take lightly.

      Speaking directly to your concern with privacy policy information, a tool like Kåre mentioned here sounds like it would be super valuable for gathering all of that information quickly. Of course it will mean all the developers doing their part to provide the information in text form. :) https://core.trac.wordpress.org/ticket/43620

  • Design Lord, Child of Thor

    I definitely agree with Kåre that more attention needs to be focused on the technical side of GDPR instead of just the legal aspect of it. While looking for answers to the question “how do I make my WordPress site compliant?” all I seemed to find is list of what needs to be done. But none are telling me how to do it. The GDPR plugins I’ve seen so far are mostly elaborate cookie consent plugins that don’t really make your site compliant.

    I’m about to launch a membership site where privacy and even anonymity is a key element. I have a great desire to keep their personal data safe regardless if GDPR is around or not. To me GDPR is coming at the perfect moment because it forces developers to think about personal data handling, who might not have given it much attention was it not a legal requirement.

    What scares me is how everyone seems to be waiting on everyone else to present their solution first and procrastinating until the very last minute to implement things. GDPR has been coming since 2016 and it’s only now people are starting to talk about it. My coding skills are not good enough to solve this problem myself. Being dependent on someone else’s solution is giving me a very uneasy feeling. Trying to create my own solution would be an enormous task.

    When I think about how many website owners there are who couldn’t code “hello world’ in PHP if their life depended on it, how are they going to make sure they are GDPR compliant?

    I truly hope the plugins and themes repositories will be transparent in which ones are GDPR compliant soon.

    • WordPress Enthusiast

      Hello John,

      You’re absolutely right. Unfortunately, this is not entirely the fault of plugin/theme devs as they are waiting for the main upstream provider that their products rely on… WordPress. The complicated part is the methods that many plugins store data are native WordPress methods. Which puts devs in a situation where they are trying to keep track of how things are going to be handled in the WordPress core and adjust accordingly.

      That being said, I do know from checking our internal dev trackers that our team has been extremely active on working on making sure our products are compliant. While we’re in the same figurative boat as most devs as far as still waiting on WordPress to finalize how they are going to handle this, we are taking every action possible on our end to work on what we can now.

      Also, as all this gets worked out, you can be assured that our excellent authors here will be keeping our members in the loop and providing some great resources and tutorials on how to make your site GDPR compliant.

      Best regards,

      James Morris

      • Design Lord, Child of Thor

        Thank you for your quick reply, James,

        When I was talking about the waiting in my initial response, I was talking in a much broader sense than the WordPress or WPMU DEV communities. There is still nothing published on how Google, Facebook, Amazon and the likes, are tackling these GDPR issues. I believe these huge companies have a social responsibility, when it comes to these issues that affect us all.

        I’m confident WordPress and WPMU DEV will come with solutions. I only feel a little anxious because we’re barely a month away from May 25th and I have no idea what these solutions will be, nor how easy (or hard) they will be to implement and I don’t have the slightest idea how much time it will take to actually implement them.

        It’s simple fear of the unknown. I know things will be alright in the end, but I hate being in a state of ignorance.

        I’m very excited to find out what you have been working on to tackle these issues and I follow the roadmap very closely.

        Kind regards,

        John van Berghem

  • Flash Drive

    I’d argue in favor of a checklist or guide or other procedure to help navigate this process. The vague advice “evaluate how your business collects, stores, uses, and deletes person information” isn’t quite enough. I found this privacy policy generator helpful:
    https://dsgvo-muster-datenschutzerklaerung.dg-datenschutz.de/?lang=en
    A guide that can help with the documentation and direct your thinking to areas that you might overlook is going to be extremely valuable.

    • Author

      A checklist would be awesome and tools like the one you mentioned can help, but I think what is being communicated here is that it is important to not depend on these checklists and scans to catch every little thing. A list or scan may help you get started…but it doesn’t guarantee compliance.

      We get comfortable with automation and forget these tools are coded by humans that make errors and miss things. This is inline with the recent amendment to the WordPress plugin review team guidelines:

      …developers and their plugins must not do anything illegal, dishonest, or morally offensive…implying that a plugin can create, provide, automate, or guarantee legal compliance.

      So, my recommendation is, if you like the tools and checklists use them, but they are not infallible. Pair the tools with common sense. Protect your user’s data the way you would want your data protected. A checklist can help but it is not responsible if something is missed.

  • Connector

    Hi and many thx for all the information.

    One of the questions I haven’t seen addressed, is about backups.
    If someone asks to be removed, what we’ll do in current records, such as user profile, email address book, etc… but what about them being listed in old backups?

    For example, if I keep a backup of my sites’ sql dumps, for security reasons. And say I have a backup of each day for the last week, each week for the last month, and each month for the last year. Then, the contact information of the person is still in there somewhere, even if removed from the current base.
    I’m not going to manually remove entries in the tables in the backup files, right?

    Does GDPR mention that?

    • WordPress Enthusiast

      Hello PatriciaBT

      There’s some grey area here when dealing with backups. Essentially, there has to be policies and procedures in place that will ensure that the backups are

      1. Properly handled
      2. When restored, the personal data gets removed from the live site as previously requested

      Due to the nature of backups, it’s not practical or expedient to attempt to go through backups to remove personal data. So your handling of the backup if it ever needs to be restored is what is critical.

      I hope this clarifies a bit.

      Best regards,

      James Morris

        • WordPress Enthusiast

          Hi PatriciaBT,

          There’s actually a pretty easy method of doing this while remaining in compliance with the GDPR…

          The GDPR governs personally identifiable data. Things such as name, address, IP addres, phone number, etc… However, a simple, single-column spreadsheet can be maintained for the purpose of recording what users need to be removed from your backups upon restore by simply using the User ID. While this ID identifies the user in context of the relational database, in and of itself, it is not a unique identifier of any one individual because, in the world, there can be millions of User ID # 5.

          A good method of doing this to ensure security would to be use a model like so:

          If the site in question is BobsWidgets.com, title your spreadsheet “BW Backup Delete” and only have the single column of “UID” in the spreadsheet. Even if this document were to be compromised, there’s little chance of anyone figuring out what it is or what it’s context is. Therefore, it anonymized the user data.

          So, when developing your compliance strategy, if you know your backups contain information that will need to be removed if ever restored and a member has contacted you asking for anonymization or entire removal, you can remain compliant by only recording that user’s ID in your internal backup management records.

          I hope this clarifies a bit.

          Best regards,

          James Morris

    • Chief Pigeon

      Hey there.

      So, backups. The GDPR states you should aim to handle the customer request within one calendar month from the day after you received the request. Because some months vary it is advised to use a 28 day period to ensure you comply with the legally required timeframe. Should it take longer than that to remove the customer’s data, it’s ok, but you must communicate with them the reason why and also when that will be done.

      The backups you keep with us are cycled every 30 days. So… you respond to your customer, tell them you’ve removed them from your company website. You should then state that you have backups which cycle and get removed every 30 days and at that point, their data will be removed from your archives totally.

      It would be worth noting how many requests you handle so that if you restore you can remove again and immediately. Using James suggestion above of tracking their UID is a good option, it’s not personally identifiable and with a timestamp, you can clean your spreadsheet ever couple of months or so.

      Also, remember that if you are required by law or there is a legitimate reason for refusal of removal, you can refuse. In the interests of security, fraud prevention, accounting laws, for the purposes of completing the contractual agreement, those are some examples of grounds you can refuse. I’m advised (this weekend at WordCamp London) that a good number of years you could retain the data once they stop being a customer is 7 but less is better and again, there should be a good cause. You must still remove them from mailing lists.

      Something else you have to consider in my last paragraph, a customer with contract (someone that paid for something, even if there is no written contract) Vs potential customer.

      Hope this helps. :)

  • The Bug Hunter

    thanks, there was some good stuff in there :) …thought I’d share a few notes, perhaps save a few folks a few minutes …seems like a good start might be at:

    #43738:11 — (note in comment: Note that wp_blogmeta landed for 5.0 in #37923 and may help quite a bit with tracking export status on individual sites.)

    #43797 | #43546 | #43821 | #43822 | #43551 | ~gdpr

    #gdpr-compliance | and this might be handy 😉 draft version privacy section Plugin Dev guide @ google docs

    Cheers, Max

Comments are closed.