Veri İhlali Bildirimi: 72 Saatte Kurul'a Bildirim Playbook'u

Veri ihlalleri "olursa" değil "olduğunda" sorusudur. Fark yaratan şey, ihlal anında hazır bir müdahale planınızın olup olmamasıdır. Panik anında sıfırdan karar vermek yerine, önceden yazılmış adımları uygulamak hem süreyi hem de itibar kaybını azaltır. Kurul uygulamasında bildirim için pratik ölçüt 72 saattir; bu süreyi ancak önceden kurgulanmış bir playbook ile yakalayabilirsiniz.

Bu yazı, bir ihlali fark ettiğiniz andan Kurul'a bildirimi tamamlayıp süreci kapattığınız ana kadar izlenebilecek uçtan uca bir yol haritası sunar. Amaç, teknik ekipten hukuk birimine kadar herkesin aynı senaryoyu paylaşmasıdır.

Neyin İhlal Sayıldığı

Kişisel verilerin; hukuka aykırı olarak ele geçirilmesi, ifşası, değiştirilmesi, silinmesi veya erişilemez hâle gelmesi bir ihlaldir. Yani ihlal yalnızca "veri çalındı" durumuyla sınırlı değildir; verinin gizliliği, bütünlüğü veya erişilebilirliğinden herhangi birinin zarar görmesi yeterlidir.

Sık karşılaşılan örnekler:

• Yetkisiz erişim ve hesap ele geçirme (phishing sonrası),
• Fidye yazılımı ile verinin şifrelenip erişilemez hâle gelmesi,
• Yanlış alıcıya gönderilen e-posta veya belge,
• Kaybolan ya da çalınan dizüstü bilgisayar, telefon, USB,
• Yanlış yapılandırma sonucu internete açık kalan veritabanı,
• Çalışanın yetkisi dışında veriyi kopyalaması.

72 Saatlik Kural

Kurul, ihlalin "en kısa sürede" bildirilmesini düzenler ve uygulamada bunu 72 saat olarak somutlaştırmıştır. Süre, ihlali öğrendiğiniz an başlar; olayın gerçekleştiği an değil. Bu ayrım kritiktir: sayaç, olayın bir çalışan, sistem uyarısı veya üçüncü taraf tarafından fark edilip sorumlulara ulaştığı anda işlemeye başlar.

Bu yüzden "öğrenme anını" belgelemek en az bildirim kadar önemlidir. Kim, ne zaman, hangi kanaldan haberdar oldu? Bu zaman damgası, süreye uyduğunuzu gösteren temel kanıttır. Ayrıca, riski yüksek ise yalnızca Kurul'a değil, etkilenen kişilere de bilgilendirme yapılması beklenir.

Playbook: Adım Adım

Bu tablonun değeri, ihlal anında kimin neyi yapacağının önceden belli olmasıdır. Her aşama için bir sorumlu ve bir yedek atanmalı; iletişim bilgileri güncel tutulmalıdır. Kontrol altına alma ile kanıt koruma arasındaki dengeye dikkat edin: sistemi kapatmak yayılmayı durdurur ama değerli log kayıtlarını da silebilir.

Bildirimde Ne Yer Almalı?

• İhlalin ne zaman ve nasıl gerçekleştiği,
• Etkilenen veri kategorileri ve yaklaşık kişi sayısı,
• Olası sonuçlar,
• Alınan ve alınacak tedbirler,
• İletişim noktası.

Tüm bilgiler ilk anda net olmayabilir. Bu durumda eksik bilgiyle beklemek yerine, bilinenlerle bildirimi yapıp süreci aşamalı olarak güncellemek daha güvenlidir. Bildirimin tonu savunmacı değil, şeffaf ve çözüm odaklı olmalıdır.

İhlalin Riskini Değerlendirme

Etkilenen kişilere bildirim yapılıp yapılmayacağını belirleyen şey risktir. Riski değerlendirirken şu unsurlara bakın:

