GDPR for SaaS

The General Data Protection Regulation (GDPR) went into effect on May 25th, 2018, but some companies - especially those relating to IT and software - may still be scrambling to catch up with compliance measures.

If your business offers Software as a Service (SaaS), you may still be struggling with the full implications of the GDPR on your business. For example, have you performed a full inventory of your entire database of memory and backups? Do you have a Data Protection Officer in place, or do you know if you need one?

If you're still not sure that your SaaS company has reached flawless GDPR compliance, this article is for you.

A Quick Overview of the GDPR

By now every online business should be familiar with the basics of GDPR requirements. Here's a simplified summary of its main tenets:

  • Privacy Policy - Privacy Policies must be public and written in clear language, stating which personal information is collected, for what reasons, and who it is shared with.
  • Data Protection by Design - Also known as Privacy by Design, security and protection protocols of personal data should be designed into the infrastructure of the business and its systems.
  • Rights of the European Union (EU) Consumer - The individual consumer rights of the GDPR must be communicated and upheld.
  • Data Protection Officer (DPO) - Certain companies will be required to hire a DPO to oversee the management of personal data and advise on GDPR compliance.
  • Legal Basis for Processing Data - Communicate and comply with a legal basis for processing customer data. In most cases the legal basis is consent, legitimate interest, or entering into a legal contract.
  • Breach Response Plan - Responses and solutions to data breaches must be performed in accordance with the GDPR.
  • Data Retention - Personal data should be retained for no longer than necessary to fulfill the agreed-upon services.
  • International Data Transfers - Transfers of EU user data over international borders must be EU-U.S. Privacy Shield-certified and utilize the EU Model Contractual Clauses.

These requirements will apply to almost anyone who collects or processes data from EU residents, regardless of where in the world the business is located.

A Terms and Conditions agreement isn't required by the GDPR legislation, but it's very useful for any online businesses. A Terms and Conditions document is also known as a Terms of Use document or Terms of Service document.

Implications of GDPR for SaaS Companies

Whether your SaaS business operates on a B2B or B2C format will make a big difference in how your company will be dealt with under the GDPR.

If you are a B2B operation that handles the personal data of your clients' customers, this would make you a data processor. On the other hand, if you market your software products directly to consumers, you will be considered a data controller.

The data controller is the owner and controller of consumer personal data and collects it for their own purposes. They will make final decisions regarding data processing.

The data processor has possession of consumer data for purposes of processing but only in the ways that the data controller instructs them to do so.

A very important point to remember here is that either party may be held responsible for GDPR noncompliance by supervisory authorities, and so it is important that both parties - the processor and the controller - are following GDPR requirements.

Penalties for GDPR infringement could be as high as € million or 4% of annual global turnover, so compliance on all fronts is worth the effort.

Data Inventory

One of the first measures you should have taken while preparing for the GDPR was to conduct a full data inventory of all personal data you have on file for EU residents. If you cannot separate EU consumer data from the remainder of your database, then a complete inventory would be necessary. This includes personal data that is kept on backup drives and that dusty old computer in the back storage room.

The reason for this inventory is two-fold. First, it will ensure that you have not retained any personal data unnecessarily. Secondly, it will let you check that you have a legal basis for the personal data in your possession.

For example, if you were hired by a business client to process their customer data but have since parted ways with that client, then you no longer have the right to retain their customer data. The data of past clients and their customer databases must be deleted.

The same goes for log files, client file uploads, diagnostics data, and so on. If the data can be connected in any way to an individual living in the EU, then you will need to have a valid reason to possess the data and a legal basis to process it.

When it comes to data retention under the GDPR, if in doubt, the best policy is usually to delete it.

Another alternative may be to anonymize data that is no longer necessary for processing. Your diagnostic records, log data, and outdated backups may be anonymized in such a way that all personal information is removed and only the non-personal facts remain. If the data cannot be connected or retraced to an individual, then it can be retained indefinitely.

Establish a system for deleting or anonymizing personal data records after they are no longer used. Since the GDPR allows data to be retained only as long as it is necessary for the purpose it was collected, old unused data must be deleted after a reasonable amount of time. Many software companies have an automatic system that deletes or anonymizes unused personal information after a few months.

You must state your data retention procedures within your Privacy Policy. This is simply a statement describing how long you intend to retain consumer data and under which circumstances it is retained, as illustrated by this clause in Adobe's Privacy Policy:

Adobe Privacy Policy: Data retention clause

Note how it includes information about what happens to specific data when a user closes an account, stating that some information is deleted immediately while some other information is retained for seven years. You should try to be as specific as possible in this clause. If you have different retention periods for different types of data, disclose this.

Legal Basis for Processing

