1. Mobil check-in/dijital anahtar çözümlerinde hangi veriler toplanır?
Mobil check-in ve dijital anahtar tarafında veri ikiye ayrılır: (1) check-in verisi ve (2) anahtar/oda erişim olay logları. KVKK raporlama için önce bu iki katmanı ayırmak gerekir.
1) Mobil check-in’de işlenen veri türleri (örnek)
- •Kimlik/iletişim (misafirin uygulamada verdiği bilgiler)
- •Rezervasyon referansı / check-in doğrulama bilgisi
- •Oda ataması ile ilişkili bilgiler (room assignment)
- •Zaman bilgisi (check-in/out timestamp)
2) Dijital anahtar verisi ve logları (kritik kanıt seti)
- •Dijital anahtar üretimi (issue) ve iptal (revoke) olayları
- •Anahtar yeniden atama (re-issue)
- •Oda kapısı açma olayları (unlock events)
- •Cihaz ID ve/veya push token gibi teknik alanlar
- •Yetkili kullanıcı/rol (kim atadı, kim iptal etti) (Varsayım: sistem logluyorsa)
| Alan | Açıklama | Örnek |
|---|---|---|
| event_id | Tekil olay | key_001 |
| event_type | issue/revoke/reissue/unlock | unlock |
| timestamp | Olay zamanı | 2026-01-12T10:15+03:00 |
| room_id | Oda | 1207 |
| device_id | Cihaz kimliği | dev_xxx |
| actor_role | Kim tetikledi | guest/app / staff |
| result | success/fail | success |
| reason | incident_id (varsa) | INC-2026-014 |
3) “Teknik alanlar” ile “PII” ayrımı
- •Teknik: cihaz ID, token, session (operasyon kanıtı)
- •PII: misafir kimlik/iletişim (minimize edilmesi gerekir)
Bu ayrım raporda net olmalı; aksi halde anahtar logları “kimlik deposuna” dönüşür.
Mini örnek (Antalya modern resort)
Mobil check-in yaygınlaştıkça “anahtar iptali” ve “yeniden atama” olayları artabilir (telefon değişti, uygulama kapandı). Bu olayların loglanması, hem güvenlik hem misafir deneyimi için kritiktir.
Mini Check
- • Check-in verisi ile anahtar logları ayrıldı mı?
- • Cihaz ID/token gibi alanlar yalnız teknik amaçla mı tutuluyor?
- • Oda açma logları erişim kısıtıyla korunuyor mu?
Ne yapmalıyım?
- • Mobil check-in veri akışını data map’e ekleyin.
- • Anahtar loglarını “yüksek hassasiyet” sınıfında yönetin.
- • Misafir kimlik verisini log sistemine gereksiz taşımayın.
2. Bu verileri KVKK’ya uygun nasıl raporlarsınız?
KVKK uyumlu raporlama, 4 parçaya bölünür: data map, retention, role-based access, incident/audit raporu.
1) Mobil check-in akışını veri haritasına eklemek (data map)
Uygulama → PMS → Kilit sistemi akışını tek şemada gösterin:
- •Misafir uygulamada check-in → PMS doğrular → oda atanır → dijital anahtar üretilir → kilit sistemiyle eşleşir → oda açma olayları loglanır
2) Saklama süresi (Retention) – “ne kadar yaşar?”
Kesin süre rakamı vermek yerine (hukukla belirlenmeli), raporlama standardı:
- •Check-in verisi: operasyonel ihtiyaç bitince minimize edilir
- •Anahtar logları: olay inceleme ve kanıt ihtiyacı için politika ile saklanır
- •Süre dolunca silme/anonimleştirme job’u (Varsayım: uygulanabiliyorsa) ve kanıt raporu
3) Erişim yetkisi (RBAC) – “kim görür?”
- •Ön Büro: check-in operasyonu
- •Güvenlik: olay inceleme (unlock log)
- •IT: sistem yönetimi (loglara sınırlı)
- •Yönetim: sadece olay bazlı onayla rapor (Varsayım)
4) Erişim/export logları – “kim, ne yaptı?”
Anahtar loglarına erişim ve export, CCTV ve call center kayıtlarında olduğu gibi “kırmızı alan”dır:
- •access log: user/role, timestamp, log_id, action, reason, result
- •export listesi: incident_id ile
Mini Check
- • Data map çizildi mi?
- • Retention policy yazılı mı?
- • Unlock log erişimi role-based mi?
- • Export işlemleri incident_id ile izleniyor mu?
Ne yapmalıyım?
- • Unlock event log’larını “audit pack” içinde ayrı klasör olarak tutun.
- • Erişimi ve export’u loglayın.
- • Check-in verisini pazarlama katmanına “minimum” şekilde aktarın (Varsayım: gerekiyorsa).
3. Dijital anahtar logları ne kadar saklanmalı, kimler erişmeli?
Bu sorunun cevabı, otelin risk profili ve hukuk/uyum değerlendirmesine bağlıdır; ancak pratik prensipler sabittir:
- •Saklama süresi “olay inceleme ihtiyacı” ve “gerektiği kadar saklama” dengesiyle belirlenir
- •Erişim, en az yetki (least privilege) ile sınırlandırılır
- •Misafir taleplerinde (ör. “odam açıldı”) kanıt üretmek için loglar korunur; ama herkesin erişimine açılmaz
“Benim odamı kim açtı?” talebi için rapor yaklaşımı
- •Tam logu paylaşmak yerine, yetkili ekip tarafından olay raporu üretilir
- •Logdan ilgili zaman aralığı çıkarılır
- •Rapor, gerekli minimum bilgiyi içerir (kimlik ifşası üretmeden)
Mini örnek
Misafir “odama biri girdi” dediğinde, anahtar logları güvenlik için hızlı kanıt sağlar. Ama bu logları geniş erişime açmak yeni risk doğurur. Çözüm, “rapor üretimi” ve erişim loglamasıdır.
Mini Check
- • Erişim rolleri net mi?
- • Misafir talepleri için “rapor üretim” prosedürü var mı?
- • Retention job raporu var mı?
Ne yapmalıyım?
- • “Unlock log” erişimini sadece güvenlik/özel role verin.
- • Misafir talebi için standart rapor şablonu kullanın.
- • Retention politikasını yıllık güncelleyin (Refresh 365).
4. Olay ve ihlal incelemelerinde kullanılacak raporlar
Mobil check-in ve dijital anahtar sistemleri, “incident response” için yeni kanıt kaynakları oluşturur. Denetimde ve olay incelemede minimum rapor seti:
Minimum audit/incident rapor seti
- Mobil check-in veri akışı haritası (data map)
- Dijital anahtar log alan seti (schema)
- Son 90 gün erişim/export log özeti
- Anahtar iptal/yeniden atama raporu (trend)
- Retention/silme kanıtı (Varsayım: job raporu)
3 tip ihlal senaryosu / 3 kontrol
- Senaryo: Yetkisiz anahtar yeniden atama → Kontrol: RBAC + re-issue log + onay
- Senaryo: Loglara geniş erişim → Kontrol: role-based view + access log + periyodik review
- Senaryo: Cihaz/token verisi pazarlamaya sızıyor → Kontrol: minimization + anonim KPI yaklaşımı
Key Statistics / Data Point (yumuşatılmış): Dijital anahtar logları, güvenlik olaylarında ve misafir taleplerinde kritik kanıt kaynağıdır; bu nedenle doğru saklama ve raporlama, hem operasyonel netlik hem KVKK riski açısından değer üretir.
İç link notu: /tr/pms-ota/pms-kurulum, /tr/otel/pms-entegrasyonu, /tr/raporlama/kvkk-veri-guvenligi ve /tr/yazilim/kvkk-uyum-hizmeti sayfalarına bağlayın.
5. Mobil Check-in Veri Haritası & Anahtar Log Şablonunu İndir
Mobil Check-in Veri Haritası & Anahtar Log Şablonunu İndir — Mobile & Key Data (v1.0)
Bu audit sheet, otellerin mobil check-in ve dijital anahtar süreçlerinde oluşan veri akışını (uygulama→PMS→kilit sistemi) haritalamasını ve anahtar erişim olaylarını kanıtlanabilir log şemasıyla raporlamasını sağlar. Amaç; anahtar atama/iptal/yeniden atama ve oda açma olaylarını rol bazlı erişim, retention ve export kontrolüyle yöneterek denetim ve olay incelemede netlik üretmektir.
Kim Kullanır?
IT/entegrasyon ekibi, ön büro, güvenlik, GM (onay).
Nasıl Kullanılır?
- Data map şablonuna sistemleri ve veri setlerini yazın (check-in verisi vs key logs).
- Anahtar log alan setini doldurun; erişim ve export’u incident_id ile şartlandırın.
- Aylık raporda erişim/export sayısı ve iptal/yeniden atama trendlerini KPI olarak izleyin.
Ölçüm & Önceliklendirme (Kısa sürüm)
- ▢ ✅ Unlock log erişimi role-based sınırlandı | Owner: __ | Due: __
- ▢ ✅ Re-issue işlemleri onay akışına bağlandı (Varsayım) | Owner: __ | Due: __
- ▢ ✅ Export incident_id zorunlu | Owner: __ | Due: __
- ▢ ✅ Retention policy yazıldı | Owner: __ | Due: __
- ▢ ✅ Aylık KPI raporu kuruldu | Owner: __ | Due: __
PDF içinde: Problem→Kök Neden→Çözüm tablosu + 14 gün sprint planı + önce/sonra KPI tablosu
Bir Sonraki Adım
Mobil check-in ve anahtar log yönetiminizi otelinize özel kuralım.
Sık Sorulan Sorular
Mobil check-in ve dijital anahtar sistemlerinde hangi kişisel veriler işlenir?▾
Dijital anahtar logları ne kadar saklanmalı, kimler erişmeli?▾
Mobil check-in akışını KVKK veri haritasına nasıl eklerim?▾
Olası bir ihlalde mobil check-in verilerini nasıl raporlarım?▾
“Benim odamı kim açtı?” talebinde doğru yaklaşım nedir?▾
İlgili İçerikler
İlgili Yazılar