Tecof • 28 Eylül 2026
KVKK Uyumu: E-ticaret Sitesi İçin Kontrol Listesi
Kısaca
KVKK uyumu, bir e-ticaret sitesinin müşteri, ziyaretçi ve çalışan verilerini hangi hukuki sebebe dayanarak, ne kadar süreyle ve kimlerle paylaşarak işlediğini yazılı hale getirmesi ve bunu sistem tarafında da gerçekten uygulamasıdır. E-ticarette zor olan kısım metin yazmak değildir; sipariş akışı doğası gereği ad, adres, telefon, ödeme ve sipariş geçmişi toplar ve bu veriler kargo firmasına, ödeme kuruluşuna, muhasebe yazılımına, e-posta aracına ve reklam platformlarına dağılır. Uyumsuzluk çoğunlukla kötü niyetten değil, bu dağılımın haritasını kimsenin çıkarmamış olmasından doğar. 2026 itibarıyla soru "aydınlatma metnimiz var mı" değil, "topladığımız her veri alanının bir hukuki sebebi, bir saklama süresi ve bir sorumlusu var mı" sorusudur.
Perşembe öğleden sonra 15.10. Dokuz yıldır satış yapan bir ev tekstili mağazasının panelinde 61.400 kayıtlı müşteri görünüyor. Üyelik formu ad, soyad, e-posta, telefon, doğum tarihi ve cinsiyet istiyor; son iki alanın ne için toplandığını ekipten kimse bilmiyor, çünkü bu alanlar siteyle birlikte 2017'de gelmiş. Bülten listesinde 38.000 kayıt var, bunların 12.000'inin hangi tarihte ve hangi ekrandan izin verdiği kayıtlı değil. Site kaynağında on dört farklı üçüncü taraf etiketi çalışıyor; dördünü kimin, ne zaman eklediği bilinmiyor.
Buradaki asıl sorun eksik bir belge değil, envanterin hiç çıkarılmamış olmasıdır. Aydınlatma metni sitede duruyor ama metin sekiz veri alanından bahsederken form on iki alan topluyor; çerez banner'ı "kabul et" diyor ama reddetme seçeneği yok ve etiketler banner'dan önce çalışıyor. Bu üç uyumsuzluğun hiçbiri hukuki metin yazarak çözülmez; formun, banner'ın ve etiket yöneticisinin gerçekte ne yaptığını değiştirerek çözülür. KVKK uyumunu bir yazı işi değil bir sistem işi yapan şey budur.
1. KVKK E-ticarette Tam Olarak Neyi Kapsar?
KVKK, kimliği belirli veya belirlenebilir bir gerçek kişiye ilişkin her türlü bilginin işlenmesini düzenler; e-ticarette bu, sipariş veren müşteriden siteyi ziyaret eden anonim görünümlü kullanıcıya kadar geniş bir alanı kapsar. Aşağıdaki kavramlar, listenin geri kalanının dayandığı temeldir.
Kişisel veri, e-ticarette hangi alanlara karşılık gelir?
E-ticarette kişisel veri, sadece ad ve adres değildir; kullanıcıyı tekil olarak işaret edebilen her kayıt bu kapsama girer.
- Kimlik ve iletişim verisi: ad, soyad, e-posta, telefon, teslimat ve fatura adresi.
- İşlem verisi: sipariş geçmişi, sepet içeriği, iade kayıtları, fatura numarası.
- İşlem güvenliği verisi: IP adresi, oturum kayıtları, giriş logları, cihaz bilgisi.
- Pazarlama verisi: çerez tanımlayıcıları, reklam kimlikleri, açılan e-posta ve tıklama kayıtları.
- Müşteri hizmetleri verisi: çağrı kayıtları, canlı destek yazışmaları, şikâyet dosyaları.
IP adresi ve çerez kimliği de kişisel veridir; "isim yoksa kişisel veri değildir" yaklaşımı e-ticarette en sık yapılan kavram hatasıdır, çünkü bu tanımlayıcılar sipariş kaydıyla eşleştiği anda kişiyi doğrudan işaret eder.
Veri sorumlusu kimdir, veri işleyen kimdir?
Mağazayı işleten şirket veri sorumlusudur; altyapı, kargo, e-posta aracı gibi onun talimatıyla veri işleyen taraflar ise veri işleyendir. Bu ayrım pratik bir sonuç doğurur: sorumluluğu hizmet sağlayıcıya devredemezsiniz. Kargo firmasında yaşanan bir sızıntı müşteri gözünde ve hukuken sizi de ilgilendirir; bu yüzden veri işleyenlerle yazılı sözleşme ve bu sözleşmede güvenlik taahhütleri gerekir.
Açık rıza her zaman gerekli mi?
Hayır; açık rıza, kişisel veri işlemenin tek hukuki sebebi değil, sebeplerden yalnızca biridir. Siparişin hazırlanması ve teslim edilmesi için gereken ad, adres ve telefon bilgisi sözleşmenin ifası kapsamında işlenir; fatura ve mali kayıtlar hukuki yükümlülük kapsamındadır. Açık rıza asıl olarak pazarlama iletişimi, profilleme ve zorunlu olmayan çerezler gibi, hizmetin yürütülmesi için şart olmayan işlemlerde devreye girer. Her şeyi rızaya bağlamak riskli bir kolaycılıktır: müşteri rızasını geri çektiğinde siparişi teslim edemez duruma düşersiniz.
Özel nitelikli veriden uzak durun
Sağlık, biyometri, din, üyelik gibi özel nitelikli verilerin işlenmesi çok daha ağır koşullara bağlıdır ve tipik bir e-ticaret operasyonunun bunlara ihtiyacı yoktur. Buna rağmen istemeden toplandığı iki yer vardır: serbest metin alanları (müşterinin sipariş notuna sağlık durumunu yazması) ve iade gerekçesi formları. Bu alanları zorunlu tutmayın, serbest metin yerine seçenek listesi kullanın ve müşteri hizmetleri ekibine bu tür bilgileri kayda geçirmeme talimatı verin.
2. Veri Envanteri: Neyi, Nerede, Ne Kadar Süre Tutuyorsunuz?
Envanter, KVKK uyumunun ilk adımıdır çünkü diğer bütün belgeler ondan türetilir: aydınlatma metni de, saklama ve imha politikası da envanterin yazıya dökülmüş hâlidir. Envanteri çıkarmadan yazılan metin, sitenin gerçekte yaptığı işi anlatmaz.
Envanter nasıl çıkarılır?
Veri kategorisinden değil, ekrandan başlayın. Üyelik formu, misafir sipariş ekranı, bülten kutusu, iletişim formu, yorum alanı, iade talebi ekranı ve çağrı merkezi kaydı; her biri için hangi alanların toplandığını tek tek yazın. Ardından her alan için dört soruyu cevaplayın: neden topluyoruz, hangi hukuki sebebe dayanıyor, nerede duruyor, ne zaman siliniyor. "Neden" sorusuna cevap bulunamayan alan, formdan çıkarılacak alandır. Doğum tarihi yalnızca yaş sınırlı ürün satıyorsanız gereklidir; cinsiyet alanı segmentasyon için isteniyorsa isteğe bağlı yapılmalıdır.
Saklama süresi nasıl belirlenir?
Saklama süresi keyfi değildir; verinin dayandığı hukuki sebep ne kadar sürerse veri o kadar saklanır. Mali kayıtlar için vergi mevzuatının öngördüğü süre, sözleşme kaynaklı kayıtlar için zamanaşımı süresi, pazarlama izni için iznin geri çekilmediği süre belirleyicidir. Sürelerin güncel halini kendi mali müşaviriniz ve hukuk danışmanınızla birlikte tabloya dökün; tek bir "hepsi 10 yıl" kuralı hem gereksiz risk biriktirir hem de imha yükümlülüğüne aykırıdır.
İmha gerçekten çalışıyor mu?
Kâğıt üzerinde imha politikası olup uygulamada hiçbir şeyin silinmemesi, sahada gördüğümüz en yaygın durumdur. İmhanın çalışması için üç şey gerekir: periyodik imha işinin bir takvime bağlanması, silmenin yalnızca ana veritabanında değil yedeklerde, veri ambarında, e-posta aracında ve destek sisteminde de karşılığının olması, ve her imha turunun tutanakla kayıt altına alınması. Yedekten geri dönüldüğünde silinmiş kayıtların geri gelmesi, imha sürecinin en sessiz açığıdır.
| Veri kategorisi | Tipik kaynak | Tipik hukuki sebep | Süreyi belirleyen |
|---|---|---|---|
| Ad, adres, telefon | Sipariş formu | Sözleşmenin ifası | Sözleşme zamanaşımı |
| Fatura ve ödeme kaydı | Muhasebe entegrasyonu | Hukuki yükümlülük | Mali mevzuat süresi |
| Üyelik hesabı | Kayıt ekranı | Sözleşme / meşru menfaat | Hesap aktifliği |
| Bülten aboneliği | Bülten kutusu | Açık rıza + İYS onayı | İznin geri çekilmesi |
| Pazarlama çerezi | Etiket yöneticisi | Açık rıza | Çerez ömrü / rıza |
| Site güvenlik logu | Sunucu | Meşru menfaat | Güvenlik ihtiyacı |
3. Aydınlatma ve Açık Rıza: İkisi Aynı Şey Değil
Aydınlatma bir bilgilendirme yükümlülüğüdür ve her durumda yerine getirilmesi gerekir; açık rıza ise belirli işlemler için alınan ayrı bir onaydır. Bu ikisini tek kutuda birleştirmek, en sık karşılaşılan ve düzeltmesi en kolay hatadır.
Aydınlatma metni neyi içermeli?
Aydınlatma metni, veri sorumlusunun kimliğini, hangi verilerin hangi amaçlarla işlendiğini, kimlere ve hangi amaçla aktarıldığını, toplama yöntemini ve hukuki sebebini, ilgili kişinin haklarını anlaşılır bir dille anlatmalıdır. İki pratik kural: metin, formun gerçekte topladığı alanlarla birebir örtüşmeli ve veri toplanan her noktada erişilebilir olmalıdır. Yalnızca site altındaki bir bağlantı yeterli sayılmaz; üyelik ekranında, sipariş ekranında ve iletişim formunda ayrı ayrı görünür olmalıdır.
Açık rıza kutusu nasıl kurulur?
Açık rıza özgür iradeyle, belirli bir konuya ilişkin ve bilgilendirmeye dayalı olmalıdır; bu üç şart kutu tasarımına doğrudan yansır.
- Önceden işaretli olmamalı: kullanıcı kutuyu kendisi işaretlemelidir.
- Hizmete şart koşulmamalı: "bülten iznini kabul etmeden sipariş veremezsiniz" kurgusu rızayı geçersiz kılar.
- Ayrıştırılmalı: aydınlatmayı okudum onayı, ticari ileti izni ve üyelik sözleşmesi ayrı kutular olmalıdır.
- Kanıtlanabilmeli: iznin tarihi, saati, IP'si, gösterilen metnin sürümü ve hangi ekrandan verildiği kayıt altına alınmalıdır.
Son madde uygulamada en çok ihmal edilenidir. İzin kaydı tutulmayan bir bülten listesi, denetim anında izinsiz liste ile aynı konumdadır.
Çerezler ve izin yönetimi
Sitenin çalışması için zorunlu çerezlerde aydınlatma yeterliyken, analitik ve pazarlama çerezleri için açık rıza aranır. Bunun teknik sonucu nettir: reklam ve analitik etiketleri, kullanıcı onay verene kadar çalışmamalıdır. Çoğu sitede banner vardır ama etiketler banner'dan bağımsız olarak sayfa açılışında tetiklenir; bu durumda banner yalnızca görsel bir dekordur. Reddetme seçeneği, kabul seçeneğiyle aynı görünürlükte olmalı ve verilen izin sonradan değiştirilebilmelidir.
Ticari ileti izni ayrı bir dünyadır
SMS, e-posta ve arama yoluyla yapılan ticari iletişim, KVKK'nın yanında ayrı bir mevzuata ve İleti Yönetim Sistemi'ne tabidir; KVKK'ya uygun bir açık rıza almış olmak, tek başına ticari ileti gönderme hakkı vermez. Bu tarafın nasıl kurulduğunu İYS yazımızda ayrıntılı anlattık; kanal seçiminin maliyet ve dönüşüm tarafını ise e-posta ve SMS karşılaştırmasında ele almıştık.
| Konu | Aydınlatma | Açık rıza | İYS onayı |
|---|---|---|---|
| Ne zaman gerekir | Her veri işlemede | Rızaya dayalı işlemede | Ticari iletide |
| Onay kutusu | Gerekmez | Gerekir | Gerekir |
| Geri alınabilir mi | — | Evet | Evet |
| Kanıt kaydı | Metin sürümü | Tarih, IP, sürüm | Sistem kaydı |
| Eksikliğin sonucu | Yükümlülük ihlali | İşleme dayanaksız kalır | İleti gönderilemez |
4. Üçüncü Taraflar ve Yurt Dışına Aktarım
E-ticarette verinin çoğu, toplandığı yerde kalmaz; sipariş oluştuğu anda en az beş farklı sisteme dağılır. Uyumun en zor bölümü, bu dağılımın kontrol altında olduğunu gösterebilmektir.
Tipik aktarım haritası
Bir siparişin arkasında genellikle şu aktarımlar vardır: ödeme kuruluşuna kart ve tutar bilgisi, kargo firmasına ad, adres ve telefon, muhasebe yazılımına fatura bilgileri, e-posta aracına iletişim bilgisi, analitik ve reklam platformlarına davranış verisi, pazaryeri satışı varsa pazaryerine sipariş bilgisi. Her aktarım için üç şeyi bilmeniz gerekir: hangi alanlar gidiyor, hangi amaçla gidiyor, karşı tarafla yazılı bir sözleşme var mı. Kart verisinin sizin sisteminizde hiç durmaması, ödeme tarafında hedeflenmesi gereken yapıdır.
Aktarımı fazlasıyla yapmamak
En sık rastlanan aşırılık, entegrasyonların "kolay olsun" diye tüm müşteri kaydını karşı tarafa göndermesidir. Kargo firmasının sipariş geçmişine, e-posta aracının fatura adresine ihtiyacı yoktur. Entegrasyonu kurarken alan eşlemesini daraltmak, sonradan yazılacak her belgeden daha etkilidir. Alan bazlı eşlemenin nasıl kontrol edileceğini API ve entegrasyon yazımızda teknik tarafıyla anlatmıştık.
Yurt dışına aktarım
Bulut barındırma, e-posta gönderim araçları, analitik ve reklam platformlarının önemli bölümü verileri yurt dışında işler; bu aktarımların ayrı bir hukuki dayanağa ihtiyacı vardır. Mevzuat bu alanda yakın dönemde değişti ve uygulama ayrıntıları gelişmeye devam ediyor; bu nedenle kullandığınız her yurt dışı hizmet için hangi mekanizmaya dayandığınızı ve gerekli bildirimlerin yapılıp yapılmadığını hukuk danışmanınızla birlikte güncel mevzuata göre doğrulayın. Pratik tavsiye şudur: hangi hizmetin verinizi nerede işlediğini listeleyin, bu listeyi sözleşmelerle eşleştirin ve yeni bir araç eklendiğinde listeyi güncellemeyi satın alma sürecinin parçası yapın.
| Taraf | Aktarılan tipik veri | Gereken kontrol | Sık yapılan hata |
|---|---|---|---|
| Ödeme kuruluşu | Tutar, sipariş, kart işlemi | Kart verisinin sizde durmaması | Kart bilgisini loglamak |
| Kargo firması | Ad, adres, telefon | Alan eşlemesinin daraltılması | Tüm profili göndermek |
| E-posta aracı | E-posta, ad, izin kaydı | İzinsiz kaydın senkronlanmaması | Tüm listeyi aktarmak |
| Reklam platformu | Çerez kimliği, olay verisi | Rıza öncesi tetiklenmemesi | Banner'dan bağımsız etiket |
| Muhasebe / ERP | Fatura, tutar, kimlik | Erişim yetkisinin sınırlanması | Herkese tam yetki |
5. Teknik ve İdari Tedbirler
KVKK, veri güvenliği için uygun teknik ve idari tedbirlerin alınmasını ister; bu, e-ticarette büyük ölçüde erişim yetkisi, şifreleme, kayıt tutma ve personel disiplinine indirgenir. Belgeler denetimde sorulur, ama sızıntıyı önleyen şey bu dört başlıktır.
Erişim yetkisi ve rol yönetimi
Panelde kimin neyi görebildiğini yazılı bir yetki matrisine bağlayın. Depo ekibinin sipariş adresine ihtiyacı vardır, müşterinin e-posta geçmişine yoktur; pazarlama ekibinin segment listesine ihtiyacı vardır, tekil fatura kaydına yoktur. Ayrılan çalışanın hesabının aynı gün kapatılması, ajans ve serbest çalışanlara verilen erişimlerin süreli olması ve yönetici hesaplarında iki adımlı doğrulama, üç temel kuraldır. Toplu veri dışa aktarma yetkisini yalnızca iki kişide tutmak, çoğu kazayı baştan keser.
Şifreleme, yedek ve aktarım güvenliği
Site baştan sona HTTPS üzerinden sunulmalı, parolalar geri döndürülemez biçimde saklanmalı, yedekler şifreli tutulmalı ve yedeklerin nerede durduğu envantere yazılmalıdır. Sertifikanın hem güvenlik hem görünürlük tarafındaki rolünü SSL yazımızda ayrıntılandırmıştık. Veri dışa aktarımlarının şifresiz e-posta ekiyle yapılması, pratikte en sık görülen ve en kolay kapatılan açıktır.
Log ve izlenebilirlik
Kimin hangi kayda ne zaman eriştiği tutulmadığında, bir ihlal yaşandığında kapsamı belirlemek mümkün olmaz. Yönetici girişleri, toplu dışa aktarma işlemleri, yetki değişiklikleri ve müşteri kaydı görüntülemeleri kayıt altına alınmalı; bu kayıtlar da kendi saklama süresine tabi tutulmalıdır. Log tutmak, ihlal bildirimi yükümlülüğünü yerine getirebilmenin önkoşuludur.
Personel ve süreç disiplini
İdari tedbirlerin görünmeyen kısmı insandır. Müşteri hizmetleri ekibinin ekran görüntüsüyle veri paylaşmaması, kişisel e-posta hesaplarına liste indirilmemesi, sipariş notlarına sağlık ve benzeri bilgilerin yazılmaması, yeni işe başlayanlara gizlilik taahhüdü imzalatılması ve yılda en az bir kez kısa bir farkındalık eğitimi verilmesi; bunların hiçbiri maliyetli değildir ve denetimde de sorulur.
6. VERBİS, İlgili Kişi Başvuruları ve İhlal Süreçleri
Bu bölüm, uyumun dışa dönük yüzüdür: kayıt yükümlülüğü, müşteriden gelen talepler ve kötü gün senaryosu. Üçü de önceden kurulmadığında baskı altında yönetilmek zorunda kalır.
VERBİS kaydı gerekli mi?
Veri Sorumluları Sicil Bilgi Sistemi'ne kayıt, belirli eşiklerin üzerindeki veri sorumluları için zorunludur; çalışan sayısı ve mali bilanço eşiğinin altında kalan ve ana faaliyeti özel nitelikli veri işlemek olmayan işletmeler için istisna öngörülmüştür. Eşikler ve istisnaların güncel hali değişebildiği için, kayıt yükümlülüğünüzün bulunup bulunmadığını Kurum'un güncel duyuruları üzerinden ve mali müşavirinizle birlikte doğrulayın. Kayıt gerekiyorsa, bildirilen envanterin gerçekte işlediğiniz verilerle örtüşmesi gerekir; VERBİS beyanı ile aydınlatma metni arasındaki çelişki, denetimde ilk fark edilen şeydir.
İlgili kişi başvurusu geldiğinde ne olacak?
Müşteri; verisine erişme, düzeltme, silme, aktarıldığı tarafları öğrenme ve işlemeye itiraz etme haklarına sahiptir ve bu talepleri önce size yöneltir. Başvurunun ulaşabileceği bir kanal (ayrı bir e-posta adresi ve form) tanımlayın, gelen talebi kaydedin, kimlik doğrulamasını yapın ve mevzuatın öngördüğü süre içinde yanıt verin. Süre ve biçim şartlarının güncel halini hukuk danışmanınızla teyit edin. Pratikte kritik olan nokta şudur: silme talebi geldiğinde silmenin ana veritabanıyla sınırlı kalmaması, e-posta aracı, destek sistemi, veri ambarı ve yedekler için de bir yordamın bulunması.
Veri ihlali yaşanırsa
İhlal bildirimi, öğrenildiği andan itibaren kısa ve sınırlı bir süre içinde Kurul'a, ayrıca etkilenen kişilere yapılır; bu yüzden süreç ihlal gününde tasarlanamaz. Önceden hazırlanması gerekenler: kimin karar vereceği, hangi logların inceleneceği, hangi metnin müşteriye gönderileceği ve hizmet sağlayıcılarla iletişimin nasıl kurulacağı. Bir sayfalık bir müdahale planı, bu senaryoda yazılabilecek en değerli belgedir. Yükümlülüğün güncel süre ve kapsamını hukuk danışmanınızla doğrulayın.
Belgeler: olması gerekenlerin kısa listesi
- Kişisel veri işleme envanteri: diğer tüm belgelerin kaynağı.
- Aydınlatma metni: web sitesi, üyelik, sipariş ve çağrı merkezi sürümleriyle.
- Saklama ve imha politikası: veri kategorisi bazında süre tablosuyla.
- Çerez politikası: çalışan çerezlerin listesi ve kategorileriyle.
- Veri işleyen sözleşmeleri: altyapı, kargo, e-posta ve ajans tarafı için.
- İhlal müdahale planı: rol, süre ve iletişim adımlarıyla.
30 Günde Uyum Seviyesini Yükseltmek
Otuz günde tam uyum iddiası gerçekçi değildir, ama en büyük açıklar bu sürede kapatılabilir. Sıra önemlidir: envanter çıkarılmadan yazılan metin, bir ay sonra yeniden yazılır.
1-7. gün: envanter ve gerçeğin tespiti
Veri toplanan tüm ekranları listeleyin, her formun topladığı alanları tek tek yazın, sitede çalışan üçüncü taraf etiketlerini sayın ve hangi sistemlerin hangi veriyi tuttuğunu çıkarın. Bu hafta hiçbir metin yazılmaz; yalnızca mevcut durum kayda geçer. Çıkacak listenin beklenenden uzun olması normaldir.
8-14. gün: fazlalıkları kesmek
Gerekçesi bulunamayan form alanlarını kaldırın veya isteğe bağlı yapın, entegrasyonlardaki alan eşlemelerini daraltın, kullanılmayan üçüncü taraf etiketlerini silin, panel yetkilerini rol bazında yeniden kurun ve ayrılmış çalışan hesaplarını kapatın. Bu haftanın çıktısı daha az veri ve daha az erişimdir.
15-21. gün: rıza ve bilgilendirme akışları
Aydınlatma metnini envanterle birebir eşleştirin, onay kutularını ayrıştırın ve önceden işaretli kutuları kaldırın, izin kayıtlarını tarih ve sürüm bilgisiyle tutmaya başlayın, çerez banner'ını gerçekten etiketleri durduracak biçimde bağlayın ve ticari ileti izinlerini İYS tarafıyla uyumlu hale getirin.
22-30. gün: süreç, sözleşme ve tatbikat
Saklama süresi tablosunu tamamlayın ve ilk periyodik imha turunu çalıştırın, veri işleyen sözleşmelerinin eksiklerini çıkarın, ilgili kişi başvuru kanalını açın, ihlal müdahale planını bir sayfada yazın ve bir silme talebini baştan sona deneyerek sürecin gerçekten çalıştığını görün. Entegrasyon tarafındaki veri akışlarını sadeleştirmek için entegrasyon seçeneklerine bakabilirsiniz.
Yarın sabah yapabileceğiniz iş şu: üyelik ve sipariş formunuzu açın, topladığınız her alanın karşısına tek cümlelik bir gerekçe yazın ve gerekçe bulamadığınız alanları o gün formdan kaldırın; toplamadığınız veri, korumak, saklamak ve silmek zorunda olmadığınız veridir. İzin kaydı, saklama süresi ve rol bazlı yetki gibi kontrollerin şablon düzeyinde hazır geldiği bir e-ticaret altyapısında bu listenin önemli bölümü baştan işaretli başlar. Bu yazı genel bir çerçevedir; yükümlülüğünüzün güncel halini kendi hukuk danışmanınız ve mali müşavirinizle doğrulayın.
Sıkça Sorulan Sorular
Küçük bir e-ticaret sitesi de KVKK kapsamında mı?
Evet; kapsam, işletmenin büyüklüğüne göre değil kişisel veri işlenip işlenmediğine göre belirlenir ve sipariş alan her site kişisel veri işler. Büyüklüğe bağlı olan şey kapsam değil, VERBİS kaydı gibi bazı ek yükümlülüklerdir. Tek kişilik bir mağaza da aydınlatma, güvenlik ve saklama yükümlülüklerini taşır.
Aydınlatma metnini internetten kopyalayabilir miyim?
Kopyalanan metin, sitenizin gerçekte topladığı alanları ve aktardığı tarafları anlatmadığı için pratikte işe yaramaz ve bir uyumsuzluk kaydı yaratır. Metin envanterden türetilmelidir. Hazır bir şablonu iskelet olarak kullanabilirsiniz, ancak veri alanları, amaçlar, aktarım tarafları ve saklama süreleri sizin operasyonunuza göre yazılmalıdır.
Çerez banner'ı koymak yeterli mi?
Yeterli değildir; banner'ın işlevsel olması, yani kullanıcı onay verene kadar analitik ve pazarlama etiketlerinin çalışmaması gerekir. Reddetme seçeneği kabul seçeneğiyle aynı görünürlükte olmalı, verilen izin sonradan değiştirilebilmeli ve hangi çerezlerin hangi amaçla çalıştığı listelenmelidir.
Müşteri "verilerimi silin" derse siparişleri de silmeli miyim?
Hayır; silme hakkı mutlak değildir ve saklanması hukuki yükümlülüğe dayanan kayıtlar için işlemez. Fatura ve mali kayıtlar mevzuatın öngördüğü süre boyunca saklanır. Bu durumda yapılması gereken, pazarlama verisi ve hesap bilgisi gibi dayanağı kalkan verileri silmek ve müşteriye hangi kayıtların neden saklandığını açıklamaktır.
Pazaryerinde satıyorum, müşteri verisi kimin sorumluluğunda?
Pazaryeri kendi platformu için veri sorumlusudur, ancak size aktarılan sipariş verisini siz işlediğiniz ölçüde o veri bakımından siz de veri sorumlusu konumundasınız. Pazaryerinden aldığınız iletişim bilgisini kendi pazarlama listenize eklemek, ayrı bir izin gerektirir ve platform kurallarına da tabidir.
Google Analytics veya reklam pikselleri kullanmak sorun mu?
Kullanımın kendisi değil, izinsiz ve bilgilendirmesiz kullanımı sorundur. Bu araçlar zorunlu olmayan çerez kategorisindedir; kullanıcı onay vermeden tetiklenmemeli, aydınlatma metninde ve çerez politikasında yer almalı ve verinin nerede işlendiği aktarım envanterinize yazılmalıdır.
Personelimin kişisel verileri de bu kapsamda mı?
Evet; çalışan özlük dosyaları, bordro kayıtları, işe alım başvuruları ve kamera kayıtları da kişisel veridir ve kendi envanter satırlarını, saklama sürelerini ve aydınlatma metinlerini gerektirir. E-ticaret şirketlerinde en sık atlanan bölüm budur, çünkü dikkat müşteri tarafında yoğunlaşır.
Bülten listemde izin kaydı olmayan kişiler var, ne yapmalıyım?
İzni kanıtlanamayan kayıtlar için güvenli yol, yeniden izin almak ya da bu kayıtları listeden çıkarmaktır. Yeniden izin kampanyası yapacaksanız, gönderim için de geçerli bir dayanağa ihtiyacınız olduğunu göz önünde bulundurun; bu noktada kanal ve yöntem seçimini hukuk danışmanınızla birlikte değerlendirin. Kısa vadede liste küçülür, orta vadede hem risk hem teslim edilebilirlik iyileşir.
Verilerimi yurt dışındaki bir bulut sağlayıcıda tutabilir miyim?
Yurt dışına aktarım mümkündür, ancak mevzuatın öngördüğü mekanizmalardan birine dayanması ve gerekli bildirim ve belgelerin tamamlanması gerekir. Bu alandaki kurallar yakın dönemde değiştiği için, kullandığınız her yurt dışı hizmet için dayanağınızı hukuk danışmanınızla güncel mevzuat üzerinden doğrulayın ve hizmet listesini envanterinizde güncel tutun.
Uyum çalışmasını ne sıklıkla tekrarlamalıyım?
Envanteri ve aktarım listesini altı ayda bir, yetki matrisini ve erişim listesini üç ayda bir gözden geçirin; imha turlarını politikanızda belirlediğiniz periyotta çalıştırın. Bunların dışında her yeni araç, yeni entegrasyon, yeni form alanı ve altyapı değişikliğinden sonra envanteri güncelleyin; uyumun bozulduğu an, genellikle yeni bir aracın sessizce eklendiği andır.