İletişim formu olan bir site bile kişisel veri işler. KVKK, verinin nerede tutulduğuyla değil nasıl işlendiğiyle ilgilenir; ama sunucunun konumu, aktarım kuralları ve denetlenebilirlik açısından doğrudan sonuç doğurur. Bu yazı hukuki görüş değil, teknik karar verirken kullanacağınız bir çerçevedir.
Hangi veriler kapsamda?
Kişisel veri, kimliği belirli ya da belirlenebilir gerçek kişiye ilişkin her türlü bilgidir. Web tarafında tipik olarak şunlar sayılır:
- Ad, soyad, e-posta, telefon, fatura adresi.
- Üyelik ve sipariş kayıtları.
- Sunucu erişim günlüklerindeki IP adresleri ve oturum kayıtları.
- Çerezler aracılığıyla toplanan davranış verileri.
Erişim günlükleri sık atlanır. Ham access.log dosyalarınız IP adresi
içerdiği için kişisel veri barındırır; saklama süresi tanımlamak ve gereksiz eskiyi
silmek gerekir.
Günlükleri baştan maskelemek
İhtiyacınız olan genelde kimin geldiği değil, nereden geldiğidir. IP adresinin son sekizlisini atmak istatistiksel değeri korur, kişiye ulaşılabilirliği düşürür. Nginx tarafında karşılığı şudur:
map $remote_addr $ip_maskeli { "~(?<ilk>\d+\.\d+\.\d+)\.\d+" "$ilk.0"; default 0.0.0.0; }
log_format maskeli '$ip_maskeli - [$time_local] "$request" $status $body_bytes_sent';
Saklama süresini de aynı yerde bağlayın. logrotate yapılandırmasındaki
rotate 60 satırı, günlük döndürmede altmış günden eski dosyanın silinmesi
demektir. Politikanızda "erişim günlükleri iki ay saklanır" yazıyorsa bunun teknik
karşılığı tam olarak bu satırdır.
Saldırı engelleme araçlarının ham IP'ye ihtiyacı olabilir; bu durumda ham günlüğü kısa, maskeli günlüğü uzun süre tutan iki ayrı akış kurun.
Yurt dışına aktarım
KVKK'nın 9. maddesi, kişisel verinin yurt dışına aktarımını belirli şartlara bağlar. 2024'teki değişiklikle standart sözleşme ve bağlayıcı şirket kuralları gibi araçlar kullanılabilir hale geldi, ancak bunlar da bildirim ve belge yükümlülüğü doğurur. Sunucunuz yurt dışındaysa, işlediğiniz kişisel veriler orada tutuluyor demektir; bu bir aktarımdır ve hukuki dayanağını belgelemeniz gerekir.
Sunucuyu Türkiye'de tutmak bu başlığı kökünden ortadan kaldırır. Uyum yükünü azaltmanın en basit yolu, aktarım yapmamaktır. Türkiye lokasyonlu altyapı tercih ettiğinizde, veri yerelliği tartışması denetimde gündeme bile gelmez.
Barındırma sağlayıcınız "veri işleyen" dir
Verinin amacını ve yöntemini siz belirlersiniz: veri sorumlusu sizsiniz. Barındırma sağlayıcısı sizin adınıza veriyi tutar; veri işleyendir. Bu ilişki yazılı olmalıdır ve sağlayıcınızdan şunları sorabilmelisiniz:
- Veriler hangi ülkede, hangi veri merkezinde tutuluyor?
- Yedekler nerede saklanıyor? (Yedeğin yurt dışında olması da aktarımdır.)
- Erişim yetkisi kimlerde, erişim kayıtları tutuluyor mu?
- Veri ihlali durumunda bildirim süreci nasıl işliyor?
- Hizmet sona erdiğinde veriler ne zaman ve nasıl siliniyor?
VERBİS kaydı
Belirli eşiklerin üzerindeki veri sorumlularının Veri Sorumluları Sicil Bilgi Sistemine kayıt yükümlülüğü vardır. Çalışan sayısı, yıllık mali bilanço ve işlenen verinin niteliği (özel nitelikli kişisel veri işleniyor mu) belirleyicidir. Muafiyet kapsamında olsanız bile aydınlatma metni, veri envanteri ve saklama-imha politikası hazırlamak yükümlülükten düşmez.
Kayıt yükümlülüğünü kanunun 16. maddesi düzenler, muafiyet ölçütlerini Kurul kararları belirler. Eşiklerin güncel hali ve sizin işletmenize nasıl uygulandığı için hukuk danışmanınıza başvurun.
Aydınlatma ile açık rıza aynı şey değildir
Sık karıştırılan iki kavram. Aydınlatma yükümlülüğü koşulsuzdur: hangi veriyi, hangi amaçla, hangi hukuki sebeple işlediğinizi ve kime aktardığınızı, veriyi topladığınız anda anlatmak zorundasınız. Açık rıza ise yalnız başka bir hukuki sebebe dayanamadığınız durumda gerekir ve özgür iradeyle, belirli bir konuya ilişkin ve bilgilendirilmiş olmalıdır.
Pratikte bu şu demektir: bir sipariş formundaki ad ve adres, sözleşmenin ifası için gereklidir; ayrıca rıza kutusu koymak gereksizdir ve rızayı sakatlar. Buna karşılık aynı formdaki "kampanya duyurusu almak istiyorum" seçeneği ayrı ve işaretsiz gelmelidir. Hizmet almanın ön şartı haline getirilen bir onay kutusu, özgür irade ölçütünü karşılamaz.
Veri ihlali olduğunda
Kurul, ihlalin öğrenilmesinden itibaren gecikmeksizin ve en geç 72 saat içinde Kuruma bildirim yapılmasını arar; ilgili kişilere de makul en kısa sürede haber verilir. Bu süre teknik ekibin hazırlıklı olmasını zorunlu kılar, çünkü 72 saatin büyük bölümü "ne oldu, hangi veriler etkilendi, kaç kişi" sorularıyla geçer.
Cevaplayabilmek için önceden hazır olması gerekenler: erişim ve yönetici işlem günlükleri, veri envanteri, sunucudaki kullanıcı yetki listesi ve iletişim kurulacak kişilerin listesi. Bunlar ihlal gününde toplanamaz.
Teknik tedbirler somuttur
Kurul kararlarında en sık atıf yapılan eksiklikler teknik ve idari tedbirlerdir. Web tarafında karşılığı şunlardır:
- Tüm trafiğin HTTPS üzerinden akması; sertifikanın geçerli ve güncel olması.
- Panel erişimlerinde güçlü parola ve iki adımlı doğrulama.
- Yetki ayrımı: her çalışana yalnız işi için gereken erişim.
- Yedeklerin şifreli tutulması ve geri dönüş provasının yapılması.
- Günlük kayıtlarının tutulması ve saklama süresi sonunda silinmesi.
- Güvenlik güncellemelerinin düzenli uygulanması.
Kendi sunucusunu yöneten işletmeler için bu maddelerin somut karşılığı ilk gün yapılan sunucu sertleştirmesidir: SSH anahtarına geçmek, gereksiz servisleri kapatmak, güvenlik duvarını yalnız gereken portlara açmak. Denetimde "hangi tedbirleri aldınız" sorusuna verilecek cevabın büyük bölümü bu adımlardan oluşur.
İdari taraf da yazılı olmalıdır: gizlilik taahhütnameleri, yetki matrisi ve personel işten ayrıldığında erişimlerin kapatılması yordamı.
Saklama süresi ve imha
Kişisel veri, işleme amacı ortadan kalktıktan sonra saklanamaz. Pratikte bu, her veri kategorisi için bir süre belirlemek ve süre dolduğunda otomatik silme kurmak demektir. İletişim formu kayıtları için altı ay, sipariş kayıtları için mevzuatın öngördüğü ticari saklama süresi, erişim günlükleri için birkaç ay gibi. Otomatik silme kurulmadığında politika kâğıt üzerinde kalır ve denetimde işe yaramaz.
Aşağıdaki tablo, sürelerin nereden türediğini gösterir. Rakamlar örnektir; kendi sürelerinizi mevzuat ve hukuk danışmanınızın görüşüyle belirleyin.
| Veri kategorisi | Süreyi belirleyen | Teknik karşılığı |
|---|---|---|
| İletişim formu kayıtları | İşleme amacı | Veritabanında zamanlanmış silme görevi |
| Sipariş ve fatura kayıtları | Vergi ve ticaret mevzuatındaki saklama süreleri | Arşiv tablosu, süre dolunca anonimleştirme |
| Erişim günlükleri | Güvenlik ihtiyacı | logrotate döndürme sayısı |
| Yedekler | Kurtarma hedefi | Yedek saklama politikasındaki gün sayısı |
| Silinmiş üyelik hesapları | İşleme amacının sona ermesi | Yumuşak silme yerine gerçek silme işi |
Yedekler burada en çok atlanan satırdır. Canlı veritabanından sildiğiniz kayıt, aylar öncesine ait bir yedekte durmaya devam eder. Yedek saklama süresini imha politikasıyla uyumlu tutmadığınız sürece silme işlemi yarım kalır. Aynı gerilim yedekleme tarafında da görülür: sürüm sayısı arttıkça kurtarma gücü artar, imha yükü de artar.
Alt yükleniciler zinciri
Kendi sunucunuz Türkiye'de olsa bile kullandığınız üçüncü taraf servisler veriyi yurt dışına taşıyabilir: analitik, canlı destek, e-posta pazarlama aracı, form servisi, ödeme sağlayıcısı. Envanterinizi çıkarırken sitenizin dış dünyaya yaptığı istekleri tarayıcının ağ sekmesinden listeleyin. Çoğu işletme, hangi verinin nereye gittiğini ilk kez bu listeyi çıkarırken görür.
Envanteri çıkarma yordamı
- Sitenin en çok kullanılan beş sayfasını tarayıcının ağ sekmesi açıkken gezin ve kendi alan adınız dışına giden tüm istekleri listeleyin.
- Her satır için üç soruyu cevaplayın: hangi veri gidiyor, hangi şirkete gidiyor, o şirketin sunucusu nerede?
- Sunucu tarafındaki dış çağrıları da ekleyin: ödeme sağlayıcısı, kargo entegrasyonu, SMS servisi, e-posta gönderim servisi. Bunlar ağ sekmesinde görünmez.
- Veritabanı tablolarını gözden geçirip hangi tabloda kişisel veri olduğunu işaretleyin.
- Listeyi yılda en az bir kez ve her yeni entegrasyondan sonra güncelleyin.
Bu çerçeve ne zaman yetmez?
Sunucuyu Türkiye'ye almak aktarım başlığını kapatır, uyumun tamamını değil. Özel nitelikli kişisel veri işliyorsanız (sağlık, biyometrik veri gibi), yurt dışı merkezli bir bulut servisini iş süreçlerinizin merkezine koyduysanız ya da yurt dışında müşteriniz varsa tablo değişir ve başka mevzuatlar devreye girebilir. Bu yazı hukuki görüş değildir; uygulama kararlarını hukuk danışmanınızla verin.
Uyum, tek seferlik bir proje değil sürdürülen bir işletim disiplinidir. Altyapı tarafında Türkiye lokasyonunu seçmek, bu disiplinin en az tartışılan ve en kolay uygulanan parçasıdır.
- #kvkk
- #uyum
- #veri yerelliği
