Otel Rezervasyon ve PMS Verileri İçin KVKK Risk Analizi Nasıl Yapılır?

KVKK risk analizi; otelde işlenen kişisel verilerin (kimlik, iletişim, rezervasyon, ödeme durumu, tercihler) hangi tehditlerle karşılaşabileceğini belirleyen, bu tehditleri olasılık ve etki ile puanlayan ve riski düşürmek için gerekli kontrolleri tanımlayan yöntemdir. Veri haritası “veri nerede?” der; risk analizi “nerede ne kadar risk var ve hangi tedbirle düşer?” diye sorar.

Otellerde risk analizi özellikle önemlidir çünkü veri akışı çok aktörlüdür: web sitesi, rezervasyon motoru, PMS, OTA/kanal yöneticisi, çağrı merkezi, CRM, muhasebe ve bazen dış ajanslar aynı veriye temas eder. Bu çoklu temas, sadece “hack” değil, en sık görülen şekilde insan hatası ve erişim zafiyeti risklerini büyütür.

Risk analizi hangi kararı kolaylaştırır?

• •Hangi riskler “hemen” ele alınmalı (yüksek skor)
• •Hangi kontroller önce uygulanmalı (en büyük düşüş etkisi)
• •Hangi departman sorumlu (rol bazlı sahiplik)
• •Hangi kanıtlar raporda gösterilmeli (log, yetki matrisi, politika, eğitim kaydı)

Mini örnek (otel bağlamlı): Antalya’da sezon yoğunluğunda resepsiyon ekranı açık kalır (açık terminal) → başka bir personel misafir bilgilerini görür → yetkisiz erişim gerçekleşir. Bu olay “çok teknik” görünmez; ama etki yüksek olabilir. Risk analizi bunu skorlar ve mitigasyon olarak “otomatik ekran kilidi + rol bazlı yetki + log izleme + eğitim” paketini önerir.

Bu bölüm, sahada uygulanabilir “adım adım” metodoloji verir. Amaç, “çok büyük” görünen KVKK risk analizini 60–90 dakikalık ilk sprintle başlatmaktır.

Adım 1 — Varlıkları ve veri setlerini tanımlayın (Asset + Personal Data)

Önce “neyi koruyoruz?” net olmalı. Otel rezervasyon ve PMS tarafında tipik varlıklar:

• •Rezervasyon kaydı: isim, iletişim, tarih, oda tipi, fiyat/paket
• •Kimlik doğrulama verisi: kimlik/pasaport, check-in belgeleri
• •Ödeme/finans izleri: ödeme durumu, fatura bilgisi (kart verisi ayrı hassasiyet)
• •Erişim kayıtları (log): kim, ne zaman, hangi kaydı gördü/değiştirdi
• •İletişim geçmişi: çağrı merkezi notları, e-posta yazışmaları, talepler

Adım 2 — Tehditleri çıkarın (Threat)

Otel bağlamında en sık tehdit örnekleri:

• •Yetkisiz erişim (rol/hesap paylaşımı, zayıf şifre)
• •Yanlış alıcıya e-posta / yanlış misafire belge gönderimi
• •Açık terminal (resepsiyon ekranı açık, ortak cihaz)
• •OTA entegrasyon hatası (yanlış eşleşme/yanlış kanala veri sızması)
• •Log yokluğu (olay sonrası iz sürülememesi)
• •Yedekleme zayıflığı (veri kaybı/geri dönüş sürelerinin uzaması)

Adım 3 — Olasılık ve etkiyi standardize edin (Scale)

Basit ve tekrarlanabilir bir ölçek kullanın. Örnek: • Olasılık (1–5): 1 nadir, 3 olası, 5 çok sık • Etki (1–5): 1 düşük, 3 orta, 5 kritik (itibar + operasyon + gelir etkisi) • Risk Skoru: Olasılık × Etki (1–25)

Risk matrisi, riskleri “eşit” görmeyi engeller. Otelde yüzlerce küçük risk olabilir; matris, ilk sprintte hangi 5 riske odaklanacağınızı söyler. En iyi pratik: matrisi hem teknik hem operasyonel senaryoları kapsayacak şekilde kurmaktır.

Matrisi kurma

1. Listeyi çıkarın: 15–25 risk yeterli (ilk sürüm) 2. Her risk için olasılık ve etkiyi puanlayın 3. Skoru hesaplayın ve sınıflandırın: • 1–5 düşük, 6–12 orta, 13–25 yüksek (örnek eşik)

