1. 2026’da PMS Veri Lokasyonu ve Data Residency Oteller İçin Neden Kritik?
Data residency en basit haliyle “veri nerede duruyor?” sorusudur: hangi ülke, hangi bölge (region), hangi veri merkezi. Bu soru, regülasyon ve denetim baskısı arttıkça “opsiyonel” olmaktan çıkar. Çünkü PMS verisi, çok sayıda entegrasyonla (OTA, web, call center, BI, CRM, marketplace app’leri) farklı sistemlere kopyalanır; data residency stratejisi yoksa veri “gölge kopyalar” halinde yayılır.
Net cevap bloğu
Data residency; PMS verisinin hangi ülkede/bölgede tutulduğunu ve entegrasyonlarla nereye aktarıldığını yönetmektir. Bu yönetim; KVKK/GDPR uyumu, denetlenebilirlik ve felaket anında süreklilik (DR) için mimarinin parçası olmalıdır.
“Veri nerede duruyor?” sorusunu 3 katmanda sorun
- Depolama lokasyonu: PMS database hangi region’da? (Data Center/Region)
- İşleme lokasyonu: log/analitik/BI nerede işliyor? (processing)
- Paylaşım lokasyonu: app’ler ve entegrasyonlar hangi ülkeye kopyalıyor? (cross-border)
Mini örnek
Bodrum’daki resort’ta mobile check-in uygulaması eklediniz. PMS verisi Türkiye region’da duruyor olabilir; ama uygulamanın analitik servisi farklı bir bölgede çalışıyorsa “işleme/aktarım” katmanı devreye girer. Aynı otel, Antalya’da sezon ortasında kesinti yaşarsa; DR’nin hangi bölgede çalıştığı da “lokasyon” sorusunun parçasıdır.
Mini Check
- • PMS’in ana veri bölgesi (region) net mi?
- • Entegrasyon envanteri (hangi sistemler veri alıyor) güncel mi?
- • Marketplace/app’lerin veri paylaşım kapsamı dokümante mi?
- • Loglarda kişisel veri minimizasyonu var mı?
- • DR senaryosu hangi bölgede çalışıyor?
Ne yapmalıyım?
- • “Data residency”yi tek cümlelik bir politika metnine çevirin.
- • Veri akış haritasını çıkarın (PMS → kimlere → hangi veri).
- • Log/retention/erişim rollerini standardize edin.
- • DR katmanını “uyum”un parçası olarak planlayın.
2. KVKK, GDPR ve Data Residency Gereksinimleri PMS Entegrasyonlarını Nasıl Etkiler?
Bu bölümde kritik sınır: hukukî yorum yapmıyoruz. Ama teknik/mimari açıdan şunu netleştiriyoruz: regülasyonlar, özellikle yurtdışı aktarım ve tasarımda veri koruma (privacy by design) gibi başlıklarda mimariye doğrudan gereksinim olarak yansır. GDPR’de üçüncü ülkelere aktarımlar için çerçeve, ilgili bölümde düzenlenir. KVKK tarafında da “yurtdışına aktarım” başlığı altında kurum kaynakları bulunur.
Net cevap bloğu
KVKK/GDPR, PMS entegrasyonlarında veri lokasyonu ve veri aktarımını “tasarım kararı” haline getirir: hangi verinin kime aktarıldığı, hangi bölgede işlendiği, erişim rolleri ve retention/loglama gibi kontrollerin dokümante ve denetlenebilir olması gerekir. Yurtdışı aktarım gibi konular ise teknik planın yanında hukuk danışmanınızla birlikte değerlendirilmelidir.
Entegrasyon perspektifinden 5 “zorunlu” doküman
- •Veri akış haritası: PMS → sistem → veri alanları → amaç
- •Erişim rol matrisi (RBAC): kim hangi veriyi görür/yazar
- •Retention planı: log/backup/veri saklama süreleri (Varsayım: politika bazlı)
- •DPA/SLA paket özeti: tedarikçi sorumluluğu ve bildirim süreçleri (Varsayım)
- •Değişiklik kaydı: region/servis değişiklikleri ve etkileri
“Yurtdışı aktarım”ı mimariye çeviren kontrol noktaları
- •veri sınıflandırması: kimlik, iletişim, ödeme, özel nitelik vs. (Varsayım)
- •kopya sayısı: aynı veri kaç sistemde duruyor?
- •erişim kanalı: API key, IP kısıt, rol (Varsayım)
- •şifreleme: aktarımda ve depoda (Varsayım)
- •audit log: ne aktarıldı, ne zaman, kim çağırdı
Mini Check
- • PMS → 3. taraf uygulamalar için “minimum veri” prensibi var mı?
- • API anahtarı/rol yönetimi ve rotasyon planı var mı? (Varsayım)
- • Loglarda PII maskeleme uygulanıyor mu? (Varsayım)
- • Entegrasyon değişiklikleri “onaylı süreç” mi?
- • Hukuk danışmanı ile aktarım senaryoları listelendi mi?
Ne yapmalıyım?
- • Regülasyonu “kontrol listesi” değil “mimari gereksinim” yapın.
- • Veri akışını haritalayın; gereksiz aktarımı keskin şekilde azaltın.
- • Marketplace/app eklemeyi onay kapısından geçirin.
- • Erişim/retention/loglama kararlarını yazılılaştırın.
3. Çok Otelli ve Çok Ülkeli Yapılarda Veri Lokasyonu Stratejisi Nasıl Planlanmalı?
Zincir yapılarda “tek PMS mi, bölgesel mi?” sorusu; sadece performans değil, data residency ve DR kararını da belirler. Üç tip yaklaşım vardır; her birinin artı/eksi’si “uyum + süreklilik + operasyon” üçgeninde değerlendirilmelidir.
Net cevap bloğu
Çok otelli/çok ülkeli yapılarda veri lokasyonu stratejisi; merkezi raporlama ihtiyacı, bölgesel regülasyon gereksinimleri, operasyonel kesinti toleransı ve DR mimarisi birlikte düşünülerek seçilmelidir.
3 mimari seçenek (otelci diliyle)
- Merkezi (single region) PMS: raporlama kolay, uyum riski yüksek olabilir (senaryoya bağlı)
- Bölgesel hub: TR/EU gibi bölgesel ayrım, daha dengeli yönetim
- Ülke/tesis bazlı ayrışma: uyum kontrolü güçlü, entegrasyon/raporlama daha karmaşık
Mini örnek
Antalya, Belek ve Side’deki tesisler için “TR bölgesi” altında merkezi PMS mantıklı olabilir; ama EU pazarında farklı regülasyon/denetim baskısı varsa “bölgesel hub” yaklaşımı masaya gelir. Buradaki doğru cevap; “en az kopya + en net sorumluluk + en test edilmiş DR” kombinasyonudur.
Mini Check
- • Grup raporlaması tek panel mi, bölgesel mi?
- • Ülke bazlı veri lokasyonu zorunlulukları var mı? (hukukla birlikte)
- • Entegrasyonların çoğu hangi bölgede çalışıyor?
- • DR planı bölgesel mi, merkezi mi?
- • Erişim rolleri tesis bazlı ayrışıyor mu?
Ne yapmalıyım?
- • Mimari kararı “raporlama” ile değil “uyum + DR” ile birlikte verin.
- • Bölgesel hub yaklaşımını “minimum karmaşa” hedefiyle tasarlayın.
- • Tesis bazlı ayrışmada entegrasyon standardını zorunlu kılın.
- • Yönetim için “tek sözlük, çok panel” stratejisi belirleyin (Varsayım).
4. Veri Aktarımı, Yedekleme ve Felaket Kurtarma: Residency ile Sürekliliği Birleştirmek
Data residency stratejisi, DR’siz eksik kalır. Çünkü “veri nerede duruyor?” sorusu kadar “veri gittiğinde nereden geri dönüyor?” sorusu da denetim ve operasyon için kritiktir. Özellikle Kemer/Bodrum gibi sezon yoğun bölgelerde kesinti toleransı düşüktür; DR seviyesini buna göre seçmek gerekir.
| Katman | Amaç | Ne sağlar | Tipik kullanım (otel) |
|---|---|---|---|
| Backup (yedek) | Veri kaybını azaltma | geri yükleme | muhasebe kapanışı, PMS kritik kayıtlar |
| Replica (replika) | Kesintiyi azaltma | hızlı devralma | sezon yoğun tesisler |
| Warm Standby | Orta hız devreye alma | daha kısa kesinti | çok otelli yapılarda |
| Hot Standby | En hızlı devreye alma | minimum kesinti | yüksek hacimli zincir yapılar |
| DR Test Rutini | Güven kanıtı | denetlenebilirlik | yılda/6 ayda test (Varsayım) |
Backup/DR tasarımında 5 kritik karar
- •DR bölgesi ana bölgeyle aynı mı, farklı mı?
- •log/backup retention politikası (uyum + maliyet)
- •kim DR devreye alır (yetki ve prosedür)
- •DR test sıklığı ve raporu (Varsayım)
- •entegrasyonların DR’de davranışı (kanal/web/call center)
Regülasyon baskısının arttığı pazarlarda, veri lokasyonu ve yedekleme stratejisini doğru kurgulayan otellerin denetim süreçlerini daha sorunsuz geçebildiği ve veri kesintisi riskini azalttığı senaryo bazlı gözlemlenir (kesin rakam iddiası yok).
Mini Check
- • DR bölgesi ve devralma prosedürü yazılı mı?
- • Backup/replica erişimleri rol bazlı mı?
- • DR test raporu denetim için saklanıyor mu? (Varsayım)
- • Entegrasyonlar DR’de “failover” sonrası tutarlı mı?
- • Loglar PII minimizasyonuyla tutuluyor mu?
Ne yapmalıyım?
- • DR’yi “teknik opsiyon” değil “uyum + gelir koruma” olarak konumlandırın.
- • DR testini düzenli ritme bağlayın; rapor üretin.
- • Entegrasyon failover senaryolarını (OTA/web) önceden simüle edin.
- • Backup/replica erişimlerini en dar yetkiyle verin.
5. 2026 Sonrası İçin “Privacy by Design”: Uyumun Tasarıma Gömülmesi
Privacy by Design, “sonradan eklenen” bir kontrol değil; veri işleme araçlarını ve entegrasyon akışını tasarlarken en başta veri korumayı düşünmektir. GDPR’de “design and default” yaklaşımı ilgili maddede yer alır. Bu yaklaşım, PMS entegrasyonlarında şu şekilde görünür: minimum veri, sınırlı erişim, ölçülü loglama, açık retention ve denetlenebilir değişiklik yönetimi.
Net cevap bloğu
Privacy by Design, PMS entegrasyonlarını tasarlarken veri minimizasyonu, rol bazlı erişim, güvenli aktarım, denetlenebilir loglama ve açık retention/DR kararlarını “varsayılan” hale getirir; hukukî değerlendirme gerektiren konular ise hukuk danışmanınızla birlikte ele alınmalıdır.
Rakip boşluğunu kapatan “12 mimari karar listesi”
- •veri sınıflandırması ve etiketleme
- •PII maskeleme (log/UI) (Varsayım)
- •API anahtarı yönetimi ve rotasyon (Varsayım)
- •erişim rolleri (front office / finance / HK / IT)
- •“write-back” izinleri (hangi app PMS’e yazabilir?)
- •region değişikliği için change control
- •retention politikası (log/backup)
- •DR test ritmi ve raporu
- •vendor lock-in çıkış planı (export)
- •marketplace app onay kapısı
- •audit trail standardı
- •veri akış haritasının güncelleme rutini
Mini Check
- • Veri akış haritası “tek kaynak” mı?
- • Marketplace/app ekleme için onay süreci var mı?
- • Retention ve loglama denetlenebilir mi?
- • DR test raporu üretiliyor mu?
- • Hukuk danışmanıyla aktarım senaryoları listelendi mi?
Ne yapmalıyım?
- • Privacy by Design’ı “entegrasyon standardı” olarak yazın.
- • 10 kontrol sorusunu her yeni entegrasyonda zorunlu kılın.
- • DR testini yılda en az 1 kez planlayın (Varsayım).
- • Uyum + süreklilik KPI’larını yönetim paneline taşıyın.
6. PMS Veri Lokasyonu & Felaket Kurtarma Kontrol Listesini İndir — Otel / Data Residency
PMS Veri Lokasyonu & Felaket Kurtarma Kontrol Listesini İndir — Otel / Data Residency (v1.0)
Bu asset, PMS verisinin nerede tutulduğunu (region), entegrasyonlarla nereye aktarıldığını (cross-border), erişim/retention/loglama kararlarını ve DR seviyesini tek formatta standartlaştırır. Amaç; denetim ve kesinti riskini azaltmak, “data residency”yi kağıt üzerinde değil mimari karar olarak yönetmektir. Hukukî değerlendirme gerektiren başlıklarda, hukuk danışmanınızla birlikte kontrol noktalarını tamamlamanızı kolaylaştırır.
Kim Kullanır?
IT/ops owner + GM/finans + güvenlik/uyum sorumlusu (Varsayım) birlikte.
Nasıl Kullanılır?
- 10 soruluk residency checklist’i ile mevcut durumu puanlayın.
- Problem→kök neden→çözüm tablosuyla riskleri iş paketine çevirin.
- 14 günlük sprint planıyla veri akış haritası + DR testini tamamlayıp go/no-go kararı verin.
Ölçüm & Önceliklendirme (Kısa sürüm)
- ▢ ✅ PMS ana veri lokasyonu (ülke/bölge/region) net mi?
- ▢ ✅ PMS’ten veri alan tüm sistemler (OTA/web/BI/app) listeli mi?
- ▢ ✅ Hangi veriler aktarılıyor (minimum veri prensibi) net mi?
- ▢ ✅ Yurtdışı aktarım senaryoları hukuk danışmanıyla değerlendirildi mi?
- ▢ ✅ Erişim rolleri (RBAC) ve yazma yetkileri tanımlı mı?
- ▢ ✅ Loglarda PII maskeleme ve retention politikası var mı? (Varsayım)
- ▢ ✅ Backup/replica/DR bölgesi ve devralma prosedürü yazılı mı?
- ▢ ✅ DR test sıklığı ve raporu tanımlı mı? (Varsayım)
- ▢ ✅ Vendor lock-in çıkış planı (export/taşınabilirlik) var mı?
- ▢ ✅ Değişiklik yönetimi (region/servis/app ekleme) onaylı süreç mi?
PDF içinde: Problem→Kök Neden→Çözüm tablosu + 14 gün sprint planı + önce/sonra KPI tablosu
7. Sonuç: Data residency, PMS entegrasyonunda teknik detay değil mimari karardır
2026’da PMS entegrasyonlarında sadece bağlantının çalışması yetmez; verinin hangi bölgede tutulduğu, hangi servislerle nereye aktarıldığı, erişim/retention/loglama kararlarının nasıl yönetildiği ve kesinti anında DR katmanının nasıl devreye girdiği birlikte düşünülmelidir.
Bu yüzden data residency; uyum, denetlenebilirlik ve operasyon sürekliliğini aynı çerçevede yöneten bir tasarım kararıdır. Veri akış haritası, rol bazlı erişim, minimum veri prensibi ve test edilmiş DR rutini; çok lokasyonlu otellerde riski azaltan temel yapı taşlarıdır.
Bir Sonraki Adım
Çok lokasyonlu otellerde veri lokasyonu ve DR kararlarını netleştirmek isteyen ekipler için.
Sık Sorulan Sorular
Data residency nedir, PMS verisi için neden önemlidir?▾
PMS verisi nerede tutuluyor (ülke/bölge/bulut sağlayıcı) nasıl anlaşılır?▾
KVKK ve GDPR, PMS veri lokasyonu ve entegrasyonları nasıl etkiler?▾
Çok ülkeli otel zincirlerinde veri lokasyonu stratejisi nasıl planlanmalı?▾
Yedekleme ve felaket kurtarma (DR) entegrasyona nasıl yansır?▾
“Privacy by Design” PMS entegrasyonlarında pratikte ne demek?▾
Marketplace/app ekosistemi data residency riskini artırır mı?▾
İlgili İçerikler
İlgili Yazılar