GDPR for Startups like yours and mine.

Preface

The new European Data Protection Regulation, Regulation (EU) 2016/679, (a.k.a GDPR) kicked off on May 25, 2016 and it will be fully implemented 3 months from today. It represents the biggest change to EU data protection and privacy legislation in decades.

For big companies, it represents a substantial increase in business risk, from how to approach the change to become compliant, to the introduction of technologies that enable this compliance. For startups, the risk remains, but “change management” should be a lot easier.

In order to scare you

From May 25th, the risk of bad practices dealing with personal data will escalate to the level of money laundering, bribery and corruption.

A fine of 4% of your global annual revenue is possible, and other legal measures will also be introduced:

  • Breach Notifications
  • Class-Action Lawsuits
  • The suspension of storing and processing ANY personal data (including employee payroll and customer information), effectively killing your company.

If fines weren’t enough motivation to keep you awake, there’s also the deliberate lack of information on how a company should tackle these issues; so it makes you do the legwork, understand, think and effectively implement measures.

It’ll also be a great pain to defend or prosecute in court; because what does taking “appropriate measures” and “state of the art security” legally mean? Where does “negligence” sit amongst these? I can’t wait to see the first court hearings on this.

The Overview

Although it may seem tedious now, we must admit that reinforcing the right to privacy and the protection of personal data are the foundations of any advanced democracy and it starts with people who deal with data. People like you and me.

First of all, I must add that this regulation doesn’t apply to European companies alone, but rather to any company that caters or provides services to European citizens. Google and Amazon are valid examples of companies outside the EU which are affected by the GDPR, since they provide services and gather data from European citizens.

As usual, technology develops at a much faster rate than legislation. The previous data protection law, Directive 95/46/CE precedes Google, and one can safely argument that the world and the way we do business has changed quite a bit since then.

