Veri İhlali Bildirimi — KVKK 72 Saat Kuralı ve İlk Müdahale Rehberi

KVKK m.12 kapsamında veri ihlali bildirimi 72 saat kuralı, ihlal müdahale planı, masaüstü tatbikat ve ilk 72 saat kontrol listesi.

Gece yarısı gelen bir güvenlik alarmı, çalışanın yanlışlıkla müşteri listesini e-posta ile dışarı göndermesi veya fidye yazılımının yedekleme sunucusuna erişmesi — veri ihlali senaryoları çoğu zaman “bir gün olur” diye ertelenen konulardır. Oysa ihlal gerçekleştiğinde kurumun ilk sorusu nettir: Kurul'a ne zaman, neyi bildirmeliyiz? 6698 sayılı KVKK m.12, kişisel verilerin hukuka aykırı olarak başkaları tarafından elde edilmesi hâlinde veri sorumlusunun en kısa sürede Kişisel Verileri Koruma Kurulu'na bildirim yapmasını zorunlu kılar. Kurul uygulaması ve AB GDPR ile uyumlu yorumda bu süre fiilen 72 saat olarak kabul edilir.

Kurul kararlarında ihlal sonrası değerlendirmenin merkezinde çoğu zaman “ihlal oldu mu?” sorusundan çok “ihlal öncesi ve sonrası tedbirler etkili miydi?” sorusu yer alır. Bildirim gecikmesi ceza sebebidir; ancak hazırlıksızlık, kayıt eksikliği ve müdahale planının olmaması ceza riskini katlar. Bu rehber, 72 saat kuralını, ihlal müdahale planını ve ilk 72 saatte izlenecek operasyonel adımları somut bir kontrol listesiyle açıklar.

KVKK m.12: Bildirim Yükümlülüğü Ne Zaman Doğar?

KVKK m.12/5 uyarınca, kişisel verilerin hukuka aykırı olarak başkaları tarafından elde edilmesi hâlinde veri sorumlusu, durumu en kısa sürede Kurul'a bildirir. Bildirimde asgari olarak şu bilgiler yer almalıdır:

  • İhlalin niteliği
  • Etkilenen veri kategorileri ve kişi sayısı (mümkün olduğunca)
  • İhlalin olası sonuçları
  • Alınan veya önerilen tedbirler

Aynı madde, ihlalin ilgili kişilerin hakları üzerinde yüksek risk doğurması hâlinde ilgili kişilere de bilgilendirme yapılmasını öngörür. Bildirim yükümlülüğü, ihlalin “kesinleşmesini” beklemek anlamına gelmez; makul ölçüde ihlal olduğuna kanaat getirildiği anda süre işlemeye başlar.

72 saat kuralı pratikte nasıl işler?

“En kısa süre” ifadesi belirsiz görünse de Kurul rehberleri ve yerleşik uygulama 72 saati referans alır. Kritik noktalar:

AşamaSüreAçıklama
İhlalin öğrenilmesiT0İç ekip, SIEM alarmı, tedarikçi bildirimi veya dış ihbar
Ön değerlendirmeT0 – 24 saatGerçek ihlal mi, kapsam ne, acil kontrol gerekli mi?
Kurul bildirimiEn geç T0 + 72 saatEksik bilgiyle bildirim yapılabilir; sonradan tamamlanır
İlgili kişi bilgilendirmeRisk analizine göreYüksek risk varsa gecikmeden
Kayıt ve dokümantasyonSürekliDenetimde ispat için zorunlu

72 saat içinde tüm detayların netleşmemesi bildirimi engellemez. Kurul'a “henüz bilinmeyen alanlar” açıkça belirtilerek kısmi bildirim yapılmalı; yeni bilgiler geldikçe güncelleme gönderilmelidir.

Bildirim yükümlülüğünün ihlali, 2026 KVKK idari para cezası tablosunda veri güvenliği ihlalleri bandıyla (256.357 – 17.092.242 TL) doğrudan örtüşür. İhlal sonrası gecikme ve yetersiz tedbir, aynı denetimde birleşik değerlendirilir.

İhlal Müdahale Planı: Kriz Anında Değil, Öncesinde Hazırlanır

Veri ihlali müdahale planı (incident response plan), ihlal anında “kim ne yapar?” sorusunun yazılı cevabıdır. m.12 kapsamındaki teknik ve idari tedbirlerin bir parçası olarak değerlendirilir; planın olmaması veya uygulanmaması Kurul nezdinde ağırlaştırıcı faktör sayılır.

