Data Protection Impact Assessment

Processing of Applicants' Personal Data. Assessment Platform & Automated Selection Decisions

Reference: PRIV-DPIA-01
Organisation: The Selection Lab B.V.
Version / Period: Version 2026.9 · September 2026
Address: Sint Pieterspoortsteeg 19, 1012 HM Amsterdam
Data Protection Officer: Ondřej Sloup (independent)
Chamber of Commerce: 71341730
Supervisory Authority: Autoriteit Persoonsgegevens (AP)

1 General Information

2 Overview of the Processing Activity

2.1 Context and Purpose

The Selection Lab provides an online assessment platform used by organisations to evaluate job applicants through structured psychometric assessments. The platform supports recruitment by generating insights into candidate characteristics and competencies. Organisations invite candidates to complete an assessment; candidate responses generate a digital skills profile used by the recruiting organisation during its recruitment procedure. Participation is voluntary.

In high-volume recruitment procedures, the platform may also apply predetermined, rule-based scoring thresholds to support or make selection decisions automatically. This use is addressed in full in Section 9, which sets out the Article 22 GDPR basis, conditions and safeguards that apply.

2.2 Service Objectives

• Support structured, objective candidate evaluation
• Improve recruitment decision quality and reduce unconscious bias
• Support transparent and fair hiring processes
• Enable proportionate, lawful automated processing of large candidate volumes where a recruitment procedure requires it
• Provide candidates with lasting insight into their own strengths and preferences
• Enable continuous improvement of the psychometric methodology and quality of hire through data analysis

3 Roles and Responsibilities

3.1 The Selection Lab as Primary Data Controller

The Selection Lab B.V. is the primary data controller for all processing activities described in this DPIA. It bears full legal responsibility under the GDPR for the lawfulness, fairness and transparency of the processing, for data subject rights, and for all security measures.

SOLV legal memorandum
"TSL verzamelt (bijzondere) persoonsgegevens in het kader van haar dienstverlening […] Zij bepaalt het doel en de middelen van verwerking en is als zodanig als een verwerkingsverantwoordelijke aan te merken." (SOLV §15)

Data subject rights, clear responsibility: When a candidate exercises GDPR rights, including erasure, access, rectification or portability, The Selection Lab is the responsible party, regardless of which client organisation invited the candidate. All requests must be sent to [email protected] and will be handled within one calendar month. The Selection Lab cannot redirect candidates to the client organisation for the fulfilment of these rights.

3.2 Client Organisation as Downstream Controller

The recruiting organisation is an independent controller for its own recruitment process: determining whether to make a job offer and managing its own personnel records. It does not control the psychometric assessment methodology and does not have access to raw candidate assessment scores. The boundary is defined in the Data Processing Agreement.

3.3 The Selection Lab as Processor (limited activities)

For operational tasks performed strictly on behalf of a client (e.g., sending assessment invitations), The Selection Lab may also act as data processor. In such cases a DPA is in place.

4 Data Subjects

This DPIA covers one category of data subject: individuals who apply for a position at a client organisation and are invited by that organisation to complete a psychometric assessment through The Selection Lab platform.

These are external job applicants who have actively applied for a role and have been selected by the recruiting organisation to complete a TSL assessment as part of the process. They are not employees of the client organisation. They have chosen to enter a recruitment procedure, which means their participation is grounded in a voluntary act prior to any TSL involvement.

1. They receive an invitation from TSL on behalf of the recruiting organisation, by email or (where the assessment runs by telephone) by phone, which they can choose to act on or disregard
2. They access the platform, are given the Privacy Statement through a link on the consent screen, and are asked to provide or withhold consent before any assessment data is collected
3. They complete a psychometric questionnaire that generates a personal skill profile covering personality traits, behavioural preferences, and motivational characteristics
4. They receive their own full assessment report, which they may choose to share with the recruiting organisation
5. They may, in high-volume procedures, be subject to an automated selection decision based on predetermined scoring thresholds, subject to the safeguards in Section 9
6. They may optionally consent to long-term retention of their profile for personal career use, and to use of their data for quality of hire analysis

Applicants are typically motivated to participate, as the assessment forms part of a recruitment procedure they have chosen to pursue. The legal and organisational measures described in this DPIA ensure that this motivation does not compromise the voluntary character of their participation and that automated decisions, where used, are accompanied by the safeguards Article 22(3) GDPR requires.

5 Categories of Personal Data Processed

5.1 Standard Personal Data

1. Name and email address
2. Telephone number, where the assessment is administered or completed by telephone rather than by email
3. Login credentials
4. Questionnaire responses
5. Candidate assessment results and skill profile
6. Recruitment stage classification data (e.g., hired / not hired, department)

5.2 Special Category Personal Data: Legal Qualification

The psychometric assessment outputs, comprising personality traits, behavioural preferences, motivational profiles, and cognitive ability, are classified as special category personal data under Article 9 GDPR, specifically as data relating to health (psychological condition).

AP BrainCompass ruling + SOLV confirmation
The Autoriteit Persoonsgegevens ruled (2 October 2017) that psychometric profiling data constitutes health data under GDPR. SOLV confirmed this applies to TSL's processing:

"De (gecombineerde) Assessmentgegevens zijn aan te merken als bijzondere persoonsgegevens, nu TSL hiermee een profiel creëert van de psychische gesteldheid, vaardigheden en beperkingen en daarmee de emotionele capaciteit van de deelnemer." (SOLV §12)

Processing of special category data is prohibited under Art. 9(1) GDPR unless an exception applies. TSL relies on explicit consent, Art. 9(2)(a).

6 Description of Processing Operations

1. Sending assessment invitations to candidates
2. Candidate authentication and platform access
3. Collection of questionnaire responses
4. Algorithmic generation of candidate skill profile and assessment results (deterministic, rule-based scoring)
5. Delivery of candidate reports to both candidate and recruiting organisation
6. Automated selection decisions based on predetermined scoring thresholds, where a recruitment procedure requires it (see Section 9)
7. Optional: long-term storage of candidate profile for continued personal access
8. Optional: data analysis for optimising quality of hire for the organisation

