Turkey's Personal Data Protection Law, known as KVKK, has been in force since 2016, yet it is still the last topic to come up in software projects. The usual scenario: the product is nearly done, the legal team or an adviser asks "where is the privacy notice, which country holds the data, what happens when a deletion request arrives?" and the launch date slips.
Most of these questions are cheap to answer at the design stage and expensive to answer afterwards. This article collects the items that anyone commissioning or building software that handles customer data in Turkey should settle before starting.
One note: this is an engineering list, not legal advice. Your company's situation needs a KVKK adviser or a lawyer. The purpose of the list is to let you walk into that conversation prepared, and to make sure the software is built so it can do what will be required of it.
1. Data inventory: what do we collect, and why?
The first question is architectural rather than legal: which personal data does the software hold? Name, email, phone, address, national ID number, location, device data, purchase history, support conversations. All of it is personal data.
Three things should be written down for every field:
- Purpose. Why is this collected? "It might be useful later" is not a purpose. A field without a purpose is not collected.
- Legal basis. Performance of a contract, a legal obligation, legitimate interest, or explicit consent. Explicit consent is not needed for every operation; taking an address to ship an order is part of the contract. Sending marketing email is not.
- Retention period. How long is it kept, and what happens then?
This table is the foundation of the inventory a data controller must maintain. It also helps on the software side by simplifying the data model. In practice, once the inventory is drawn up, some of the fields turn out to be unnecessary.
Special categories of data (health, religion, biometrics, criminal convictions and similar) are a separate class. They are subject to stricter conditions and in most projects should not be collected at all. If they are, those fields should be stored separately, authorised separately and encrypted.
2. Privacy notice and consent are different things
A common mix-up: the privacy notice is always mandatory, while explicit consent is needed only when no other legal basis applies.
The notice tells the person who is processing their data, for what purpose, with whom it is shared and on what basis. A link next to the sign-up form, a screen on first launch in a mobile app. Easy on the software side; what matters is that the text matches what the software actually does.
Explicit consent must relate to a specific matter, be informed and be given freely. For the software this means:
- No pre-ticked boxes.
- Marketing consent and terms of service are not the same checkbox.
- When consent was given, for which version of the text and through which channel is recorded. Without that record, consent cannot be proven.
- Consent can be withdrawn, and withdrawing must be as easy as giving it.
A separate consent-log table is a day's work. Adding it later means asking every existing user for consent again.
3. Cookies and third-party tools
In web applications, analytics, marketing and session cookies process personal data too. For strictly necessary cookies the notice is enough; analytics and marketing cookies should not be set until consent is given. A cookie banner that consists of an "OK" button does not meet this.
The most common technical mistake: there is a consent banner, but the analytics script already runs when the page loads. Scripts must be gated on consent. The same applies to analytics and crash-reporting SDKs in mobile apps.
4. Retention and deletion: can the software actually do it?
Data whose retention period has expired must be deleted, destroyed or anonymised. This is a periodic job; "we will delete it by hand when needed" does not work.
The software needs to be able to:
- Delete on schedule. Each data type has a defined retention period, and a scheduled job processes records whose period has expired.
- Delete one person. On request, remove that person's data from every table, every file store and the accessible part of the backups. Deleting a row from the users table is not enough; there are orders, support tickets, logs and analytics records too.
- Handle conflicts with legal retention. Data that tax law requires you to keep, such as invoice details, is not affected by a deletion request. The software must know this: anonymise the person, keep the commercial record.
- Anonymise. Data that will continue to be used for analysis has its link to the person severed. "We deleted the name" is not anonymisation; if the person can still be identified indirectly, the data is still personal.
All of this requires the data model to track consistently "whose record is this". Adding it afterwards means visiting every table one by one.
5. Logs and backups
Two quiet stores of personal data: application logs and backups.
- Emails, phone numbers, ID numbers and request bodies should not be written to logs. A user ID is enough for debugging; the rest is masked.
- Logs need a retention period too. Unlimited logs mean unlimited personal data.
- Since applying deletion requests inside backups is impractical, backups get a defined retention period and are deleted when it ends. A deletion record is kept so that deleted people do not reappear after a restore.
Access logs are a separate matter: who looked at which personal data, and when. In a breach investigation this is the first place anyone looks. Every operation that displays customer data in the admin panel should be recorded.
6. Servers and services abroad
Where is the data? This question applies not only to the database server but to every external service in the project: the email delivery service, analytics, error tracking, cloud storage, AI APIs, the customer support tool. Many of these process data outside Turkey, and each one counts as a transfer abroad.
The 2024 amendment to the law reworked the conditions for transfers abroad, introducing routes such as adequacy decisions, standard contracts and binding corporate rules. Which one applies is a legal decision. The engineering side's job is to produce a complete list: which service, which data, which country. Without that list, the legal team cannot make a proper assessment.
Practical choices:
- For the database and file storage, choosing a server in Turkey or in a location where the transfer conditions are met is the path of least friction for most projects.
- Send external services only the data they need. The email service needs an address; it does not need purchase history.
- Before sending customer data to an AI API, get it in writing that the provider does not use the data for training and where it is stored.
7. Requests from data subjects
The law gives people the right to learn what is held about them, to have it corrected or deleted and to object, and requests must be answered within a set period. The software should make these jobs easy:
- Exporting all of one person's data from a single place.
- Corrections and deletions performed by an authorised user, leaving an audit trail.
- Recording the date, subject and response date of each request.
These can be done by hand, but starting to search for "which tables hold their data?" when the first request arrives burns the response period. Writing the export and delete functions up front does not take days.
8. Security measures and the breach process
KVKK expects the data controller to take appropriate technical and organisational measures; what counts as adequate depends on the data type and the risk. The minimum list on the software side:
- Encryption in transit and at rest, especially for special categories and ID data.
- Role-based authorisation: not everyone sees every customer.
- Secrets never written into code or the repository.
- Dependencies and servers updated regularly.
- No real customer data in test environments.
If a breach occurs, the data controller has a short window from learning of it to notify the Board. The precondition for meeting that window is noticing the breach at all: access logs, alerts on abnormal queries, monitoring of outbound data volume. A breach nobody notices is a breach nobody reports.
The short checklist
These items should be settled before the project starts:
- Data inventory done: purpose, basis and period for every field.
- Is any special-category data collected? If so, why, and how will it be protected?
- Privacy notices will be written to match the software's actual behaviour.
- The consent-log table is in the design.
- Cookies and SDKs will be gated on consent.
- Scheduled deletion, single-person deletion and anonymisation are in scope.
- Logs will be masked and time-limited; access logs will be kept.
- External services are listed: which data, which country.
- Export and request-logging functions are in scope.
- Breach detection and the notification process are defined.
Conclusion
KVKK compliance is not a text appended at the end of the project; it is the sum of design decisions reaching from the data model to the choice of server. Planned from the start, the extra work is small. Added later, it means touching every table, every integration and every user again.
To go through these items together for a new project or an existing system, see our software consulting page or the contact page. For the legal assessment we work alongside your company's KVKK adviser.
