Bir saldırıdan sonra müşterilerimi ve otoriteyi bilgilendirmeli miyim
Ele geçirilmiş bir çevrim içi mağaza adları, adresleri ve satın alma geçmişlerini işler. GDPR, veri sorumlusunun ne yapması gerektiğini, hangi süre içinde ve hangi durumlarda hiçbir bildirim gerekmediğini açıkça belirler.
GDPR'ın veri ihlali dediği şey
Tanım, çoğu satıcının sandığından geniştir. Kişisel veri ihlali, kazara veya hukuka aykırı biçimde kişisel verilerin yok edilmesine, kaybına, değiştirilmesine veya yetkisiz ifşasına yol açan bir güvenlik olayıdır.
Sıklıkla yanlış anlaşılan üç pratik sonuç:
- Hırsızlık şart değildir. Bir saldırgan tarafından silinen veya şifrelenerek kullanılamaz hâle getirilen bir sipariş tablosu da ihlaldir.
- Sızma şart değildir. Müşteri adları, adresleri ve telefonlarını içeren, dışarıdan okunabilen günlük dosyaları yetkisiz ifşa oluşturur. PrestaShop için
upsshippingmodülüne ilişkin Mayıs 2026 tarihli bildiri, etkilenen satıcılardan açıkça GDPR yükümlülüklerini değerlendirmelerini ister. - Kusurlu olmanız şart değildir. Yükümlülük, olayın teknik kaynağı ne olursa olsun veri sorumlusuna, yani size aittir.
Buna karşılık her güvenlik olayı bir veri ihlali değildir: veritabanına veya kişisel veri içeren dosyalara erişilmeden yalnızca ana sayfası tahrif edilen bir site ihlal sayılmaz. Ayrım, hissedilen ağırlığa göre değil, verilere göre yapılır.
72 saat gerçekte ne zaman işlemeye başlar
Yetkili denetim otoritesine bildirim süresi, ihlalden haberdar olduğunuz andan itibaren 72 saattir. Uygulamada sorun çıkaran nokta bu başlangıç anıdır.
Haberdar olmak, incelemeyi bitirmiş olmak veya verilerin çıktığından emin olmak anlamına gelmez. Sayaç, kişisel verileri etkileyen bir güvenlik olayının gerçekleştiğine dair makul bir kesinlik derecesine ulaştığınızda başlar: tuzaklanmış bir eklentiyi veya veritabanına erişmiş yabancı bir dosyayı bulduğunuz gün; danışmanınızın raporunu teslim ettiği gün değil.
GDPR, incelemenin tamamlanmadığı durumu açıkça öngörür: bildirim, eldeki bilgilerle aşamalı olarak yapılabilir, sonra tamamlanabilir. Süre aşılmışsa bildirimde gecikmenin gerekçeleri belirtilmelidir. Gerekçeli ve geç bir bildirim, hiç bildirim yapmamaktan iyidir.
Üç durum ve her birinin doğurduğu yükümlülük
-
Kişiler için risk yok
Ne otoriteye bildirim, ne müşterilerin bilgilendirilmesi. Ancak olay yine de iç ihlal kayıt defterinize, bu sonuca götüren değerlendirmeyle birlikte işlenmelidir. Gerekçelendirmemek başlı başına bir eksikliktir.
-
Haklar ve özgürlükler için risk var
72 saat içinde denetim otoritesine bildirim. Bireysel bilgilendirme zorunlu değil. Bir mağazada en sık görülen durum budur: kimlik ve sipariş verileri erişilebilirdi, ancak kullanıldıkları ortaya konmuş değil.
-
Yüksek risk
Hem otoriteye bildirim hem de ilgili kişilerin gecikmeksizin bilgilendirilmesi; somut koruma tavsiyeleriyle birlikte: başka yerde de kullanılan bir parolayı değiştirmek, banka ekstrelerini izlemek, mağazanız adına gelen iletilere karşı temkinli olmak.
-
Her durumda: kayıt defteri
İhlalin niteliği, etkilenen kişilerin kategorileri ve yaklaşık sayısı, olası sonuçlar, alınan önlemler. Bu defter içeridedir, gönderilmez; ama var olmalı ve gerektiğinde sunulabilmelidir.
Hangi durumda olduğunuzu nasıl anlarsınız
Teknik çalışmanın hukuki kararı belirlediği yer burasıdır. Risk değerlendirmesi; erişilebilir verilerin niteliğine, hacmine, kişilerin ne kadar kolay tanımlanabildiğine ve onlar için makul sonuçlara bağlıdır.
Son dönemde yayımlanan olaylar bu ölçeği gösteriyor. Gravity SMTP eklentisinde Mart 2026'da düzeltilen açıkta olduğu gibi teknik kimlik bilgilerini ve eklenti envanterini dışarı aktaran bir arka kapı, müşterilerinize doğrudan dokunmaz; ama başka kapılar açar ve soru, o anahtarlarla sonradan ne yapıldığına döner. Diğer uçta, Haziran 2026'da bir WordPress eklenti yayıncısının dağıtım zinciri ihlalinde anlatılan zararlı yük, son üç aya ait WooCommerce siparişlerini çıkarıyordu: burada ad içeren kapsam nettir ve tarihlidir. Sansec'in Şubat 2026'da belgelediği çift formlu hırsızlıkta olduğu gibi kart bilgileri yazıldığı anda yakalandığında ise en ağır durumdasınızdır: müşterileri bilgilendirmek ve ödeme sağlayıcınızı uyarmak gerekir.
Önemli bir not: müşteri parolalarının özet olarak saklanması hafifletici bir unsurdur, muafiyet değil. GDPR, bireysel bilgilendirmeden muafiyeti özellikle verilerin ele geçirilmemiş anahtarlarla şifrelenmiş olması, sonraki önlemlerin riski ortadan kaldırması veya herkese ulaşmanın orantısız çaba gerektirmesi hâllerinde öngörür; ancak bu hâllerden birinde olduğunuzu göstermek size düşer.
Müşterilere ne yazılır ve hangi üslupla
İlgili kişilere gönderilen ileti ne bir basın bülteni ne de bir özürdür. İhlalin niteliğini anlaşılır bir dille anlatmalı, olası sonuçları belirtmeli, bir iletişim noktası vermeli, alınan ve planlanan önlemleri açıklamalı ve her şeyden önce kişinin kendisinin uygulayabileceği tavsiyeler içermelidir.
Düzenli olarak gördüğüm üç hata: müşterinin harekete geçmesi gerektiğini anlamayacağı kadar önemsizleştirmek; kendisi bir kimlik avı denemesine benzeyecek kadar genel bir ileti göndermek; ve her şeyi anlamayı bekleyip hiçbir şey yazmamak. Neyin etkilendiği ve neyin etkilenmediği konusunda net, kısa ve tarihli bir ileti, üç haftalık sessizlikten iyidir.
Kanal da önemlidir. Kendi e-posta sisteminiz etkilendiyse başka bir kanaldan gönderin ve bunu söyleyin: bu, meşru iletinizin saldırının devamı sanılmasını önler.
Konuyla ilgili diğer sayfalar
-
Sitemin ele geçirilip geçirilmediğini doğrulamak
Kapsamı sınırlandırmayı sağlayan teknik kontroller; risk değerlendirmesinin ön koşulu.
-
İlk iki saatte ne yapmalı
Öncelik sırası ve devamının bağlı olduğu günlüklerin korunması.
-
Temizlikten sonra kalıcı koruma
Bildiriminizde alınan düzeltici önlemler olarak sayabileceğiniz tedbirler.
İhtiyacınızı bir dakikada anlatın
Size bir anket daha değil, doğrudan bir tahmin sunabilmem için birkaç hedefli soru.