In-House Counsel

Don't Get SaaS'd: Contractual Tips For In-House Counsel Regarding GDPR Compliance (Part III)

There are a lot of things for service providers to consider when it comes to GDPR compliance.

By  
on

As you have likely gathered by now, the General Data Protection Regulation (“GDPR”) has created compliance challenges for not only companies gathering “personal data” (operating as GDPR-defined “data controllers”), but those service providers (think SaaS) that are operating as “data processors” under the GDPR as well.  In my previous two columns, I laid the groundwork for taking a technology-oriented systemic approach to GDPR compliance as well as initial contractual considerations for such compliance.  Having an understanding of what personal data is being collected and how it is being processed, specific policies are necessary to fully implement GDPR compliance, such as privacy policies, data security policies, and data retention policies. For SaaS providers, addressing these policies effectively is essential, but for more reasons than you may think.

Unless you have been hiding under a rock, you probably know that the GDPR has upended how (and even if) companies can gather “personal data” from EU “data subjects.”  Given the substantial fines that can be imposed for non-compliance (i.e., 4 percent of total annual global turnover or $20M euros, whichever is greater), U.S. companies have been scrambling to ensure compliance such as obtaining the requisite consent from targeted EU data subjects to collect and use such personal data.  Even though the GDPR implementation date has been known for the last couple of years, it has not stemmed what can only be described as considerable scrambling by companies to comply.  As a result, a certain amount of contractual chaos has ensued. Why? It comes down to liability and risk allocation.

For SaaS providers, this issue is all too real. Most service providers have found themselves squeezed between their company-clients (operating as “data controllers”) and the actual customers of their company-clients (potential “data subjects”) because such service providers are usually “data processors” that are “processing” the “personal data.” Although existing agreements may have addressed some level of risk allocation between the parties regarding data, the GDPR has prompted many companies (acting as data controllers) to seek unlimited liability for service provider breach. Why? Because data processors not only have specific obligations to data controllers but have specific responsibilities such as ensuring the security of its processing as well as record-keeping obligations.  If not, the GDPR states that data processors can be held directly liable under the GDPR by the appropriate data protection authority (“DPA”) under Article 28.  Of course, there is significant exposure to the companies operating as data controllers, but the point here is that SaaS providers need to be vigilant in avoiding the imposition of liability far beyond what is necessary.

As the GDPR requires that data processors have written contracts with data controllers, it goes without saying that SaaS providers have an opportunity to level the playing field with their company-clients.  In fact, the GDPR requires certain elements and minimum terms (i.e., only acting upon the written instructions of the controller, compliance with confidentiality obligations by people processing the data, implementing appropriate security measures to ensure the security of the personal data, etc.).  When applied to existing agreements, however, specific policies should be reviewed (or implemented) and addenda may be necessary (or otherwise require modification).  Here are a few areas where such providers can (and indeed, should) address these concerns:

Data Security Addenda.  Without question, such policies are at the forefront of GDPR compliance.  As the U.S. approach to “personal information” is different than the more expansive GDPR definition of “personal data,” it is essential to not only implement the appropriate definitional terms in any data security addendum, but specifically insert required elements.  Generally, this should include elements beyond mere security of personal data, such as  (i) the processing of personal data being performed, (ii) personnel obligations (i.e. duty of confidentiality), (iii) any use of sub-processors to do so (including but not limited to any data backup and disaster recovery services contracted by the data processor), (iv) interaction with the controller regarding controller compliance with its obligations, including personal data breach notification and management, and (v) liability limitations.  Auditing of such processing by the controller will likely be requested by the client-company acting as a controller so as to ensure that they both meet Article 28 obligations, but should be delicately addressed so as to avoid unreasonable (or unnecessary) requirements (such as broad or unlimited audits, or audits without reasonable notice).

Data Retention Policies.  Under Article 5 (1)(e) of the GDPR, personal data need not be retained longer than necessary when viewed in relation to the purpose for which such data is processed. For companies that do not have data retention policies in place, they need to do so — the GDPR requires that companies handle “personal data” with care, and if a company does not have such a policy in place, GDPR compliance will be like trying to hit s moving target with your eyes closed.   Moreover, the right of access and “right to be forgotten” impose obligations on controllers (and by extension, data processors) that should not be stymied by ineffective data retention policies.  In fact, SaaS providers should specifically ask their client-companies about their data retention policies so that existing agreements can properly address data retention under the GDPR.  In any event, such policies will help establish a baseline from which to address (or modify) existing data obligations.

Privacy Policies.  I know what you are thinking — such policies are normally customer-facing, so how does this come into play contractually between SaaS providers and their client-companies?  The simple answer is that such policies are likely being revisited by such client companies as a result of the GDPR.  As a result, reviewing the client-company privacy policy will help shape the risk allocation under the existing contract.  Further, for Privacy Shield-certified companies receiving personal data from the EU, the Privacy Shield’s onward-transfer requirements must be met (and for companies not yet certified, their vendor agreements will need to address such requirements before they can be certified).  These policies provide a window into the company operating as a data controller, and should be viewed accordingly.

Sponsored

Needless to say, there are a lot of things for service providers to consider when it comes to GDPR compliance and the points set forth above and in my prior columns on the subject truly only scratch the surface. That said, these steps at least point in the right direction, and should help in addressing the multi-layered challenges of GDPR compliance.  So don’t get “SaaS’d” by the GDPR — your company (and clients) will thank you for it.

Tom Kulik is an Intellectual Property & Information Technology Partner at the Dallas-based law firm of Scheef & Stone, LLP. In private practice for over 20 years, Tom is a sought-after technology lawyer who uses his industry experience as a former computer systems engineer to creatively counsel and help his clients navigate the complexities of law and technology in their business. News outlets reach out to Tom for his insight, and he has been quoted by national media organizations. Get in touch with Tom on Twitter (@LegalIntangibls) or Facebook (www.facebook.com/technologylawyer), or contact him directly at [email protected].

Sponsored

Topics

, , , ,