1. KVKK’nın Dijital ve Web Tarafına Etkisi (Teknik Perspektif)
KVKK’yı web tarafında “metin” olarak düşünmek yerine sistem davranışı olarak ele almak gerekir: hangi veriyi alıyorsunuz, nerede saklıyorsunuz, kim erişiyor, ne kadar süre tutuyorsunuz ve bir ihlalde ne yapıyorsunuz? Web altyapısı; formlar, çerezler, sunucu logları, CDN/WAF kayıtları, analitik tag’leri ve üçüncü taraf widget’larla veri üretir. Bu yüzden uyum; ürün, yazılım, pazarlama ve operasyonun ortak kontrol alanıdır.
KVKK teknik uyum modeli nedir?
KVKK teknik uyum modeli; form + cookie + log + erişim + yedekleme + entegrasyon katmanlarının tek bir çerçevede değerlendirilmesidir. “Hangi veri nereden nereye akıyor?” sorusuna cevap veren basit bir veri akışı diyagramı olmadan, hangi kontrolün hangi riski azalttığını görmek zorlaşır. Bu model; hem otel rezervasyon akışında hem de B2B teklif/lead toplama akışında aynı mantıkla çalışır.
“Hukuki metin” ile “teknik gerçeklik” arasındaki fark
Aydınlatma metni ve açık rıza, sayfada yazan cümlelerdir; ama teknik gerçeklik şudur: veri gerçekten toplanıyor mu, gerçekten sınırlanıyor mu, gerçekten izleniyor mu? Örneğin “çerezler onaydan sonra çalışır” denirken, tag manager onay öncesi tetikleniyorsa uyumsuzluk oluşur. Ya da “erişim yetkileri kısıtlıdır” denirken admin paneli herkese açık test hesabıyla kalmışsa risk büyür.
☑ Mini Check :
- • Sitede kişisel veri üreten tüm noktalar listelendi mi? (form, chat, arama, üyelik, rezervasyon)
- • Tag’ler consent durumuna göre çalışıyor mu?
- • Erişim yetkileri (CMS/panel) rol bazlı mı?
- • Loglar kişisel veri içeriyor mu ve maskeleme var mı?
- • 3. taraf sistemlerle (PMS/CRM) veri akışı dokümante mi?
Ne yapmalıyım?
- • “Veri envanteri mini listesi” çıkarın: hangi sayfada hangi veri toplanıyor.
- • Consent ve tag tetiklerini kontrol edin (onay öncesi çalışan tag var mı?).
- • Admin/panel erişimlerini gözden geçirin (rol, MFA, IP kısıtı).
- • Loglarda maskeleme ihtiyacını belirleyin (IP, e-posta, telefon).
- • Entegrasyonlar için veri akışı diyagramını hazırlayın (Web → PMS/CRM/Call Center).
2. Veri Toplama Noktaları: Formlar, Çerezler, Loglar
Web tarafında KVKK riskini büyüten ana hata; veri toplama noktalarının “parça parça” görülmesidir. Oysa form alanları, çerezler ve loglar aynı hikâyenin farklı kayıtlarıdır: kullanıcı davranışı ve kimlik bilgisi. Otel ve B2B projelerinde özellikle “teklif al”, “broşür indir”, “rezervasyon sor” gibi formlar; pazarlama ekiplerinin en değerli varlığıdır ama en sık unutulan uyum noktasıdır.
Form ve kayıt alanları (lead, rezervasyon, üyelik)
Formlarda KVKK için kritik olan; asgarilik (gerekmeyen veriyi istememe), amaç (niçin toplandığı), açık rıza gerekip gerekmediği, aydınlatma linki ve log/kanıt (consent kayıtları) düzenidir. “Ad-soyad + telefon” alanını her formda istemek, pratikte dönüşümü de düşürür; KVKK açısından da gereksiz veri işleme riski doğurabilir. Ayrıca form submit’lerinde “hata mesajı” üzerinden bile veri sızması (ör. e-posta sistemde kayıtlı) yaşanabilir.
Formlarda teknik iyi pratikler (KVKK odaklı)
- •Alanları minimum tutun: “Bu alan gerçekten gerekli mi?” sorusunu her input için sorun.
- •Aydınlatma metni ve KVKK linkleri erişilebilir olmalı (mobilde kaybolmamalı).
- •Consent log’u tutun: timestamp, IP (gerekliyse maskeleme), form adı, consent versiyonu.
- •Form verisini ileten servislerde TLS/HTTPS zorunlu; e-posta ile ham veri göndermekten kaçının.
- •ReCAPTCHA/anti-bot kullanırken veri paylaşımını ve üçüncü taraf riskini bilin.
☑ Mini Check (Formlar):
- • Form alanları “minimum veri” prensibine göre düzenlendi mi?
- • Aydınlatma linki + gerekiyorsa açık rıza checkbox’ı doğru yerde mi?
- • Consent kayıtları (versiyon + zaman + kaynak) tutuluyor mu?
- • Form hataları veri ifşa etmiyor mu?
- • Form verisi admin panelde maskeleme ile görüntülenebiliyor mu?
Ne yapmalıyım?
- • En çok trafik alan 3 formu seçin ve alanları sadeleştirin.
- • Consent kayıtlarını tek formatta standardize edin.
- • Form verisinin nerede saklandığını netleştirin (DB, CRM, e-posta?).
- • E-posta ile ham veri gönderimini azaltın (panel/CRM üzerinden erişim).
- • “kvkk web checklist” yaklaşımıyla form sayfalarını tek tek test edin.
Çerez kategorileri ve consent mekanizması (CMP)
Çerez yönetimi; sadece banner’ın görünmesi değil, kategori bazlı kontrol ve tetik yönetimi demektir. “Zorunlu / Analitik / Pazarlama” kategorileri net olmalı; özellikle pazarlama piksel ve remarketing tag’leri, onay öncesi çalışmamalıdır. Bunun için CMP (Consent Management Platform) ile Tag Manager kurulumunun birbirine bağlı tasarlanması gerekir.
Consent tasarımında dönüşüm + uyum dengesi
Otel ve B2B projelerinde aşırı agresif banner tasarımları dönüşümü düşürür; aşırı pasif tasarımlar ise uyum riskini artırır. İyi pratik: ilk katmanda anlaşılır seçenekler, ikinci katmanda kategori detayları. Ayrıca “reddet” seçeneği erişilebilir olmalı; kullanıcı deneyimi kötüleşmeden şeffaflık sağlanmalıdır.
☑ Mini Check (Çerez & Consent):
- • Çerez kategorileri doğru tanımlandı mı? (zorunlu/analitik/pazarlama)
- • Onay öncesi çalışan pazarlama tag’i var mı?
- • Consent seçimi değiştirilebiliyor mu? (footer linki vb.)
- • Consent log’u tutuluyor mu? (versiyon, tarih)
- • Consent metinleri sade ve anlaşılır mı?
Ne yapmalıyım?
- • Tag Manager’da “consent state” kontrolü yapın.
- • Analitik/pazarlama tag’lerini kategori bazlı bağlayın.
- • Consent değişikliği için kalıcı bir erişim noktası ekleyin.
- • Banner metnini 2–3 cümlede netleştirin.
- • Otel rezervasyon sayfalarında (kritik funnel) UI’ı test edin.
Loglar: Sunucu, uygulama, CDN/WAF, analitik
KVKK perspektifinde loglar çoğu zaman “unutulan alan”dır. Çünkü loglar; IP, cihaz bilgisi, kullanıcı ajanı, hata payload’ları, bazen form verisi veya token’lar gibi kişisel veri barındırabilir. Üstelik loglar genellikle uzun süre saklanır; bu da saklama süresi ve erişim kontrolü riskini büyütür. Kurumsal web projelerinde yapılan KVKK teknik taramalarında, özellikle loglama ve erişim kayıtlarında ciddi eksikler sık görülür; checklist yaklaşımı bu eksikleri daha sistematik kapatır.
Loglarda risk yaratan 4 teknik anti-pattern
- Hata log’larına form payload yazmak (e-posta/telefon sızar)
- Sınırsız saklama (rotate yok, retention yok)
- Loglara herkesin erişebilmesi (rol yok, audit yok)
- Masking olmaması (IP/e-posta açık)
☑ Mini Check (Loglar):
- • Loglarda kişisel veri içerme ihtimali analiz edildi mi?
- • Retention/rotate politikası var mı?
- • Log erişimi RBAC + audit ile izleniyor mu?
- • Hata log’larında payload maskeleme var mı?
- • Üçüncü taraf log servislerinde (SaaS) veri işleme şartları net mi?
Ne yapmalıyım?
- • Uygulama ve sunucu log formatını denetleyin (PII var mı?).
- • Retention politikası belirleyin (ör. 180 gün periyodik gözden geçirme).
- • Log erişimlerini minimuma indirin (need-to-know).
- • Masking kuralı ekleyin (e-posta/telefon/IP).
- • “kvkk icin loglama erisim yedekleme” başlığını tek sprintte kapatın.
3. Erişim ve Yetki Yönetimi (RBAC, Audit, Panel Güvenliği)
KVKK’da teknik olarak en kritik başlıklardan biri “kim neye erişebiliyor?” sorusudur. Web sitesi sadece “public” bir yüz değildir; CMS, admin panel, rezervasyon/lead paneli ve entegrasyon panelleri (CRM, e-posta) içerir. Bu katmanlarda rol bazlı yetkilendirme (RBAC), audit log, MFA ve hesap yaşam döngüsü yönetimi yoksa; veri sızıntısı ihtimali ciddi yükselir.
Rol bazlı yetkilendirme (RBAC) ve hesap hijyeni
RBAC; “admin/her şeye yetkili” tek rol yerine; içerik editörü, pazarlama görüntüleme, satış erişimi, teknik admin gibi ayrımlar oluşturur. Otellerde; ön büro, çağrı merkezi, satış ve IT ekiplerinin farklı erişim ihtiyaçları vardır. B2B’de ise CRM yöneticisi, satış temsilcisi ve müşteri destek ekibi farklı görmelidir.
Minimum yetki (least privilege) ve operasyon akışı
Least privilege yaklaşımı; sadece güvenlik değil, operasyonel kalite sağlar. Yanlışlıkla silinen lead listeleri, yanlış fiyat/teklif paylaşımı veya panelde gereksiz veri görme gibi sorunlar azalır.
☑ Mini Check (Erişim & RBAC):
- • Panel/CMS’de roller tanımlı mı?
- • Admin hesap sayısı minimumda mı?
- • MFA aktif mi?
- • Parola politikası ve hesap kapatma süreci var mı?
- • Erişim olayları audit log’da tutuluyor mu?
Ne yapmalıyım?
- • Roller ve izin matrisi çıkarın (kim, hangi ekrana, hangi yetki).
- • MFA’yı zorunlu yapın (özellikle admin).
- • Eski hesapları kapatın (ex-employee risk).
- • Panel girişlerini IP/ülke bazlı kısıtlamayı değerlendirin.
- • Audit log’ları periyodik kontrol edin.
Erişim kayıtları (audit trail) neden KVKK için önemlidir?
Web sitesinde hangi teknik başlıklar KVKK ile ilişkilidir? Formlar, çerez yönetimi, loglar, panel erişimleri ve yedekleme/saklama düzeni KVKK’nın web tarafındaki ana teknik başlıklarıdır; çünkü kişisel veriyi toplar, işler, saklar ve eriştirirler. Audit trail; bir olay olduğunda “kim, ne zaman, hangi veriye erişti?” sorusunu yanıtlar. Bu, hem olay yönetimi (incident response) hem de iç kontrol açısından kritik bir güvence sağlar. Ayrıca ekip büyüdükçe; erişim karmaşası artar, audit trail yoksa “sorumluluk” ve “kanıt” üretmek zorlaşır.
☑ Mini Check (Audit Trail):
- • Kritik ekranlar için audit log var mı? (lead listesi, export, kullanıcı yönetimi)
- • Export/download işlemleri izleniyor mu?
- • Log bütünlüğü sağlanıyor mu? (değiştirilemezlik / WORM opsiyonları)
- • Yetki değişiklikleri kaydediliyor mu?
- • Düzenli inceleme periyodu var mı?
Ne yapmalıyım?
- • “Export/download” gibi kritik aksiyonları log’layın.
- • Kullanıcı/rol değişikliklerini audit’e alın.
- • Audit log’a erişimi sınırlandırın.
- • Aylık kısa kontrol rutini oluşturun (15 dk).
- • KVKK veri güvenliği perspektifi için /tr/raporlama/kvkk-veri-guvenligi sayfasına bağlayın.
4. Yedekleme ve Loglama: Saklama, Şifreleme, Geri Yükleme
Yedekleme; çoğu ekipte “var” kabul edilir ama KVKK teknik uyumu açısından üç soru önemlidir: (1) yedeklerde kişisel veri var mı, (2) yedekler şifreli mi ve kim erişiyor, (3) geri yükleme test ediliyor mu? Ayrıca loglama ile yedekleme birlikte düşünülmelidir; çünkü “iz” ve “veri” aynı güvenlik çemberinde korunur.
Yedekleme ve şifreleme temelleri
- •Yedekleri şifreleyin (at-rest encryption) ve anahtar yönetimini netleştirin.
- •Yedek erişimini RBAC ile sınırlandırın.
- •Yedek saklama süresini belirleyin; sınırsız tutmayın.
- •Geri yükleme testlerini yapın (sadece yedek almak yetmez).
Retention ve refresh (180 gün döngüsü)
Bu içerik için refresh cycle 180 gün; çünkü KVKK ikincil rehberleri ve kullanılan altyapılar (CMS/PMS/CRM/CMP) değiştikçe kontrol noktaları güncellenir. Teknik olarak da retention süreleri, log formatları ve entegrasyonlar zamanla evrilir.
☑ Mini Check (Backup & Encryption):
- • Yedekler şifreli mi?
- • Anahtar yönetimi ve erişim yetkisi net mi?
- • Retention süresi ve silme politikası var mı?
- • Geri yükleme testi periyodik mi?
- • Yedekler ayrı ortamda mı? (segmentation)
Ne yapmalıyım?
- • Yedeklerin şifreleme durumunu doğrulayın.
- • Geri yükleme testini takvime bağlayın (çeyrek dönem).
- • Retention politikasını yazılı hale getirin.
- • Log + backup erişimlerini ayrı rollerle yönetin.
- • Incident senaryolarında sorumluluk dağılımını netleştirin.
5. Otel ve B2B İçin KVKK Teknik Checklist’i (Uygulanabilir Rehber)
Otel ve B2B sitelerinde KVKK teknik checklist’i neler içermeli? Minimumda; form alanları ve consent kayıtları, çerez kategorileri ve tag tetikleri, loglarda maskeleme-retention, RBAC+MFA, yedekleme şifreleme ve PMS/CRM/Call Center veri akışı kontrolleri olmalıdır. Bu bölümde; “yayında siteler için KVKK teknik tarama checklist’i”ni operasyonel hale getireceğiz. Amaç; 1 günde mevcut durumu görmek, 14 günde kritik açıkları kapatmak ve 30 günde sürdürülebilir bir kontrol rutini kurmaktır.
Otel senaryosu: Web → Rezervasyon → PMS → Call Center
Otel projelerinde web sitesi; rezervasyon motoruna yönlendirir, kampanya formları lead üretir, çağrı merkeziyle satış kapanır. Bu akışta veri; bazen farklı sağlayıcılara gider. Bu nedenle “veri işleyen taraflar” ve “entegrasyon noktaları” hem teknik hem operasyonel olarak dokümante edilmelidir.
B2B senaryosu: Web → CRM → Doküman yönetimi → E-posta otomasyonu
B2B’de; teklif dosyaları, fiyat listeleri, sözleşmeler ve müşteri listeleri ayrı sistemlerde yaşar. Web’den CRM’e giden veri; e-posta otomasyonuna, doküman paylaşımına veya satış ekiplerinin cihazlarına taşınır. Bu da erişim kontrolünü daha kritik hale getirir.
“Çerez banner’ı ötesi” fark yaratan mini bölüm (Competitor gap kapanışı)
Piyasadaki içeriklerin çoğu sadece “cookie banner nasıl yapılır?” seviyesinde kalır. Oysa gerçek risk; form payload’ları, loglarda PII, panel yetkileri, export işlemleri ve yedeklerin kontrolsüzlüğü gibi noktalarda birikir. Bu rehberin farkı; bu alanları tek checklist çatısında birleştirip sprint planına bağlamasıdır.
☑ Mini Check (Uçtan uca):
- • Web → PMS/CRM/Call Center veri akışı çizildi mi?
- • Form verisi hangi sistemlere gidiyor, hangi ekip görüyor?
- • Export/download aksiyonları audit’e alındı mı?
- • Loglarda PII maskeleme var mı?
- • Yedekler şifreli mi, erişim kısıtlı mı?
Ne yapmalıyım?
- • “Veri akışı” diyagramını çıkarın ve ekiplerle doğrulayın.
- • Kritik 10 kontrolü seçin (form, consent, log, RBAC, backup).
- • 14 günlük sprint planı oluşturun ve sorumluları atayın.
- • Sonuçları raporlayın; /tr/raporlama/kvkk-veri-guvenligi ile ilişkilendirin.
- • 180 gün sonra refresh edin (altyapı ve rehberler değişebilir).
Önemli not (Teknik SEO Notu): Bu içerik hukuki danışmanlık değildir; teknik/operasyonel uyum rehberidir. Hukuki metinler ve yorumlar için avukat/uzmanla çalışılmalıdır. KVKK veri güvenliği raporlama çerçevesi için: https://dgtlface.com/tr/raporlama/kvkk-veri-guvenligi
| Alan | Kontrol | Durum (Var/Yok/Kısmi) | Aksiyon | Sorumlu | Süre |
|---|---|---|---|---|---|
| Formlar | minimum veri, aydınlatma linki, consent kayıtları, hata payload maskeleme | ||||
| Çerezler | kategori bazlı CMP, tag tetikleri, değiştirilebilir consent, log kaydı | ||||
| Loglar | PII maskeleme, rotate/retention, RBAC erişim, bütünlük | ||||
| Erişim | RBAC, MFA, audit trail, export izleme, hesap yaşam döngüsü | ||||
| Yedekleme | şifreleme, erişim kısıtı, retention, geri yükleme testleri | ||||
| Entegrasyon | Web→PMS/CRM/Call Center veri akışı dokümanı + sorumluluklar |
6. KVKK Uyumlu Web Altyapısı Teknik Checklist Şablonunu İndir — Yazılım / KVKK (v1.0)
KVKK Uyumlu Web Altyapısı Teknik Checklist Şablonunu İndir — Yazılım / KVKK (v1.0)
Bu asset; web sitesinde KVKK’ya temas eden teknik/operasyonel noktaları (form, çerez, log, erişim, yedekleme, entegrasyon) tek sayfalık bir tabloya indirger. Ekibin farklı parçalarının (yazılım, pazarlama, operasyon) aynı checklist üzerinden konuşmasını sağlar. Sonuçta “durum tespiti → öncelik → sprint planı” hattını hızlandırır.
Kim Kullanır?
Otel ve B2B projelerinde site sahibi/GM, pazarlama, ajans, yazılım/IT ekipleri.
Nasıl Kullanılır?
- 1 günde durum tespiti: Checklist tablosunda her maddeyi “Var/Yok/Kısmi” işaretleyin.
- Önceliklendirin: Risk + etki + efor kriteriyle ilk 10 aksiyonu seçin.
- 14 günlük sprint: Aksiyonları günlere bölün, sorumlu atayın, KPI ile kapanışı doğrulayın.
Ölçüm & Önceliklendirme (Kısa sürüm)
- ▢ ✅ Formlar: minimum veri, aydınlatma linki, consent kayıtları, hata payload maskeleme
- ▢ ✅ Çerezler: kategori bazlı CMP, tag tetikleri, değiştirilebilir consent, log kaydı
- ▢ ✅ Loglar: PII maskeleme, rotate/retention, RBAC erişim, bütünlük
- ▢ ✅ Erişim: RBAC, MFA, audit trail, export izleme, hesap yaşam döngüsü
- ▢ ✅ Yedekleme: şifreleme, erişim kısıtı, retention, geri yükleme testleri
- ▢ ✅ Entegrasyon: Web→PMS/CRM/Call Center veri akışı dokümanı + sorumluluklar
PDF içinde: Problem→Kök Neden→Çözüm tablosu + 14 gün sprint planı + önce/sonra KPI tablosu
Bir Sonraki Adım
Yayındaki otel/B2B sitenizde form–çerez–log–erişim–yedekleme risklerini tespit edip sprint planı çıkarır.