Candidates are given the Privacy Statement, linked from the consent screen, before participation. All optional processing requires separate, granular consent. Where an automated selection decision is applied, candidates are informed in advance in accordance with Article 13(2)(f) GDPR (see Section 9).

7 Legal Basis for Processing

7.1 Legal Basis Architecture

The Selection Lab relies on explicit consent as the primary legal basis for all psychometric assessment processing. This choice is deliberate: consent reflects the genuine, voluntary nature of the candidate's participation and gives data subjects the clearest possible control over their own data. The architecture is designed to ensure that consent is as freely given, specific, informed, and unambiguous as technically and contractually possible.

For automated selection decisions specifically (Section 9), TSL relies primarily on the necessity-for-a-contract exception in Article 22(2)(a) GDPR, with explicit consent under Article 22(2)(c) as an alternative basis. The reasoning is set out in Section 9.3.

One consent architecture for the entire selection process, not a special case for automated decisions
The explicit consent obtained under Art. 6(1)(a) and Art. 9(2)(a) is the lawful basis for the collection and processing of every assessment TSL administers within a selection procedure, whatever its modality: cognitive, personality, hard-skill, video, game-based, AI chat or avatar. It is not a basis engineered specifically for automated decisions. Automated selection under Article 22 is an additional layer built on top of an assessment that already rests on this consent.

This matters for how the freely-given question is weighed. If the argument were accepted that this consent is structurally invalid because the invitation originates from a prospective employer, the consequence would not be limited to automated selection: it would mean that no psychometric assessment of any kind could lawfully be administered in any selection process, by TSL or by any other provider, because they all rest on the same consent logic. Assessment-based selection is an established, regulator-acknowledged practice. The structural guarantee that a candidate who declines is simply routed to an alternative route in the procedure (for example, an on-site interview) rather than disadvantaged, is the concrete evidence that the refusal carries no penalty, which is precisely what makes the consent freely given.

7.2 What Makes Consent Valid: The Four Conditions

Article 7 and Recital 32 GDPR require that consent be freely given, specific, informed, and unambiguous. The Selection Lab's consent flow is engineered to satisfy all four conditions, as documented in the Personal Data Consent Description, available for regulatory inspection upon request:

7.3 The Power Imbalance Question: TSL's Position

The EDPB (WP259) and the AP (BrainCompass, 2017) have stated that consent in employment contexts is generally not freely given due to the hierarchical power relationship between employer and employee. The Selection Lab's model is materially different from the employment relationship for the following reasons:

1. Candidates are not employees. They are external applicants who have chosen to apply for a role. SOLV concluded (§26) that the power imbalance concern is less acute for external applicants who are free not to apply at all
2. The assessment provides candidates with something of value: they receive their full psychometric profile, a portable, professionally valuable document they can use beyond this application
3. A candidate who declines the assessment is not excluded: they continue the procedure through an alternative route. Declining changes the method of assessment, not the candidate's standing in the process

Note on automated decisions
Because the power imbalance argument is raised against consent in recruitment generally, TSL does not depend on consent as the sole basis for automated selection decisions. It relies primarily on Article 22(2)(a) necessity for a contract, which does not require consent. This is a deliberate strengthening of TSL's position: see Section 9.3. The Art. 9(2)(a) consent for the underlying special-category data rests on the same freely-given architecture that supports every assessment TSL administers (see §7.1).

7.4 Free Consent Architecture: Structural Guarantees

Guarantee 1: Refusal has no effect on candidacy. 'Yes' to the core consent question is required to take the assessment, not to continue the application. A candidate who declines leaves the assessment and is taken to the Selection Lab user portal; the recruiting organisation continues the procedure without the TSL assessment, for example through an on-site interview. The two optional consent questions state on screen that the choice does not matter for the progress of the application.

Guarantee 2: Client contractual obligation. Client organisations are contractually prohibited from using a candidate's refusal to consent as a reason to reject, deprioritise, or otherwise disadvantage that candidate.

Guarantee 3: Granular and revocable. The core assessment consent and each of the two optional opt-ins (long-term storage; algorithm improvement) require separate consent. Any consent can be withdrawn at any time via [email protected] without consequence.

7.5 Residual Legal Position and Monitoring

Residual legal position (SOLV §25)
SOLV noted that the AP may in principle question whether consent is freely given, on the basis that the assessment invitation originates from the employer rather than the candidate. TSL's structural guarantees substantially reduce this exposure, and TSL's reliance on Art. 22(2)(a) for automated decisions removes the most consequential processing from dependence on consent. Because this exposure applies to assessment-based selection as a category rather than to TSL specifically, the DPO monitors AP and EDPB guidance and initiates a DPIA review if new guidance materially affects the consent or automated decision-making architecture. See §22.

8 Data Flow Overview

9 Automated Decision-Making (Article 22 GDPR)

9.1 Why Article 22 Applies, and Why That Is Not a Problem

Article 22(1) GDPR gives a data subject the right not to be subject to a decision based solely on automated processing, including profiling, which produces legal effects concerning them or similarly significantly affects them. A decision to reject or advance a candidate on the basis of a score, taken without meaningful human involvement, engages this provision.

TSL takes the honest position that where the platform applies a predetermined threshold to automatically exclude or advance candidates in a high-volume procedure, this is a decision based solely on automated processing within the meaning of Article 22(1). TSL does not attempt to characterise this as non-automated by pointing to a downstream human who does not, in practice, review each individual outcome.

The key distinction: automated decision-making is not the same as an "AI system"
Article 22 GDPR is technology-neutral. It applies to any solely automated decision with significant effects, whether the logic is a simple fixed rule ("score below 60 = not advanced") or a machine-learning model. TSL's rule-based scoring falls under Article 22 when used to decide, but it is not an "AI system" under the EU AI Act, because it infers nothing: it executes fixed, validated rules. The two regimes are assessed separately. See Section 23 for the AI Act analysis, which is unaffected by this section.

9.2 Nature of the Automated Processing

The platform performs automated analysis of questionnaire responses to generate a match score indicating how well a candidate aligns with a validated benchmark. In high-volume procedures, a predetermined threshold may be applied so that candidates above the threshold advance and candidates below it do not, without an individual human decision on each candidate. This is the processing to which Article 22 applies.

