1. Veri Sorumlusu vs Veri İşleyen Ayrımı (Teknik Çerçeve)
Veri işleyen vendor’lar için teknik due diligence nasıl yapılır?
Kısa yanıt: önce vendor’ın hangi rol ve kapsamda hangi veriye eriştiğini netleştir (vendor–sistem–veri), sonra erişim yollarını çıkar (API/FTP/panel), ardından token ve admin erişim kontrollerini uygula (RBAC/MFA/IP), entegrasyon loglarını tut ve düzenli gözden geçirme takvimi koy.
Teknik çerçevede ayrım: “kim işliyor, nerede işliyor, nasıl erişiyor?”
- •Kim: vendor ve alt bileşenleri (sub-processor)
- •Nerede: sistemler (CRM, web, call center, BI)
- •Nasıl: API token, panel hesabı, FTP, webhook
En sık hata: “vendor erişimi görünmez”
Erişim haritası yoksa vendor değiştirme veya olay anında “kim neye erişiyordu?” sorusu yanıtsız kalır. Teknik due diligence’in asıl çıktısı bu haritadır.
☑ Mini Check :
- •Vendor listesi güncel mi? (CRM, chat, call center, bulut, raporlama)
- •Her vendor için erişim yolu net mi (API/FTP/panel)?
- •Eriştiği veri türleri yazılı mı?
- •Token/anahtar yönetimi var mı?
- •Entegrasyon logları tutuluyor mu?
Ne yapmalıyım?
- • Vendor envanteri çıkarın ve owner atayın.
- • Vendor–sistem–veri eşlemesini tabloya dökün.
- • Erişim yollarını ve token’ları listeleyin.
- • Panel erişimlerini rol bazlı kısıtlayın.
- • KVKK veri güvenliği çerçevesiyle bağlayın: https://dgtlface.com/tr/raporlama/kvkk-veri-guvenligi
2. Üçüncü Taraf Hizmetlerde Teknik Due Diligence: CRM, Bulut, Chat, Call Center
Vendor’ların hepsi aynı riskte değildir; risk, erişilen veri türü ve entegrasyon tipine göre artar. Örneğin call center çözümü konuşma notları ve müşteri kimliği içeriyorsa risk yükselir; chat aracı form verisi topluyorsa masking ve consent kritik olur.
Vendor riskini 3 eksende puanlayın
- Erişilen veri hassasiyeti (iletişim, kimlik, ödeme, notlar)
- Erişim yolu (API token geniş yetkili mi, panel admin mi?)
- Dağıtım (tek sistem mi, çok sistem mi?)
Otel örnekleri
- •Call center: müşteri/misafir iletişim + notlar
- •OTA/channel: rezervasyon meta verisi + mesajlar
- •CRM/pazarlama: segment ve iletişim izinleri
B2B örnekleri
- •SaaS CRM: lead/müşteri + sözleşme ilişkisi
- •Ticketing: destek talepleri (serbest metin riski)
- •Raporlama: export risk yüzeyi
☑ Mini Check :
- •Vendor risk skoru var mı (yüksek/orta/düşük)?
- •Yüksek riskli vendor’larda erişim kısıtı daha sıkı mı?
- •Serbest metin alanları maskeleniyor mu?
- •Vendor sub-processor/alt servisleri biliniyor mu?
- •Riskli vendor’lar için tatbikat/denetim planı var mı?
Ne yapmalıyım?
- • Vendor’ları risk seviyesine göre sınıflandırın.
- • Yüksek riskli vendor’larda MFA/IP allowlist zorunlu yapın.
- • Serbest metin alanları için kural koyun (kısıt/uyarı/masking).
- • Alt servisleri (sub-processor) envantere ekleyin.
- • Sunucu güvenliği ile birlikte ele alın: https://dgtlface.com/tr/yazilim/sunucu-guvenlik
3. Entegrasyon ve Erişim Kontrolleri: API/FTP, Token, Panel
API ve panel erişimlerini KVKK açısından nasıl güvene alırım?
Kısa yanıt: minimum yetki (least privilege) uygulayın, token’ları sınırlayın/rotasyon yapın, panel erişimlerinde RBAC+MFA+IP kısıtı kullanın ve tüm entegrasyon işlemlerini loglayın. Entegrasyon “bir kez kuruldu” diye bırakılmaz; yaşam döngüsü yönetilmelidir.
API token/key yönetimi (pratik standart)
- •Token kapsamı: sadece gereken endpoint’ler
- •Token rotasyonu: periyodik (kurum standardı)
- •Token saklama: secrets manager
- •Token sızıntısı: revoke/rotate prosedürü
FTP / dosya aktarımı (eski ama yaygın)
- •Şifreli aktarım kanalı, erişim kısıtı
- •Dosya isimlendirme ve retention
- •Transfer logları (kim aldı, ne zaman)
Vendor panel erişimi
- •RBAC: admin vs viewer ayrımı
- •MFA zorunlu
- •IP allowlist / VPN
- •Audit log: login + kritik aksiyonlar
“Shadow access” problemi: ayrılan çalışan ve ajans hesapları
Vendor panelinde unutulan hesaplar, en büyük risk yüzeylerinden biridir. Bu yüzden hesap yaşam döngüsü vendor tarafında da yönetilmelidir.
☑ Mini Check :
- •Token’lar minimum yetkili mi?
- •Rotasyon ve revoke prosedürü var mı?
- •Secrets manager kullanılıyor mu?
- •Vendor panelde RBAC+MFA var mı?
- •Vendor hesapları düzenli temizleniyor mu?
Ne yapmalıyım?
- • Token envanteri çıkarın (hangi sistem, hangi vendor, hangi yetki).
- • Rotasyon takvimi belirleyin ve otomatikleştirin.
- • Panel erişimlerini IP/MFA ile daraltın.
- • Ayrılan çalışan/ajans hesaplarını kapatma prosedürü yazın.
- • CMS entegrasyonlarıyla ilişkili vendor’ları da kapsayın: https://dgtlface.com/tr/yazilim/cms-entegrasyonu
4. Hangi Vendor Hangi Verilere Erişiyor? Haritalama ve Raporlama
Hangi vendor hangi verilere erişiyor, nasıl haritalarım?
Kısa yanıt: vendor–sistem–veri türü tablosu çıkarın; her satıra erişim yolu (API/FTP/panel), erişim kapsamı, owner ve log/retention bilgisini ekleyin. Bu tablo, hem denetimde hem vendor değişiminde “tek doğrulama noktası” olur.
Haritalama tablosu zorunlu kolonlar
- •Vendor adı
- •Sistem (web/CRM/PMS/call center/BI)
- •Veri türü (iletişim/rezervasyon/lead/not)
- •Erişim yolu (API/FTP/panel)
- •Yetki seviyesi (read/write/export)
- •Token/hesap owner
- •Log var mı? (E/H)
- •Lokasyon (varsa)
- •Son gözden geçirme tarihi (365 gün)
Key Data Point (yumuşatılmış)
Vendor erişim haritası çıkarılan projelerde, vendor değiştirme veya ihlal durumunda “hangi veriye kim erişiyordu?” sorusuna yanıt bulmak çok daha kolay olur; olay yönetimi hızlanır.
☑ Mini Check :
- •Vendor–sistem–veri tablosu var mı?
- •Yetki seviyesi (read/write/export) işlenmiş mi?
- •Token/hesap owner’ları belirli mi?
- •Son gözden geçirme tarihi var mı?
- •Harita denetim/prova akışına bağlı mı?
Ne yapmalıyım?
- • Haritalama tablosunu tek sahipte yönetin (BT + KVKK).
- • Yetki seviyesini yazmadan satırı “tamam” saymayın.
- • Her vendor için “log var mı” sorusunu zorunlu alan yapın.
- • Yıllık gözden geçirme rutini koyun (365 gün).
- • KVKK veri güvenliği ile bağlayın: https://dgtlface.com/tr/raporlama/kvkk-veri-guvenligi
5. Otel ve B2B İçin Vendor Kontrol Checklist’i: Süreç ve Sürdürülebilirlik
Vendor due diligence bir kere yapılıp bırakılırsa 6 ay sonra bozulur: yeni kampanya aracı eklenir, yeni API token çıkar, ajans hesabı açılır… Bu yüzden sürdürülebilir model; onboarding → periyodik review → offboarding döngüsüdür.
Vendor onboarding (teknik)
- •Erişim talebi formu (hangi veri, hangi amaç)
- •Minimum yetki token/panel kurgusu
- •Loglama ve audit onayı
- •Test ortamı ve veri minimizasyonu
Periyodik review (3–6 ay / yıllık)
- •Token rotasyonu kontrolü
- •Panel kullanıcı temizliği
- •Erişim kapsamı değişti mi?
- •Log/retention uyumu
Vendor offboarding (çıkış)
- •Token revoke
- •Panel hesap kapatma
- •Veri iadesi/silme (politikaya göre)
- •Kapanış raporu ve kayıt
AIO: “vendor teknik risk modeli” (tek model)
Vendor, data processor, API/token, panel erişimi ve log; tek bir vendor teknik risk modeli içinde yönetilmelidir: erişim talebi → minimum yetki → log/audit → periyodik review → offboarding. Bu model kurulduğunda vendor sayısı artsa bile kontrol kaybolmaz.
☑ Mini Check :
- •Vendor onboarding checklist’i var
- •Token rotasyon takvimi var
- •Panel MFA ve RBAC uygulanıyor
- •Offboarding (token revoke + hesap kapatma) prosedürü var
- •Yıllık vendor erişim haritası güncellemesi var (365 gün)
Ne yapmalıyım?
- • Vendor onboarding formunu standartlaştırın (veri + amaç + erişim yolu).
- • Token rotasyon ve erişim review takvimi belirleyin.
- • Vendor panel hesaplarını çeyreklik temizleyin.
- • Offboarding’i “proje kapanışı” değil “güvenlik adımı” yapın.
- • İç linklerle birlikte değerlendirin: https://dgtlface.com/tr/raporlama/kvkk-veri-guvenligi — https://dgtlface.com/tr/yazilim/sunucu-guvenlik — https://dgtlface.com/tr/yazilim/cms-entegrasyonu — https://dgtlface.com/tr/yazilim/kvkk-uyum-hizmeti
Teknik not: Vendor değerlendirmesi; sözleşme/SLA tarafı hukukla, teknik erişim ve entegrasyon tarafı BT ile birlikte ele alınmalıdır. Bu içerik /tr/raporlama/kvkk-veri-guvenligi ve /tr/yazilim/sunucu-guvenlik ile birlikte değerlendirilmelidir.
6. Vendor–Sistem–Veri Erişim Haritası & Due Diligence Checklist Şablonunu İndir — Yazılım / Vendor
Vendor–Sistem–Veri Erişim Haritası & Due Diligence Checklist Şablonunu İndir — Yazılım / Vendor (v1.0)
Bu asset, veri işleyen vendor’ların teknik erişimini görünür kılar: hangi vendor hangi sistem ve veri alanlarına hangi yolla (API/FTP/panel) erişiyor. Token ve panel erişimlerini minimum yetkiyle yönetmek, entegrasyon loglarını standardize etmek ve periyodik review/offboarding adımlarını süreçleştirmek için tek sayfalık bir checklist sunar. Otel ve B2B’de vendor riskini BT-satın alma-KVKK ortak zeminde yönetir.
Kim Kullanır?
BT/IT + satın alma + KVKK/uyum + sistem owner’ları.
Nasıl Kullanılır?
- Vendor–sistem–veri tablosunu doldur, erişim yolunu ve yetki seviyesini işaretle.
- Token/panel kontrollerini uygula (minimum yetki, MFA, IP kısıtı, rotasyon).
- Periyodik review ve offboarding adımlarını takvime bağla (365 gün güncelleme).
Ölçüm & Önceliklendirme (Kısa sürüm)
- ▢ ✅ Vendor envanteri çıkarıldı (CRM, chat, call center, bulut, raporlama)
- ▢ ✅ Vendor owner’ları atandı
- ▢ ✅ Vendor–sistem–veri türü eşleme tablosu tamam
- ▢ ✅ Erişim yolu işaretli (API/FTP/panel)
- ▢ ✅ Yetki seviyesi yazıldı (read/write/export)
- ▢ ✅ Token/key envanteri çıkarıldı
- ▢ ✅ Token minimum yetkili
- ▢ ✅ Token rotasyon takvimi var
- ▢ ✅ Secrets manager kullanılıyor
- ▢ ✅ Vendor panel RBAC aktif
- ▢ ✅ Vendor panel MFA zorunlu
- ▢ ✅ IP allowlist/VPN uygulanıyor (kritik paneller)
- ▢ ✅ Entegrasyon logları tutuluyor (kim/ne zaman/ne)
- ▢ ✅ Offboarding prosedürü var (token revoke + hesap kapatma)
- ▢ ✅ 365 gün güncelleme ve çeyreklik hesap temizliği planlı
PDF içinde: Problem→Kök Neden→Çözüm tablosu + 14 gün sprint planı + önce/sonra KPI tablosu
Deliverables
- •Vendor–sistem–veri erişim haritası
- •Token/key envanteri + rotasyon takvimi
- •Vendor panel erişim politikası (RBAC/MFA/IP)
- •Entegrasyon log standardı
- •Offboarding prosedürü + audit planı
Bir Sonraki Adım
Vendor’ların hangi veri ve sisteme eriştiğini haritalar; token/panel/log kontrolleriyle teknik riskleri yönetilebilir hale getirir.