Europe has always been ahead of data privacy, especially Spain and Germany. As a matter of fact, this new GDPR will NOT overrule our Spanish LOPD, (law 15/1999 of December 13 nor its implementing regulations (Royal Decree 1720/2007 of December 21), because this attribution corresponds to the Spanish Parliament. The GDPR only calls for a “normative displacement” of that Spanish order if anything opposes the new GDPR.

GDPR essentially focuses on:

  • Privacy By Design
  • Right to Access Information
  • Consent
  • Transparency
  • Security

1.- Privacy By Design

We have to be familiar with a framework called “Privacy by Design“, where we execute an internal Privacy Analysis and design the solution. In the case of our little startup, this can be rather simple, but we need to be able to ask ourselves -and have some answers for- questions like:

  • Am I asking for “too much” information or is the amount of data I’ve got “only sufficient” to run my business?
  • How am I going to request my client’s data? Is it secure? Where will I store it?
  • How am I going to let our customers know about the way we process their data in an understandable and easy manner?
  • The terms “encryption” and “pseudonymisation” (aka tokenisation) are specifically mentioned several times so I’d venture to say that encryption will be an important section of the taken measures. We’ll possibly see this once the basics are in place. It’s not as easy as it sounds because it’s important to take into account that encrypting data can reduce its utility: for example, one cannot sort, search, report or analyse encrypted data, at least with the generally-available technology in our hands.

Essentially, you’ll want to have some structure in place so that in the case of an audit, you can prove that you’ve made efforts in clients’ best interests to prevent misuse of their information.

2.- Right to Access Information

This is just an extension of our actual practices. Until now (and on request), we had to give our customers the identity of any data processors or data storage and the specific use we were going to give to their personal information.

However, now we’ll have to get more into the nitty gritty of things by providing (on request) the following mandatory information:

  • The identity of the controller and representatives (i.e. Amazon + John Smith + an address)
  • The recipients or “category of recipients” to whom we’ll be disclosing our client’s data .(i.e. “ Higher Education Centres in London”)
  • The purpose of the processing & the purpose for the specific use of their data (i.e. “AWS will be processing, storing and serving as a general repository of lists of Candidates for Marketing Communications related to post grad courses.”)
  • The time period which you might keep it or if unknown, the criteria used by the controller to determine such period.

All pretty reasonable. This needs to be in all relevant legal notifications, contracts, website’s privacy policy etc.

3.- Consent

An important point on the new regulation. Consent or conformity is not new but rather reinforced. It will need to be explicit and unambiguous. A passive, silent or omissive act will not be valid as consent.

A “By navigating this site you agree with…” is a thing of the past. In the same way, I would not recommend those pre-checked checkboxes on forms either.

Remember that if your app or service is dealing with a minor’s data, it gets a bit more complicated, since the minimum official age of consent is 16; however, each country can tweak this slightly, as long as it’s not below 13. (For us in Spain is presently set at 14 years old.) Anything below this threshold should have the consent of parents or legal guardians.

4.- Transparency

Here’s something emphasised at -almost- every Article. The best practice here is a no-brainer: Easily understandable and accessible access for all our policies.

Everything starts with intelligible terms and conditions that can actually be found on our website, -maybe in the small print at your home page?- contracts etc.

We must give our clients the chance to exercise their rights, such as the right to access, modify, delete or challenge any of their personal information, but also through exercising their right to complain, in line with the well known “right to be forgotten.”

Let’s not forget the auditing practices included on the GDPR (Article 30), where we must record the processing of this data and keep it up to date in order to make it “available to the supervisory authority on request.”

5.- Security

Always a tricky one. Hacker’s gonna hack right?

Sometimes our monetisation strategy might be based on data. We walk on a thin rope between having enough data to be able to make money with it and having too much data, which makes us a bigger target for criminals.

The 2015 Ashley Madison hack resulted in numerous cases of blackmail, extortions, lost relationships, loss of jobs, and even in several cases, loss of life (by suicide).

While in my opinion there is no system that can’t be penetrated, with the new GDPR we have to make sure that we take “appropriate actions”. (Whatever that means, legally.) So until a court sets legal precedent, “appropriate actions”. That’s all.

Same basics could be:

  • Establishing secure access to the company’s backend, CRM or database.
  • Establishing adequate backup procedures, guaranteeing the security of these backups.
  • “Taking appropriate measures” to avoid data leaks, installation of ransomware, malware or any other associated risks occurring, such as attacks by crackers, DoS etc.

As a matter of fact, with this new GDPR we will be obliged to have a Data Protection Officer when: (Article 37)

- “the processing is carried out by a public authority or body, except for courts acting in their judicial capacity”;

- “the core activities of the controller or the processor consist of processing operations which, by virtue of their nature, their scope and/or their purposes, require regular and systematic monitoring of data subjects on a large scale”;

or

- “the core activities of the controller or the processor consist of processing on a large scale of special categories of data pursuant to Article 9 and personal data relating to criminal convictions and offences referred to in Article 10.”

But hey! Things get hacked. And always will.Notice I said things, as in “Internet of Things”? Just a thought.

When they do get hacked, Article 83 of the GDPR contains a list of aggravating or mitigating factors. You should check that out.

If Hacked, early detection and rapid responses are very important mitigating factors. Report any type of incidents to the authorities and affected users ASAP when their privacy or personal data is at risk.

When dealing with Data Transfers, (Articles 44 to 51) particularly to third countries beyond the EU, an extraterritoriality clause extends the scope of any personal data, irrespective of the location or its processing. (a.k.a. “GDPR still applies”.) Most importantly, it introduces the concept of Shared Liability where data controllers and data processors are subject to the same penalties and sanctions.

Conclusions

  • As owners of any business we’re both data controllers and consumers with personal information. The GDPR is here to help us all.
  • Big companies may have to go through “Change Management” where it’ll horizontally affect multiple departments and roles. Some will have to create the role/roles of Data Protection Officer; let’s count ourselves as lucky if we don’t, but truth be told, some measures needed to be taken.
  • These measures are not really defined, so the obvious applies, we need to rethink our processes, improve where we can and be ready for a possible audit.

For specific steps to be taken, especially if you use Salesforce, I recommend SalesforceBen and the Drip’s series of posts on GDPR.