Regardless of whether you are a processor or a controller, you must ascertain a legal basis before processing any EU user data. The GDPR sets the possible lawful grounds for processing data as follows:

  1. Consent
  2. Fulfillment of a contract
  3. Legal obligation
  4. Protection of an individual's vital interest
  5. Public interest or vested authority
  6. To fulfill the legitimate interest of an individual without intruding upon individual rights and freedoms

In the vast majority of cases, a SaaS company will utilize consent, legitimate interest, or legal contract as lawful grounds for processing data.

In the case of a contract, a written contract must be kept on record and in the case of consent, the consent must be obtained in way that is deemed fair and valid by the GDPR. You must be able to show proof of valid consent in order to process the data.

If you are a processor of the personal data, it will be your responsibility to request records of valid consent, proof of contract, or legitimate interest from the data controller before processing any EU consumer information.

Finally, even if you have updated your consent acquisition methods to reflect GDPR policy, you should ensure that you can prove valid consent for any older data you have on record. If you cannot prove valid consent on all records of personal information, you will need to perform a repermission campaign to request the consent of all EU data subjects before processing their data, even if their personal information was already in your possession. Consent only counts if it can be confirmed via a clear record.

Be sure your Privacy Policy discloses your legal bases for collecting user data, as shown in Globalscape's Privacy Policy:

Globalscape Privacy Policy: Legal basis for processing clause

If you have different legal bases for processing different types of information, disclose each basis and how it relates to each type of data.

Data Protection Officer

There is a common misconception that if the data controller has a DPO, then the data processor does not need one. This is not necessarily the case. According to GDPR Article 37, these are the scenarios in which a Data Protection Officer would be necessary:

  1. The processing is carried out by a public authority
  2. The core activities of the controller or processor consist of processing operations which require regular and systematic processing of data subjects on a large scale
  3. The core activities of the controller or processor consist of processing on a large scale of sensitive data or data relating to criminal offenses

Scenarios one and three above will rarely apply to a SaaS business.

However, scenario two says that if "the core activities of the controller or processor consist of processing operations which require regular and systematic processing of data subjects on a large scale." This indicates that any processor or controller who systematically processes large quantities of EU consumer data would need a DPO. The question is, what qualifies as a large quantity?

Unfortunately, the GDPR does not define what "processing data on a large scale" entails, but the Article 29 Working Party suggested that this applies to companies like banks, social networks, behavioral advertising firms, and other organizations that process enormous quantities of consumer data on a day-to-day basis.

If your company is processing data according to the first or third scenarios above (processing sensitive data, information relating to criminal offenses, or data from a public authority) then a DPO will be required automatically.

Another important takeaway from this requirement is that if both a data controller and their data processor qualify, then each entity will need its own DPO. If you are in doubt as to whether or not your SaaS needs to appoint a Data Protection Officer, it would be wise to seek advice from a privacy consultant.

In the case that your business does require a Data Protection Officer, his or her contact information will need to be listed in your Privacy Policy, even if it's just an email address.

Slack keeps this Privacy Policy section short and sweet:

Slack Privacy Policy: Data Protection Officer contact clause

Some DPO contact clauses will be far more robust with the full name of the DPO, a physical address, phone number and other methods of contact. However, so long as you provide at least one method for users to get in touch, that will suffice.

EU Consumer Rights

The GDPR grants eight rights to individuals in the EU. Any company that processes EU consumer data must respect these rights and acknowledge them in their Privacy Policy as well. However, not all rights will apply to every business or every situation.

While some of these rights are simple and straightforward, others may be challenging for a SaaS infrastructure. Below we'll describe each of these rights and their respective implications for a SaaS business.

1. The Right to Be Informed

The right to be informed requires that businesses be open and transparent about how and why personal data is collected from individuals and how it will be used.

As long as your company or the data controller in charge of information collection informs users about when, what, and how information is collected, there should be no problem. These points should be disclosed in a public Privacy Policy so users can be informed.

2. The Right of Access

Under the right of access, you must be prepared to provide EU data subjects with full access to the personal information you hold about them. This may require some programming changes that allow users to login and download a full report of their data records including log data, diagnostic records, or uploads that could be defined as personal information.

3. The Right to Rectification

Under the right to rectification, consumers have the right to edit or correct their data at any time, or request that you do so for them. This can be facilitated by allowing for independent customer logins that let each data subject view, edit, or delete their own information whenever needed. Or, provide contact information for users to make requests of you to do so.

4. The Right to Erasure

The right to erasure comes with some limitations. You're only required to honor a request a user makes under this right if you meet any of the following:

  • You no longer require the personal data at issue for its originally-intended purposes.
  • The user has withdrawn consent for you to continue processing their data, and processing had been done based on consent as its legal basis.
  • You are processing the user's data unlawfully.
  • You have a legal obligation to erase the data.
  • You cannot successfully argue that your legitimate interests in processing the user's data outweigh the user's right to have it erased.

