Special Category Data and Biometrics: Where It Piles Up

Special category data is the kind of data organizations plan for least and accumulate most. A medical report, a biometric entry log or a disability declaration is never filed in something called the “special category data store”; it is filed in an HR folder, a SharePoint library, an email attachment, a side column of a payroll table. In 2026, the principle decision on biometric data issued by Türkiye’s data protection authority made clear that the question is not only how this data was collected, but where it remained afterwards.

Why special category data is a class of its own

The special-category provisions of Türkiye’s data protection law set health, biometric and genetic data, religion and sect, political opinion, union membership and criminal convictions apart from other personal data. The reason is the risk of discrimination or serious harm to the person if this data is exposed. Processing conditions are therefore narrower and security measures heavier.

The authority’s Guide on the Processing of Special Categories of Personal Data brings together measures such as limiting the staff who can access this data, logging access rights, encrypting data held electronically and protecting physical environments. The most important operational consequence of the guide is this: none of those measures can be applied without knowing where the data is. If access rights are to be restricted, the question of which folder, which library, which table has to be answered first.

This article is not legal advice. How the authority’s decisions and guide apply to your organization should be assessed with your legal function.

Decision 2026/921: what was said about biometric data

On 27 August 2026 the authority published a public announcement answering requests for opinion on Principle Decision 2026/921 of 29.04.2026 on the processing of biometric data for timekeeping purposes. According to the announcement, the decision was published in the Official Gazette on 2 June 2026 and covers only biometric processing carried out for timekeeping purposes.

The points that stand out in the announcement’s summary: processing biometric data solely for timekeeping rests on no processing condition; even with the employee’s explicit consent, proportionality is not satisfied. Fingerprint, vein and palm data are biometric data, and storing them converted into a code or template does not remove that character. In facilities carrying a high security risk, limited and proportionate use for access to critical areas remains possible. The decision covers only processing for timekeeping purposes; other purposes are outside its scope.

On 13 October 2026 the authority also held a webinar titled “Current Developments in Personal Data Protection: 2026 Principle Decisions and Public Announcements”, which discussed this decision alongside the year’s other developments.

The decision itself concerns the processing condition; the question this article is about, where the data piles up, lies outside it. But the operational consequence is plain. An organization that used a biometric system for timekeeping cannot simply switch the system off. The template files, entry logs, exported reports and backups the system produced over the years are sitting somewhere, and the organization has to find them and decide what to do with them.

Where biometric data remains

When a biometric access or timekeeping system is decommissioned, its database usually leaves the organization with the device. What does not leave is everything that accumulated around the system. Typical examples:

• Monthly exports from the timekeeping software: employee name, staff number, clock-in and clock-out times and, often, the template ID from the device, saved as a spreadsheet on the HR share or in the payroll folder.
• Device backups: the backup job the vendor set up copies the template database to a file server or an S3-compatible store; the job stops when the contract ends, the files stay.
• Enrollment forms: consent and enrollment forms collected from staff at installation, scanned to PDF and sitting in a SharePoint library.
• Mail archives: sample exports sent as attachments in correspondence with the vendor, kept in a PST archive for years.

What these copies have in common is that none of them is labelled “biometric data”. The file is called “timesheet_2023_03.xlsx”; the template ID column looks like a string of numbers. The record sits with far wider access than the system it came from ever had.

Where health data accumulates

In most organizations health data is both more widespread and more scattered than biometric data. The occupational health process alone produces several accumulation points: pre-employment and periodic examination forms, incapacity reports, occupational disease correspondence, medication and treatment declarations. These documents live in sub-folders named after employees inside the HR “Personnel Files” folder, or on the local disk of the occupational physician’s own computer.

The second large accumulation point is supplementary health insurance and benefits. Policy application forms hold chronic illness declarations, dependants’ health details and claims; email exchanges with the insurance broker carry the same information as attachments. The third is leave and absence: sick-note attachments, hospital printouts with ICD diagnosis codes, disability percentage certificates.

