When does the GDPR apply?

The GDPR applies when public or private organization process personal data. These assume one of two distinct roles, either as a data controllers and data processors. When discussing role distribution in supplier or customer relationships, we label one or the other as data controller or processor, respectively. However, one logically determines this at the level of a single processing activity.

The law is extremely clear about the territoriality, targeting and offering of goods and services. Thus, the GDPR applies to your non-EU company if: 

1. you establish a company or a subsidiary in the EU.
   No matter your product or service, your employees are people too and their data is protected by law. This places you under data controller obligations.
2. you provide goods and services (for a fee or not) to people in the EU.
   Since processing their personal data is a requirement to provide said goods and services, you are under data controller obligations.
3. you provide processing services (SaaS, PaaS) to a company to which the GDPR applies by virtue of the above points.
   The GDPR becomes applicable when handling personal data for a company established in the EU. In this case you likely assume data processor obligations.

Supplying services to end users

Beyond the letter of the law, your sales teams faces demanding questions from client procurement teams and end users alike. This is the case whether you offer B2B, B2B2C or B2C goods and services. Sales teams need to understand what procurement teams asked of them. At the very least, it communicates a sense of preparedness. In practice, they should only occasionally forward less obvious questions to the tech, product or legal teams.

Your internal or external data protection officer (DPO) or chief privacy officer (CPO) should sit comfortably astride legal and tech. If they do, have them train sales to reduce back and forth communication. These individuals see data processing from the technical perspective of data flows. Importantly, they understand risk from the perspective of risk to the data subject.

Leveraging privacy

Being able to address data subject requests (DSRs) in a timely manner, ensures you remain a contender in your client’s procurement shortlist. Some clients operate in a highly regulated field so compliance is crucial to them. Others show high ethical drive and understand non compliance as a risk to their operations. For clients who don’t care, your common relationship will deteriorate at the first privacy pinch from data subject requests. Pressure will come from their own vertical relationships in the supply chain, or enquiries by supervisory authorities.

If your business enjoys a direct relationship with people in the EU, you likely assume a data controller role. This is the case with the provision of B2C goods and services. The full requirements of transparency, security and accountability apply, so do the performance of data subject rights. Subjects are savvier now about exercising their rights. You can expect their privacy experience with you to make it onto social media if they don’t trust your practices.

Supplying services to other organizations

When supplying SaaS or PaaS solutions, the B2B / B2B2C scenario likely makes you a data processor. The requirements for security and accountability apply to both controllers and processors. Yet, transparency obligations are fulfilled by the data controller. This is done through their own channels or via a notice your platform allows them to provide to their end-users. However, your ability to be forthcoming with demonstrations immediately satisfy your customers’ expectation that you are set up to help them demonstrate how they comply.

Transparency is not the only obligation you will help your customer fulfil. Say you provide a platform that corporate customers can use to create user retail experiences. They remain responsible for collecting proof of consent to the data processing resulting from triggering your platform features (e.g. shopping cart memory or reward schemes). Your platform being the front-end of user interaction for your customers, ask yourself whether your platform

• provides your customers with consent collection mechanisms, collecting proof of consent and allowing for user revocation of consent;
• provides APIs to push data from your platform to your customer’s ERP, therefore triggering data transfers and access right management;
• helps generate records of processing activities that satisfy GDPR Article 30 requirements;
• helps generate a privacy notice based on the factual data processing caused by the user’s choice of features.

Engaging a non-compliant SaaS solution remains the data controller’s statutory responsibility. Yet remember that their DPO and legal counsels can be powerful show-stoppers when signing procurement contracts. No one appreciates manual work, much less when it involves getting it from the less responsive solutions providers out there.

Are employees people too?

You bet they are. Tunnel vision is frequent when focusing on exporting your product. Yet, when setting up a subsidiary to manage staff locally or remotely contracting staff in the EU, the data you process about them for employment and project management purposes is subject to regulation. Job boards and recruiting agencies allow you to tap into talent but the nature of the services you use may vary. Yet your obligations on the underlying data remain those of transparency, lawfulness and retention.

