KVKK ve GDPR Uyumlu Yazılım Geliştirme: Mimariden Teste Kontrol Listesi

Kişisel verilerin korunması çoğu zaman hukuk departmanının konusu olarak görülür; aydınlatma metni yazılır, sözleşmeye madde eklenir ve iş bitmiş sayılır. Oysa mevzuatın gerektirdiği ilkelerin büyük kısmı yazılımın mimarisinde karşılık bulmak zorundadır. Bu yazı, Türkiye'de 6698 sayılı KVKK, KKTC'de Kişisel Verilerin Korunması Yasası ve AB'de GDPR'nin ortak ilkelerini bir yazılım ekibinin kontrol listesine çevirir. Hukuki değerlendirme için mutlaka uzman desteği alınmalıdır; burada anlatılan teknik tarafıdır.

1. Veri envanteri: hangi alan kişisel veri?

Veritabanı şemasındaki her tablo ve sütun için "kişisel veri mi, özel nitelikli mi, ne amaçla işleniyor, ne kadar saklanıyor" bilgisi tutulmalıdır. Bu envanter, VERBİS benzeri kayıt yükümlülüklerinin ve veri sahibi taleplerinin temelidir. Pratik yöntem: şema içinde sütun yorumları ve ayrı bir veri sözlüğü tablosu.

comment on column employees.national_id is 'kişisel veri; amaç: bordro; saklama: iş ilişkisi + yasal süre';
comment on column employees.health_note is 'özel nitelikli; amaç: işyeri hekimi; erişim: yalnızca sağlık rolü';

2. Amaç sınırlaması ve veri minimizasyonu

Form tasarımında "belki lazım olur" diye alan eklemek, mevzuata aykırılığın en yaygın başlangıcıdır. Her alanın bir amacı olmalı; amaçsız alan toplanmamalıdır. Konum, fotoğraf ve biyometrik gibi hassas alanlar için ayrı bir gerekçe ve ayrı erişim kontrolü gerekir.

3. Saklama süresi ve otomatik silme

Saklama süresi bir belgede değil, sistemde tanımlı olmalıdır. Süresi dolan kayıtlar için otomatik anonimleştirme veya silme görevleri kurulur; silme işlemi yedeklerdeki kopyaları da kapsayacak şekilde planlanır (yedek saklama süresi ile uyumlu olmalıdır).

4. Erişim kontrolü: veritabanı seviyesinde

"Yalnızca yetkili erişir" ilkesinin güvenilir uygulaması, kuralın veride yaşamasıdır. PostgreSQL Row Level Security ile her sorgu kullanıcının yetki kapsamına göre süzülür; uygulama kodundaki bir hata, yetkisiz veriyi açığa çıkarmaz. Yönetici erişimleri ise süreli ve gerekçeli olmalıdır.

5. Şifreleme: aktarımda ve depoda

• Aktarımda TLS zorunlu; eski protokol ve şifre takımları kapalı.
• Depoda disk veya veritabanı seviyesinde şifreleme; özel nitelikli alanlar için ek sütun şifreleme değerlendirilebilir.
• Parolalar asla düz metin değil; güncel ve yavaş özetleme algoritmalarıyla (örneğin Argon2 veya bcrypt) saklanır.
• Anahtar yönetimi: anahtarlar kodda ve depoda değil, ayrı bir gizli bilgi yönetiminde tutulur.

6. Kayıt (log) ve denetim izi

Kişisel veriye kimin, ne zaman, hangi amaçla eriştiği kayıt altına alınmalıdır. Ancak kayıtlar da kişisel veri içerir: kayıt içeriğinde gereksiz veri (örneğin tam kimlik numarası) bulunmamalı, kayıtların kendi saklama süresi ve erişim yetkisi tanımlanmalıdır.

Uyum, bir metin değil bir davranıştır: sistem, veriyi gerektiği kadar toplar, gerektiği kadar saklar, gerektiği kişiye gösterir ve yaptıklarını kaydeder.

7. Veri sahibi hakları için teknik hazırlık

Erişim, düzeltme, silme ve taşınabilirlik talepleri geldiğinde sistem bunu makul sürede karşılayabilmelidir. Bunun için bir kişiye ait tüm verinin hangi tablolarda olduğu bilinmeli (envanter), dışa aktarım fonksiyonu bulunmalı ve silme talebinin yasal saklama yükümlülükleriyle (örneğin muhasebe kayıtları) çakıştığı durumlar için anonimleştirme yolu tanımlanmalıdır.

8. Üçüncü taraflar ve veri aktarımı

SMS, e-posta, ödeme, harita ve analitik servisleri birer veri işleyendir. Her biri için sözleşme, veri işleme yeri ve gönderilen alanların listesi tutulmalıdır. Yurt dışına aktarım, mevzuata göre ek şartlara tabi olabilir; servisin sunucu konumu bu nedenle teknik değil hukuki bir karardır.

9. Güvenli geliştirme pratiği

OWASP Top 10 ve OWASP ASVS, kişisel veri sızıntılarının çoğunun kaynağı olan uygulama açıklarını kapsar: kırık erişim kontrolü, enjeksiyon, güvensiz tasarım, yanlış yapılandırma. Kod incelemesi, bağımlılık taraması ve yetki politikalarının otomatik testi bu başlıkların düzenli kontrolünü sağlar.