Illustrative example. A client receives 350 applications for a small number of positions within a fixed timeframe. Conducting an individual human assessment of every one of the 350 candidates before any filtering is not reasonably practicable within the procedure. A predetermined, validated score threshold is applied automatically to produce a longlist, and only from that point is individual human assessment conducted. For the candidates who fall below the threshold, the automatic step is a solely automated decision with significant effect, and is governed by this section.

9.3 Legal Basis for the Automated Decision

Article 22(2) permits solely automated decisions with significant effects only where one of three grounds applies. TSL relies on the following, in order of primacy:

Primary basis: necessity for a contract, Article 22(2)(a)

Recruitment and selection are directed at concluding an employment contract with a candidate. Where the volume of applications makes individual human assessment of every applicant genuinely impracticable within the procedure, an automated selection step is necessary for the steps taken at the request of the data subject prior to entering into a contract. Necessity is assessed conservatively and documented per procedure: TSL and the client record why, at the given volume and timeframe, no less intrusive means (for example, human pre-screening of every applicant) would reasonably achieve the same purpose. The threshold policy and the volume justification are documented per procedure.

Alternative basis: explicit consent, Article 22(2)(c)

Where necessity for a contract is not established for a given procedure, TSL relies on the candidate's explicit consent, obtained separately and in advance. Refusal of this consent does not prevent participation in the core assessment; it means the automated selection decision is not applied to that candidate, who is instead routed to human assessment.

Special category data: Article 9(2)(a)

Because the score derives from special category (health) data, the automated decision also requires a condition under Article 9(2). TSL relies on the candidate's explicit consent under Article 9(2)(a) for the processing of the special category data underlying the decision. This is the same consent that lawfully grounds the assessment itself (see §7.1). It is obtained regardless of whether Art. 22(2)(a) or 22(2)(c) is the Article 22 basis, because Article 22(4) requires an Article 9(2)(a) or (g) condition for solely automated decisions based on special category data. TSL uses (a), explicit consent.

Interaction of the two consents
For an automated selection decision based on psychometric (health) data, TSL always obtains the candidate's explicit consent for the Article 9 special-category processing (Art. 9(2)(a)), as required by Article 22(4). The Article 22 decision itself rests primarily on necessity for a contract (Art. 22(2)(a)). This layered approach means the decision does not fail merely on the freely-given question, while the special-category data is processed on a valid Article 9 condition that is common to every assessment in the selection process.

Psychometric thresholds versus non-psychometric knock-out criteria
Two things are distinct and are treated differently in this DPIA. Article 22 governs the automation of a significant decision, whatever the criterion. Non-discrimination law governs the criterion itself, whether the decision is automated or human.

Psychometric thresholds (the subject of this section) rest on special-category health data, so they engage Article 22(4) and require the Art. 9(2)(a) condition described above.

Non-psychometric knock-out criteria (for example a required driving licence, a minimum level of relevant experience, or availability) do not rest on special-category data. Article 22(1)–(3) still apply when such a knock-out is fully automated and significant, but Article 22(4) and the Art. 9 condition do not, because no special-category data is involved.

A knock-out on a protected characteristic such as age is not permitted, and automation is not the reason. Direct distinction on age in recruitment is in principle prohibited under the Dutch Wet gelijke behandeling op grond van leeftijd bij de arbeid and Directive 2000/78/EC, absent a statutory exception or objective justification. This prohibition applies identically whether the knock-out is applied by a recruiter or by the platform. Automating it does not create the problem and does not cure it; it simply makes the offending rule explicit in the configuration. TSL therefore does not configure knock-out criteria on protected characteristics, and clients are contractually required not to request them. This is a non-discrimination constraint that sits above the Article 22 analysis and applies to every criterion, psychometric or not.

9.4 Safeguards Required by Article 22(3)

Article 22(3) requires suitable measures to safeguard the data subject's rights, freedoms and legitimate interests, including at least the right to obtain human intervention, to express their point of view, and to contest the decision. Because TSL applies automated decisions at scale rather than case by case, these safeguards operate after the automated decision, on the candidate's initiative, and are made genuinely accessible:

1. Right to human intervention. Any candidate subject to an automated selection decision may request that a qualified human assessor review the decision. The reviewer has the competence to understand the score, the authority to depart from it, and access to the candidate's full profile. This is a substantive re-assessment, not an administrative confirmation.
2. Right to express a point of view. Candidates may submit additional context (for example, circumstances affecting their assessment) which the human reviewer must consider.
3. Right to contest the decision. Candidates may formally challenge the outcome; TSL provides a written, reasoned response.
4. Transparency in advance. Before assessment, candidates are told that an automated decision may be made, are given meaningful information about the logic involved, and are told the significance and envisaged consequences (Art. 13(2)(f) and Art. 15(1)(h)).
5. Accessible route. Human review is requested via [email protected] and is handled within the timeframes in §16. The availability of this route is stated at the point the candidate is informed of the decision.

"Meaningful" human involvement
Human involvement only removes a decision from Article 22 if it is meaningful: the reviewer must have the knowledge to understand the outcome, the authority to deviate, and must actually use that room. Simply passing a computer result through to a rejection is not meaningful review. TSL does not claim that its up-front automated filtering is non-automated. It accepts that Article 22 applies and provides meaningful human review on request as the Article 22(3) safeguard. The meaningful-human-involvement test is satisfied at the review stage; it is not used to deny that automation occurred.

9.5 Additional Fairness Safeguards Specific to Threshold Decisions

• Thresholds are set on validated, job-relevant grounds and documented per procedure, with the necessity and volume justification recorded.
• Bias monitoring (Section 17, Risk 1) applies with particular force to threshold decisions: once the planned monitoring programme runs, it measures the effect of thresholds on protected groups.
• A cohort minimum and periodic review prevent thresholds from operating on unstable or unrepresentative norms.
• Clients are contractually required to disclose the use of automated selection in their own candidate communications and to honour human-review requests routed through them.

9.6 Proportionality: The Automated Decision Improves on the Human Baseline

A proportionality assessment compares the automated decision not against a hypothetical bias-free ideal, but against the realistic alternative it replaces. In practice, the alternative to an assessment-based decision is a human recruiter forming a judgement about a candidate's character, personality and suitability in a CV screen or a live interview, and applying a knock-out on that basis.

