The General Data Protection Regulation (“GDPR”) takes effect in less than two months and will give significantly more control to EU citizens and residents over their personal data. It will also simplify and unify data regulations within the EU, and tighten restrictions around how businesses collect, process, store, and share personal data online.
The team here at Codility is happy to share some of the things we’re doing to get ready. After all, our headquarters is based 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.
Read on to see our ownGDPR readiness checlist to ensure GDPR compliance.
Our Core Objectives
First and foremost, Codility’s primary goal is to be GDPR-compliant by May 25, 2018. To do this we need to:
1) Store our data in the EU
Our data is currently stored with Amazon Web Services (“AWS”) in Northern Virginia and we will switch to storing 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. In addition to AWS, we use EEA-based Hetzner and Rackspace as secondary hosting providers for support tasks and backups. Both are strongly encrypted for maximum security.
2) Ensure compliance at every step
We will 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. For instance, we’ll need IP addresses to investigate technical difficulties to resolve connection problems.
3) Be able to erase data effectively
A major part of GDPR is that it gives more ownership to EU citizens over their personal data, including the right to have their data “be forgotten” by companies. At Codility, we want to ensure our clients are easily able to handle these requests from candidates, but also don’t want to lose out on analytical capabilities.
Through our product, we capture candidate personal data as well as candidates’ coding test scores. We don’t necessarily need the personal information, so we will separate this from test scores so we can continue to capture score statistics in order to deliver a better product and screen technical skills more accurately. This way we can also draw better developer insights to provide more value to our customers without breaching GDPR terms.
Our Methods and Procedures
Below are our key focuses to meet our GDPR readiness checklist objectives:
1) Infrastructure (where we store data and for how long)
Currently we only delete data from our live database on request. We’re currently in the process of changing our backup strategy to be able to 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.
Additionally, we can 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.
2) Messaging (keeping users informed of their rights)
3) Procedures (have formal procedures in case of requests)
We will create written procedures to form a playbook in the case of:
- Requests for information
- Requests for erasure
- What to do in case of a data breach
- Any other requests pertaining to individual rights
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 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.
At Codility, we’re committed to helping hiring teams carry out their tech recruiting efficiently, effectively, and compliantly. On that note, we will hire a Data Protection Officer (“DPO”), even though hiring a DPO is mainly a priority for larger enterprises. We want our clients to feel that they’re in good hands, and we believe hiring a DPO to diligently ensure we are compliant and that we’re empowering our customers to be compliant too is crucial for our business success.