1. GDPR ve KVKK’nın Teknik Perspektiften Ortak Noktaları
GDPR ve KVKK teknik olarak hangi başlıklarda kesişir?
Kısa yanıt: veri envanteri (hangi veri nerede), veri akışı (nereye gidiyor), erişim kontrolleri (kim görüyor), logging/audit (kim ne yaptı) ve hak kullanımı/DSR (veri erişimi/silme/düzeltme) başlıklarında kesişir. Teknik ekip açısından bu kesişim, “tek mimari, iki okuma” yaklaşımını mümkün kılar.
Kesişim alanlarını “teknik kontrol alanlarına” çevirin
Aşağıdaki kontrol alanları, her iki rejimde de pratikte iş görür (hukuki yorumdan bağımsız olarak teknik kanıt üretir):
- •Veri envanteri: sistem → veri türü → owner
- •Erişim kontrolleri: RBAC/MFA/IP kısıtları
- •Loglama: login, export, yetki değişikliği, kritik erişim
- •Export yönetimi: kapsam/maskeleme/onay
- •DSR pipeline: kimlik doğrulama + çok sistemli veri çekme
- •Retention: prod/backup/log tutarlılığı
Rakip boşluğu: “hukuk farkı” yerine “tek pipeline”
TR’de içerikler çoğunlukla hukuki farklar seviyesinde kalır; oysa teknik ekip için asıl değer, “iki rejimi aynı anda kurgulamak”tır. Bu rehberin farkı; veri envanteri, log ve DSR’yi tek pipeline’da birleştirip rejimi etiket olarak ele almasıdır.
☑ Mini Check :
- •Veri envanteri güncel mi ve sistem owner’ları belli mi?
- •Kritik erişim (login/export) loglanıyor mu?
- •DSR akışı tek pipeline olarak yazılı mı?
- •Export’lar kapsam/maskeleme ile yönetiliyor mu?
- •Rejim (GDPR/KVKK) “etiket” olarak işlenebiliyor mu?
Ne yapmalıyım?
- • Teknik kontrol alanlarını sabitleyin: envanter, log, DSR, export, retention.
- • Her kontrol alanı için tek doküman ve tek owner belirleyin.
- • “Rejim etiketi” yaklaşımını benimseyin (aynı veri, farklı okuma).
- • Denetlenebilir loglama ile kanıt üretin.
- • KVKK veri güvenliği yaklaşımıyla hizalayın: https://dgtlface.com/tr/raporlama/kvkk-veri-guvenligi
2. Tek Veri Envanteri ile “Çifte” Düşünmek: Data Flow Mapping
GDPR+KVKK uyumunu iki ayrı envanterle yönetmek, kaçınılmaz olarak tutarsızlık üretir. Yeni bir vendor eklenir, bir entegrasyon değişir, bir script eklenir; iki envanterden biri güncellenmez. Bu yüzden “tek veri envanteri ile gdpr kvkk yönetimi” yaklaşımı en sürdürülebilir olandır.
Envanteri nasıl kurgulamalı?
Tek envanter, iki rejime de cevap verecek şekilde şu kolonları taşımalı:
- •Sistem (web/PMS/CRM/call center/OTA/BI)
- •Veri türü (kimlik/iletişim/rezervasyon/lead/not)
- •Kaynak (form/OTA/telefon/import)
- •Amaç (operasyon/satış/analitik)
- •Saklama (retention) + kapanış yöntemi
- •Erişim rolleri (kim görür)
- •Export kabiliyeti (var mı)
- •Rejim etiketi: KVKK/GDPR/ikisi (operasyonel etiket)
Otel örneği: “AB misafiri olan otel için GDPR↔KVKK” haritası
Otel tarafında web rezervasyon, PMS misafir kartı, call center notu ve OTA mesajı aynı kişiye ait olabilir. Bu yüzden envanterde “kaynak kanalı” ve “join anahtarı” (guest_id, rezervasyon no vb.) net olmalıdır.
☑ Mini Check :
- •Web/PMS/CRM/call center/OTA sistem listesi tam mı?
- •Veri türleri ve amaçlar net mi?
- •Join anahtarları dokümante mi?
- •Retention ve kapanış yöntemi yazılı mı?
- •Rejim etiketi kolon olarak var mı?
Ne yapmalıyım?
- • Tek bir envanter tablosu oluşturun ve “rejim etiketi” ekleyin.
- • Join anahtarlarını standardize edin (ID sözlüğü).
- • Otel için PMS/OTA akışını netleştirin: https://dgtlface.com/tr/pms-ota-yonetimi
- • Call center kaynaklarını ve not alanlarını sınırlayın: https://dgtlface.com/tr/cagri-merkezi-hizmetleri
- • Envanteri 180 gün döngüsüyle güncelleyin (refresh).
3. Loglama ve Erişim Kayıtlarını “Her İki Rejime de Raporlanabilir” Tutmak
Loglar, teknik dünyanın “kanıt” üretme aracıdır. Rejim farkı ne olursa olsun, şu sorular değişmez: kim erişti, neyi export etti, hangi yetki değişti, hangi anomali oldu? Bu nedenle loglama modeli rejimden bağımsız tasarlanmalı, çıktıların üstüne gerekirse rejim etiketi eklenmelidir.
Hangi loglar çekirdek set olmalı?
- •Login success/failure
- •Yetki/rol değişikliği
- •Export/download event
- •Kritik ekran erişimi (misafir kartı, sözleşme ekranı vb.)
- •DSR işlemleri (kimlik doğrulama, veri çekme, paket oluşturma)
Loglarda minimizasyon: kanıt üret, PII üretme
Loglar kanıt üretirken aynı zamanda PII üretebilir. Bu yüzden loglarda gereksiz payload tutmamak, masking uygulamak ve log erişimini RBAC+audit ile kısıtlamak kritik önemdedir.
☑ Mini Check :
- •Export olayları loglanıyor mu?
- •Yetki değişiklikleri audit’e giriyor mu?
- •Loglarda PII maskeleme var mı?
- •Log retention ve erişim politikası yazılı mı?
- •Loglar “denetim paketi”ne dönüşebilecek formatta mı?
Ne yapmalıyım?
- • “Çekirdek log seti”ni sabitleyin (login/export/role change).
- • Loglara masking kuralı ekleyin (e-posta/telefon/token).
- • Log erişimini daraltın; audit log’ları düzenli inceleyin.
- • Denetim için “log bundle” şablonu çıkarın (kapsam sınırlı).
- • KVKK veri güvenliğiyle birlikte yönetin: https://dgtlface.com/tr/raporlama/kvkk-veri-guvenligi
4. Hak Kullanımı (DSR) Pipeline’ını GDPR + KVKK’ya Uygun Tasarlamak
Hak kullanımı (DSR) pipeline’ını GDPR+KVKK’ya uygun nasıl tasarlarım?
Kısa yanıt: tek bir teknik akış kurun: talep toplama → kimlik doğrulama → çok sistemli veri çekme → güvenli export paketi → log/audit → yanıt. Ardından “rejim etiketi” ile hangi kural setinin devreye girdiğini operasyonel olarak işaretleyin. Böylece iki ayrı DSR sistemi işletmek yerine tek pipeline üzerinden çalışırsınız.
DSR’de iki kritik risk
- Yanlış kişiye veri vermek (kimlik doğrulama zayıf)
- Eksik veri vermek (sistem taraması eksik)
Tek pipeline, iki rejim: nasıl uygulanır?
- •Tek ticket sistemi (talep kaydı)
- •Tek kimlik doğrulama checklist’i
- •Tek sistem lookup listesi (web/PMS/CRM/call center/OTA)
- •Tek export paket formatı (PDF özet + CSV ekler)
- •Rejim etiketi: talep başında işaretlenir (GDPR/KVKK/ikisi)
Teknik pratik: “DSR kanıt paketi” oluşturun
Denetim veya itiraz anında, DSR yanıtının nasıl üretildiğini gösterebilmek için süreç loglarını ve export paket versiyonunu saklamak gerekir (kapsam/retention politika içinde).
☑ Mini Check :
- •Tek DSR ticket sistemi var mı?
- •Kimlik doğrulama adımları yazılı mı?
- •Çoklu sistem lookup listesi güncel mi?
- •Export paket formatı standard mı?
- •DSR adımları loglanıyor mu ve rejim etiketi tutuluyor mu?
Ne yapmalıyım?
- • DSR pipeline’ı tek dokümanda yazın (swimlane mantığı).
- • Sistem lookup tablosunu oluşturun ve owner atayın.
- • Export paketini standardize edin (PDF+CSV).
- • Süreci loglayın ve denetim paketi oluşturun.
- • Çağrı merkezi ve PMS süreçleriyle hizalayın: https://dgtlface.com/tr/cagri-merkezi-hizmetleri — https://dgtlface.com/tr/pms-ota-yonetimi
5. AB Misafirleri/Müşterileri Olan Oteller ve B2B Ekipleri İçin Teknik Haritalama
AB misafir/müşteri segmenti olan yapılarda en kritik fark, veri akışının ve vendor setinin daha karmaşık hale gelmesidir: çoklu dil/ülke, çoklu ödeme/rezervasyon akışı, çoklu pazarlama aracı. Teknik köprü yaklaşımı burada karmaşıklığı azaltır: tek envanter, tek logging, tek DSR.
Otel: AB misafiri olan otel için kritik pratikler
- •Rezervasyon akışı (web → booking engine → PMS) uçtan uca haritalı
- •OTA mesajlaşma ve call center notları sınırlı ve kontrollü
- •Consent ve pazarlama izinleri kanal bazlı ve kanıt kayıtlı
- •Export/raporlar masked view ile (isim yerine ID)
B2B: AB müşterisi olan ekipler için dikkat noktaları
- •CRM ve ticketing’de serbest metin alanları (PII mıknatısı)
- •Doküman link paylaşımı ve export kontrolü
- •Vendor erişim haritası + token/panel governance
- •BI raporlarında pseudo-ID ve masking
Key Statistic / Data Point (yumuşatılmış)
GDPR+KVKK kapsamındaki kurumlarda, tek teknik pipeline ile çalışan veri haritaları; denetim ve olay anlarında karmaşayı ciddi biçimde azaltır. Çünkü hangi verinin nereden geldiği, kimlerin eriştiği ve DSR yanıtının nasıl üretildiği “tek yerden” okunur.
☑ Mini Check :
- •Tek veri envanteri “rejim etiketi” ile çalışıyor
- •Loglama modeli denetlenebilir ve PII-minimize
- •DSR pipeline tek ve test edilmiş
- •BI/raporlar pseudo-ID/masking ile güvenli
- •Vendor erişim haritası güncel
- •180 gün refresh planı var
Ne yapmalıyım?
- • “Tek pipeline, iki rejim” diyagramını çıkarıp ekiplerle paylaşın.
- • Envanter + log + DSR üçlüsünü aynı doküman setinde toplayın.
- • Otel için rezervasyon/PMS akışını netleştirin.
- • B2B için CRM/ticketing serbest metin riskini azaltın.
- • KVKK veri güvenliğiyle bağlayın: https://dgtlface.com/tr/raporlama/kvkk-veri-guvenligi
Teknik not: Bu içerik iki rejim arasındaki teknik ortak paydaları gösterir. Hangi hükmün nerede geçerli olduğu, dışa aktarım ve benzeri hukuki detaylar mutlaka hukuk ekibiyle netleştirilmelidir. Refresh cycle: 180 gün (rehberler ve envanter değişebilir).
6. GDPR+KVKK Veri Envanteri & DSR Pipeline Planlama Şablonunu İndir — Yazılım / Multi-Regime
GDPR+KVKK Veri Envanteri & DSR Pipeline Planlama Şablonunu İndir — Yazılım / Multi-Regime (v1.0)
Bu şablon, GDPR ve KVKK’yı iki ayrı teknik sistem gibi yönetmek yerine tek veri envanteri + tek DSR pipeline üzerinde haritalamanızı sağlar. Sistem–veri–log–export ilişkilerini tek tabloda toplar ve “rejim etiketi” ile hangi senaryoda hangi çerçevenin devreye girdiğini görünür kılar. Otel ve B2B’de AB misafir/müşteri bulunan yapılarda operasyonel karmaşıklığı azaltır.
Kim Kullanır?
IT/BT + KVKK/uyum + sistem owner’ları (otel ve B2B).
Nasıl Kullanılır?
- Tek veri envanterini doldur (sistem, veri türü, owner, retention, rejim etiketi).
- DSR swimlane akışını yaz ve sistem lookup listesini bağla.
- Loglama ve export kanıt setini belirle; 180 gün refresh planı ekle.
Ölçüm & Önceliklendirme (Kısa sürüm)
- ▢ ✅ Tek envanter güncel
- ▢ ✅ Rejim etiketi kolon olarak işliyor
- ▢ ✅ DSR pipeline test edildi
- ▢ ✅ Log seti denetlenebilir
- ▢ ✅ Export kapsamı minimize
- ▢ ✅ 180 gün refresh planı var
PDF içinde: Problem→Kök Neden→Çözüm tablosu + 14 gün sprint planı + önce/sonra KPI tablosu
Bir Sonraki Adım
Tek veri envanteri, loglama ve DSR pipeline’ını otel/B2B sistemlerinizde birleştirir; iki rejimi “etiket” yaklaşımıyla yönetilebilir kılar.
Sık Sorulan Sorular
GDPR ve KVKK teknik olarak hangi başlıklarda kesişir?▾
AB misafir/müşteri verisi için web ve PMS’te ek ne yapmalıyım?▾
Hak kullanımı (DSR) pipeline’ını GDPR+KVKK’ya uygun nasıl tasarlarım?▾
Otel ve B2B için tek veri haritası ile iki hukuki rejimi nasıl yönetebilirim?▾
“İki rejim = iki sistem” yaklaşımının riski nedir?▾
İlgili İçerikler