Data subject requests under KVKK: the clock, the search, the evidence

A data subject request tests an organization’s data management under the hardest conditions: the clock is running, the person is identified, the data is scattered and the outcome must be proven. When a request is missed, the cause is rarely unwillingness; it is not knowing which systems hold the person’s data. This article walks through the request process, explains why the statutory deadline gets missed, and shows the operational path to finding the data across sources and answering with evidence.

This article is not legal advice; the response period, its exceptions and the grounds for refusal should be confirmed with your legal function.

What a request is and how the process runs

Under KVKK, Türkiye’s data protection law, a data subject may apply to a controller to learn whether personal data about them is processed, to request information if it is, and to ask for the data to be corrected, deleted or destroyed, among other rights. The Authority’s “Board Decision Summaries” page shows that complaints about how requests were handled reach the Board and are decided; the process is not merely an internal procedure but an obligation supervised by the Authority.

The process typically has five steps: receiving the request and verifying identity; registering and classifying it (information, correction, deletion); locating the person’s data in the organization’s systems; preparing and approving the response or the action (correction, deletion, anonymization); and delivering the response and keeping the evidence. Each step needs an owner, a time budget and a record.

The Law requires the controller to conclude the request within a set period. How that period is computed and when it may be extended is the legal function’s domain. The operation’s responsibility is to have done, in advance, the preparation that makes staying within the period possible.

Why the deadline is missed

Delays rarely accumulate in one step; small losses add up across the process. The first loss is late registration. The request arrives at a branch mailbox, in a call-centre note or by notarized letter, and takes days to reach the compliance team. The clock, however, started when the request reached the organization.

The second and largest loss is finding the data. The person’s data may be in the CRM, the payroll system, a support application, a contracts folder on a file server, a SharePoint library, the correspondence in a former employee’s PST archive and a backup in an S3 bucket. Asking a different department for each system, having each one search by hand and compiling the results consumes most of the period. If one system is forgotten, the response is incomplete, and an incomplete response is as risky as none.

The third loss is preparing the response. The documents found contain other people’s data: the counterparty in a contract, the other recipients of an e-mail, the other employees on a payroll list. Producing a redacted copy by masking these manually is both slow and error-prone. The fourth loss is approval: for a deletion request, which copy may be deleted and which must be kept under a legal retention obligation bounces between legal and the business.

Step	Typical cause of delay	Preparation that can be done in advance
Intake and registration	Request arrives through the wrong channel	Single registration point with timestamp
Locating	Systems searched by hand, department by department	Current discovery inventory; cross-source search
Preparing the response	Third-party data masked manually	Redacted copy generation
Approval	Scope of deletion debated	Retention calendar; label-bound rules
Evidence	What was done sits in scattered e-mails	Audit log attached to the request

Finding the data across sources

The precondition for answering a request is knowing where the person’s data is. That knowledge is needed at two levels. The first is the inventory: which systems hold which data categories? This comes from building the VERBİS inventory from real discovery, and it is ready before any request arrives. The second is the person level: in which files, tables and messages does this particular person’s national ID number, e-mail address, phone number or name appear?

The second-level search cannot be done without discovery infrastructure. Searching file servers, Microsoft 365, databases, object storage and mail archives by a person’s identifier requires a system that connects to each source read-only and has already indexed the content. The result must not be a bare “found”; it must say in which source, on which path, with which data type and at what confidence level, or the completeness of the response cannot be defended.

An example scenario: a retail company receives a deletion request from a former customer. The CRM record is deleted and a response is sent. Months later the same person complains to the Authority that they have received a campaign e-mail. The investigation finds the person’s data in an Excel list prepared for a marketing agency and left in a SharePoint library. The list was not in the inventory; nobody asked about it because nobody knew. A cross-source search would have found that copy at the first request.

The redacted copy and carrying out the action

For an information request, the response is a copy of the documents or records containing the person’s data, but that copy cannot disclose other people’s data. The redacted copy is the version in which identifiers that do not belong to the requester and information outside the request’s scope are masked. Masking should be performed by a detection engine that knows which data type it is looking at, and the result should be approved by a person.

For a deletion or destruction request, the action applies to every copy of the person’s data: the record in the production system, the export on the file server, the attachment in the mail archive, the row in the test database. Copies that must be kept under a legal retention obligation are identified through the retention calendar and labels, and the ground for refusal is recorded. The Authority’s page “Deletion, Destruction or Anonymization of Personal Data” frames the methods of deletion, destruction and anonymization; where anonymization is chosen instead of deletion, a redacted copy is produced, the original is destroyed and the result is measured with a uniqueness check.

Every action should be assigned to an owner and pass through a separate approval authority. Separating the person who proposes deletion from the person who approves it prevents both erroneous deletion and the situation where deletion was “reported done” but never happened.

Evidence: not what was done, but being able to show it

When the request is closed, the organization should hold the following: the date and channel of receipt, the identity verification record, which sources were searched and what was found, which action was proposed by whom and approved by whom, when the action was completed, which masking rules produced the redacted copy, and when the response was delivered. That chain is the organization’s only defence if a complaint reaches the Authority.

Evidence should live in one record bound to the request, not in scattered e-mails and personal notes. The audit log must answer who, when and why for every step and must be exportable. Missing evidence can lead to the same outcome as the action never having been taken.

How Seratus closes these gaps

Gap 1: Nobody knows which systems hold the person’s data. Seratus’s KVKK suite registers the request and searches for the person’s data across every connected source: file servers, local disks on Windows, Linux and macOS, Microsoft 365, Oracle, SQL Server, PostgreSQL/MySQL, S3-compatible storage and PST/OST/MSG archives. Connections are read-only and discovery runs without agents.

Gap 2: Searching by Turkish identifiers is unreliable. The Turkish-specific detection engine finds national ID numbers, phone numbers, e-mail addresses and IBANs in context; every finding is listed with a confidence percentage and a masked sample. In databases, “not found in the sample” is never presented as a risk decision; the finding status is stated explicitly.

Gap 3: The redacted copy is prepared by hand. Seratus produces the redacted copy by masking identifiers that do not belong to the requester; masking rests on classification labels and passes through human approval. An optional private, on-premises LLM enriches the request summary; no data goes to an external AI service.

Gap 4: The scope and approval of deletion are unclear. Deletion, destruction and anonymization actions are assigned to an owner and carried out under a separate approval authority. The retention calendar shows, through labels, which copies must be kept under a legal retention obligation; for anonymization a redacted copy is produced, the original is destroyed and quality is measured with a uniqueness check.

Gap 5: Overdue requests go unnoticed. The “gaps” list in the KVKK readiness score shows overdue requests as a separate item. Requests can be forwarded to SIEM and ticketing systems so that teams track them in their existing workflows.

Gap 6: Evidence is scattered. Every search, finding, redaction, approval and action is written to the audit log with who, when and why, and attached to the request. The audit report and source-level detail export to PDF, Excel or CSV.

Takeaway

A data subject request is a real test of an organization’s inventory and discovery infrastructure. The period is consumed by the time spent finding data; incomplete responses are born from unknown copies; evidence is lost in scattered e-mails. An organization that has run discovery before the request arrives, built its inventory from real findings and carries out every action with approval and a record closes the request within the period and in a defensible way. Seratus runs that process in one console, on the organization’s own infrastructure.