Web Siteleri için GDPR Uyumu: Uyumlu Bir Site Kurmak Gerçekte Ne Gerektirir

İnternetteki GDPR tavsiyelerinin çoğu ya avukatlar ya da hazır politika oluşturucu satın alacak kişiler için yazılmış. Bir editör açıp bir şeyi değiştirmesi gereken kişi için yazılanlar ise çok az.

Bu rehber ikinci türden. Genel Veri Koruma Tüzüğü'nün (GDPR) bir web sitesinden ve arkasındaki sistemlerden ne istediğini; geliştirdiğiniz, yapılandırdığınız veya sildiğiniz şeyler üzerinden anlatıyor. Bu işi, Tüzük'ün uygulanmaya başladığı 2018'den beri AB'de faaliyet gösteren şirketler için yapıyoruz ve o günden bu yana neyin yanlış gittiğine dair tablo neredeyse hiç değişmedi.

En baştan söylenmesi gereken bir şey var: GDPR, yeni düzenlemeler geldi diye kolaylaşmadı. Aksine daha önemli hale geldi; çünkü AB'nin yeni dijital kurallar dalgasındaki hemen her şey, kişisel verilerle ilgili işlerinizi zaten düzene soktuğunuzu varsayıyor.

Dürüst Bir Veri Envanteriyle Başlayın

Devraldığımız başarısız GDPR projelerinin neredeyse hepsi aynı noktada başarısız olmuştu. Ekip önce politikayı yazmış, verileri sonra keşfetmişti.

Her şeyden önce sitenizin gerçekte hangi kişisel verileri topladığını çıkarın. Ürün şartnamesinin topladığını söylediklerini değil. Veritabanında, loglarda, analitik platformunda, CRM'de, destek aracında, pazarlama otomasyonu altyapısında, hata izleme aracında, CDN loglarında ve sayfadaki üçüncü taraf betiklerde ne varsa onu.

Pratikte bu şu anlama geliyor:

• Şemayı tarayın. Bir kişiyi doğrudan ya da başka bir sütunla birlikte tanımlayabilecek her sütunu bulun.
• Gerçek bir sayfa yüklemesinde tarayıcının ağ sekmesini inceleyin. Kontrol etmediğiniz bir alan adına giden her istek potansiyel bir kişisel veri aktarımıdır; çünkü bir IP adresi ile bir tarayıcı kimliği (user agent) birlikte kişisel veridir.
• Hata izleme aracınızın neler yakaladığını kontrol edin. Yığın izleri (stack trace) rutin olarak e-posta adreslerini, belirteçleri ve istek gövdelerini içerir.
• Log saklama sürelerini kontrol edin. IP adreslerini içeren erişim loglarının süresiz saklanması en sık karşılaşılan bulgulardan biri ve düzeltmesi en kolay olanlardan biridir.

Bunu bir işleme faaliyetleri kaydı olarak yazıya dökün. 30. madde çoğu kuruluş için bunu zaten zorunlu kılıyor; mühendisler için işe yarayan sürümü ise sistemi, veriyi, amacı, hukuki dayanağı, saklama süresini ve alıcıları gösteren bir tablodur.

Hukuki Dayanağı Sisteme Göre Değil, Amaca Göre Seçin

Tüzük'ün 6. maddesi size altı hukuki dayanak sunuyor. En sık gördüğümüz hata, tüm ürün için tek bir dayanak seçmek.

Neredeyse kesin olarak aynı anda birden fazla amaç için veri işliyorsunuz. Bir siparişi yerine getirmek sözleşmeye dayanır. Dolandırıcılık kontrolleri genellikle meşru menfaat ya da hukuki yükümlülüğe dayanır. Faturaları yasal süre boyunca saklamak hukuki yükümlülüktür. Pazarlama e-postası çoğu Üye Devlet'te açık rızaya dayanır. Zorunlu olmayan analitik de açık rızaya dayanır; ancak bunun sebebi GDPR'nin kendisi değil, ePrivacy'nin uç cihaz erişimine ilişkin kurallarıdır.

Bunun pratik sonucu şu: veri modelinizin her kaydın hangi amaca hizmet ettiğini bilmesi gerekiyor. Pazarlama profilini sipariş kaydından ayıramıyorsanız, sipariş geçmişini bozmadan bir pazarlama itirazını yerine getiremezsiniz. Bu ayrım bir şema kararıdır ve sonradan uyarlanması zahmetlidir.

