Only a few months remain until the European Union’s General Data Protection Regulation (“GDPR”) starts being enforced. Many organizations have May 25, 2018 circled in red ink on their calendars and have a concrete plan in place to become GDPR-compliant. Not being GDPR-compliant by this date could cost you up to 4% of your global annual revenue.
The primary objective of GDPR is to give more control to EU citizens and residents over their personal data and to simplify and unify data regulations within the EU. The implications for organizations that collect, process, store, and share personal data online for people in the EU are massive.
If you’re looking for good summary of GDPR, check out this quick guide.
In terms of the personal data your company handles and stores, here are the four main things you need to think about:
If you already have answers to these questions and processes in place to address them, you’re off to a good start.
But how can you further prepare for GDPR?
The team here at Codility is happy to share some of the things we’re doing to get ready. After all, one of our offices is located in Warsaw, Poland, so a significant percentage of our customers are located in the EU. But it’s important to note that many of our non-EU based customers collect, process, store, and share personal data for people in the EU too.
Our clients use the Codility tech hiring platform to identify the strongest programmers in their pipeline, so they can invest in the most promising candidates and advance them through their recruiting process. The implications? Hiring teams we work with want to know how we collect and handle their candidate data.
How businesses prepare themselves ultimately depends on their specific business needs and processes, and what their customers value the most. Organizations will find the most success if they partner with their customers on how to approach GDPR-compliance.
Let’s review some GDPR terminology in the scope of HR Technology companies and their customers:
Data Controller = The company doing the hiring
The company doing the recruiting is the data controller because they decide the purposes for collecting candidate data and how they collect it.
Data Processor = Codility, and all other software vendors used in the hiring process
HR Tech companies process data on behalf of their customers, making them a data processor.
Here’s an example of this in action: After GDPR hits, hiring companies are responsible for deleting candidate data and reacting to requests regarding data. And as HR Tech vendors, we need to make sure we can delete it for them, and react quickly and appropriately to other requests. If an EU-based candidate messages a hiring team they’ve been communicating with that they want some or all of their data erased, that hiring team will rely on its vendors to delete that information.
What can be helpful is listing out all the pieces of information your customers will care about. These are the most important personally identifiable information that we collect about candidates on behalf of our customers:
Another consideration many companies have is whether to hire a Data Protection Officer (“DPO”). Even though hiring a DPO is mainly a priority for larger enterprises than Codility, we still plan to add one to our ranks. Codility processes significant amounts of person data—we’re talking thousands of candidates every month. We want our clients to feel like they’re in good hands, and our having a DPO, whose main responsibility is to ensure compliance with data laws, further backs up our statement that we’re committed to delivering premium products and services for companies looking to bolster their tech hiring. Hiring a DPO is a great way to turn GDPR from a daunting challenge into an opportunity to differentiate your offering.
Read on to see our own plan and more thoughts.
First and foremost, Codility’s primary goal is to be GDPR-compliant by May 25, 2018. To do this we need to:
Currently our data is stored with Amazon Web Services (“AWS”) in Northern Virginia, but we’d like to store it in the EU (possibly with AWS in Frankfurt) instead. We actually aren’t required to make this switch thanks to the AWS Data Processing Agreement, but it will make things easier and simpler for our customers, and will eliminate any questions about whether our data operations are compliant.
If you don’t use a service like AWS that has this special exemption from GDPR, you should move to EU-based servers. In some cases it might make more sense to keep some data in the US and only move the data you need to move to the EU, especially if you want lower latency for US customers. But this will pose problems if breaking down your storage strategy requires big architectural changes. Do your due diligence with your current vendor to see if you’re exempt or if you should consider switching.
We’ll need to ensure the right legal reason is documented in every case and make sure we keep data for only as long as we have a documented reason to do so. Our focus is to make sure we always have a lawful basis to collect, process, store, and share personal data on behalf of our customers. In some cases we’ll need to hold on to candidate data in case we need to recover it from a backup. We also need IP addresses to investigate technical difficulties to resolve connection problems.
Where should you start? Start with an information audit. Do a deep dive into what kinds of information you have, how it’s collected, and where it ends up. Then you can determine how long it’s used and how long it’s stored. You might find you’re collecting certain information without having a good reason to do so.
A major part of GDPR is that it gives more ownership to EU citizens over their personal data. It’s a good idea to separate out your data instead of storing everything together to prevent losing out on analytical capabilities.
For instance, at Codility we capture candidate personal data as well as candidates’ coding test scores. We don’t necessarily need the personal information, so if we can separate this from test scores, we’ll continue to capture great data and draw better developer insights. We’ll be able to provide more value to our customers without breaching GDPR terms.
Below are our key focuses to meet our GDPR objectives:
Currently we store all of our data forever and we delete data from our live database on request. We have a lot of backups, which are basically snapshots of our database. This makes it difficult to delete specific pieces of information, like information pertaining to a specific individual. We’re currently in the process of changing our backup strategy—one thing we might do is compartmentalize our data backups or only backup certain data, making it easier to parse out what we need to delete and what we need to keep.
Another option is to create a feature for our users to manage their own data, like providing a “delete” button for a single test submission. This is dangerous though because there won’t be an undo option. The data won’t be recoverable because the entire point is to not archive the data to comply with GDPR. It’s important to sufficiently warn users of the consequences their actions will have in these cases.
We will create written procedures to form a playbook in the case of:
If a customer requests to delete some data we need to make sure we know who on our team does what and when in this situation. Automation could help a lot here, but for now we’ve nailed down roles and responsibilities.
First, we’ll need to designate which contacts in a client company are allowed to request data deletion. We can restrict this based on permission levels within our product or by point of contact on the customer success side of things. A customer will likely reach out to their dedicated relationship manager or our customer support team. We’ll then get our tech team to run scripts to delete the data.
Organizations that touch personal data of citizens and residents in the EU need to know the in’s and out’s of GDPR. Thinking long-term, GDPR might only be the start of an increasing trend of data compliance laws. There’s no telling if GDPR will add requirements in the EU or if a similar regulation will make its way outside the EU. This only means it’s critically important to get compliant now. And with proper preparation and process, you can make the most of the situation and turn GDPR into a competitive advantage.
Looking for more insights? Check out the rest of our blog below!
© 2009–2016 Codility Ltd., registered in England and Wales (No. 7048726). VAT ID GB981191408. Registered office: 107 Cheapside, London EC2V 6DN