Çoğu kişi KVKK'yı bir metin işi sanır. Siteye bir aydınlatma sayfası koyarsın, alt kısma bir onay kutusu eklersin, iş bitmiştir diye düşünürsün. Oysa bir e-pin satış scripti kurduğun anda sen sadece ürün satmaya başlamıyorsun; her siparişte ad, e-posta, telefon, IP, ödeme referansı ve çoğu zaman oyun kullanıcı adı toplayan bir veri işleme makinesini çalıştırmaya başlıyorsun. O makinenin nasıl kurulduğu, hangi metni yazdığından çok daha belirleyici.
İşin ilginç tarafı şu: denetim ya da şikâyet anında kimse senin aydınlatma metnindeki cümlelerin güzelliğine bakmıyor. Bakılan şey, o metinde söylediklerinin veritabanında gerçekten karşılığı olup olmadığı. "Verileri gerektiği süre kadar saklıyoruz" yazıp 2019'dan beri hiçbir kaydı silmemiş bir panel, hiç metin koymamış panelden daha kötü durumda — çünkü artık beyan var, uygulama yok. Bu yazıda bir e-pin yazılımını ilk günden bu çelişkiye düşmeyecek şekilde nasıl kuracağını, hangi tablo hangi süreyle yaşar, hangi log tutulur hangisi tutulmaz seviyesinde anlatıyorum.
Panellerin çoğu KVKK'ya uyumlu değil, sadece sessiz
Piyasadaki hazır dijital ürün satış scripti paketlerinin ezici bölümü veri koruma tarafında hiçbir şey yapmaz — ama bunu sana söylemez de. Kurulumu bitirir, panel açılır, satış alırsın. Arka planda ne olur? Sipariş tablosuna müşterinin adı ve telefonu düşer. Ziyaret loglarına IP'si yazılır. Destek modülüne ekran görüntüleri yüklenir. Başarısız ödeme denemeleri ayrı bir tabloda birikir. Hiçbiri silinmez, hiçbirine erişim kısıtı konmaz, hiçbirinin neden toplandığı kayıtlı değildir. Sessizlik uyum değildir; sadece sorunun henüz sana ulaşmamış olmasıdır.
Doğru yaklaşım, uyumu bir sayfa değil bir mimari kararı olarak görmek. Yani panel kurulurken şu soruyu sormak: bu alan olmasa satışı yapabilir miyim? Yapabiliyorsan o alanı hiç toplama. Veri minimizasyonu en pahalı danışmanlıktan daha etkilidir, çünkü toplamadığın veriyi korumak, silmek, açıklamak veya sızdırmak zorunda kalmazsın. Pinova gibi bir yönetim yazılımında bu, sipariş formundaki zorunlu alanları tek tek gözden geçirmek kadar basit bir işle başlar.
E-pin satışında hangi veriyi gerçekten işliyorsun?
Envanter çıkarmadan uyum konuşulmaz. Bir e-pin satış yazılımında veri dört kümede toplanır: kimlik ve iletişim (ad, e-posta, telefon), işlem (sipariş, tutar, ödeme referansı, fatura bilgisi), teknik (IP, oturum, cihaz, tarayıcı parmak izi) ve teslimat kimliği — oyun kullanıcı adı, karakter adı, hesap ID'si. Bu son küme e-pin sektörüne özgüdür ve çoğu şablon envanterde hiç geçmez. Oysa bir oyun hesabı kimliği, bir kişiyi doğrudan işaret ettiği ölçüde kişisel veridir.
Kümelerin her biri farklı hukuki dayanağa ve farklı ömre sahiptir. İşlem verisi sözleşmenin kurulması ve yasal saklama yükümlülüğü ile ayakta durur; kolayca silemezsin. Teknik veri meşru menfaat (dolandırıcılık önleme) ile kısa süre tutulur. Pazarlama verisi yalnızca açık rıza ile yaşar ve rıza çekilince gider. Bu ayrımı yapmadan "hepsini 10 yıl tutuyorum" demek, pazarlama listesini de ticari defter muamelesi yapmak demektir — savunulamaz.
| Veri kümesi | Tipik tablo | Hukuki dayanak | Önerilen ömür | Silme biçimi |
|---|---|---|---|---|
| Kimlik & iletişim | users, orders | Sözleşme | İlişki + yasal süre | Anonimleştirme |
| Fatura & işlem | invoices, payments | Hukuki yükümlülük | Mevzuattaki süre | Süre sonunda arşiv+silme |
| Teslimat kimliği | order_meta | Sözleşme | 90–180 gün | Maskeleme |
| Erişim / IP logu | access_log | Meşru menfaat | 30–90 gün | Otomatik rotasyon |
| Destek yazışması | tickets, attachments | Sözleşme | 12 ay | Ek dosyalar önce gider |
| Bülten / SMS | subscribers | Açık rıza | Rıza sürdükçe | Talepte anında silme |
| Çerez & analitik | consent_log | Rıza (zorunlu hariç) | Rıza ömrü + ispat | Kayıt korunur, kimlik kopar |
Aydınlatma metni bir sayfa değil, bir zamanlama sorunudur
Aydınlatma yükümlülüğünün püf noktası içerik değil andır: veriyi elde ettiğin sırada bilgilendirmek zorundasın. Yani menüde bir "KVKK" linki bulunması yetmez; sipariş formunun yanında, üyelik adımında, destek talebi açılırken ve bülten kutusunun altında, o bağlamda hangi verinin neden alındığını söyleyen kısa bir bilgi katmanı olması gerekir. Uzun metin ayrı bir sayfada durur, bağlam metni formun yanında durur.
İkinci püf nokta: rıza ile sözleşmeyi karıştırmamak. "Siparişi tamamlamak için kişisel verilerimin işlenmesine izin veriyorum" cümlesi hatalıdır, çünkü satışı yapmak için zaten rızaya ihtiyacın yok — sözleşme dayanağın var. Rıza kutusu sadece pazarlama, profilleme ve isteğe bağlı çerezler için ayrı ve önceden işaretli olmayan biçimde durmalı. İyi kurulmuş bir panelde bu iki şey aynı checkbox'ı paylaşmaz.
E-pin panellerinde KVKK uyumsuzluğunun kaynağı
- Saklama süresi ve silme yok 45%
- Rıza ile sözleşme karışmış 25%
- Panel erişim yetkisi sınırsız 20%
- Başvuru kanalı tanımsız 10%
Saklama süresi olmayan veritabanı, gecikmiş bir risktir
Her tabloya bir ömür yazmadıkça uyum diye bir şey yoktur. Pratikte bunu üç katmanda kurarsın. Birincisi kayıt: hangi tablo ne kadar yaşayacak, bir dosyada yazılı olsun. İkincisi otomasyon: zamanlanmış bir görev, süresi geçen satırları silsin veya kimlik alanlarını geri döndürülemez şekilde kırpsın. Üçüncüsü kanıt: silme işinin çalıştığını gösteren bir özet log tutulsun — kaç satır, hangi tablo, hangi tarih. Kişisel veri içermeyen bu özet, ihtilafta en çok işe yarayan şeydir.
Silme derken çoğu zaman kastedilen şey anonimleştirmedir. Muhasebe tarafında satış kaydını tutman gerekir ama o kayıtta müşterinin telefonu durmak zorunda değil. Sipariş satırını koru, kimlik alanlarını kopar. Böylece hem ticari kaydın bütünlüğü bozulmaz hem de gereksiz kişisel veri taşımazsın. Bir epin yazılım altyapısında bu, kullanıcı silindiğinde siparişi "silinmiş kullanıcı" referansına bağlayan basit bir yabancı anahtar tasarımıyla çözülür.
Kullanıcıyı panelden sildin ama gece yedeğinde duruyor. Yedek rotasyonuna da bir ömür yaz: silme politikası yedeği kapsamıyorsa politika yoktur. 30–60 günlük döngü, hem kurtarma hem uyum açısından makul bir dengedir.
Veri sahibi başvurusu geldiğinde sayaç işlemeye başlar
Bir müşteri "hakkımdaki tüm verileri istiyorum" yazdığında kronometre başlar ve yanıt süresi gün cinsindendir. O anda panelinde tek tuşla şunu yapamıyorsan sorun var: bu e-postaya ait tüm satırları topla, okunabilir bir çıktıya dönüştür, ver. Manuel SQL yazarak her başvuruyu karşılamak ilk üçte çalışır, sonra çatlar.
Pratik kurulum şu: paneldeki kullanıcı kartına "veri çıktısı" ve "silme talebi" düğmeleri ekle. Silme düğmesi doğrudan silmesin — kuyruğa alsın, yasal saklama gerektiren kayıtları işaretlesin, kalanını anonimleştirsin ve sonucu bir özet olarak yazsın. Başvuru kanalını da tek bir yere sabitle: KEP, noter, ıslak imzalı dilekçe veya sistemde kayıtlı e-posta. Kanalı yazmazsan her Instagram mesajı resmî başvuru sayılabilir.
Kurulumda doğru sıralama nedir?
Uyumu sonradan eklemek, ev bittikten sonra tesisat çekmeye benzer. Doğru sıra şudur: önce veri envanteri, sonra form alanlarının kısaltılması, sonra saklama tablosu, sonra otomasyon, en son metinler. Metinleri en sona bırakmak mantıksız görünür ama doğrudur — çünkü metin, sistemin ne yaptığını anlatan şeydir. Sistem belli olmadan metin yazarsan kaçınılmaz olarak yalan yazarsın.
Bu sıralamayı bir kontrol listesine dökmek işi somutlaştırır. Aşağıdaki tablo, yeni bir e-pin scripti ayağa kaldırırken ilk haftada kapatılması gereken kalemleri, sorumluyu ve kanıtı birlikte gösteriyor. Hukuki metinlerin son halini mutlaka bir hukukçuya doğrulat; buradaki liste teknik kurulum disiplinidir, hukuki mütalaa değildir.
| # | Yapılacak | Nerede | Kanıt | Durum |
|---|---|---|---|---|
| 1 | Veri envanteri tablosu çıkar | Veritabanı şeması | Envanter dosyası | Zorunlu |
| 2 | Gereksiz form alanlarını kaldır | Sipariş / üyelik formu | Ekran kaydı | Zorunlu |
| 3 | Rıza kutularını sözleşmeden ayır | Ödeme adımı | Form HTML'i | Zorunlu |
| 4 | Saklama sürelerini yaz | Politika dosyası | Süre tablosu | Zorunlu |
| 5 | Otomatik silme görevi kur | Zamanlanmış görev | Çalışma logu | Zorunlu |
| 6 | Panel rollerini daralt | Yetki modülü | Rol matrisi | Zorunlu |
| 7 | Başvuru kanalını ilan et | İletişim sayfası | Yayınlı metin | Zorunlu |
| 8 | Yedek ömrünü sınırla | Sunucu / hosting | Rotasyon ayarı | Önerilen |
| 9 | İhlal müdahale adımlarını yaz | İç doküman | Tek sayfa plan | Önerilen |
| 10 | Yıllık gözden geçirme koy | Takvim | Toplantı notu | Önerilen |
Uyumu sonradan yamamak zorunda kalmayan bir altyapı
Pinova, rol bazlı panel yetkisi, veri çıktısı, kayıt ömrü ve onay kaydı gibi kalemleri kurulumun parçası olarak ele alan bir dijital ürün satış yazılımıdır. Modülleri ve fiyatlandırmayı incele.
Küçük bir e-pin sitesi için de KVKK gerekli mi?
Ciro veya müşteri sayısı eşiği yoktur; kişisel veri işliyorsan kapsamdasın. Küçük olmak yükümlülüğü kaldırmaz, sadece uygulamayı basitleştirir: daha az tablo, daha az rol, daha kısa politika.
VERBİS'e kayıt olmam şart mı?
Kayıt yükümlülüğü, çalışan sayısı ve mali büyüklük gibi kriterlere ve istisna kararlarına bağlıdır. Eşikleri kendi tablonla karşılaştırıp bir hukukçuyla teyit et; teknik tarafta envanterin hazır olması her iki durumda da işini kolaylaştırır.
Müşteri tüm verilerinin silinmesini isterse siparişi de silmem gerekir mi?
Hayır. Yasal saklama yükümlülüğü olan işlem ve fatura kaydı korunur; korunması gerekmeyen kimlik ve iletişim alanları anonimleştirilir. Bunu müşteriye yanıtında açıkça yazmak gerekir.
Yurt dışı ödeme veya bulut sağlayıcı kullanmak sorun mu?
Sorun değil ama aktarımın bir dayanağı ve şeffaf bir açıklaması olmalı. Hangi sağlayıcıya hangi verinin gittiğini envanterinde ayrı bir satır olarak tut; aydınlatma metninde de kategori olarak belirt.
Uyum, panelinin yavaşlaması ya da satışının düşmesi anlamına gelmez; aksine iyi kurulmuş bir veri disiplini destek yükünü de, sıkıntılı iadeleri de azaltır. Hangi modülün hangi kaydı tuttuğunu, yetki matrisinin nasıl çalıştığını ve çıktı araçlarını kendi gözünle görmek istersen canlı demo üzerinden dolaşabilir, özellik listesini ve fiyat seçeneklerini karşılaştırabilirsin.