What GDPR and KVKK actually require from a website
Not a cookie banner. The obligations are mostly architectural, they are cheaper to build in than to retrofit, and about half of them do not apply if you simply stop collecting the data.
The banner is the smallest part, and usually the wrong one
Almost every site that adds a consent banner adds it wrongly: the banner appears, the analytics script has already run, and consent is collected after the thing it was supposed to gate. That is worse than having no banner, because it documents the violation.
The rule is simple and it is about order, not design. Nothing that is not strictly necessary may run before the visitor agrees. If your tag manager loads in the head, no banner in the world makes it lawful.
There is a third option people forget: collect nothing. A site with no analytics, no pixel and no third-party script needs no banner at all, because there is nothing to consent to.
What both laws actually ask for
GDPR and KVKK are separate laws with different regulators, but the engineering work they imply overlaps almost entirely. Build for the stricter of the two and you have satisfied both.
- A lawful basis for every piece of personal data you hold, written down before you collect it.
- Data minimisation: if you do not need the phone number to answer the enquiry, do not ask for it.
- A retention period per data type, and something that actually deletes when it expires.
- Export and erasure on request, within one month, without charging for it.
- A processor agreement with every third party that touches the data: your host, your email provider, your CRM.
- Breach notification within 72 hours, which means you need to be able to tell that a breach happened.
The part that costs money if you get it late
Retention and erasure are the two that hurt. A schema that never anticipated deletion turns a one-line legal request into a migration: rows referenced by orders, copies in backups, derived analytics tables nobody remembers building.
Design it at the start and it is a `deleted_at` column, a scheduled job and a documented backup window. Retrofit it after two years of production data and it is a quarter of work that produces no visible feature.
The single most useful artefact is a table: what data, why, where it lives, how long it stays. Most of the compliance work becomes obvious once it exists, and it is the first thing a regulator asks for.
Where this stops being engineering
Everything above is buildable and testable, and it is what we implement on a project. What none of it replaces is a lawyer who knows your sector and your jurisdiction, particularly if you handle health data, financial data or anything about children: those sit in the strictest tier of both laws and carry obligations no amount of good architecture discharges.
Treat the technical measures as the floor. They are necessary, they are the part that is expensive to add later, and they are not the whole of it.