A candidate you presented to two clients last spring emails on a Friday afternoon: under the GDPR she wants to see every piece of personal data you hold about her, who you shared it with and how long you will keep it. Her CV is in the Applicant Tracking System, interview notes sit in a consultant’s notebook, client feedback is in three mail threads and one phone screen was summarised in chat. This article explains how to answer a candidate data access request from your Applicant Tracking System: what the candidate is entitled to receive, how to log the request as tracked work with an owner and a deadline, which fields make the answer quick, how to handle notes that mention other people, and how to measure your response time with your own data. It is practical guidance for recruitment teams, not legal advice.
The request lands differently per segment. Recruitment agencies have to show which clients received a profile. Staffing desks hold large pools of candidates who registered once and placed several times. Secondment firms keep assignment history and client evaluations for years. Executive search consultants hold confidential notes on people who never applied. In-house recruitment teams answer applicants who were rejected and want to know why.
Why access requests go wrong when data is scattered
- Nobody owns the request, so the one-month deadline passes while the email sits in a shared inbox
- The answer lists the CV and the profile fields, but misses interview notes, scorecards and client feedback held elsewhere
- The team cannot say which clients received the profile, because submissions were sent from personal mailboxes
- The source of the profile is unknown, so the candidate who never applied cannot be told where you found her details
- Notes about other candidates or colleagues are copied into the reply without anyone checking them
An access request is a test of your records. If the Applicant Tracking System is the place where candidate work happens, the answer is mostly an export. If it is not, the answer is a search across every tool your desk has ever used.
What the candidate is entitled to receive
Under Article 15 of the GDPR, a candidate can ask for confirmation that you process their personal data and, if so, for a copy of it, together with supporting information:
- A copy of the personal data — profile fields, CV and documents, notes, interview outcomes, scorecards, assessment results and messages that are about the candidate
- The purposes — for example presenting the candidate for current vacancies or keeping the profile in a talent pool
- The recipients — the clients, hiring managers or other parties the profile was shared with
- The retention period — how long you keep the data, or the criteria you use to decide
- The source — where the data came from when the candidate did not provide it, such as a referral, a job board or a professional network
- Automated decisions — whether automated decision-making with legal or similarly significant effects is used and, if so, meaningful information about the logic involved; automated screening or ranking suggestions are worth describing even when a recruiter makes the final call
- The candidate’s rights — rectification, erasure, restriction, objection and the right to lodge a complaint with a supervisory authority
The reply is due without undue delay and at the latest within one month of receipt. That period can be extended by two further months for complex or numerous requests, but you must tell the candidate within the first month and explain why. The first copy is free of charge.
Where it lives: a tracked task on the candidate record
Log every access request in the Applicant Tracking System as a task on the candidate record, not as an email someone means to answer. The task needs a few fields:
- Date received — the day the request arrived, which starts the one-month clock
- Named owner — one person who collects, checks and sends the answer; usually the privacy lead or office manager, not the recruiter who happened to receive it
- Response deadline — calculated from the date received and shown as the next action date so the request cannot drift
- Identity check — how you confirmed the requester is the candidate, recorded before any data leaves the building
- Extension — if used, the reason and the date the candidate was informed
- Date sent and what was sent — so you can prove later what the candidate received
Requests also arrive by phone, through a client or via a colleague’s inbox. Whoever receives one logs it the same day, even if they are not the owner. The clock started when the candidate asked, not when the right person noticed.
Which fields make the answer quick
Most of what Article 15 asks for is information a disciplined desk already records. Each field below turns a search into a lookup:
- Source — a source recorded at first application answers where the data came from
- Submissions — every presentation to a client, sent from the Applicant Tracking System and backed by candidate consent before submission, gives you the list of recipients
- Retention — a retention date on the candidate record answers how long you keep the data
- Outcomes and reasons — a written interview outcome, standardised rejection reasons and a recorded withdrawal reason show what was decided and why, in words you are prepared to share
- One record per person — merging duplicates means the export is complete and you do not miss the second profile created by a colleague
The same discipline helps with the requests that often follow an access request: correcting a field, restricting use or erasing the profile. When the data lives on one record, each of those is one change instead of a hunt.
Notes that mention other people
A copy of the candidate’s data must not adversely affect the rights and freedoms of others. Recruitment records often do: a shortlist comparison names other candidates, a client email quotes a hiring manager, an interview note mentions a reference by name. Before sending, the owner reviews the export and removes or redacts data about other people, while keeping what is about the candidate. Interviewer comments about the candidate are generally part of the candidate’s data, so write them as if the candidate will read them one day. That is a good habit regardless of any request.
Keep a short internal note on the task explaining what was redacted and why. If the candidate questions the reply, you can show your reasoning rather than reconstruct it.
Common mistakes to avoid
- Answering with the CV only — the candidate asked for all personal data, including notes, outcomes and recipients
- No identity check — sending a full profile to an email address you have never seen is a data breach waiting to happen
- Deadline in someone’s head — without a date on the record, a busy month quietly becomes two
- Notes kept outside the Applicant Tracking System — personal files and chat summaries are still in scope; they just make you slower and less complete
- Asking for a reason — the candidate does not have to explain why they want their data
- Deleting during the request — erasing records after a request has arrived, and before you answer it, looks like hiding information; finish the reply first, then apply the retention date
Questions teams ask
- Do we have to include internal notes? — Notes about the candidate are personal data and are in scope; remove data about other people, not the notes about the requester
- The client also holds the profile. Who answers? — You answer for the data you hold, list the client as a recipient, and tell the candidate they can also ask the client for the data the client holds
- Can we send a portal link instead of a file? — A secure download or self-service view is fine if the candidate can actually access the full answer; record what was provided on the task
- What about a candidate who never applied? — The same rules apply; that is exactly why a recorded source matters for sourced profiles
Measure it with your own data
Count from your own records: how many access requests arrived per quarter, how many calendar days passed between receipt and reply, how many replies needed an extension, how often data had to be collected from outside the Applicant Tracking System, and how many requests were followed by a correction or erasure request. Report the number of requests behind each figure. Do not compare yourself with industry averages; your own counts show where your records are incomplete.
A practical start
- Create an access request task type on the candidate record with date received, owner, deadline, identity check, extension and date sent
- Name one owner for privacy requests and one stand-in for holidays
- Write a short checklist: confirm identity, export the record, add recipients, source and retention date, review for other people’s data, send, log
- Move notes and client feedback that still live in personal files onto the candidate record
- Review every closed request once: what was hard to find, and which field would have made it easy
An access request is a records check you did not schedule
A candidate asking for their data is asking whether your desk knows what it holds. Log the request on the record, give it an owner and a deadline, answer from the Applicant Tracking System and keep proof of what you sent. Explore the product or book a demo — we show how candidate records, sources, submissions and retention dates are set up in BoldATS for your segment. For how BoldATS itself handles personal data, see our privacy statement.