That human judgement also evaluates what are, in substance, personal characteristics relating to psychological disposition, and it is well established in selection research that unstructured human judgement of this kind carries substantially more bias and lower predictive validity than a validated psychometric instrument. TSL's automated decision therefore does not introduce a new intrusion into a previously neutral process; it replaces a subjective, poorly-validated and less transparent human assessment with a structured, validated, measurable and monitorable one.

• The decision rests on scientifically validated, measurable criteria with documented predictive validity, rather than on an individual recruiter's impression.
• Bias can be measured and reduced through the planned monitoring programme (Section 17, Risk 1), which is not possible for informal human judgement.
• The candidate receives their full profile and a route to human review, giving more transparency and recourse than a standard interview rejection.

This proportionality argument supports the necessity assessment; it is presented as a proportionality argument, not as an independent legal basis. The Article 22 basis remains Art. 22(2)(a) with Art. 9(2)(a) consent (Section 9.3).

10 Data Recipients and Sub-Processors

10.1 Internal Access and Data Recipients

Access is restricted to authorised personnel under role-based, least-privilege controls: senior technical staff, senior customer support, and C-level executives for compliance oversight. Periodic access reviews are conducted.

Data recipients. Beyond internal access, candidate data is exchanged with the client's own recruitment systems where an ATS integration is in place. TSL transmits assessment status and results to, and receives candidate details from, the client's applicant tracking system, including Recruitee, Teamtailor, Workable, iCIMS and the other systems TSL supports. Get Noticed, a job-site platform operated by the client, sends applications to TSL in the same way. These platforms are operated by the client organisation, which is an independent controller for its own recruitment process (§3.2); they are recipients of data rather than sub-processors of TSL, and the boundary is set in the Data Processing Agreement.

10.2 Sub-Processors: Assessment Platform (all clients)

10.3 Sub-Processors: Assessment Providers (per assessment used)

Scope note
TSL administers assessments from a number of specialist providers. A given provider is engaged only where the recruiting organisation uses the assessment concerned; no candidate data reaches a provider whose assessment is not part of that client's configuration. The providers are listed in full so that the documented scope covers every assessment a client may use.

10.4 Sub-Processors: SmartChat Module (SmartChat clients only)

Scope note
The sub-processors listed here are exclusively relevant to organisations using the SmartChat module. Organisations using only the assessment platform have no involvement with any of the processors below.

11 Client-Configurable Processing Scope

11.1 Principle

Not every processing purpose described in this DPIA is applied to every client. A number of processing purposes are optional and are configured per recruiting organisation at onboarding. Where an optional purpose is switched off for a client, it is not offered to that client's candidates: the corresponding consent question and privacy-notice text are suppressed, so that the documented scope and the candidate-facing flow always match. This section makes that configurability explicit and records how each choice is fixed contractually.

11.2 Configurable Processing Options

11.3 How Configuration Is Fixed and Kept Consistent

1. Contractual record. The enabled/disabled state of each optional purpose is recorded per client in the Data Processing Agreement (or an order form/schedule referenced by it), so the agreed scope is documented and auditable.
2. Technical enforcement. When an optional purpose is disabled for a client, the platform suppresses the corresponding consent question and the related privacy-notice text for that client's candidates. A candidate is never asked to consent to a purpose that is switched off, and never sees notice text for processing that will not occur.
3. Documentation-practice parity. Because the candidate-facing flow is driven by the same configuration, the DPIA description, the DPA, the consent flow and the privacy notice remain aligned by construction.
4. Change control. A change to a client's configuration that introduces a new processing purpose (for example, enabling automated selection decisions) is a change to the processing and is subject to the review triggers in Section 22.

12 International Data Transfers

12.1 Assessment Platform: Transfers Outside the EEA and Safeguards

All core assessment data is stored and processed within the EEA, except questionnaire responses collected through Typeform and VideoAsk (touchpoint 1) and, for clients that use it, the CriteriaCorp aptitude test (touchpoint 3). Candidate responses and results are stored in AWS Frankfurt (eu-central-1); the backend application runs in Heroku EU (AWS Dublin, Ireland). Platform data also sits in the following locations: AWS Stockholm (eu-north-1) holds the air-gapped backup vault; AWS Paris (eu-west-3) holds the data stores of the staging application, which runs on Heroku, and holds no production data; AWS Ireland (eu-west-1) holds deployment assets and Athena query results; the query results include user and participant data, prepared from DynamoDB for the internal sales and finance dashboards in Amazon QuickSight, a setup that is being phased out; an RDS SQL mirror is held in Frankfurt.

TSL does not routinely transfer assessment personal data outside the EEA. The following touchpoints exist and rest on Article 46 safeguards rather than on EU hosting:

1. Typeform and VideoAsk. Response data is hosted in the US on TSL's current plan. The executed Typeform/VideoAsk DPA applies, with SCCs; Annex III names Amazon Web Services Inc. (US). This risk is mitigated by contract, not by EU hosting.
2. Cloudflare, Papertrail (SolarWinds) and Superhuman are US entities with access to, respectively, request metadata including candidate IP addresses, application logs that may carry candidate identifiers, and candidate correspondence held in company mailboxes. Each is covered by SCCs (see §10.2).
3. CriteriaCorp is established in the United States and Australia and processes candidate answers and results for the cognitive aptitude test, for existing clients that use that assessment. Its SCCs apply once its DPA is executed; Australia has no adequacy decision (see §10.3).
4. HubSpot and Pendo are US-headquartered but contractually process data on EU infrastructure.

All of the above is supplemented by encryption in transit and at rest and by the contractual safeguards recorded in §10.2 and §10.3.

12.2 SmartChat Module: Transfer Analysis (SmartChat clients only)

SmartChat involves one transfer touchpoint outside the EEA (OpenAI API, USA). By design, the local PII detection model removes or substitutes all personal data before messages are transmitted, so OpenAI receives sanitised content only. OpenAI DPA and SCCs act as a belt-and-braces safeguard. The WhatsApp channel processing remains entirely within the EU. See Section 24 for the full architecture.

13 Data Retention

13.1 Retention Schedule

