Why does talent acquisition sit at the sharp end of PDPL?
Recruitment is the function that collects the most personal data about people who are not yet your employees. A single application can carry a national ID, contact details, employment history, salary expectations, references, sometimes health or family information volunteered in a cover letter. Under Saudi Arabia's Personal Data Protection Law (PDPL), that data is personal data, and the employer is the controller — accountable for why it was collected, who saw it, and when it was deleted.
Most HR teams already handle this well on paper. The difficulty appears when volume rises, when agencies and job boards sit between you and the candidate, and when screening tools are added to the funnel. At that point consent becomes ambiguous, retention becomes accidental, and the audit trail — the record that lets you answer a regulator, a candidate, or your own board — is scattered across inboxes and spreadsheets.
This guide sets out a practical operating model for talent acquisition under PDPL. It is written for heads of HR and talent acquisition who need faster, fairer, auditable hiring, and for the CIO or COO who has to sign off on the tooling.
What is a defensible lawful basis for candidate data?
PDPL does not treat all recruitment data the same way, and the lawful basis you rely on shapes everything downstream. For most of the funnel, consent is the cleanest basis: the candidate actively applies, and you capture a clear, specific statement of what you will do with their data and for how long. Consent must be informed, recorded, and withdrawable — a candidate who asks you to stop processing should be able to, without having to argue their case.
Some processing rests on other grounds. Assessing a candidate for a specific role you have advertised is generally tied to steps leading to a contract. Retaining a candidate in a talent pool for future roles, however, is a different purpose and usually needs its own consent, clearly separated from the application itself. Bundling the two — "apply now and we'll keep your CV forever" — is the pattern that creates exposure.
Practically, this means: one consent statement per purpose, versioned and dated, stored alongside the application record. When you later change your retention period or add a new screening step, the version history shows what the candidate actually agreed to at the time.
How long should you keep candidate data?
There is no single correct retention period, and any vendor who quotes you one is guessing. Retention should follow from the purpose. A useful starting model:
- Active applicants — retained for the duration of the recruitment cycle plus a short buffer for disputes.
- Rejected candidates — retained only as long as needed to demonstrate fair process, then deleted or anonymised.
- Talent-pool candidates — retained only with explicit, separate consent, with a defined expiry and a reminder before it lapses.
- Hired candidates — their recruitment record folds into the employee file under HR's own retention rules.
The operational failure is not the policy; it is the calendar. Retention only works when deletion is scheduled, owned and logged. If your ATS cannot trigger a deletion event and record that it happened, you have a policy, not a control. Data minimisation matters here too: if a screening step does not need a national ID or a birth date, it should not receive one.
What does an audit trail actually need to capture?
An audit trail is not a log file. It is the evidence that lets a human reconstruct a decision months later. For recruitment, that means answering four questions for any candidate: what data was collected and under which consent version, who or what accessed it, what decision was made and on what basis, and when the data was deleted.
That last point is where AI agents change the picture. If a screening agent ranks or shortlists candidates, the trail must record the agent's inputs, its output, the model or rule version used, and the human who reviewed and signed off. A shortlisting decision that cannot be traced back to a reviewer is a governance gap, whether or not any AI was involved.
This is the design principle behind LeenAI's Smart Employment System (MasterHR): candidate screening, shortlisting and communication run as a governed agent with human sign-off, PDPL-aware on candidate data, with the decision record written by default rather than reconstructed later.
How do you keep AI screening fair and explainable?
Fairness in AI-assisted hiring is not a claim you make; it is something you test. Three controls do most of the work. First, read-only-first: the agent reads and ranks, but cannot reject, message or move a candidate without a human action. Second, human-in-the-loop at the decision point: a recruiter reviews the shortlist and owns the outcome. Third, evals: a fixed set of test cases, run before go-live and re-run when anything changes, so you can show the shortlist behaves consistently across Arabic and English CVs and does not systematically disadvantage a group.
Explainability follows from the same discipline. A recruiter should be able to see why a candidate surfaced — which criteria matched, which did not — in language they can put in front of a hiring manager. If the system cannot produce that, it is not ready for a regulated funnel.
What should a 6–8 week recruitment pilot deliver?
A pilot should produce evidence, not enthusiasm. For talent acquisition, a defensible scope is one role family, one channel, and a defined set of KPIs — time-to-shortlist, screening accuracy against a human-reviewed sample, and candidate response time. The pilot should run with real data under real consent, not a synthetic demo.
At close, you should hold an Acceptance Pack: user acceptance testing signed off by recruiters, the eval results, runbooks for the retention and deletion jobs, and training for the team. That package is what a CIO needs to approve wider rollout, and what an auditor or regulator can be shown. If you want to see how we scope that, talk to us — or review how we price fixed-scope pilots before you commit.
The operating checklist
- One consent statement per purpose, versioned and dated, stored with the application.
- Retention periods defined by candidate status, with scheduled deletion and a deletion log.
- Data minimisation applied at the point of collection and again at the point of screening.
- Every access, ranking and decision recorded, including the human sign-off.
- Evals run before go-live and re-run after any change to the model, rules or criteria.
- A named owner for candidate data requests, with a response path that does not depend on one person's inbox.
None of this requires a year-long programme. It requires deciding the rules first, then choosing agents that operate inside them — read-only-first, human-in-the-loop, and audited by design.
