Veri Sorumlusu – Veri İşleyen Ayrımında Yapılan Kritik Hatalar (Güncel Örnekler ile)
KVKK ve GDPR uygulamalarında en sık yapılan uyum hatalarından biri,
veri sorumlusu (data controller) ile veri işleyen (data processor) rollerinin yanlış belirlenmesidir.
2024–2025 döneminde hem Avrupa veri otoriteleri hem de KVKK Kurulu, özellikle karma hizmet modellerinde ve SaaS altyapılarında rol karışıklığını ciddi bir risk alanı olarak tanımladı.
Bu hatalar sadece uyumsuzluk yaratmıyor;
yanlış sıfat belirlemesi nedeniyle yapılan veri işleme faaliyetinin tamamen hukuksuz hale gelmesine bile yol açabiliyor.
1. Veri Sorumlusu – Veri İşleyen Ayrımının Kritik Önemi
Bir şirketin hangi veri işlemede hangi rolü üstlendiğini doğru belirlemek, aşağıdaki yükümlülükleri doğrudan etkiler:
- Aydınlatma yükümlülüğü
- Rıza + işleme şartlarının belirlenmesi
- İhlal bildirimi sorumluluğu
- İşlenen verinin güvenliği
- Silme / anonimleştirme politikaları
- Denetim – sözleşme – ek yükümlülükler
Bu nedenle bir şirket “biz processor’ız” dediğinde ama fiilen controller gibi davranıyorsa,
sunulan tüm hizmet hukuken riskli hale gelir.
2. 2024–2025 Döneminde En Sık Görülen 7 Kritik Hata
Hata 1: “Sözleşmede processor yazıyorsa sorun yok” yaklaşımı
Birçok şirket, sözleşmeye “veri işleyen” yazmanın yeterli olduğunu düşünüyor.
Oysa otoriteler defalarca şu ilkeyi vurguladı:
Unvanlar sözleşmeyle değil; verinin kim için, ne amaçla ve nasıl işlendiğiyle belirlenir.
Örnek:
Bir SaaS CRM sağlayıcısı, müşteri davranış analizi yapıyor, arayüzde kullanıcı rotası çıkarıyor, veri tutma süresine kendi karar veriyor.
Bu durumda processor değil controller sayılıyor.
Hata 2: “Ortak veri sorumluluğu”nun fark edilmemesi
Birçok hizmet modeli artık klasik controller–processor ilişkisine uymuyor.
Örneğin:
- Pazaryeri – satıcı ilişkisi
- Bankalar – fintech underwriting API’leri
- Sigorta şirketi – hasar eksper yazılımı
- E-ticaret platformu – reklam hedefleme ağları
Bu ilişkilerin büyük kısmı joint controller (ortak veri sorumlusu) niteliği taşıyor.
Ancak Türkiye’de çoğu işletme bunu processor olarak yorumladığı için ciddi ihlal riski oluşuyor.
Hata 3: Tedarik zincirinde rollerin zincirleme yanlış atanması
Tedarikçiler çoğu kez yanlış etiketlendiği için zincir kopuyor.
Örnek zincir:
Marka → Ajans → Reklam teknolojisi sağlayıcısı → Bulut altyapısı → Analitik aracı
Burada:
Ajans: çoğu zaman controller/controller ilişkisi
Reklam platformu: ortak sorumlu
Bulut hizmet: processor
Analitik çözüm: çoğunlukla controller (çünkü amaç ve aracı belirliyor)
Türkiye’de ise hepsine aynı model uygulanıyor: “Ajans bizim processor’ımızdır.”
Bu yaklaşım 2025’te Kurul’un sık denetlediği alanlardan biri haline geldi.
Hata 4: Processor’ın amaç belirlemesi (en kritik hata)
Bir veri işleyen aşağıdaki faaliyetlerden birini yapıyorsa artık controller’dır:
- Veri tutma süresine tek başına karar veriyorsa
- Yeni analiz türlerine karar veriyorsa
- Verileri kendi ürününü geliştirmek için kullanıyorsa
- Hangi verilerin toplanacağına tek başına karar veriyorsa
- Veriyi üçüncü taraflarla paylaşma yetkisi varsa
Bu durum Türkiye’de özellikle:
CRM sağlayıcılarında
E-ticaret pazaryeri entegrasyonlarında
Chatbot/AI SaaS çözümlerinde
Reklam analitiği araçlarında
çok sık görülüyor.
Hata 5: Sözleşmelerde teknik–organizasyonel tedbirlerin belirsiz bırakılması
Birçok DPA ve Kurul denetiminde en çok eleştirilen konu:
Data processing agreement (DPA) içinde “genel ifadeler” kullanılması.
Örnek hatalı maddeler:
“Gerekli tüm güvenlik önlemleri alınacaktır.”
“Kişisel veriler gerektiği kadar saklanacaktır.”
“İlgili mevzuata uygun şekilde silme yapılır.”
Bu maddeler artık kabul edilmiyor.
Denetimlerde “somutlaştırılmış yükümlülük” aranıyor.
Hata 6: Sub-processor kullanımının bildirilmemesi
2025 yılındaki Kurul denetimlerinde öne çıkan bulgu:
Alt işleyicilerin (sub-processor) gizli kullanımı.
Özellikle:
E-posta hizmetleri (Sendgrid, Mailgun)
Bulut server sağlayıcılar
Log/monitoring araçları
Çerez ve analitik çözümleri
Bu yüzden hizmet alan veri sorumlusu gerçek riskleri göremiyor.
Hata 7: Kimin ihlal bildirimi yapacağı konusunda belirsizlik
Birçok şirket hala şu sorunun cevabını bilmiyor:
İhlal bildirimi kimin sorumluluğunda?
Cevap role göre değişir:
Controller → Kurul + ilgili kişi bildirimi
Processor → derhal controller’a bildirme
Sözleşmelerde ihlal bildirim SLA’ları eksik olduğu için birçok şirket 72 saatlik süreyi kaçırıyor.
3. Güncel, Gerçekçi Örnekler (2024–2025)
Aşağıdaki örnekler otoritelerin 2024–2025 bulgularından türetilmiş risk senaryolarıdır.
Örnek 1: “Biz sadece CRM sunuyoruz” diyen SaaS platformu
Durum:
Müşteri davranış analizi yapıyor.
Müşterilere segment oluşturuyor.
“Product improvement” için tüm verileri işliyor.
Sonuç: Controller
Hatalı belirleme: Processor yazılmış → sözleşme geçersiz → hukuksuz işleme.
Örnek 2: E-ticaret platformu – satıcı ilişkisi
Platform:
Teslimat süreçlerini yönetiyor.
Dolandırıcılık analizleri yapıyor.
Ödeme akışını kontrol ediyor.
Sonuç:
Platform ve satıcı çoğu zaman joint controller.
Türkiye’de ise %90 processor sözleşmesi yapılıyor → ağır uyumsuzluk.
Örnek 3: Dijital pazarlama ajansı
Ajans:
Kampanya hedeflemesini belirliyor.
İçerik ve hedef kitle stratejisini tek başına tanımlıyor.
Bu ajans controller kabul edilir.
Ancak sözleşmelerde “processor” yazıldığı için tüm kampanya verisi hukuksuz işlenmiş oluyor.
Örnek 4: Fintech kimlik doğrulama API’si
API hizmeti:
Sahtecilik tespit modelleri geliştiriyor.
Kendi veri setini genişletiyor.
Bu durumda controller.
Türkiye’de birçok fintech bu modeli “işleyen” gibi gösteriyor → risk yüksek.
4. Tedarikçi Sözleşmelerinde En Yaygın 8 Eksik
1. Roller açık belirtilmemiş
Controller/processor/joint controller ayrımı yazılmamış veya yanlış.
2. Alt işleyicilerin listesi yok
Sub-processor ekleri sözleşmeye konmamış.
3. Silme/anonimleştirme prosedürleri yok
Ne zaman, hangi yöntemle, kim sorumlu → belirsiz.
4. Denetim hakkı eksik
Processor’ın denetlenmesine ilişkin prosedürler tanımlanmamış.
5. SLA’lar bulunmuyor
Özellikle ihlal bildirimi için “derhal” ibaresi kullanılıyor → yetersiz.
6. Veri güvenliği teknik önlemleri soyut
Şifreleme, erişim kontrolü, log yönetimi gibi maddeler “gerektiğinde” bırakılıyor.
7. Coğrafi aktarım hükümleri net değil
Bulut sağlayıcının veri merkezleri belirtilmemiş.
8. İşleme amacı belirsiz
“Geliştirme için kullanılabilir” gibi geniş ifadeler uyumsuzluk doğuruyor.
5. 2026’ya Girerken Şirketler Ne Yapmalı?
Aşağıdaki adımlar otoritelerin 2025 yönlendirmeleri doğrultusunda hazırlanmıştır:
- Her veri işleme faaliyeti için rol analizi (RACI) çıkarılmalı.
- Tedarikçi haritası çıkarılmalı (martech, fintech, SaaS, bulut).
- Controller–processor sıfatları yeniden sınıflandırılmalı.
- Sözleşmeler rol uyumuna göre revize edilmeli.
- Processor olan taraflar için zorunlu DPA ekleri hazırlanmalı.
- Sub-processor listesinin şeffaf yönetimi sağlanmalı.
- İhlal bildirimi SLA’ları ve iletişim zinciri netleştirilmeli.