The optional retention purposes above are governed by the consent structure in Section 7 and are configurable per client (Section 11). A client can switch the optional opt-ins on or off for its own candidates; where an opt-in is switched off, the corresponding retention does not occur and the candidate is not asked to consent to it. The core 6-month retention is always applied. Retention is reviewed every six months, in April and in the October review week.

13.2 Quality of Hire Data: 5-Year Retention Rationale

Data used for quality of hire analysis (with separate consent) is retained for up to five years. This data must remain linked to individual results: anonymisation would defeat the purpose, as predicting which profiles lead to successful hires requires connecting assessment outcomes to actual performance data at the individual level. Predictive validity can only be assessed against actual performance outcomes, typically available 12 to 24 months after hire; five years is a proportionate window balancing analytical value against data minimisation.

Client access: Recruiting organisations do not have access to individual candidate data after the completion of a recruitment procedure. Clients receive only aggregated insights, never individual candidate performance data, for the 5-year retention period.

13.3 20-Year Long-Term Access: Rationale, Proportionality and Governance

The option to retain a personal skill profile for up to 20 years is a voluntary, opt-in feature for candidates only. A validated psychometric skill profile functions as a portable, objective record of a person's competencies, used across multiple job applications over a career, comparable to a LinkedIn profile or CV. The data belongs to the candidate, is stored solely for their benefit, and is never accessible to client organisations during this extended period.

1. Long-term storage is an explicit opt-in: the default is deletion at 6 months
2. An annual reminder is planned: each year, candidates will be asked to confirm whether TSL may continue to retain their profile. It will be an active check-in rather than a silent renewal: if a candidate does not respond, the profile remains stored, and the reminder will also prompt them to update or delete it at any time. Until it is in operation, candidates can withdraw consent and have the profile deleted at any time via [email protected].
3. Candidates may request deletion at any time via [email protected]

Proportionality (Art. 5(1)(e)): a working career commonly spans 35 to 45 years; a 20-year maximum, supported by explicit opt-in, withdrawal at any time and, once in operation, annual reminders, is proportionate. The period was directly informed by data subject consultation under Article 35(9) (see Section 14).

14 Data Subject Consultation (Article 35(9) GDPR)

Article 35(9) GDPR requires that, where appropriate, the controller seeks the views of data subjects or their representatives on the intended processing. The Selection Lab conducted data subject consultation as part of this DPIA. Key findings:

1. Candidates expressed a strong preference for long-term access to their own skill profile, directly informing the 20-year maximum retention period
2. Candidates valued clear explanations of how their data contributes to algorithm improvement and indicated willingness to consent when transparently explained
3. Candidates regarded advance transparency about any automated selection decision, and an accessible route to human review, as essential to trust
4. The ability to withdraw consent at any time was cited as a key condition of trust

15 Security Measures

15.1 Technical Safeguards

1. Encryption of all data in transit (TLS) and at rest (AES-256)
2. Primary data storage in secure EU cloud infrastructure (AWS Frankfurt); the backend application runs in Heroku EU (Dublin)
3. Multi-factor authentication available for all platform access: switched on for a client's users on request, or applied by the client's own identity provider where the client signs in through single sign-on. Staff access to the infrastructure (AWS, Heroku, GitHub, Cloudflare, Google Workspace) requires MFA.
4. Role-based access controls with least-privilege enforcement
5. Continuous monitoring, intrusion detection and access logging
6. Automated vulnerability scanning and penetration testing
7. Pseudonymisation applied to all employee baseline data

15.2 Organisational Safeguards

1. Confidentiality obligations for everyone who may come into contact with confidential data: the employment contract for employees, and a standalone confidentiality agreement for contractors and for interns whose agreement lacks an equivalent clause
2. Regular security awareness training
3. Vendor risk management programme for all sub-processors
4. Documented incident response and 72-hour AP breach notification procedure
5. Periodic internal privacy compliance reviews

15.3 Operational Resilience

1. Encrypted automated backups with tested restoration procedures. Recovery drills restore production backups into a fresh table in the production region and point the staging application at it, under the DPO's advance approval, with the access window and teardown logged; nothing is copied into Paris staging.
2. Disaster recovery and business continuity plans
3. Infrastructure redundancy

16 Rights of Data Subjects

All data subjects may exercise their rights under Chapter III GDPR free of charge. The Selection Lab is the sole responsible party for fulfilling these rights regardless of which client organisation invited the candidate.

16.2 Response Procedure and Timeframes

16.3 Erasure During Active Recruitment

If a candidate requests erasure during an active procedure, TSL erases all data it holds within the 1-month deadline, notifies the client that the profile is no longer available (without disclosing the reason), and informs the candidate that their application status is now a matter between them and the client. TSL cannot compel a client to erase data the client holds independently.

17 Risk Assessment

Risk 1: Algorithmic Bias and Unfair Impact on Protected Groups

Psychometric instruments, and the thresholds applied to their scores, may produce results that systematically disadvantage candidates from certain demographic groups (gender, ethnicity, age, disability). Where a threshold drives an automated selection decision (Section 9), biased scoring creates a heightened risk of indirect discrimination.

Inherent likelihood: Medium-High · Inherent impact: High

• Instrument-level bias screening: all instruments tested for differential item functioning (DIF) across gender, age, and cultural background before deployment
• Multiple norm groups so scores can be contextualised appropriately
• Threshold-specific monitoring: the impact of any automated selection threshold on protected groups is tested before use; testing during use follows with the planned monitoring programme
• Human review on request provides an individual corrective route for candidates excluded by an automated decision
• Candidate transparency: candidates receive their full profile and can challenge results

Residual risk: Low-Medium (reflecting the strength of the mitigation programme; elevated attention for threshold decisions)

Post-assessment bias monitoring programme
Planned, together with the annual retention reminder (§13.3): six months after results, TSL will send a voluntary follow-up questionnaire (the delay ensures no active recruitment is affected) collecting self-reported demographic data, linked only via anonymous identifiers to assessment scores, to test whether mean scores, distributions, match ratings and threshold pass-rates are statistically equivalent across groups. Systematic differences that cannot be explained by genuine job-relevant variation will trigger recalibration. Findings will be documented in an annual report reviewed by the DPO. The questionnaire collects new special category data, so this DPIA is updated before it starts.

