How to Validate Employment Data for EU ATS Profiles

If you build recruiting software for the EU market, profile enrichment is one of the most useful and most dangerous features you can ship. Useful, because a candidate record with a current employer, a current job title, and clean employment dates is worth far more than a resume snapshot from two years ago. Dangerous, because the moment your pipeline writes that data onto a profile, you are making a legal claim that the data is accurate.

That claim is governed by the accuracy principle. GDPR Article 5(1)(d) requires that personal data is "accurate and, where necessary, kept up to date", and that "every reasonable step must be taken to ensure that personal data that are inaccurate, having regard to the purposes for which they are processed, are erased or rectified without delay". You can read the principle in Regulation (EU) 2016/679, the GDPR, which has applied since 25 May 2018.

Employment data is exactly the kind of data that goes stale. The US Bureau of Labor Statistics reported that median tenure for wage and salary workers was 3.9 years in January 2024, the lowest since 2002, and that 22 percent of workers had one year or less of tenure with their current employer, per its Employee Tenure in 2024 release. People change jobs often, so a "current employer" field is stale on arrival unless you validate it. This guide gives you the three validation layers every enrichment write should pass before it reaches an ATS profile.

The first layer is the one teams skip most often, and it is the one that causes the most damage. Before you look at a single field, ask whether the source you pulled the data from is both trustworthy and lawful to use as an enrichment feed. A well-formatted job title from an unreliable source is still bad data, and it is bad data you are now accountable for.

Regulators expect this to scale with how much the data matters. The UK Information Commissioner's Office, interpreting the same accuracy text, advises that "the more important it is that the personal data is accurate, the greater the effort you should put into ensuring its accuracy", and that you should keep "the source and status of personal data" clear in your records. Both points are set out in the ICO's guidance on the accuracy principle. Employment data feeds a hiring decision, so it sits at the high-effort end of that scale.

Concretely, a source-validation step should record, for every enrichment feed, where the data originated, whether it is a publicly accessible source, and when it was last refreshed. Reject data from feeds you cannot attribute. This record is not busywork: it is what makes the next two layers, and your Article 14 notice, possible.

Once the source passes, validate the fields themselves. Employment enrichment usually writes three things, and each has its own failure modes worth checking before the data lands on a profile.

• Employment dates. Check that ranges are internally consistent: a start date before an end date, no end date in the future, and no impossible overlaps that suggest two records were merged. Normalise every date to one format so downstream code is not guessing at day and month order.
• Job titles. Titles are free text and vary wildly, so normalise them to a consistent representation rather than writing whatever string the source returned. Flag titles that do not resolve to anything recognisable rather than trusting them blindly.
• Employer identifiers. Resolve the employer to a stable identifier, not just a display name, so "the same company" spelled three ways does not create three employers. This is what lets you dedupe and, later, detect when someone has actually changed jobs.

Field validation is not optional politeness. If you write an inaccurate employer or title, you have manufactured a liability under GDPR Article 16, which gives the candidate the right to obtain "without undue delay the rectification of inaccurate personal data" and to have incomplete data completed. Validating before the write is far cheaper than fielding rectification requests after it.

The third layer is legal, and it is where enrichment differs most from ordinary parsing. Enrichment is a new processing purpose, so it needs its own lawful basis under GDPR Article 6(1). You cannot piggyback on the basis you used to collect the original application. Of the six bases, two are realistic for enrichment: consent under Article 6(1)(a), or legitimate interests under Article 6(1)(f).

If you rely on legitimate interests, you have to run the balancing test. Article 6(1)(f) and the European Data Protection Board's guidelines on legitimate interest set out three cumulative conditions: there is a legitimate interest, the processing is necessary for that interest, and that interest is not overridden by the candidate rights and freedoms. Document the outcome, because you may have to defend it.

Then there is the duty most enrichment pipelines miss entirely. Because the data does not come from the candidate, GDPR Article 14 applies. You must tell the candidate the purposes, the legal basis, and, in the words of the regulation, "from which source the personal data originate, and if applicable, whether it came from publicly accessible sources". The information is due within a reasonable period after you obtain the data and at the latest within one month, or at your first communication with the candidate if that comes sooner. The source record from Layer 1 is exactly what this notice needs.

Validation is only half the job. The write itself has to be safe to repeat, because enrichment pipelines get re-run: a retried job, a backfill, a corrected source. If a re-run creates a second conflicting employer record, you have reintroduced the inaccuracy you just validated away. Dedupe by a stable candidate key so the same enrichment applied twice produces the same result, not a duplicate.

You also have to be able to prove all of this happened. GDPR Article 5(2), the accountability principle, requires the controller to be "responsible for, and be able to demonstrate compliance with" the data-protection principles. In practice that means logging, for every enriched field, the source, the validation result, and a timestamp. When a candidate or a regulator asks why a field says what it says, that log is your answer.

Finally, apply data minimisation and storage limitation. GDPR Article 5(1)(c) limits data to what is "adequate, relevant and limited to what is necessary", and Article 5(1)(e) says data should be kept "no longer than is necessary". Enrich only the employment fields you actually use, and expire or refresh enriched data on a schedule rather than letting stale facts sit on a profile indefinitely. That refresh loop is what keeps you on the right side of the accuracy principle over time.

Building all of this in house means owning source attribution, field normalisation, employer resolution, and a refresh loop, on top of the recruiting product you actually set out to build. That is the layer RecruitAI Suite provides as APIs you call from your own product. The Data Enrichment API returns current, structured employment data you can run through these validation layers before you write, and the Resume Parser API turns raw resumes into clean structured fields you can validate the same way. ATS and CRM teams can see how this slots in on the ATS vendors page, and the full set is on the product list.

For the surrounding context, the applicant tracking system API guide covers what an ATS API exposes and the obligations you inherit when you score candidates, and the ATS integration API guide covers reading and writing that data reliably at scale. When you want to try enrichment against your own data, you can book a demo for API access and a walkthrough.