Açık Rıza Gerçek Olmalı ve Kayıt Altına Alınmalı

Açık rızaya dayanıyorsanız, rızanın özgür iradeyle verilmiş, belirli, bilgilendirilmiş ve açık olması gerekir; üstelik bunu sonradan kanıtlayabilmeniz gerekir.

Somut olarak:

• Kullanıcı bir işlem yapmadan zorunlu olmayan hiçbir şey çalışmamalı. Buna analitik kod parçacığı, reklam pikseli, sohbet aracı, üçüncü taraf bir CDN'den yüklenen yazı tipi ve A/B test betiği de dahil.
• Reddetmek, kabul etmek kadar kolay olmalı. Aynı katmanda, aynı belirginlikte, aynı sayıda tıklamayla. Düzenleyiciler bunun dışındaki her şeyi karanlık örüntü (dark pattern) olarak değerlendiriyor ve bu konuda tutarlı davrandılar.
• Rıza amaç bazında alınır. “Analitik, pazarlama ve kişiselleştirme” için tek bir anahtar, belirli bir rıza sayılmaz.
• Rızayı geri çekmek, vermek kadar kolay olmalı. Desteğe gönderilen bir e-posta değil, her zaman görünen bir bağlantı ya da yüzen bir düğme.
• Kanıtı saklayın: bir zaman damgası, rıza dizesi veya her kategorinin durumu, banner sürümü ve kullanıcıya gösterilen metin. Sürüm bilgisi olmadan iki yıllık bir rıza kaydını savunamazsınız.

Buradaki yaptırımlar teorik değil. Eylül 2025'te Fransız veri koruma otoritesi aynı gün çerez uygulamaları nedeniyle Google'a 325 milyon avro, Shein'e 150 milyon avro para cezası verdi. Her iki dava da politika metnine değil, işleyişe dayanıyordu: herhangi bir etkileşimden önce bırakılan çerezler ve aslında reddetmeyen reddet düğmeleri.

Bu konudaki kurallar da hareket halinde. Komisyon'un Digital Omnibus teklifi, uç cihaz erişimine ilişkin rızayı doğrudan GDPR'nin içine taşıyacak ve tarayıcı düzeyindeki sinyalleri bağlayıcı hale getirecek. Konsey ise ters yöne gidiyor: bildirildiğine göre 2 Ekim 2026 tarihli taslak müzakere metni, çerez rızasını ePrivacy Direktifi'nin 5(3). maddesinde tutuyor ve yeni GDPR maddelerinin ikisini de çıkarıyor. 10 Ekim 2026 itibarıyla Konsey bu pozisyonu henüz kabul etmemişti ve Parlamento ile görüşmeler başlamamıştı. Komisyon'un teklifinin neleri değiştireceğini Digital Omnibus sonrası çerez rızası yazımızda ele aldık.

İlgili Kişi Hakları Altyapısını Erkenden Kurun

15 ile 22. maddeler, kişilere verilerine erişme, düzeltme, silme, işlemeyi kısıtlama, taşıma ve itiraz etme hakkı tanıyor. Yanıt vermek için bir ayınız var; karmaşık durumlarda bu süre üç aya uzatılabiliyor.

Ekipler ilk birkaç talebi genellikle elle karşılar; bu yöntem işe yaramayı bıraktığı ana kadar işe yarar. Talep hacmi gelmeden çok önce sahip olmak isteyeceğiniz şeyler:

Bir kişiyi sistemler genelinde bulan bir çözümleyici. Bir e-posta adresi verildiğinde her şeyi döndürmeli: hesabı, siparişleri, destek taleplerini, pazarlama profilini, analitik kimliğini, logları. Bir insanın, veri tutan üçüncü taraf bir değerlendirme platformu olduğunu hatırlaması gerekiyorsa, eninde sonunda biri unutacaktır.

Saklama yükümlülüklerine saygı gösteren bir silme yolu. Silme hakkı mutlak değildir. Faturaların genellikle vergi nedeniyle saklanması gerekir. İhtiyacınız olan, amaca göre kapsamlandırılmış kalıcı silmeyle birlikte çalışan yumuşak silme (soft delete); böylece muhasebe kaydını korurken pazarlama profilini kaldırabilir, muhasebe kaydının da zamanı geldiğinde süresinin dolmasını sağlayabilirsiniz.

