KVKK Uyumunda Veri Seti Nasıl Ele Alınır?

Android uygulamalarında kullanıcıdan toplanan her bilgi, teknik bir kayıt gibi görünse bile KVKK açısından belirli bir amaca, hukuki sebebe ve saklama süresine bağlanmalıdır. Bu nedenle bir veri setini ele almak yalnızca veritabanı tasarımı ya da analitik ihtiyacı değildir; uygulamanın izin ekranlarından sunucu kayıtlarına, hata ayıklama süreçlerinden üçüncü taraf SDK kullanımına kadar bütün veri yaşam döngüsünü kapsayan kurumsal bir uyum çalışmasıdır.

Doğru yaklaşım, önce hangi verinin neden toplandığını netleştirmekle başlar. Kullanıcı adı, e-posta, cihaz kimliği, konum, IP adresi, reklam kimliği, işlem geçmişi veya uygulama içi davranış verileri farklı risk seviyelerine sahiptir. KVKK veri seti yönetimi, bu bilgilerin rastgele bir tabloda tutulması yerine sınıflandırılmış, erişimi sınırlandırılmış ve gerektiğinde silinebilir şekilde yapılandırılmasını gerektirir.

Veri setini tanımlama: İlk kontrol noktası

Bir veri seti, aynı amaçla işlenen kişisel verilerin bütünüdür. Android tarafında bu veri seti yerel depolamada, mobil analitik araçlarında, bildirim servislerinde, CRM sisteminde veya backend veritabanında oluşabilir. Sık yapılan hata, yalnızca merkezi veritabanını dikkate alıp cihaz üzerinde tutulan önbellek, log dosyası veya üçüncü taraf servis kayıtlarını kapsam dışında bırakmaktır.

Kurumsal bir envanter çalışmasında şu sorular net yanıtlanmalıdır:

• Hangi kişisel veriler toplanıyor?
• Veri hangi ekran, form, SDK veya API üzerinden elde ediliyor?
• İşleme amacı açık ve ölçülü mü?
• Veri Türkiye içinde mi, yurt dışında mı saklanıyor?
• Erişim yetkisi kimlerde bulunuyor?
• Silme, anonimleştirme veya maskeleme yöntemi tanımlı mı?

Veri minimizasyonu Android uygulamalarında nasıl uygulanır?

KVKK’nın en kritik ilkelerinden biri, işlenen verinin amaçla sınırlı ve ölçülü olmasıdır. Uygulama deneyimini iyileştirmek için tüm izinleri baştan istemek pratik görünse de uyum açısından risklidir. Örneğin yalnızca şehir bazlı kampanya göstermek için sürekli hassas konum almak çoğu durumda gereksizdir. Bunun yerine kullanıcıdan il seçimi almak veya yaklaşık konum kullanmak daha doğru olabilir.

Android izinlerinde de aynı mantık geçerlidir. Kamera, mikrofon, rehber, konum veya dosya erişimi yalnızca ilgili özellik kullanılacağı anda talep edilmelidir. Kullanıcı izni reddettiğinde uygulama tamamen kullanılamaz hale gelmemeli; mümkünse alternatif bir akış sunulmalıdır. Bu yaklaşım hem kullanıcı güvenini artırır hem de aydınlatma yükümlülüğünün daha anlaşılır yerine getirilmesine katkı sağlar.

Hukuki sebep ve açık rıza ayrımı

Her kişisel veri işleme faaliyeti için açık rıza almak doğru bir yöntem değildir. Bazı veriler sözleşmenin kurulması veya ifası için gerekli olabilir; bazıları hukuki yükümlülük kapsamında tutulabilir. Pazarlama, kişiselleştirilmiş reklam veya üçüncü taraf analiz amaçlı kullanımlarda ise açık rıza gerekebilir.

Pratikte dikkat edilmesi gereken nokta, aydınlatma metni ile rıza metninin aynı şey gibi sunulmamasıdır. Aydınlatma, kullanıcıya bilgi verme yükümlülüğüdür; açık rıza ise belirli bir konuya ilişkin özgür irade beyanıdır. Özellikle mobil uygulamalarda tek bir onay kutusuyla hem üyelik, hem pazarlama, hem veri paylaşımı hem de çerez/SDK izinlerini almak uyum riski doğurur.

Teknik güvenlik: Veri setinin korunması

