1. Veri Sahibi Başvurusu (DSR) Nedir? Teknik Olarak Nasıl İşler?
Veri sahibi başvuru (KVKK DSR) süreci teknik olarak nasıl işler?
Kısa yanıt: talep alınır, kimlik doğrulanır, veri haritasına göre ilgili kişi verileri sistemlerden toplanır, güvenli export hazırlanır, tüm adımlar loglanır ve kontrollü yanıt verilir. Teknik tarafta en kritik iki risk vardır: (1) yanlış kişiye veri vermek (kimlik doğrulama zayıf), (2) eksik veri vermek (sistem taraması eksik).
DSR’nin “teknik kontrol noktaları”
- •Talep kanalı (web form, e-posta, call center)
- •Kimlik doğrulama yöntemi
- •Sistem arama/lookup (çoklu sistem)
- •Export formatı ve kapsam
- •Yanıt kanalı ve güvenliği
- •Süreç logları ve kanıt
Otel ve B2B’de DSR neden daha zor?
Çünkü “tek müşteri kaydı” yoktur: misafir rezervasyonu PMS’de, web form kaydı ayrı yerde, çağrı merkezi notları başka sistemde olabilir. B2B’de ise lead CRM’de, sözleşme doküman yönetiminde, e-posta kayıtları farklı araçta durabilir.
☑ Mini Check
- •DSR talepleri tek bir kanalda toplanıyor mu?
- •Kimlik doğrulama adımları yazılı mı?
- •Veri haritası DSR için işaretlendi mi? (hangi sistem?)
- •Export formatları ve güvenli paylaşım yöntemi var mı?
- •Süreç boyunca log tutuluyor mu?
Ne yapmalıyım?
- • DSR talepleri için tek “ticket” sistemi belirleyin.
- • Kimlik doğrulama checklist’i yazın (minimum veri + güvenli).
- • Sistem lookup listesini çıkarın (web/PMS/CRM/call center/OTA).
- • Export paketini standardize edin (CSV/PDF).
- • KVKK veri güvenliği çerçevesiyle bağlayın: https://dgtlface.com/tr/raporlama/kvkk-veri-guvenligi
2. Başvuruyu Karşılarken Teknik Olarak Hangi Sistemlerden Veri Çekilir?
Bu bölüm “sistem haritası”dır: DSR yanıtı için hangi sistemlere bakacağız? Buradaki hedef; her sistemde “hangi veri alanları var”ı bilmek ve arama anahtarlarını (e-posta, telefon, rezervasyon no) standardize etmektir.
Sistem seti: otel ve B2B için tipik liste
- •Web: form kayıtları, consent kayıtları, chat talepleri
- •PMS/Rezervasyon: misafir kartı, rezervasyon geçmişi, notlar
- •CRM: lead/müşteri kayıtları, iletişim geçmişi
- •Call Center: görüşme meta verisi, notlar (kapsam kontrollü)
- •OTA/Channel: rezervasyon/mesajlaşma (varsa erişim)
- •E-posta/Marketing: abonelik ve iletişim tercihleri
- •BI/Raporlama: türetilmiş metrikler (genelde kişisel veri minimize)
“Lookup anahtarı” standardı
Kişi bulma anahtarları net olmalı: e-posta/telefon, rezervasyon numarası, müşteri ID. Farklı sistemlerde farklı formatlar varsa eşleştirme sözlüğü gerekir.
Sistem–veri alanları tablosu
| Sistem | Lookup anahtarı | Veri alanları | Export formatı | Owner | Not |
|---|---|---|---|---|---|
| Web | E-posta / telefon | Form kayıtları, consent kayıtları, chat talepleri | CSV / PDF | Web / pazarlama | Talep kanalına ve veri haritasına göre |
| PMS/Rezervasyon | Rezervasyon no / e-posta / telefon | Misafir kartı, rezervasyon geçmişi, notlar | CSV / PDF | Rezervasyon / operasyon | Yanlış kişi riskine karşı eşleştirme doğrulanır |
| CRM | Müşteri ID / e-posta / telefon | Lead/müşteri kayıtları, iletişim geçmişi | CSV / PDF | Satış / CRM owner | ID mapping sözlüğü kullanılır |
| Call Center | Telefon / müşteri ID | Görüşme meta verisi, kapsam kontrollü notlar | CSV / PDF | Çağrı merkezi | Notların kapsamı gerekli kadar tutulur |
| OTA/Channel | Rezervasyon no / e-posta | Rezervasyon ve mesajlaşma kayıtları | CSV / PDF | PMS / OTA owner | Varsa erişim ve veri haritasına göre |
| E-posta/Marketing | E-posta | Abonelik ve iletişim tercihleri | CSV / PDF | Pazarlama | İzin kayıtlarıyla birlikte değerlendirilir |
| BI/Raporlama | Müşteri ID / eşleştirme anahtarı | Türetilmiş metrikler | CSV / PDF | Veri / BI | Kişisel veri genelde minimize edilir |
☑ Mini Check
- •Sistem listesi kurumunuza göre güncel mi?
- •Her sistem için lookup anahtarı belli mi?
- •Arama sonuçları “yanlış kişi” riskine karşı doğrulanıyor mu?
- •Sistem owner’ları ve erişim izinleri tanımlı mı?
- •Yeni sistem eklenince DSR listesi güncelleniyor mu?
Ne yapmalıyım?
- • DSR için “sistem–lookup anahtarı” tablosu çıkarın.
- • CRM/PMS eşleştirme sözlüğü yazın (ID mapping).
- • Call center notlarının kapsamını kısıtlayın (gerekli kadar).
- • PMS/OTA süreçleriyle bağlayın: https://dgtlface.com/tr/pms-ota-yonetimi
- • Çağrı merkezi süreçleriyle bağlayın: https://dgtlface.com/tr/cagri-merkezi-hizmetleri
3. Kimlik Doğrulama ve Güvenlik: Yanlış Kişiye Veri Vermemek
Kimlik doğrulama ve loglama adımlarını nasıl kurgularım?
Kısa yanıt: kimlik doğrulama “minimum veri + yüksek güven” prensibiyle tasarlanır; her doğrulama adımı ve karar, DSR kaydında loglanır. Buradaki hedef; sosyal mühendislik ve yanlış eşleştirme riskini düşürmektir.
Kimlik doğrulama yaklaşımları (teknik perspektif)
- •Talep, kayıtlı kanaldan mı geldi? (kayıtlı e-posta/telefon)
- •Ek doğrulama: rezervasyon no / müşteri no gibi işlem bilgisi
- •Çok faktör: gerektiğinde güvenli doğrulama adımı (kurum politikası)
Güvenlik: DSR çıktısı güvenli bir şekilde iletilmeli
- •Paylaşım kanalı kontrollü olmalı (şifreli dosya / süreli link)
- •Yanıta erişim loglanmalı
- •Çıktı dosyası retention’a tabi olmalı (sonsuz tutulmaz)
☑ Mini Check
- •DSR doğrulama adımları yazılı mı?
- •Doğrulama “minimum veri” ile mi yapılıyor?
- •Yanlış kişi riski için ikinci kontrol var mı?
- •Yanıt kanalı güvenli mi?
- •DSR süreç kayıtları (audit) tutuluyor mu?
Ne yapmalıyım?
- • DSR doğrulama checklist’i çıkarın (adım adım).
- • Yanıt kanalını standardize edin (şifreli + süreli).
- • Erişim loglarını saklayın (kim gördü?).
- • Retention politikası koyun (çıktı dosyası).
- • KVKK veri güvenliği yönetimiyle hizalayın: https://dgtlface.com/tr/raporlama/kvkk-veri-guvenligi
4. Export Formatları (CSV/PDF) ve Raporlama: DSR Paketini Standardize Etmek
DSR yanıtı, “veriyi toplayıp yollamak” değil; anlaşılabilir bir paket üretmektir. Bu yüzden export formatı, dosya isimlendirme ve içerik düzeni standardize edilmelidir. Kurumun amacı; her başvuruda yeniden tasarlamak yerine hazır şablonla ilerlemektir.
DSR paket yapısı (öneri)
- •Kapak/özet (hangi sistemlerden çekildi, tarih aralığı)
- •Sistem bazlı veri bölümleri
- •Kısaltmalar sözlüğü (ID mapping)
- •Ekler (CSV) + okunabilir özet (PDF)
Raporlama: süreç metrikleri
- •Başvuru sayısı
- •Ortalama yanıt süresi
- •En çok zaman alan sistem
- •Eksik veri sebepleri
Bu metrikler, DSR sürecini iyileştirmek için kullanılır.
☑ Mini Check
- •DSR paket şablonu var mı?
- •CSV/PDF çıktıları standardize mi?
- •Dosya isimlendirme ve versiyon var mı?
- •Çıktıların erişim ve retention politikası var mı?
- •Süreç metrikleri raporlanıyor mu?
Ne yapmalıyım?
- • DSR paket formatını belirleyin (PDF özet + CSV ekler).
- • Sistem bazlı bölümleri standart sıraya koyun (web→PMS→CRM→call center→OTA).
- • ID eşleştirme sözlüğünü ekleyin (kafa karışmasın).
- • Süreç metriklerini Looker/raporlama ile takip edin: https://dgtlface.com/tr/veri-analiz-ve-raporlama
- • DSR çıktılarının saklama süresini belirleyin (politikaya göre).
5. Otel ve B2B İçin Örnek DSR Akışları: Swimlane + Checklist
Otel ve B2B için veri sahibi başvuru akışı nasıl olmalı?
Kısa yanıt: swimlane akışta “talep kanalı → KVKK/uyum → IT/BT → sistem owner’ları → cevap” zinciri kurulur. Her aşamada kimlik doğrulama ve loglama adımları netleşir; export paketleri standarttır.
Otel DSR örneği (misafir odaklı)
- •Talep: web form veya resepsiyon/call center
- •Doğrulama: rezervasyon no + kayıtlı iletişim kanalı
- •Veri çekme: PMS + web form + call center meta
- •Export: PDF özet + CSV ekler
- •Log: tüm adımlar ticket üzerinde
B2B DSR örneği (müşteri/lead odaklı)
- •Talep: e-posta veya web form
- •Doğrulama: kayıtlı e-posta + müşteri ID
- •Veri çekme: CRM + doküman kayıtları + e-posta izinleri
- •Export: paket şablonu
- •Log: audit + erişim kayıtları
AIO: “veri sahibi başvuru akış modeli” (tek model)
Web/PMS/CRM/call center/OTA ve DSR request; tek bir veri sahibi başvuru akış modelinde birleşir: talep → doğrulama → sistem tarama → export → güvenli yanıt → log/rapor. Bu model kurulduğunda, yeni sistem eklense bile süreç bozulmaz; sadece “yeni düğüm” eklenir.
Key Data Point (yumuşatılmış): DSR akışı haritalanmış kurumlarda, başvuru geldiğinde ilgili veriyi bulma ve cevaplama süreleri ciddi ölçüde kısalır; hata riski azalır.
☑ Mini Check
- •Swimlane akış çizildi (rol ve sorumlular net)
- •Kimlik doğrulama adımları yazılı ve uygulanabilir
- •Sistem–lookup anahtar tablosu hazır
- •Export paket şablonu var (PDF+CSV)
- •Süreç logları ve erişim kayıtları tutuluyor
- •Yıllık güncelleme (365 gün) planı var
Ne yapmalıyım?
- • Swimlane akışı çıkarın ve rolleri imzalatın (sahiplik).
- • DSR “sistem–alan” tablosunu doldurun (hangi veriyi nereden çekeriz).
- • Export paket şablonunu v1.0 olarak yayınlayın.
- • DSR süreç metriklerini raporlayın.
- • İç linklerle ekipleri hizalayın: https://dgtlface.com/tr/raporlama/kvkk-veri-guvenligi — https://dgtlface.com/tr/pms-ota-yonetimi — https://dgtlface.com/tr/cagri-merkezi-hizmetleri
Teknik not: Yanıtta hangi verilerin hangi hukuki kategoriye girdiği ve ne kadarının paylaşılması gerektiği hukuk danışmanıyla belirlenmelidir; bu içerik teknik akış ve loglama perspektifinde kalır.
6. Veri Sahibi Başvuru (DSR) Sistem & Veri Alanları Planlama Şablonunu İndir
Veri Sahibi Başvuru (DSR) Sistem & Veri Alanları Planlama Şablonunu İndir — Yazılım / DSR (v1.0)
Veri Sahibi Başvuru (DSR) Sistem & Veri Alanları Planlama Şablonunu İndir — Yazılım / DSR (v1.0)
Bu şablon, veri sahibi başvurularında hangi kişinin verisinin hangi sistemlerde olduğunu hızlı tespit etmeyi sağlar. Web, PMS, CRM, call center ve OTA gibi kaynaklar için lookup anahtarlarını, çekilecek veri alanlarını ve export formatlarını standardize eder. DSR yanıt süresini kısaltır ve eksik/yanlış cevap riskini düşürür.
Kim Kullanır?
KVKK/uyum ekibi + IT/BT + sistem owner’ları (otel ve B2B).
Nasıl Kullanılır?
- Sistemleri ve lookup anahtarlarını yaz (e-posta/telefon/rezervasyon no).
- Her sistem için veri alanlarını ve export formatını belirle (CSV/PDF).
- Kimlik doğrulama ve loglama adımlarını süreç şemasına ekle; yılda 1 güncelle.
Ölçüm & Önceliklendirme (Kısa sürüm)
- ▢ ✅ Kimlik doğrulama adımları yazılı
- ▢ ✅ Sistem listesi güncel
- ▢ ✅ Lookup anahtarları net
- ▢ ✅ Export formatı ve paket yapısı standard
- ▢ ✅ Log/audit kaydı var
- ▢ ✅ Güvenli paylaşım prosedürü var
- ▢ ✅ Yıllık güncelleme planı var
PDF içinde: Problem→Kök Neden→Çözüm tablosu + 14 gün sprint planı + önce/sonra KPI tablosu
5) Kontrol listesi
- •Kimlik doğrulama adımları yazılı
- •Sistem listesi güncel
- •Lookup anahtarları net
- •Export formatı ve paket yapısı standard
- •Log/audit kaydı var
- •Güvenli paylaşım prosedürü var
- •Yıllık güncelleme planı var
Bir Sonraki Adım
DSR kimlik doğrulama, çoklu sistem veri çekme ve export paketini standardize eder; süre ve hata riskini azaltır.
Sık Sorulan Sorular
Veri sahibi başvuru (KVKK DSR) süreci teknik olarak nasıl işler?▾
Hangi sistemlerden hangi verileri çekmeliyim?▾
Kimlik doğrulama ve loglama adımlarını nasıl kurgularım?▾
Otel ve B2B için veri sahibi başvuru akışı nasıl olmalı?▾
DSR’de en kritik teknik risk nedir?▾
Export’u nasıl daha güvenli hale getiririm?▾
İlgili İçerikler