Privacy Concerns as GDPR Compliance

Very interesting! This may be something for the ideas queue. Also, should we not wait on the core discussion until we know from the module maintainers there is something the module cannot override?

I agree.

Hi!

Sorry, for some reason i missed the notification in twitter. We will take more detailed view of this issue bit later but i will quickly brief the current situation:

It's still bit too early to say if there are some things that gdpr-module(we are not very far in the development) could not do because of core-issues, but it is quite likely that there are some. Currently our plan is to implement(are are partly implemented already)
a) GDPR-checklist that includes checks and recommendations for configuration and contrib modules that would fix issues as well as general GDPR-things that won't necessarily be anything Drupal-related directly. This checklist could then also be used as proof to authorities that your company is trying it's best to follow GDPR.
b) Add any recommended configuration and settings we can via core hooks(registration forms etc.)
c) Provide users all data(extensible by other modules) site has saved about them with option to ask for data removal from admin.

We started with Drupal 7 because most sites are running it currently and this is something that all EU companies need right now.
All suggestions and patches are welcome.

IANAL and this is not advice, but I've been doing some work on GDPR recently (and presenting partly about it at DrupalCamp Lannion). The main elements, IMHO, are:

• organizational issues, entirely out of our scope
• an up-to-date record of automated processes. Here Drupal could:
  • at least provide at description of the types of personal data core handles by default, with links to more information
  • provide a hook or other mechanism for modules to declare the data they handle
• need to obtain opt-in for any treatment, with explicit action (opt-out is out!). The user register form mode might include a legal field displayed by default, and acceptance forced to disabled by defaut, in order to ensure active opt-in before registration
• means for users to access their personal data kept, and access an export of these data: a module like the existing GDPR contrib looks like it could be a starting point for this
• need to encrypt personal data without access to those without a need to know matching the opt-in agreement given
• record of actions on personal data, and purge of these actions. Could be helped by an extensive logging system
• and a need for individual sites to override any of this, because regulations differ vastly between: organizations below 250 staff or above, those handling data with higher risk, like gender, race, religion, politics, and those exercising public authority.... and we know how much government use exists for Drupal

Plus probably some reminders during installation about the compliance requirements: just because GDPR seems to have the most stringent requirements to date doesn't mean other regions don't have comparable requirements, even if they are more lax.

From my limited understanding hearing back from a very pessimistic, dry and dull GDPR workshop, these are what I see as the three main challenges for Drupal sites to become compliant. (PII = Personal Identifiable Information)

• Data minimisation on dev / stage environments - PII should not be stored on non-production environments, therefore we need a mechanism to mask the data for non-prod while ensuring it's still meaningful
• Pseudonymisation - Separating PII data from non-PII data - storing IDs for PII data and the actual PII data in another database.
  Potentially this could be mitigated by an encrypted database and SSL, but many hosting companies do not offer DB encryption. Should we be encrypting the PII data tables, and would this even matter if it's readable from the application layer anyway?
• Right to be forgotten for Core modules, and contrib is a headache (think Commerce, for example). Difficulty in managing third-party remove requests (e.g. mailchimp, payment providers, etc.). Conflicts with the need to maintain financial records, etc.

I think there's so much uncertainly around interpreting the requirements. If anyone is or knows any data lawyers in the EU it would be very helpful to clearly interpret the requirements so we can think about these for the Drupal project but clearly this will become a priority.

As Drupal professionals it's important we ensure our clients' websites are compliant too and this is where responsibility (think fines) comes into play. At a GDPR workshop there was an implication that site maintainers could be equally liable for non-conformity and breaches. Ouch - for an agency with a lot of sites that could be expensive.

Sites with simple contact forms and user profiles are easy to manage. I think the problems come from many of the third-party modules that we rely on so heavily. These may all need rewriting to conform to the regulations if the worst interpretations (like the ones I listed above) are correct.

