Yazılımcı gözünden KVKK

6698 sayılı Kişisel Verilerin Korunması Kanunu (KVKK) 2016'dan beri yürürlükte ama hâlâ birçok ekip, yasayı hukuk ekibinin sorunu olarak görüyor. Gerçek şu: yazılım mimarisi kararlarının çoğu — hangi alanı loglarsın, ne kadar süre saklarsın, kime API erişimi verirsin, test ortamına hangi veriyi koyarsın — doğrudan KVKK uyumuna girer. Hukuk ekibi sadece sözleşme ve aydınlatma metnini yönetir; teknik uygulama mühendisin sorumluluğundadır.

Bu yazı, Türkiye'de TC kimlik doğrulaması yapan bir yazılım ekibinin KVKK açısından bilmesi gereken temelleri işliyor: Türkiye Cumhuriyeti Kimlik Numarası'nın (TCKN) hangi veri kategorisine girdiği, nerede ve ne kadar saklanabileceği, log ve metrik politikalarının nasıl kurulacağı, anonim test verisi üretimi ve aydınlatma metninin yazılımcı odaklı kontrol listesi.

Hukuki tavsiye değildir. Hukuk departmanınızla mutlaka doğrulayın. Ancak aşağıdaki pratikler çoğu denetimde karşılaşılan teknik bulguların önüne geçer.

TC kimlik (TCKN) ve VKN: aynı kefede değiller

KVKK'nın 3. maddesi "kişisel veri"yi "kimliği belirli veya belirlenebilir gerçek kişiye ilişkin her türlü bilgi" olarak tanımlar. TC kimlik numarası bir gerçek kişiyi tek başına tanımlar — dolayısıyla kişisel veridir. Üstelik Kişisel Verileri Koruma Kurulu'nun (KVKK Kurulu) kararları TCKN'yi zaman zaman "özel nitelikli olmayan ama yüksek risk taşıyan" kategoride değerlendirir.

VKN ise tüzel kişiliklere aittir. Tüzel kişilikler KVKK'nın koruma kapsamında değildir (KVKK, sadece gerçek kişileri korur). Yani bir şirketin VKN'sini log'da tutmak KVKK açısından ihlal oluşturmaz. Ancak şu istisna önemlidir: şahıs şirketlerinde VKN yerine TCKN kullanılır; bu durumda log'daki "vkn" alanı aslında gerçek kişinin TCKN'si olabilir. Uygulamanız bu ayrımı yapabiliyor olmalı.

Pratik çıkarım: TCKN'ye uygulanan politikaların büyük kısmı VKN'ye uygulanmaz. Ancak aynı alan tipinde taşınıyorsa (örneğin customer_identifier kolonu TCKN de VKN de kabul ediyor), muhafazakâr davranıp en katı politikayı uygulayın.

VKN'nin yapısal detayları için VKN yapısı ve doğrulama yazımıza göz atın.

Hukuki işleme sebebi: rıza her zaman doğru cevap değil

KVKK madde 5, kişisel veriyi işlemek için altı farklı hukuki sebep tanır: açık rıza, kanunlarda öngörülme, sözleşmenin kurulması, hukuki yükümlülük, hakların tesisi/korunması, meşru menfaat. "Rıza" sadece bunlardan biridir ve aslında en zayıf olanıdır — çünkü kullanıcı her an geri çekebilir.

TC kimlik doğrulaması yapıyorsanız, doğru hukuki sebep genelde "sözleşmenin kurulması" veya "kanunlarda öngörülme"dir:

  • Banka/ödeme kuruluşu → MASAK düzenlemesi gereği (kanuni yükümlülük)
  • E-ticaret kaydı → sözleşmenin kurulması (müşteri kimliği gerekli)
  • Sigorta teklifi → meşru menfaat + sözleşme öncesi
  • Pazarlama amaçlı → açık rıza (ayrı ve geri çekilebilir)

Bu, aydınlatma metninizdeki "hukuki sebep" alanının doğru doldurulmasını etkiler ve DevOps tarafında retention policy'yi belirler.

Log ve telemetri: en sık ihlal noktası

