GDPR - option to not capture / keep email address etc?

[Jenn_Pellerin]

Hello -

This could be answered elsewhere, but I cannot find it.

I'm trying to make GDPR global in our instance to avoid any headache in the future. I am making the "I consent to receive future communications ..." etc on every form. However, I keep getting hung up on the capturing / retaining data on forms.

If someone fills out a form to be emailed one of our white papers, do I also have to put in an option to not keep / retain their information? Email, name etc?

I read the statement below here: GDPR Compliance and WordPress Forms: Everything You Need to Know - Ninja Forms

"To Store or Not to Store?

Drop dead easy way to comply: if you don’t need a record of the data collected via your forms, then simply don’t store the data. This eliminates any question of GDPR compliance. Just zip on over to the Emails & Actions tab of the form and toggle off (grey) the Store Submission action and make sure that if you’re using an email action that the email doesn’t include form fields with personally identifiable data."

Can someone point me in the direction of more information on this? Is this also legally required? And how would we be able to email content if they do not want us to have their information?

[SanfordWhiteman]

Drop dead easy way to comply: if you don’t need a record of the data collected via your forms, then simply don’t store the data. This eliminates any question of GDPR compliance

Ha, anyone who thinks there's a "drop dead easy" interpretation of GDPR hasn't been paying attention.

Anyway, within Marketo there is no way to both capture information from forms and not store information from forms. For as long as the lead exists, their historical Activity Log exists. So at present you need to delete the lead -- there is no anonymization technique that will allow you to act on a Filled Out Form activity and then scramble/empty it.

[Jenn_Pellerin]

Thank you for your response Sanford Whiteman​

I am re-reading the GDPR pdf from Marketo. It is quite helpful with understanding the different ways of consent: https://www.marketo.com/ebooks/the-gdpr-and-the-marketer/

(I'm sorry to bombard you with these questions if you are unsure. But thought to continue on this thread in case someone else has the answer)

1. Page 9: a disclaimer that these fields are required and the person is acknowledging they agree to our privacy policy. Fine and dandy. Is it then ok to have this persons information and it is up to them to update their preferences on our preference center (which will be on the bottom of a confirmation email etc?)

[Grégoire_Miche2]

Hi Jenn

The GDPR, taken rigorously, would require that you in fact have 2 opt-in fields:

• One consent field for the daqta storage. In fact, this one could event be made mandatory (if one does not consent, they cannot submit the form since they do not authorize you to store their, not even 1 minute)
• One consent field for the various treatment you might do with the data, first of which is sending emails

The issue is that no one wants to multiply the number of consent fields, so people are merging all of them in only one fields that covers all the consents thus creating the misunderstanding and grey zone pointed out by Sanford.

Until Marketo implements these ideas, and especially this one, most Marketers and DPOs I work with will go for a smart campaign based anonymization, knowing that you can still reengineer the data for 90 days (after which the Data Value Change activities are discarded by Marketo, per their retention policy that will become applicable next august).

-Greg

[Jenn_Pellerin]

Thanks Grégoire Michel​!

Pardon my naiveté, but I thought making that field required was not allowed under the law? Or is that just for sending marketing emails?

[Grégoire_Miche2]

Making the field opt-in field mandatory is not allowed unless the optin is required to process the associated service. In the case of the optin to store the personal data, if you no not have this opt-in, then the data cannot even enter Marketo and therefore, one should not be allowed to submit the form... But this is only possible if the data storage opt-in is separated from the other opt-ins.

-Greg

[Shannon_Kelly1]

Greg, by "smart campaign based anonymization," do you mean a Smart Campaign that replaces all the "personal" data with default values?

[SanfordWhiteman]

Not just data, but completely clearing the activity history (which includes all the data necessary to reproduce the lead) using a Flow step. Returning the person to the same place they'd be as an anonymous lead.

[Grégoire_Miche2]

Yes, this is it.

But you need to be aware that the activity log will still enable to retro-engineer the data for 90 days.

-Greg

[SanfordWhiteman]

Is it then ok to have this persons information and it is up to them to update their preferences on our preference center (which will be on the bottom of a confirmation email etc?)

Thing is, it's all still fuzzy as far as technical implementation. Even a not-lying-we-really-do-GDPR law firm won't understand checkboxes and pre-fill and so on.

Are we denying people access to change their preferences, by simply making them go to your Preference Center instead of displaying them in every single place we can? It's undeniable that we're discouraging them based on what we could technically offer them, but whether that rises to an illegal level of denying, who knows? It used to be fairly clear that a method of unsubscribing needed to be easy to find and, um, not fake. Now we worry that we aren't prominently featuring the Uninstall button, so to speak.

I think overall (like Greg says) people underestimate how severe the consequences are of the strictest interpretation of the GDPR.  If you want to stay incontrovertibly legal, unlike the supposedly "drop dead easy" suggestion above, you must not process forms at all.  Perhaps if your form posted to an anonymous web service, and data only existed in memory for as long as it took to send an email (you could only attempt to send it one time, since after that you've implicitly stored the data!) maybe that would pass muster.  Not that we can do that with Mkto, though.