Not up on GDPR Compliance? Read Part 1 here.
Now that GDPR has been around for more than a year and the fires are mostly put out, we’ve had a chance to take stock of how the email industry is adjusting to GDPR.
Trendline deliverability consultants work with all kinds of senders, who have all kinds of different email programs and compliance needs. We’ve noticed a common thread among the various senders to whom GDPR applies. They have an explicit opt-in for each user and nothing else. It turns out that the majority of senders we encounter don’t realize that there’s more to GDPR than simply getting an opt-in–a lot more! Many senders don’t realize that GDPR isn’t even an email law; it’s a data and privacy law, and the opt-in requirement is simply a consequence of the strict rules for the who, what, when, where, why, and how of handling personal data. Senders need to stop thinking of themselves solely as senders and, instead, think of themselves as Data Controllers–entrusted with personal data and burdened with the associated legal and ethical responsibilities.
Here’s what senders need to know about GDPR, but often don’t:
- Data Controllers must keep auditable electronic records.
- This is a common issue for many B2B senders who gather interest at trade shows and expos. A fishbowl for business cards may be clearly labeled as an opt-in request, but as far as GDPR is concerned, if you can’t provide an electronic record of the request on demand, the request didn’t happen. This record needs to include such information as the time and date, the text of the opt-in request, and the personal information provided. This means that senders who gather business cards need to have a computer or tablet available where the user can type in any personal information they would like the sender to have. Many senders assume that their ESP and/or CRM is going to help them with this, and most reputable ESPs and CRMs are happy to, but they can only create records of things that happened on their platform. Therefore, it’s ultimately the responsibility of the sender to make sure those records are created and to work with their ESP/CRM to keep them secure and accessible.
- Complying with Right-to-Know and Right-to-be-Forgotten requests when asked is not enough.
- Most senders know that a data controller has to comply as quickly as reasonably possible with a user’s request to be informed of any or all information the sender has about them, as well as any requests to correct or delete that information. Where we see senders going wrong is in making this a reactive process handled via support ticket. Instead, this should be a documented and repeatable process handled by a specific person or team. Not every company is required to appoint a DPO (Data Privacy Officer) to handle this, but if a company needs to show a regulator that they acted in good faith, they’re going to have a tough time if they don’t have these processes documented along with a DPIA (Data Protection Impact Assessment) from a trained DPO or certified third-party. A full-featured ESP or CRM may be able to provide some assistance here, but responsibility for this is, again, ultimately on the controller.
- Senders must understand the difference between a Data Processor and a Data Controller (and the necessity of Data Processing Agreements).
- A Data Processor does only exactly what the Data Controller tells them. But, and here’s where senders can get into trouble, if a Data Processor uses any of that data for their own purposes, that Processor immediately becomes a Co-Controller and is operating illegally if their use of the personal data was not requested by the user. In June 2018, a court judgment found that the volunteer and non-employee administrators of a certain Facebook fan page were Co-Controllers and therefore on the hook for even using aggregate personal data from the Facebook group only within the limits of each user’s request. The request for personal data, in that situation, should have told the users that the Facebook group admins will be controlling their data along with Facebook and the company who originally asked for the personal data. A “catch-all” opt-in is no good; the opt-in has to call out everyone who will be a Data Controller. Normally, a clear Data Processing Agreement protects the Data Controller from any mistakes or breaches by the Data Processor (and vice versa), but if a Co-Controller relationship exists, things can get considerably muddier. Senders who have partner senders, affiliates, and other such business relationships need to carefully review their Data Processing Agreements (or create them if they don’t already exist) to be sure that they are protected.
- Senders must not gather personal data that they don’t need right now.
- This one is a little abstract, but the GDPR indicates that privacy and protection should be “default and by design” as well as “adequate, relevant, and limited” and “specified, explicit, and legitimate” which, all together, means that if processing personal data is not explicitly necessary to do what the user has requested, don’t process it and, if possible, don’t even have the data. An interesting wrinkle to this is that “deceptive” opt-ins are not allowed and “deceptive” is pretty broad, which, along with the mandate to gather the “minimum necessary” personal data to provide the user with the requested service, means that senders are not allowed to ask for personal data that they don’t need to process to fulfill that user’s request. If it turns out a sender needs more personal data later, they need to ask for it then. In short, even if a user consents to giving you personal data that you don’t explicitly need to do what that user asked, you must not keep that data.
All of this might seem intimidating, but GDPR compliance is quite simple for most senders–do with personal data no more and no less than what the user requests. Simple does not mean easy, however, and it’s important that anyone who handles personal data takes a long, hard look at how they handle that data.
A full compliance audit is an involved affair, and best done by a certified professional, but there are some things you can do to mitigate your exposure (and show good faith to a potential regulator inquiry) right now.
Check this list to get started:
- Review all opt-in language to be sure that how you will use personal data is clearly communicated to the user and is explicitly requested by the user; pre-checked boxes and “fine print” don’t cut it.
- Limit access to personal data internally, and make sure anyone who interacts with it clearly knows the limits of its use based on the request of the user.
- Review collected personal data with the purpose of deleting any that is not relevant to providing users with the service or product they have explicitly requested. Do not hoard personal data for “future needs.”
- Review and clearly understand the extent and purpose of any Data Processing performed by partners, affiliates, and other Processors so that you don’t end up with any accidental or rogue Co-Controllers.
- Review (or create), with your attorney, Data Processing Agreements for any and all Data Processors, partners, affiliates, etc. to make sure nobody is going outside the bounds of your processing requests. Typically, a compliant Data Processor will have their own comprehensive agreement that you’ve already signed, make sure you’ve read it. If they don’t, either get your own in place or ditch them for a more compliant Processor.
- Establish and train on internal processes for handling Right-to-Know requests, Right-to-be-Forgotten requests, and data breaches, including an assigned point person or team to take responsibility for each. These don’t have to be complicated, but they do have to be comprehensive.
- Have your DPO or a certified third-party perform a Data Protection Impact Assessment to discover and remove any potential problems before they arise and help create internal processes and policies that will protect you.
More Resources & Insights