Taşınabilir bir dışa aktarım. Yapılandırılmış, yaygın olarak kullanılan, makine tarafından okunabilir. JSON uygundur. Görüntülenmiş bir HTML sayfasının PDF'i uygun değildir.

Tüm sistemin okuduğu bir itiraz işareti. Profillemeye itiraz, gece saat 3'te çalışan ve bu işareti kontrol etmeyen toplu iş dahil, profillemeyi gerçekten durdurmalıdır.

Saklama Süresi Bir Politika Satırı Değil, Bir İştir

Saklamanın sınırlandırılması ilkesi, diğer açılardan iyi kurulmuş sistemlerin en sık ihlal ettiği ilkedir; çünkü veriyi silmek, kimsenin istemediği bir işi birinin yazıp zamanlamasını gerektirir.

Her veri kategorisine tanımlı bir ömür verin, ardından bunu uygulayın. Erişim logları, oturum kayıtları, terk edilmiş sepetler, doğrulanmamış kayıtlar, kapatılmış destek talepleri, eski yedekler ve analitik ham verilerinin hepsinin bir son kullanma tarihi olmalı. Yedekler özel ilgiyi hak ediyor: geri yükleme süreciniz silinmiş kişisel verileri yeniden canlandırıyorsa silme işleminiz eksik demektir. Genellikle çözüm, azami yaşı belli, belgelenmiş bir yedek rotasyonu ve her geri yüklemeden sonra silme işlemlerinin yeniden uygulanmasıdır.

Aktarımlar, Alt İşleyenler ve Altyapınızın Gerçekte Nerede Çalıştığı

Avrupa Ekonomik Alanı (AEA) dışına yapılan aktarımlar hukuki bir mekanizma gerektirir: sertifikalı ABD'li alıcılar için genellikle EU-US Data Privacy Framework, diğer yerler için ise Standart Sözleşme Hükümleri ile birlikte bir aktarım etki değerlendirmesi.

Mühendislik açısı hukuki açıdan daha basit: verinizin fiziksel olarak nerede olduğunu bilin. Bu da her hizmetin bulut bölgesini, yedeklerinizin konumunu, yönetilen veritabanınızın bölgesini, CDN uç yapılandırmasını ve önemli olarak kullandığınız her SaaS aracının destek modelini bilmek demek. Frankfurt'ta barındırılan ama destek ekibi üretim ortamına AEA dışından erişen bir sağlayıcı da yine bir aktarımdır.

Aksi yönde güçlü bir neden olmadıkça kişisel verileri AB bölgelerinde tutmanızı genellikle öneriyoruz. Bu, bütün bir tartışma kategorisini ortadan kaldırır ve maliyet farkı genellikle önemsizdir.

Bir alt işleyen listesi tutun ve güncel tutun. 28. madde her biriyle yazılı bir veri işleme sözleşmesi yapılmasını zorunlu kılıyor; bu liste aynı zamanda müşterilerinizin durum tespiti (due diligence) sırasında isteyeceği şeydir.

Varsayılan Olarak Güvenlik: Yapılandırma Olarak İfade Edilmiş Hali

Tüzük'ün 32. maddesi uygun teknik ve idari tedbirler istiyor. Bu ifade bilerek belirsiz bırakılmış; ancak 2026'da bir web sitesi için asgari seviye belirsiz değil:

• Her yerde TLS, HSTS etkin, karışık içerik yok.
• Modern, bellek yoğun (memory-hard) bir fonksiyonla özetlenmiş parolalar ve kişisel veri tutan hesaplar için kullanılabilir çok faktörlü kimlik doğrulama.
• Veritabanları ve yedekler için durağan veri şifrelemesi.
• Üretim ortamındaki kişisel verilere erişimin role göre sınırlandırılması ve loglanması; incelemelerin de gerçekten yapılması.
• Mümkün olan yerlerde takma adlandırma: analitikteki tanımlayıcının özetini alın, eşleme tablosunu ayrı ve erişim kontrollü tutun.
• Yalnızca bir yedek değil, test edilmiş bir geri yükleme.

25. maddedeki tasarım yoluyla ve varsayılan olarak veri koruma, hiçbir şey yapmadan elde ettiğiniz seçeneğin gizliliği koruyan seçenek olması anlamına gelir. Bülten onay kutusu işaretsiz. Profil görünürlüğü gizli. İsteğe bağlı alanlar gerçekten isteğe bağlı.

