GDPR for SaaS in plain spoken English

A little while back, Google sent out an email to all G Suite owners. Its subject said: “[ACTION REQUIRED] Rollout of Data Processing Amendment version 2.0 to reflect the GDPR.”

That left me thinking — and now writing about what it all meant. This article walks you through the process of becoming GDPR compliant if you’re a SaaS. Since it looks like we can’t put GDPR off any longer 🙌

I’m no lawyer and may have gotten a thing or two wrong, but hopefully, this article serves you well as a good starting point.

GDPR

General Data Protection Regulation is a new European personal information law regulating data stored both online and offline. Regarding the law, personal information is any data that pertains to a specific individual — name, IP, email, etc.

Another important detail about the regulation is it’s new. At the moment, no one has any actual experience: there’s no certification in place, not a darn single thing. My advice here would be to follow the lead of large companies with real salaried legal teams on staff. It’s a safe bet they will start figuring things out.

Now, a GDPR inspection may never come. But, let’s say you get reported by someone or receive a request out of the blue, you better have all your I’s dotted and t’s crossed. 😌

GDPR states that one can only gather personal information once a user has given explicit and informed consent. There’s a loophole, and I’ll cover that below. The law also mandates that users be able to access their personal information, delete it, and receive it in a machine-readable format to allow the transfer of the data to a third party. For example, the third-party detail can be about sending a hospital chart from one system to another.

GDPR recognizes two types of agents: controllers (who collect data) and processors (who process data). A good number of SaaS services are mostly processors (handling outside data), but there are some controller functions they cover (e.g., collecting info when registering users).

Let’s loop back to the loophole. It is as follows: you are permitted to collect and store data that is crucial for your business operations (i.e., “legitimate interests”) “after considering the interests of the individuals involved.” For more on this, check out #5.

What does it take to become GDPR compliant? There are 12 steps:

1. Awareness — inform all employees about the initiative.
2. Information you hold — review all data streams handling personal data; make sure you’re not collecting data more than your product or service needs. Delete misplaced or unneeded data, especially if it just sits in your internal correspondence or ancient backups. Make sure all third parties plan on becoming GDPR-compliant as well (AWS and other major services will obviously do).
3. Communicating privacy information — update your privacy policy. Keep it simple to understand.
4. Individuals’ rights — make sure you provide the right to view (in a machine-readable format 🤖), modify, and delete data (either automatically or via a support request). When users delete their data, it also has to be deleted from any third party you’ve sent it to and can access.
5. Subject access requests — define a procedure to handle user requests regarding their rights under the act. Respond to support requests about users’ rights within a month.
6. Lawful basis for processing personal data — spell out in your privacy policy why you collect specific individual data and what you are planning to do with it.
7. Consent — receive an overt consent to collect personal information, not just “as stated in terms of service.” “Enter your email address here if you want to receive new product information” — OK, while “I agree to whatever” — NOT OK. Provide the option of retracting consent, like unsubscribing from a mailing list. When dealing with sensitive information (criminal records, sexual orientation, etc.), you may need to go all out and bring up a popup asking for additional affirmative consent, e.g., in a way a mobile OS would ask you for consent to share geolocation data, etc. Log when and under what circumstances consent was received.
8. Children — restrict access to your service to European children under the age of 16 (some EU states may lower the permissible age to 13, but that is out of our control).
9. Data breaches — define what your data breach might look like and define procedures for immediately alerting your users and related European Union agencies. Thankfully, most services do not handle data that could be used to infringe on the rights and freedoms of users, so this is typically a non-issue.
10. Data protection by design and data protection impact assessments — adhere to the technical security requirements for data protection in the event of a breach; in case the data can be used to violate the rights and freedoms of users.
11. Data Protection Officers — appoint a data protection officer. Not all organizations require one, but the vast majority do. So, it’s easier to just appoint someone. The DPO “must not carry out any other tasks that could results in a conflict of interest,” though, given the size of the typical SaaS company, this is not always feasible. Do what you can in this case.
12. International — moot point for most, since “controllers without any establishment in the EU must deal with local supervisory authorities in every Member State they are active in, through their local representative.”

While you’re busy chewing through the list, you can put up a stub on your website stating that you will be GDPR compliant by May 25th, 2018 🙄 Here’s a good example, if we do say so ourselves: https://uploadcare.com/about/gdpr/.

Privacy Shield Framework

If your company is registered in the US, you can get GDPR compliant faster through the first implementing Privacy Shield Framework. PSF is well-documented, and I am up to a separate article on becoming PSF-compliant. I will also compile two ready-made cheatsheets covering both regulations. I will post everything the following week.