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. 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ırlamak, 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.
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. 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ı
Saklama süresi 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
İç link notu: /tr/raporlama/kvkk-veri-guvenligi, /tr/pms-ota/rezervasyon-yonetimi, /tr/yazilim/kvkk-uyum-hizmeti ve /tr/cagri-merkezi/satis-sonrasi-destek sayfalarına bağlayın.
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