Cloud SaaS Provider Liability under GDPR

From May 2018, any SaaS provider managing personal data of European citizens will be jointly liable for GDPR requirements.

SaaS providers can manage personal data in unstructured data
  • Type: Blogs
  • Date: 08/01/2018
  • Author: Kyle DuPont
  • Tags: GDPR, Regulation, SaaS, Data Privacy

Even if a the company is not in Europe, any SaaS provider with European personal or corporate clients is at risk for up to 4% of global annual revenue or EUR 20 million.

One of the biggest risks that GDPR will bring is not actually for the large end-user facing enterprises who are used to data protection regulations but rather the companies that these larger companies use to provide services to end users, including cloud SaaS providers providing services for anything from accounting to file storage.

In GDPR parlance, the relevant entities are broken down into: Data Subjects, Data Controllers, and Data Processors. Data Subjects are simply end-users or consumers with data about them stored at a Data Controller or Data Processor. Data Controllers are those entities that are providing services directly to Data Subjects–any company from a bank to a social network. Data Processors are third party organizations that are providing services to Data Controllers and using Data Subject data to do so.


Although Data Processors have in the past been required usually by some sort of contractual obligation to provide Controllers with sufficient safeguards and assurances that Data Subject data is being properly managed, the GDPR significantly increases the risk of Data Processors. The biggest risk among those lies in the extra-jurisdictional and networked nature of the new GDPR along with Article 82, which puts joint liability on both Controllers and Processors.

Under the Data Protection Directive (the predecessor to the GDPR), the onus was on the Controller to ensure that data regulations are being properly followed throughout their ecosystems. However under the GDPR, the Processor is also liable for damage caused by processing of data where it has not complied with the obligations of the regulation or acted outside of the instructions of the Controller. Moreover, Processors are even liable for the actions of third party Processors that they might use to provide services.


The principle requirements for Processors are in Article 28 of the GDPR. In additional to standard contractual obligations like fulfilment of service and confidentiality, some of the most noteworthy requirements and impact of this article are:

  • Controllers are only able to use Processors that are providing sufficient guarantees to implement appropriate technical and organizational measures to protect the rights of the end Data Subject. This means that there must be some sort of contractual language between Controllers and Processors ensuring that the Processor follow the regulation.
  • Processors cannot use other Processors without first receiving written authorization from a Controller to do so. Every time a Processor needs to change for instance a file storage solution or some other aspect of their software stack, they need to inform all of their customers of this fact and provide them the right to object.
  • Processors need to be able to help Controllers respond to Data Subject rights requests such as access, erasure, and rectification. So when a Data Subject requests their data to be deleted from, say a bank, any service that a bank is using must also be able to ensure that that end user’s data is deleted.
  • The Processor needs to be able to show the Controller what data that it has on a Data Subject at any time and demonstrate compliance with the regulation. This means that a Data Processor should have a very thorough grasp of what data they are storing where in the first place and how that data is being used so that a Controller can fulfill their obligations to the end Data Subject.
  • The Processor needs to ensure the security of processing (Article 32) such as the pseudonymisation and encryption of personal data, ongoing availability of systems and services, the ability to restore data in a timely manner in case of an event, and regular testing to ensure the security of processing.


The GDPR is coming into force on the 25th of May 2018. Because of the networked extra-jurisdictional nature of the GDPR, SaaS companies processing any kind of personal data are going to be in one way or the other linked to the GDPR even if they do not have direct European clients.

One of the best ways to start demonstrating action to clients and regulators is to understand and record what your current status is. You can do this by performing a scan of your data infrastructure to find out where personal data is stored. For smaller companies, this might be as simple as maintaining an updated spreadsheet of what services you use and which services hold personal data. Organizations any larger than 20 people may use dozens of services and hold data across many file storage accounts making a manual process more difficult.

Subscribe to our newsletter

Subscribe now