Hukuk ekibinden gelen telefondaki ses gergindi: iki hafta sonra veri koruma denetimi vardı ve "teknik taraf hazır mı" diye soruyorlardı. Kâğıt tarafı gerçekten hazırdı — aydınlatma metinleri yazılmış, envanter çıkarılmış, VERBİS kaydı yapılmış. Sonra biz eski bir yan servisin sunucusuna bağlanıp uygulama loglarına baktık: middleware, gelen her isteğin gövdesini olduğu gibi log dosyasına yazıyordu. TC kimlik numaraları, telefonlar, açık adresler — aylardır, düz metin hâlinde, log rotasyonuyla çoğaltıla çoğaltıla. Hukuk departmanının o dosyalardan haberi bile yoktu.
KVKK uyumu kâğıt üstünde hukuk departmanının işi gibi görünür; oysa cezaya dönüşen ihlallerin çoğu kod seviyesinde doğar. Loglara sızan kimlik verisi, süresiz saklanan üyelik kayıtları, üçüncü parti SDK'ya akan telefon numaraları... Bunların hiçbiri sözleşme maddesiyle çözülmez; mimariyle çözülür. Aşağıdaki çerçeve, kendi projelerimizde uyguladığımız hâliyle, verinin üç yaşam evresini takip ediyor: toplanırken, yaşarken, ölürken.
Veri kapıdan girerken: az al, doğru anlat, ayrı sor
İlk ilke minimizasyon ve itiraf edeyim, geliştirici refleksine en aykırı olanı bu. Hepimiz form tasarlarken "belki ileride lazım olur" diye alan ekleriz — doğum tarihi, ikinci telefon, meslek. KVKK'nın mantığı bunun tam karşıtıdır: toplamadığınız verinin sızması, kötüye kullanılması, silinmesi gerekmesi mümkün değildir. Yeni projelerde her form alanı için tek soru soruyoruz: bu veri olmadan hizmet verilemiyor mu? Cevap "aslında verilebilir" ise alan formdan da veritabanı şemasından da çıkıyor. En güvenli veri, hiç toplanmamış veridir.
İkinci ilke, aydınlatma metninin gerçek olması. Metin, uygulamanın gerçekten yaptığını anlatmalı — avukatın üç yıl önce yazdığını değil. En sık kopan yer şurası: geliştirici sprint ortasında bir analitik SDK ekler, kimseye haber vermez, metin eski kalır. Bizde bu kopukluğu önleyen şey release checklist'idir: "yeni SDK ya da veri akışı eklendiyse aydınlatma metni güncellenmeden yayın yok" yazılı bir maddedir ve uygulanır.
Üçüncüsü açık rızanın gerçekten açık olması. Üyelik şartlarının içine gömülmüş pazarlama izni hukuken geçersizdir; onay kutusu ayrı ve varsayılan olarak boş olmalı. Geliştiriciye düşen kısım ise kanıt: kullanıcının ne zaman, hangi metin sürümüne onay verdiğini kayıt altına alın. "Rıza aldık" demek yetmez; gösterebilmek gerekir.
Veri içeride yaşarken: loglar, erişim, üçüncü partiler
Girişteki log hikâyesine dönelim, çünkü orası gerçekten en yaygın sızıntı noktası. İstek gövdesini komple loglayan bir middleware, kullanıcının şifresini ve kimlik bilgilerini de loglar — logları gören herkes (geliştiriciler, log servisi, olası bir saldırgan) o verileri görür. Maskeleme sonradan eklenen bir özellik değil, log altyapısının kuruluş günü kararı olmalı: hassas alanlar (şifre, kimlik no, kart bilgisi) merkezi olarak tanımlanır ve log katmanı bunları yazmadan önce karartır.
Erişim tarafında hedef cümle şu: "Bu müşterinin verisine son üç ayda kim baktı?" sorusuna dakikalar içinde cevap verebilmek. Bunun gereği rol bazlı yetkilendirme artı erişim logu — yönetim panelindeki müşteri arama ekranı bile kayıt düşmeli. Abartı gibi mi geldi? Veri ihlali şüphesinde ilk sorulan soru tam olarak budur ve "bilmiyoruz" cevabının denetimde nasıl karşılandığını tahmin edebilirsiniz.
Üçüncü parti envanteri de bu evrenin parçası. Projenizdeki her SDK ve dış servis için üç soruya cevabınız hazır olsun:
- Hangi kişisel veriyi alıyor?
- Veriyi nerede işliyor — yurt dışı aktarımı var mı? (Çoğu bulut serviste var.)
- Aktarımın sözleşme ve mekanizma ayağı hukukla birlikte netleştirildi mi?
Bu envanteri çıkarmadan yaptığınız her beyan, temenniden ibarettir.
Bir de geliştirici günlük hayatının en gözden kaçan köşesi: test ve geliştirme ortamları. Üretim veritabanının kopyasını "gerçekçi test verisi lazım" diye staging'e, oradan geliştiricilerin dizüstülerine taşımak, sektörde hâlâ yaygın bir alışkanlık — ve her kopya, kişisel verinin korumasız bir nüshası demek. Staging ortamının parolası zayıftır, dizüstü kaybolur, eski çalışanın diskinde kopya kalır. Çözüm bilinen ama üşenilen şey: üretim verisi geliştirme ortamına inecekse maskelenerek iner, ideali ise sahte veri üretimidir (faker kütüphaneleri tam bu iş için var). Gerçek müşteri verisiyle test yapmayı bırakmak, uyum listesinin en ucuz maddelerinden biri.
Veri ölürken: silmek, gerçekten silmek demek
Önce saklama süresinin kendisi: "verileri ne kadar tutuyorsunuz" sorusuna "sonsuza kadar, disk ucuz" cevabını hâlâ çok duyuyoruz. Oysa her veri kategorisinin tanımlı bir saklama süresi olmalı ve bu süre koda yansımalı — elle hatırlanan silme takvimi, hiç silinmeyen veri demektir. Biz bunu zamanlanmış temizlik işleri olarak kuruyoruz: süresi dolan kayıtları düzenli tarayan, silen ya da anonimleştiren ve ne yaptığını raporlayan görevler.
Silmenin kalitesine gelince: buradaki en yaygın kandırmaca, hepimizin bildiği aktif=0 numarası. Soft delete bir yazılım deseni olarak meşrudur ama KVKK anlamında silme değildir; veri orada durmaya devam eder. Anonimleştirme yolunu seçecekseniz de çıta yüksek: işlem geri döndürülemez olmalı. Kullanıcı ID'sini hash'lemek anonimleştirme sayılmaz — hash'i kimin ürettiğini bilen herkes eşleştirmeyi geri kurabilir.
Ve unutulma hakkını uçtan uca test edin; bu, birim testi yazılabilen bir gereksinimdir. Üyelik silindiğinde sadece users tablosuna bakmayın: yedeklerde ne oluyor, log arşivinde ne kalıyor, arama indeksi (Elasticsearch vb.) hâlâ o kaydı dönüyor mu, e-posta servisine gönderilmiş liste ne olacak? Platformda silme akışını test ederken kullanıcının arama indeksinde aylarca yaşamaya devam ettiğini bulmuştuk — veritabanı tertemizdi, indeks unutulmuştu. Yedekler için de gerçekçi olun: geriye dönük her yedeği ayıklamak çoğu zaman teknik olarak makul değildir; kabul gören yaklaşım, yedeğin yaşam süresini sınırlamak ve geri yükleme yapılırsa silinmiş kayıtların yeniden silinmesini garanti eden bir prosedür yazmaktır.
Uyum sonradan yapılınca ceza, baştan yapılınca mimari
Bütün listenin damıtılmış hâli tek ilke: KVKK'yı proje sonunda hatırlanan bir doküman işi değil, ilk günden bir mimari girdi yapın. Tasarım aşamasında düşünülen uyum neredeyse bedavadır — bir kolon eksiltirsiniz, bir maske eklersiniz, bir log kararı verirsiniz; hiçbiri sprint planını sarsmaz. Denetim mektubuyla hatırlanan uyum ise ceza riski artı yeniden yazım faturası olarak gelir; ikisinin arasındaki fark, bazen bir sıfır bazen iki sıfırdır.
Mevcut sisteminizin bu üç evrede nerede durduğunu merak ediyorsanız, geliştirici gözüyle bir uyum taraması yapın; o tarama, hukuki denetimin göremediği katmanı görünür kılıyor. Girişteki o log dosyalarını hatırlayın — onları bulan hukuk ekibi değildi; sunucuya bağlanıp bakmayı akıl eden biriydi. Bu konuları tartışmayı severim; iletişim sayfası açık.