The General Data Protection Regulation (GDPR) is the European Union’s (EU) new law to protect its residents’ personal data. This regulation primarily governs how legal entities (i.e. companies) may (or may not) handle data about natural persons (that is, living humans and their respective primary identity). It doesn’t say anything about personal data collected by natural persons for their own personal use (i.e. your rolodex).
This law is largely derived from Germany’s own data privacy regulations that has been around just after around the time the Berlin Wall came down — but extended to include the opinions of all EU member nations. It now becomes a “one stop shop” standard that governs handling of EU residents’ personal data. Another big change besides unification is the potential penalties imposed should a breach occur and which parties that may be held responsible.
Previously personal data breaches carries a maximum penalty of of “only” several hundred thousand euros — a small risk for billion-euro companies. However the GDPR now poses a penalty of up to 4% of the corporation’s global turnover. The penalty is also to be enforced on a per-case basis, not a blanket of similar cases. Hence it potentially only takes 25 personal data breaches to close down a billion-dollar company.
The regulation introduces the concept of “Data Controller” versus “Data Processor”, the roles that they play in handling personal data and how the regulation would hold each role responsible for a breach. A “data controller” is the starting point-of-contact with the natural person and is the entity ultimately responsible on how the personal data gets used. Whereas a “data processor” are entities that only processes data as according to the instruction of the data controller.
In the event of a personal data breach (or misuse), the data controller is ultimately held responsible and legally liable for the event. However the data controller may pass down the blame to its data processors — and any data sub-processors down the chain — for their respective parts of the responsibility. Hence in the event of litigation for a data privacy breach, the data controller may sue its data processor and collect sanctions for their part of the breach. Similarly a data processor may do the same thing for its own sub-processors until no more sub-processors can prove innocence.
Yes, the “guilty by default” rule is also somewhat new and maybe counter-intuitive with respect to modern-time regulations. In the event of a litigation of a data privacy issue, the court would assume that the company is guilty by default — unless it can demonstrate that all “technical and organizational measures” are already in place to prevent the issue from happening. It puts the burden of complying to the company and not the individual (presumably victim) to prove that the company is guilty.
Let’s say that you are working for Ideovu, Pte Ltd, a fictitious company. It is Software-as-a-Service (SaaS) company incorporated in South-east Asia offering a number of web applications to individuals and small businesses. Almost all of the company’s offerings are 12-factor web apps deployed on a landscape operated by My Hero Inc, which is a Platform-as-a-Service (PaaS) company which services and monitors these kinds of applications on a day-to-day basis. This PaaS provides system services such as the operating system, database, network routing, and various low-level services that Ideovu has no interest in doing or maintaining the in-house skillset to up-keep these. In turn, My Hero Inc leases servers, bandwidth, along with the staff to support these from Borneo Web Services Corporation — which is an Infrastructure-as-a-Service (IaaS) company. The latter manages data centers, physical security, connectivity, and actual racks containing servers. Similarly, Borneo Web Services may engage several local property companies to lease warehouses, local telecommunications operators to ensure bandwidth, and a number of computer hardware companies to provide it with servers. Note that this arrangement is a typical “business stack” for a typical SaaS company.
Now Erika Mustermann, a natural person of EU residence, signs up for one of Ideovu’s web application. She gives her name, e-mail address, and credit card number in the process. In this situation, Ideovu is a “data controller” because it is the entity that directs processing of Erika’s personal data. Both My Hero Inc and Borneo Web Services Corporation — as well as any vendor of them — are “data processors” since they are there only to process Erika’s data as per Ideovu’s instruction (or technically as instructed by the logic in Ideovu’s web application).
There is no escaping from the GDPR unless the company do not want business with any EU nationals. Even though none of the companies in the chain are incorporated in the EU, the GDPR applies since Erika Mustermann is an EU resident. Sure, those companies’ legal residence may be beyond EU’s reach, but the union can definitely embargo any non-complying entities from ever doing business with EU.
What should you do
In most cases, simply don’t process personal data — unless you have legal ground to do so. Moreover you must not repurpose personal data beyond the original consent as obtained from the respective natural persons. People may change their mind and thus revoke their consent. Hence you need to provide a way for them to do just this — revoking consent and have their data excluded from further processing. Likewise you need to protect any personal data that you process — and have layered protection as according to how sensitive the nature of each data item.
For example, Erika Mustermann signed up to your web application and gave your company her name and e-mail address. This gives your company a legal ground to process her data for the purpose of enabling her to use your web app. Examples of such purposes may include sending a password reset e-mail or sending her a summary of new features of the web application that she subscribes to. However this does not give you the right to package her contact information into a bundle that you re-sell to third party e-mail marketing companies. Nor it gives you the right to send marketing information about third-party services unrelated to your company’s web application that she is currently using.
Erika Mustermann also discloses her credit card number to your company when she on-boarded. The legal ground (and implied consent) is to enable her to pay your company for the web app that she is using. Hence you can use this information to bill her for the services that your company render (and she has agreed beforehand to pay). However, being a financial information (and thus sensitive personal data), you are obliged to provide additional protection to this data — higher than the level of protection to her e-mail address.
You also need to provide a way to report to Erika what you know about her. For a SaaS can be as simple as a “my account” screen showing name, e-mail address, service plan and the last four digits of the credit card number that she uses for payment. But this can also be as complicated as an “account dump” option that pulls out just about any interaction that she had with your system.
Then there is revoking consent. For a web application, typically this is a “close account” option. Should Erika deletes her account, you would need to remove all data that you have about her since you no longer have her consent. For example, clear out her name, e-mail address, and credit card number from the customer file. Nonetheless you might still be able to keep her customer number since you likely still need it for revenue-reporting (hence tax-related) purposes. This is yet another reason why you shouldn’t expose internal identifiers to the outside world. Showing the her customer ID number that is also a database record identifier in invoices and others would inadvertently link that internal identifier to the outside world. This would cause problems when you need to remove the person’s data but still keep the ID number.
Lastly you need to have both read and write logging to any personal data that you process. That is, whenever one of your employee (or contractors) pulls up a customer file, there need to be a record that keeps note who saw what data and at what time. This is even more important when the data items are sensitive — such as financial information, health data, sexual preference, religion, racial background, etch.
Having proper procedure would defend your company in the event of a data breach. With proper policies and corresponding logging in place, you can correctly say that the breach was done “not in accordance to the company’s standard processes and regulations”. However if you can’t prove that adequate measures are already in place then the courts would likely assume that your company is guilty by neglecting to have proper data protection measures.
Where to find more information
The official GDPR text is available in English and various EU languages. There is also a third-party website that parses the legal text into smaller chunks that are easier to navigate. The EU also provides Handbook on European Data Protection Law — a free e-book (and also available in print version from their bookshop) that summarizes the legalese into something that is easier for non-lawyers to understand.
That’s all for now. Until next time.