KVKK ve kişisel veri: satılık web projesinde veri devri başlıkları

Veri devri neden “dosya göndermekten” fazlasıdır

Kişisel veri içeren bir web projesi satılırken devredilen şey yalnızca veritabanı dökümü olmayabilir; aynı zamanda işleme faaliyetleri, alt işleyen ilişkileri, saklama süreleri ve kullanıcıya yapılmış aydınlatmaların kapsamı da sahada değişir. Bu yüzden veri devri, teknik bir kopyala-yapıştır işlemi gibi ele alınmamalıdır. Satıcı ve alıcı, mümkünse ortak bir envanter çıkarmalı ve hangi kategorilerin hangi sistemlerde işlendiğini listelemelidir.

Hukuki sebep zinciri devralma sonrası yeniden değerlendirilir. Örneğin mevcut aydınlatma metni satıcı şirkete göre yazılmış olabilir; alıcı şirketin kimliği ve iş modeli farklıysa metin güncellenmesi gerekebilir. Bu güncelleme sadece “metin değişimi” değil; kullanıcı iletişimi ve süreç işidir.

Veri minimizasyonu ilkesi gereği, satış kapsamında gerçekten gerekli verilerin aktarımı planlanmalıdır. “Her şey gitsin” yaklaşımı hem risk hem gereksiz yük oluşturur.

Veri envanteri: kategori, amaç, süre ve alt işleyenler

Basit bir envanter tablosu şu sütunları içerebilir: veri kategorisi (kimlik, iletişim, lokasyon, ödeme ile ilgili olmayan işlem verileri vb.), işleme amacı, saklama süresi, alt işleyen ve aktarım yapılan ülke/bölge (varsa), güvenlik önlemleri özetleri. Bu tablo mükemmel olmak zorunda değildir; fakat başlangıç noktası sağlam olmalıdır. Boş tablo, devralma sonrası ilk denetimde panik üretir.

Üçüncü taraf SaaS araçları (CRM, destek, e-posta, analitik) ayrı satırlarda tutulmalıdır. Bir aracın hesabı satıcı üzerindeyse devredilebilirlik veya yeniden kurulum maliyeti konuşulmalıdır.

Çerez ve pazarlama etiketleri de kişisel veri işleme boyutu taşıyabilir; sadece “teknik konfigürasyon” sanılmamalıdır.

Aydınlatma, rıza ve “meşru menfaat” çerçevesinin yeniden okunması

Aydınlatma metni satıcının dünyasına göre yazılmış olabilir. Alıcı, yeni gerçeklikte hangi işleme faaliyetlerini sürdüreceğini tanımlamalı ve metni buna göre güncellemelidir. “Rıza” ile “meşru menfaat” gibi hukuki dayanaklar birbirine karıştırılmamalıdır; yanlış dayanak seçimi risk üretir. Bu konular uzman desteği ister; blog yazısı kişisel sonuç üretmez.

Pazarlama iletişimleri için ayrı onay geçmişleri düşünülmelidir. Liste devri, izin devri anlamına gelmeyebilir.

Çocuklara yönelik veya hassas kategoriler söz konusu ise ek hassasiyetler gündeme gelir.

Veri aktarımı ve sözleşme dili: KVKK + ticari gerçeklik

Satış sözleşmesinde veri devrine dair madde mümkün olduğunda somut olmalıdır: hangi kategoriler, hangi ortamda, hangi tarihte ve hangi güvenlik kontrolleri ile. “KVKK’ya uygun devredilir” cümlesi tek başına operasyonel değildir. Taraflar, devralma öncesi ve sonrası için iş birliği yükümlülüğü (bildirim, kullanıcı iletişimi, taleplere yanıt) paylaşımını yazmalıdır.

Alt işleyen sözleşmeleri yenilenmeli veya devredilebilirlik şartları kontrol edilmelidir. Bazı sağlayıcılar hesap devrini kısıtlar; bu durumda veri taşıma planı ve kayıt dışı bırakılmaması için teknik çözüm gerekir.

