1. Bulut ve sunucu lokasyonu neden kritik?
Bulut lokasyonu kritik çünkü veri “nerede” sorusu, hem risk yönetimini hem de denetimde kanıt setini etkiler. Otel verisi; PMS kayıtları, rezervasyon akışı, CRM segmentleri ve bazen e-posta iletişimlerini içerir. Bu veriler birden fazla ülke/yargı alanında işleniyorsa, raporlamada belirsizlik büyür. Ayrıca lokasyon, felaket senaryolarında geri dönüş planıyla da bağlantılıdır: yedekler başka lokasyondaysa, restore süreci ve süreleri etkilenir.
AIO mantığı:
Cloud Provider → stores → hotel data in specific jurisdictions
Bu nedenle KVKK raporu “bulutta” demekle yetinmez; ülke/region + kontrol seti ister.
Otelde lokasyonun etkilediği 3 alan
- •Denetim şeffaflığı: veri nerede, kim erişiyor?
- •Güvenlik yüzeyi: erişim/loglama kanıtı var mı?
- •İş sürekliliği: yedek lokasyonu ve geri dönüş planı
Mini örnek (Antalya sezon)
Sezon ortasında PMS performans problemi yaşanır ve vendor “region değişimi” yapar. Eğer lokasyon ve yedek lokasyonları raporlanmıyorsa, denetimde “veri nerede işlendi?” sorusuna net cevap verilemez. Bu yüzden lokasyon değişimleri bile raporlanabilir bir politika konusu olmalıdır (Varsayım: vendor izin veriyorsa).
☑ Mini Check (kritiklik)
- •Veri merkezi ülke/region bilgisi net mi?
- •Yedek lokasyonları ayrı yazılı mı?
- •Erişim/log kanıtı talep ediliyor mu?
Ne yapmalıyım?
- • “Lokasyon”u tek satır değil, tablo alanı yapın.
- • Yedek lokasyonlarını ayrıca raporlayın.
- • Sağlayıcıdan kanıt türlerini isteyin (log, politika, sertifika vs. yüksek seviye).
2. Bulut sağlayıcınızı teknik açıdan nasıl değerlendirirsiniz?
Değerlendirme, “cloud iyi mi?” gibi genel sorudan değil; ölçülebilir kriterlerden oluşmalıdır. Oteller için pratik çerçeve 5 başlıkta toplanır: lokasyon, şifreleme, erişim, loglama, yedekleme/restore.
1) Lokasyon (Data Center Location)
- •Veri merkezi ülke/region nedir?
- •Üretim ve yedek aynı yerde mi, farklı mı?
- •Alt sağlayıcı/sub-processor var mı? (Varsayım)
2) Şifreleme (Encryption)
- •Aktarım sırasında (in transit) şifreleme var mı?
- •Saklama halinde (at rest) şifreleme var mı?
- •Anahtar yönetimi (yüksek seviye) nasıl? (Varsayım: provider yönetiyor / müşteri yönetiyor)
3) Erişim kontrolü (Access Control)
- •Admin erişimleri rol bazlı mı?
- •MFA/2FA kullanımı var mı? (Varsayım)
- •Ayrılan vendor personeli erişimleri nasıl kapanıyor? (Varsayım: süreç kanıtı)
4) Loglama ve izlenebilirlik (Logging)
- •“Kim, ne zaman, ne yaptı?” logları var mı?
- •Loglar ne kadar saklanıyor? (policy)
- •Olay incelemede rapor/çıktı verilebiliyor mu? (yüksek seviye)
5) Yedekleme lokasyonu ve restore
- •Yedekler nerede tutuluyor? (ülke/region)
- •Restore testleri yapılıyor mu? (kanıt)
- •RTO/RPO yaklaşımı (yüksek seviye) net mi? (Varsayım)
☑ Mini Check (değerlendirme)
- •Lokasyon + yedek lokasyonu net yazıldı mı?
- •Şifreleme (in transit/at rest) ayrı ayrı doğrulandı mı?
- •Log ve erişim kanıtı raporda var mı?
Ne yapmalıyım?
- • Sağlayıcı değerlendirme tablosunu doldurun (aşağıda).
- • Belirsiz alanları “kanıt talebi” aksiyonuna bağlayın.
- • Yüksek riskli belirsizlikleri vendor risk raporuna taşıyın (Blog-9 ile bağ).
3. Yurt içi / yurt dışı sunucular için teknik soru seti
Bu bölüm, pratikte en hızlı değer üreten kısımdır: “sağlayıcıya sorulacak sorular” listesi. Amaç, belirsizliği azaltıp raporu kanıtlanabilir hale getirmektir.
Sağlayıcıya sorulacak 10 teknik soru
- Üretim verisi hangi ülke/region’da tutuluyor?
- Yedekler hangi ülke/region’da tutuluyor? (aynı mı farklı mı?)
- Aktarımda (in transit) şifreleme var mı?
- Depoda (at rest) şifreleme var mı?
- Admin erişimlerinde MFA/2FA zorunlu mu?
- Erişim logları (kim/ne zaman/ne yaptı) sağlanabiliyor mu?
- Log saklama süresi ve erişim yetkisi nasıl?
- Olay yönetimi (incident) için SLA/yanıt süresi nedir?
- Sub-processor/alt sağlayıcı kullanılıyor mu? (yüksek seviye)
- Restore testi yapılıyor mu, rapor/kanıt var mı?
Mini örnek (yurt dışı PMS)
“Sunucumuz yurt dışında” tek başına karar verdirmez; ama “yedek de yurt dışında, log kanıtı yok, MFA belirsiz” gibi cevaplar toplamda riski büyütür. Bu nedenle soru seti “lokasyon + kontrol” bütünlüğüyle ele alınır.
☑ Mini Check (soru seti)
- •10 sorunun en az 8’ine yazılı cevap var mı?
- •Yedek lokasyonu ayrı soruldu mu?
- •Log ve restore kanıtı istendi mi?
Ne yapmalıyım?
- • Bu soru setini vendor onboarding dokümanına ekleyin.
- • Cevapları “kanıt linki” ile saklayın (policy/pdf vs.).
- • Eksik cevapları “aksiyon planı”na bağlayın.
4. Sunucu lokasyonunu KVKK raporlarına nasıl yazarsınız?
KVKK raporlarında ideal hedef “çok teknik açıklama” değil, kısa ve doğrulanabilir teknik özettir. Yönetim ve denetim için okunabilir format:
KVKK raporu teknik özet şablonu (örnek)
- •Sistem/Hizmet: Bulut PMS / CRM / Mailing / Raporlama
- •Veri lokasyonu: Ülke/region (üretim)
- •Yedek lokasyonu: Ülke/region
- •Şifreleme: in transit / at rest (var/yok)
- •Erişim kontrolü: rol bazlı + MFA (yüksek seviye)
- •Loglama: erişim logu var mı + saklama notu
- •Not: Belirsiz alanlar ve aksiyonlar (kanıt talebi)
“Kısa ama net” rapor örneği (tek paragraf)
“Bulut PMS sistemimizde üretim verisi X ülke/region’da tutulur; yedekler Y ülke/region’da saklanır. Aktarımda ve depoda şifreleme uygulanır; erişim rol bazlı yönetilir ve loglama kanıtı denetim paketine eklenir. Eksik kanıt alanları için sağlayıcıdan yazılı doğrulama talep edilmiştir.”
Not: Bu metin “hukuki yorum” yapmaz; teknik gerçekleri ve kanıt durumunu belirtir.
☑ Mini Check (raporlama)
- •Üretim lokasyonu ve yedek lokasyonu ayrı yazıldı mı?
- •Şifreleme ve loglama “var/yok” net mi?
- •Belirsiz alanlar aksiyona bağlandı mı?
Ne yapmalıyım?
- • Tüm sistemler için aynı özet formatını kullanın (standart).
- • Özetin altına “kanıt dosyası” referansı ekleyin (audit pack).
- • Yılda 1 güncelleme takvimi koyun (Refresh 365).
5. Oteller için örnek cloud değerlendirme tablosu
Aşağıdaki tablo, hem satınalma/management hem IT için ortak dil üretir.
| Sistem | Sağlayıcı Türü | Üretim Lokasyonu | Yedek Lokasyonu | Şifreleme | Loglama | SLA/Incident | Risk Notu | Aksiyon |
|---|---|---|---|---|---|---|---|---|
| PMS | Bulut PMS | |||||||
| CRM | Bulut CRM | |||||||
| Mailing | E-posta aracı | |||||||
| Raporlama | BI/Tool |
Key Statistics / Data Point (yumuşatılmış)
Doğru değerlendirilmeyen sunucu lokasyonları; hem denetimde belirsizlik (kanıt eksikliği) hem de felaket senaryolarında geri dönüş süresi açısından problem yaratabilir. Bu nedenle lokasyon + yedek lokasyonu + restore kanıtı birlikte ele alınmalıdır.
3 pratik risk senaryosu (mini bölüm – competitor gap’i kapatır)
- •Senaryo 1: Üretim lokasyonu net, yedek lokasyonu belirsiz → Risk: restore planı zayıf → Aksiyon: yedek lokasyonu kanıtı + test raporu
- •Senaryo 2: Şifreleme var deniyor ama kanıt yok → Risk: denetimde boşluk → Aksiyon: teknik doküman talebi
- •Senaryo 3: Log sağlanmıyor → Risk: olay inceleme uzar → Aksiyon: log export/rapor yeteneği şartı
İç link notu: /tr/yazilim/sunucu-guvenlik, /tr/raporlama/kvkk-veri-guvenligi ve /tr/yazilim/kvkk-uyum-hizmeti sayfalarına bağlayın.
6. Bulut Sağlayıcı Teknik Soru & Değerlendirme Tablosunu İndir — Veri Analizi & Raporlama (v1.0)
Bulut Sağlayıcı Teknik Soru & Değerlendirme Tablosunu İndir — Veri Analizi & Raporlama (v1.0)
Bu audit sheet, otellerin bulut PMS/CRM/mailing/raporlama sağlayıcılarını veri merkezi lokasyonu ve güvenlik kontrolleri açısından standart biçimde değerlendirmesini sağlar. Amaç; lokasyon + şifreleme + erişim/loglama + yedek lokasyonu verilerini kanıtlanabilir şekilde toplamak ve KVKK raporuna “kısa teknik özet” olarak eklemektir. Yüksek riskli belirsizlikler aksiyon planına bağlanır.
Kim Kullanır?
IT/teknik ekip, ajans/entegrasyon ekibi, GM (onay), satınalma/operasyon lideri.
Nasıl Kullanılır?
- Sağlayıcıdan 10 sorunun cevaplarını yazılı alın ve tabloyu doldurun.
- Belirsiz veya kanıtsız alanları “yüksek risk” olarak işaretleyip aksiyon planı yazın.
- KVKK raporuna teknik özet paragrafını ve tabloyu ekleyin; yılda bir güncelleyin (Refresh 365).
Ölçüm & Önceliklendirme (Kısa sürüm)
- ▢ ✅ AUDIT SHEET – Sağlayıcı Teknik Soru Seti (kopyala–yapıştır)
- ▢ ✅ 1. Üretim verisi hangi ülke/region’da tutuluyor?
- ▢ ✅ 2. Yedekler hangi ülke/region’da tutuluyor?
- ▢ ✅ 3. Aktarımda şifreleme (in transit) var mı?
- ▢ ✅ 4. Depoda şifreleme (at rest) var mı?
- ▢ ✅ 5. Anahtar yönetimi modeli (yüksek seviye) nedir?
- ▢ ✅ 6. Admin erişimlerinde MFA/2FA zorunlu mu?
- ▢ ✅ 7. Erişim logları “kim/ne zaman/ne yaptı” sağlanabiliyor mu?
- ▢ ✅ 8. Log saklama süresi ve erişim rolleri nedir?
- ▢ ✅ 9. Olay yönetimi SLA/yanıt süresi nedir?
- ▢ ✅ 10. Restore testleri yapılır mı, rapor/kanıt verilir mi?
- ▢ ✅ AUDIT SHEET – Cloud Değerlendirme Tablosu
- ▢ ✅ İlk 10 Aksiyon Listesi (owner + tarih)
- ▢ ✅ Üretim lokasyonu kanıtı alındı | Owner: __ | Due: __
- ▢ ✅ Yedek lokasyonu kanıtı alındı | Owner: __ | Due: __
- ▢ ✅ Log export/rapor kanıtı alındı | Owner: __ | Due: __
- ▢ ✅ MFA zorunluluğu doğrulandı | Owner: __ | Due: __
- ▢ ✅ Restore test raporu talep edildi | Owner: __ | Due: __
- ▢ ✅ … (toplam 10)
- ▢ ✅ Öncesi/Sonrası KPI Tablosu
- ▢ ✅ Deliverables
- ▢ ✅ 10 soru cevap seti
- ▢ ✅ Cloud değerlendirme tablosu
- ▢ ✅ KVKK raporu teknik özet paragrafı + aksiyon planı
PDF içinde: Problem→Kök Neden→Çözüm tablosu + 14 gün sprint planı + önce/sonra KPI tablosu
Bir Sonraki Adım
Cloud provider’larınızı lokasyon+kontrol setiyle puanlayıp KVKK raporunu otelinize özel kurgulayalım.