You’re working diligently to ensure that your organization is GDPR compliant by May 25. Are your third-party vendors making the same effort?
Under the EU’s General Data Protection Regulation (GDPR), subject companies are responsible for the readiness and conduct of third-party vendors that store or process EU customers’ personal information. You might be taking all the proper precautions internally, but if one of your vendors’ practices fail to comply, your organization could be on the hook for some significant fines.
Don’t let your vendors be the weak link in your compliance chain. Confirm that their data-management practices comply with the GDPR’s specifications.
Fortunately, the regulation provides guiding criteria, three of which we’ll address in this post: data mapping, data minimisation, and pseudonymisation.
Do they have a clear, useable map of their data?
First and foremost, it’s imperative that an organization perform a privacy impact assessment (PIA), to get a clear picture of what personally identifiable data is collected, and how it is used, shared, and maintained. For the purposes of GDPR compliance, it is important that a business is able to identify the types of data it holds, where it’s held, for how long, and for what purposes; because if you don’t have a clear map it’s impossible to get to your destination.
The PIA should guide decisions about what data needs to be pseudonymised (more on that later), appropriate retention periods and help ensure individuals privacy rights are upheld.
In the event that a data subject chooses to exercise their "Data Subject Rights" under GDPR, you'd need to know where their data were stored, and provide access within one month of receiving their request. As data subjects become aware of their rights and that they may have a case for compensation for the impediment of those rights, it’s even more important to have all those data mapped out precisely.
What’s more, in the event of a data breach or loss, a data map will help the organization to determine exactly where breached data were being stored and processed, and to assess the extent of the breach.
Are they minimising the data they collect?
Compliant organizations will only collect that data which is necessary for the intended purpose. If you don’t require a piece of your users’ data to perform a function, then there’s no reason for you to collect it.
We at iovation applaud this requirement. Solutions that rely on users’ directly identifying personal data are inherently less secure. The dark web has been flooded with stolen credentials. Cybercriminals can buy this information for a pittance.
In fact, we believe that data minimisation will bring a relief of sorts. The less personal data you collect, the less that must be secured. And besides, even if a fraudster provided personally identifying data, who would believe them?
So, how much of your users’ data are your third-party vendors ‘collecting first and protecting second’? Will they be able to change their collection processes by the time the GDPR is enforced? If they can manage a change, will it be a ‘bolted on,’ or ‘baked in?’
That’s an important distinction. The GDPR encourages the inclusion of privacy as a fundamental consideration of an organization’s operations, not as the exclusive purview of an assigned department. That requires a core change to operations, a far cry from ‘bolting on’ a layer of privacy considerations just before shipping, say, a fraud-prevention solution.
Are they pseudonymising the data they collect?
The GDPR defines pseudonymisation as “the processing of personal data in such a way that the data can no longer be attributed to a specific data subject without the use of additional information.” Think of it as a concession to Data Controllers for the regulation’s additional obligations.
For the data you must collect – that is, data you can’t minimise – pseudonymisation reduces the security risk. If an attacker were to acquire pseudonymised data, they wouldn’t be able to do anything harmful with it.
For that reason, Article 33 of the GDPR exempts Data Controllers from having to give notification of a breach of pseudonymised data; it’s “unlikely” to create risk. What’s more, Article 11 relaxes certain data subject rights for pseudonymised data. This gives businesses some leeway in dealing with the anticipated increase in the enforcement of Subject Access Rights.
With that in mind, ask your vendors whether they’ve updated their processes. For some, this might represent the smallest of changes from their current operations. For others, this might be an insurmountable hurdle in their development roadmap.
While there’s still time, you want to know where your vendors stand.
OK, enough discussion of what could go wrong with your GDPR compliance. Let’s talk about the upside! Join us on March 20, when we’ll explore the GDPR as an opportunity to create competitive advantage.