KVKK Veri Haritası Nedir, Nasıl Çıkarılır? Oteller İçin Veri Akışı Rehberi

KVKK veri haritası (data map), otelinizdeki kişisel verilerin nerede oluştuğunu, hangi sistemlere girdiğini, hangi süreçlerden geçtiğini ve hangi kişi/rollerin erişebildiğini tek resimde gösteren bir envanter + akış dokümanıdır. “Veri envanteri” çoğu zaman bir tablo olarak kalırken, “veri haritası” aynı tabloyu akış mantığıyla tamamlar: kaynak → işlem → aktarım → saklama → erişim.

Otel tarafında bu harita özellikle kritiktir çünkü veri; resepsiyon check-in ekranından web rezervasyon formuna, çağrı merkezinden PMS/CRM’e, OTA ekstranetlerinden muhasebeye kadar dağınık şekilde akar. Harita sayesinde “hangi veri nereden geliyor, hangi amaçla işleniyor, kim görüyor, ne kadar tutuluyor” soruları netleşir.

• •KVKK (kişisel veri) odağı: kimlik, iletişim, rezervasyon, ödeme, tercih/segment, pasaport vb.
• •Data Map (harita) odağı: sistemler ve süreçler arası transferler
• •Hotel personal data map: otel bağlamında “misafir yaşam döngüsü” boyunca veri izi

Mini örnek (otel bağlamlı):

Misafir web sitesinden rezervasyon yapar → PMS’te rezervasyon oluşur → OTA ile kanal eşitlemesi yapılır → check-in’de kimlik/pasaport doğrulanır → ödeme bilgileri muhasebe/pos sistemine gider → CRM segmentasyonuna aktarılır. Bu akış, KVKK veri haritasında tek şema olarak görünür.

☑ Mini Check (Hızlı Tanım Kontrolü):

• •Harita yalnız “liste” değil, akış içeriyor mu?
• •Her sistem için veri kategorisi + amaç + erişim yazıldı mı?
• •Aktarımlar (API, export, manuel excel) ayrı ayrı işaretlendi mi?

KVKK veri haritası çıkarırken en sık hata, “kişisel veri”yi yalnızca kimlik bilgisi sanmaktır. Otelde veri, misafir deneyimi boyunca farklı kategorilerde toplanır ve farklı amaçlarla işlenir. Bu nedenle haritayı kurarken veri kategorilerini net sınıflamak gerekir.

En yaygın kişisel veri kategorileri (otel örneğiyle)

• •Kimlik verisi: ad-soyad, TCKN/pasaport, doğum tarihi
• •İletişim verisi: telefon, e-posta, adres
• •Rezervasyon verisi: giriş-çıkış, oda tipi, fiyat, paket, özel istek
• •Ödeme/finans verisi: fatura bilgisi, ödeme durumu, işlem kayıtları (kartın tam bilgisi ayrı hassasiyet gerektirir)
• •Davranış/tercih verisi: tercih edilen oda/konsept, geçmiş konaklama, kampanya etkileşimi
• •Güvenlik verisi: erişim logları, kamera kayıtları (kapsam ve saklama kuralları operasyonel olarak kritik)

Mini örnek:

Antalya’da sezon yoğunluğunda çağrı merkezi “erken rezervasyon” kampanyası açar. Telefonda isim-telefon-e-posta alınır (iletişim), tarih/oda tipi konuşulur (rezervasyon), teklif e-postası atılır (pazarlama). Bu setin tamamı “kişisel veri”dir; haritada çağrı merkezi → CRM → e-posta aracı → raporlama akışı görünmelidir.

☑ Mini Check (Veri Kategorisi Kontrolü):

• •“Rezervasyon verisi” ile “pazarlama etkileşimi” ayrıldı mı?
• •Kamera/log gibi “operasyonel” veriler unutulmadı mı?
• •Hassas/hassas olmayan veri ayrımı için not düşüldü mü? (Hukuk ekibiyle doğrulanacak)