Veri ihlali olayı senaryosu için haberleşme hattı ve zaman çizelgesi tanımlanabilir. Tanımlanmazsa olay anında dağınık müdahale çıkar.

Silme, anonimleştirme ve “ gereksiz veriyi taşımama”

Satış öncesi dönemde silinmiş olması gereken ama hâlâ yedeklerde duran veriler risk oluşturur. Yedekleme politikaları ve saklama süreleri gözden geçirilmelidir. Alıcı, gereksiz veriyi devralmak istemeyebilir; bu durumda temizleme sprinti planlanmalıdır.

Anonimleştirme mümkünse istatistiksel kullanım için değerli olabilir; fakat anonimleştirme teknik olarak zorsa hukuki danışmanlık ve mühendislik birlikte çalışmalıdır.

Test ortamlarında gerçek kişisel veri bulunmamalıdır; satış demosu için maske üretilmelidir.

Çalışan verisi ve müşteri verisi ayrımı

Projede içerik üreticileri veya moderatörlerin kişisel verileri de sistemde olabilir. Bu verilerin devri ayrı değerlendirilmelidir. Çalışan verisi, iş sözleşmesi ve hukuki çerçeveye bağlıdır; müşteri verisi ise ticari işleme konusudur. İkisini aynı pakette tek tuşla devretmek hatalıdır.

Kullanıcı destek yazışmaları kişisel veri içerebilir; arşivlenmiş ticket’lar için saklama süresi ve erişim rolleri gözden geçirilmelidir.

Satıcı tarafında “elimizde ne var” bilgisini gizlemek, alıcıyı kötü sürprize düşürür; bu da satışın hukuki riskini büyütür.

Denetim ve kayıt: devralma sonrası 30-60-90 gün

Veri uyumu devralma ile bitmez; ilk 30-60-90 günde erişim kontrolleri, log süreleri ve veri silme taleplerine yanıt süreleri test edilir. Bu testler dokümante edilmezse “uyum var” sanılır; oysa pratikte kırılır. Küçük bir kontrol tablosu (hangi politika, hangi tarih, kim doğruladı) operasyonel uyumu görünür kılar.

Bulut loglarında eski satıcı erişimi varsa kapatma ve rotasyon planı uygulanmalıdır.

Veri işleme envanterinin güncellenmesi periyodik olmalıdır; proje yaşadıkça envanter de yaşar.

Satıcı için şeffaflık: “veri var” demenin doğru biçimi

Satıcı “veri var” deyip kapsamı söylemezse alıcı en kötümser varsayımı yapar. Kısa envanter özeti, güveni artırır ve fiyat savunmasına yardım eder çünkü alıcı uyumluk maliyetini modelleyebilir. Bu özet kişisel verileri ifşa etmeden kategori düzeyinde olabilir.

Satıcı, kullanıcıya yapılacak duyuru metni taslağı hakkında erken konuşursa süreç hızlanır; geç konuşulursa alıcı ilk haftada tıkanır.

Bilerek veya bilmeyerek tutulmuş fazla veri varsa temizleme planı satışın parçası olmalıdır.

Alıcı için kontrol soruları ve durdurma hakkı

Alıcı şu soruları sorabilmelidir: hangi alt işleyenler var, sözleşmeler devredilebilir mi, yedekler nerede ve ne kadar süreyle tutuluyor, silme talepleri nasıl işliyor, pazarlama izinleri nasıl yönetiliyor? Cevap yoksa risk primi artar. Şüphe büyükse işlemi durdurmak rasyonel olabilir.

Veri devri ticari heyecanla aceleye getirilmemelidir; acele çoğu zaman yanlış sınıflandırma üretir.

Son olarak, bu başlıklar hukuki kesinlik değildir; uzman yorumu şarttır.

Kapanış: uyum, satıştan sonra başlayan bir süreçtir

KVKK uyumu tek seferlik PDF değildir; yaşayan süreçtir. Satılık proje devrinde veri envanteri ve sorumluluk paylaşımı, satışın “görünmez bedelini” belirler. Bu bedel erken yazıldığında fiyat daha doğru konur; geç yazıldığında ise şaşkınlık ve dava riski büyür.