Because demographic data cannot lawfully be collected on a mandatory basis, the monitoring will rely on voluntary self-reporting. TSL will address the representativeness of that response by (a) requiring a minimum response volume and minimum subgroup size before drawing any statistical conclusion; (b) not treating a low or skewed response as evidence of an absence of bias, but marking such a measurement as inconclusive and continuing to monitor; and (c) using multiple measurement cycles rather than a single snapshot.

The combination of instrument-level DIF screening before deployment, multiple norm groups, threshold-specific monitoring, the planned continuous bias measurement and an individual human-review route reduces this risk to Low-Medium. A residual element remains and is kept under review rather than treated as fully eliminated.

Risk 2: Invalidity or Unfairness of an Automated Selection Decision

An automated decision under Article 22 may be unlawful if a valid Art. 22(2) ground is absent, if the Art. 22(3) safeguards are not genuinely available, or if human review is administrative rather than meaningful.

Likelihood: Medium · Impact: High

• Primary reliance on Art. 22(2)(a) necessity for a contract, documented per procedure with a volume and necessity justification
• Art. 9(2)(a) explicit consent always obtained for the special-category data underlying the decision (Art. 22(4)), on the same architecture as every assessment
• Meaningful human review guaranteed on request, conducted by an assessor with competence and authority to deviate
• Advance transparency (Art. 13(2)(f)) and accessible contest route
• Threshold policies validated and documented; necessity re-assessed per procedure

Residual risk: Medium (depends on disciplined per-procedure documentation and genuinely meaningful human review)

Risk 3: Unauthorised Access to Candidate Data

Likelihood: Low · Impact: High

• MFA enforced for staff access to the infrastructure, and available to client users on request or through their own single sign-on; encryption in transit (TLS) and at rest (AES-256); role-based least-privilege access; continuous monitoring and third-party penetration testing

Residual risk: Low

Risk 4: Data Breach Exposing Special Category Psychometric Data

Likelihood: Low · Impact: Very High

• All data encrypted at rest; secure EU-hosted infrastructure; documented breach response and 72-hour AP notification; regular penetration testing

Residual risk: Low-Medium

Risk 5: Misinterpretation or Excessive Reliance on Assessment Results

Likelihood: Medium · Impact: Medium

• Outputs framed as advisory insights where used by humans; where used as an automated threshold, the Section 9 safeguards apply; client onboarding includes guidance on appropriate use

Residual risk: Low-Medium

Risk 6: Re-identification in Anonymised Analytics Datasets

Likelihood: Low · Impact: Medium

• Cohort minimum of 10 (k-anonymity standard) before any aggregated output; identifying variables separated from analytical datasets

Residual risk: Low

Risk 7: Consent Validity Due to Power Imbalance

The AP may hold that consent is not freely given due to the recruitment power imbalance. As set out in §7.1, this exposure applies to assessment-based selection as a category, not to TSL specifically.

Likelihood: Medium · Impact: High

• Consent refusal has zero effect on candidacy: candidates who decline continue via an alternative route, and clients are contractually prohibited from using refusal as a selection criterion; granular, purpose-specific, revocable consent
• For automated decisions, primary reliance on Art. 22(2)(a) reduces dependence on consent; Art. 9(2)(a) consent remains required for the special-category data but the decision does not stand or fall on the freely-given question alone

Residual risk: Low-Medium (the structural guarantees and the Art. 22(2)(a) reliance materially reduce the exposure; remaining uncertainty depends on future regulatory interpretation)

18 Proportionality and Necessity

1. Participation in the assessment is voluntary; where an automated decision applies, the candidate is informed in advance and retains the right to human review
2. Automated selection is used only where the volume of applications makes individual human assessment of every applicant genuinely impracticable; necessity is documented per procedure
3. Where an automated decision is made, it rests on scientifically validated, measurable criteria with documented predictive validity, and replaces a less controlled, more biased human judgement rather than a neutral process (see Section 9.6)
4. Only the minimum data necessary to deliver the service is collected
5. Explicit, granular consent is obtained for special-category processing and for each optional purpose
6. Candidates retain full control and can withdraw consent or request erasure at any time
7. Retention periods are defined, justified, and enforced by automated deletion
8. Psychometric assessment has a well-recognised legitimate utility in improving the quality and fairness of hiring decisions

19 External Legal Foundation: SOLV B.V.

This DPIA incorporates and builds upon the legal memorandum prepared by SOLV B.V. (Thomas van Essen, Advocaat; Mike Landerbarthold, Legal Counsel), Amsterdam, Project 11711, dated 4 March 2019. The memorandum is available for regulatory inspection upon request.

Consistency of the Article 22 architecture with the SOLV foundation
The Article 22 basis adopted in Sections 9 and 23 is built on the same controller status, special-category qualification and consent architecture that SOLV established. The automated-decision layer applies the Art. 22(2)(a) and Art. 9(2)(a) grounds to the existing, validated consent model rather than introducing a new legal foundation, so the memorandum's findings carry through to this version. The memorandum predates both the automated selection decisions described in Section 9 and the AI features described in Section 23; the AI Act analysis in Section 23 has not been subject to external legal review.

20 Residual Risk Evaluation

Following the mitigation programmes described above, algorithmic bias and consent validity are assessed at a Low-Medium residual level, and the validity and fairness of automated decisions at Medium. All three are kept under ongoing review. This DPIA does not claim any risk is fully eliminated; it concludes that the safeguards in place reduce the residual risks to a level proportionate to the legitimate purpose.

Prior consultation with the AP
No individual risk is assessed as high residual risk, so prior consultation under Article 36 GDPR is not mandatory. Given TSL's deliberate adoption of solely automated decisions on special-category data at scale and the AP's active 2026 guidance on automated decision-making in assessments, the DPO keeps proactive engagement with the AP on the automated decision-making architecture under active consideration, and will reassess the need for prior consultation if the bias or automated-decision risks move to high.

21 Data Protection Officer: Independence and Role

The Selection Lab has appointed Ondřej Sloup as its registered Data Protection Officer (DPO), effective 8 September 2026, in compliance with Article 37 GDPR, formally registered with the Autoriteit Persoonsgegevens.

