Are You Liable for the Data Shenanigans of Others? (Part 2 – Controllers and Processors)

Re-posted from intothecyberbreachcom, originally published on September 5, 2019

In Part 1 of this post, we laid a framework for the legal landscape for American businesses and their potential for exposure to State and International law regarding data privacy, very broadly. If you missed it, and you could use a 30,000 foot view, its here.

Now that you know the basics behind GDPR and CCPA, what responsibilities or liabilities do you have in regard to entities that process data it got from you. Let’s walk through a scenario to illustrate what I mean…

Say you’ve got a website that attempts to develop a mailing list or subscriber list. It’s a site about designer sneakers, and it notifies your customers on that list whenever certain sneakers that are difficult to locate, are available for sale in their size. The website is owned by you, belongs to you, is run by you. But… somewhere, you’ve got this little snippet of code on the site, which allows users to subscribe to your page, and enter their name, address, email address, phone, and shoe size. Now let’s say that all of that information about your client, gets stored on a website that does NOT belong to you. So, think of a separate contact management application that you have linked into your site, but is run by another company.

Under the GDPR framework, you would be what is a called a “controller” of the data your customer has shared, and the company that handles your contact management system would be the “processor” of that data.

The GDPR defines a “controller” as an entity that “determines the purposes and means of the processing of personal data.” A “processor” is defined as an entity that “processes personal data on behalf of the controller.” So, why do we care?

According to the GDPR, the data controller is primarily responsible for getting consent to collect data (that will be a topic for another day), revoking that consent, as well as notification of any breaches of that data. This is true even though it may be the processor that actually possesses the data.

Regarding revocation… Recall that under the GDPR, you have a right to be forgotten. Anyone located in the European Union can contact an American company and demand that any data about them be removed. Pretty neato for them! Total headache for you!

So, back to our example: You’ve got this lit sneaker shop online, you have a vendor that collects your customer contact information and their shoe size, and someone contacts you and demands to be forgotten. As the data controller, it would be your responsibility to contact the processor and have them remove that data. It might be as easy going onto your admin page on the processor’s website and removing the information. But… data storage is rarely that easy, and it is more likely that you will have to check the processor’s privacy agreement with you (ahem, which you read ahead of time…. right?) and possibly even contact a human to discuss how the data processor handles GDPR rights revocation requests. As a data processor, your vendor then has to comply with that request to remove the data for you. Simple, right? No, of course not. But, if you’ve followed along this far, you’re already a few steps ahead of the game here. Might as well see the ending, no?

As you know, as a loyal reader of this blog, and as a person who has ever shopped at a big box retail store, when a breach happens the company who was breached has to provide notification to the people whose personal information has been affected… So, what happens when the data that came through your website and into the vaults of your third-party vendor gets hacked into? How about if that third-party vendor did something supremely stupid to enable the breach?

Article 28 of the GDPR requires that “where processing is to be carried out on behalf of a controller, the controller shall use only processors providing sufficient guarantees to implement appropriate technical and organisational measures in such a manner that processing will meet the requirements of this Regulation and ensure the protection of the rights of the data subject.” Thus, not only do Europeans spell “organizational” wrong, they also require controllers to only use processors that are GDPR compliant. Thus, if your vendor is doing something supremely stupid, and you had reason to know about it ahead of time, you’ve violated GDPR. Congrats!

This issue recently came up for Delta Airlines, who initiated a lawsuit against its third-party vendor [24]7.ai Inc, after the vendor experienced a data breach in 2017. Delta alleges that its vendor had weak security protocols and had not notified them of the breach for five months. Of course, Delta, itself, has been fending off lawsuits from its own customers as a result of this breach.

Under the GDPR, “[t]he processor shall notify the controller without undue delay after becoming aware of a personal data breach.” Delta alleges that the data pirate that hacked into its vendor’s system had unauthorized access to names, addresses, and payment card information of approximately 800,000 to 825,000 Delta customers in the U.S. The vendor failed to notify Delta of the breach until one month after Delta renewed its contract with the vendor. Further, the vendor contract required that Delta be notified of any breach. The basis of Delta’s suit is a breach of contract and negligence, not GDPR compliance, per se. Be that as it may, many, if not most, vendor contracts from major players nowadays are going to include terms or requirements that the vendor be GDPR compliant, however they choose to define that. That’s a solid endorsement that you should consider similar requirements in your own vendor contracts.

Back stateside, the new California Consumer Privacy Act (“CCPA”), discussed in Part 1, creates a private cause of action for consumers affected by data breach when that breach is caused by a business’s violation of the duty to implement and maintain reasonable security procedures . Naturally, the plaintiffs’ bar will contend that all breaches are caused by a failure to implement reasonable security procedures. How does that affect our example though?

The CCPA is one avenue where your business may face liability when your vendor fails to secure the data that you have provided it. Fortunately, the CCPA only applies to certain businesses. If you are still in startup mode (< $25 million in revenue), chances are the CCPA excludes you, unless you are in the business of buying or selling personal information. While the CCPA does not use terms like “controllers” and “processors”, the concept is a useful one that many teams are already familiar with. Your vendors will attempt to opt-out of any liability to you for a breach, meanwhile, the CCPA squarely puts the onus on you to ensure the safety of the data being used. The CCPA has a private cause of action, which allows not only for state enforcement, but also for private individuals to sue the pants off of you.

So what is the take away?

First, make sure you understand what data is being collected by any vendors that you are working with. Remember, vendors can be anything from the applications that you add to your website to certain backend service providers. Given today’s expanded view of private personal data, it is likely they are collecting something that would trigger GDPR or CCPA.

Second, read your terms and conditions with your vendors. If you are using systems like Mail Chimp, Google Analytics, or any number of other plug-in style apps in your website to gather data, you are unlikely to be in a position to negotiate with them. But at least know what you are signing up for, and decide whether its worth the risk.

Third, if you are negotiating with vendors, don’t accept their denial of liability for their own data shenanigans. They shouldn’t become your cybersecurity insurance policy, but they shouldn’t be creating unchecked liability for you either.

Fourth, consider using GDPR compliance efforts as an opportunity to work with your vendors to be clear about what they are doing, why, how the data is being protected, and what they are required to do in the event things go sideways. Remember that the purpose of a contract is to prevent litigation.

Last, no legal blog post would be complete without an admonition to ask a lawyer and get actual legal advice.