I would not be so pessimistic, although the output from the BOF at DrupalCamp Lannion was definitely not optimistic either: in most case, I think that, as web/data processing professionals, but not lawyers, we are likely (country dependent, probably) to have a duty to advise customers about the existence of possible legal issues, and recommend referring to a law professional, possibly through their DPO (data protection officer), in order to get technical requirements we can implement to allow compliance. Not forgetting the periodic simulation exercises which appear to be mandatory.

On the plus side, the ability to validate compliance with the declaratory duties (registry, etc), and the required ability for data portability, and resumption of service after an intrusion, all of which appear to be required from site owners' DPOs ; these are likely to push some reluctant customers towards a more fully fledged maintenance schedule.

Such duty to advise matches the IEEE/ACM code of ethics we are normally expected to apply as basic good practice as IT professionals anyway. And the reason why I think our duties do not go significantly further in many cases is the very fact that, in all jurisdictions I'm aware of, non-law-professionals are simply prevented by law from providing law-related advice, which means our web agencies just cannot legally provide compliance advice, only technical advice on how to implement the provisions required by customers' legal counsels.

I just found a link which indicates some use cases to implement from a development point of view (although we should clarify the legal obligations before going further): https://techblog.bozho.net/gdpr-practical-guide-developers/.

FYI for Russia we use module fz152 that covers "Consent checkboxes" and that's enough

@Simon - that's an excellent article. Thanks for posting that. It looks like most of these would be fairly easy to add to Drupal.

I'd suggest discussing this topic in this dedicated Group: https://groups.drupal.org/node/518197

I also contact other individuals from other GDPR-related contrib projects to gather there and let's start common brainstorming about the topic.

For Drupal Commerce, a good start may be https://www.drupal.org/project/commerce_gdpr

1. Right to Secure Data Processing (default)
2. Right of Access
3. Right to Rectification
4. Right to Erasure
5. Right to Data Portability

Minimum personal data storage.
You can only have access to those who are absolutely necessary.
Mask the data where you need it.
Encrypted personal data storage. https://www.drupal.org/project/drupal/issues/2962250

In my opinion, it would be good if the drupal core would support encryption of fields.
For example, when creating a field, you can activate encrypted storage by encrypting the check box.

If personal data is encrypted, it is not mandatory for the authority to report the case in case of database leakage or database stolen as the data is stored in encrypted form.

That would be great relief.

I'd love to see some consolidation around the GDPR modules - there are a lot of duplicate efforts and folks not building upon the work of others.

Definitely - we should all chat on the group pages

-

Not sure if it is of any use but related item over at WordPress which might be of interest - https://make.wordpress.org/core/2018/03/28/roadmap-tools-for-gdpr-compli...

@mgifford i agree with you. The law will enter into force on may 25, 2018. Then the rules of the GDPR are obligatory for all pages where Europeans have access... so practically for all websites. So it's important that Drupal offers a complete solution that covers all rules of the GDPR.

Because the time is running...

https://drupal.stackexchange.com/questions/255107/is-drupal-ready-for-gdpr-compliance

I will share requirements that I had on the subject so maybe there can be a roadmap for this issue eventually:

1. Ability to anonymise / erase all personal data of a specific user,
2. ability to export all personal data of a user to csv (possibly other data formats would be OK as well).

The above should be possible for the user in question and / or for the site administrator as requested by the user.

For a complete solution I used commerce_gdpr, views_bulk_operations and vbo_export modules.

Also I think we need a different approach here, with the standard "Drupal core issue approach" it'll take half a year, not 2.5 weeks.

I forgot about automatic anonymisation / deletion of data after a configurable amount of time passed since last usage.

@Graber: I totally agree that a "Drupal core issue approach" takes too much time. But not on the long road. But for now... because time is running, can the GDPR rules fullfilled with existing contrib modules? If so, how about writing a detailed manual for it on drupal.org for every important GDPR rule? You say that you are using other contrib modules for a complete solution.

If no complete solution exist, then we would have to improvise and add options such as "delete all personal data" in a contact form or something and we would have to do this manually as soon as a request arrives.

@handkerchief

"can the GDPR rules fulfilled with existing contrib modules?"

