KVKK, Turkish data protection law, turns employee monitoring into one software question: what a timekeeping record holds as identity, data read off a body or an identifier the employer can reissue. Which of the two fills that field is settled in the record model, before any code is written. The engineering objection that the reader stores a number and not an image settles a storage question, not the category of the field.
The question that brings most employers here is blunter. If the fingerprint reader at the gate comes out, what holds the timesheet up? A timekeeping entry carries three things: who, which site, which moment. None of those three answers requires the identity to have been taken from a body. Change the identifier and the record model stays where it is; the only thing that moves is the category of data sitting in the identity field.
The Personal Data Protection Board’s own sentences are set out below as the source states them. The legal assessment is not this article’s work, and the questions it does not answer are listed in the closing section and sent back to the source. A note on quotation: the announcements are published in Turkish, and the passages below are rendered in English here.
What the announcement actually assesses
A timekeeping record has a job that is easy to state: show who was at which site and for how long. Those three answers are the record’s own fields. How the identity was verified is not part of that job; it is the method chosen to do the job. The distinction looks small on paper and everything below rests on it.
The Board’s announcement on processing biometric data for timekeeping purposes carries that same distinction in its own sentences. It describes a trend: institutions turning in growing numbers to biometric identification systems in order to digitise employee attendance and improve security. It names what those systems are: biometric identification systems such as fingerprint, facial recognition, iris and retina scanning. And it states its reasoning: since there is no explicit statutory provision foreseeing that attendance be tracked through biometric identification systems, carrying out timekeeping by processing biometric data may constitute a breach of the law.
Read that sentence for its subject. The subject is not attendance recording; it is the data the record is made from. Any reading of how far the decision reaches belongs to the source text and to a lawyer. What is left for a software team is narrower and can be stated plainly: none of the three answers a timekeeping record gives has to be taken from a body.
We have a working arrangement where those three answers are produced without any biometric input. The article on logging entry and exit with the checks embedded in the record rather than in a fixed device sets out the mechanism in detail: an entry is created by scanning a printed code on site together with a location check taken at that moment. There is no reason to repeat it here. The question in this article is what that mechanism writes into the identity field.
One situation sits outside the frame. If the purpose is not a timekeeping record but controlling who enters a restricted area, the question changes with it: what is being asked there is not how long someone stayed but whether that person was cleared to pass. This article does not take that case, and how the announcements treat it is one of the questions sent to the source in the closing section.
A consent checkbox does not change the method
The first reflex is usually a form: have the staff sign something and consider the matter closed. The announcement meets that reflex in its own words. Its assessment is that even where valid explicit consent exists, the processing activity in question would not satisfy the proportionality criterion within the general principles of the Law.
It gives its reasoning in the same text. Because of the imbalance of power in the employer-employee relationship, there is doubt as to whether explicit consent rests on free will, and in that respect it does not on its own form a sufficient legal basis. The text goes one step further: where withholding consent could produce likely adverse outcomes for the employee, the employee cannot be said to have a genuine choice, and consent cannot then be said to rest on free will either.
Whether consent holds in an employment relationship is a legal argument, and this article does not run it. What is left for software fits on one line: a consent checkbox is a step placed in front of the record. One more screen enters the flow, the worker approves, and then the same finger goes on the same reader. The category of data entering the identity field is what it was before the approval and what it will be after. Consent is not a design decision about the data being processed; it is a gate placed in front of it.
The second reflex is more technical and usually comes from the engineering side: we do not store the fingerprint image, we store the mathematical value derived from it. The Authority’s second public announcement on the scope of the same principle decision answers that defence in its own sentence: storing the data in a database after converting it into a mathematical code does not remove its character as biometric data.
In software terms: the shape of the column does not determine the category of what is in it. Storing a numeric sequence instead of an image is a storage decision, not a decision about the data category. What determines the category is where the data came from.
What proportionality becomes at a design table
Proportionality is a principle in a legal text. Until it becomes a constraint on a design table, nobody knows what to do with it. The useful part of the announcement is that it splits the principle itself into three: the assessment is to be made separately in terms of the suitability of the method to the purpose (being connected to the purpose of processing), whether alternative methods have been exhausted (being limited to the purpose of processing), and the extent of the interference (being proportionate to the purpose of processing).
The middle criterion is the only one a software team can answer. Whether alternative methods have been exhausted becomes, at the design table, a single question: can the same three answers be produced from data that is not taken from a body? That question asks for no legal opinion. It asks someone to look at which fields the record carries.
An entry record has three fields and each one fills from a different source. In the construction site entry and exit system, where the scan establishes who and the location check establishes which site, the ‘who’ field is filled by the act of scanning, the ‘which site’ field by the location check taken at the moment of capture, and both land in a single entry record. The site name is never picked from a list by hand at any step.
The third field is never filled at all. ‘Which moment’ is the moment the record came into being, and hours worked come out of a matched entry and exit. How that derivation works is the neighbouring article’s subject; here the question is only which fields the record carries.
The difference collects in one place. On a fingerprint reader the ‘who’ field takes data drawn from the body; on the construction site the same field takes the scanning act of a person the system already knows. The other two fields are identical in both. When the method changes, the record loses no information; one field changes its data category.
This arrangement has a limit that cannot be written up as solved. An identifier that can be reissued can also be handed over: a phone can be given to someone else. The location check does not close that gap, because location confirms the site and not the person. The objection is real, and it sits in the table below as an open limit in its own row.
What identity is bound to: a body, a card, or a printed code
The announcement lists the alternatives itself. Its assessment is that timekeeping should be provided, instead of biometric identification systems, through alternative routes such as encrypted card or PIN based systems, traditional signature and paper attendance sheets, RFID/NFC identity cards, or manual entry under a supervisor’s oversight. The table below places these methods side by side. It does not say which one is good. It asks one thing: what is stored as identity, and can that data be reissued?
| Method | Identity data stored in the system | Can that data be reissued | Where the place check comes from | What gets rebuilt when the method changes |
|---|---|---|---|---|
| Biometric reader (fingerprint) | Biometric data taken from the body; converting it into a mathematical code does not change its character | No; a body cannot be reissued | The fixed point where the reader is installed; the site comes from the device’s identity | The device comes out; because the record was created on the device, its source changes too |
| Encrypted card or PIN based reader | A card number or PIN tied to the person record | Yes; a card is reprinted, a PIN is reset | The fixed point where the reader is installed | Reader and card stock come out; the person record stays, the record’s source changes |
| Printed QR code on site with the worker’s own phone | Who scanned; the identity input is the scanning act, with no measurement taken from the body | Yes; a worn code is reprinted, and a new one is produced for the next site | The location check at the moment of capture; the site name is never picked by hand | Nothing on site to dismantle; the record model stays as it is |
| Paper attendance sheet | A name written by hand on the sheet | No identifier to reissue; identity is the handwriting itself | The site name written by hand; no place input independent of the record | Carrier and fields change together; there is no identifier to carry over |
The third column separates the rows. A card is reprinted, a PIN is reset, and a printed code on a site wall is replaced when it wears out. There is no such operation for a body: once a fingerprint has been taken by someone else, no replacement can be issued. The sentence from the Authority’s second announcement earns its keep a second time here — converting the data into a mathematical code does not turn it into an identifier that can be reissued.
The last column shows the cost of switching, and it carries the widest spread between rows. If the record is created on the device itself, taking the device out changes where the record comes from. If the record is created on the worker’s phone, there is nothing on site to take out and the record model stays as it is.
The table rules nothing out. In a permanent facility with a single entrance and a settled crew walking through the same door every day, a fixed reader is a reasonable installation. The comparison covers installation, maintenance and what gets stored; it carries no legal assessment.
Location is personal data too: a continuous trail or a point at the moment of entry
Moving from biometrics to location looks like a way out, yet location is personal data as well. This section carries no legal assessment. The principle-decision announcement contains no statement about location data, so the distinction below is not drawn from the scope of the decision. It is a design question that comes out of reading what the record holds.
The question is where location gets written. In the construction site system, location is a field of the entry record. It is written into that record at the moment the record is created, it lands there together with the scan, and the site name is never selected by hand. How location establishes the site is set out in the turnstile article; the question here is where it sits in the record.
Collecting a location stream through the day is a different thing, and the difference is easy to see from the software side. An entry record has three fields: who, which site, which moment. Which of those three would a continuous location trail be written into? None of them. The record model has no field to take it; the trail accumulates somewhere else and adds nothing to the questions a timekeeping record answers.
None of this turns into a claim that nothing is held in between. What a system holds is read from its design, not inferred from the fields of one record. The question to put to a supplier is exactly that: which data is collected, at which moment, and where is it written.
There is a case where this framing breaks. If the work itself depends on the route taken through the day, a moment-of-capture model does not answer the question being asked. In delivery or field service, what is wanted is not how long someone stayed but where the vehicle went. At that point the purpose has stopped being a timekeeping record; it is a different purpose and it calls for its own assessment, outside this article.
What gets rebuilt if the reader comes out
The real cost worry comes from the system behind the device rather than from the device itself. If the reader comes out, does the whole timekeeping arrangement get built again?
Looking at the record gives the answer. A timekeeping record has four parts: who, which site, the entry moment, and the matched exit moment. Not one of those four dictates what kind of identifier goes into the identity field. Hours, the per-site breakdown, the month-end listing: all of them sit on top of those four parts and none of them asks what type the identifier was.
The answer does depend on where the record originates, and skipping that distinction would hand out a false assurance. If the record is created on the device, removing the device changes where the record comes from: the surface producing the record is now a different one, and how that surface connects to the system has to be built. If the record is created on the worker’s phone, what changes is not the source of the record but only the data category of one field.
The second case has a concrete form on the construction site. In the system we built there, nothing is mounted on site; the app runs on the worker’s own phone. When the site closes, no device has to be dismantled, moved, or parked in a store room. The only physical item left standing is the printed code, and a new one is produced when it wears out.
Where a record is created is a design subject of its own and sits outside this article. The arrangement in which the field record comes into being on the worker’s phone is covered separately; the only link that matters here is this one: because the record is created on the phone, no device is installed on site to be taken down later. The layer that moves verification off a fixed device and onto the phone a worker already carries is described under its own heading for the same reason.
One question stays unanswered in this section: what becomes of biometric data already held. Neither announcement takes it up, and it is not a decision made at a design table. That question goes to a lawyer.
Which questions belong to software, and which to a lawyer
The questions this article answers are narrow and countable. Which data is collected for a timekeeping record, at which moment it is collected, where it is written, and what gets rebuilt when the method changes. All four are answered by looking at the fields the record carries, and none of them needs a legal opinion.
The unanswered ones have to be named, because taking legal assurance from this article would be a mistake. Four headings go back to the source. The first is whether explicit consent holds in an employment relationship: the announcement makes its own assessment, quoted above in its own words, and the reading of it belongs to a lawyer. The second is what becomes of biometric data already collected, which neither announcement takes up. The third is whether high-security areas are treated differently; that heading does not appear in either announcement either, so saying here that an exception exists, or that it does not, would be putting words into a text that does not contain them. The fourth is sanctions, which is not the subject of the announcements.
All four land in the same place: the Board’s own text and a lawyer. Any answer a software team gives to them is an answer without a source.
What stays on the software side is concrete. Which fields a record carries, what a matched entry and exit produce, and what an entry whose exit never arrived actually is: these are design decisions, and they are made before any code is written. The arrangement that connects a site entry and exit record to the calculation done in the office comes from one question: is this information entered once, or written again at every layer? Which data goes into the identity field is the first link in that chain.
