GDPR Is Here – What Does It Mean To You?
The General Data Protection Regulation (GDPR) applies to any business storing personal data on EU citizens. If you’re outside of Europe, you probably haven’t heard of the rules and potentially massive penalties. In this post, I will summarize GDPR and what it means to you.
The last time that the European Union attempted to protect personal data was in 1995 with the Data Protection Directive. This set of guidelines instructed EU member states on how to protect personal data … based on how things were in 1995. There was no cloud, no Facebook, and the Internet was still toddling around college campuses and a few corporations. Things have changed, the nature of personally identifiable information (PII) has changed, and how that data is stored, shared, and easily transmitted around the world has completely changed.
The EU has updated its data protection with a new regulation (more rigid than a directive) called the General Data Protection Regulation, or GDPR. The GDPR document is quite a beast to read and understand. It is 11 chapters with 99 articles. Each article documents scope, protection, requirements, and penalties. More often than not, the articles cross-reference each other, requiring the reader to have many tabs open to fully understand an individual article. But worst of all, GDPR is often subjective and open to interpretation, leading to many “experts” having opposing opinions on how it should be implemented.
However, one thing is true. GDPR must be implemented and not just in the European Union.
There is lots of terminology in the document but there are a few important ones to know:
- Data Subject: This is a natural person (not a corporation) that can be identified from personal data.
- Personal Data: This is data that can be used to identify a data subject, such as name, address, phone number, IP address, MAC address, sexuality, race, culture, genetic, physical/mental, or social identity data. This isn’t an exhaustive list! This data can be physical or digitally stored.
- Processor: This is a person, business, agency, or any entity that processes personal data.
- Controller: A controller is a person, business, agency, or any entity that determines the means for collecting and processing data, directing processors on its behalf.
Chapter 1 – Article 3 of GDPR defines the scope of enforcement of the EU’s new data protection law and this scope is not limited to the EU. In short, if you store data on EU citizens, the law and punishments apply to you. For example:
- You have a US-based company with employees in the EU. Any data you store on those employees is subject to GDPR.
- You run a marketing company out of Asia with a database including PII on EU citizens. GDPR applies to you.
- You run a hotel chain in Canada and are storing data on customers from the EU. Guess what? GDPR applies to you too!
Be careful because that data might not be immediately obvious. It could be in a scanner (passports scanned at a hotel), in a credit card payment device or shop till, scattered all over file shares in Word/Excel documents, or distributed in many mail server databases.
Some processing is exempted from GDPR. This is mostly EU government processing. But some EU member states have exempted their own state agencies from GDPR too.
Collection of Data
A Controller may only collection/store data with the provable consent of the data subject. A trend in GDPR is that the burden of proof is always on the Controller. The Controller must design practices around the concepts of consent and data protection. When asking for consent, the Controller must clearly explain, in terms that a child could understand, why the data is being asked for, what data is being asked for, how it will be used, and how long it will be retained for. The data can only be used for the agreed purpose(s) and must be deleted once it is no longer required.
There are some exemptions to deletion, including:
- Use for legal defense/claim
- Public discourse
- A legal requirement by the Collector to retain the data
Right to Search
A Data Subject has the right to ask what PII is stored about them – at no charge. The Controller must respond in 1 month with a human-readable set of data, or inform the requestor that there is no data. In the case of an exceptionally complex request, the Controller can inform the Data Subject that an additional 2 months are required. However, the Controller must be able to prove the exceptionality of the case.
There is no right to charge the requestor unless the Controller can prove that it is a nuisance request. In this case, they can charge a reasonable processing free. Alternatively, they can refuse the request, but remember that the burden of proof is on the Controller.
Searching data is going to be a challenge. Cloud services such as Office 365 and Azure either have or are adding search tools to deal with GDPR’s requirements. But what about all the data that is scattered across DropBox, file shares, Exchange databases, Oracle, SQL Server, and so on? Finding what you have and where it is will be a monumental challenge and so will creating a centralized index of all identified PII. To be frank, I think this will require specialist third-party tools, which will add complexity to storing data on EU citizens.
Right to be Forgotten
Once a Data Subject has verified that a Controller is storing PII on them, the Data Subject can request that the PII is deleted. This is subject to the previously mentioned deletion exemptions.
Are you truly in a position to say that you can delete all data on a person? Indexing, searching, and finding that data is tough. But have you thought about the data that resides in your backups or offline data archives? Can you delete that data?
This is one of the many situations where the current state of technology and the law are incompatible. You’ll have to make an effort if GDPR applies to you and that might be choosing vendors/solutions that are forward-thinking and that use modern technologies that can be updated with a searchable index and an ability to selectively delete search results.
The guidance on how to secure PII against breaches is as follows (Chapter 4 – Article 32):
… the controller and the processor shall implement appropriate technical and organisational measures to ensure a level of security appropriate to the risk.
If you lined up 10 IT pros and asked them what were appropriate technical measures, you would get 10 different answers. And what are appropriate risks? I might put in lots of systems today, but in 2 weeks’ time a new breach might hit my network and a security consultant will likely claim that I didn’t assess my risks appropriately.
Article 32 does give some examples of protections but they are not a definitive list of “this is all you must do”:
- Pseudo-anonymization of data subjects and encryption of personal data. Have a look at Azure Information Protection, SQL data masking, TDE, and Always Encrypted.
- Continuous auditing, assessment, and improvement of security measures to keep up with changing threats. Maybe consider tools such as Azure Security Center for on-premises/cloud assessment of your security.
- An ability to restore data from backup (small-scale technical/human issues) or disasters (failover to another location) in a timely manner.
- Regular testing and evaluation of the above measures. Test restores are critical. Choose a backup vendor that can automate the tests and email you the results. Bring in good security consultants who didn’t just download a checklist.
My advice is to think beyond classic firewalls and AV protections of 2003. It’s time to get real about security modernization, including advanced threat protection (ATP) for firewalls, email, patching, configuration enforcement, data loss prevention, security at the data/file layer instead of just the disk, and multi-factor authentication (MFA) to secure the most at risk company asset … the username and passwords of your employees.
If the plethora of quarterly and annual security reports can confirm anything, it’s that data breaches happen all of the time. It doesn’t have to be the scale of a supermarket chain appearing on prime-time news; it could be a crypto-ware attack on a small business.
It is the duty of the Controller to report a breach to the local data protection commission of the EU member state within 72 hours of discovery. This is to avoid another Yahoo where it took 2 years for the company to reveal to customers/users that they were compromised.
If your company does not have a physical presence in the EU, then you must have an agent to represent your company in the EU to make these notifications (Chapter 4- Article 27).
Complaints and Penalties
There are some subtle changes to how the complains process is being handled that might have a significant impact on the enforcement of GDPR versus how data protection commissioners handled the old Data Protection Directive. One example is Facebook, which hosts its EU services in Ireland, making the Irish Data Protection Commissioner the local “enforcer”. Many jokes have been made about this commission because the office is above the Irish equivalent of a 7-11. Its enforcement seems to mirror the first impressions. One might claim that they are a soft touch for the big cloud operators like Microsoft, Amazon, Google, and Facebook. This is possibly true because of the tax inputs to the Irish economy but those might be unfounded claims. GDPR Article 77 states that a person can lodge a complaint with their local commissioner solving two issues:
- Data being hosted in a non-EU country
- Bypassing a foreign commission that might have a bias in favor of the Controller
Article 79 allows a complainant to take their case to the courts in their local country to seek legal remedy against breaches of the law.
Article 82 allows for compensation in the event of a Controller and/or Processor being found responsible for breaches of the GDPR law. It should be noted that a Controller/Processor can make claims against service providers (other Processors) that were found to be at fault. This means that if you use an external processor (a service provider) to process PII and they are to blame for your violation, you can seek remedy from them via the courts.
If a member state’s commission or it’s GDPR inspectors find your organization to be at fault, then they can levy very heavy penalties. These are designed to be deterrents against directors adopting the same lazy approaches to IT security and data protection. It will be cheaper to be compliant than to pay the penalties.
Less severe offenses can lead to a fine of up to €10 million (approximately $1.17 million USD) or up to 2 percent of global annual turnover, whichever is higher. More severe offenses can result in a fine of €20 million (approximately $23.41 million USD) or up to 4 percet of global annual turnover.
I was recently asked how the EU would enforce such payments against a non-EU company – ask Microsoft or Google. If the company has a presence in the EU then the fine is easy to enforce. If the company doesn’t have a presence in the EU, then I would advise the directors not to take a European vacation if they refuse to sign the check.
If you store PII on EU citizens, then you have no choice; you must be compliant with GDPR. And yes; this applies to organizations outside of the EU, such as in the USA.
I don’t believe that any organization can be fully compliant with GDPR today. For example, you must be able to backup PII. However, you must also be able to delete data from those backups (which is impossible today) upon request if the data is not exempted from the right to be forgotten.
The most important thing you can do today is to engage a GDPR expert and get their advice. Find out if this law applies to you (it is pretty clear). And then start the process. Assign your data protection office role(s), identify your controllers, and audit your data to find PII. Starting the process, even if you are late, will be much better in the eyes of enforcement than ignoring it. GDPR is mostly about an attitude adjustment for board members and for staff that manage data and security. Once you know what you have, you can begin work on privacy statements and consent forms. And then comes the hard work – implementing better processes, designing security, and privacy into existing systems and new ones.
If today is the first time that you have heard of GDPR, then don’t get too stressed. I believe that most businesses in Europe still haven’t begun the journey or aren’t that far along. Inspectors will hopefully be looking for the effort to begin with because anyone with a connection to reality will understand that the shifts and changes that are required will either take time or are impossible today.