When onboarding and during the employment lifecycle, employees yield and generate tons of personal data. Some of that data may be highly sensitive, such as that associated with sick leave and disabilities. Remember that your HR systems may not be contracted in the EU and likely plug into other tools. That is often the case with payroll management, training and employee development. As you would expect, this tool landscape comes with additional challenges for complex organizations sharing services across multiple jurisdictions. Due diligence should take place before onboarding a tool and continuously while feature testing.

What about applicants?

No evidence suggests that merely looking at profiles on LinkedIn triggers GDPR obligations. The GDPR refers to that data as publicly available. However, the moment you make use of a third party tool or structure information, requirements are triggered. This customarily takes the form using spreadsheet trackers for driving applicants through a conversion funnel or sharing them for assessment. Not all applicant tracking software is created equal. Identifying a supplier based in the EU does not guarantee that its compliance is up to par. At the very least, you should expect them to know what compliance you need their solution to offer. 

Don’t take their word for it, challenge their assertions and document their response.

What does it take for non-EU companies to become compliant?

How is compliance defined and measured?

At its heart, compliance is about developing and maintaining the ability to demonstrate awareness of risk and risk control. Note that in data protection we do not measure risk in financial terms, nor in terms of corporate reputation. We see privacy risk through the lens of impact to the data subject. However, whether you rely on staff that is good at understanding ISO norms or legal officers good at interpreting legal provisions, your compliance essentially relies on whether your product owners understand:

• what data they need (data);
• what they are doing with it (purpose);
• to whom they have provided access to -e.g. through APIs- (recipients);
• where it comes from (source & confidentiality),
• how they legitimize its handling (legal basis), and
• what rights can be exercised against that data (DSRs).

This inventory is not established in a week. Not unless employees actually speak to one another and have nothing else on their plate. Needless to say, the inventory is never perfect. Worse, it is often erected on erroneous assumptions. For instance, ruling too quick on what is not personal data or failing to register the implementation of an API as triggering a processing activity. Have you ever had an awkward discussions with partner procurement teams?

For organizations making use of the ISO27001 security management cookbook. The 27701 extension is the cherry on top to help demonstrate, to customers and authorities, the organization is serious about compliance. Serious enough that it allows a third party to independently audit its compliance management system (ISMS and PIMS respectively). 

What do you need in order to demonstrate compliance?

You’ll need Records of Processing Activities (RoPA) to start with. That will put everyone on the same page; from your tech teams, to your legal teams, your product owners, your sales and procurement teams. It will allow you to update your privacy notices, enter (and exit!) sales discussions comfortably. You’ll need to review all your 3rd party contracts to identify where Data Processing Agreements (DPAs) and international transfer mechanisms are missing. You may also need to perform impact assessments based on whether your activity is blacklisted.

You might need to drop vendors with appalling documentation or those refusing to provide it. For instance, consent management platforms will lur your into thinking you don’t process personal data. If you are not willing to change suppliers, then maintain a list of vendors to deprecate for compliance issues and communicate it to upper management. You’ll need robust security documentation, and a fair share of training and awareness raising at all levels of the organization. Perhaps least discussed but most wanted on your compliance journey, is an organizational appetite for change management.

Much like that of ISO27001, whether your company is EU or non-EU-based, what helps you demonstrate GDPR compliance is the amount of available, relevant, readable, useful [and used !] documentation that demonstrate accountability. Compliance and product teams are already getting creative with MS copilot, allowing it to read through emails, repositories and spreadsheets. Are your ready to let an algorithm adjudicate on your company’s compliance and leave you none the wiser? AI is likely to become an audit support tool in first and second party audits. It is however unlikely to replace the auditor’s judgement and decisional independence any time soon for third party audits that rely on market-leading certification bodies.

The post Embracing the GDPR as a non-EU company appeared first on TechGDPR.

Stay up to date! Sign up to receive our fortnightly digest via email.

LLMs, data labelling and data protection

