Let’s be honest: applying for a job is not the most thrilling of tasks. It might start with a CV and a cover letter, or perhaps a long-winded application form, wading through question after question, designed to capture seemingly “boring” or “bland” routine information such as the applicant’s name, address, and what their passport number is.
Yet, for the employer, this process is essential. Beyond the routine details, the application process also serves as the first opportunity to catch or filter out any potential risky hires, or to assess at the earliest possible stage whether to progress an application forward or not. If the decision is made not to proceed there and then, it saves time for both the applicant and the employer, and both parties continue on their separate ways.
But what happens when a serious applicant declaration slips through the net?
This instalment of the Verification Chronicles shares a rather unbelievable recent case we encountered where failures within the hiring process, coupled with an unfortunate and rare accuracy lapse at the data source’s end, led to a convicted sex offender being employed as a supermarket delivery driver.
We’ll call him Alex.
He’d applied for a job as a supermarket delivery driver. The kind of everyday role that keeps people’s groceries, and lives, moving. His application form was ordinary enough: name, address, contact details, and that familiar question about criminal convictions. To his credit, Alex ticked yes. He had a record. And he said so.
That honesty should have been the very thing to pause the process. Yet, somewhere between form and follow-up, it wasn’t. The declaration went unnoticed.
So, Alex was invited to interview.
At that stage, another chance presented itself. A chance to ask questions, to discuss the disclosure, to show diligence. But once again, the detail slipped quietly past. Perhaps the interviewer didn’t spot it, perhaps they didn’t know how to handle it. Either way, the conversation moved on, and by the end of it, Alex had been offered the job.
By late March 2025, the supermarket had gone through what most would consider a solid vetting process. A basic criminal record check was submitted, and the result returned clear. A neat green traffic-light symbol on the report – one of thousands we see every week – confirming there were no convictions held on record.
That was that. Or so it seemed.
A few months later, the client came back to us. Alarmed, confused, and searching for answers.
They’d just discovered that Alex was, in fact, a convicted sex offender, serving a suspended sentence, and listed on the Sex Offenders Register. Understandably, they couldn’t reconcile that with the clear DBS result they’d received only weeks earlier. Something didn’t add up.
We investigated immediately. The DBS confirmed that Alex had indeed been convicted the previous October, but the conviction hadn’t been entered onto the Police National Computer (PNC) until May 2025. That’s seven months later.
Convictions are added to the PNC as they are reported by the courts. There was no good reason why months passed without Alex’s conviction appearing. Delays like this, though rare, can have serious consequences when roles involve public contact and trust.
When his check was processed in March, the PNC record still hadn’t been updated, meaning the DBS result reflected what the system knew at the time: nothing. The data was clean because the database was late.
It’s a rare occurrence, but a sobering one.
Convictions are supposed to be logged promptly by police forces and then uploaded to the PNC so the DBS can reference them. In this case, human error – or administrative delay – caused a serious disconnect. The system did what it was built to do; it’s the data feeding into it that failed.
We rely on source-verified data because it is, ordinarily, the gold standard. Accurate, objective, and trustworthy. But what happens when the source itself falters?
The employer, meanwhile, had done what they believed was right. They’d screened their hire, obtained a clear result, and carried on with business. They could never have known that a gap existed between reality and record. The revelation that followed must have been deeply unsettling: the person driving their customers’ groceries home each day was someone legally barred from contact with children.
It’s an outcome no employer ever expects and one no verification provider ever wants to see.
In reflecting on this case, it’s easy to point fingers. But the truth is more complicated. Mistakes like this often come from several small oversights aligning in the wrong order: a missed declaration, an unchecked interview note, a lagging database entry. Each alone might seem minor; together, they create risk.
Technology can help. Imagine if, when Alex ticked yes to that conviction question, the recruitment platform (ATS) automatically flagged his application for manual review or even locked further progress until someone had verified the detail. A visual red flag, a momentary pause, could have prevented all that followed.
Stories like Alex’s remind us why verification isn’t simply about running checks. It’s about understanding them. We can’t always control the accuracy of every external data source, but we can control how attentively we handle what we see, and how we design systems to catch what humans sometimes miss.
For us, this case reaffirmed what our work stands for: that safeguarding trust requires vigilance at every stage, from the first ticked box to the final hiring decision. Because in our world, even one small oversight can change everything.
We’ve talked in the past about how HR and recruitment teams have a responsibility to champion and promote a culture of compliance, and the importance of quality and accuracy within the hiring process. These attributes should be non-negotiable.
On the other hand, however, stories like this speak to, and reinforce, Verifile’s mission: to make the world a more honest and safer place. Achieving that requires everyone on the HR and recruiting side to play their part, from start to finish.