DPO independence confirmed
Ondřej Sloup is not a member of the Management Team and holds no shares or financial interest in the company (Art. 38(6) GDPR). The DPO reports directly to the highest management level and cannot be penalised for performing DPO tasks.

The DPO's responsibilities under this DPIA include advising on lawfulness (including the Article 22 basis in Section 9), reviewing and approving the annual bias monitoring report once the monitoring programme runs, monitoring retention schedules, handling escalated data subject rights requests, acting as AP point of contact, and triggering and coordinating DPIA reviews (Section 22).

22 DPIA Review Triggers and Schedule

Under Article 35(11) GDPR and EDPB guidelines, a DPIA must be reviewed when there is a change in the risk represented by the processing. The following events require the DPO to initiate a formal DPIA review:

Review ownership: The DPO (Ondřej Sloup) monitors the above triggers and initiates a review when any is met. The updated DPIA is approved by management before the relevant change goes into production. A version log is maintained at the end of this document.

23 EU AI Act Compliance Analysis

Relationship to Section 9
This section is deliberately kept separate from the Article 22 analysis in Section 9. Article 22 GDPR governs automated decision-making regardless of the technology used. The EU AI Act governs only "AI systems". TSL's rule-based scoring is an automated decision-maker under Article 22 but is not an AI system under the AI Act. The adoption of automated selection decisions therefore does not change TSL's AI Act position, because the scoring remains rule-based (no inference or learning).

23.1 Background and Applicability

The EU Artificial Intelligence Act (Regulation (EU) 2024/1689) entered into force on 1 August 2024 and introduces a risk-based classification framework, with the most stringent obligations attached to high-risk AI systems listed in Annex III. Annex III, point 4, includes AI systems used to screen or filter applications, evaluate or assess candidates, or make or significantly influence hiring decisions.

Timeline note (2026)
The application date for Annex III high-risk obligations, including employment systems, was originally 2 August 2026. Under the Digital Omnibus political agreement this date is proposed to move to 2 December 2027. As of September 2026 this remains a proposal, not enacted law (the European Parliament adopted a first-reading position on 16 June 2026; the procedure is ongoing). TSL treats the later date as planning input only and does not rely on a possible postponement to defer its own controls.

Voluntary pre-compliance: TSL applies the safeguards now
Although TSL's components fall outside the high-risk category (Section 23.3–23.5), and although the high-risk obligations are in any case not yet in application, TSL already holds itself to the substance of the AI Act's high-risk safeguards as a matter of policy. This is deliberate: rather than wait for the obligations to apply, TSL operates the controls now, so that any future move toward a higher-risk feature starts from an already-compliant baseline.

Concretely, and independently of any statutory deadline, TSL already maintains: pre-deployment bias screening of the instruments, with ongoing bias monitoring and documented recalibration planned (Section 17, Risk 1); advance transparency to candidates and meaningful human review on request (Section 9.4); human oversight designed into the process; versioned technical documentation of the scoring logic (Section 23.3); and AI transparency disclosure for SmartChat (Section 23.5). These mirror the high-risk expectations around risk management, data governance, transparency, human oversight and record-keeping, even where TSL is not legally required to meet them.

23.2 TSL's Technology Components: What Is and Is Not AI

23.3 Psychometric Scoring: A Deterministic Rule Engine, Not an AI System

The AI Act defines an AI system as a machine-based system that, for explicit or implicit objectives, infers from the input it receives how to generate outputs such as predictions, recommendations, or decisions (Article 3(1)). The operative word is infers: it presupposes that the system derives its outputs through learning, statistical modelling, or pattern recognition, rather than through the execution of predetermined rules.

TSL's psychometric scoring does none of that. It is a deterministic rule engine, built and fixed in advance by psychometric scientists, that can be described exhaustively in the following terms:

1. No machine learning. The scoring logic is not trained. There is no model that has learned parameters from data; there are only scoring rules written by domain experts and validated against psychometric norms.
2. No inference. The system does not estimate, predict, or generalise beyond its rules. It reads the candidate's answers, applies fixed weightings and scoring keys, and computes a score by arithmetic. Every step is a predetermined calculation, not a learned judgement.
3. Fully deterministic and reproducible. The same input always produces the same output. There is no probabilistic component, no randomness, and no drift over time. A given set of answers scored today and scored in five years yields an identical result, provided the (versioned, documented) rule set is unchanged.
4. Transparent and inspectable. Because the logic is a fixed rule set rather than a learned model, it can be read, audited and explained in full. There is no opaque layer whose behaviour must be probed empirically; the rules are the specification.
5. Rule changes are governed, not learned. When a scoring rule or weighting is updated, that is a deliberate, documented change to the specification made by TSL's psychometricians and recorded under version control. The system never modifies its own rules in response to data.

This is functionally equivalent to a calculator or a spreadsheet formula: it executes rules, it does not infer. A calculator that returns the same answer for the same sum every time is not performing inference, and neither is TSL's scoring engine.

Position
Psychometric scoring as implemented by TSL does not meet the AI Act definition of an AI system and falls outside the Act's scope entirely, even when its output is used to make an automated Article 22 decision. Using a non-AI, deterministic, rule-based score to decide automatically is a GDPR Article 22 question (Section 9), not an AI Act question.

23.4 LLM-Assisted Knock-Out Question Interpretation

TSL uses a large language model to interpret free-text candidate responses to knock-out questions. For example, if a candidate writes "I got mine last year" in response to a question about a driver's licence, the LLM interprets this as "Yes" and populates the field. Before anything is submitted, the chat sends the candidate a summary of the questions and their answers as the chat understood them. The candidate can reply in the conversation to change any answer, and submits by clicking "Confirm"; after that the answers can no longer be changed. Only the candidate-confirmed version is submitted.

Why this is not a high-risk AI system
The confirmation step severs the causal link between the LLM and any decision. After confirmation, the submitted record is the candidate's own confirmed statement, functionally identical to selecting "Yes" from a dropdown. The LLM is a natural-language input parser, not an evaluator or decision-maker. Its output has no effect on any candidacy without the candidate's active validation.

Documented safeguard: interpretation accuracy is monitored; the confirmation summary always shows the answers as the chat understood them before submission; systematic patterns trigger a prompt-engineering review reported to the DPO.