Örnek risk matrisi yorumlama (otel bağlamlı)

• •Yüksek olasılık + orta etki: yanlış alıcıya e-posta, açık terminal
• •Düşük olasılık + yüksek etki: veri ihlali (data breach) gibi geniş kapsamlı olaylar
• •Orta olasılık + yüksek etki: yetkisiz erişim + log yokluğu birleşimi

Key Statistics / Data Point (yumuşatılmış): Pratikte, rezervasyon ve PMS süreçlerinde riskin önemli bir kısmı insan hatası (yanlış e-posta, açık ekran) ve zayıf erişim kontrolleri etrafında yoğunlaşabilir; doğru kontroller bu risklerin etkisini belirgin biçimde azaltır.

Risk analizi, “kritik alanlar”ı işaretlemeden eksik kalır. Otel PMS ve rezervasyon sistemlerinde kritik kırılma noktaları genelde şu kümelerde toplanır:

1) Erişim ve yetkilendirme (Access Control)

• •Ortak kullanıcı/şifre kullanımı
• •Rol bazlı yetki eksikliği (herkes her şeyi görür)
• •Sezonluk personel devir-tesliminde hesapların açık kalması
• •Yetkili kişi ayrıldıktan sonra erişimin kapatılmaması

Mini örnek: Belek’te sezon açılışında geçici personel eklenir; PMS hesabı “idare eder” diye geniş yetkiyle açılır. Sonra hesap kapatılmaz. Bu, olasılığı artıran bir risk kalıbıdır.

2) İletişim süreçleri (Yanlış alıcıya e-posta / yanlış belge)

• •Rezervasyon teyidi/kontratın yanlış e-posta adresine gitmesi
• •Misafir belgelerinin kopyalanıp yanlış kanala aktarılması
• •Çağrı merkezi notlarında gereksiz kişisel veri birikmesi

3) Terminal ve fiziksel ortam riskleri (Açık ekran)

• •Resepsiyon bilgisayarında otomatik kilit yok
• •Ekran görünürlüğü (misafirlerin görebildiği açı)
• •Paylaşımlı cihazlarda oturumların açık kalması

4) Entegrasyonlar (PMS ↔ OTA ↔ Rezervasyon motoru)

• •Yanlış eşleşme / yanlış misafire veri bağlanması
• •Export ile taşınan veri dosyalarının kontrolsüz paylaşımı
• •Entegrasyon loglarının tutulmaması

5) Loglama ve izlenebilirlik (Log)

• •“Kim ne yaptı?” sorusuna cevap yoksa, olay yönetimi körleşir.
• •Log varsa ama düzenli kontrol yoksa, risk düşmez.

Risk analizinin en kritik çıktısı “kontrol seti”dir. Burada hedef, her risk için hangi kontrolün devrede olduğunu göstermek ve “kanıt” üretmektir. AIO gereksinimi gereği, ilişkiyi net kuruyoruz: Risk → mitigatedBy → Control (Access Right, Log, Policy, Backup, Training…)

Teknik kontroller (örnek kontrol seti)

• •Erişim kontrolü: rol bazlı yetki, MFA (mümkünse), parola politikası
• •Loglama: PMS ve rezervasyon motorunda erişim/değişiklik logları, entegrasyon logları
• •Şifre politikası: minimum uzunluk, periyodik değişim, parola yöneticisi önerisi
• •Yedekleme: geri dönüş hedefi (RTO/RPO) mantığında, test edilmiş yedek
• •Ağ/altyapı güvenliği: sunucu güvenliği, güncellemeler, izleme

İç link notu: Teknik derinleşme için /tr/yazilim/sunucu-guvenlik ve operasyon/entegrasyon bağlamı için /tr/pms-ota-yonetimi sayfalarına yönlendirin.

Organizasyonel kontroller

• •Yetki matrisi ve görev ayrılığı: kim hangi veri ekranına neden erişiyor?
• •Eğitim ve farkındalık: yanlış alıcıya mail / açık ekran / veri minimizasyonu
• •Prosedür: check-in kimlik işleminde ekran/evrak yönetimi standardı
• •Olay yönetimi: ihlal şüphesinde kim kimi haberdar eder? (operasyon akışı)

