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.
☑ 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.
İ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 IncidentReport, 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.
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
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ı).
☑ 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.
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)
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.