Çoğu işletme sahibi veri sızıntısını sinema sahnesi gibi hayal eder: gece yarısı sunucuya giren biri, ekranda akan yeşil satırlar, çalınan kart numaraları. Bu yüzden de kendini güvende sanır; çünkü kart verisini hiç tutmuyordur, ödemeyi sağlayıcı üzerinden alıyordur, sunucusunda güvenlik duvarı vardır. Oysa Türkiye'de bildirime konu olan sızıntıların büyük kısmı bu kadar dramatik değil. Bir bayinin panel şifresini paylaşması, yedek klasörünün web kökünde açıkta kalması, sipariş listesini dışa aktaran bir Excel'in WhatsApp grubunda dolaşması, eski bir çalışanın hesabının hâlâ aktif olması. Hepsi kişisel veri ihlali sayılır ve hepsi seni aynı saatli bombaya bağlar.
Asıl mesele şu: ihlalin kendisi değil, ihlalden sonraki davranışın yargılanıyor. Kurul'un yayımladığı karar özetlerine bakınca ortaya çıkan tablo çok net; ceza tutarını büyüten şey genellikle sızıntının teknik boyutu değil, gecikmiş bildirim, eksik kayıt, kanıtlanamayan tespit anı ve ilgili kişinin hiç haberdar edilmemesi oluyor. Yani senin e-pin satış scriptinin log mimarisi, bu noktada avukatından daha belirleyici. Bu yazıda 72 saatin nereden başladığını, Kurul dosyasına ne yazacağını, hangi kayıtların olmadan o dosyanın yazılamayacağını ve dijital ürün satış yazılımı tarafında hangi ayarları bugün açman gerektiğini adım adım kuruyoruz.
Sızıntı Dediğin Şey Aslında Neyi Kapsıyor?
Kişisel veri ihlali, verinin yetkisiz kişilerce ele geçirilmesi, ifşa edilmesi, değiştirilmesi veya erişilemez hâle gelmesi. Bu son madde çoğu kişiyi şaşırtıyor: fidye yazılımı yüzünden kendi müşteri veritabanına erişemiyorsan, veri hiç kimsenin eline geçmese bile bu bir ihlal. E-pin ve dijital ürün satan bir işletmede risk yüzeyi sandığından geniş; üyelik tablosunda ad, e-posta, telefon, IP ve cihaz kaydı var, sipariş tablosunda satın alma geçmişi var, bakiye yükleme tarafında fatura bilgisi ve bazen TCKN var, destek taleplerinde ise müşterinin ekran görüntüsüyle birlikte üçüncü taraf oyun hesabı bilgileri dolaşıyor. Destek eklerinin herkese açık bir klasörde durması, tek başına bildirime yeter. Önce neyi tuttuğunu yaz; envanteri olmayan işletme, sızıntının boyutunu da ölçemez.
72 Saat Kimden Başlar: Fark Ettiğin An mı, Sızdığı An mı?
Süre, ihlalin gerçekleştiği andan değil, senin öğrendiğin andan işlemeye başlar. Kulağa rahatlatıcı geliyor ama tersi de doğru: öğrendiğin anı kanıtlayamıyorsan, süre aleyhine yorumlanır. Burada işletmeleri en çok yakan senaryo şudur; bir müşteri Instagram'dan yazar, "benim bilgilerim bir Telegram kanalında dolaşıyor" der, mesaj destek ekibinde iki gün bekler, sonra sana ulaşır. Sen 72 saati o gün başlatmak istersin ama ekran görüntüsündeki tarih başka şey söyler. Çözüm teknik ve sıkıcı: her şüphe bildirimi, panelde tarih-saat damgalı bir kayda dönüşmeli. Scriptinin destek modülünde "güvenlik şüphesi" etiketi açık olsun, bu etiketle gelen talep otomatik olarak yöneticiye bildirim göndersin. Böylece dosyada "tespit anı" diye yazdığın tarihin arkasında sistem kaydı durur.
| Adım | Süre | Sorumlu | Kanıtın nerede durur |
|---|---|---|---|
| Şüphenin kayda geçmesi | 0. saat | Destek ekibi | Panel destek kaydı + zaman damgası |
| Kapsam tespiti (hangi tablo, kaç kayıt) | 0-12. saat | Teknik sorumlu | Veritabanı erişim logu, sorgu kaydı |
| Geçici tedbirler (oturum iptali, şifre sıfırlama) | 0-24. saat | Yönetici | Yönetici işlem logu |
| Kurul'a bildirim formu | 72. saate kadar | Veri sorumlusu | Başvuru çıktısı, referans numarası |
| İlgili kişilere bildirim | En kısa sürede | Pazarlama + destek | E-posta gönderim logu, site duyurusu |
| Kök neden raporu | 7-30. gün | Teknik sorumlu | Değişiklik kaydı, yama notları |
Kurul'a Ne Yazacağını Bilmeyen Herkes Aynı Yerde Tıkanıyor
Bildirim formunun zor kısmı hukuk dili değil, sayılar. Formda ihlalin ne zaman ve nasıl gerçekleştiğini, etkilenen kişi ve kayıt sayısını, etkilenen veri kategorilerini, olası sonuçları ve aldığın tedbirleri yazman gerekiyor. "Yaklaşık" demek mümkün ama tamamen bilmiyorum demek değil. İşte burada e-pin scripti tarafındaki hazırlığın bedeli ortaya çıkıyor. Hangi tablonun kaç satır olduğunu, o tabloda hangi alanların dolu olduğunu, son 90 günde hangi yönetici hangi dışa aktarımı yaptığını dakikalar içinde çıkarabiliyorsan form yarım saatte dolar. Çıkaramıyorsan üç gün boyunca tahmin üretirsin, sonra da o tahminin yanlış olduğu anlaşıldığında dosyayı güncellemek zorunda kalırsın. İkinci bir düzeltme bildirimi, ilk bildirimden daha kötü görünür.
Bildirim dosyalarında en sık eksik kalan bölümler
- Etkilenen kayıt sayısı 45%
- Tespit anının kanıtı 25%
- Alınan tedbirlerin kaydı 20%
- İlgili kişi bildirim kanıtı 10%
İlgili Kişiye Bildirim: Sessiz Kalmanın Maliyeti Cezadan Büyük
Kurul'a bildirmek tek başına yeterli değil; etkilenen müşterilere de makul en kısa sürede haber vermen gerekiyor. Çoğu işletme bu adımı atlar, çünkü "panik yaratır, satış düşer" diye düşünür. Gerçekte olan şudur: müşteri veriyi başka bir kanaldan öğrenir, yorum sitelerinde ve forumlarda öğrendiğini yazar, marka güveni senin kontrol etmediğin bir anlatı içinde çöker. Kendin duyurursan anlatıyı sen kurarsın. Bildirim metni kısa olmalı; ne sızdı, ne sızmadı, müşterinin ne yapması gerekiyor, sen ne yaptın. Özellikle "kart bilgisi sistemimizde tutulmuyor" gibi bir cümle varsa, bunun doğru olduğundan emin ol. Doğrulanamayan bir rahatlatma cümlesi, ikinci bir ihlal kadar zarar verir. Duyuruyu sitede kalıcı bir sayfada da yayımla; e-posta ulaşmayan müşteri için tek kanıtın o olur.
Sızıntı gününde metin yazmaya çalışmak en kötü fikir. Bugün, sakinken, üç ayrı şablon hazırla: Kurul formu taslağı, müşteri e-postası, site duyurusu. Boşlukları tarih, kayıt sayısı ve veri kategorisi olarak bırak. O gün sadece boşlukları doldurmak, saatler kazandırır.
Scriptinin Log Mimarisi Bildirimi Yazabilir mi?
Bir dijital ürün satış scriptinin güvenlik olgunluğunu tek soruyla ölçebilirsin: "Dün gece 02.14'te kim hangi müşteri kaydını görüntüledi?" Cevap veremeyen yazılım, sızıntı gününde seni yalnız bırakır. Pinova'da bu yüzden kayıt katmanı üç ayrı düzeyde tutulur. Yönetici işlem logu, panelde yapılan her görüntüleme, düzenleme ve silme işlemini kullanıcı, IP ve zaman damgasıyla saklar. Dışa aktarım logu, hangi listenin kim tarafından indirildiğini ayrı tutar; çünkü sızıntıların en sessiz kaynağı budur. Oturum logu ise aynı hesabın farklı cihaz ve konumlardan aynı anda kullanılıp kullanılmadığını gösterir, yani paylaşılmış bayi şifresini yakalar. Üçü birlikte, bildirim formundaki "ihlalin nasıl gerçekleştiği" alanını tahmin değil kanıt hâline getirir.
Sızıntı Sonrası 30 Günlük Onarım Takvimi
Bildirim yaptın, duyuruyu yayımladın, iş bitmedi. Saldırganın elinde e-posta ve telefon listesi varsa, sırada oltalama dalgası vardır; müşterine senin adına "bakiye iadesi" mesajı gider. Bu yüzden onarım takvimi, teknik yamanın ötesine geçmeli. İlk hafta tüm yönetici ve bayi şifrelerini sıfırla, iki adımlı doğrulamayı zorunlu yap, aktif oturumların tamamını düşür. İkinci hafta yetkileri sıfırdan kur; herkesin her şeyi görebildiği bir epin yazılım kurulumu, ihlalin tekrarını garanti eder. Üçüncü hafta yedekleri web kökünün dışına taşı ve erişimini şifrele. Dördüncü hafta kök neden raporunu yaz, dosyaya ekle ve ekibe anlat. Bu rapor, benzer bir olayda "ders aldık" iddianın tek somut kanıtı olur.
| Kontrol | Nerede bakılır | Hazır mı |
|---|---|---|
| Veri envanteri güncel | Panel tablo listesi + alan dökümü | Yılda 2 kez |
| Yönetici işlem logu açık | Güvenlik ayarları | Zorunlu |
| Dışa aktarım kaydı tutuluyor | Rapor modülü | Zorunlu |
| Yedekler web kökü dışında | Sunucu dizin yapısı | Zorunlu |
| Bayi ve personel yetkileri sınırlı | Rol yönetimi | Aylık gözden geçir |
| İki adımlı doğrulama zorunlu | Hesap güvenliği | Zorunlu |
| Bildirim şablonları hazır | Şirket içi doküman | Yılda 1 gözden geçir |
| Ayrılan personel hesapları kapalı | Kullanıcı listesi | Çıkış günü |
Sızıntı gününde dosyanı yazabilecek bir altyapı kur
Pinova, e-pin ve dijital ürün satan işletmeler için log, rol ve dışa aktarım denetimini kutudan çıkar çıkmaz açık getirir. Özellik listesini ve fiyatlandırmayı incele, sonra kararını ver.
Kart bilgisi tutmuyorum, yine de bildirim yapmam gerekir mi?
Evet. Kişisel veri yalnızca kart bilgisi değil; ad, e-posta, telefon, IP, sipariş geçmişi de kişisel veridir. Bunlardan biri yetkisiz kişilerin eline geçtiyse bildirim yükümlülüğü doğar.
Etkilenen kayıt sayısını kesin bilemiyorum, ne yazacağım?
Gerçekçi bir aralık ve bu aralığı nasıl hesapladığını yaz. Sonradan netleştiğinde dosyayı güncelle. Tahmin yerine hiç yazmamak veya sayıyı küçük göstermek, çok daha ağır sonuç doğurur.
Bildirim yapmak beni otomatik olarak cezaya mı sokar?
Hayır. Kararların gösterdiği eğilim tam tersi: zamanında bildirim, şeffaf iletişim ve alınan tedbirlerin belgelenmesi lehte değerlendirilen unsurlardır. Gecikme ve gizleme ise ağırlaştırıcı unsurdur.
Kullandığım satış yazılımı sızıntıya neden olursa sorumluluk kimde?
Müşteriye karşı veri sorumlusu sensin. Bu yüzden yazılım seçiminde log tutma, rol ayrımı ve güncelleme sürekliliği pazarlık konusu olmamalı; sözleşmede işleme şartlarının yazılı olması da gerekir.
Veri sızıntısı, iyi hazırlanmış bir işletme için kötü bir hafta; hazırlıksız bir işletme için ise şirketi kapatan bir olaydır. Aradaki farkı belirleyen şey kahramanlık değil, sıkıcı altyapı: kim neye erişti, kim neyi indirdi, hangi şüphe ne zaman kaydedildi. Bunları bugün açarsan, o gün sadece form doldurursun. Kayıt katmanının gerçek panelde nasıl göründüğünü merak ediyorsan canlı demo üzerinden yönetici işlem loguna ve rol yönetimine kendin bak; ardından kurulum adımına geçmek çok daha kolay bir karar olacak.