KVKK: the operational duties of a data controller

In most organizations, Türkiye’s Personal Data Protection Law (KVKK) begins as a text on the legal team’s desk and ends as a task list on the IT team’s desk. The translation between the two is rarely done. This entry attempts it: the duties of a data controller, without legal interpretation, in the language of daily operations. What work is done, what input it needs, what evidence it produces. This entry is not legal advice; the organization’s legal function should confirm the scope of each duty in its own context.

What it means to be a data controller

The law names the party that determines the purposes and means of processing personal data as the data controller. A company is the data controller for its employees’ payroll data, its customers’ contact details and its visitors’ camera footage. Being a data controller is not a title but a set of continuous duties: ensuring data is processed lawfully, informing the people concerned, keeping data only as long as needed and then disposing of it, answering requests, notifying breaches, and being able to prove all of it.

Translated into operational language, these duties reduce to six workflows: inventory, privacy notices, retention and disposal, data subject requests, breach management and VERBİS registration. Each workflow has an input, an output and an evidence requirement. All six share the same input: knowledge of where the data actually is.

Inventory: where everything starts

The personal data processing inventory is the table in which the data controller records which data it processes, for what purpose, on what legal basis, from whom it is obtained and to whom it is transferred, and for how long it is kept. This table is the source of the VERBİS record, the privacy notice, the retention schedule and the answers to requests; if the inventory is wrong, all of them are wrong.

The operational difficulty of the inventory is that it rests on declarations. Forms sent to departments record what the respondent knows. Copies, archives, legacy systems and files left behind by departed employees do not make it onto the form. A discovery-based inventory reverses the problem: first what exists on disks, in databases and on collaboration platforms is found, then the data found is mapped to category, purpose and retention period. The difference list (in the inventory but not found, found but not in the inventory) is the inventory’s quality measure.

An example scenario: at a retail company the inventory shows customer data only in the CRM, while discovery shows the same data as campaign exports on a marketing share, as attached spreadsheets in a PST archive and as copied columns in a test database. Until the inventory is corrected to cover those three locations, neither the retention schedule nor the answer to a request can be complete.

Privacy notices and legal basis

The person concerned needs to know by whom, for what purpose and on what basis their data is processed, and what rights they have. Privacy notices are the vehicle for that information. The operational question is not whether the notice is well written but whether it matches the inventory. If the notice says “contact data is processed for marketing purposes” while discovery shows health data held in the same system, the notice is incomplete.

Legal basis is a column of the inventory as well. For each data category the basis relied on is recorded; for special-category data the basis is narrower, and among the Authority’s guides there is one dedicated to that set. Discovery provides two things here: it exposes data categories with no recorded basis (found but not in the inventory) and shows where special-category data accumulates. What the basis should be is the legal function’s decision; where the data is, is discovery’s output.

Retention and disposal

Data is kept for as long as the purpose of processing requires; when the purpose lapses or the period expires, it is deleted, destroyed or anonymized. The Authority’s page on the subject defines the three methods; which one is chosen depends on the medium and on the organization’s retention and disposal policy.

The operational flow is this: each data category is assigned a retention period, the period is tied to a schedule, a disposal task opens when the schedule expires, the task is assigned to an owner, approved, executed and recorded. The flow breaks in two places. First, when the retention period is unknown at file and record level; the expiry date of files in a folder cannot be calculated if the files are unlabelled. Second, when disposal is carried out only in the core system; copies and archives remain, and disposal has not taken place.

Anonymization deserves separate attention. Making data impossible to link to a person is not the same as deleting the name; if the combination of remaining fields can single the person out, anonymization has failed. A sound disposal flow therefore produces a redacted copy, destroys the original and measures the quality of the redacted copy with a uniqueness check.

Data subject requests

A person may apply to the data controller to learn whether their data is processed, to request information, correction or deletion, and to exercise related rights. The law requires these requests to be answered within a defined period; missing the period is a non-compliance in itself.

Operationally, the life cycle of a request consists of these steps:

1. Recording and identity verification. The request is received, time-stamped, and the applicant’s identity is verified.
2. Locating. The sources holding the person’s data are determined. Without current discovery, this is the longest step; searching the core system is easy, while searching archives and shared folders without discovery amounts to guesswork.
3. Response or action. For an information request a response is prepared; for a deletion request approved disposal is executed; for a correction request a task is opened in the relevant system.
4. Evidence. Which sources were searched, what was found, what was done and when the response was given are attached to the request.