Yesterday on DrupalCamp Transylvania I presented an overview of the currently available contrib modules in relation to GDPR requirements. Please find my slides here: https://goo.gl/5HhFVJ (The session was recorded, but I guess it may take a couple of days for organizers to edit and publish the videos.)

As I did in my talk, I also emphasize here again: consider the contrib modules as a "toolbox" of available building blocks, not a "one-click-good-to-go" solution. Imagine like cooking: based on the given situation your legal consultant/DPO will provide the custom-taylored recipe of which food to cook. Now you know the ingredients available on the market, so it's your turn to map them together.

"If so, how about writing a detailed manual for it on drupal.org for every important GDPR rule?"

Personally, I really like this idea. I see the newly revamped Documentation system of Drupal.org would be a perfect fit to host such a generic guide. What do you think?

Good idea with the doc guide. Can someone create a main page and a sub pages for D7 and D8? I can cover the D7 part with Drupal Commerce.

@Balu: I almost thought you meant your last part sarcastically. :)

Yes please go on with the doc guide. I hope it will be quickly written down so that it can help many who use Drupal but are unsure about GDPR.

First the disclaimer, IANAL, and this is not legal advice. For legal advice, you must hire a lawyer.

However, I am currently serving in the board of the GDPR supervisory authority in Norway. I have been appointed to that office by the government in accordance with Article 53 of the GDPR. I will immodestly state that I am currently deeply involved in the GDPR-adoption process in Norway.

As many others have said: Getting ready for the GDPR is not really about IT or software. It is certainly not about the Drupal core (so I think this issue is somewhat misplaced in the core issue queue – there should be a separate Drupal.org-project for community discussions about GDPR compliance).

Over the past six months, I have worked with several web site controllers to make their websites GDPR-compliant. Balu Ertl has (in the slideshow linked in comment #41) made an excellent job of summing up what Drupal projects exist to help you, but I want to highlight the non-IT side of the process.

To reiterate: GDPR-compliance is mainly about organization and documentation. Therefore, unlike most other contributors to this thread, I am going to talk about other things then IT. In particular, I will share some of my experience from my work on making web-sites GDPR-compliant and perhaps also suggest a tentative checklist of the things you have to get in place before May 25. Feel free to suggest changes to this checklist.

Also: I am writing this from the perspective of the processor. My choice of perspective is based on the assumption that in the terminology of the GDPR, most of us in the Drupal.org community are “processors”.

First, you need to get on board on GDPR terminology. If you have not done so already, review Article 4 (“Definitions”)

Are you a “controller” or “processor”? As I said, this comment is written from the perspective of the processor. If you are the controller, your compliance requirements will be different from those described below.

Your first duty, as a processor, is to make sure there exist a Data Protection Agreement or Data Processing Addendum (both abbreviated DPA) between you and the controller. Article 28 of the GDPR says that a processor can only process personal data provided there exists a contract that stipulate that the processor “processes the personal data only on documented instructions from the controller” – this is exactly what the DPA is. This and the following articles up to Article 35 goes into great detail about this agreement. Read them carefully to determine what you have to do.

If you make use of service providers outside of the EU, you need to ensure that they are “Privacy Shield” certified. If they are not, you cannot use them, and you need to find another provider.

Article 28 also says that the “processor shall not engage another processor without prior specific or general written authorisation of the controller”. This entails that any use of third parties (i.e. IT service providers) needs to be documented in the DPA, and that the processor needs to have a DPA with every service provider that process personal data. I had to drop NodeSquirrel/Pantheon as a service provider, as they did not respond to my requests for a DPA. However, I have successfully negotiated DPAs with AWS, MailChimp and Twilio.

Another major requirement of a processor is that you need to determine whether you are obliged to do a Data protection impact assessment (and if you are, you of course need to do it). This requirement mainly follows from Article 35.

While the duty to “implement appropriate technical and organisational measures to ensure and to be able to demonstrate that processing is performed in accordance with this Regulation” (Article 24 and Recital 74) formally are the responsibility of the controller, it follows from other places in the GDPR (e.g. Article 30 and Recital 82) that the actual task of doing this can be delegated to the processor. (In my experience, this is what most controllers prefer to do.)

The above describes what in my opinion is the major and most time consuming tasks a processor has to do (and repeat regularly) in order to be GDPR compliant.

In addition, the GDPR also has a number of more technical requirements. There is a module for all of these (as already demonstrated in Balu’s excellent presentation).

However, in summing up, I would like to point out that you do not need a module in order to be compliant, and that installing a specific module that appear to address a technical requirement may not make you comply with the technical requirement. For instance, take GDPR Chapter 3 (Rights of the data subject).

Beyond the specifics about the Privacy Policy document, the GDPR does not say anything about how the controller or processor shall go about granting those rights. So while a module that help the processor to comply with GDPR Articles 15 and 20 (e.g. GDPR export) is a noble and well-intended effort, as a controller or processor, you need to understand its limitations. I.e.: Installing this module will not in any way make the site ready to comply with GDPR Articles 15 and 20. To quote from the project page:

“It comes with some useful defaults, but if a site is using additional fields or entities, based on other 3rd party modules, you'll have to implement additional code to export it. See gdpr_export.api.php for more information on that.”

As it turns out, it does not even provide information about content with the data subject's name or nickname attached as a by-line (which I think would be trivial to do, given that entities are in core). Should you receive a Nightmare subject access request asking the data subject to push the “Export all data”-button on his/her user page would probably not fulfill the controllers obligations in response to an access request under the GDPR Article 15.

In my case, I have instead tweaked the core Search module to have a mode where users with the required access can search the site for personal data about a named individual, and also (as part of our efforts to comply with GDPR Article 35) created instructions for staff, telling them how to search and compile a report that satisfy Article 15. To satisfy Article 20 (data portability), we add a data dump created by means of Views.

By writing this, I do not want to discourage the creation of new software tools in core and in contributed projects to help controllers and processors comply with the GDPR, but I simply want to point out that: 1) The usefulness of many if these by May 25 will not be adequate; and 2) Making the deadline of May 25 is possible, but in order to make it, IMHO, you need to focus on organisation and documentation – not on IT.

