KVKK Denetimine Hazırlık: Oteller İçin Veri Raporlama Checklist’i

Denetimde talep edilen şey çoğu zaman “tek bir dosya” değil; otelin veri işleme süreçlerini kanıtlayan pakettir. Bu paketin omurgası; (1) veri envanteri ve veri haritası, (2) erişim ve log kanıtları, (3) rıza/consent ve aydınlatma kayıtları, (4) rezervasyon–PMS–çağrı merkezi gibi süreçlerden örnek kayıtlardır.

Otel ölçeğinde tipik kayıt grupları

• •Veri envanteri (Data Inventory): sistem × veri türü × amaç × erişim × saklama (not)
• •Veri haritası (Data Map): web → PMS → OTA → çağrı merkezi → muhasebe → CRM akış şeması
• •Erişim yetkileri: rol bazlı yetki matrisi, kullanıcı listesi, yetki değişiklik kayıtları
• •Log kanıtları: PMS login/değişiklik log’ları, entegrasyon log’ları, kritik sistem log politikası
• •Consent/cookie: opt-in/opt-out oranları, consent log örnekleri, banner_version, saklama prensibi
• •Süreç örnekleri: rezervasyon kayıt örneği, web form örneği, çağrı merkezi kayıt örneği
• •Operasyonel ekler: kamera kayıt yönetimi notu (saklama/erişim), cihaz envanteri notu (Varsayım: varsa)

Mini örnek (Antalya turizm oteli): Denetim talebi geldiğinde “PMS logları nerede?” sorusu 2 saat sürüyorsa, sorun logun yokluğu değil; “kanıt seti klasörü”nün hazır olmamasıdır. Bu rehberin amacı, her şeyi tek klasörde indeksli sunmaktır.

Bu bölüm, rakip içeriklerin çoğunda eksik olan “somut klasör yapısı”nı verir. Amaç; denetimde istenecek her şeyin tek pakette bulunmasıdır.

Önerilen klasör diyagramı (kanıt seti)

Aşağıdaki yapıyı “KVKK-AUDIT-PACK_YYYY” gibi sürümleyebilirsiniz.

• •01_Data_Inventory/ (data-inventory.xlsx (veya pdf), data-categories.md (Varsayım: kısa açıklama))
• •02_Data_Map_Flows/ (data-map-overview.pdf, web-pms-ota-flow.png)
• •03_Access_Rights/ (role-matrix.xlsx, active-users.csv, access-review-notes.pdf)
• •04_Log_Evidence/ (pms-login-logs_sample.csv, pms-change-logs_sample.csv, logging-policy.pdf)
• •05_Consent_Cookie/ (consent-log_sample.csv (maskeli), optin-kpi-dashboard.pdf, banner-version-history.md)
• •06_Process_Samples/ (reservation-record_sample.pdf (maskeli), web-form_sample.pdf, call-center-note_sample.pdf (maskeli))
• •07_Incidents_Improvements/ (Varsayım: varsa) (incident-reports_index.xlsx, improvement-actions.pdf)

Varsayım: Kamera kayıtları gibi özel alanlar varsa ayrıca “08_CCTV_Notes/” gibi bir klasör eklenebilir; ancak bu rehber hukuki detay yerine kanıt seti mantığında kalır.

Klasörün “index” dosyası (en büyük hızlandırıcı)

Her denetim paketinin kökünde tek sayfa bir INDEX.pdf tutun: Klasör listesi + içerik özeti, sorumlu kişi/rol, son güncelleme tarihi, erişim yetkisi (kim görebilir).

Denetimde veri envanteri tek başına “liste” olarak kalırsa eksik anlaşılır; veri haritası ise “akış”ı görünür kılar. Birlikte olduklarında otelin veri işleme gerçekliği ortaya çıkar: hangi sistem hangi veriyi işliyor ve nereye aktarıyor?

Envanterde olmazsa olmaz alanlar

• •Sistem/kaynak (web, PMS, OTA, çağrı merkezi, CRM, muhasebe)
• •Veri türü (kimlik/iletişim/rezervasyon/ödeme durumu)
• •Amaç (rezervasyon yürütmek, kampanya göndermek gibi)
• •Erişim rolleri (rol bazlı)
• •Saklama notu (Varsayım: sınırlı süre hedefi)

Haritada (data map) olmazsa olmazlar

• •Transfer türü (API/export/manuel)
• •Üçüncü taraflar (OTA, e-posta aracı, ajans araçları)
• •Kritik risk noktaları (manuel export gibi)

Erişim ve log kanıtı, “olay olursa iz süreriz” kapasitesinin ispatıdır. Denetimde iyi görünen şey, binlerce satır log değil; log’un kapsamı, saklama prensibi ve örnek kanıttır.

Yetki matrisi (rol bazlı)

• •Rol → ekran/işlev erişimi
• •Yeni kullanıcı açma/kapama prosedürü (Varsayım: kısa not)
• •Periyodik erişim gözden geçirme (aylık/çeyreklik)

Log kanıtı paketleme

• •PMS login log örneği (maskeli olabilir)
• •PMS değişiklik log örneği
• •Log politikası (hangi sistemde hangi log tutuluyor)
• •Log’ların nerede saklandığı ve erişim rolü

Mini örnek: Belek’te sezonluk personel sirkülasyonu yüksekse, “erişim review” kayıtları özellikle değerlidir; çünkü riskin büyük kısmı erişim ve insan faktöründe toplanır.

Cookie/consent tarafında denetimde aranan şey; “banner var mı?” değil, kanıtlanabilir rıza kaydı ve ölçümün rıza bazlı çalıştığının gösterimidir. Bu yüzden: Consent log örnekleri (maskeli), Banner sürüm geçmişi (banner_version), Opt-in KPI raporu (istatistik/pazarlama ayrı), Saklama ve erişim prensibi notu.

Kritik yorum kuralı: Opt-in oranı ölçüldüğünde, Analytics/raporlar “tüm kullanıcılar” yerine izin veren kullanıcılar evrenini temsil eder; bu notu dashboard’a eklemek denetimde de iç yönetimde de faydalıdır.

Denetimde “gerçek örnek” görmek isteyebilirler; burada amaç tüm veri değil, süreç kanıtıdır. Bu nedenle: Maskeli rezervasyon kayıt örneği (PDF), Web form örneği (hangi alanlar toplanıyor), Çağrı merkezi not örneği (gereksiz veri yok), PMS erişim log örneği (kimin eriştiği).

Mini örnek (Side): Rezervasyon kaydında gereksiz alanlar (örn. “not” alanında hassas bilgi) birikiyorsa, bunu “iyileştirme aksiyonu” olarak rapora eklemek olgunluk göstergesidir.

1. Klasör yapısını dondurun (yapı sabit, içerik güncel)
2. INDEX dosyasını güncelleyin (sorumlu + tarih)
3. Yetki matrisi ve aktif kullanıcı listesini yenileyin
4. PMS login/değişiklik log örneklerini paketleyin
5. Consent opt-in KPI raporunu güncelleyin ve “evren notu” ekleyin
6. Örnek kayıtları maskeyle kontrol edin (PII sızıntısı olmasın)
7. 30 dakikalık “dry-run” yapın: Her klasörden 1 dosya açıp kontrol edin

Denetimde talep edilen şey çoğu zaman tek bir dosya değil; otelin veri işleme süreçlerini kanıtlayan pakettir. Veri envanteri + veri haritası, erişim/log kanıtları, consent/cookie kayıtları ve süreç örneklerini tek bir klasör yapısında “kanıt seti” halinde sunmak denetimi hızlandırır ve eksik kayıt riskini azaltır.