İyi haber: çoğu proje, kategori düzeyinde düzenli liste ve açık iletişimle güvenli şekilde devredilebilir. Kötü haber: liste yoksa alıcı model kuramaz ve güven kırılır.

Son cümle: veri devri, teknik aktarımdan önce hukuki ve operasyonel netliği gerektirir; bu netlik olmadan “siteyi aldık” demek mümkün olsa bile “uyumu aldık” demek zordur.

Ek derinleştirme: başvuru kanalları, şikâyet yönetimi ve veri talepleri

Kullanıcılar başvurularını e-posta, form veya destek paneli üzerinden yapıyorsa bu kanalların kişisel veri işleme akışları farklı olabilir. Satış sırasında “tek CRM var” demek yetmez; eski kayıtların hangi sistemde, hangi saklama süresiyle durduğu envantere yazılmalıdır. Devralma sonrası ilk haftalarda en çok sorulan konu “bu talep hangi sistemde” sorusudur; cevap yoksa operasyon kilitlenir.

Şikâyet ve disputes kayıtları, ürün güvenliği veya yasal süreçlerle ilişkili olabilir. Bu kayıtların devri mümkün mü, maskeleme gerekir mi soruları erken sorulmalıdır. Bazı kayıtlar satıcıya özgü kişisel sıfatla ilişkilidir; alıcıya aktarılamayabilir. Bu sınır yazılmazsa “tüm veritabanını aldık” sanılır; oysa kullanılabilir olmayan veri yük oluşturur.

Veri sahibi başvuruları (silme, düzeltme, bilgi talebi) için iş akışı tanımı yoksa devralma sonrası ilk büyük kriz buradan gelir. Basit bir akış çizelgesi bile alıcıyı rahatlatır: talep gelir, kim doğrular, hangi SLA ile yanıt verilir, hangi sistemde kayıt düşülür. SLA yoksa bile “şimdilik böyle yürütüyoruz” demek dürüstlüktür.

Pazarlama iletişimleri ve çerez onayları yeniden kurulurken kısa süreli trafik veya dönüşüm düşüşü yaşanabilir. Bu düşüş bazen uyumun maliyetidir; satıcı bunu önceden anlatırsa alıcı sürpriz yaşamaz. Satıcı anlatmazsa alıcı “site bozuldu” sanır ve destek talebi yağmuruna girer.

Son olarak, KVKK uzmanlığı gerektiren noktaları zorlamayın: bu metin bilgilendiricidir, yerine geçmez. Doğru soruları sormak, yanlış varsayımdan daha değerlidir. Veri devrinde en pahalı şey varsayımtır; en ucuz şey ise kategori düzeyinde liste ve net sorumluluk paylaşımıdır.

Ek olarak, çerez duvarı ve etiket yöneticisi ayarları devralma sonrası sık sil baştan yaşar. Eski etiketler yanlış çalışır, ölçüm iki kez sayılır veya hiç sayılmaz. Bu teknik borç, kişisel veri işleme kayıtlarıyla da çakışabilir. Bu yüzden devrin ilk 30 günü için “ölçüm ve uyum” mini takvimi yazmak faydalıdır.

Veri sınıflandırması yapılırken “kişisel olmayan” zannedilen bazı alanlar aslında birleştirildiğinde kimliği tanımlayabilir. Bu risk, envanterde kümülatif etki olarak not düşülmelidir. Not düşülmezse alıcı sonradan veri minimizasyonu sprintine girer.

Üçüncü taraf kütüphaneler ve gömülü widget’lar, kullanıcı verisini dışarı taşıyabilir. Bu bileşenler sözleşmeye “teknik detay” gibi girer; oysa uyum açısından hayatidir. Liste: analitik, canlı destek, harita, yorum pluginleri, reklam ağları. Her biri için kısa “veri akışı yönü” cümlesi eklemek bile büyük belirsizliği kırar.

