Why does an applicant tracking system become a PDPL question?
An applicant tracking system (ATS) is not a filing cabinet. It is a decision engine that ingests CVs, contact details, salary expectations, assessment scores and interview notes — often for thousands of candidates a year, most of whom are never hired. Under Saudi Arabia's Personal Data Protection Law, every one of those records is personal data, and the employer is the controller responsible for how it is collected, used, shared and eventually deleted.
Most HR teams do not set out to mishandle candidate data. They inherit it. A spreadsheet here, a recruiter's inbox there, a WhatsApp thread with a shortlisted candidate, and a screening tool nobody remembers procuring. The result is data sprawl: candidate records living in five places with no single owner, no retention clock and no way to answer a simple question — who accessed this CV, and why?
That is the real governance gap. PDPL does not demand that you stop screening candidates quickly. It demands that you can explain, on request, what you hold, why you hold it, who has seen it, and when it will be erased. An ATS that cannot answer those questions is a liability, however efficient it looks on the surface.
What is a lawful basis for collecting candidate data?
PDPL expects a lawful basis for processing, and for recruitment the two realistic candidates are explicit consent and a documented legitimate interest tied to the hiring process itself. In practice, the cleanest approach is a layered one: a short, plain-language notice at the point of application that states the purpose, the categories of data collected, how long it will be kept, and how the candidate can exercise their rights.
Consent must be specific and informed, not buried in a wall of terms. A candidate ticking a box that covers "future opportunities, marketing and third-party sharing" has not meaningfully consented to any of them. Separate the purposes: applying for this role, being considered for similar roles later, and being contacted about unrelated services are three different decisions and should be three different choices.
Where you rely on legitimate interest — for example, retaining a strong candidate's file for a defined future window — document the balancing test. Write down why the interest is legitimate, why the processing is necessary, and why it does not override the candidate's expectations. That written reasoning is what turns a defensible practice into a demonstrable one.
How long should you keep candidate records?
Retention is where most ATS deployments quietly fail. The default behaviour of many systems is to keep everything forever, because storage is cheap and deletion feels risky. PDPL takes the opposite view: data should be kept no longer than the purpose requires.
A workable retention schedule is short and explicit. Active applicants are retained for the duration of the hiring process plus a defined notice period. Silver-medalist candidates — those you may want to revisit — are retained only with a separate, time-boxed consent. Unsuccessful applicants without that consent are deleted or anonymised on a fixed schedule. Assessment recordings, if any, follow the same logic and should expire sooner, not later.
The critical word is automated. A retention policy that depends on someone remembering to run a cleanup is not a control; it is an intention. Configure the ATS to enforce deletion dates, log the deletion, and report exceptions. When a candidate asks you to erase their data, the system should be able to action that request end-to-end and prove it happened.
What belongs in the audit trail?
An audit trail is the difference between claiming compliance and demonstrating it. For candidate data, the log should capture who accessed a record, when, from where, and for what stated purpose — plus every state change: screening decisions, shortlisting, rejection, sharing with a hiring manager, and deletion.
Access logging matters most for the sensitive steps. Who viewed the salary expectation field? Who exported a shortlist to a spreadsheet? Who overrode an AI-generated ranking? These are the moments where bias, leakage and unauthorised sharing actually occur, and they are exactly the moments a generic activity log tends to miss.
The trail should also be readable by a human. A log that only an engineer can interpret is not much use during a review. Aim for an export that a compliance officer, an internal auditor or a regulator can follow without translation — plain descriptions, timestamps, actor identities and the reason recorded at the point of action.
How do you use AI screening without losing control?
AI-assisted screening is where the governance question becomes sharpest, because the system is now making judgements about people, at scale, faster than any human could review. The safe pattern is read-only-first and human-in-the-loop: the agent reads, ranks and summarises, but a named human approves every shortlist and every rejection that reaches a candidate.
Keep the model's role narrow and explainable. It should surface evidence — relevant experience, matching skills, gaps against the job criteria — with citations back to the source CV, not issue a verdict. Where the agent communicates with candidates, that communication should be templated, bilingual and reviewable, with escalation to a human whenever the candidate's message falls outside the agreed scope.
This is the design LeenAI applies to its Smart Employment System (MasterHR), which handles CV screening, shortlisting and candidate communication with human sign-off and PDPL-aware handling of candidate data. The point is not to remove recruiters from the process; it is to give them a governed, auditable first pass so their judgement is spent where it matters.
What does a governed recruitment pilot look like in practice?
Start narrow. Pick one high-volume role family, define the acceptance criteria before any build begins, and measure against them. Typical criteria for a recruitment agent are time-to-shortlist, screening consistency against agreed job criteria, and the proportion of candidate communications answered within the target window — all measurable, all reviewable.
Governance is part of the deliverable, not a later phase. A pilot should hand over a working system plus the evidence that it behaves: user acceptance testing, evaluation results, runbooks for the retention and deletion jobs, and training for the recruiters who will operate it. LeenAI packages this as an Acceptance Pack on every pilot, so the compliance story is documented at go-live rather than reconstructed during an audit.
If you are weighing whether your current ATS can carry this load, the honest first step is a scoped review of where candidate data actually lives today. Talk to us about a fixed-scope pilot, and see how we scope and price engagements before committing to anything larger.
