Cuma, saat 17.40. Destek ekibine bir müşteri yazıyor: kendi sipariş geçmişine bakarken URL’deki numarayı değiştirmiş ve başka birinin adresini, telefonunu, sipariş içeriğini görmüş. Ekran görüntüsü de eklemiş.
Bu mesajın okunduğu an, şirketiniz için bir sayaç çalışmaya başlar. 72 saat sonra — yani pazartesi akşamı — Kişisel Verileri Koruma Kurulu’na bildirim yapmış olmanız gerekiyor. Önünüzde bir hafta sonu var, açığın ne zamandan beri var olduğunu bilmiyorsunuz, kaç kişinin etkilendiğini bilmiyorsunuz ve log’larınızın bunu söyleyip söyleyemeyeceğinden emin değilsiniz.
İhlal müdahalesi, o cuma akşamı öğrenilecek bir beceri değildir. Bu yazı o 72 saatin nasıl geçmesi gerektiğini ve — daha önemlisi — o gün gelmeden neyin hazır olması gerektiğini anlatıyor.
Bu yazı genel bilgilendirme amaçlıdır, hukuki görüş değildir. Gerçek bir ihlal durumunda hukuki destek almanızı öneririz.
Kanun Ne Diyor?
KVKK’nın 12. maddesi, işlenen kişisel verilerin kanuni olmayan yollarla başkaları tarafından elde edilmesi hâlinde veri sorumlusunun bunu en kısa sürede ilgilisine ve Kurul’a bildirmesini ister. Kurul, 24 Ocak 2019 tarihli ve 2019/10 sayılı kararıyla bu ifadeyi somutlaştırdı:
- Kurul’a bildirim, ihlalin öğrenildiği andan itibaren gecikmeksizin ve en geç 72 saat içinde yapılır.
- Etkilenen kişiler belirlendikten sonra ilgili kişilere de makul olan en kısa sürede bildirim yapılır — iletişim bilgisine ulaşılabiliyorsa doğrudan, ulaşılamıyorsa web sitesinde yayımlamak gibi uygun yöntemlerle.
- 72 saat içinde bildirim yapılamıyorsa, gecikmenin gerekçesi bildirimle birlikte açıklanır.
- Tüm bilgiler aynı anda sağlanamıyorsa aşamalı bildirim yapılabilir.
- İhlal veri işleyende gerçekleştiyse, veri işleyen durumu gecikmeksizin veri sorumlusuna bildirmek zorundadır.
- Veri sorumlusu ihlalleri, etkilerini ve alınan önlemleri kayıt altına almak ve bir müdahale planı hazırlamak zorundadır.
Yurt dışında yerleşik bir veri sorumlusunda yaşanan ihlal Türkiye’deki kişileri etkiliyorsa, aynı bildirim yükümlülüğü geçerlidir.
Saat Ne Zaman Başlar?
Süre ihlalin gerçekleştiği anda değil, öğrenildiği anda başlar. Bu iki taraflı bir bilgidir.
İyi tarafı: altı ay önce başlayan ve dün fark ettiğiniz bir sızıntıda süre dünden itibaren işler.
Kötü tarafı: “öğrenme” şirket olarak öğrenmedir, yöneticinin öğrenmesi değil. Destek temsilcisinin gelen kutusuna düşen o mesaj, bir geliştiricinin gördüğü tuhaf log satırı, tedarikçiden gelen uyarı e-postası — bunlardan herhangi biri süreyi başlatabilir. Bilginin içeride üç gün elden ele dolaşması sizin sorununuzdur, Kurul’un değil. Bu yüzden ilk tedbir tekniği değil örgütseldir: herkes şüpheli bir durumu kime, hangi kanaldan bildireceğini bilmelidir.
İhlal Yalnızca “Hack’lenmek” Değildir
Kurul’a bildirilen ihlallerin önemli bir kısmı sofistike saldırılar değil, sıradan hatalardır:
- Yanlış alıcıya gönderilen e-posta ya da BCC yerine CC ile yapılan toplu gönderim
- Yetkilendirme açığı — yukarıdaki örnekte olduğu gibi, numarayı değiştirince başkasının kaydını görmek
- İnternete açık bırakılmış depolama alanı, yedek dosyası ya da yönetim paneli
- Şifrelenmemiş dizüstü bilgisayarın veya telefonun kaybolması
- İşten ayrılan çalışanın müşteri listesini götürmesi
- Fidye yazılımı — veri dışarı çıkmasa bile erişilebilirliğin kaybı da bir ihlaldir
- Kaynak koduna gömülmüş ve herkese açık bir depoya gönderilmiş erişim anahtarları
Listenin yarısından fazlası temel mühendislik hijyeniyle önlenebilir. Yetkilendirme açıkları özelinde web uygulama güvenliği rehberimize bakın; Kurul kararlarında en sık karşılaşılan teknik kök nedenlerden biri budur.
72 Saat, Saat Saat
0-4. saat: Doğrula ve durdur
- Olay sorumlusunu ve çekirdek ekibi belirleyin (teknik, hukuk, yönetim, iletişim). Tek bir iletişim kanalı açın.
- Bir zaman çizelgesi tutmaya başlayın. Kim, neyi, ne zaman öğrendi ve ne yaptı. Bu kayıt hem bildirimin hem de sonraki incelemenin omurgasıdır.
- İhlali doğrulayın ve kanamayı durdurun: açığı kapatın, ele geçen kimlik bilgilerini ve anahtarları iptal edin, etkilenen sistemi izole edin.
- Delili yok etmeyin. Sunucuyu silip yeniden kurmak en doğal reflekstir ve en pahalı hatadır. Önce disk ve bellek imajı, log kopyası; sonra temizlik.
4-24. saat: Kapsamı belirle
Cevaplanması gereken sorular, bildirim formunun da sorularıdır:
- Hangi veri kategorileri etkilendi? Özel nitelikli veri var mı?
- Kaç kişi ve kaç kayıt etkilendi?
- İhlal ne zaman başladı, ne zaman sona erdi?
- Veriye yalnızca erişildi mi, kopyalandı mı, değiştirildi mi?
- Kök neden nedir?
Bu soruları cevaplayabilmeniz tamamen ihlalden önce tuttuğunuz log’lara bağlıdır. Erişim log’ları yoksa ya da 7 gün sonra siliniyorsa, “kaç kişi etkilendi?” sorusunun dürüst cevabı “bilmiyoruz, herkesi etkilenmiş varsaymak zorundayız” olur.
24-48. saat: Riski değerlendir, bildirimi hazırla
Etkilenen kişiler açısından olası sonuçları değerlendirin: kimlik hırsızlığı, dolandırıcılık, maddi kayıp, itibar zararı. Bu değerlendirme hem Kurul’a bildirimin bir parçasıdır hem de ilgili kişilere ne söyleyeceğinizi belirler.
Kurul’a bildirim, Kurum’un internet sitesindeki Kişisel Veri İhlal Bildirim Formu ile yapılır. Tüm bilgiye sahip değilseniz bile elinizdekiyle süresinde bildirin ve aşamalı olarak tamamlayın. Eksik ama zamanında bildirim, eksiksiz ama geç bildirimden her zaman iyidir.
48-72. saat: Bildir
- Kurul’a bildirimi yapın.
- İlgili kişilere bildirimi hazırlayın ve gönderin. Kurul’un 2019/271 sayılı kararına göre bu bildirim açık ve sade bir dille yazılmalı ve asgari şunları içermelidir: ihlalin ne zaman gerçekleştiği, hangi verilerin etkilendiği, olası sonuçları, alınan ve alınması önerilen tedbirler, bilgi alınabilecek iletişim kanalları.
- Kullanıcıların yapabileceği somut şeyleri söyleyin: parolayı değiştirin, şu tür iletilere itibar etmeyin. “Güvenliğiniz bizim için önemlidir” bir tedbir değildir.
72. saatten sonra
Kök neden analizi, kalıcı düzeltmeler, ihlal kaydının tamamlanması ve — mutlaka — müdahale planının bu deneyimle güncellenmesi. Kurul çoğu zaman ek bilgi ve belge ister; zaman çizelgeniz burada tekrar işe yarar.
72 Saati Mümkün Kılan Teknik Altyapı
O hafta sonunun yönetilebilir olup olmayacağı, aylar önce verilmiş mühendislik kararlarına bağlıdır:
Merkezi ve değiştirilemez log’lar. Uygulama, veritabanı ve erişim log’ları tek yerde toplanmalı, saldırganın (ya da kötü niyetli bir çalışanın) silemeyeceği şekilde saklanmalı ve saklama süresi aylarla ölçülmelidir.
Kişisel veriye erişimin kaydı. Yalnızca “kim giriş yaptı” değil, “kim, hangi kaydı, ne zaman görüntüledi veya dışa aktardı”. Kapsam sorusunu cevaplayan log budur.
Anomali uyarıları. Bir hesabın bir saatte 10.000 müşteri kaydı çekmesi, gece üçte yapılan toplu dışa aktarım, alışılmadık ülkeden yönetici girişi. İhlali müşteriden değil kendi uyarınızdan öğrenmek hem süreyi hem hasarı küçültür.
Veri haritası. Hangi sistemde hangi kişisel verinin durduğunu gösteren güncel bir envanter. “Bu sunucuda ne vardı?” sorusuna iki gün değil iki dakikada cevap verebilmelisiniz.
Şifreleme. Doğru şifrelenmiş ve anahtarı ele geçmemiş bir verinin sızması, etkilenen kişiler açısından riski ciddi biçimde azaltır — ve bu, risk değerlendirmenize ve Kurul’un değerlendirmesine doğrudan yansır.
Test edilmiş yedekler. Fidye yazılımı senaryosunda yedeğin var olması değil, geri dönülebildiğinin denenmiş olması önemlidir.
Anahtar ve parola rotasyonu. Tüm API anahtarlarını, veritabanı parolalarını ve token’ları bir saat içinde değiştirebilir misiniz? Çoğu ekip bu soruyu ilk kez ihlal sırasında sorar. Altyapı tarafı için DevOps pratikleri yazımıza bakabilirsiniz.
Veri işleyen sözleşmeleri. Tedarikçilerinizle yaptığınız sözleşmelerde ihlali size kaç saat içinde bildirecekleri yazıyor mu? Yazmıyorsa, 72 saatinizin bir kısmı sizin kontrolünüzde değildir.
Planı Yazın, Sonra Deneyin
Müdahale planı bir sayfalık olabilir: kim karar verir, kime haber verilir, ilk dört saatte ne yapılır, bildirim taslakları nerede durur, hukuki destek kimden alınır. Önemli olan uzunluğu değil, denenmiş olmasıdır.
Yılda bir kez iki saatlik bir masa başı tatbikatı yapın: “Cuma 17.40, şu mesaj geldi. Şimdi ne yapıyoruz?” İlk tatbikatta neredeyse her ekip aynı şeyleri keşfeder: log’lar sanıldığı kadar geriye gitmiyordur, kimse bildirim formunu daha önce açmamıştır ve hafta sonu kime ulaşılacağı belli değildir. Bunları tatbikatta öğrenmek ucuzdur.
Bildirmemenin Bedeli
Veri güvenliği yükümlülüklerine aykırılığın 2026 yılı için idari para cezası 256.357 TL ile 17.092.242 TL arasındadır. Kurul kararlarında tekrar eden bir örüntü var: ihlalin kendisi kadar, geç bildirim, eksik bildirim ve ilgili kişilere hiç bildirim yapılmaması da yaptırıma konu oluyor. Tersine, hızlı ve şeffaf hareket eden, tedbirlerini belgeleyebilen veri sorumlularının durumu belirgin biçimde daha iyi değerlendiriliyor.
İhlali gizlemek ise neredeyse hiçbir zaman işe yaramaz: veriler bir forumda satışa çıkar, etkilenen kişi şikâyet eder ya da bir çalışan konuşur. O noktada elinizde hem ihlal hem de bildirmeme vardır.
Hazır mısınız?
Şu üç soruya bugün net cevap verebiliyorsanız iyi durumdasınız: İhlal şüphesini kim, kime bildirir? Belirli bir müşterinin kaydına son 90 günde kimlerin eriştiğini gösterebilir misiniz? Müdahale planınız en son ne zaman denendi?
Cevaplar net değilse, düzeltmenin en ucuz zamanı şimdidir. IWWOMI olarak KVKK danışmanlığı kapsamında ihlal müdahale planını hazırlıyor, loglama ve uyarı altyapısını kuruyor ve ekibinizle tatbikatı birlikte yapıyoruz. Mevcut hazırlık seviyenizi konuşmak isterseniz bize ulaşın.
Kaynaklar: Kişisel Veri İhlali Bildirim Usul ve Esaslarına İlişkin 2019/10 sayılı Kurul Kararı · İlgili kişiye yapılacak bildirimin asgari unsurlarına ilişkin 2019/271 sayılı Kurul Kararı