A fundamental principle of data protection law is data minimisation. Privacy International however insists that LLMs are being trained through indiscriminate data scraping and generally maximise their approach to data collection. Under data protection laws, individuals have the right to assert control over data related to them. However, LLMs are unable to adequately uphold these rights, as the information is held within the parameters of a model in addition to a more traditional form, such as a database. ‘Regurgitation’ can also lead to personal data being spat out by LLMs. Because training data is enmeshed in LLM algorithms, this can be extracted, (or regurgitated), by feeding in the right prompts. 

PI also investigated digital labour platforms that have arisen to supply data labelling for LLM training. This includes training an AI model against a labelled dataset and is supplemented by reinforcement learning from human feedback. For example, data labellers mark raw data points, (images, text, sensor data, etc.), with ‘labels’ that help the AI model make crucial decisions, such as for an autonomous vehicle to distinguish a pedestrian from a cyclist. It appeared that many such labellers can be completely disconnected from the AI developers, and are often not informed about who or what they are labelling raw datasets for. They are also subject to algorithmic surveillance and unreliable job stability. 

Third-party cookies as a cause of data breaches

JDSupra legal insights look at the disclosure of data through website cookies which may facilitate a data breach in California. In the related court case, the plaintiff claimed that an online counselling service where website users can find and seek therapy violated the California Consumer Privacy Act by allowing tracking software to retarget website users with ads. The court refused to dismiss the data breach claim. Specifically, the simple fact a user visited the website, may qualify as sensitive information because such a visit could mean they must have been seeking therapy.

Concerning whether using retargeting cookies is inherently illegal, the court refrained from rendering a decision.

US Child privacy bill

On 30 July, the Kids Online Safety and Privacy Act was passed by the Senate. KOSPA is a variation of two previously proposed bills: the Kids Online Safety Act, (KOSA), and the amended Child Online Privacy Protection Act, (COPPA 2.0). The act applies to digital platforms, particularly those with more than 10 million active monthly users. The duty of care includes options for minors to protect their data, prohibition of the use of dark patterns, and transparency regarding the use of opaque algorithms, etc. KOSPA now heads to the House, where it will be debated over potential censorship and the possibility of minors lacking access to vital information. 

Oncological oblivion

The Italian data protection authority Garante looks at “the right to be forgotten” in oncology, and whether banks, insurance companies, credit bodies, and employers can ask for information on the oncological pathology of an individual in a remission stage. Also, can a clinically recovered person adopt a child? These and other questions are answered in the FAQs published by the regulator, (in Italian). The aim is to prevent discrimination and protect the rights of people who have recovered from oncological diseases.

Chatbots and customer data

Employees sharing patient or consumer personal information with an AI chatbot have resulted in allegations of data leaks to the Dutch Data Protection Authority, (AP). The majority of chatbot developers store all data entered. Organisations must make clear agreements with their employees about the use of AI chatbots.  They could also arrange with the provider of a chatbot that it does not store the entered data. 

More official guidance

Avoiding outages and system failures: The US Federal Trade Commission insists that many common types of software flaws can be preemptively addressed through systematic and known processes that minimise the likelihood of outages. This includes rigorous testing of both code and configuration and the incremental rollout procedures. For instance, when deploying changes to automatically updating software, vendors could initially deploy it to a small subset of machines, and then roll it out to more users after it’s confirmed that the smaller subset has continued to function without interruption. 

Surveys at schools: The Latvian data protection authority investigates if a teacher can ask students to complete surveys. The educational process has long been not limited to the learning of the subject, but the psychological state of the child too. Answers given in student surveys can be divided into standard, personalised or anonymous forms. However, children often are not able to assess how much private information to give to others. Thus, security requirements, such as data non-disclosure and storage limitations must be applied in most cases.

Additional parent consent should be required if the surveys are related to the organisation of the learning process indirectly.

