Drupal and GDPR (General Data Protection Regulation)

Disclaimer

If probably goes without saying, but we are Drupal experts and not GDPR lawyers. We have tried our best to outline our understanding of the new requirements and how this impacts Drupal sites - this page does not in any way constitute legal advice.

Introduction

After more than three years of planning and discussion the EU's General Data Protection Regulation has been agreed upon. This major legislative change is due to roll out in May 2018 and as website developers responsible for client's websites we must be ready to ensure we all conform. 

Here's a list of the impacts the new regulations have, and how they could relate to Drupal: -

GDPR Country Requirements

Companies with Drupal sites in the EU and any countries outside the EU that target visitors inside the EU are subject to GDPR which is a change from the previous requirements.

Consent of Personal Data

Any personal data must freely be given and opt-ins must be specific and clear. Users who do not give consent must not be discriminated against.

This means ensuring any forms that collect data from users (user profiles, webforms, shopping carts, donation forms, etc.) have clear opt-in fields with concise descriptions, and more importantly that visitors can still benefit from the same features if they do not want to supply their information. In practice this is impossible for supplying good on e-commerce, but does mean freemium offerings in exchange for data may not be allowed.

We must also explain to the visitor how their personal data will be used, by whom, and for how long. We must make clear what is being processed and for what reasons, as well as how long the data will be stored for. We have to also make it clear who the visitor can contact about their data and any processing actions.

We also have to ensure that personal data is ONLY used for the purposes we have defined, so being clear about any potential future intentions is very important at the outset. This means we can't automatically add shoppers or webform submitters to our mailchimp lists without explicit consent for this action.

Our privacy policies must clearly define what we do with the data.

Data Minimisation and Privacy by default

For Drupal development we normally have dev, stage and production environments. Data minimisation means any personal data should be suppressed from non-production environments. This makes testing and development very difficult and if we decide not to do this we must mask the sensitive data in a realistic and consistent fashion - which satisfies the GDPR requirements while still allowing us to test and develop with a meaningful data set.

In production environments this means limiting the data we are collecting in the first place. Do we really need this data? Ideally forms should be streamlined as much as possible anyway to prevent abandonment, but now we should address all data forms again in light of this new question and GDPR.

For data analysis we should be thinking about stale data. Do we still need data points from x months / years ago? Can we mask out older data?

Data minimisation is one of the trickiest pieces to manage, especially in a dev / stage / production environment. Simply dragging databases from production will no longer be an acceptable workflow.

Pseudonimisation, Encryption and SSL

GDPR refers to pseudonimisation. This is a way to transform data so that it cannot be linked back to an individual easily. For example, we could use an ID against non-personal data (commerce product, amounts, shipping costs, etc.) and keep the personally identifiable data in a separate database. This means if there is a data breach on our main database no personal data will be lost. Clearly this is not possible in Drupal at the moment. Major rewriting of many modules including core would be required.

An often mentioned example of this is encryption. If we store the data in an encrypted database then the key is required to decrypt. SSL is very important too - data should be transmitted over secure channels. This is not the same thing, but may go some way to meeting the requirement.

Drupal has a long way to catch up on this requirement but I am sure as time goes on we will see modules that start to take care of data separation. We are already removing any personally identifiable information from a major NGO charity's donation workflow to ensure compliance. The PII data is stored on a completely separate database that cannot be directly read from the application. This means hooking and overriding classes for a lot of Drupal Core and Commerce processes, and securely passing the data via write-only services.

Data Breaches

If there are any suspected data breaches then the Data Protection Authorities must be notified within 72 hours of discovery. An audit must be taken of any suspected data loss and obviously the breach exploit must be fixed and addressed. Good Drupal support and maintenance means we should be keeping all our core code and modules secure and up to date. We should hopefully be storing data on secure hosting platforms too using encrypted databases ideally. 

Right to be forgotten

This has to be one of the trickiest things for Drupal. An individual has the right to be forgotten, which means they can request they're data to be removed from a Drupal website. Data from visitors is typically stored in User Profiles, Webform submissions, Commerce Order data, and any other module data that gathers information about visitors. User Profiles are easy to handle. We can simply remove an account and make its contents belong to an anonymous user. Webform submissions can be deleted. Commerce data is different. We may be required to keep an audit of financial transactions by law and this is in conflict with the right to be forgotten. Speak to a lawyer on this one!

Another important aspect is data sharing. If you are passing data to a third-party service (mailchimp, payment processors,etc.) then the right-to-be-forgotten requests need to be forwarded to the third parties.

The GDPR Drupal Module

There is already a module for Drupal (https://www.drupal.org/project/gdpr) which has (at the time of writing) the following features: -

• Allow logged in user to see all raw data stored about himself/herself (user entity)
• Allow user to initiate “forget me” action from site admins
• Checklist for site admin (recommend modules like cookie consent, check if there is privacy policy page etc)

For the future it is planned to have: -

• Make sure user can rectify all data about himself/herself
• Allow user to remove the account (content is not removed)
• More items and recommendations to checklist
• Add Drush hooks to sanitize data when syncing databases
• Make API for other contrib modules to announce user data stored

This clearly cannot address all of the requirements but shows a tiny part of the Drupal community is trying to address the issue (download count is very low!).

Conclusion

While it's great that there is a module trying to address some of the GDPR requirements it is very clear that each individual Drupal website will need to tailor a solution to the GDPR requirements problem. There will not be a one-size-fits-all fix for this. Site owners must carefully consider all their data gathering and storage functionality and ensure their sites comply with the new regulations. In some cases this may mean major workflow and database changes. Speaking to a professional about these implications is crucial as non-compliance fines are high. This will no doubt involve a fair degree of work to ensure compliance, but it's absolutely essential.

If you have a Drupal website, have clear guidance about what needs to be changed, and you are unsure about how to make the necessary technical and developmental changes then please get in touch and see how we can help.