KVKK uyumlu CDP mimarisi: Sekiz katmanlı bir karar dökümü

Şirketiniz İstanbul’dan Frankfurt’a satıyorsa ve “iki ayrı sistem mi kuralım yoksa tek bir CDP mi” sorusu masada duruyorsa bu yazı tam size yönelik. KVKK ile GDPR’yi aynı yığında karşılamak teorik olarak basit, pratikte değil. İki yönetmelik aynı tarafa bakıyor — kullanıcının kendi verisi üzerinde söz hakkı — ama uygulama detayları (saklama bölgesi, açık rıza biçimi, silme süresi, denetim kayıtları) yer yer çatışıyor. “İki ayrı sistem kuralım” cevabı kâğıtta iyi durur, üretimde işlemez.

Son 14 ayda dört müşteriyle KVKK + GDPR uyumlu Customer Data Platform (CDP) inşa ettik. Sektörler farklıydı (fintech, B2B SaaS, eğitim teknolojisi, lojistik) ama altta yatan mimari kararlar şaşırtıcı şekilde tekrarlıyordu. Bu yazıda sekiz katmanlı bir karar dökümü paylaşıyoruz: hangi katmanın hangi mevzuat maddesine cevap verdiği, hangi araçların hangi koşulda işe yaradığı, hangi ödünleşmelerin gerçekten ödün olduğu. Amaç bir “KVKK uyumluluk şablonu” değil; ekibinizin ilk sözleşmeyi imzalamadan önce hangi kararların hangi sıraya alındığını görmesi. Üretim ortamına geçtikten sonra geri dönüşü olmayan kararlar var; bunları başta görmek hem maliyet hem itibar tarafında ciddi kazanç sağlıyor.

Karar 1: Veri toplama ve açık rıza katmanı

Hiçbir CDP, “user_id” oluşturmadan önce açık rıza katmanını çözmeden başlamıyor. KVKK Madde 5 ve GDPR Article 6 her ikisi de işlemenin hukuki dayanağını ister; “açık rıza” en sağlam dayanak — ama “açık” kelimesinin operasyonel anlamı detaylarda saklı. Sayfaya tek bir “Kabul ediyorum” düğmesi koymak ne KVKK’yı ne GDPR’yi geçer.

Pratik kurulum üç parçadan oluşuyor. Birincisi: cookie banner ayrıştırılmış granülarlikle çalışmalı — pazarlama izni, analiz izni, kişiselleştirme izni ayrı ayrı seçilebilir olmalı. OneTrust, Cookiebot veya Iubenda kurumsal seçenekler; daha küçük ekipler için Klaro açık kaynak alternatifi. Banner’ın “Tümünü reddet” butonu “Tümünü kabul et” ile aynı görünürlükte olmalı; aksi halde GDPR’nin “freely given consent” tanımı düşer. İkincisi: e-posta abonelikleri için double opt-in zorunlu — kullanıcı ilk kez abone olduğunda doğrulama bağlantısı gönderilir, tıklamadan ad listesine eklenmez. Resend, Postmark, Mailgun kutudan double opt-in destekler. Üçüncüsü: rıza kaydı denetlenebilir olmalı — hangi kullanıcı, hangi izni, hangi versiyondaki metin altında, hangi IP’den, hangi zaman damgasıyla verdi? Bu kayıt 5 yıl saklanmalı; KVKK denetiminde “kanıtlayamadığınız izin yoktur” prensibi uygulanır.

Tipik hata: rıza katmanını CDP’ye gömmek. Segment’in consent management modülü iyi ama düzenleyici tarafa karşı tek başına savunma değil. Rıza ayrı bir append-only log’da tutulmalı; CDP yalnızca tüketici. Üç müşterimizde bu log Cloudflare D1 veya Postgres üzerinde duruyor, CDP’den bağımsız.

Karar 2: Saklama ve veri yerelleştirme

