1. Veri ihlali nedir, oteller için tipik örnekler nelerdir?
Veri ihlali; kişisel verinin yetkisiz kişilerce erişilmesi, ifşa edilmesi, kaybolması veya değiştirilmesi gibi olayları kapsar. Otellerde ihlal çoğu zaman “sistem hacklendi” diye başlamaz; süreç/erişim hataları ve insan faktörü öne çıkar. Bu yüzden playbook’un ilk hedefi, “suçlu aramak” değil; olayı soğukkanlı şekilde dokümante etmek olmalıdır.
Otel ölçeğinde en sık 3–5 senaryo
- •Yanlış alıcıya e-posta: oda listesi/kontrat/fatura yanlış kişiye gider
- •Açık terminal: resepsiyon ekranı açık kalır, misafir verisi görünür
- •Kaybolan laptop/USB: içinde misafir listesi veya rapor dosyası olabilir
- •Yetkisiz PMS erişimi: paylaşımlı hesap, zayıf parola veya eski personel erişimi
- •CRM/entegrasyon hatası: yanlış eşleşme ile yanlış kayda veri bağlanması
Mini örnek (Antalya/Belek): Sezon yoğunluğunda ön büro, oda listelerini satış ekibine yollarken CC alanına yanlış e-posta ekler. Bu olay teknik açıdan basit olsa da “kapsam” doğru çıkarılmazsa denetimde zorlanılır. Bu nedenle olay kaydı + gönderim log’ları + etkilenen veri seti listesi kritik hale gelir; özellikle rezervasyon akışında PMS veri ihlali riski ayrıca değerlendirilmelidir.
☑ Mini Check (Senaryo tanımlama):
- • Olay “erişim mi, ifşa mı, kayıp mı?” net mi?
- • Etkilenen veri seti (kimlik/iletişim/rezervasyon) yazıldı mı?
- • Etkilenen sistem(ler) (PMS/e-posta/terminal) listelendi mi?
Ne yapmalıyım? :
- • Olay tipini sınıflandır (mail/terminal/cihaz/PMS/entegrasyon).
- • Etkilenen veri setlerini 3–6 kalemde yaz.
- • İhlalin başlangıç zamanını “tahmini” bile olsa belirt (timeline için).
2. Veri ihlali sonrasında kayıt ve raporlama süreci nasıl yönetilir?
Bu bölümün ana prensibi: Önce kayıt, sonra analiz. Çünkü iyi kayıt yoksa, doğru analiz ve doğru aksiyon çıkmaz. Ayrıca “kayıt kalitesi” denetimde en değerli varlıktır; bu nedenle olay akışını log tabanlı ihlal analizi perspektifiyle genel veri analiz mimarisi içine yerleştirmek gerekir.
İlk 24 saatte atılması gereken 7 adım
- Olayı başlat (Incident ID): tekil olay numarası ver, zaman damgası koy
- Kapsamı dondur: ilgili hesap/cihaz/süreçte yeni değişiklikleri minimize et
- İlk bilgi toplama: kim fark etti, ne gördü, hangi sistem? (kısa not)
- Log ve delil toplama: e-posta gönderim kaydı, PMS erişim log’u, cihaz log’u
- Timeline çıkar: olay öncesi/olay anı/olay sonrası kronoloji
- Etkilenen veri setlerini listele: hangi kategoriler, yaklaşık kayıt sayısı (Varsayım: tahmini)
- İlk aksiyonları başlat: parola reset, erişim kısıt, terminal kilidi, yanlış mail geri çağırma girişimi (mümkünse)
Not: “Dış bildirim” adımlarının detayına girmeden, bu rehberde kayıt/kanıt/iyileştirme odağı korunur.
Olay kayıt formu (Incident Report) neden bu kadar kritik?
AIO mantığını net kuralım: Incident → documentedBy → IncidentReport İyi kurgulanmış bir olay kayıt formu, sadece “ne oldu?” değil, “ne yaptık?” ve “ne geliştirdik?” sorusunun kanıtıdır. İyi tutulan rapor, gelecekte kontrol setlerini tasarlarken referans olur: IncidentReport → guides → future controls
☑ Mini Check (ilk 24 saat):
- • Olay ID + zaman damgası var mı?
- • Loglar “değişmeden” kopyalandı mı? (bütünlük)
- • Timeline çıkarıldı mı?
- • İlk aksiyonlar kayıt altına alındı mı?
Ne yapmalıyım? :
- • Olay formunu standartlaştır (her olay aynı şablon).
- • Log toplama “kaynağa göre” checklist’le yönet (e-posta/PMS/terminal).
- • 48 saat içinde “aksiyon planı” ekle (sahip + tarih).
3. İhlal tespitinde log, kayıt ve delil toplama nasıl yapılır?
İhlalin kapsamını “log’lardan okumak” çoğu otelde atlanan adımdır. Oysa PMS, e-posta ve cihaz log’ları; olayın ne zaman başladığını, kimlerin eriştiğini ve hangi verinin etkilenmiş olabileceğini anlamanın en hızlı yoludur. Bu yüzden log tabanlı ihlal analizi operasyonel playbook’un merkezinde durmalıdır.
Hangi log’lar toplanmalı? (pratik liste)
- •E-posta senaryosu: gönderilen mail, alıcı listesi, gönderim zamanı, varsa sistem gönderim kaydı
- •PMS senaryosu: giriş log’u (user/time/ip), erişilen kayıtlar, değişiklik log’u
- •Terminal/cihaz senaryosu: oturum açma kapanma, ekran kilidi politikası, cihaz envanteri
- •Entegrasyon senaryosu: API çağrı log’ları, export dosyaları, paylaşım kanalları
- •Yetki yönetimi: rol matrisi, aktif kullanıcı listesi, son parola değişimleri
Delil bütünlüğü (neden önemli?)
Delil toplarken amaç “tekno-dedektif” olmak değil; olayın kronolojisini ve kapsamını tutarlı şekilde çıkarabilmektir. Bu yüzden: • Log’ları “ham” olarak saklayın (orijinal) • Kopya üzerinde analiz yapın • Kim aldı, ne zaman aldı, nerede saklandı: kısa zincir kaydı tutun Veri kaybı veya sistem bozulması ihtimali varsa yedekleme ve restore kaydı da aynı olay zincirinin parçası olarak belgelenmelidir.
Mini örnek: Side’de bir otelin PMS hesabı yetkisiz kullanıldı şüphesi var. PMS login log’ları yoksa, olay “iddia” olarak kalır. Log varsa; IP/time/user üzerinden olay çerçevelenir ve kontrol aksiyonu netleşir (MFA, kişi bazlı hesap, rol kısıtı). Çok kanallı yapılarda PMS ve OTA olay senaryoları ayrıca izlenmelidir.
☑ Mini Check (log toplama):
- • PMS login + değişiklik log’u alındı mı?
- • E-posta gönderim kanıtı eklendi mi?
- • Cihaz envanteri (kaybolan laptop) kaydı var mı?
- • Log saklama yeri ve erişim rolü belirlendi mi?
Ne yapmalıyım? :
- • Olay türüne göre log checklist’i aç (mail/PMS/cihaz).
- • “Ham log” + “analiz kopyası” ayrımı yap.
- • Log kapsamı yetersizse, bunu rapora “geliştirme aksiyonu” olarak yaz.
4. Olay kayıt formunda hangi alanlar olmalı?
Aşağıdaki form alanları, otel ölçeğinde pratik ve yeterli bir kayıt standardı sağlar. (Amaç: kanıt üretmek, aksiyonu yönetmek, tekrar riskini azaltmak.)
Örnek olay kayıt formu alanları (tablo)
| Alan | Açıklama | Örnek |
|---|---|---|
| incident_id | Olay kimliği | INC-2026-001 |
| discovered_at | Ne zaman fark edildi | 2026-01-12 11:20 |
| discovered_by_role | Kim fark etti (rol) | Ön Büro / IT |
| incident_type | Olay tipi | Wrong Email / Unauthorized Access |
| systems_affected | Etkilenen sistemler | PMS, Email |
| data_sets | Veri setleri | İletişim, Rezervasyon |
| estimated_scope | Tahmini kapsam | Varsayım: ~200 kayıt |
| timeline | Kronoloji | T0…T+24h |
| logs_collected | Toplanan log listesi | PMS login log, mail evidence |
| immediate_actions | İlk aksiyonlar | Parola reset, erişim kısıt |
| mitigation_plan | Azaltım planı | MFA, rol matrisi |
| owner | Sorumlu | IT Manager |
| due_dates | Tarihler | 7 gün / 30 gün |
| closure_notes | Kapanış | Kontrol devrede |
☑ Mini Check (form yeterliliği):
- • Olay tipi ve sistemler net mi?
- • Log listesi “ne topladık” olarak yazılı mı?
- • Aksiyonların sahibi ve tarihi var mı?
- • “Kapanış notu” için yer var mı?
Ne yapmalıyım? :
- • Bu formu tek sayfalık standart yapın.
- • Her olayda “owner + due date” zorunlu olsun.
- • Kapanışta “öğrenim + kontrol” maddesi ekleyin.
5. Olay sonrası iyileştirme ve önleyici aksiyonlar nasıl raporlanmalı?
İyi kayıt tutulan ihlallerin en büyük faydası, tekrar riskini azaltan kontrol setlerinin çıkarılmasıdır. Olay raporu, sadece “olay bitti” dememeli; “hangi kontrol eklendi ve nasıl doğruladık?” demelidir. Bu aşamada sunucu güvenliği ve olay kaydı kontrolleri ile KVKK incident response dokümantasyonunun birlikte düşünülmesi gerekir.
Teknik aksiyon örnekleri (kontrol seti)
- •Rol bazlı yetki matrisi + kişi bazlı hesap
- •MFA (mümkünse) + güçlü parola politikası
- •Otomatik ekran kilidi (resepsiyon)
- •PMS ve e-posta olay loglarının kapsamını artırma
- •Sunucu güvenliği ve izleme iyileştirmeleri
Organizasyonel aksiyon örnekleri
- •Yanlış mail önleme prosedürü (kritik mail’lerde çift kontrol)
- •Sezon başlangıcı onboarding eğitimi (açık ekran, veri minimizasyonu)
- •Export dosyaları için paylaşım standardı
- •Olay yönetimi mini akışı (kim-kimi-ne zaman)
Aksiyon planı checklist’i (kapanış standardı)
- •Kök neden belirlendi (insan/süreç/teknik)
- •Kontrol eklendi (mitigation)
- •Kanıt üretildi (log/policy/konfigürasyon)
- •Eğitim/duyuru yapıldı
- •30 gün sonra yeniden değerlendirme yapıldı (risk skoru)
PMS ve OTA tarafı kadar telefon, WhatsApp, e-posta ve form temas noktaları da olay sonrasında kanıt üretir; bu yüzden çağrı merkezi olay kayıtları aynı playbook içinde ele alınmalı, süreç detayları için KVKK Veri Güvenliği Raporlama hakkında sık sorulan sorular sayfası da referans alınmalıdır.
6. Veri İhlali Olay Kayıt Formu Şablonunu İndir — Veri Analizi & Raporlama (v1.0)
Veri İhlali Olay Kayıt Formu Şablonunu İndir — Veri Analizi & Raporlama (v1.0)
Bu şablon, otel veri ihlallerinde ilk 24 saat içinde olayın panikle değil, standart bir süreçle yönetilmesini sağlar: olay kimliği, timeline, log/delil listesi, etkilenen veri setleri ve aksiyon planı tek formda toplanır. Amaç; KVKK denetimlerinde “nasıl öğrendik, ne yaptık, ne geliştirdik?” sorularına net ve kanıtlı yanıt verebilmektir.
Kim Kullanır?
GM/otel sahibi, IT/teknik ekip lideri, ön büro yöneticisi (hukuk ekibiyle koordinasyon önerilir).
Nasıl Kullanılır?
- Olay anında Incident ID açın ve ilk bilgileri (kim/ne/nerede) 10 dakikada yazın.
- Log/delil listesini oluşturun; ham log’u saklayıp kopya üzerinde analiz yapın.
- 48 saat içinde aksiyon planını ekleyin (sahip+tarih) ve 30 gün sonra kapanış notunu tamamlayın.
Ölçüm & Önceliklendirme (Kısa sürüm)
- ▢ ✅ Olay ID + zaman damgası var
- ▢ ✅ Timeline (T0 → T+24h) çıkarıldı
- ▢ ✅ Ham log saklandı, analiz kopyası ayrıldı
- ▢ ✅ Aksiyon planı owner + due date ile yazıldı
- ▢ ✅ 30 gün sonra yeniden değerlendirme planlandı
PDF içinde: Problem→Kök Neden→Çözüm tablosu + 14 gün sprint planı + önce/sonra KPI tablosu
Bir Sonraki Adım
Olay kaydı, log analizi ve aksiyon planını otelinize özel playbook’a dönüştürelim.