Kişisel Verilerin Korunması Kanunu (KVKK) 2016'dan beri yürürlükte, ama yazılım projelerinde hâlâ en sona kalan konu. Senaryo genellikle şöyle: ürün bitmek üzere, hukuk ekibi ya da danışman "aydınlatma metni nerede, veriler hangi ülkede, silme talebi gelirse ne olacak?" diye soruyor ve yayın tarihi kayıyor.
Oysa bu soruların çoğunun cevabı tasarım aşamasında verildiğinde maliyeti küçük, sonradan verildiğinde büyük. Bu yazı, müşteri verisi işleyen bir yazılımı yaptıran ya da geliştiren biri için başlamadan önce cevaplanması gereken maddeleri topluyor.
Bir not: bu bir mühendislik listesi, hukuki görüş değil. Şirketinizin durumu için bir KVKK danışmanı ya da avukatla çalışmak gerekir. Listenin amacı, o görüşmeye hazır gitmeniz ve yazılımın gerekli şeyleri yapabilecek şekilde kurulması.
1. Veri envanteri: ne topluyoruz, neden?
İlk soru hukuki değil, mimari: yazılım hangi kişisel verileri tutuyor? Ad, e-posta, telefon, adres, TC kimlik numarası, konum, cihaz bilgisi, satın alma geçmişi, destek yazışmaları. Hepsi kişisel veri.
Her alan için üç şey yazılı olmalı:
- Amaç. Bu veri neden toplanıyor? "İleride lazım olur" geçerli bir amaç değil. Amacı olmayan alan toplanmaz.
- Hukuki dayanak. Sözleşmenin kurulması, yasal yükümlülük, meşru menfaat ya da açık rıza. Her işleme için açık rıza gerekmez; sipariş için adres almak sözleşmenin gereğidir. Pazarlama e-postası göndermek ise değildir.
- Saklama süresi. Ne kadar tutulacak ve sonra ne olacak?
Bu tablo, veri sorumlusunun tutmak zorunda olduğu envanterin temelidir. Yazılım tarafında da işe yarar: veri modelini sadeleştirir. Pratikte envanter çıkarıldığında alanların bir kısmının gereksiz olduğu görülür.
Özel nitelikli veriler (sağlık, din, biyometrik veri, ceza mahkumiyeti gibi) ayrı bir kategori. Daha sıkı şartlara tabi ve çoğu projede hiç toplanmaması gerekir. Toplanıyorsa bu alanlar veritabanında ayrı tutulmalı, ayrı yetkilendirilmeli ve şifrelenmeli.
2. Aydınlatma ve rıza: ayrı şeyler
Sık karıştırılan nokta: aydınlatma her zaman zorunlu, açık rıza sadece diğer dayanaklar yoksa gerekli.
Aydınlatma, kişiye verisinin kim tarafından, hangi amaçla, kime aktarılarak ve hangi dayanakla işlendiğinin söylenmesi. Kayıt formunun yanında bir bağlantı, mobil uygulamada ilk açılışta bir ekran. Yazılım tarafında kolay; önemli olan metnin yazılımın gerçekten yaptığıyla örtüşmesi.
Açık rıza ise belirli bir konuya ilişkin, bilgiye dayalı ve özgür iradeyle verilmiş olmalı. Yazılım için anlamı:
- Önceden işaretli kutu olmaz.
- Pazarlama rızası ile hizmet şartları aynı kutuda olmaz.
- Rızanın ne zaman, hangi metin için, hangi kanaldan verildiği kaydedilir. Bu kayıt olmadan rıza ispatlanamaz.
- Rıza geri alınabilir ve geri alma, verme kadar kolay olmalı.
Rıza kaydı için ayrı bir tablo kurmak bir günlük iş. Sonradan eklemek, mevcut kullanıcıların hepsinden yeniden rıza istemek demek.
3. Çerezler ve üçüncü taraf araçlar
Web uygulamalarında analitik, pazarlama ve oturum çerezleri de kişisel veri işler. Zorunlu çerezler için aydınlatma yeterli; analitik ve pazarlama çerezleri için rıza alınmadan çerez yerleştirilmemeli. Yani çerez bildirimi "Tamam" düğmesinden ibaret olamaz.
Teknik tarafta en sık yapılan hata: rıza bandı var ama analitik betik sayfa yüklenirken zaten çalışıyor. Betikler rızaya bağlanmalı. Aynı şey mobil uygulamalardaki analitik ve çökme raporu SDK'ları için de geçerli.
4. Saklama ve silme: yazılım bunu yapabiliyor mu?
Saklama süresi dolan veri silinmeli, yok edilmeli ya da anonim hale getirilmeli. Bu, periyodik olarak yapılması gereken bir iş; "gerekince elle sileriz" işlemiyor.
Yazılımın yapabilmesi gerekenler:
- Süreye bağlı otomatik silme. Her veri tipi için saklama süresi tanımlı ve zamanlanmış bir görev süresi dolan kayıtları işliyor.
- Tek kişi silme. Bir kişinin talebiyle o kişiye ait verinin bütün tablolardan, dosya depolarından ve yedeklerin erişilebilir kısmından kaldırılması. Kullanıcı tablosundan satır silmek yeterli değil; sipariş, destek, log ve analitik kayıtları da var.
- Yasal saklama ile çakışma. Fatura bilgisi gibi vergi mevzuatı gereği tutulması zorunlu veriler silme talebinden etkilenmez. Yazılım bunu bilmeli: kişiyi anonimleştirip ticari kaydı korumak gibi.
- Anonimleştirme. Analiz için kullanılmaya devam edecek veride kişiyle bağ koparılır. "Adı sildik" anonimleştirme değildir; dolaylı olarak kişiye ulaşılabiliyorsa veri hâlâ kişiseldir.
Bu maddeler veri modelinde "bu kayıt kime ait" bilgisinin tutarlı tutulmasını gerektirir. Sonradan eklemek, her tabloyu tek tek gezmek demek.
5. Loglar ve yedekler
İki sessiz kişisel veri deposu: uygulama logları ve yedekler.
- Loglara e-posta, telefon, kimlik numarası, istek gövdesi yazılmamalı. Hata ayıklama için kullanıcı kimliği yeterli; gerisi maskelenir.
- Logların da saklama süresi olmalı. Sınırsız log, sınırsız kişisel veri demek.
- Yedeklerde silme talebini uygulamak pratik olmadığından yedeklerin saklama süresi tanımlanır ve süre sonunda yedek de silinir. Yedekten geri dönüşte silinmiş kişilerin geri gelmemesi için silme kaydı tutulur.
Erişim logları ayrı: kim, ne zaman, hangi kişisel veriye baktı. Bir ihlal incelemesinde ilk bakılan yer burası. Yönetici panelinde müşteri verisi görüntüleyen her işlem kayıt altına alınmalı.
6. Yurt dışı sunucu ve servisler
Veriler nerede? Bu soru sadece veritabanı sunucusu için değil, projede kullanılan her dış servis için sorulur: e-posta gönderim servisi, analitik, hata takibi, bulut depolama, yapay zeka API'leri, müşteri destek aracı. Bunların birçoğu veriyi yurt dışında işler ve her biri yurt dışına aktarım sayılır.
2024'teki kanun değişikliğiyle yurt dışına aktarım şartları yeniden düzenlendi; yeterlilik kararı, standart sözleşme ve bağlayıcı şirket kuralları gibi yollar geldi. Hangisinin geçerli olduğu hukuki bir karar. Mühendislik tarafının görevi, listeyi eksiksiz çıkarmak: hangi servis, hangi veri, hangi ülke. Bu liste yoksa hukuk ekibi doğru değerlendirme yapamaz.
Pratik seçimler:
- Veritabanı ve dosya depolama için Türkiye'de ya da aktarım şartı sağlanan bir lokasyonda sunucu seçmek çoğu projede en az sürtünmeli yol.
- Dış servise sadece gereken veriyi göndermek. E-posta servisine adres gerekir, satın alma geçmişi gerekmez.
- Yapay zeka API'lerine müşteri verisi göndermeden önce sağlayıcının veriyi eğitimde kullanmadığını ve nerede sakladığını yazılı almak.
7. İlgili kişi başvuruları
Kanun, kişilere verisi hakkında bilgi alma, düzeltme, silme ve itiraz hakları veriyor ve başvuruya belirli bir süre içinde cevap vermek gerekiyor. Yazılım bunun için şu işleri kolaylaştırmalı:
- Bir kişinin bütün verisinin tek yerden dökülebilmesi.
- Düzeltme ve silmenin yetkili kullanıcı tarafından, kayıt bırakarak yapılabilmesi.
- Başvurunun tarihi, konusu ve cevap tarihinin tutulması.
Bu işlemler elle yapılabilir, ama ilk başvuru geldiğinde "verisi hangi tablolarda?" diye aramaya başlamak süreyi tüketir. Dışa aktarma ve silme fonksiyonlarını baştan yazmak günler sürmez.
8. Güvenlik önlemleri ve ihlal süreci
KVKK, veri sorumlusundan uygun teknik ve idari tedbirleri bekler; neyin yeterli olduğunu veri türü ve risk belirler. Yazılım tarafında asgari liste:
- Aktarımda ve depolamada şifreleme, özellikle özel nitelikli ve kimlik verisinde.
- Rol tabanlı yetkilendirme: herkes her müşteriyi görmez.
- Gizli anahtarların koda ve depoya yazılmaması.
- Bağımlılıkların ve sunucunun düzenli güncellenmesi.
- Test ortamında gerçek müşteri verisinin kullanılmaması.
İhlal olursa, veri sorumlusunun öğrenmesinden itibaren kısa bir süre içinde Kurul'a bildirim yükümlülüğü var. Bu süreyi tutturmanın ön şartı, ihlali fark edebilmek: erişim logları, anormal sorgu uyarıları, dışarıya giden veri hacminin izlenmesi. Fark edilmeyen ihlal, bildirilmeyen ihlaldir.
Kısa kontrol listesi
Proje başlamadan şu maddeler cevaplanmış olmalı:
- Veri envanteri çıkarıldı: her alan için amaç, dayanak, süre.
- Özel nitelikli veri toplanıyor mu? Toplanıyorsa neden ve nasıl korunacak?
- Aydınlatma metinleri yazılımın gerçek davranışına göre yazılacak.
- Rıza kayıt tablosu tasarımda var.
- Çerez ve SDK'lar rızaya bağlanacak.
- Süreye bağlı silme, tek kişi silme ve anonimleştirme fonksiyonları kapsamda.
- Loglar maskelenecek ve süreli olacak; erişim logu tutulacak.
- Dış servisler listelendi: hangi veri, hangi ülke.
- Dışa aktarma ve başvuru kaydı fonksiyonları kapsamda.
- İhlal fark etme ve bildirim süreci tanımlı.
Sonuç
KVKK uyumu, projenin sonunda eklenen bir metin değil; veri modelinden sunucu seçimine kadar uzanan tasarım kararlarının toplamı. Baştan planlandığında toplam işe eklediği yük küçük. Sonradan eklendiğinde her tabloya, her entegrasyona, her kullanıcıya yeniden dokunmak gerekiyor.
Yeni bir projede ya da mevcut sistemde bu maddeleri birlikte gözden geçirmek için yazılım danışmanlığı sayfasına ya da iletişim sayfasına bakabilirsiniz. Hukuki değerlendirme için şirketinizin KVKK danışmanıyla birlikte çalışıyoruz.
