How is KVKK applied in recruitment?

For candidate data the data controller is the company that opens the posting. The software vendor is a data processor, meaning it stores and processes the data on the company instructions. This distinction is not cosmetic: whose name the privacy notice is issued under, who answers a candidate request and who accounts for it in an audit all follow from it. That is also why the text shown to the candidate is issued under your company name, not the name of the product.

The problem the software solves is this: most of what KVKK asks for is a record, not a document. The moment consent was taken, who saw the data, which field changed to what, when the record was deleted. Kept by hand in a spreadsheet, those fall apart in the first audit, because nobody writes down every single view.

The five steps below are jobs to be done in the panel. Two of them are done once at setup, three run continuously. The sections after that cover the records an audit will ask for, the places the data travels to and how candidate requests are met, one at a time.

• Once at setup: the privacy notice and consent texts, the role and permission matrix.
• Continuously: the limit on what you collect, checking the records, the deletion schedule.
• There is one thing the software never does on its own: deleting data whose period has expired.

Two separate checkboxes sit at the bottom of the application form: one confirms that the candidate has read and approved the KVKK privacy notice, the other that they have read and approved the explicit consent text on the processing of their personal data. The form is not submitted until both are ticked. Keeping them apart is a deliberate decision: the notice informs, while explicit consent is a separate declaration of will. Merged into a single box, what the candidate agreed to becomes unclear.

The full texts open from the link in the form and are assembled on the server. The data controller named inside them is always the company that opened the posting. Both approvals are written to the application record with a timestamp, so the answer to "when did this candidate consent" is the record itself, not an estimate produced after the fact.

If you have a text approved by your own lawyer, it replaces the default one word for word. There is no screen in the panel where you write it: the text is read from the company settings record, and none of the sections on the company settings screen show that field. Changing the text is work done on the setup side, so do not attempt it yourself, ask for it.

Purpose limitation is applied most cheaply on the application form. The stock form takes personal details, education, the CV file, the salary expectation and the start date. For a pre evaluation that is enough; if you add nothing, the form keeps working exactly as it is.

There is no national ID number and no IBAN anywhere on the application form. Those two fields are asked for only in the information step that follows the hiring decision, and they are written to the database encrypted with AES-256-GCM. The order is no accident: a form that asks for an ID number at application time has to store the ID numbers of rejected candidates too.

To add a question specific to one posting you use the Custom Application Fields section, at most 20 fields per posting. Every field you add is an item of personal data and falls under the storage, masking and deletion obligations. Before you add a question, do not ask whether it is useful, ask whether it is necessary to make this decision.

• A candidate CV is accepted only as a PDF, with a 5 MB file limit.
• Custom field answers appear in the application detail and in the context of the evaluation, which means they fall under masking as well.
• Candidates open no account to upload documents: a unique, time limited link is produced for each request, and the candidate can reach neither the panel nor the data of another record.

Seeing personal data unmasked is a permission of its own: pii:view. Every user without it gets the candidate name, email and phone masked. The permission belongs to the role, not to the user; you cannot say "let this person see just this candidate unmasked". If you want an evaluation done with identities kept hidden, you open a separate role for that person.

Setup brings four roles: CompanyAdmin (every permission), HRManager, Recruiter and Viewer. The last three carry no pii:view. So if you do nothing after setup, your HR manager sees candidate names masked. This is not a fault but a closed default, and if it goes unnoticed it gets read as a broken panel. You have to open the permission deliberately from the role screen.

Do not look for the permission under a KVKK or Privacy heading. Permissions are grouped module by module, and because this module has no display name defined, the group is listed with the raw code, that is as "pii". The single permission inside that group is named PII Görüntüle, described as unmasked viewing of personal data covered by KVKK.

Masking is not a blur on the screen but a cut made on the server. The list, the detail, candidate comparison, the pool summary, natural language search and the export endpoints all return the data masked. The blur on screen is a presentation layer on top of that, not the only defence. The difference matters: a user who opens the developer tools sees masked data too.

File access goes through the same gate. A masked user cannot open the CV or the transcript; the interface shows that the file is hidden instead of the file itself, and the server cuts access off on the grounds of the personal data restriction. Links issued for candidate files are signed and time limited: one hour by default, five minutes for the short path. An expired link works for nobody.

In AI evaluation the quotes taken verbatim from the CV count as personal data as well and drop for a masked user: semantic evidence, free text reasoning and item quotes come back empty, while the call and the score of the item remain. The audit trail is not lost, its content is hidden: which field changed, who changed it and when it changed stay visible, the old and the new value are hidden.

The most important limit in this guide sits here: the system does not delete candidate data on its own because a period expired, it does not anonymise it and it does not remind you. You set the retention period, you build the schedule into your own processes, you carry out the deletion from the panel by hand. A policy that is not tied to a calendar reminder stays on paper.

Deletion happens in two stages. An application deleted from the panel first drops into the trash; the record shows who deleted it and when, and it can be restored from there. Permanent deletion from the trash cannot be undone and takes the files with it: the CV and portfolio files, the document request files, the AI profile and the record itself go together.

On the storage side a deleted file does not disappear outright either: it is moved to the trash together with its reason and permanently deleted 30 days later. For files with no counterpart left in the database there is an orphaned files scan under Settings > Storage; the scan moves whatever it finds into the same trash.

What a data controller is asked is usually not "do you have a policy" but "what did you do about this person". The table below shows which record in the panel answers those questions, and what a masked user can see in that same record.

The last row is deliberate: the consent timestamp is written to the database, but no screen or export column in the panel shows it. The record is there, it just cannot be read from a screen. If an audit is going to ask for it, the setup side has to extract it; arrange that beforehand, not when the request arrives.

The most skipped part of a privacy notice is the list of sub processors. The answer is short: candidate CV files are stored with a cloud storage provider based abroad and sent to an AI provider based abroad for analysis. Beyond that, candidate data is not transferred to any third party.

The reason it is not transferred is an absence rather than a promise: the product has no LinkedIn, Indeed, HR information system or Slack integration. Because there is no channel to carry the data out, "we send it to nobody" is a sentence that can be verified. The day an integration is added, this section changes with it.

There are two more boundaries on the inside. The company boundary is enforced on the server, not in the interface: every read and write asks for the company identity as a parameter, and the service never guesses it. Candidates open no account to upload documents; a unique, time limited link is produced for each request and that link opens only the items of its own request.

• File links are signed and time limited: one hour by default, five minutes for the short path.
• For candidate data you are the data controller; the platform own privacy notice states that split of roles in writing.
• Evaluation does not learn from the past: who was invited or hired never enters the scoring, the data of one candidate never affects the score of another.

Once a candidate has applied, four kinds of request can reach you: asking what data you hold, asking for a correction, asking for deletion, and objecting to automated evaluation. All four have a counterpart in the panel, but three of them are run by hand.