23.5 SmartChat Guidance Chatbot (SmartChat clients only)

TSL uses an AI-powered chatbot to answer candidate questions about the process, platform navigation, and privacy. It is informational only: it does not assess candidates, does not feed any scoring or matching process, and has no connection to the hiring decision pipeline. It is powered by OpenAI via API, with a locally-deployed PII gateway ensuring OpenAI receives only sanitised content (Section 24).

AI Act position
The SmartChat guidance chatbot is not a high-risk AI system. It performs a customer-service function with no connection to hiring decisions and falls into the limited-risk category under Article 50: TSL discloses in the chat interface that the candidate is interacting with an AI system, satisfying the transparency obligation.

23.6 Forward-Looking: When High-Risk Would Apply

TSL's current architecture sits outside the high-risk category. The following developments would change this and require a formal AI Act conformity assessment before deployment:

• Automated candidate ranking or shortlisting using machine learning to rank, score, or recommend candidates based on profile data (this is inference, and Annex III point 4 would apply)
• Predictive performance scoring that infers likely job performance and presents it as a recommendation
• Automated talent-pool matching that proactively surfaces candidates to employers via a learned model
• Any use of LLM outputs in decisions without candidate confirmation (removing the knock-out confirmation step)

Important boundary
Introducing automated Article 22 decisions using the existing deterministic score does NOT cross into high-risk, because no inference is added. It would cross into high-risk only if TSL replaced the rule-based score with a machine-learning model that infers outcomes. The line is inference, not automation. The DPO reviews any move from rule-based scoring to a learned model against the AI Act high-risk criteria before launch.

23.7 Summary Position

24 SmartChat: Privacy Architecture and Data Flow

Scope: SmartChat clients only
This section is relevant only to organisations that have contracted the SmartChat module. Organisations using the assessment platform only have no involvement with OpenAI, Meta/WhatsApp, or any of the data flows described here.

24.1 What SmartChat Is

SmartChat is an optional add-on providing candidates with an AI-powered conversational interface for questions about the recruitment process, the platform, and privacy. It is available via a web interface (AWS Frankfurt, EU) and WhatsApp via 360dialog GmbH (Berlin), which uses WhatsApp Ireland Limited (Dublin) for delivery. All WhatsApp processing takes place within the EEA; file uploads are technically blocked. SmartChat does not evaluate candidates and has no connection to the psychometric pipeline.

24.2 The PII Gateway: Privacy by Design

A locally-deployed open-source PII detection model acts as a gateway between the candidate and OpenAI, running entirely on TSL's EU infrastructure. Every message passes through detection and removal/substitution of personal data before any external transmission; only sanitised, PII-free content is sent to OpenAI, which returns a response routed back via AWS Frankfurt.

GDPR consequence of effective PII removal
If no personal data reaches OpenAI, which is the design intent, transmitting sanitised messages does not constitute an international transfer of personal data under GDPR Chapter V. TSL maintains OpenAI's DPA and SCCs as a belt-and-braces safeguard against edge-case failures. Low-entropy identifiers (phone numbers) are removed rather than hashed, because hashing finite-space identifiers is pseudonymisation, not anonymisation.

24.3 Retention for SmartChat

• Message content (TSL database, AWS Frankfurt): retained for the recruitment process plus a short support window; not linked to the psychometric profile
• Message content (360dialog): auto-deleted after a maximum of 7 days
• Channel metadata (360dialog): timestamps and delivery status retained max 7 days
• PII gateway logs: record that a detection event occurred (not the data), retained 30 days, EU only
• Prompt and completion logs (Langfuse Cloud EU): sanitised content and quality scores, candidate identified by pseudonymous id only
• OpenAI: does not train on API content; sanitised messages not retained beyond request processing

Residual risk: Low No automated PII detection achieves 100% recall; the OpenAI DPA/SCCs and continuous gateway monitoring mitigate the edge-case residual. The WhatsApp channel introduces no international transfer risk, as all processing occurs within the EU/EEA.

25 Conclusion

This Data Protection Impact Assessment concludes that the processing of personal data by The Selection Lab B.V. is underpinned by appropriate legal bases, incorporates recognised security safeguards, ensures meaningful transparency and control for candidates, and has been designed with proportionality and necessity in mind.

This version reflects TSL's deliberate use of fully automated, rule-based selection decisions in high-volume procedures. TSL takes the honest position that these are solely automated decisions under Article 22 GDPR and relies primarily on necessity for a contract (Art. 22(2)(a)), with explicit consent as an alternative, and always obtains Art. 9(2)(a) consent for the special-category data underlying the decision. That consent is the same architecture that lawfully grounds every assessment TSL administers within a selection process, whatever its modality; if it were held invalid, no assessment-based selection would be lawful for any provider, which is why the freely-given question is treated as a category-wide regulatory matter rather than a TSL-specific defect. The Article 22(3) safeguards, meaningful human review on request, the right to express a view, and the right to contest, are made genuinely accessible rather than treated as an administrative formality.

This version also documents, in Section 11, that a number of processing purposes are configurable per client and that the candidate-facing consent flow and privacy notice track that configuration, so documented scope and practice remain aligned. Section 10 now records the full sub-processor landscape, including the specialist assessment providers engaged per assessment used, so that the DPIA, the Data Processing Agreement and the privacy statement present one and the same list.

Separately, the platform's scoring is a deterministic rule engine that performs no inference and no learning, and therefore remains outside the scope of the EU AI Act; the LLM knock-out and SmartChat components remain non-high-risk and limited-risk respectively. Automating decisions with a rule-based score does not alter this AI Act position; only a move to a learned, inferential model would.

Article 22 governs the automation of a significant decision whatever the criterion, while non-discrimination law governs the criterion itself. Knock-out criteria on protected characteristics such as age are therefore not configured, independently of the Article 22 analysis and independently of whether the decision is automated.

After mitigation, algorithmic bias and consent validity in the recruitment context are assessed at a Low-Medium residual level, and the validity and fairness of automated decisions at Medium; all three are kept under ongoing review. This DPIA is a well-founded internal assessment maintained by the DPO under the review schedule in Section 22.

26 Reference Documents

Every later revision updates this table with the versions it used.

A Appendix — Version Log