1. Veri İhlali (Data Breach) Nedir? KVKK’da Nasıl Ele Alınır?
Veri ihlali (data breach) nedir, KVKK’da nasıl ele alınır? Kısa yanıt: kişisel verinin yetkisiz erişim, ifşa, kayıp veya bozulma gibi bir olayla güvenliğinin zedelenmesidir. Teknik tarafta amaç; olayın “ne olduğunu” hızla anlamak, yayılımı durdurmak, kanıtı korumak ve kapsamı doğru belirlemektir. KVKK bağlamında ise bu teknik çalışma; hukuk ve iletişim ekipleriyle birlikte bildirim ve iletişim akışına bağlanır.
İhlal senaryolarını 4 sınıfta düşünün
- Yetkisiz erişim: panel hesabı ele geçirildi, API anahtarı sızdı
- Yanlış yetkilendirme: RBAC hatasıyla veri listesi görünür oldu
- Yanlış paylaşım/export: veri dışarı aktarıldı, yanlış kişiye gitti
- Altyapı olayı: sunucu açığı, log/backup sızıntısı, ransomware
Otel ve B2B’ye özgü “kritik ekran” örnekleri
- •Otel: rezervasyon/misafir kartı, iletişim bilgileri, talep notları
- •B2B: sözleşme/teklif ekranları, fiyat listeleri, müşteri listeleri
Mini Check
- • “Veri ihlali” tanımı ekipte ortak mı?
- • Kritik sistem ve ekranlar listelendi mi?
- • Olay kaynakları tanımlı mı? (log, alert, şikâyet)
- • Hukuk + iletişim devreye girme eşiği belli mi?
- • Sunucu güvenliği temel kontrolleri hazır mı?
Ne yapmalıyım?
- • 10 dakikalık “ihlal örnekleri” kartı oluşturun (ekip aynı dili konuşsun).
- • Kritik ekranları ve veri türlerini listeleyin.
- • Olay kaynaklarını yazın: log/alert/şikâyet/monitoring.
- • “İlk 60 dakika” hedefini belirleyin (izolasyon + kanıt).
- • Sunucu güvenliğiyle birlikte ele alın: https://dgtlface.com/tr/yazilim/sunucu-guvenlik
2. Incident Response Ekip ve Roller: Kim Ne Yapar?
Planın kalbi roldür; araçlar ikinci sırada gelir. Çünkü olay anında “kim karar verir, kim izole eder, kim iletişimi yönetir” belirsizse, dakikalar içinde kaos oluşur.
Temel roller (teknik + operasyon + iletişim)
- •Incident Commander (IC): karar ve koordinasyon sahibi
- •Tech Lead: izolasyon, analiz, teknik aksiyonlar
- •Forensics/Log Owner: kanıt toplama, log bütünlüğü
- •Ops Owner: iş etkisi ve kesinti yönetimi
- •Legal/Compliance: hukuki çerçeve, bildirim koordinasyonu
- •Comms/PR: iç/dış iletişim (tek ağız)
Otel/B2B uyarlaması
- •Otelde IC çoğu zaman GM/operasyon lideri + IT ile birlikte hareket eder.
- •B2B’de IC genellikle yönetici + IT lideri; sözleşme/teklif tarafı hassas olduğu için iletişim daha kontrollü olmalıdır.
Mini Check
- • Incident Commander belli mi (yedekli)?
- • Teknik izolasyon yetkisi olan kişi/ekip belli mi?
- • Log ve kanıt sahipliği net mi?
- • Hukuk ve iletişim devreye girme kriteri yazılı mı?
- • Tek iletişim kanalı var mı? (Slack/WhatsApp/Bridge)
Ne yapmalıyım?
- • Rol tablosunu 1 sayfada çıkarın (isim + yedek + iletişim).
- • IC’nin karar sınırlarını yazın (ne zaman sistemi kapatır?).
- • Kanıt toplama yetkisini netleştirin.
- • PR/iletişim için tek onay noktası belirleyin.
- • Tatbikat takvimi ekleyin (yılda en az 1).
3. Tespit: Şüpheli Olayı Nasıl Yakalarım?
Veri ihlali tespit edildiğinde teknik ekip ne yapmalı? Kısa yanıt: önce olayın gerçekliğini doğrula, ardından hızlı triage yap ve kanıtı koru. Tespit kaynakları üçlüdür: (1) log/alert, (2) kullanıcı/çalışan şikâyeti, (3) anomali (trafik artışı, export patlaması).
Tespit sinyalleri (örnek)
- •Login başarısız denemelerde ani artış
- •Aynı hesapla farklı ülkelerden giriş
- •Kısa sürede çok sayıda export/download
- •Beklenmeyen admin/rol değişikliği
- •WAF/CDN’de saldırı imzası veya spike
Triage: 15 dakikalık sınıflandırma
- •P1: aktif sızıntı/yayılım ihtimali yüksek
- •P2: şüpheli ama doğrulama gerekiyor
- •P3: düşük riskli, izlemeye alınır
Mini Check
- • Tespit kaynakları net mi (log/alert/şikâyet)?
- • İlk 15 dakika triage şablonu var mı?
- • “Export patlaması” gibi KPI alarmları var mı?
- • Yetki değişikliği ve login olayları loglanıyor mu?
- • Kanıt toplama prosedürü hazır mı?
Ne yapmalıyım?
- • Login/export/rol değişimi için alert eşikleri belirleyin.
- • “P1/P2/P3” triage kartı hazırlayın.
- • Olay ID (ticket) açmadan aksiyon almayın (iz bırakın).
- • Logların bütünlüğünü koruyun (kopya al, erişimi sınırla).
- • KVKK veri güvenliği raporlama ile bağlayın: https://dgtlface.com/tr/raporlama/kvkk-veri-guvenligi
4. İzolasyon: Yayılımı Durdurma ve Erişimi Kesme
İzolasyon, “panikle sistemi kapatmak” değildir; hedefli bir yayılım durdurma aksiyonudur. En büyük risk, olay devam ederken sistemin açık kalmasıdır; ikinci büyük risk ise izolasyon sırasında kanıtı kaybetmektir.
İzolasyon aksiyonları (örnek set)
- •Şüpheli hesabı kilitle / oturumları kapat
- •API anahtarlarını döndür (rotate)
- •WAF kuralı ile saldırı kaynağını blokla
- •Kritik endpoint’leri geçici kapat (rate limit)
- •Export fonksiyonunu geçici devre dışı bırak
Otel/B2B kesinti yönetimi
Otel tarafında rezervasyon akışı kritik olabilir; bu yüzden izolasyon “tam kapatma” yerine kontrollü sınırlama ile yapılabilir (ör. sadece admin panel erişimini kesmek). B2B’de sözleşme/teklif ekranları kritik olduğundan export ve dosya paylaşımlarını anlık kısıtlamak daha mantıklıdır.
Mini Check
- • Hesap kilitleme ve token rotate prosedürü hazır mı?
- • WAF/CDN bloklama yetkisi kimde?
- • Export’u tek tuşla kapatabiliyor musunuz?
- • İzolasyon kararını kim verir (IC)?
- • İzolasyon adımları olay kaydına yazılıyor mu?
Ne yapmalıyım?
- • “Kill switch” listesi çıkarın (export kapat, token rotate, hesap kilitle).
- • WAF/CDN erişimlerini yedekli yapın (tek kişiye bağlı kalmasın).
- • İzolasyon sırasında log snapshot alın (kanıt).
- • Kesinti iletişimini tek kanal üzerinden yönetin.
- • Sunucu güvenliği ile birlikte değerlendirin: https://dgtlface.com/tr/yazilim/sunucu-guvenlik
5. Analiz: Kapsam Tespiti ve Kanıtların Korunması
Analizin hedefi üç soruya cevap vermektir: 1. Ne oldu? (vektör) 2. Ne etkilendi? (sistem/veri/kayıt) 3. Ne zaman başladı/bitti? (timeline)
Kanıt yönetimi: “düzeltmeden önce kopyala”
- •Logların snapshot’ını al
- •Zaman çizelgesini çıkar (login, export, admin değişikliği)
- •Etkilenen kayıt aralığını tespit et
- •Kanıt erişimini sınırla (chain-of-custody mantığı)
Etkilenen kayıtları daraltma stratejisi (key practice)
Erişim/değişiklik logları ve correlation ID kullanıyorsanız, “hangi kullanıcı hangi kayıtları görüntüledi/export etti?” sorusu dakikalara iner. Bu yüzden incident response planı, RBAC + log mimarisiyle birlikte düşünülmelidir.
Mini Check
- • Timeline çıkarma şablonu var mı?
- • Etkilenen sistem listesi hızlı çıkarılabiliyor mu?
- • Audit loglar “kim-ne yaptı” sorusuna yanıt veriyor mu?
- • Kanıt erişimi sınırlandırıldı mı?
- • Analiz bulguları tek yerde toplandı mı? (incident doc)
Ne yapmalıyım?
- • “Timeline” template oluşturun (T0–Tn).
- • Audit logları ve WAF loglarını korele edin.
- • Etkilenen kayıtları daraltın (kapsamı küçültün).
- • Kök neden için düzeltme planı çıkarın (patch, config, RBAC fix).
- • KVKK veri güvenliği raporlama ile bağlayın: https://dgtlface.com/tr/raporlama/kvkk-veri-guvenligi
6. Bildirim ve Koordinasyon: Teknik Ekip Hukuk ve İletişimle Nasıl Çalışır?
Incident response planı neleri içermelidir? Kısa yanıt: roller, iletişim zinciri, tespit–izolasyon–analiz akışı, kanıt yönetimi, karar kriterleri ve post-incident iyileştirme adımları. Bildirim süreleri gibi hukuki detaylar değişken olabilir; bu rehber teknik ekiplerin “doğru veriyle” hukuk ve iletişim ekiplerini beslemesini hedefler.
Teknik ekibin bildirim sürecine katkısı: “net veri”
- •Olay türü ve başlangıç zamanı
- •Etkilenen sistemler
- •Etkilenen veri türleri (kapsam)
- •İzolasyon/düzeltme adımları
- •Devam eden risk var mı?
Post-incident: 7 günlük iyileştirme (sürdürülebilirlik)
- •Root cause fix
- •Log/alert iyileştirmeleri
- •RBAC sıkılaştırma
- •Tatbikat ve doküman güncelleme
- •365 gün refresh planı ve “yılda en az 1 tatbikat” kuralı
Key Data Point (yumuşatılmış): Önceden incident response planı olan kurumlarda, gerçek olay yaşandığında ilk saatlerde yapılan hatalar ve koordinasyon sorunları belirgin şekilde daha az raporlanır; çünkü rol ve iletişim zinciri bellidir.
Mini Check
- • Bildirime gidecek teknik bilgi paketi hazır mı?
- • Hukuk ve iletişim için tek koordinasyon noktası var mı?
- • Olay sonrası “lessons learned” toplantısı planlı mı?
- • Doküman güncelleme ve tatbikat takvimi var mı?
- • İç link hedefleri içerikte bağlandı mı?
Ne yapmalıyım?
- • “Bildirime girdi sağlayan teknik özet” şablonu yazın (1 sayfa).
- • IC + hukuk + iletişim onay akışını netleştirin.
- • Olay kartı/checklist’i herkesin erişebileceği yerde tutun.
- • Yılda en az 1 tatbikat planlayın; sonuçları kaydedin.
- • İlgili sayfalarla bağlayın: https://dgtlface.com/tr/raporlama/kvkk-veri-guvenligi — https://dgtlface.com/tr/veri-analiz-ve-raporlama — https://dgtlface.com/tr/yazilim/sunucu-guvenlik
7. Veri İhlali (Incident Response) Akış & Rol Dağılımı Planlama Şablonunu İndir
Veri İhlali (Incident Response) Akış & Rol Dağılımı Planlama Şablonunu İndir — Yazılım / Incident Response (v1.0)
Bu şablon, veri ihlali anında improvize etmeyi önlemek için ilk 60 dakikayı ve ilk 24 saati netleştirir. Teknik ekip, hukuk ve iletişim ekipleri için rol dağılımı ve swimlane akışını tek sayfada toplar. Kapsam analizi ve kanıt koruma adımlarını standartlaştırır.
Kim Kullanır?
IT/BT + hukuk + iletişim + operasyon liderleri (otel ve B2B).
Nasıl Kullanılır?
- Sistemlerinizi ve kritik ekranları yazın; olay kaynaklarını (log/alert/şikâyet) tanımlayın.
- Rolleri doldurun (IC, Tech Lead, Legal, Comms…) ve iletişim zincirini belirleyin.
- Swimlane akışı olay kartı checklist’iyle birlikte yayımlayın; yılda 1 tatbikat yapın.
Ölçüm & Önceliklendirme (Kısa sürüm)
- ▢ ✅ Olay ID açıldı, kayıt tutuluyor
- ▢ ✅ Triage yapıldı (P1/P2/P3)
- ▢ ✅ İzolasyon aksiyonları uygulandı
- ▢ ✅ Kanıt snapshot alındı, erişim sınırlandı
- ▢ ✅ Kapsam analizi ve timeline çıkarıldı
- ▢ ✅ Teknik özet paketi hazırlandı (hukuk/iletişim için)
- ▢ ✅ Düzeltme planı ve takip metrikleri belirlendi
- ▢ ✅ Tatbikat ve doküman güncelleme takvimi eklendi
PDF içinde: Problem→Kök Neden→Çözüm tablosu + 14 gün sprint planı + önce/sonra KPI tablosu
8. Sonuç: Krizde improvize etmeyin, planla yönetin
Veri ihlalinde başarı; “en hızlı düzeltme” değil, en hızlı doğru koordinasyondur: yayılımı durdurmak, kanıtı korumak, kapsamı doğru çıkarmak ve hukuk/iletişim ekiplerine net veri sunmaktır. Otel ve B2B kurumlarda bu plan önceden yazılı olursa, kriz anındaki hata ve koordinasyon sorunları belirgin şekilde azalır.
Bir Sonraki Adım
Otel ve B2B kurumlarda ilk saatlerdeki aksiyonları netleştirir, koordinasyonu hızlandırır.
Sık Sorulan Sorular
Veri ihlali (data breach) nedir, KVKK’da nasıl ele alınır?▾
Incident response planı neleri içermelidir?▾
Veri ihlali tespit edildiğinde teknik ekip ne yapmalı?▾
Otel ve B2B için veri ihlali akışını nasıl dokümante ederim?▾
İzolasyon sırasında en sık yapılan hata nedir?▾
Neden yılda en az bir tatbikat yapılmalı?▾
İlgili İçerikler