Planın asgari bileşenleri

  1. Tetikleyici tanımları — Hangi olaylar ihlal şüphesi sayılır? (yetkisiz erişim, veri sızıntısı, kayıp cihaz, fidye yazılımı, yanlış alıcıya e-posta)
  2. İhlal müdahale ekibi (IRT) — IT güvenlik, hukuk, uyum, iletişim, üst yönetim temsilcileri ve yedekleri
  3. Eskalasyon matrisi — Seviyeye göre kimin bilgilendirileceği ve karar yetkisi
  4. İletişim şablonları — Kurul bildirimi, ilgili kişi bilgilendirme, tedarikçi bildirimi, basın/halkla ilişkiler
  5. Teknik müdahale adımları — İzolasyon, log toplama, erişim iptali, yedekten geri yükleme
  6. Hukuki değerlendirme akışı — Bildirim zorunluluğu, ilgili kişi bilgilendirme eşiği
  7. Kayıt tutma formatı — Zaman damgalı olay günlüğü (incident log)

Plan yılda en az bir kez gözden geçirilmeli; organizasyon yapısı, sistem envanteri veya tedarikçi zinciri değiştiğinde güncellenmelidir.

Masaüstü Tatbikat: Planı Kağıt Üzerinde Bırakmayın

Masaüstü tatbikat (desktop exercise), gerçek sistemlere dokunmadan senaryo üzerinden ihlal müdahale planının test edilmesidir. Kurumlar genellikle politika yazıp tatbikat yapmaz; denetim anında “plan var ama uygulanmadı” tablosuna düşer.

Örnek tatbikat senaryosu

Pazartesi 09:15'te IT, müşteri veritabanına yetkisiz erişim denemesi tespit etti. Loglarda üç başarılı oturum görülüyor; 12.000 müşteri kaydına erişim izi var. Saldırgan IP'si yurt dışından.

Tatbikat sırasında ekip şu soruları yanıtlar:

  • İhlal müdahale ekibi 30 dakika içinde toplanabildi mi?
  • Kapsam (hangi veri, kaç kişi) 4 saat içinde tahmin edilebildi mi?
  • Kurul bildirimi için sorumlu ve şablon hazır mı?
  • İlgili kişi bilgilendirme kararı kim veriyor?
  • Tedarikçi (bulut sağlayıcı) sözleşmesindeki bildirim süresi nedir?
  • Olay günlüğü tutuluyor mu?

Tatbikat sonunda eksikler raporlanır ve 30 gün içinde plana yansıtılır. Yılda en az bir masaüstü, iki yılda bir teknik tatbikat (sınırlı kapsamlı) önerilir.

İlk 72 Saat Kontrol Listesi

Aşağıdaki liste, ihlal şüphesi doğduğu andan Kurul bildirimine kadar izlenmesi gereken operasyonel adımları özetler.

Saat 0–4: Acil müdahale ve izolasyon

  • İhlal müdahale ekibi lideri atandı ve ekip bilgilendirildi
  • Olay günlüğü açıldı (tarih, saat, kaynak, ilk tespit yöntemi)
  • Etkilenen sistemler izole edildi veya erişim kısıtlandı
  • İlgili loglar, ekran görüntüleri ve kanıtlar güvenli biçimde korundu
  • Yanlışlıkla kanıt silinmesini önlemek için değişiklik durduruldu
  • Dışarıya bilgi sızdırılması engellendi (iç iletişim kanalı belirlendi)

Saat 4–24: Kapsam analizi ve ön değerlendirme

  • Hangi veri kategorilerinin etkilendiği belirlendi (kimlik, finans, sağlık vb.)
  • Etkilenen kişi sayısı için ilk tahmin yapıldı
  • İhlalin hukuka aykırı elde edilme niteliği değerlendirildi
  • Özel nitelikli veri (m.6) etkilenip etkilenmediği tespit edildi
  • Veri işleyen tedarikçiler bilgilendirildi (sözleşme yükümlülükleri)
  • Hukuk/uyum birimi bildirim zorunluluğunu ön değerlendirdi
  • 72 saatlik bildirim son tarihi hesaplandı ve takvime işlendi

Saat 24–48: Bildirim hazırlığı ve tedbirler

  • Kurul bildirim taslağı hazırlandı (eksik alanlar “bilinmiyor” olarak işaretlendi)
  • Alınan teknik tedbirler dokümante edildi (şifre sıfırlama, erişim iptali, yama)
  • Alınan idari tedbirler dokümante edildi (personel bilgilendirme, yetki gözden geçirme)
  • İlgili kişi bilgilendirme ihtiyacı risk analiziyle değerlendirildi
  • Üst yönetim bilgilendirildi; iletişim stratejisi belirlendi
  • Olası medya/dış paydaş senaryosu için hazırlık yapıldı