Denetimlerde en sık bulunan teknik ihlal, TC kimlik numarasının uygulama loglarına düşmesidir. Üç klasik senaryo:

  1. HTTP erişim loglarına query string olarak TCKN gider. /api/user?tckn=12345678901 yanlıştır; POST + body kullanın, TCKN'yi URL'de taşımayın.
  2. Error stack trace'lerinde request body dump edilir ve TCKN de oraya düşer. Sentry, Datadog, New Relic gibi APM araçlarında PII scrubbing kurallarını mutlaka aktif edin.
  3. SQL query loglarında WHERE tckn = '12345678901' açıkça görülür. pg_stat_statements veya slow query log'u parametreleri maskelemeli.

Pratik çözüm: uygulama log'unda TC kimlik no asla tam haliyle yer almamalı. Maskelenmiş bir formatta tutulabilir:

function maskTckn(t) {
  if (typeof t !== 'string' || t.length !== 11) return '***';
  return t.slice(0, 3) + '****' + t.slice(-2);
}
// "12345678901" -> "123****01"

Bu, destek ekibinin "bu TCKN'yi logda görebiliyor musun" tarzı taleplerinde bile yeterli olur. Tam TCKN'ye ihtiyaç olursa, sadece audit log'larda ve şifreli tutulmalı.

Log saklama süresi

KVKK Kurulu kararları "veri, işleme amacı için gereken süre kadar saklanır" demekle yetinir; spesifik süre vermez. Pratik saha normları:

  • HTTP erişim log'u: 7–30 gün
  • Uygulama log'u: 30–90 gün
  • Audit log'u (compliance gereği): 2–10 yıl, ama erişim kısıtlı ve şifreli

Bankacılık/sigorta gibi düzenlemeye tâbi sektörlerde BDDK/SPK kuralları KVKK'dan daha uzun saklama şart koşabilir. Hukuk ekibinizin sektör regülasyonunu doğrulaması şart.

Veritabanı: şifreleme ve erişim

TC kimlik numarası tutan kolonlar için şu katmanları düşünün:

  • At-rest encryption: PostgreSQL için TDE veya volume-level encryption (LUKS, AWS KMS). Minimum şart.
  • Application-level encryption: hassas alanları (TCKN, IBAN) bir HSM/KMS anahtarıyla şifreleyip DB'ye şifrelenmiş yazmak. Arama yapılacaksa deterministik şifreleme veya hash tabanlı indeks.
  • Row-level security: kullanıcının kendi satırlarına erişimi. PostgreSQL RLS kullanışlı.
  • Audit trigger: SELECT'leri de loglayan tetikleyici. Denetim için kritik.

TCKN'yi cleartext index'le tutmak hatalı değildir ama ideal de değildir. Orta yol: TCKN'yi SHA-256 + secret salt ile hash'leyip bir ayrı tckn_lookup kolonunda tutmak, aramaları bu kolonla yapmak, gerçek değeri şifreli saklamak.

Cross-border transfer (veri yurtdışı aktarımı)

KVKK madde 9, kişisel verilerin yurtdışına aktarılmasını kurul izni şartına bağlar (bazı istisnalar var). Yazılımcı açısından bu şu anlama gelir:

  • TCKN'yi Amerika'daki bir APM servisine göndermek risklidir. PII scrubbing şart.
  • AWS eu-central-1 yerine us-east-1 kullanıyorsanız, veri yurtdışına gidiyordur. Kurul kararı veya yeterlilik belgesi gerektirir.
  • Cloudflare, Sentry, Slack gibi SaaS araçları kullanıyorsanız veri işleme sözleşmesi (DPA) imzalayın ve veri akışını haritalayın.

2024 sonrası "taahhütname + bilgilendirme" rejimi bazı aktarımları kolaylaştırdı, ancak ekibinizin bir "veri akış haritası" (data flow diagram) tutması hem teknik hem hukuki olarak kıymetlidir.

Test ortamında gerçek TC kimlik numarası kullanmak: yapmayın

Production DB'nin bir snapshot'ını test/staging ortamına kopyalamak klasik bir anti-pattern. Bu neredeyse kesin bir KVKK ihlalidir çünkü test ortamlarının güvenlik kontrolü (access log, encryption, backup policy) production ile aynı seviyede değildir.

