Why a Data Inventory Comes Before Every Other KVKK Document

Visit an organisation to help with KVKK compliance work and this is usually what's already in the folder: a privacy notice, a consent form, a retention and destruction policy. All three drafted, signed, filed.

Then one question gets asked. Where did the data categories listed in these documents come from?

The answer is usually: a template found online, the company's name filled in, a few clauses added. In other words, the statement wasn't derived from checking the facts — it was derived from a template. This is the most common, and most costly, sequencing mistake I see in compliance work.

Why the order matters this much

A privacy notice is a statement. Article 10 of Law No. 6698 requires the controller to disclose the categories of data processed, the purposes, the recipients data is transferred to, and the legal basis. If you're making a statement, it has to be accurate.

A notice written without an inventory can't be accurate. At best, it's incomplete. When an audit turns up a processing activity the notice doesn't cover, that isn't just a technical gap — it's a failure to properly discharge the duty to inform.

The reverse is also true. An organisation that already has an inventory writes the privacy notice in a day, because everything that needs writing has already been identified.

What the inventory actually needs to capture

Inventory tables usually get built with three columns: data category, purpose, retention period. Those three aren't enough.

The missing column is: where does this data physically sit? Which database, which table, which field? Is it in the backups too? Is a copy of it sitting in a third-party provider's system?

Without asking that question, the inventory reflects the organisation's own belief about itself, not the underlying reality. The first question asked after a data breach will be "what personal data was on that server" — and an inventory with no physical location recorded is useless at that moment.

Choosing a legal basis is an architectural decision

Article 5 of Law No. 6698 lists the grounds on which processing is permitted. In practice this article is often treated as a formality, but the legal basis chosen directly shapes how the system has to be built.

Where processing relies on explicit consent, that consent can be withdrawn at any time, and processing has to stop the moment it is. That makes three things necessary in the system: a record of which version of the notice the consent was given against, an interface that lets the user withdraw it, and a control that actually stops the relevant processing once consent is withdrawn. Without all three, relying on consent leaves the organisation in an indefensible position.

Processing that's necessary for performance of a contract doesn't need any of that machinery. The same piece of data, processed on a different legal basis, carries an entirely different technical burden. That's why the choice of legal basis should never be made by a lawyer alone, in isolation from the architecture.

Retention periods and the component that enforces them

Setting a retention period is the easy part of a compliance programme. Making sure it's actually applied is the hard part.

A working design looks like this: every record carries its own retention date — a retention_expires field, for example. A job runs on a schedule to find records past that date. The job deletes, destroys or anonymises the record, and writes its own action into a separate log table. What gets shown at audit isn't the policy document — it's that log.

Organisations without this structure typically do the opposite: they write the period into the policy, push implementation to some future date, and that date never arrives. Two years later, there's unerased data sitting alongside a document that says it should have been erased. Having both of those things at once is worse than having no policy at all.

The VERBİS register and its scope

The duty to register with the Data Controllers' Registry (VERBİS) depends on criteria the Board sets: annual staff numbers, balance-sheet size, and the nature of the data processed.

A caution is worth stating here. The scope of the exemption has changed over time through Board decisions and can change again. An organisation exempt today can become subject to the duty once its headcount grows. This isn't a question to settle once and forget — it needs checking annually, against the Authority's current published thresholds.

The breach plan gets written in advance

The fifth paragraph of Article 12 of Law No. 6698 requires a breach to be notified to the Board as soon as possible; Board decisions have fixed that period at seventy-two hours.

Those seventy-two hours are the total time available, once an incident is noticed, to scope it, identify affected individuals, and prepare the notification. Even the first of those steps takes days in most organisations, because there's no written record of what data sits where.

So breach preparation starts long before a breach happens, and it leads back to the same place: the inventory.

What happens once compliance is "done"

It doesn't finish. A new feature creates a new data field. A new supplier creates a new transfer. Board decisions narrow the framework.

That's why compliance works better built into the product-development process than run as a one-off project. If updating the inventory when a new field is added becomes part of code review, the process sustains itself. Otherwise, the work starts over every year, and the same sequencing mistake gets repeated each time.