Veri setinin KVKK’ya uygun ele alınması, yalnızca metin ve izin süreçleriyle sınırlı değildir. Teknik ve idari tedbirler birlikte değerlendirilmelidir. Android uygulamalarında yerel veri saklanıyorsa hassas bilgilerin düz metin olarak SharedPreferences içinde tutulması ciddi bir zafiyettir. Gerekli durumlarda şifreli depolama, güvenli anahtar yönetimi ve token süre kısıtları uygulanmalıdır.

Sunucu tarafında ise rol bazlı erişim, kayıt altına alma, veri maskeleme, düzenli yetki gözden geçirme ve yedeklerde kişisel veri kontrolü önemlidir. Test ortamlarında gerçek kullanıcı verisi kullanılması da sık karşılaşılan bir hatadır. Test ve geliştirme süreçlerinde anonimleştirilmiş veya sentetik veri tercih edilmelidir.

Log kayıtlarında gözden kaçan riskler

Mobil uygulamalarda hata takibi için kullanılan loglar, beklenenden fazla kişisel veri içerebilir. API yanıtlarının tamamını loglamak, kullanıcı tokenlarını, e-posta adreslerini veya konum bilgisini istemeden kaydetmeye neden olabilir. Log politikası oluşturulurken hangi alanların kaydedileceği, ne kadar süre tutulacağı ve kimlerin erişeceği açıkça belirlenmelidir.

Saklama süresi ve silme süreçleri

Bir veri seti için en önemli kararlardan biri, verinin ne kadar süre saklanacağıdır. “İleride lazım olabilir” yaklaşımı KVKK açısından yeterli gerekçe oluşturmaz. Üyelik verisi, fatura bilgisi, işlem kayıtları, pazarlama izinleri ve analitik veriler farklı saklama sürelerine sahip olabilir.

Kullanıcı hesabını sildiğinde tüm verilerin anında yok edilmesi her zaman mümkün olmayabilir; örneğin mevzuat gereği saklanması gereken kayıtlar bulunabilir. Ancak bu durumda veri aktif kullanım dışına alınmalı, erişim sınırlandırılmalı ve süre sonunda silme veya anonimleştirme işlemi çalıştırılmalıdır. KVKK veri seti yönetimi açısından silme talebinin hangi sistemlere yansıyacağı önceden haritalanmalıdır.

Üçüncü taraf SDK ve veri aktarımı

Android uygulamalarında analitik, reklam, crash reporting, push notification veya ödeme altyapısı için üçüncü taraf SDK’lar kullanılabilir. Bu bileşenler çoğu zaman cihaz bilgisi, oturum verisi, IP adresi veya kullanıcı davranışı toplayabilir. Bu nedenle her SDK için hangi verilerin işlendiği, verinin nereye aktarıldığı ve aktarımın hangi hukuki temele dayandığı incelenmelidir.

Özellikle yurt dışına veri aktarımı ihtimali varsa, yalnızca teknik entegrasyon yeterli görülmemelidir. Sözleşme, kullanıcı bilgilendirmesi, rıza yönetimi ve aktarım mekanizması birlikte değerlendirilmelidir. Uygulama mağazalarındaki veri güvenliği beyanları ile KVKK aydınlatma metinlerinin birbiriyle çelişmemesi de kurumsal itibar açısından önem taşır.

Uygulanabilir kontrol listesi

Veri setini yönetirken ekiplerin kullanabileceği sade bir kontrol listesi uyum sürecini hızlandırır:

• Veri envanteri güncel mi?
• Her veri alanı için işleme amacı tanımlı mı?
• Gereksiz izin ve veri alanları kaldırıldı mı?
• Açık rıza gereken işlemler ayrı yönetiliyor mu?
• Yerel depolama ve API trafiği güvenli mi?
• Loglarda kişisel veri sızıntısı kontrol edildi mi?
• Saklama ve silme süreleri teknik sistemlere uygulanıyor mu?
• Üçüncü taraf SDK’lar düzenli olarak gözden geçiriliyor mu?

Bu adımlar, Android uygulamasında veri işleme faaliyetlerini yalnızca mevzuata uygun hale getirmekle kalmaz; ürün ekiplerinin daha sade, güvenli ve sürdürülebilir bir veri mimarisi kurmasına da yardımcı olur. Veri seti her yeni özellikte yeniden değerlendirildiğinde, uyum çalışması sonradan eklenen bir kontrol olmaktan çıkar ve ürün geliştirme sürecinin doğal parçası haline gelir.