Saklama bölgesi KVKK ile GDPR’nin en sert çatıştığı nokta. KVKK Madde 9 yurt dışına aktarımı “yeterli koruma” şartına bağlar; GDPR Article 44 AB dışına aktarımı SCC veya adequacy decision’a bağlar. Pratikte bu, “veriyi nerede tutuyorsun” sorusuna ikna edici bir cevap istiyor.

Default kurulumumuz şöyle: birincil veri AB içinde tutulur, Türkiye’deki kullanıcılar için ek bir Türkiye replikası gerekiyorsa (özellikle finans veya sağlık sektörlerinde) hibrit bölgeli kurulum yapılır. Pratik araç seçimleri: PostHog yerine eu.posthog.com (Frankfurt), Resend yerine region: 'eu-west-1' parametreli kurulum, S3 yerine Cloudflare R2 ile EU jurisdiction işaretlemesi, vector store için Qdrant Cloud EU veya Pinecone’un AB bölgesi. Cloudflare Workers’ın global edge yapısı KVKK için bir tartışma noktası; çözüm Workers’ı sadece edge cache olarak kullanıp veri saklamayı R2’ya bırakmak.

Türkiye replikası gerekiyorsa ek yük büyük: ya Türkiye’de bir cloud sağlayıcı (Türk Telekom Cloud, A101 Cloud) kullanılır ya da Almanya’daki ana veriden Türk kullanıcılar için bir alt küme replike edilir. İkinci seçenek operasyonel olarak daha sade; replikasyon CDC (Change Data Capture) ile yapılır, gecikme 2-5 dakika.

Önemli not: “veri yerelleştirme” sadece veritabanı değil. Logging, monitoring, error tracking de düşünmeli. Sentry’nin EU instance’ı var (sentry.io yerine de.sentry.io); Datadog’un EU site’ı var. Ekip Slack üzerinden production data örnekleri paylaşıyorsa bu da bir aktarım — Slack Enterprise Grid’in EU data residency add-on’u şart.

Karar 3: PII pseudonymization

Kişisel veriyi sistemden tamamen çıkarmak nadiren mümkün; ama “ne kadar az yerde dolaşırsa o kadar iyi” prensibi her uyumluluk denetiminde para kazandırıyor. Pseudonymization burada anahtar: PII’yi hash + salt ile dönüştürerek analitik ve aktivasyon katmanlarında düz metin yerine bu deterministik vekiller kullanılır.

Pratik kurulum: email, phone, tckn, ip gibi alanlar CDP’ye yazılırken HMAC-SHA256 + sabit salt ile hash’lenir. Salt’ı ayrı bir KMS’te tutmak (AWS KMS, GCP KMS, Cloudflare R2 + restricted token) önemli; hash’in tersine çevrilebilmesi salt’ın sızdırılmasıyla mümkün. Identity resolution gerekiyorsa hash’lenen değer üzerinden eşleşme çalışır; downstream sistemler (Customer.io, HubSpot) hash’lenmiş tanımlayıcıyı görür, düz e-postayı değil.

Vector embedding’lerde PII bulundurmama disiplini ayrıca önemli. AI özelliği için kullanıcı içeriğini embedding’e dönüştürürken metin içindeki ad-soyad, telefon, e-posta otomatik bir Microsoft Presidio veya benzeri bir PII detector ile temizlenir. Embedding’den geri PII çıkarmak imkansıza yakın ama veri tabanına düz haliyle giren her bilgi sonradan ihlal kapsamına girer. AI ürün geliştirme disiplini yazımızda tartıştığımız “günlük model değerlendirmesi” alışkanlığı burada da geçerli — PII filtrelemesinin kaçırdığı örnekler manuel inceleme ile yakalanır.

CRM tarafına gönderilen aktivasyon tetikleyicileri için tipik mimari: CDP’de hash’lenmiş kullanıcı, MAP’te düz e-posta. İki sistemi köprülemek için MAP tarafında bir “lookup table” tutulur; hash → e-posta eşleşmesi yalnızca son aktivasyon anında çözülür, log’lara yazılmaz.

Karar 4: Veri silme talep akışları

