1. Veri işleyen ve tedarikçi risk analizi nedir?
Vendor risk analizi, otelin misafir verisini işleyen üçüncü tarafların (vendor) risk seviyesini ölçmek ve yönetmektir. Bu analiz, “kötü vendor var mı?” gibi sezgisel sorudan; “hangi kriterde risk yüksek ve hangi aksiyonla düşer?” sorusuna geçiş sağlar. KVKK bağlamında kritik ayrım şudur: Otel çoğu senaryoda veri sorumlusu, vendor ise veri işleyen rolündedir; bu rol ayrımı risk yönetiminin çerçevesini belirler.
AIO mantığı:
Vendor → processes → hotel guest data with certain risk level
Bu yüzden vendor risk raporu; verinin vendor’a hangi kanaldan gittiğini, vendor’ın hangi kontrollerle işlediğini ve risk skorunu göstermek zorundadır.
Otel için tipik veri işleyen/vendor örnekleri
- •OTA platformları (rezervasyon akışı, misafir bilgileri)
- •PMS sağlayıcısı (misafir profili, rezervasyon, operasyon verisi)
- •Barındırma/bulut (sunucu, veri tabanı, yedekleme)
- •Çağrı merkezi iş ortağı (iletişim, talep, teklif, notlar)
- •E-posta/SMS sağlayıcıları (kampanya, transactional mesajlar) (Varsayım: varsa)
Mini örnek (Antalya)
Yabancı menşeli bir PMS ile çalışan otelde veri lokasyonu (yurt içi/yurt dışı) ve loglama/izlenebilirlik seviyesi, risk skorunu belirgin etkiler. Bu nedenle “vendor risk” raporu, lokasyon + kontrol seti üzerinden önceliklendirme yapar.
☑ Mini Check (vendor risk tanımı)
- •Vendor listesi çıkarıldı mı (OTA, PMS, call center, hosting)?
- •Her vendor için “hangi veri seti işleniyor?” yazıldı mı?
- •Lokasyon + güvenlik + SLA kriterleri tanımlı mı?
Ne yapmalıyım?
- • Vendor envanteri çıkarın (kim, ne işliyor).
- • Risk kriterlerini standardize edin (aşağıda).
- • Skorla ve ilk 3 vendor’a aksiyon planı yazın.
2. Oteliniz için tedarikçi risk raporunu nasıl hazırlarsınız?
Bu bölüm “uygulanabilir” bir çerçeve verir: kriter seti, puanlama ve rapor formatı.
Adım 1 — Vendor envanteri ve veri işleyen haritası çıkarın
- •Vendor adı + hizmet türü (OTA/PMS/Call Center/Hosting)
- •İşlenen veri setleri (kimlik/iletişim/rezervasyon/ödeme durumu)
- •Veri akışı (otel → vendor → alt vendor’lar) (Varsayım: sub-processor varsa)
Adım 2 — Risk kriterlerini belirleyin (kriter seti)
Temel kriter grupları (sheet ile uyumlu):
- •Lokasyon: yurt içi / yurt dışı (ve operasyonel etkisi)
- •Güvenlik kontrolleri: şifreleme, erişim kontrolü, loglama, yedekleme
- •SLA & operasyon: kesinti, destek, olay yönetimi yanıt süresi
- •Sözleşmesel çerçeve (yüksek seviye): veri işleme sözleşmesi var mı (detaya girmeden)
Not: Bu içerik hukuki sözleşme maddelerine girmez; “var/yok ve operasyonel kanıt” üzerinden ilerler.
Adım 3 — Risk skoru ve önceliklendirme (örnek ölçek)
Basit ve yönetilebilir bir model:
- •Her kriter 0–5 arası puan (0 iyi, 5 riskli gibi)
- •Toplam skor = kriter toplamı
- •Eşik: düşük/orta/yüksek (örnek)
Mini örnek
- •Lokasyon riski yüksek (yurt dışı) + loglama zayıf + SLA belirsiz → yüksek skor
- •Lokasyon orta + şifreleme güçlü + loglama var + SLA net → orta/düşük skor
☑ Mini Check (metodoloji)
- •Kriterler 3–4 grup altında toplandı mı?
- •Puanlama aynı ölçekle yapılıyor mu?
- •Skor çıktısı aksiyon planına bağlanıyor mu?
Ne yapmalıyım?
- • Önce “basit skor” ile başlayın; mükemmelleştirmeyin.
- • İlk raporda sadece 5–10 vendor değerlendirin.
- • Sonra sub-processor ve entegrasyonları ekleyin.
3. Tedarikçi risk kriterleri (lokasyon, güvenlik, SLA) nasıl seçilir?
Kriter seçiminin amacı “her şeyi ölçmek” değil; riskin en çok toplandığı alanları görünür kılmaktır. Otel özelinde pratikte üç alan belirleyicidir: lokasyon, güvenlik/izlenebilirlik, operasyonel süreklilik (SLA).
Lokasyon kriteri (yurt içi/yurt dışı)
- •Veri nerede işleniyor/saklanıyor? (yüksek seviye)
- •Vendor’ın alt tedarikçileri var mı? (Varsayım)
- •Turizm bölgelerinde (Antalya/Belek) sezon yoğunluğu nedeniyle “kesinti” ve “destek” etkisi büyür
Güvenlik kriteri (şifreleme, loglama, erişim)
- •Şifreleme: veri aktarımında ve depoda (yüksek seviye)
- •Loglama: erişim ve kritik işlemler izlenebilir mi?
- •Erişim: rol tabanlı kontrol, admin erişim sınırı (Varsayım)
SLA kriteri (operasyonel risk)
- •Kesinti süreleri ve destek kanalları
- •Olay yönetimi: ihlal/şüpheli durumda kim, ne kadar sürede yanıt verir?
- •Change yönetimi: kritik güncellemeler nasıl planlanır?
Mini örnek (Side)
Çağrı merkezi iş ortağı yoğun dönemde CRM üzerinden misafir verisine erişiyor; eğer erişim logları vendor tarafında görünür değilse, olay incelemesi uzar. Bu nedenle “loglama/izlenebilirlik” kriteri yüksek ağırlıkla puanlanır.
☑ Mini Check (kriter seçimi)
- •Lokasyon bilgisi raporda var mı?
- •Loglama/izlenebilirlik kriteri ölçülüyor mu?
- •SLA/olay yanıtı kriteri var mı?
Ne yapmalıyım?
- • Lokasyon + loglama + SLA’yı “çekirdek” kriter yapın.
- • Her vendor için 1 sayfalık özet üretin (risk + aksiyon).
- • Yüksek skorlu vendor’lara aksiyon planı tanımlayın.
4. Tedarikçi risk matrisi nasıl hazırlanır? (Örnek tablo)
Bu tablo, yönetim için en hızlı “nereden başlamalıyız?” cevabını verir.
| Vendor | Tür | İşlenen Veri | Lokasyon | Güvenlik (0–5) | Loglama (0–5) | SLA (0–5) | Toplam | Öncelik | Aksiyon |
|---|---|---|---|---|---|---|---|---|---|
| OTA-A | OTA | Rezervasyon+İletişim | Yurt dışı | ||||||
| PMS-B | PMS | Misafir+Rezervasyon | Yurt dışı/yurt içi | ||||||
| CC-C | Call Center | İletişim+Not | Yurt içi | ||||||
| Host-D | Hosting | DB/Backup | Yurt içi |
Varsayım: Skorlar otelin kendi kriter ağırlıklarıyla doldurulacaktır.
Risk skoru çıktılarını aksiyona bağlama
- •Yüksek risk: ek teknik kontrol + sık review + alternatif değerlendirme
- •Orta risk: kontrol iyileştirme planı + SLA netleştirme
- •Düşük risk: rutin review + yılda 1 denetim paketi güncelleme
5. KVKK raporlarında tedarikçi risk görünümü nasıl sunulur?
KVKK rapor setinde vendor risk görünümü; “liste” değil, önceliklendirilmiş yönetim çıktısı olmalıdır. Pratik paket:
- Vendor envanteri (kim, ne işliyor?)
- Risk matrisi (skor + öncelik)
- Yüksek riskli 3 vendor için aksiyon planı (owner + tarih)
3 örnek tedarikçi risk senaryosu
- Senaryo: Yurt dışı PMS + belirsiz loglama → Risk: olay inceleme uzar → Aksiyon: log kapsamı kanıtı + erişim raporu talebi
- Senaryo: OTA’da veri aktarımı çok kanallı → Risk: veri seti büyür → Aksiyon: veri minimizasyonu + aktarım noktalarını haritalama
- Senaryo: Çağrı merkezi export yapıyor → Risk: kontrolsüz kopya → Aksiyon: export log + prosedür + rol kısıtı
İç link notu: Bu içerik /tr/raporlama/kvkk-veri-guvenligi ile bağlanmalı; teknik hazırlık için /tr/yazilim/kvkk-uyum-hizmeti ve entegrasyon bağlamı için /tr/pms-ota-yonetimi sayfalarına yönlendirilmelidir.
6. Tedarikçi Risk Matrisi & Rapor Şablonunu İndir — Veri Analizi & Raporlama (v1.0)
Tedarikçi Risk Matrisi & Rapor Şablonunu İndir — Veri Analizi & Raporlama (v1.0)
Bu audit sheet, otellerin OTA, PMS sağlayıcısı, hosting ve çağrı merkezi gibi veri işleyen tedarikçileri tek çerçevede değerlendirmesini sağlar. Lokasyon, güvenlik (şifreleme/loglama) ve SLA kriterleriyle risk skoru üretir; yüksek riskli vendor’lar için aksiyon planını (owner+tarih) rapora bağlar. Amaç; KVKK raporlarına “vendor risk görünümü” eklemek ve önceliklendirmeyi netleştirmektir.
Kim Kullanır?
GM/otel sahibi, IT/teknik ekip, satınalma/operasyon lideri, ajans yöneticisi.
Nasıl Kullanılır?
- Vendor envanterini çıkarın ve işlenen veri setlerini yazın.
- Kriterleri 0–5 ölçeğinde puanlayıp toplam skoru hesaplayın.
- İlk 3 yüksek riskli vendor için aksiyon planı oluşturun ve çeyreklik review takvimi koyun.
Ölçüm & Önceliklendirme (Kısa sürüm)
- ▢ ✅ A) Ölçek Tanımı
- ▢ ✅ 0–5 puan: 0 düşük risk, 5 yüksek risk (Varsayım: kurum içi ağırlıklandırma yapılabilir)
- ▢ ✅ Toplam skor: kriter toplamı
- ▢ ✅ Öncelik: Yüksek / Orta / Düşük (eşik kurum tarafından belirlenir)
- ▢ ✅ B) Vendor Envanteri ve Skor Tablosu
- ▢ ✅ C) Kırmızı/Sarı/Yeşil Yorum Alanları
- ▢ ✅ Kırmızı (yüksek risk): __________________________
- ▢ ✅ Sarı (orta risk): ______________________________
- ▢ ✅ Yeşil (düşük risk): _____________________________
- ▢ ✅ D) İlk 10 Aksiyon Listesi (owner + tarih)
- ▢ ✅ (Opsiyonel) Alternatif vendor araştırması başlatıldı
- ▢ ✅ E) Öncesi/Sonrası KPI Tablosu
- ▢ ✅ Deliverables
- ▢ ✅ Vendor risk matrisi (skor + öncelik)
- ▢ ✅ İlk 10 aksiyon listesi
- ▢ ✅ Çeyreklik review planı
PDF içinde: Problem→Kök Neden→Çözüm tablosu + 14 gün sprint planı + önce/sonra KPI tablosu
Bir Sonraki Adım
Vendor matrisinizi puanlayıp, ilk 90 gün aksiyon planını birlikte çıkaralım.