Bu bölüm, “otel veri akışı dokümantasyonu”nun kalbidir. Çünkü veri haritası; sistem envanteri olmadan sağlıklı kurulamaz. Buradaki hedef, otelde veri üreten ve veri işleyen tüm kaynakları çıkarmak ve aralarındaki bağlantıları tanımlamaktır.

Otelde tipik veri kaynakları (touchpoint listesi)

• •Resepsiyon / Ön büro: check-in/out ekranları, kimlik doğrulama, misafir notları
• •Web sitesi: rezervasyon formu, iletişim formu, chat, çerez/analitik
• •Çağrı merkezi: CRM kayıtları, görüşme notları, teklif süreçleri
• •PMS/OTA yönetimi: rezervasyon senkronizasyonu, kanal yöneticisi, extranet işlemleri
• •CRM: segmentasyon, kampanya listeleri, geçmiş konaklama
• •Muhasebe / ERP: faturalama, ödeme/iadeler, cari hesap
• •E-posta/SMS araçları: kampanya gönderimleri, transactional mesajlar
• •Raporlama/BI: dashboard’lar, veri ambarı, excel export’ları

“System → Processes → PersonalData” ilişkisini netleştirme

AIO gereksinimi gereği, entity’leri yalnız saymak değil, ilişkileri net anlatmak gerekir:

• •System: PMS
• •Process: Rezervasyon oluşturma, check-in doğrulama, oda atama
• •PersonalData: kimlik + rezervasyon + iletişim (bazı durumlarda ödeme durumu)

Bu ilişkiyi her kritik sistem için kurduğunuzda, harita “neden var” sorusuna cevap verir: hangi süreç hangi veriyi gerektiriyor ve hangi noktada risk oluşuyor?

Veri envanteri tablosu (örnek)

Aşağıdaki örnek tablo, veri haritasının “tablosal omurgası”dır. (Tabloyu kendi otelinize göre genişletin.) Not: “Hukuki dayanak” ve kesin saklama süreleri hukuki değerlendirme gerektirebilir; burada amaç operasyonel çerçeve kurmaktır.

☑ Mini Check (Sistem Envanteri Kontrolü):

• •“Manuel excel export” yapılan yerler ayrı işaretlendi mi?
• •Üçüncü taraflar (ajans, çağrı merkezi outsource, e-posta aracı) eklendi mi?
• •Her sistem için en az “veri türü + amaç + erişim” dolduruldu mu?

Bu aşama, “data flow diagram hospitality” üretimidir: tabloda yazan bilgiyi görselleştirir. En iyi pratik, akışı misafir yolculuğu üzerinden kurmaktır: Lead → Rezervasyon → Konaklama → Ödeme → Sadakat/Pazarlama → Raporlama.

Otel için örnek veri akışı (web → PMS → OTA → çağrı merkezi)

Örnek bir çekirdek akış:

1. Web sitesi (form/engine) rezervasyon verisini toplar
2. Veri PMS’e düşer (rezervasyon kaydı)
3. PMS ↔ OTA/Channel Manager ile oda/price/availability senkronize olur
4. Misafir ararsa çağrı merkezi kaydı oluşur, PMS rezervasyonuyla eşleştirilir
5. Muhasebe fatura/ödeme kaydıyla süreci tamamlar
6. CRM segmentasyon ve kampanya için minimum gerekli alanları alır
7. Raporlama/BI sistemleri KPI üretir

Bu akışı çıkarırken en kritik nokta: “veri kopyalanıyor mu, çoğaltılıyor mu, hangi noktada dışarı çıkıyor?” sorularıdır. Çoğu otelde risk, teknik sistemden çok export/manuel süreçlerde büyür.

Key Statistics / Data Point (yumuşatılmış):

Çoğu tesiste kişisel verinin büyük kısmı rezervasyon ve PMS süreçlerinde yoğunlaşır; kalan kısım ise çağrı merkezi ve muhasebe tarafında parçalı şekilde dağılabilir. Bu nedenle ilk risk taraması genelde PMS ve rezervasyon akışı üzerinden başlatılır.

Veri akışı diyagramında dikkat edilecekler