KVKK Madde 11 ve GDPR Article 17 (right to erasure) ikisi de silme hakkı tanır. KVKK 30 gün, GDPR “without undue delay” ve genelde 30 gün altı bekler. Pratikte 30 günlük SLA’nın içinde kalmak operasyonel olarak yeterli; daha kısa hedef koymak (15 gün) denetim avantajı yaratır.

Silme akışının zorluğu “veri her yere kopyalanmıştır” gerçeğinden kaynaklanır. Bir kullanıcı verisi tipik olarak şu yerlerde: ana CDP, warehouse, MAP (Customer.io/HubSpot), CRM, support tool (Zendesk/Intercom), analytics (PostHog/Mixpanel), backup’lar, cold storage, vector store, log dosyaları. Manuel silme bu 10-12 noktada koordineli yapılmadığında gizli kopya kalır.

Pratik çözüm: silme talebi tek bir “deletion orchestrator” üzerinden geçer. Müşteri bir form veya [email protected] gibi resmi bir kanaldan talep gönderir, ticket sisteme düşer, otomasyon her downstream sistem için silme işlemini sırayla yürütür ve her birinde bir API çağrısı + receipt log’u tutar. n8n veya Temporal bu orchestrator için doğru araç; her downstream’in farklı API’si var, retry mantığı şart. Sürecin sonunda kullanıcıya “şu sistemlerden silindi, şu kayıtlar mevzuat gereği saklı kalır (örn. fatura kayıtları VUK gereği 10 yıl)” raporu gönderilir. Bu rapor başlı başına bir denetim aracı.

Backup’lar ayrı bir tartışma. “Backup’tan sileyim” demek kullanışsız çünkü backup zaten bir geri dönüş aracı. Çözüm: backup’lar belirli bir rotation süresine sahip (örn. 35 gün), o süre içinde silme tamamlanmamışsa “expired backup” otomatik silinir; bu sayede silinmiş kullanıcı backup’tan geri gelmez. Bu mantığı kurmak ekstra çalışma; ama denetim sırasında “backup’ım var, restore edersem o veri geri gelir” dendiğinde mevzuat tarafı kötü tepki veriyor.

Karar 5: Veri taşıma ve export API

GDPR Article 20 (right to data portability) ve KVKK Madde 11 verinin makine-okunabilir formatta taşınmasını zorunlu kılar. Pratik anlamı: kullanıcı kendi verisini JSON, CSV veya benzeri bir formatta indirebilmeli, ve gerekirse başka bir sistemde içeri alabilmeli.

Kurduğumuz tipik export endpoint: kullanıcı portal üzerinden talep yapar, arka tarafta bir job kullanıcının tüm sistemlerdeki verisini toplar (CDP profil, event’ler, support ticket’ları, abonelik tarihçesi), JSON-LD formatında bir paket oluşturur, signed URL ile 7 gün geçerli bir indirme bağlantısı e-posta ile gönderilir. JSON-LD’nin avantajı schema.org tipleriyle uyumluluğu; kullanıcının başka bir sisteme aktarması daha kolay. Format CSV de olabilir ama nested ilişkileri (event’lerin attribute’ları) düz CSV’de temsil etmek kayıplı.

Export job’ının kendisi de PII içerdiği için kısa süreli, ifrazlı saklama ile koşulmalı: signed URL’in arkasındaki dosya 14 gün sonra otomatik silinir. Bu detay denetimde sıklıkla soruluyor.

Karar 6: Audit log ve breach notification

KVKK Madde 12 ve GDPR Article 33 her ikisi de veri ihlalinin 72 saat içinde Veri Sorumlusuna Başvuru (KVKK için VERBİS) ve etkilenen kullanıcılara bildirimini ister. Bunu becerebilmek için iki ön koşul lazım: ihlali tespit edebilmek ve etkilenen kullanıcı listesini hızlıca çıkarabilmek.

