KVKK uyumu çoğu şirkette hukuk departmanının hazırladığı bir aydınlatma metniyle başlayıp orada bitiyor. Oysa uyumun büyük kısmı yazılımın içinde yaşıyor.
1. Veri envanteri
Hangi tabloda hangi kişisel veri var? Bu soruyu cevaplayamıyorsanız hiçbir uyum çalışması gerçek değildir. Şema seviyesinde etiketleme yapın: kimlik verisi, iletişim verisi, özel nitelikli veri.
Özel nitelikli veriler (sağlık, biyometrik, din, sendika üyeliği) ayrı muamele gerektirir — şifreleme ve erişim denetimi daha katıdır.
2. Saklama süresi
"Ne olur ne olmaz" diye sonsuza kadar veri tutmak KVKK'ya aykırıdır. Her veri türü için saklama süresi tanımlayın ve bunu otomatik uygulayan bir iş yazın:
- Aday CV'leri: genellikle 1-2 yıl
- Form kayıtları: amaç gerçekleştiğinde silinmeli
- Fatura ve ticari kayıtlar: vergi mevzuatı gereği daha uzun
- Sunucu logları: makul bir süre, sonra anonimleştirme
3. Erişim denetimi ve denetim izi
Kim, hangi kişisel veriye, ne zaman erişti? Bu sorunun cevabı loglanmalı. Sadece değişiklikler değil görüntülemeler de. Denetim kaydı, kaydı üretenin silemeyeceği bir yerde tutulmalı.
4. Log politikası
En sık gördüğümüz ihlal burada: uygulama logları içine TC kimlik numarası, telefon, adres ve hatta kart bilgisi düşüyor. Loglama katmanında maskeleme uygulayın; hassas alanlar log'a yazılmadan önce filtrelensin.
5. Test ortamları
Üretim veritabanının kopyasını test ortamına almak yaygın ve tehlikeli bir alışkanlık. Test ortamlarında gerçek kişisel veri bulunmamalı. Anonimleştirilmiş veya sentetik veri seti üretin — bir kez kurulduğunda sürekli işler.
6. Veri sahibi talepleri
Bir kullanıcı "verilerimi sil" veya "verilerimi ver" dediğinde ne oluyor? Bu işlem elle SQL yazarak yapılıyorsa sürdürülebilir değil. İki uç nokta yazın:
- Dışa aktarma: Kullanıcıya ait tüm veriyi okunabilir formatta üretir.
- Silme: Yasal saklama zorunluluğu olanları koruyarak diğerlerini siler veya anonimleştirir.
Yedeklerdeki veriyi de düşünün — silme talebi yedekleri nasıl etkiliyor, politikanız net olsun.
7. Açık rıza yönetimi
Pazarlama izni, çerez tercihi ve aydınlatma metni onayı ayrı ayrı ve zaman damgalı saklanmalı. "Kullanıcı onayladı" yetmez; ne zaman, hangi metnin hangi sürümünü onayladığı kayıtlı olmalı.
8. Üçüncü taraf aktarımı
Analitik, e-posta servisi, bulut sağlayıcı, yapay zekâ API'si — her biri veri işleyen taraftır. Envanterinizde listeleyin, yurt dışına aktarım varsa hukuki dayanağını netleştirin.
Sonuç
Bu maddelerin çoğu iyi mühendislik pratikleriyle örtüşüyor: az veri tut, erişimi sınırla, ne yaptığını kaydet. Uyumu sonradan eklenen bir katman değil, mimarinin parçası olarak kurgulayın.