The ICD code deserves a special mention. ICD is the international classification of diseases, and a code placed next to a person states that person’s diagnosis explicitly. The code itself is short and structured, so it is easy to find in text, but found without context it also produces false positives: a product code or an order number can follow a similar pattern. The Seratus Turkish-specific detection engine evaluates ICD codes in context, assigns each finding a confidence percentage and shows a masked sample; the final decision is confirmed by a human. “Not found in the sample” is not a risk decision; it only says the pattern did not appear in that sample.

The “special category data overshared” gap

The most common operational gap around special category data is not its existence but its access scope. A medical report can sit in an HR folder; the problem is that the folder is readable by “Domain Users” or “everyone in the organization”. The gap appears in three forms:

Inherited permissions. A broad read permission granted on the parent folder years ago is inherited by every new personnel folder created underneath. The HR specialist who creates the folder does not think of it as granting access; the permission was not set, it was inherited.

Sharing links. An “everyone in the organization” link created to send a report attachment to a manager is forgotten once sent; the link stays valid until the file is deleted, and the file surfaces in search results even for people who never knew its path.

Departed users and orphaned access. The occupational physician who left has had their account disabled, but the folder from their local disk was moved to a share; the ACL on that share now points to a SID that cannot be resolved. The question “who can reach this” has no clear answer.

Seratus produces this combination, content classification joined with access information, as the finding “special category data overshared”. The finding appears in the list of gaps that lowers the KVKK readiness score and enters the remediation flow.

An operational plan: find, narrow, decide

A workable plan for special category data has three stages. The first is discovery: scanning file servers, local disks, Microsoft 365, databases, object storage and mail archives for health and biometric patterns and classifying what is found. At this stage the “health data” label has to be tied to its own confidentiality level in the taxonomy; otherwise an examination form and a canteen menu sit at the same level.

The second stage is narrowing access. For every finding, “who can reach this” is answered; inherited broad permissions, anonymous or organization-wide sharing links and unresolvable SIDs are listed. The permission removal, quarantine or masking action is assigned to an owner and executed under a separate approval right.

The third stage is the retention decision. For biometric exports whose purpose has ended, expired medical reports and duplicate enrollment forms, a disposal or anonymization flow is started. Each action is recorded with who, when and why. This stage puts, next to the sentence “we removed the biometric system”, the sentence “and we disposed of every record the system produced, on this date, with this approval”.

How Seratus closes these gaps

Gap: nobody knows where the biometric exports and backups are. Seratus agentless discovery scans SMB/NFS shares, Windows, Linux and macOS local disks, SharePoint, OneDrive and Teams files, S3-compatible stores and PST/OST/MSG archives over a read-only connection; an interrupted scan resumes where it stopped.

Gap: health data not separated from other documents. Classification tags each document by type, confidentiality level and business category; the health and biometric categories are tied to their own confidentiality level in the taxonomy and confirmed through human-approved correction. These tags feed retention and disposal directly.

Gap: false positives on ICD codes and health terms. The Turkish-specific detection engine runs an accuracy and false-positive reduction program for every rule; findings come with a confidence percentage and a masked sample.

Gap: special category data overshared. The access and exposure graph joins ACLs, sharing links and database roles with the content finding; “special category data overshared” appears in the KVKK gaps list.

Gap: unresolvable SIDs and departed-user access. The graph flags unresolvable SIDs, orphaned access and cyclic group memberships as separate findings; LDAP/directory synchronization keeps user and scope information current.

Gap: disposal without evidence. Permission removal, quarantine, masking and disposal are assigned to an owner, executed under separate approval rights (with a second approver where required) and written to the audit log; the KVKK readiness summary and audit report export as PDF, Excel or CSV. The flow is tied to the retention calendar in the KVKK compliance module.

Takeaway

Special category data accumulates not in the system that collected it but around that system: in exports, attachments, backups, folders opened under inherited permissions. Decision 2026/921 addresses the processing condition for biometric data; the organization’s operational task is to find where that data remained, narrow access to it and dispose of the rest with evidence. That task cannot be carried out without knowing where the data is.