Audit log altyapısı her veri erişimini, değişikliğini ve dışa aktarımını yapısal olarak kaydeder. Tipik şema: timestamp, user_id, action, resource, ip, user_agent, result. Log append-only, en az 5 yıl saklanır, write erişimi sadece sistem servislerinde, read erişimi denetim ve güvenlik ekibinde. Bu log’un kendisi de KVKK kapsamında işleme — yani audit log’a yazılan PII de hash’lenmeli.

İhlal tespit tarafında: SIEM (Wazuh, Elastic Security, Datadog Security) anormal erişim örüntülerini yakalar; bir kullanıcı bir saatte 10.000 kayıt okuduysa alarm tetiklenir. Tespit-bildirim arası 72 saat hedefini tutmak için runbook hazır olmalı: kim KVKK Kuruluna form gönderir, kim kullanıcılara e-posta yazar, kim hukuk ekibiyle koordine olur. Runbook’u tatbikat ile test etmek (yılda 1-2 kez) denetim sırasında çok değerli — “biz bunu hiç yaşamadık” cevabı kötü, “yılda iki kez tatbikat yapıyoruz, sonuçlar şurada” iyi.

Karar 7: Pratik mimari diyagram

Sekiz katmanı somut bir mimaride birleştiren tipik akış: kullanıcı tarayıcısı → Cloudflare edge (consent check) → Hono ya da Astro server endpoint (PII pseudonymization) → CDP (Segment veya kendi RudderStack instance’ı) → Warehouse (BigQuery EU veya Snowflake EU) → reverse-ETL (Hightouch/Census) → MAP (Customer.io EU) ve Analytics (eu.posthog.com). Audit log her katmanda paralel olarak append-only bir Postgres’e yazılır. Silme orchestrator (n8n) tüm bu zinciri tersinden gezer.

Bu mimariyi hangi koşullarda hangi araçlarla daha çok kullandığımızı MarTech yığını mimarisi yazımızda ayrıntılı tartıştık. Tek farkla: KVKK + GDPR koşulu varsa “warehouse-first” yaklaşımı varsayılan oluyor, çünkü warehouse veri yerelleştirmesini en sade şekilde çözüyor.

Karar 8: Mevzuat yorumlamasının kuralı

Mevzuat metinleri sıklıkla yoruma açık. “Açık rıza” nedir, “yeterli koruma” hangi seviyedir, “uygun teknik tedbirler” hangi araçları içerir? Bu sorulara kesin cevap vermek hukuk ekibinin işi; mühendislik ekibinin işi savunulabilir bir karar üretmek. “Savunulabilir” tanımı: bir denetimde “neden bu kararı aldınız” sorusuna belgeyle dayalı cevap vermek.

Pratik disiplin: her mimari kararın yanına bir DPIA (Data Protection Impact Assessment) notu konur. Hangi mevzuat maddesi için hangi kontrol seçildi, alternatif neydi, neden bu seçim yapıldı? Bu notlar 12 ay sonra denetim geldiğinde “biz bu kararı şu gerekçeyle aldık” demenin tek yolu. Notion, Confluence veya basit bir markdown repo yeterli; format değil disiplin önemli.

Kapanış

KVKK + GDPR uyumlu bir CDP “olağan” bir CDP’den belirgin şekilde daha karmaşık değil; sadece sekiz katmanın her birinde bilinçli bir karar ister. İlk kurulumda verilen kararların büyük kısmı geri dönüşü pahalı kararlar — saklama bölgesini değiştirmek, audit log şemasını yeniden yazmak, silme orchestrator’ı sonradan eklemek hem maliyetli hem operasyonel risk. İlk haftada 8 katmanı masaya yatırmak, 12. ayda denetim geldiğinde gözle görülür bir fark yaratıyor.

Mevcut yığınınızda bu kararların hangileri açık, hangileri “sonra düşünürüz” listesinde duruyor? Bir bağlam tarama görüşmesi için bize MarTech ve AI Operasyonları sayfamızdan ulaşabilir veya iletişim sayfası üzerinden [email protected]’a yazabilirsiniz.