Saat 48–72: Kurul bildirimi ve kapanış öncesi

  • Kurul'a bildirim gönderildi (en geç T0 + 72 saat)
  • Bildirim kaydı ve gönderim teyidi arşivlendi
  • İlgili kişi bilgilendirmesi gerekiyorsa başlatıldı veya planlandı
  • Kök neden analizi (RCA) için veri toplama devam ettirildi
  • Etkilenen verilerin saklama süresi ve imha durumu kontrol edildi
  • Saklama ve imha politikası kapsamında süresi dolmuş verinin ihlalde yer alıp almadığı değerlendirildi
  • Olay sonrası gözden geçirme toplantısı planlandı

Bildirimde Sık Yapılan Hatalar

  1. Süreyi ihlal tespitiyle karıştırmak: Log incelemesi bitene kadar beklemek. 72 saat, “kesin kanıt” değil “makul şüphe” anında başlar.
  2. Bildirimi IT'ye bırakmak: Kurul bildirimi hukuki bir süreçtir; IT müdahale eder, uyum/hukuk bildirimi hazırlar.
  3. Kapsamı küçümsemek: “Sadece 50 kayıt” ifadesi, özel nitelikli veri veya finansal veri içeriyorsa riski azaltmaz.
  4. Kayıt tutmamak: Olay günlüğü olmadan “tedbir aldık” iddiası denetimde çöker.
  5. Tedarikçi ihlalini görmezden gelmek: Veri işleyen taraftaki ihlal de veri sorumlusunun bildirim yükümlülüğünü tetikleyebilir.
  6. Tek seferlik plan: Tatbikat yapılmayan plan, fiilen yok sayılır.

m.12 Tedbirleri ve İhlal Önleme Bağlantısı

Kurul, ihlal sonrası ceza miktarını belirlerken m.12 kapsamındaki teknik ve idari tedbirlerin etkinliğini ayrı ayrı inceler. Etkili tedbir örnekleri:

  • Rol bazlı erişim kontrolü (RBAC) ve düzenli yetki gözden geçirmesi
  • Çok faktörlü kimlik doğrulama (MFA)
  • Veri şifreleme (aktarım ve depolama)
  • Güvenlik olay izleme (SIEM) ve alarm yönetimi
  • Personel gizlilik ve güvenlik farkındalık eğitimi
  • Veri minimizasyonu ve periyodik imha takvimi
  • Tedarikçi güvenlik değerlendirmesi ve DPA yükümlülükleri

İhlal hiç olmayabilir; ancak tedbirlerin dokümante edilmesi ve düzenli test edilmesi, hem önleme hem de denetim savunması için kritiktir.

İlgili Kişi Bilgilendirmesi: Ne Zaman Gerekli?

KVKK m.12/5 son cümle, ihlalin ilgili kişilerin hakları üzerinde yüksek risk doğurması hâlinde ilgili kişilere de bilgilendirme yapılmasını öngörür. Pratikte değerlendirme kriterleri:

  • Özel nitelikli veri sızıntısı var mı?
  • Finansal dolandırıcılık riski doğuyor mu?
  • Kimlik hırsızlığı veya itibar zararı olasılığı yüksek mi?
  • Etkilenen kişi sayısı ve veri hassasiyeti nedir?

Bilgilendirme gecikirse ayrı risk doğar; ancak gereksiz panik yaratacak erken bilgilendirme de kurum itibarını zedeler. Karar, hukuk ve uyum biriminin koordinasyonunda, olay günlüğüne kayıtlı şekilde verilmelidir.

Lexidata Uyum Paneli ile İhlal Yönetimi

Manuel tablolar ve e-posta zincirleri, kriz anında süre takibini zorlaştırır. Lexidata uyum panelinin ihlal yönetimi modülü şu ihtiyaçları karşılar:

  • İhlal kaydı açma — T0 zaman damgası, kategori, etkilenen veri türleri, kişi sayısı tahmini
  • 72 saat geri sayım — Bildirim son tarihi otomatik hesaplama ve uyarı
  • Olay günlüğü — Zaman damgalı müdahale adımları ve sorumlu atama
  • Kurul bildirim takibi — Gönderim durumu, eksik alanlar, güncelleme geçmişi
  • İlgili kişi bilgilendirme kaydı — Risk değerlendirmesi ve iletişim kanıtı
  • Olay sonrası rapor — Kök neden, alınan tedbirler, plan güncelleme notları

İhlal müdahale planınızı bugün yazın, masaüstü tatbikatla test edin; ihlal anında süreyi değil hazırlığınızı yönetin. platform.lexidata.io adresinden uyum panelini inceleyebilirsiniz.

Diğer yazılar