İhlal Bildirimi Bir Uygulama Kılavuzu Gerektirir

İhlalden haberdar olunmasından denetim otoritesine bildirime kadar geçen yetmiş iki saat uzun bir süre değil; özellikle ihlal bir cuma akşamı fark edilirse. Digital Omnibus teklifinin bu süreyi doksan altı saate çıkaracağını da not edin; ancak bu henüz yasalaşmadı.

Önceden hazırlanın: bir olayı kim ilan ediyor, kişisel verilerin etkilenip etkilenmediğini kim değerlendiriyor, düzenleyiciyle kim iletişime geçiyor, bildirim neleri içeriyor ve risk yüksekse etkilenen kişilere nasıl haber veriliyor. Bunu rolleri adlarıyla belirlenmiş bir uygulama kılavuzu (runbook) olarak yazın ve bir kez prova edin. Kılavuzu ilk kullandığınız an, onu ilk okuduğunuz an olmamalı.

Web Sitesinin Kendisi

GDPR'nin bir kısmı sayfada görünür ve ayrıntıları doğru yapmaya değer; çünkü insanların şikâyet ettiği şeyler bunlardır.

Gizlilik bildiriminizin şunları belirtmesi gerekir: veri sorumlusunun kimliği ve iletişim bilgileri, amaçlar ve hukuki dayanaklar, alıcılar ve alıcı kategorileri, aktarım mekanizmaları, saklama süreleri, bir denetim otoritesine şikâyette bulunma hakkı dahil hakların tam listesi ve otomatik karar verme olup olmadığı. Bunu sıradan bir insanın takip edebileceği bir dille yazın. Ayrıntılara bağlantı veren kısa bir sürümle başlayan katmanlı bildirimler, bir metin duvarından daha iyi işler.

Formlar yalnızca ihtiyacınız olanı toplamalı. Her alan, gerekçelendirmek zorunda kalabileceğiniz bir şeydir. Pazarlama rızası onay kutusu siparişle aynı gönderim adımındaysa, ayrı olarak işaretsiz olmalı ve ayrı bir ifadeyle yazılmalı.

Üçüncü taraf gömülü içerikler sessiz bir başarısızlık kaynağıdır. YouTube gizliliği geliştirilmiş modda, haritalar tıklayınca yüklenen bir yer tutucunun arkasında, yazı tipleri üçüncü taraf bir CDN'den çekilmek yerine kendi sunucunuzda. Bunların her biri küçük bir değişiklik ve her biri bir bulguyu ortadan kaldırıyor.

En Sık Gördüğümüz Hatalar

Yeterince denetimden sonra aynı kısa liste karşımıza çıkmaya devam ediyor:

1. Rızadan önce yüklenen analitik; genellikle bir etiket yöneticisi pazarlama ekibi tarafından yapılandırıldığı ve mühendislik ekibi tarafından hiç incelenmediği için.
2. Üçüncü taraf bir betiğin varsayılan davranışı yüzünden yine de rıza tetikleyen reddet düğmeleri.
3. Hiçbir tabloda hiçbir saklama işinin olmaması.
4. Yedekleri, logları ve CRM'i atlayan silme işlemleri.
5. On sekiz ay önce değişmiş bir veri akışını anlatan bir gizlilik bildirimi.
6. Akla ilk gelen üç sağlayıcıda biten alt işleyen listeleri.
7. Gösterilen metnin sürümünü içermeyen rıza kayıtları.

Bunların hiçbiri zor problem değil. Yalnızca kimseye atanmamış işler.

Destek Almak

Mevcut bir siteye ikinci bir göz baktırmak isterseniz, rapor yerine önceliklendirilmiş bir iş listesi (backlog) üreten teknik GDPR denetimleri yapıyoruz: neyin düzeltileceği, hangi sırayla ve her kalem için bir tahminle. Yeni bir şey geliştiriyorsanız, veri modelini ve rıza mimarisini en baştan doğru kurmak çok daha ucuzdur.

Erişilebilirlik ve Avrupa pazarına giriş dahil daha geniş AB uyum konularında da çalışıyoruz. Bize office@c9group.dev adresinden ulaşabilirsiniz.

Biz yazılım geliştiriyoruz. Hukuki tavsiye vermiyoruz; herhangi bir gerekliliğin yorumu hukuk danışmanınıza aittir. Bizim yapabileceğimiz, sistemin hukuk danışmanınızın söylediğini yapmasını sağlamak.