The deadline for GDPR coming into effect is just around the corner. With that in mind, we’d like to formally introduce our Compliance Manager and Data Protection Officer, Mark Weston. Mark has over a decade of experience with compliance, and is part of iovation’s UK contingent calling Chorley, Lancashire home. Mark is coming up on his year anniversary with iovation and in that time he has been working tirelessly to ensure iovation is compliant with GDPR on day one. He was largely responsible for driving iovation’s certification with the EU/US Privacy Shield program and will be sharing his knowledge over the coming months to assist our customers in achieving GDPR compliance as well. To that end, I’ve conducted a short interview with Mark to kick things off.
GDPR: What is it?
GDPR stands for General Data Protection Regulation and replaces the current EU Data Privacy Directive of 1995. The old directive was essentially a set of commands that were the backbone of a law that all members of the European Union, and its predecessor, the European Community, were required to implement as their own law at a national level. The resultant outcome of this was a patchwork of 28 laws that were written at a time when the internet was in its infancy and smart devices and social networking were some way from being as commonplace as they are today. Essentially, the current law is out of date.
Added to this was the EU's desire to create a single "digital economy." Being a political union of 28 different nation states with their own legal systems posed something of a challenge to this wish. The EU consists of about half a billion people and it is still the world's biggest internal marketplace. As such, a new law was required that would enable individuals from Ireland to Romania, Finland to Malta to operate within a unified set of rules.
It will also have effect in the three countries outside the EU that, together with the EU countries, form the European Economic Area (EEA). They are Iceland, Norway, and Liechtenstein.
Is this something businesses outside of Europe need to be concerned with?
In short, yes! GDPR doesn't just affect the EU or the EEA, it affects:
- Anyone processing personal data within the EU or EEA
- Anyone offering goods or services to citizens in the EU/EEA, whether they are within the EU/EEA or not, also will fall under the rules set by GDPR. Additionally, anyone monitoring the behaviour of persons within the EU/EEA will also fall in scope.
- In a globalised economy, it's actually foreseeable that many organizations outside of the EU/EEA will find themselves under GDPR’s remit.
It's also important to keep in mind, for those businesses within Europe who use third-party service providers based outside of the EU/EEA, you need to consider whether these vendors understand the obligations that they will “inherit” under GDPR on behalf of European businesses? Do the contracts you hold with them reflect this? Do the terms contained within the contract align themselves with their responsibilities? Can they continue to provide this service to you without breaking the law?
What are the potential penalties under GDPR?
The penalties under GDPR are pretty sizable. For example:
- Infringements of a Data Controller's obligation to ensure that it honours requirements—such as enforcing children's online consent rules, general obligations as a Data Controller, ensuring that Privacy Impact Assessments are carried out, and maintenance of adequate security—will see fines of €10M or 2% of global turnover (whichever is greater) levied against the errant Data Controller.
- Infringements of a Data Controllers obligation to ensure that it honours requirements as basic principles around the legalities of processing—including acquiring consent, upholding the rights of Data Subjects in the EU, or transferring personal data outside the of the EU/EEA without adequate safeguards being in place—can bring fines of up to €20M or 4% of global turnover.
Whilst these penalties are eye-wateringly large, EU Data Privacy Regulators have moved to reassure Data Controllers that there is no desire to "wield the big stick" as they would sooner use the "carrot" to ensure good information rights handling within businesses and organisations. But even though they may not intend to use that stick... it's a pretty big stick, and it’s very noticeable to anyone watching.
What are the requirements for breach reporting?
Breach reporting will become mandatory. At present, only some EU jurisdictions make breach reporting mandatory. It's not required in the UK, whereas in Germany, any breach should trigger the Data Controller to post an advertisement in two of Germany's biggest newspapers to alert potential victims that they may have been affected.
Under GDPR, breach reporting becomes mandatory. Not only is this requirement absolute (and failure to make a notification can bring a fine of up to €10M or 2% of global turnover), but it needs to take place within 72 hours. That's three days to understand:
- That a breach has occurred
- What data has been lost
- Who it has affected
- Whom to notify (regulator and individuals alike)
- And mitigate the breach
Therefore, it's important to understand what data assets a business holds, where they're held, what controls are in place to protect them, and what mitigation is available BEFORE such a breach occurs. And when said breach comes, how to react.
How can organizations minimize investigation risk around breach reporting?
Fortunately, mandatory breach reporting is not required where data has been effectively "pseudonymized." Pseudonymization is a new term brought about by GDPR. It's kind of a halfway house between data held in the clear ("Mark Weston") and data that has been anonymized ("X"). Both encryption and tokenization are forms of pseudonymization, and because the means to reverse the encryption or tokenization exists (the key), they're not fully anonymized.
As such, pseudonymized data needs to handled as personal data. However, if the key is not compromised, in the event of a breach, the likelihood of harm befalling a data subject would be incredibly slight and therefore reporting would not be required.
Does Brexit mean the Brits don’t have to worry about GDPR?
As many of you are undoubtedly aware, the UK has opted to leave its European brethren to seek its fortune amongst the other great trading nations of this world of ours. How will this dynamic play out when the UK "slips its European chains" and goes it alone?
Well not unlike the entire subject of Brexit, no one at this time actually knows what will happen. GDPR, will form part of UK law on the time and date the UK leaves the EU, and any processing that takes place concerning EU citizens that is carried out within the UK will, hopefully, be done under a determination of "adequacy" made by the EU about the UK. Whether this forms part of the UK's "Brexit Deal" or not remains to be seen. Although it seems likely that this will happen, unfortunately, at this time we really don’t know.
How can an organization get a clear picture of what data needs to be protected?
In the preceding section, I alluded to the importance of understanding the data assets that a business controls. Identifying these assets is carried out through a process called "Data Mapping."
Data Mapping differs from traditional IT architecture or infrastructure mapping, as this is not the subject of the project. Rather, in the case of Data Mapping, it is important that a business is able to identify what types of data it holds, where is holds that data, how long it holds that data and the purpose that it is using that data. Because in the event that an EU citizen (or for that matter, an American Werewolf living in London) chose to exercise their "Data Subject Rights" under GDPR, you'd need to know where their data was stored, because there's a predetermined, finite period during which an organisation would be required to enact that request.
Similarly, in the event of a data breach or loss, the organisation will need to know exactly where that data is being processed. Importantly, it's also imperative to understand whether you have the consent of the data subject, or if there are alternative “conditions” to the lawfulness of the processing. And where cookies are concerned, the overriding objective is to ensure that consent is in place for the placement and retrieval of those cookies, unless one of the narrow exceptions applies.
Will GDPR have any effect on iovation’s ability to stop fraud?
In short, no. Where iovation collects personal data for the purposes of its counter-fraud and authentication products, we rely on the legitimate interests condition of processing. Recital 47 specifically cites the processing of data for fraud prevention as an example of a legitimate interest.
Mark will be a regular contributor to our blog in coming months, so be sure to check back for future insights.
If you'd like a deeper dive on GDPR, check out our solution brief: GDPR by Design - Coalescing Privacy, Security and UX.