10. Test ve demo verisi

Gerçek kişisel verinin test ortamına kopyalanması yaygın ve riskli bir alışkanlıktır. Test ortamları sentetik veya anonimleştirilmiş veriyle çalışmalıdır; bu aynı zamanda geliştirme ekibinin gereksiz erişimini ortadan kaldırır.

Özet kontrol listesi

1. Veri envanteri ve sütun bazlı sınıflandırma
2. Amaçsız alan yok
3. Saklama süresi sistemde, otomatik silme/anonimleştirme
4. Veritabanı seviyesinde erişim kontrolü
5. Aktarımda ve depoda şifreleme, güvenli parola saklama
6. Denetim kaydı (kendi saklama kuralıyla)
7. Veri sahibi talepleri için dışa aktarım ve silme yolu
8. Üçüncü taraf envanteri ve aktarım değerlendirmesi
9. OWASP temelli güvenli geliştirme
10. Anonim test verisi

Rıza ve aydınlatma: arayüzde nasıl görünür?

Hukuki dayanağın "açık rıza" olduğu durumlarda rıza kaydı sistemde tutulmalıdır: ne zaman, hangi metinle, hangi amaç için, hangi kanaldan alındı; geri çekildiyse ne zaman. Aydınlatma metinleri sürümlenmeli ve kullanıcının hangi sürümü gördüğü kaydedilmelidir. Önceden işaretli onay kutuları, zorunlu alanla birleştirilmiş rıza ve "devam ederek kabul etmiş sayılırsınız" kalıpları, rızayı geçersiz kılabilir; arayüz tasarımı hukuk danışmanıyla gözden geçirilmelidir.

Veri taşıma ve entegrasyonlarda minimizasyon

Entegrasyonlar çoğu zaman "tüm kaydı gönder" mantığıyla kurulur. Oysa SMS servisine yalnızca telefon ve mesaj, muhasebeye yalnızca tutar ve maliyet merkezi gitmelidir. Her entegrasyon için gönderilen alanların listesi belgelenir; bu liste, veri işleyen sözleşmesinin teknik ekidir. API yanıtlarında da gereksiz alan döndürülmemelidir: bir liste ekranı için kimlik numarası gerekmiyorsa API onu vermemelidir.

Kayıt örneği: gereğinden fazlasını yazmamak

// Kötü: kişisel veriyi log'a yazar
logger.info('Personel güncellendi', { employee });

// İyi: yalnızca kimlik ve değişen alan adları
logger.info('Personel güncellendi', { employee_id: employee.id, fields: ['phone', 'address'], actor: user.id });

Hata kayıtlarında istek gövdesinin tamamının yazılması yaygın bir sızıntı kaynağıdır; hassas alanlar kayıttan önce maskelenmelidir.

Veri koruma etki değerlendirmesi: ne zaman gerekir?

GDPR, yüksek riskli işlemeler (sistematik izleme, özel nitelikli veri, geniş ölçekli profilleme) için veri koruma etki değerlendirmesi (DPIA) ister; KVKK'da benzer bir risk odaklı yaklaşım Kurul kararlarında ve rehberlerde görülür. Yazılım ekibi açısından bu, konum takibi, biyometri veya yapay zekâ ile karar destek içeren projelerde tasarım başlamadan hukuk ekibiyle bir risk değerlendirmesi yapılması demektir. Değerlendirme, mimari kararları (hangi veri toplanmayacak, hangi süre sonra silinecek) doğrudan etkiler.

Yurt dışına aktarım: sunucu nerede?

Bulut servisleri, e-posta sağlayıcıları ve analitik araçları veriyi başka ülkelerde işleyebilir. Türkiye'de KVKK yurt dışına aktarımı belirli şartlara bağlar; GDPR'da da üçüncü ülkelere aktarım için yeterlilik kararı veya standart sözleşme hükümleri gibi mekanizmalar vardır. Yazılım ekibi için somut sonuç: her dış servisin veri işleme konumu envanterde yazılı olmalı ve konum değişikliği (sağlayıcının bölge değiştirmesi) bir değişiklik olarak ele alınmalıdır.

Olay bildirimi için hazırlık

Bir sızıntı olduğunda hangi verinin etkilendiğini saatler içinde belirleyebilmek gerekir. Bunun için: tablo bazlı veri sınıflandırması, erişim kayıtlarının sorgulanabilir olması ve etkilenen kişi listesinin çıkarılabilmesi. Bu hazırlık, teknik borç gibi görünür; olay anında ise en değerli varlıktır.

Uyum, bir kez değil sürekli

Her yeni özellik yeni bir veri alanı, yeni bir entegrasyon veya yeni bir rapor getirebilir. Kontrol listesi, proje başında bir kez değil, her sürümde kısa bir gözden geçirmeyle uygulanmalıdır: "Bu sürüm yeni kişisel veri topluyor mu? Yeni bir dış servise gönderiyor mu? Saklama süresi tanımlı mı?" Üç soru, çoğu sürüm için yeterlidir.

Cy Logic'in kişisel veri işleyen sistemlerinde (İK, puantaj, CRM, portal) bu liste tasarım aşamasının girdisidir; proje sonunda doldurulan bir form değil.