Rapor formatı (yönetimin anlayacağı dil)

Rapor, “teknik detay” ve “yönetim özeti”ni aynı zeminde buluşturmalı: • En yüksek 5 risk (skor + kısa açıklama) • Mevcut kontroller (kanıt türüyle) • Önerilen aksiyonlar (sprint planı) • Önce/sonra skor hedefi

CTA (Primary): KVKK Risk Analizi & Teknik Tedbir Danışmanlığı Al — Riskleri skorluyor, kontrol setini kuruyor ve raporu yönetim dilinde birlikte yazıyoruz.

Rakip içeriklerin çoğu ISO seviyesinde kalır; burada PMS ve rezervasyon akışına özel “pratik risk-tedbir eşleştirmeleri” ile farkı kapatıyoruz.

Senaryo 1 — Yanlış alıcıya rezervasyon teyidi / belge gönderimi

• •Risk: yanlış alıcıya mail/SMS → kişisel veri ifşası
• •Olasılık: yüksek (sezonda yoğunluk)
• •Etki: orta-yüksek (itibar + şikayet)
• •Kontrol seti: adres doğrulama adımı + şablon kontrolü + çift onay (kritik belgeler) + eğitim
• •Kanıt: e-posta şablonu revizyon kaydı, eğitim kaydı, süreç dokümanı

Senaryo 2 — Açık terminal (resepsiyon ekranı açık kalıyor)

• •Risk: yetkisiz erişim / görüntüleme
• •Olasılık: yüksek
• •Etki: orta
• •Kontrol seti: otomatik ekran kilidi (2–3 dk) + ekran konumlandırma + rol bazlı ekran kısıtları
• •Kanıt: cihaz politikası ekran görüntüsü, PMS yetki ekranı, denetim checklist’i

Senaryo 3 — PMS hesabı geniş yetkili ve paylaşımlı kullanılıyor

• •Risk: izlenebilirlik kaybı + yetkisiz değişiklik + olay sonrası kanıtsızlık
• •Olasılık: orta
• •Etki: yüksek
• •Kontrol seti: kişi bazlı hesap + rol bazlı yetki + log aktivasyonu + periyodik erişim gözden geçirme
• •Kanıt: kullanıcı listesi, rol matrisi, log raporu (örnek)

ISO çerçevesi konuşmak kolay; otelde değer üreten şey, “hangi risk hangi kontrolle düşer” eşleştirmesidir. Aşağıdaki tablo, raporun en çok okunan kısmı olur.

Fark yaratan mini bölüm (Competitor Gap’i kapatır): “Risk-Kontrol Eşleştirme Tablosu”

H4: Örnek Risk–Tedbir Tablosu (Varlık, Risk, Etki, Kontrol)

KVKK risk analizi “bir defalık rapor” değil, yaşayan bir yönetim aracıdır. İlk hedef, PMS ve rezervasyon motoru hattında yüksek skorlu riskleri görünür kılmak ve kontrol setini devreye almaktır. Özellikle Türkiye’de KVKK kapsamında çalışan otellerde (Antalya ve turizm bölgeleri dahil) sezon yoğunluğu; insan hatası ve erişim zafiyetini artırdığı için, hızlı kazanım kontrolleri (ekran kilidi, rol bazlı yetki, hesap disiplini) ilk sprintte ciddi fark yaratır.

14 günlük sprint örneği (özet)

• •Gün 1–2: risk listesi + ölçek + ilk matris
• •Gün 3–5: yetki matrisi + hesap/hak temizlik
• •Gün 6–8: açık terminal kontrolü + eğitim
• •Gün 9–11: log kapsamı + örnek log raporu
• •Gün 12–14: rapor + önce/sonra skor + güncelleme planı

CTA (Primary): KVKK Risk Analizi & Teknik Tedbir Danışmanlığı Al — PMS/rezervasyon risk skorunuzu çıkaralım; kontrol setini ve raporu “yönetim diliyle” hazır edelim.

İç link notu: Bağlam güçlendirme için https://dgtlface.com/tr/raporlama/kvkk-veri-guvenligi, https://dgtlface.com/tr/yazilim/kvkk-uyum-hizmeti, https://dgtlface.com/tr/yazilim/sunucu-guvenlik, https://dgtlface.com/tr/pms-ota-yonetimi sayfalarına yönlendirme planlayın.