1. Veri saklama süresi nedir, oteller için nasıl belirlenir?
Veri saklama süresi, her kişisel veri türünün “işleme amacı” tamamlandıktan sonra ne kadar süre tutulacağını tanımlayan politikadır. KVKK açısından amaç, “daha çok veri daha iyi” değil; gerektiği kadar sakla, sonra sil/anonimleştir yaklaşımıdır. Otellerde bu belirleme, tek bir departmanın kararı olamaz: hukuk + IT + operasyon birlikte çalışmalıdır.
AIO mantığını net kuralım:
RetentionPolicy → defines → how long each data type lives
Yani politika; veri türü bazında “yaşam süresi” tanımlar ve sistemlere uygulanır.
Otelde saklama politikasını belirleyen 4 soru
- Bu veri hangi amaçla tutuluyor? (rezervasyon yürütmek, fatura, güvenlik, pazarlama)
- Hangi sistem(ler)de yaşıyor? (PMS, muhasebe, CCTV, CRM)
- Kimlerin erişimi var? (rol bazlı)
- Süre bitince ne yapılacak? (silme mi, anonimleştirme mi?)
Mini örnek (Antalya/Belek):
Sezon yoğunluğunda pazarlama ekipleri “geçmiş misafir listesi”ni sürekli büyütür. Retention politikanız yoksa, liste yıllarca şişer; bu da hem gereksiz veri yükü hem de olası ihlalde etki büyümesi demektir. Politika, “ne kadar tutuyoruz ve ne zaman temizliyoruz?” sorusunu standardize eder.
Ne yapmalıyım?
- • Veri türlerini 6–8 kategoriye ayırın.
- • Her kategori için tek satırlık retention kararı yazın (süre + yöntem).
- • Politikanın sahibini belirleyin (Data Owner) ve yıllık güncelleme takvimi koyun.
2. Otellerde farklı veri türleri için saklama politikası nasıl kurgulanır?
Bu bölümde “hukuki süre rakamı” tartışmasına girmeden, otelin uygulayabileceği bir matris kurgusu veriyoruz. Kritik nokta: süreler hukuk birimiyle netleşir; biz burada modelin nasıl kurulacağını anlatırız.
Veri saklama matrisi (model)
Aşağıdaki matris; veri türü, sistem ve “süre + yöntem + kanıt” alanlarını tek ekranda toplar.
Varsayım notu: Bu tabloda süreler “hukukla belirlenir” olarak bırakıldı; amaç modelin iskeletini kurmaktır.
| Veri Türü | Sistem | Amaç | Saklama (yüksek seviye) | Süre bitince | Kanıt/Log |
|---|---|---|---|---|---|
| Misafir/rezervasyon | PMS | Konaklama operasyonu | Varsayım: hukukla belirlenir | Silme/anonim | Deletion job log |
| Fatura/finans | Muhasebe/ERP | Finansal kayıt | Varsayım: hukukla belirlenir | Silme/anonim | Audit trail |
| CCTV | Kamera sistemi | Güvenlik | Varsayım: hukukla belirlenir | Silme | CCTV retention log |
| Call center notu | CRM | Satış/rezervasyon | Varsayım: ihtiyaçla sınırlı | Anonimleştir | Anonymisation log |
| Pazarlama listesi | CRM/Email tool | Kampanya | Varsayım: izinli evren | Sil/anonim | Consent + deletion log |
Silme mi anonimleştirme mi? (pratik ayrım)
- •Silme: veriyi tamamen kaldırmak (en net minimizasyon)
- •Anonimleştirme: kişiyi tanımlanamaz hale getirip istatistiksel analiz için veri bırakmak
Otel analitiğinde (doluluk, trend) çoğu zaman kişisel tanımlayıcılar gereksizdir; anonimleştirme bazı use-case’lerde işlevsel olur.
Ne yapmalıyım?
- • Matrisi “tek kaynak gerçek” yapın (herkes buraya baksın).
- • Her satıra “kanıt” alanı ekleyin (denetim için).
- • Matristen yıllık temizlik planı üretin.
3. Silme/anonimleştirme işlemlerini nasıl kayıt altına alırsınız?
Denetimde kritik soru şudur: “Politikan var mı?” kadar “Uyguluyor musun?” sorusu da vardır. Uygulamanın kanıtı ise silme/anonimleştirme logları ve periyodik raporlardır.
Silme/anonimleştirme log kaydı (örnek alanlar)
- •job_id (toplu görev kimliği)
- •executed_at (zaman)
- •system (PMS/CRM/ERP/CCTV)
- •data_set (rezervasyon, call center notu…)
- •criteria (hangi koşulla seçildi: “süresi dolan”)
- •method (delete/anonymise)
- •records_affected (adet)
- •result (success/fail)
- •operator/automation (kim/otomasyon)
- •evidence_link (rapor dosyası / çıktı yolu)
“Şu tarihte şu veri seti şu yöntemle silindi” örneği (kayıt)
- •executed_at: 2026-01-12T03:00:00+03:00
- •system: CRM
- •data_set: marketing_list
- •criteria: retention_expired & no_active_consent
- •method: delete
- •records_affected: 1,240
- •result: success
- •evidence_link: /05_retention_reports/2026_Q1_cleanup.pdf
Mini örnek (Side):
Pazarlama listesindeki eski kayıtlar silinmezse, hem veri yükü artar hem de ihlal olursa etki büyür. Loglanan toplu silme görevleri, “süre dolunca temizliyoruz” kanıtını oluşturur.
Ne yapmalıyım?
- • Silme/anonim job’larını otomasyona bağlayın (Varsayım: mümkünse).
- • Her job için tek satır log kaydı üretin.
- • Başarısız job’ları “alarm” olarak izleyin.
4. Periyodik silme/anonimleştirme raporları nasıl hazırlanır?
Raporun amacı iki katmanlıdır:
- Yönetim: “ne kadar veri temizledik, risk nasıl düştü?”
- Denetim: “politika uygulanıyor mu?” kanıtı
Yıllık temizlik raporu mockup (içerik başlıkları)
- •Politika özeti (retention matrisinden)
- •Dönemsel job listesi (aylık/çeyreklik)
- •Silinen/anonimleştirilen kayıt adetleri (sistem bazlı)
- •Başarısız job’lar ve düzeltici aksiyonlar
- •İyileştirme planı (bir sonraki yıl)
Key Statistics / Data Point (yumuşatılmış)
Retention politikasını uygulayan otellerde gereksiz veri yükünün azalması, olası bir ihlalde “etkilenen kayıt sayısını” düşürerek risk profilini olumlu etkileyebilir.
Denetimde nasıl sunulur?
KVKK denetim paketinizde (audit pack) şu üç dosyayı birlikte sunmak güçlüdür:
- •Retention matrisi (policy)
- •Silme/anonim job log örnekleri (execution)
- •Yıllık temizlik raporu (summary)
İç link notu: /tr/raporlama/kvkk-veri-guvenligi ve /tr/yazilim/kvkk-uyum-hizmeti ile bağlayın; teknik altyapı için /tr/yazilim/sunucu-guvenlik.
Ne yapmalıyım?
- • Çeyreklik raporla başlayın, yılda 1 özet üretin.
- • “Başarısız job”ları KPI olarak izleyin.
- • Audit klasörüne tek paket halinde koyun.
5. Yıllık veri temizliği checklist’i
- •Retention matrisi güncellendi (sistem değişiklikleri işlendi)
- •Kritik veri setleri için süre bitince yöntem net (sil/anonim)
- •Silme/anonim job’ları takvimlendi (aylık/çeyreklik)
- •Job log kayıtları merkezi saklanıyor ve erişim kısıtlı
- •Başarısız job alarmı/izlemesi var
- •Pazarlama verisinde consent ile ilişki kurulmuş
- •Yıllık temizlik raporu üretildi ve audit pack’e eklendi
6. Veri Saklama Matrisi & Silme Log Şablonunu İndir — Veri Analizi & Raporlama
Veri Saklama Matrisi & Silme Log Şablonunu İndir — Veri Analizi & Raporlama (v1.0)
Bu asset, otellerin veri türlerine göre retention politikasını “saklama matrisi” ile standartlaştırmasını ve silme/anonimleştirme işlemlerini kanıtlanabilir log kayıtlarına dönüştürmesini sağlar. Amaç; KVKK’nın “gerektiği kadar sakla” ilkesini operasyonel uygulamaya bağlamak ve denetimde policy + execution + summary üçlüsünü tek pakette sunmaktır. Ek olarak 14 günlük kurulum sprint planı içerir.
Kim Kullanır?
IT/teknik ekip, operasyon lideri, GM (policy onayı için), ajans yöneticisi.
Nasıl Kullanılır?
- Saklama matrisini veri türü/sistem/amaç/yöntem alanlarıyla doldurun.
- Silme/anonim job’larını planlayın ve her job için log kaydı üretin.
- Çeyreklik rapor + yıllık özetle denetim paketini tamamlayın.
Ölçüm & Önceliklendirme (Kısa sürüm)
- ▢ ✅ A) Saklama Matrisi Şablonu (kopyala–yapıştır)
- ▢ ✅ B) Silme/Anonimleştirme Log Şablonu (kopyala–yapıştır)
- ▢ ✅ C) 14 Günlük Kurulum Sprint Planı (Gün 1–14)
- ▢ ✅ D) Öncesi/Sonrası KPI Tablosu
- ▢ ✅ Deliverables
- ▢ ✅ Saklama matrisi (policy)
- ▢ ✅ Job log kayıtları (execution)
- ▢ ✅ Çeyreklik/yıllık rapor şablonu (summary)
PDF içinde: Problem→Kök Neden→Çözüm tablosu + 14 gün sprint planı + önce/sonra KPI tablosu
Bir Sonraki Adım
Otelinizde retention matrisini ve yıllık temizlik planını, sistemlerinize göre birlikte tasarlayalım.