@Graber @handkerchief @gisle @mgifford
So, here we go:

• 7.x: https://www.drupal.org/docs/7/modules/general-data-protection-regulation
• 8.x: https://www.drupal.org/docs/8/modules/general-data-protection-regulation

As stated, these are only initial, very-first revisions, so further content is definitely needed to be added later on. But at least we have some home for them :)

As this core issue thread has evolved, more and more comments that has less and less relevance for the Drupal core has been added to it.

In comment #44 I said:

I think this issue is somewhat misplaced in the core issue queue – there should be a separate Drupal.org-project for community discussions about GDPR compliance.

Now there is one, named Drupal GDPR Compliance Team.

I hope you will join me there. The project is basically for curating content that may help Drupal system adminstrators make their web sites GDPR-compliant. This goes for both Drupal-related module projects and information, and software tools and information available elsewhere.

If we move the non-core related materials into the Drupal GDPR Compliance Team-project, this core issue thread can re-focus on its original purpose: What GDPR provisions (if any) should be brought into the Drupal core.

In comment #40 above, handkerchief said:

how about writing a detailed manual for it on drupal.org for every important GDPR rule?

I've now made a stab at this, please see #2971865: Document how to comply with every important GDPR rule for the plan.

So far, I've created stubs for these GDPR rules. Please add any GDPR rules you believe are missing as a separate issue (as described in the plan).

Currently, these are all just stubs. With the help of the community, I hope we can get these fleshed out in the days to come. May 25 is not far away.

Added https://www.drupal.org/project/eu_cookie_compliance to list of modules.

agileadam,
this issue is now closed as outdated (re: Status field). For the record, there are a lot more GDPR-relevant modules than https://www.drupal.org/project/eu_cookie_compliance missing here.

For an updated list of modules, please see this page.

If you know about modules missing from that page, please create an issue to add it. We just want to maintain this in one place.