Many SaaS providers are altering data and backup systems to work on a per-customer basis so that the entire history of each data subject can be recalled or deleted on command.

5. The Right to Restrict Processing

Data subjects may request for their data to cease being processed in part or in full at any time under the right to restrict processing. Your SaaS backend should be designed with the ability to temporarily make some data unavailable for processing, or with a separate system to move data to if a user requests it not be processed. That way you aren't deleting the data but simply making it null.

6. The Right to Data Portability

The right to data portability only applies in some specific situations, so your SaaS may not be affected.

According to Article 20 of the GDPR, data subjects have the right to request and receive an organized and machine-readable copy of the personal data a business holds about them when the data is processed based on either consent or a contract, and when that processing is carried out by automated means.

If it's feasible, the data subject can request that you transfer this data to another company on their behalf.

If your SaaS does automated processing of data of users you have contracts with or have requested consent to process from, you need to have means in place to comply with this right.

7. The Right to Object

The right to object is similar to the right to restrict processing. Under this right, a customer can object to further processing of their data if the data is:

  • Being processed for direct marketing
  • Being processed under a claim that it's necessary for carrying out a task in the public interest or in the exercise of official authority vested in the controller
  • Being processed under a claim that it's necessary for the controller or third party to process it for legitimate interests that don't override the interests or rights of the data subject

For objections to processing other than direct marketing, users must give their grounds for making the objection. Processing must cease unless it can be demonstrated that there's a compelling legitimate interest in processing that is so important that it overrides this right of the data subject, or that processing is necessary for establishing, exercising or defending a legal claim.

8. Rights Related to Automated Decision-Making or Profiling

Data subjects can object to companies making decisions about them using automated software processes and no human involvement. Consumers may also object to being automatically profiled according to their age, gender, interests, etc.

If your SaaS app has any processes in place that are fully automated and make decisions regarding your EU customers, you'll need to give users the right to request human intervention in such decisions.

The EU consumer rights listed above must also be mentioned in you Privacy Policy. You can see an example of how this might look in the Globalscape policy:

Globalscape Privacy Policy: GDPR user rights clause

Other GDPR Requirements to Keep in Mind

There are a few other key requirements of the GDPR that will likely affect your SaaS platform.

Breach Notifications

If a data processor experiences a data breach of EU consumer data, the controller must be informed as soon as possible and the EU supervisory authorities should be notified within 72 hours of the breach. It appears that supervisory authorities are going to be stringent in the enforcement of this statute, so it would be wise to have a data breach alert system and planned protocol in place before any data leaks ever occur. Your software systems and human staff should know exactly what to do if a breach does occur.

Privacy by Design

If you weren't designing software and and data handling systems with data protection in mind already, now is the time to start. Privacy by Design (PbD) is no longer an industry best practice. It's now required by the GDPR. Any system that handles personal data, from the company website to software and storage systems, should be designed to provide strong data security and protection. Any data breach or loss that occurs due to system weaknesses or design flaws will not be taken lightly by EU supervisory authorities.

You should make mention of your security and privacy design measures in the Privacy Policy, as shown in this clause by Slack:

Slack Privacy Policy: Security clause

International Data Transfers

If your company works with any data controllers or third-party vendors in other countries, this will concern you. If EU consumer data must be transferred over international borders, the transfer must qualify as EU-U.S. Privacy Shield certified or similar EU-recognized safeguards and also uphold EU Model Contractual Clauses. Find out more information about this on the Information Commissioner Office's website.

Also be sure to describe your international transfer procedures within your Privacy Policy, as demonstrated by Adobe:

Adobe Privacy Policy: International data transfer clause

Data Protection Impact Assessment

A Data Protection Impact Assessment (DPIA) will only be necessary on rare occasions, but this requirement is good to have in mind on the off chance that it becomes mandatory for a certain project or client.

A DPIA is a method for identifying and minimizing potential risks to data security in certain high-risk situations. The GDPR states that a DPIA is mandatory if a new data processing project presents "a high risk to the rights and freedoms of natural persons."

The type of scenarios that would fall into this category are large-scale data processing projects that involve:

  • Sensitive categories of data such as ethnicity, religion, sexual orientation, and the like
  • Data relating to criminal records information
  • Extensive profiling or automated decision-making

Now that you've delved a bit deeper into the GDPR requirements as they apply to SaaS businesses, do your compliance measures cover all the bases?

  • Know what data your SaaS collects and processes, and under what legal basis
  • Keep records of consent you obtain, and obtain it correctly
  • Facilitate the 8 user rights and note them in your Privacy Policy
  • Update your Privacy Policy to disclose as much information as possible to keep your users informed