• Veri türü: Özel nitelikli veri (sağlık, biyometri, din) veya finansal veri riski yükseltir.
• Hacim: Kaç kişi ve hangi kapsamda veri etkilendi?
• Kolay tanımlanabilirlik: Veri, kişilere doğrudan ulaşmayı sağlıyor mu?
• Olası zarar: Dolandırıcılık, kimlik hırsızlığı, itibar kaybı riski var mı?

Değerlendirmeyi ve vardığınız sonucu yazılı hâle getirin. "Bildirmeme" kararı verseniz bile, bu kararın gerekçesini belgelemek hesap verebilirliğin bir parçasıdır.

Örnek Senaryo: Yanlış Alıcıya Toplu E-posta

Pazarlama ekibi, tüm müşterilerin e-posta adreslerini "Kime" alanına yazarak (BCC yerine) bülten gönderdi. Bu, adreslerin birbirine ifşası olduğu için bir ihlaldir.

Doğru refleks:

1. Olayı ve öğrenme anını kaydet, sayacı başlat.
2. Kapsamı belirle: kaç kişiye gönderildi, adreslerin başka veriyle (isim, sağlık bilgisi) birlikte görünüp görünmediği.
3. 72 saat içinde Kurul'a bildir.
4. Riski değerlendir; adresler hassas bir bağlamdaysa etkilenen kişileri de bilgilendir.
5. Süreci düzelt: toplu gönderimlerde BCC zorunluluğu, ikinci onay adımı ve gönderim öncesi kontrol listesi.

Bu senaryo küçük görünse de, tekrar etmesi hâlinde sistematik bir kusura işaret eder; bu yüzden düzeltici tedbir tek bir kişiye değil sürece uygulanmalıdır.

Sık Yapılan Hatalar

• İhlali "küçük" görüp bildirimi geciktirmek.
• Sayaç ne zaman başladığını belgelememek.
• İçeride kimin ne yapacağını önceden tanımlamamak.
• İhlal sonrası düzeltici tedbiri tüm benzer süreçlere yaymamak.
• Kanıtları (log, ekran görüntüsü) korumadan sistemi aceleyle sıfırlamak.

Bildirim Sonrası: Kapatma ve Öğrenme

Bildirim, sürecin sonu değil ortasıdır. İhlal kapatıldıktan sonra bir kök neden analizi yapın: olay neden mümkün oldu, hangi kontrol eksikti? Öğrenilenleri playbook'a geri işleyin ve benzer riskleri taşıyan diğer süreçleri de gözden geçirin. Ekiple kısa bir "olay sonrası değerlendirme" toplantısı yaparak süreci güçlendirin. En iyi müdahale, bir sonraki ihlali önleyen müdahaledir.

Sık Sorulan Sorular

Her ihlali bildirmek zorunda mıyım?

Kişisel veri ihlallerinde bildirim beklenir. "Zararsız" görünse bile değerlendirmeyi kayıt altına alın; karar vermeyi belgeleyin. Bildirmeme kararının gerekçesi de dosyanızda yer almalıdır.

72 saat iş günü mü, takvim günü mü?

Süre kısadır ve öğrenme anından işler; hafta sonu veya tatil beklemez. Bu yüzden bekleme değil, hızlı ve belgelenebilir müdahale esastır. Playbook'unuz mesai dışı senaryoları da kapsamalıdır.

Etkilenen kişilere de bildirim şart mı?

Risk yüksekse evet. İhlalin niteliğine göre ilgili kişilerin de bilgilendirilmesi beklenir. Bilgilendirme açık, anlaşılır ve kişilerin kendilerini koruyabilecekleri önerilerle birlikte yapılmalıdır.

Bildirimi kim yapmalı?

Sorumluluk veri sorumlusundadır; pratikte bildirimi genellikle hukuk birimi veya DPO/irtibat kişisi koordine eder. Önemli olan, bu rolün önceden belirlenmiş ve yedeklenmiş olmasıdır.

Bu içerik yalnızca genel bilgilendirme amaçlıdır ve hukuki tavsiye niteliği taşımaz. Somut bir olayda mutlaka bir uzmana danışın. JUS. ile ihlal müdahale sürecinizi belgeleyip denetime hazır tutabilirsiniz — demo talep edin.