• •Erişim ve yetki katmanı: “kim görüyor?” kutularını role göre ekleyin
• •Saklama ve silme noktaları: “ne kadar tutuluyor?” ve “ne zaman siliniyor?” notlayın
• •Üçüncü taraflar: OTA, e-posta aracı, ödeme altyapısı, ajans araçları
• •Aktarım türü: API, entegrasyon, manuel excel, e-posta ile paylaşım

☑ Mini Check (Diyagram Kontrolü):

• •Her ok (transfer) için “aktarımı kim başlatıyor?” yazıldı mı?
• •Dış kaynak/tedarikçi kutuları ayrı renkte/katmanda mı? (tasarım notu)
• •Manuel export süreçleri diyagrama eklendi mi?

Bu bölüm “raporlama-4” sayfasının amacıyla doğrudan bağlantılıdır: veri haritası sadece “çıkarıldı” diye bitmez; raporlama, denetim hazırlığı ve sürekli iyileştirme için yaşayan bir doküman olmalıdır.

KVKK raporlamasında veri haritasının 5 kullanım alanı

1. Risk envanteri: Nerede gereksiz veri toplanıyor? Nerede erişim fazla?
2. Erişim yetkisi yönetimi: Rol bazlı erişim matrisini doğrulama
3. Saklama süresi ve silme süreçleri: “hangi veri ne kadar tutuluyor” planı
4. Tedarikçi/entegrasyon yönetimi: OTA/CRM/e-posta araçlarıyla veri paylaşımı görünür olur
5. Denetim hazırlığı: “doküman var mı?” sorusuna hızlı cevap

“Bugün başlayabileceğiniz 5 küçük adım”

• •1. Web form alanlarını gözden geçir: gerçekten gerekli mi?
• •2. PMS’te erişim rollerini çıkar: kim hangi ekrana giriyor?
• •3. Çağrı merkezi not alanlarını standardize et: gereksiz kişisel veri yazımını azalt
• •4. Export süreçlerini belirle: kim, hangi excel’i, nereye gönderiyor?
• •5. Envanteri aylık değil; sezon öncesi ve sistem değişimlerinde güncelle

Otellerde periyodik güncelleme (Refresh Cycle: 365)

Bu içerik için önerilen güncelleme döngüsü 365 gün. Ancak pratikte; kanal yöneticisi değişimi, CRM geçişi, yeni ödeme altyapısı veya yeni çağrı merkezi süreçleri gibi durumlarda “yıllık” beklemek yerine haritayı anında revize etmek gerekir. Antalya/Belek gibi destinasyonlarda sezon operasyonu değiştiğinde (yeni kampanya, yeni paket, yeni kanal), veri akışı da değişebilir.

☑ Mini Check (Raporlama Kullanımı):

• •Haritadan “aksiyon listesi” ürettiniz mi?
• •İç link / hizmet bağlantılarını planladınız mı?
• •Bir “sahip” atadınız mı? (Data Owner)

Pek çok içerik KVKK’yı teorik anlatır; ama otellerde değer yaratan şey, gerçek sistemlerle çalışan pratik şablondur. Bu nedenle aşağıdaki iki çıktıyı “paket” düşünün:

• •(1) Veri envanteri tablosu (sistem × veri türü × amaç × erişim)
• •(2) Veri akışı diyagramı (web → PMS → OTA → çağrı merkezi → muhasebe → CRM → raporlama)

Bu paket, hem teknik ekiple hem pazarlama/operasyon ekibiyle aynı dili kurar: “Hangi veri nerede?” ve “Nereye gidiyor?” soruları tek sayfaya iner.

Özetle; KVKK veri haritası, oteldeki kişisel veri akışını “görünür” kılar. Görünür olan süreç yönetilir: gereksiz veri toplanmaz, erişimler sadeleşir, saklama/silme mantığı netleşir ve raporlama hızlanır. Bu rehberdeki yaklaşım, özellikle PMS–OTA–web–çağrı merkezi hattında parçalı kalan veriyi tek çatı altında toplar.