GDPR

No one has provided any review, feedback, or patches related to GDPR.

Here is a list of GDPR resources

• Is Drupal ready for GDPR compliance?
• General Data Protection Regulation
• Drupal and GDPR (General Data Protection Regulation)
• WordPress, Gravity Forms, and GDPR Compliance
• GDPR Compliance and WordPress Forms: Everything You Need to Know

There's a central discussion going on in the core issue queue: #2848974: Privacy Concerns as GDPR Compliance

Hello,

In fact 2 patches were released that could help GDPR compliance.
https://www.drupal.org/project/webform/issues/2962349
https://www.drupal.org/project/webform/issues/2960359

These patches help you to prevent storing privacy related data in your Drupal Database.
You still need to include in your disclaimer that you are processing privacy sensitive data. But at least you are no longer storing it in your Drupal website (which is accessible over internet..).

If your system that is connected to by "remote post" to process submissions is only accessible in your intranet environment, your data is less probable to be found during a hack.

If you have multiple sites in Drupal, like us, and you send all submission data to 1 internal application through Remote post, you centralise all privacy related data and you can easily process inqueries from your users to "get or remove their data".

It is important to note that #2962349: Allow file uploads to be supported when the saving of results is disabled has to still write a temporary file to the file system and database which will be deleted via cron.

The easiest way is to simply remove the ip adress from the submission object and replace with a nonsense address in the webform.module

function webform_client_form_submit($form, &$form_state) {
.....

- 'remote_addr' => ip_address(),
+ 'remote_addr' => '00000000000',

I think there are probably a few issues here.. Even just prompting folks to think about whether they should be collecting the data.

Changing the defaults so that Drupal modules aren't collecting PII is also important.

Great work from Webform on being ahead of many in the Drupal community on this issue.

The most immediate issue that needs to be addressed is allowing a user to view all their submissions across multiple webforms and deleting a user's submissions when their account is deleted. Both of these features would need to be optional for none GDPR entities.

Thanks @jrockowitz - just adding related issues. Data portability would also be a complex one. Giving folks access to their raw data to be able to bring it over to something else. Really not trivial.

Is serializing the stored data to YAML files considered portable?

i'd prolly provide it as json zip, hope google does the same.

Thanks @idevit also, I agree that some structured data is important but that the gdpr is not clear about the format.

Apologies if I'm posting in the wrong place. I can't find an equivalent post for D7. Are there patches available for D7 to prevent Webform submissions being stored? Thanks.

For Drupal 7 try this module - it removes info after the email is sent: https://www.drupal.org/project/webform_clear

We might need to split this ticket into dedicated meta tickets for Webform 8.x-5.x and 7.x-4.x.

GDPR compliance (documentation/UI) hasn't got a home, though this seems as good a place as any. (Apologies for any duplication, please let me know if there is another place for this discussion already in existence - though this directly impacts forms in specific ways).

This issue isn't so much that the data is stored (it will be), it is more that the data is stored or used without explicit permission. Users in my view need to be advised that the data will be stored, where it will be stored, and what it will be used for. This can be handed at the point of the form submission with text that goes something like this:

The following form is to advise us of your interest in our products and services. It is our privacy policy to explicitly let you know where the data will be stored, for how long, and what it will be used for. Your data will be stored on this website and its backups for no longer than [duration], in our email system and on our company database. It is our policy to never sell your details to any other company, though will be stored at our data service provider's companies. Our privacy policy can be read here [link], please direct any privacy related communication to privacy@[your.domain.com]

The main issue will be backups of the site when determining the period of time that data is kept. I suggest some time between 3 months and 12 (I am using 12 months for my company, currently setting this up right now, so it is on my mind). As part of due diligence, this needs to work with the agreements you have with your suppliers.

If you are really keen, add a check box for users to say things like:

• I am happy for you to store my data in perpetuity
• Please delete my data after [duration]
• I give my consent for you to contact me

Obviously this needs to be adapted for each company to reflect their privacy policy, which necessarily goes beyond websites (and digital records - it needs to include all records - including hand written notes, even visitor ledgers!) I'm happy to answer questions from anyone in the Drupal community, but note that I consult to companies (I have to put bread on the table somehow!) Contact me on bruce@enzman.com :)

(PS: I'm not precious and welcome corrections / improvements to the above).

The GDPR Compliance module allows for any entity to be referenced: https://www.drupal.org/project/gdpr_compliance - I have used this on my last 4 projects and it fullfills the requirements of my clients.

Screenshot here: https://www.garypratten.co.uk/webform-gdpr.png

To help point people in a reasonable direction, I added the GDPR compliance module to the list of Webform: Add-ons

The most immediate issue that needs to be addressed is allowing a user to view all their submissions across multiple webforms…

Is it clear to anyone if a user's right to view their own data includes 'admin only' fields - i.e. notes, comments, tags added by staff - i.e. which identify the user but are not created by them? It seems like these might be covered by an FOI request, but I don't see how it's practical to operate many businesses without retaining certain private notes about customers.

I am marking this ticket's status as 'Outdated' because there is now a dedicated Drupal GDPR Compliance Team project which contains all the information referenced above.