1. Aile rezervasyonlarında hangi çocuk verileri teknik olarak işleniyor?
Aile rezervasyonlarında çocuk verisi genelde “oda planlaması ve fiyatlandırma” için kullanılır. Bu alanları aile rezervasyonlarında veri yönetimi bakışıyla ele alıp teknik olarak işlenen alanları üç gruba ayırmak iyi pratiktir: gerekli, opsiyonel ve riskli.
1) Çoğunlukla gerekli alanlar (operasyon odaklı)
- •Çocuk sayısı
- •Yaş grubu / yaş bandı (örn. 0–2, 3–6, 7–12 gibi)
- •Oda dağılımı (kaç yetişkin + kaç çocuk)
2) Opsiyonel alanlar (gerekçe ile)
- •Çocuk yaşı (tam yaş) (Varsayım: fiyatlandırma/aktivite için gerekiyorsa)
- •Özel ihtiyaç bilgisi (serbest metin yerine kategori tercih edilir)
3) Gereksiz risk üreten alanlar (raporda göstermemek / minimize etmek)
- •Çocuk adı/soyadı (çoğu raporda gereksiz)
- •Kimlik/pasaport gibi alanlar (çocuk için de yüksek risk)
- •Serbest notlarda çocukla ilgili detaylar (kontrolsüz PII riski)
AIO mantığı: Child Data → requires → stricter access & anonymised reporting
Bu yüzden çocuk verisi içeren alanlar, raporlama katmanında özellikle “maskeli/anonim” tasarlanmalıdır.
| Kategori | Alan | Yaklaşım |
|---|---|---|
| Gerekli | Çocuk sayısı | Tut |
| Gerekli | Yaş grubu / yaş bandı | Tut |
| Gerekli | Oda dağılımı | Tut |
| Opsiyonel | Çocuk yaşı (tam yaş) | Gerekçe ile |
| Opsiyonel | Özel ihtiyaç bilgisi | Kategori tercih edilir |
| Riskli | Çocuk adı/soyadı | Raporda göstermemek / minimize etmek |
| Riskli | Kimlik/pasaport gibi alanlar | Raporda göstermemek / minimize etmek |
| Riskli | Serbest notlarda çocukla ilgili detaylar | Raporda göstermemek / minimize etmek |
Mini örnek (Belek aile oteli)
Mini club ve aktivite planlamasında “yaş grubu” yeterlidir; çocuğun ismi çoğu yönetim raporunda gereksizdir. İsim alanının raporlarda görünmesi, screenshot veya yanlış paylaşımda ihlal etkisini büyütür.
Mini Check
- • Yaş grubu/çocuk sayısı alanları yeterli mi?
- • Çocuk ismi raporlarda görünüyor mu? (risk)
- • Serbest notlarda çocukla ilgili PII birikiyor mu?
Ne yapmalıyım?
- • “Gerekli alan seti”ni yazılı hale getirin.
- • Çocuk ismini raporlama katmanından çıkarın.
- • Serbest notları kategoriye çevirin (Varsayım).
2. PMS’de çocuk alanlarını nasıl sınırlamalı ve raporlamalıyım?
Çocuk alanlarını sınırlama, KVKK uyumunda “data minimization” prensibinin pratik karşılığıdır. Burada iki hedef var:
- PMS/rezervasyon ekranında gereksiz alanları doldurmamak
- Rapor katmanında çocuk verisini anonimleştirmek ve maskelemek
PMS/rezervasyon ekranında “minimum çocuk alan seti”
- •Çocuk sayısı
- •Yaş grubu/bant
- •Oda dağılımı (occupancy)
Bunun dışındaki alanlar “iş ihtiyacı” ile gerekçelenmelidir. Özellikle aile rezervasyonlarında mobil check-in verisi ve PMS aile rezervasyonu akışı içinde bu alanların ayrıca kontrol edilmesi gerekir.
Raporlama yaklaşımı: çocuk ismi yerine anonim göstergeler
Otel raporlarında şu göstergeler genelde yeterlidir:
- •Yaş grubu dağılımı (0–2 / 3–6 / 7–12)
- •Aile rezervasyonu oranı (toplam içinde)
- •Oda tipi bazlı çocuklu rezervasyon oranı
- •Sezon/hafta bazlı “çocuk sayısı trendi” (aggregate)
Mini örnek
“Side’da aile yoğunluğu arttı” raporu; isim listesi değil, yaş grubu ve oda tipi kırılımı ister. Bu hem karar aldırır hem PII riskini azaltır.
Mini Check
- • Raporlar isim/kimlik içermeden çalışıyor mu?
- • Çocuk verisi olan kayıtlar için erişim daha kısıtlı mı?
- • Export’lar (excel) kontrol altında mı?
Ne yapmalıyım?
- • “Çocuk verisi içeren kayıt” etiketini raporda kullanın (Varsayım: flag).
- • Varsayılan dashboard’u anonim KPI yapın.
- • Detay görünümü sadece gerekli role açın (RBAC yaklaşımı).
3. Çocuk verisini erişim ve raporlama açısından nasıl yönetirsiniz?
Çocuk verisi “daha sıkı erişim ve daha anonim raporlama” gerektirir. Bu yüzden çocuk verisi için yetki matrisi ile maskeleme ve erişim kısıtı birlikte düşünülmelidir. Uygulanabilir üç katman:
1) Rol bazlı erişim (Access Right)
- •Ön büro/rezervasyon: operasyon için minimum
- •Pazarlama: çocuk PII’ye erişim yok; yalnız aggregate KPI
- •IT: sistem yönetimi (PII görüntüleme değil)
- •Yönetim: yalnız KPI/aggregate; gerekirse olay bazlı rapor
2) Maskeleme (Masking)
Maskeleme örnekleri (raporda):
- •Çocuk adı varsa: C* ** (mümkünse hiç gösterme)
- •Yaş: tam yaş yerine yaş grubu
- •Oda no: gerekiyorsa kısmi (#12***)
3) Export ve paylaşım kontrolü (riskin büyüdüğü yer)
- •Çocuk verisi içeren raporlarda export kısıt
- •“Safe view” (maskeli) paylaşım
- •Export/access log (kim indirdi?) (Varsayım: altyapı destekliyorsa)
Key Statistics / Data Point (yumuşatılmış): Çocuk verisini maskeleyen ve erişimi kısıtlayan otellerde, yanlış ekran paylaşımı veya bölüm dışı erişim durumunda ihlal etkisinin ciddi ölçüde azalması teorik olarak beklenir; çünkü görünen veri isim değil anonim göstergedir.
Mini Check
- • Çocuk verisi içeren raporlar “safe view” ile mi paylaşılıyor?
- • Pazarlama katmanında çocuk PII var mı? (olmasın)
- • Export işlemleri izleniyor mu?
Ne yapmalıyım?
- • Çocuk verisi için ayrı “masking standardı” yayınlayın.
- • Çocuk PII’yi rapor katmanından çıkarın.
- • Aylık erişim review raporu oluşturun (RBAC + export).
4. Çocuk verisi içeren kayıtlarda saklama ve silme/anonimleştirme raporları
Çocuk verisi saklama politikası, kesin rakamlarla değil, “policy + kanıt” olarak ele alınır. Önemli olan:
- •Çocuk verisi içeren kayıtların saklama politikasının yazılı olması
- •Süre dolunca silme/anonimleştirme job’larının loglanması
- •Denetimde “policy + execution + summary” paketinin sunulması
Silme/anonim job log alanları (örnek)
- •job_id, executed_at
- •data_set: family_booking_child_fields
- •criteria: retention_expired
- •method: delete/anonymise
- •records_affected
- •result
Mini örnek
Çocuk isimleri raporlardan kaldırılmış olsa bile, PMS’te geçmiş kayıtlar kalabilir. Silme/anonim job raporu, “gerektiği kadar saklama” prensibini kanıtlar.
Mini Check
- • Retention policy yazılı mı?
- • Job raporu var mı?
- • Çocuk alanları anonimleştirilebiliyor mu? (Varsayım)
Ne yapmalıyım?
- • Çocuk alanlarını “yüksek hassasiyet” etiketiyle ayrı izleyin.
- • Silme/anonim job’larını aylık rapora ekleyin.
- • Denetim paketine 1 yıllık özet koyun.
5. 3 çocuk verisi risk senaryosu / 3 kontrol
- Risk: Raporlarda çocuk isimleri görünür → Kontrol: isim kaldır + yaş grubu KPI + safe view
- Risk: Pazarlama araçlarına çocuk PII akıyor → Kontrol: whitelist + minimization + sadece aggregate KPI
- Risk: Export ile dosya dışarı çıkıyor → Kontrol: export kısıt + access log + role-based erişim review
Aileye özel taleplerin çağrı merkezi tarafına taşındığı noktalarda aile rezervasyonu sonrası destek kayıtları ayrıca sınırlandırılmalıdır. İletişim tarafında ise aile segmentinde privacy-first iletişim yaklaşımı korunmalı; detay sorular için KVKK Veri Güvenliği Raporlama hakkında sık sorulan sorular sayfasına geçilmelidir.
6. Çocuk Verisi İçeren Alanlar & Maskeleme Checklist’ini İndir
Çocuk Verisi İçeren Alanlar & Maskeleme Checklist’ini İndir — Family Booking (v1.0)
Bu checklist, otellerin aile rezervasyonlarında çocuk verisini minimum alan setiyle yönetmesini ve raporlarda çocuk isimleri yerine yaş grubu/oda sayısı gibi anonim göstergelere geçmesini sağlar. Amaç; çocuk verisine erişimi sıkılaştırmak, yanlış ekran paylaşımı ve bölüm dışı erişim riskini düşürmek ve saklama/silme/anonimleştirme kanıtını loglarla üretmektir.
Kim Kullanır?
Ön büro, rezervasyon, IT/raporlama ekibi, GM (onay).
Nasıl Kullanılır?
- PMS/rezervasyon ekranında çocuk alanlarını “minimum set”e indirin.
- Dashboard’larda çocuk isimlerini kapatıp yaş grubu KPI’larına geçin; safe view oluşturun.
- Çocuk verisi içeren kayıtlar için erişim review + silme/anonim job raporunu aylık izleyin.
Ölçüm & Önceliklendirme (Kısa sürüm)
- ▢ ✅ Gerekli (tut): Çocuk sayısı
- ▢ ✅ Gerekli (tut): Yaş grubu/bant
- ▢ ✅ Gerekli (tut): Oda dağılımı
- ▢ ✅ Opsiyonel (gerekçe ile): Tam yaş (fiyat/aktivite gerekçesiyle)
- ▢ ✅ Opsiyonel (gerekçe ile): Özel ihtiyaç (kategori ile)
- ▢ ✅ Riskli (raporda gösterme / minimizasyon): Çocuk adı/soyadı
- ▢ ✅ Riskli (raporda gösterme / minimizasyon): Kimlik/pasaport alanları
- ▢ ✅ Riskli (raporda gösterme / minimizasyon): Serbest notlarda çocuk PII
- ▢ ✅ Çocuk isimleri raporda kapalı
- ▢ ✅ Yaş grubu KPI’ları aktif
- ▢ ✅ Oda/rezervasyon ID kısmi gösterim (#12***)
- ▢ ✅ Çocuk verisi içeren raporlarda export kısıtlı
- ▢ ✅ Erişim logu tutuluyor (kim erişti) (Varsayım: altyapı)
- ▢ ✅ Safe view paylaşım standardı var
PDF içinde: Problem→Kök Neden→Çözüm tablosu + 14 gün sprint planı + önce/sonra KPI tablosu
14 Günlük Sprint Planı (uygulama)
- •Gün 1–2: Çocuk alan envanteri + kullanım analizi
- •Gün 3–5: Minimum alan seti kararı + ekran düzeni
- •Gün 6–8: Dashboard maskeleme + KPI dönüşümü
- •Gün 9–11: Erişim rolleri + export kısıt
- •Gün 12–14: Retention/silme job raporu + audit pack güncellemesi
Bir Sonraki Adım
Aile konseptli otelinizde çocuk verisini minimizasyon + maskeleme + erişim raporlarıyla güvenceye alalım.
Sık Sorulan Sorular
Aile rezervasyonlarında çocuk verisi KVKK’ya göre nasıl ele alınmalı?▾
PMS’de çocuk alanlarını nasıl sınırlamalı ve raporlamalıyım?▾
Rapor ekranlarında çocuk isimlerini göstermek yerine hangi anonim göstergeler kullanılabilir?▾
Çocuk verisi içeren kayıtları saklama ve silme/anonimleştirme süreçlerini nasıl loglarım?▾
Çocuk verisi erişimini neden daha sıkı sınırlamalıyım?▾
İlgili İçerikler
İlgili Yazılar