AI systems transparency: The German Federal Information Security Office, (BSI), published a white paper on the “Transparency of AI systems”. It says that the increasing complexity of the AI “black boxes” systems as well as missing or inadequate information about them makes it difficult to make a visual assessment or to judge the trustworthiness of the outputs. The paper defines the term transparency for various stakeholders from users to developers, and discusses the opportunities and risks of transparent AI systems, both positive, (promoting safety, data protection, avoiding copyright infringements), and negative, (the possible disclosure of attack vectors). 

Uniqlo ‘payroll’ mistake

The Spanish regulator imposed a fine of 450,000 euros, (reduced to 270,000 euros), on the UNIQLO branch in Spain, DataGuidance reports. The complainant, who provided services to UNIQLO, requested their payroll data and received an email containing a PDF document with payroll information on the entire 446-strong workforce. The document contained names, surnames, social security, bank account numbers, and more.

The breach was caused by a human error within the human resources department, but the employee in question had not informed their superior. The regulator confirmed that the negligent action of the employee does not exempt the data controller from liability.

Healthcare IT provider fine

The UK Information Commissioner’s Office has provisionally decided to fine Advanced Computer Software Group 6.09 million pounds. It provides IT and software services to the NHS and other healthcare providers, and handles people’s personal information on behalf of these organisations as their data processor. The decision relates to a ransomware incident in 2022, when hackers accessed several of Advanced’s health and care systems, (with the personal information of 82,946 people), via a customer account that did not have multi-factor authentication. 

More enforcement decisions

Car rental and client’s income: The Italian Garante imposed a one million euro fine on Credit Agricole Auto Bank for the illicit processing of personal and income data of customers who requested financing for the long-term rental of a car. The bank accessed the centralised fraud prevention system, also on behalf of its subsidiary, a car leasing company, despite it not having the necessary authorisation from the Ministry of Finance. 

The complainant contacted the bank to know the reasons behind the denial of the long-term rental and the inclusion of their name on a credit risk list. The bank stated these were due to the client’s negative income situation. Furthermore, the bank did not first acquire the client’s tax return form, an essential document for making a comparison with the information contained in the database. 

Dark patterns in the gambling industry: The Guernsey privacy regulator reviewed 19 online gaming sites for indicators of deceptive designs. In 42% of cases, the analysis was unable to find the website or app’s privacy settings, (in most cases those found were unnecessarily lengthy and complex). Also, it was more difficult to delete an account than it was to create one. In one of the instances, a user made their account deletion request through an on-site chatbot, as they were unable to find the ‘delete account’ option on the site. In another case, the organisation asked that a form be completed and returned to them, along with identity verification documents. Neither the documents nor the form were required to create an account. 

Data security

Lack of encryption: The Danish regulator has reprimanded the Vejen Municipality for insufficient security measures. Three stolen computers with information about children were not encrypted – and the same turned out to be the case with up to 300 other computers in the municipality. The computers were only intended for use by teachers as part of the teaching process. In practice, however, they were also used by teachers to make status descriptions of students, class handovers, etc. The regulator also issued a reminder that encryption of portable devices is a very basic security measure which is relatively easy and not very costly to implement.

GPS tracking: A court in Slovenia confirmed the decision of the Information Commissioner to restrict the use of GPS tracking of company vehicles, on a systematic, automated and continuous basis. The company did not demonstrate that such GPS tracking is a suitable and necessary measure for the protection of company vehicles and the equipment and documentation contained in them, nor to ensure employee safety or for the enforcement of potential legal claims and defence against them. 

Among other things, the court confirmed that the data obtained by the operator through the GPS tracking of company vehicles constitutes employees’ data, even though it is not recorded and stored in the tracking system itself, as the employees as drivers can be identified with the help of other documents, (eg, travel orders).

AI Grok

X agreed with the Irish Data Protection Commission to suspend the processing of the personal data contained in the public posts of X’s EU/EEA users, (processed between 7 May and 1 August), to train its AI ‘Grok’. The suspension will last while the DPC examines, together with other regulators, the extent to which the processing complies with the GDPR. The agreement was reached after the regulator submitted the case to the country’s Supreme Court.

