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.
By now every online business should be familiar with the basics of GDPR requirements. Here's a simplified summary of its main tenets:
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.
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.
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.
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.
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:
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.
If you have different legal bases for processing different types of information, disclose each basis and how it relates to each type of data.
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:
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.
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.
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.
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.
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.
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.
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:
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.
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.
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.
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:
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.
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.
There are a few other key requirements of the GDPR that will likely affect your SaaS platform.
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.
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.
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.
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:
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?