Veri devrinde “tam yedek alındı” cümlesi, kişisel verilerin hukuki dayanağı açısından tek başına anlam taşımayabilir. Doğru soru: bu yedek hangi amaçla üretildi, hangi süreyle saklanacak, kim erişecek? Bu soruların cevabı olmadan devralan taraf karanlık kutu almış olur.

Son ek: çalışan ve içerik üreticisi kişisel verileri ile son kullanıcı verilerini aynı pakette düşünmeyin. Çakışan roller, silme taleplerinde ve iletişimde iç içe geçer. Rol ayrımı, hem etik hem operasyonel olarak hayat kurtarır.

Son ek: devralma sonrası ilk 72 saatte uyum ve operasyon

İlk 72 saatte yapılacak işler küçük görünür; oysa burada oluşan kötü alışkanlık aylarca sürer. Önerilen üst seviye sıra: erişim rollerini gözden geçir, eski paylaşımlı tokenları kapat, çerez ve etiket yöneticisini doğrula, destek kanallarında “kim yanıtlıyor?” sorusunu netleştir, kullanıcıya gidecek birincil duyuru taslağını planla. Bu sıra projeye göre değişir; fakat yazılı sıra olmadan ilk gün kaosa döner.

Veri envanterini güncellemek için “tek doğru tablo” yaklaşımı faydalıdır: dağınık Excel yerine, kısa bir Markdown dosyası bile olsa tek kaynak belirleyin. Kaynak çoğalırsa uyum çabuk çürür.

İlk haftanın en görünmez riski, satıcının eski entegrasyonlarının sessizce çalışmaya devam etmesidir. Bu sessizlik bazen güvenlik riski, bazen ölçüm hatası, bazen de faturalandırma sürprizi doğurur. Bu yüzden integrasyon listesinde her satır için “aktif/pasif” ve “yenileme tarihi” notu düşün.

KVKK açısından her şeyi ilk gün mükemmelleştirmek şart değildir; fakat hangi başlıkların bilinçli olarak ertelendiğini yazmak şarttır. Erteleme listesi, yönetişim belgesidir; ihmalkârlık değildir.

Son hatırlatma: uyum bir “PDF teslim” değildir; yaşayan iş akışıdır. İş akışı yazılmadan koşulursa ekip içi iletişimde kişisel veri sızıntıları ve yanlış paylaşımlar artar. Bu meta risk, çoğu zaman teknik riskten daha pahalıya döner.

Ek cümle: envanter tek sayfada mükemmel olmak zorunda değildir; fakat “bilinmeyenleri” açıkça yazmak zorundadır. Bilinmeyenler listesi, uyum borcunu şeffaf borç hâline getirir ve sonradan şoka düşmezsiniz.

Uzman seçimi sırasında alıcı ve satıcı aynı gün farklı KVKK yorumunu duyunca panik doğal olarak çıkar; çünkü her iki taraf da tek doğru fotoğraf bekler halde konuşur. Oysa çerçeve devir sırasında hafif kayabilir; bu yüzden erken tarih sıralı uyum çıktılarını birlikte saklamak, ileride ne zaman ne bildirilmişti sorusuna yanıt üretir ve gereksiz gerginliği küçültür.

Kapanış eki olarak: veri işleme faaliyeti geçici olarak iki tarafta paralel yürüdüğünde “aynı olayın iki kaydı” tutulmazsa silme, erişim ve aktarım talepleri hangi sorumluya ait kaldı belirsizleşir. Bu yüzden devralma haftası için kısa bir olay günlüğü (tarih, kim, hangi kayıt, hangi amaç) faydalıdır; mükemmel olmak zorunda değildir, tutarlı olması yeterlidir.

Alıcı ve satıcı aynı anda farklı “geçiş stratejileri” duyunca yaşanan panik çoğu kez teknik kusurdan çok iletişim borcundan çıkar; bu yüzden devrin ilk haftasına tarih damgalı mini özet çıktıları (hangi sistem taşındı, hangisi beklemede, kimin sorumluluğunda) not düşmek uyum adımlarının sırasını tartışılır olmaktan çıkarır ve bekleyen işler listesinin sürekli güncellenmesini kolaylaştırır.