In June, Meta also agreed with the DPC that it would delay processing EU/EEA user data for its AI tools. However, unlike Meta, X didn’t even notify its users beforehand. To make sure that X’s AI training is properly handled, the privacy advocacy group NOYB has now filed complaints with the data protection authorities in nine countries, (questioning what happened to EU data that had already been ingested into the systems, and how X can effectively distinguish between EU and non-EU data).

The post Data protection digest 3 – 16 Aug 2024: data labelling for LLMs, third-party cookies as a cause of leaks appeared first on TechGDPR.

Therefore, it is important to understand GDPR compliance. In most cases, the company that posts its vacancy and embarks on the recruitment process will be considered the data controller. This will make them responsible for adhering to several obligations.

Notably, here are some specific and recurrent instances, in the course of recruitment, headhunting and hiring, where a controller should look closely at the GDPR to make sure it is implementing the most appropriate and compliant solution. 

Legal bases: which is the most appropriate?

The lawfulness principle of the GDPR, first introduced in Article 5, requires that data is processed in a lawful manner, meaning that it must rely on at least one of the legal bases listed in the following Article 6. Not all legal bases are, however, always going to be applicable or the most appropriate choice, especially when dealing with candidates sourced online or applicants. The same holds true for current employees.

The imbalance of power when relying on consent

The European Data Protection Board (EDPB) acknowledges in their guidelines 05/2020 on consent, that there is a clear imbalance of power between an employer and their employee. Undeniably, the same is to be considered between a potential employer, and a prospective employee, or applicant. Although there is no dependency yet, one can still argue that an employer has a stronger bargaining position over a candidate that wishes to work for them. Therefore, the EDPB generally advises against the use of consent as a legal basis for processing activities carried out in this context. That is because, it would be difficult to prove that consent is freely given, as required by definition in Article 4 of the GDPR. In practice, it is likely that a candidate would feel obliged to provide their consent to any use of their data, as they might assume it gives them a better chance to get the job.

Legitimate interest is a good option, but comes with requirements

Instead, relying on legitimate interest might be preferable. However, the controller must still be mindful that it will also come with requirements. Based on Article 6 of the GDPR, the legitimate interest of the controller, cannot override the interests or fundamental rights and freedoms of the data subject. Which means that to begin with, the organization will have to, first and foremost, identify what the specific legitimate interest pursued is. Generally, sourcing individuals online, perhaps on professional social networking platforms, to find suitable candidates for a specific position, can be in the interest of growing a team and overall bettering an organization. However, merely identifying the interest is not enough. One would have to also balance this interest with the rights and freedoms of the data subject, also known as a balancing test, by performing a legitimate interest assessment.

Performance of a contract can be relied upon, but with limitations

Similarly, the legal basis of necessity for the performance of a contract might actually be the most appropriate for the processing of data of individuals who apply for an open position. Specifically, when interpreting the Article 6(1)(b) provision: in order to take steps at the request of the data subject prior to entering a contract. However, this might require strict adherence to the definition. It would have to be a contract that the data subject has requested. Therefore, for processing activities in the context of online recruitment and headhunting, it is unlikely that this legal basis can be relied upon. Instead, as mentioned above, legitimate interest might be the only option.

Online recruitment and the duty to inform

On the topic of online scouting and headhunting, there are further legal obligations that controllers need to be mindful of, when processing personal data for this purpose. Those being, depending on how these activities are carried out, the requirements of Article 14.

Reaching out to the candidate in due time

First and foremost, it is crucial to actually contact the candidate, if their data has been processed. In fact, Article 14 requires this communication to be done within a reasonable period after obtaining the personal data and at the latest within one month. That time-frame should also serve as a retention period for the data processed for this purpose, should the candidate not respond, for example. 

The communication should also require all the information to ensure that the transparency principle is met. Therefore, ideally the candidate should be directly informed, or at the very least be provided with a specific privacy notice indicating all the information required by Article 14 e.g. the identity of controller, the purpose of processing, the categories of data processed, etc…

Honoring data protection principles and data subject rights

