Personal Data Retention Periods: An HR Guide

Why retention periods stay undefined

Personal data retention periods are one of the most commonly skipped decisions in HR. A personnel file gets opened, a payslip gets uploaded, dozens of resumes land in the system during a hiring round — but nobody asks how long that data should actually stay, or what happens once its purpose has passed. The result is a data pile that keeps growing and that nobody fully owns: an ID copy from an employee who left five years ago still sits on the server, a rejected candidate's application stays accessible for years with no one revisiting it.

That vagueness has a real cost. When an audit or a data subject request asks "why do you still hold this," and there's no answer, the company faces both legal exposure and a credibility problem. This piece walks through which HR data categories need which retention approach, what to do once a period ends, and how to make that enforceable in a system rather than just written down.

What data protection law does and doesn't tell you

Most personal data regulation, Turkey's KVKK included, doesn't hand you a fixed number of years for every data type. Instead it sets a principle: keep data only as long as the purpose it was collected for requires. That's not a convenience — it's a responsibility. For every category of data, HR has to be able to answer "why did we collect this, and when does that purpose end," and write the answer down as a retention and disposal policy. Some periods come from elsewhere — labor and social security law typically mandate a minimum retention period for payroll and personnel records — and where that applies, the sector-specific rule overrides the general principle.

In practice this means HR isn't managing one retention period. It's managing several, one per data category.

A category-by-category approach

Personnel files and payroll records

Identity documents, contracts, payslips, and social security records follow whatever period labor and tax law require, and that period usually extends past the end of employment, since a dispute or audit can surface years later. You can't shorten this retention, but you can narrow access: an archived former employee's file shouldn't sit at the same visibility level as an active team member's.

Location and timesheet data

Field staff GPS data needs a different logic than personnel records, because its purpose is periodic rather than ongoing: verifying attendance. Keeping raw location data indefinitely stops being proportionate to that purpose past a reasonable window — summarizing it and discarding the raw trail keeps both compliance and data volume manageable. We covered how to disclose this purpose to employees and structure consent in privacy and consent in field staff GPS tracking; the retention period belongs in that same disclosure, stated upfront.

Rejected candidates

This is the category most companies overlook. Once a hiring process closes, a rejected applicant's resume sitting in the system with no stated purpose is pure liability. A reasonable approach is to delete unsuccessful applications after a defined window unless the candidate has separately opted in to being considered for future roles — that opt-in needs to be explicit, not assumed.

Departing employees

An employee leaving doesn't trigger automatic deletion — as above, some records legally must persist. What should change is their footprint in the live system: they drop off the active roster, asset assignments and access get closed out, and only the records with a legal retention obligation remain, in an archived state.

Leave, advance, and expense requests

This category gets overlooked because it looks like "just an approval workflow." But the receipt photo attached to an expense request, or the justification text on a leave request, is personal data too. Once approved and reflected in accounting, how long these stay follows the general document retention period your accounting policy already sets — it's more consistent to tie this to that existing policy than to invent a separate number for it.

When the period ends: delete or anonymize

Two options exist once retention expires: delete the record outright, or anonymize it so it can no longer be tied to a person. When you still need aggregate insight — average staff turnover over past years, say — but no longer need anyone's identity attached, anonymization is the right call. When nothing about that person is needed anymore, deletion is cleaner. What matters is that this decision gets made per data category in advance; debating "what do we do now" once a period expires is a sign the policy was never really written.

Making it enforceable, not just documented

Writing a policy is step one, not the finish line — it needs a counterpart in the system itself. Three things matter in practice: knowing when each data category was collected, being able to narrow access by role, and having every change to a sensitive field leave a trace. HR-Tech keeps personnel files on two tiers — operational and health-related fields stay visible to the team, while identity and financial fields open only under manager-level access — so narrowing access isn't a sentence in a policy document, it's something the system enforces on its own. Every field change also lands in the audit log, so "when was this updated, who touched it" has an answer months later.

Common mistakes

Three patterns repeat. First, collapsing every data category into a single retention number — payroll and a rejected resume have no business following the same clock. Second, writing the policy but never backing it with any system-level control, so it stays a document nobody actually follows. Third, forgetting the deletion step entirely — data gets archived and never revisited, and the archive quietly fills with records that lost their purpose years ago.

Where to start

The first step is usually an inventory, not a tool: list every data category the system holds, what purpose it was collected for, and which regulation sets its minimum period. Without that inventory, neither the policy nor the system-level access and retention rules can be set correctly.

If you want to talk through how to make your HR data's retention and access policy enforceable in the system itself, get in touch; based on your current data inventory, we can work out which fields need which retention period and who should still have access.