Turkish IT Law Is Hard Because It Isn't in One Statute

There is no single answer to "what does Turkish IT law say about this," because there's no single statute called Turkish IT law. That's the first thing anyone working in this field learns, and it's the hardest thing to explain to a client.

In Türkiye, information-technology activity is regulated at the intersection of at least six separate statutes. None of them subsumes any of the others. Each operates on its own logic, with its own sanctions regime, and its own supervisory authority. The result: you cannot draw up a list of obligations by looking at one text, and the same event can produce consequences under more than one regime at the same time.

One data breach can show up in three separate places

A concrete example makes this clearest. Say an e-commerce company's customer database is accessed without authorisation and data is exfiltrated.

The first track is administrative. Article 12 of Law No. 6698 sets out data-security obligations, and its fifth paragraph requires the breach to be reported to the Board. The Board assesses whether the technical and organisational measures taken were adequate, and if it finds them lacking, it can impose an administrative fine.

The second track is criminal. The act of the person who gained access may constitute the offence, under Article 243 of Law No. 5237, of unlawfully accessing an information system, and exfiltrating the data may separately constitute the offence, under Article 136, of unlawfully providing or obtaining data. This investigation runs independently of the company's administrative liability.

The third track is private law. The individual whose data was exposed can claim compensation for the harm suffered — the final clause of Article 11 of Law No. 6698 expressly preserves that right.

These three tracks are not alternatives to each other; they run in parallel. Having paid the Board's fine doesn't end the criminal investigation, and the outcome of a criminal case doesn't itself settle a compensation claim.

What question does each statute actually answer

The most practical way to make sense of how fragmented this field is: work out which question each statute is actually answering.

Law No. 6698 answers "can you process this data?" Conditions for processing, the duty to inform, security measures and the data subject's rights are all here.

Law No. 5651 answers "who is responsible for this content?" The distinctions between content provider, hosting provider, access provider and mass-usage provider, and the procedures for content removal and access blocking, are set out here. The liability regime changes completely depending on which of these four roles a party falls into.

Law No. 5237 answers "is this act a crime?"

Law No. 6563 answers "can you send this commercial message, and what do you, as a service provider, have to disclose?"

Law No. 5070 answers "does this electronic signature stand in for a wet-ink one?"

On a real project, all of these questions usually come up at once. A decision made by looking at only one of them creates blind spots with respect to the other four.

Fragmented authority means fragmented oversight

What makes this even more complex is that different statutes are entrusted to different authorities.

The Personal Data Protection Authority supervises data-processing activity. The Information and Communication Technologies Authority has jurisdiction over electronic communications and is involved in enforcing access-blocking decisions. The Ministry of Trade is responsible for enforcing e-commerce legislation.

The practical consequence: a single product can be answerable to more than one regulator at once, and none of them is bound by another's decision. A favourable view from one doesn't stop another from reaching a different conclusion.

Where mistakes happen in practice

Most of the mistakes I see in this field share one thing in common: the legal assessment happens after the technical decisions have already been made.

The data model is built, tables are created, integrations are written. Just before launch, someone asks a lawyer to "take a look." By that point, options are limited, because anything raised now means retroactive correction — and retroactive correction creates a separate problem for data already collected up to that point.

Yet every one of the following questions could have been answered while the data model was being built. Which categories of personal data will be processed? What legal basis does each category rest on? What's the retention period, and what component enforces it? Which tables get touched when a deletion request comes in? Will there be a transfer abroad?

Five questions. All answerable in a single meeting. The cost of not answering them ends up being many times the cost of that meeting.

The field's real difficulty

The difficulty of Turkish IT law isn't that the rules are complicated. Read individually, they're understandable.

The difficulty is knowing the moment each one switches on. An engineer's decision — "let's log this field too, might be useful" — can trigger consequences under three separate statutes at once, and the person making that call usually has no idea. The way to close that gap isn't a thicker compliance binder. It's having a lawyer at the table when the decision gets made.