Needless to say, the controller should adhere to the other principles of the GDPR. Notably, data minimization, by processing only the information that is strictly required to source the ideal candidate.

Furthermore, a controller should also inform candidates of and be mindful of data subject rights. Specifically ensuring that mechanisms are in place to allow for candidates to exercise them, and ensuring that the data be processed for a specific purpose, so once that has been fulfilled, the data should no longer be processed. In practice: if the data is only processed to reach out to potential candidates, and they reject the offer but do not expressly request the data to be erased, their personal information should still be erased, unless it serves another explicitly indicated purpose.

Processing special categories of data in recruitment

In accordance with Article 9 of the GDPR, special categories of data include the following: racial or ethnic origin, political opinions, religious or philosophical beliefs, trade union membership, genetic data, biometric data, health data and data related to sex life or sexual orientation.  As a general rule, processing data that falls under these categories is prohibited. However there are exceptions. Related to the context of hiring potential employees, two might be particularly relevant: explicit consent from the data subject and necessity to carry out legal obligations and exercising specific rights of the controller or the data subject in the field of employment and social security and social protection law, based on national law provisions.

How does this apply to recruitment?

There are several reasons. For example: a potential  employer might wish to request information about a candidate’s disability to make relevant adjustments, perhaps for interviews and, if relevant, for the work moving forward. Furthermore, many companies have established equal opportunity programs, dedicated for specific minorities and/or in a certain field. Alternatively, they wish to monitor whether they meet equal opportunity requirements. Some organizations might even get recognition for ensuring high standards for diversity e.g. Stonewall Top 100 employers in the UK, Human Rights Campaign Corporate Equality Index. However, in order to monitor those metrics and ensure diversity, they process special categories of data, such as race, disability (health data) and sexual orientation. 

Explicit consent or national law obligation?

As mentioned before, using explicit consent might be an issue, because it is hard to truly guarantee that it is freely given in this context. Especially when applying for an equal opportunity program, it is unlikely that the applicant has any choice but to disclose the relevant information, as that will be the deciding factor as to whether they meet the criteria to enter into the program. 

Instead, one can rely on the second exception, related to national legal obligations. In many countries, laws that ensure the equal treatment of minorities and penalize discrimination at work, often also include articles or sections that require positive action, in the field of employment. For example, in Germany, positive action is required by §5 of the Equal Treatment Act (AGG). In the UK, where the UK GDPR applies, this is provisioned in Article 159 of the Equality Act 2010. 

Organizations are left free to decide how to implement this, but this freedom has gradually led to defining metrics and equal employment opportunities. Since this is a way to exercise a legal right of the data subject, and a legal obligation of the controller, one could preferably rely on this exception, rather than explicit consent. 

In fact, best practice would be to rely on the national legal obligation exception where such exceptions apply, but request data subject’s explicit consent, which gives them the option not to reveal this information e.g. prefer not to say.

In conclusion…

Under the GDPR, controllers must process personal data of candidates and applicants lawfully. Not all legal bases are equally applicable: in the context of recruitment, relying on legitimate interest or performance of a contract might be more reliable than relying on the applicant’s consent, although those also have their rules and limitations too. 

Furthermore, a controller must ensure to note and follow the obligation to contact candidates that it scouts online, and keep in mind the one month deadline to get in touch.

Lastly, controllers might wish to get acquainted with national legal obligations in the scope of equal employment, as legal obligations in those frameworks provide them with a legal basis to process special categories of data, for the purpose of promoting diversity in the workplace. 

TechGDPR is a consultancy based in Berlin offering GDPR compliance assessments, DPO-as-a-service retainers and hourly consulting. TechGDPR consultants help assess the vendors you wish to purchase your solutions from, navigate the complexity of international data transfers as well as guide you through the most compliant roll-out of the solutions you have purchased. TechGDPR routinely trains product development, HR, marketing, sales and procurement teams in understanding data protection requirements.  It offers an online training course for software developers, system engineers and product owners.

The post Understanding GDPR Compliance in Recruitment appeared first on TechGDPR.