Forum

Thread tagged as: Discussion, Forms

Perch Forms, Storing Responses and GDPR

Hi,

With the upcoming legislation I'd be interested in hearing from other Perchers on their stance on storing from data.

In the past I have always enabled 'Store responses' in my Perch forms, because email is not always reliable and it’s good to have a fallback. Now however GDPR is stating that we should only store personal data (e.g. enquiry forms asking for Name, Email, Tel No etc) when absolutely necessary, and if so in a secure way e.g. with encryption and/or pseudonymization.

So, therefore I am considering switching off 'Store responses'.

Does anyone have any thoughts or insights on the matter?

Thanks.

Simon Clay

Simon Clay 127 points

  • 3 years ago

If this is a business enquiry, wouldn't this mean that you have have reasonable justification for storing the responses initially but not keeping them stored for long periods of time? You will of course need to make sure that the website form has suitable wording at the point of submission together with a link to a privacy policy there as well. The privacy policy would explain what you do with the data.

As part of GDPR, it would also be a good idea to do some data flow mapping for yourself to establish how the data travels. For example, a web form will send the data to a number of places, such as Gmail if using that, web hosting company etc.

Duncan Revell

Duncan Revell 78 points
Registered Developer

When you say "my Perch forms", do you mean forms on your website, or forms that you create for customer websites? If it's on a customer website, it's up to them - you need to explain that they have the option to store the response, let them know the relative security of the form (https, server security), let them know that permissions can be set for only certain users to be able to see the form responses etc. Then it's up to them - they can justify the storage (email isn't always reliable) and they must come up with a reasonable process in which to export/delete the response and they must document it (their own documentation and "privacy policy" documentation).

If, heaven forbid, there is ever a data breach , they need to be able to stand by the decisions they make now, especially if the breach is serious enough to warrant an investigation by the ICO.

There really isn't a simple "this is what to do" answer...

Simon Clay

Simon Clay 127 points

Thanks very much for your replies. The question was regarding clients sites as well as my own.

I agree that making clear to clients of their obligations and to visitors of how their data is stored and processed is important step in becoming compliant.

But, is ‘storing responses’ on a Perch website GDPR compliant? Even if it’s for a short time? It’s not encrypted, or pseudonymised, so I’m not convinced it’s compliant.

Is encryption and pseudonymisation even a requirement? I can’t tell from the ICO documentation.

Perhaps it’s not required and therefore it’s ok to store responses (provided you inform and gain consent).

Well, if encryption and pseudonymisation is a requirement, pretty much all websites/databases will fail that one won't they?

For my pennies worth, I think the solution from a CMS point of view would be the ability for Perch to automatically delete all form submissions after a specified time set by the user, in the same way you can now with spam comments in settings for the blog app.

Glen

Simon Clay

Simon Clay 127 points

Yes Clive, I think they will fail on that requirement. If indeed it is a requirement...

Encryption / pseudonymisation is mentioned 4 times in the legislation:

“ ... implement measures to mitigate those risks, such as encryption.” - P51. (83)

“ ... appropriate safeguards, which may include encryption” - P121 (4.e)

“ ... including inter alia as appropriate: (a) the pseudonymisation and encryption of personal data.” - P160 (1a)

“ ... unintelligible to any person who is not authorised to access it, such as encryption” - P163 (3a)

Each of the above use the words like 'such as' and 'may include' which makes it hard to know whether we are obliged to take measures like this or not.

Rachel Andrew

Rachel Andrew 394 points
Perch Support

The whole thing with GDPR is you need to document what you are doing and what you are not doing with data. I commissioned an article for Smashing by someone who actually knows what she is talking about to make this stuff clear.

https://www.smashingmagazine.com/2018/02/gdpr-for-web-developers/

The self hosted nature of your data is likely to be far more of an issue than the CMS software you use at the end of the day which will be the same for every WordPress or other self-hosted solution. Anything we do at our end immediately falls at that hurdle. I'm going to write up a page for the site about this but ultimately Perch already collects the bare minimum of data (email address to create an account, we can't anonymise a login email for obvious reasons). Anything else is up to you and your clients. Perhaps you shouldn't be collecting that data at all on your own server? Just as you wouldn't store credit card numbers (I hope).

We also can't tell you we are compliant with anything, as we literally don't know because it is so dependent on your use case and your hosting. We can consider feature requests that people believe will help with compliance, but that's as much as anyone in our position can do.

I will add this as a Suggestions post but I think it's a good idea from Glen above to have an option to run a scheduled task that would delete form responses.

Simon Clay

Simon Clay 127 points

Thanks Rachel I will read the article.