Why candidate data is the hardest part of PDPL for HR
Most HR teams in Saudi Arabia think about PDPL in terms of employee records — payroll, medical notes, performance files. But the riskiest data in your HR software is usually the data you hold about people who never became employees: applicants, interviewed candidates, and CVs that arrived through a careers inbox or a recruitment agency.
This data is sensitive for three reasons. It is collected before any contractual relationship exists, so consent is doing all the work. It arrives in volume, often from multiple channels, which makes it easy to lose track of where a given CV actually lives. And it has a short natural life — a candidate who was not hired six months ago has no reason to remain in your system, yet deleting them is exactly the step busy teams skip.
PDPL does not ask HR to stop screening candidates. It asks HR to be able to explain, for every record, why it exists, who can see it, and when it goes away. That is a design question about your HR software, and it is answerable.
What does PDPL actually require for candidate data?
The law is built on a small number of principles, and each one maps to a concrete behaviour in your recruitment workflow.
First, lawful basis and purpose limitation. You need a clear basis for processing — typically the candidate's consent, given for a stated purpose such as "assessing your application for this role." That purpose matters: using a CV submitted for a finance role to market unrelated services, or to feed an internal talent pool indefinitely, is a different purpose and needs its own basis.
Second, data minimisation. Collect what the decision requires. National ID copies, salary history, marital status and full address are rarely needed at the screening stage, and each one increases the cost of a breach and the scope of your obligations.
Third, retention limits. Data should not be kept longer than the purpose requires. A defensible policy might be: active applications retained for the recruitment cycle, unsuccessful candidates retained for a defined short period, then deleted or anonymised — unless the candidate explicitly opted into a longer talent-pool retention.
Fourth, transparency and rights. Candidates should be able to ask what you hold, request correction, and withdraw consent. Those requests need an owner and a process, not an ad-hoc email thread.
How should consent be captured in an HR software workflow?
Consent that lives in a PDF policy document is not consent you can demonstrate. In practice, capture it at the point of collection and store it as a record, not as an assumption.
A workable pattern: when a candidate applies, the application form states the purpose of processing, the retention period, and how to withdraw consent — in Arabic and English. The candidate actively confirms. Your HR software writes a consent record: timestamp, version of the notice shown, channel, and the exact scope agreed. If the candidate later opts into a talent pool, that is a separate, separately recorded consent.
This is where generic applicant-tracking tools often fall short. They store a status flag ("consented: yes") but not the evidence behind it. When a regulator or an internal auditor asks what the candidate actually agreed to, the flag cannot answer.
A governed approach treats consent as immutable evidence. It should not be editable by a recruiter, and any withdrawal should create a new record rather than overwrite the old one — because the history of what was agreed, and when it changed, is itself part of your compliance position.
What does a defensible retention policy look like?
Retention is where good intentions meet operational reality. The policy is easy to write and hard to run, because deletion is invisible work: nobody is rewarded for removing records, and every recruiter has a reason to keep a promising CV "just in case."
Start by defining categories rather than a single number. Unsuccessful applicants, interviewed finalists, and candidates who explicitly joined a talent pool have different justifications and can reasonably have different retention windows. Write down each window and the reason for it.
Then make the policy executable. Retention rules that depend on someone remembering to run a manual cleanup will fail quietly. The stronger design is automated: records carry a retention date at creation, and the system flags or deletes them when it passes, with a log of what was removed and why.
Finally, handle the exceptions honestly. Legal holds, open disputes, and active roles legitimately extend retention. The point is that the extension is recorded and justified, not accidental. An auditor does not expect zero exceptions — they expect that every exception has a reason attached.
How do you build an audit trail that survives scrutiny?
An audit trail is not a login report. It answers four questions for any candidate record: who accessed it, what they did, when, and under what authority.
For recruitment, the events that matter most are: creation of the record and its source channel; every view of the CV or personal details; any change to status or notes; any export, download or share with a hiring manager or external party; consent capture and withdrawal; and deletion or anonymisation.
Two design choices make the difference between a real trail and a decorative one. First, logs should be append-only — if a recruiter can edit or delete the log, it proves nothing. Second, access should be role-scoped, so the trail shows a narrow, explainable set of people touching each record rather than "everyone in HR."
This is the same governance pattern that applies across enterprise AI: read-only-first access, human-in-the-loop decisions, and an auditable record of every action. It is not unique to HR, and it is not exotic — it is the baseline that Saudi enterprises are increasingly asked to demonstrate.
Where AI screening fits — and where the human sign-off stays
AI-assisted CV screening is now a realistic option for Saudi employers facing high applicant volume, and PDPL does not prohibit it. But it changes the governance questions you must answer.
Automated screening is still processing of personal data, so it needs the same lawful basis, minimisation and retention discipline as manual review. It also introduces two new requirements: candidates should not be subject to a decision made solely by automated means without a meaningful human review, and the logic that ranks or rejects candidates should be explainable enough that you can justify an outcome.
In practice, that means AI should shortlist and summarise, while a human recruiter makes and owns the decision. The agent's output — its ranking, its reasoning, the evidence it used — should be logged alongside the human's decision, so the full chain is reconstructable months later.
This is the model behind LeenAI's Smart Employment System (MasterHR): CV screening, shortlisting and candidate communication with human sign-off, PDPL-aware on candidate data, and bilingual Arabic/English from day one. The same governance posture — read-only-first, human-in-the-loop, audit-logged by design — runs through the rest of our agents, from OpsRAG for document-grounded answers to WhatsApp CX for candidate and customer communication.
A practical starting checklist for Saudi HR teams
If you want to know where you stand before a pilot or an audit, work through these in order:
- Map the data. List every channel a CV can arrive through, including agency inboxes and personal email. You cannot govern what you have not found.
- Rewrite the notice. One clear Arabic and English statement covering purpose, retention and withdrawal, shown at the point of collection.
- Define retention windows by candidate category, with a written reason for each, and automate the trigger.
- Scope access by role so the audit trail shows a narrow, explainable set of viewers.
- Make logs append-only and confirm they capture views, exports and deletions, not just logins.
- Name an owner for candidate rights requests, with a response process and a target turnaround.
None of this requires a year-long programme. It requires deciding what your HR software should record, then holding it to that standard. If you want to see how we scope a governed pilot with acceptance criteria and KPIs agreed up front, talk to us — or review how we price fixed-scope pilots before you commit to anything.