The risk of missing the deadline arises mostly at the second step. If the location of the data is unknown, the search begins after the request arrives and every source is combed by hand. A discovery-based inventory reduces that step to a query.

Breach management

When personal data is obtained by unauthorized parties, the data controller is obliged to notify the Authority and the people affected. In October 2026 the Authority published several data breach notifications; those announcements show that notification is a current obligation for organizations, not a theoretical one.

At the moment of a breach, the first question is operational rather than legal: what data was on the affected system, how many people did it concern, in what category, did it include special-category data? Answered under pressure at the time of the incident, those questions are answered incompletely and late. If discovery was done beforehand, the answer is a report: this type of data on this server, in this access context. The breach record is tied to that report; the notification text rests on it.

The second operational need is keeping breach records in one place and time-stamped. Detection, assessment, notification and measures taken should form a chain; at audit time, the chain itself is requested, not the statement “we notified”.

The VERBİS record

The Data Controllers Registry is the registry kept by the Authority in which data controllers declare the categories of data they process, the purposes, recipient groups, retention periods and transfers. The Authority’s explanatory page describes the scope of the registration duty and its exemptions.

Operationally, the VERBİS record is the public summary of the inventory. Built from discovery, it reflects reality; built from a survey, it carries the survey’s omissions into the official registry. Keeping it current depends on the same mechanism: when a new data category is processed, a transfer to a new recipient group starts or a retention period changes, the record must be updated. Continuous discovery ties those changes to a scan rather than to someone remembering.

Duty	Operational work	Required input	Evidence produced
Inventory	Mapping category, purpose, basis, recipient, period	Discovery findings	Difference list, inventory version
Privacy notice	Matching the notice to the inventory	Inventory	Notice version, scope comparison
Retention and disposal	Schedule, disposal task, approval, execution	Labelled data, retention periods	Disposal record, uniqueness check
Requests	Recording, locating, response, evidence	Cross-source search	Request file, time stamps
Breach	Detection, assessment, notification	Data map of the affected system	Breach record chain
VERBİS	Keeping the record in sync with the inventory	Current inventory	Record version, update date

How Seratus closes these gaps

The common input of all six workflows is knowing where the data is; Seratus produces that knowledge and runs the workflows in the same console.

• The inventory resting on declarations. The VERBİS inventory is built from real discovery; “data missing from the inventory” is listed as a gap in the KVKK readiness score, and the difference list corrects the inventory (KVKK compliance, agentless DSPM).
• Not knowing where special-category data accumulates. The Turkish-specific detection engine finds health data (including ICD codes) with separate rules; the access and exposure graph surfaces the “special-category data in wide sharing” gap (Turkish detection accuracy, access and exposure graph).
• Retention periods that cannot be calculated at file level. Labels are tied to the retention schedule; “data past its retention period” is listed as a gap and enters the approved disposal flow. Disposal is carried out as a redacted copy plus destruction of the original, with quality measured by a uniqueness check (data classification, remediation and evidence).
• Searching sources by hand for each request. A data subject request is recorded, the person’s data is located across connected sources, a response or redacted copy is produced, approved disposal is executed and the evidence is attached to the request; “overdue request” is tracked as a gap.
• Not knowing what was on the affected system at breach time. The per-source detail report shows the data types and access context on the affected system; breach records and data protection impact assessments are kept in the same console; findings can be forwarded to a SIEM (integrations).
• Scattered evidence. The KVKK readiness summary, audit report and executive summary are produced as PDF, Excel or CSV; every action is in the audit trail with who, when and why. All of it runs on the organization’s own infrastructure, in an air-gap-compatible deployment (private LLM and air-gap).

Takeaway

Translated into operational language, a data controller’s duties come down to six workflows: inventory, privacy notices, retention and disposal, requests, breach management and VERBİS. All six rest on the same input: where the data actually is. When that input is produced by discovery rather than by a survey, each workflow turns from an exercise in remembering into a query, and every step leaves evidence. Legal interpretation stays with the organization’s legal function; Seratus produces the facts and the evidence that interpretation relies on. The next entry covers the Authority’s developments during 2026 and what they mean for data operations.