Doğru yaklaşım (Sistem testlerinizde production'dan alınan maskelenmiş veri kullanmak yerine, tc no uret sayfası yardımıyla baştan yeni sentetik kayıtlar üretebilirsiniz):

  1. Synthetic data: algoritma uyumlu ama gerçek olmayan TC kimlik numaraları üretin. TC Üretici aracı tam da bunun için.
  2. Anonymization: production verisini anonimleştirerek test'e taşıyın. Ad/soyad rastgeleleştirilir, TCKN yeniden üretilir, doğum tarihi ay bazında yuvarlanır.
  3. Pseudonymization: TCKN'yi deterministik bir hash ile değiştirin (sha256(tckn + test_salt)). Aynı kullanıcı tüm tabloda aynı pseudo-ID'yi alır; ters çevrilemez.

Ekibinizin test verisi yaşam döngüsünü nasıl kurguladığını test verisi üretiminde en iyi pratikler yazımızda detaylandırdık.

Aydınlatma metni: yazılımcı kontrol listesi

Aydınlatma metnini hukuk yazıyor olabilir, ama yazılım ekibi şunları kontrol etmeli:

  • Toplanan veri kategorileri tam listelenmiş mi? (TCKN, ad, e-posta, IP, device ID, cookie ID)
  • Hukuki sebepler her kategori için belirtilmiş mi?
  • Saklama süreleri her kategori için verilmiş mi ve sizin retention policy'nizle örtüşüyor mu?
  • Veri aktarılan üçüncü taraflar (APM, e-posta servisi, ödeme sağlayıcısı) listelenmiş mi?
  • Yurtdışı aktarımı varsa hukuki dayanağı belirtilmiş mi?

Aydınlatma metni ile kodun örtüşmemesi ("metinde yazmıyor ama biz tutuyoruz") en büyük denetim riskidir. Her yeni field eklediğinizde hukuk ekibine haber verin.

Veri sahibi hakları: teknik uygulama

KVKK madde 11 veri sahibine 7 hak verir. Bunların teknik tarafı şudur:

  • Erişim hakkı: kullanıcı "benim hakkımda ne tutuyorsunuz" isterse. Self-service bir "verilerimi indir" butonu veya mail üzerinden manuel süreç. Yanıt süresi 30 gün.
  • Düzeltme hakkı: yanlış veri varsa düzeltme. Kullanıcı paneli çoğunlukla çözer.
  • Silme hakkı: "unutulma hakkı". En zoru. Backup'larda ve anonimleştirilmemiş analytics DB'lerinde TCKN varsa bu taleplere nasıl cevap vereceğinizi önceden planlayın.

Silme talebi geldiğinde bir hafta içinde 15 farklı sistemde temizlik yapabileceğinizden emin olun. Aksi halde Kurul'a yapılan şikayetlerde ciddi idari para cezaları var (2024 itibarıyla 70.000 TL–3.500.000 TL arası; yıllık güncelleniyor).

Toplu işlemler: ekstra dikkat

Toplu TC kimlik doğrulama, validasyon, import/export işlemlerinde KVKK etkisi katlanır. 1 milyon kayıt işleniyorsa:

  • CSV dosyasının S3/object storage'da ne kadar süre durduğu (ideal: işlendikten sonra 24 saat içinde silinsin)
  • Worker loglarında TCKN'lerin görünmemesi
  • Background job payload'larında TCKN'nin encrypted tutulması
  • Job retry queue'sunda ne kadar süre kalacağı (ideal: 3-7 gün)

Bu toplu mimarinin güvenli versiyonunu toplu doğrulama rehberinde anlatıyoruz.

Veri ihlali bildirim süresi

Kişisel veri ihlali (data breach) durumunda KVKK Kurulu'na 72 saat içinde, veri sahiplerine makul süre içinde bildirim yapmanız gerekir. Bunu yapabilmek için:

  • Ekibinizin bir "breach response runbook"u olmalı
  • Hangi tabloda hangi PII olduğunu 5 dakikada cevaplayabilmelisiniz (veri envanteri)
  • İletişim zinciri net olmalı: kim CTO'yu arayacak, kim DPO'yu, kim Kurul formunu dolduracak

Sonuç

KVKK uyumu, hukuk biriminin tek başına çözebileceği bir konu değildir. TC kimlik numarasının her bir noktada (form, DB, log, APM, backup, test ortamı) nerede durduğunu ve ne kadar süre kaldığını bilmek yazılım ekibinin sorumluluğundadır. Yukarıdaki prensipleri sistem tasarımınıza yerleştirirseniz, denetim geldiğinde ekstra iş çıkmaz.

Anonim test verisi için TC Üretici ve Toplu Üretim araçlarını kullanın.