KVKK uyumlu mobil uygulama geliştirmek, yalnızca bir onay kutusu eklemekten ibaret değildir. Mobil tarafta toplanan her veri alanı, cihaz izni, analitik eventi, log kaydı ve saklama süresi daha tasarım aşamasında düşünülmelidir. Özellikle konum, iletişim bilgisi, cihaz kimliği, ödeme verisi ya da sağlık verisi gibi alanlarda “önce topla, sonra bakarız” yaklaşımı ciddi risk yaratır.
Türkiye’de faaliyet gösteren işletmeler için temel çerçeve 6698 sayılı Kişisel Verilerin Korunması Kanunu’dur. Mobil uygulama geliştirme sürecinde ürün ekipleri, yazılım ekipleri ve hukuk birimi aynı masada buluşmadığında en sık görülen tablo şudur: uygulama işlevsel olarak hazırdır, ancak veri işleme envanteri, açık rıza kurgusu, log politikası ve silme akışı eksik kalır. Bu eksik de yayına çıkış sonrasında maliyetli bir yeniden geliştirme döngüsüne dönüşebilir.
Sağlam yaklaşım aslında nettir. Hangi veriyi neden topladığınızı tanımlayın. Hukuki işleme şartını belirleyin. Açık rıza gerekip gerekmediğini ayırın. Logları sınırlayın. Saklama süresini en baştan yazın. Uygulama ekranları, API katmanı, veritabanı ve bulut altyapısı bu çerçeveyle hizalanırsa, KVKK uyumlu mobil uygulama kurmak teknik açıdan yönetilebilir bir probleme dönüşür.
Veri toplama tasarımı: Her alan için amaç, dayanak ve süre tanımlayın
İyi bir başlangıç noktası veri minimizasyonudur. Bir mobil uygulamada kayıt formunda 12 alan istemek kolaydır; oysa gerçekten gerekli alan sayısı çoğu senaryoda 4 ila 6 arasında kalır. Ad, e-posta, telefon ve parola ile ilerlenebilecek bir akışta doğum tarihi, açık adres ya da rehber erişimi istemek çoğu durumda gereksizdir.
Burada ekiplerin kullanabileceği pratik yöntem, “veri envanteri tablosu” oluşturmaktır. Her veri alanı için şu başlıklar net olmalıdır: veri kategorisi, işleme amacı, hukuki sebep, saklama süresi, erişen sistemler, aktarım yapılan üçüncü taraflar. Örneğin bir kurye uygulamasında anlık konumun işlenme amacı teslimat takibi olabilir. Aynı konumu pazarlama segmentasyonu için kullanmak istiyorsanız, bu ikinci amaç ayrıca değerlendirilmelidir.
Mobil uygulamalarda sık toplanan veriler nasıl sınıflanır?
- Zorunlu operasyonel veriler: kullanıcı kimliği, oturum bilgisi, sipariş geçmişi, teslimat adresi.
- Cihaz ve kullanım verileri: IP, işletim sistemi sürümü, uygulama versiyonu, çökme kayıtları.
- İsteğe bağlı veriler: profil fotoğrafı, pazarlama tercihleri, favoriler, ilgi alanları.
Buradaki kritik nokta şu: teknik olarak erişebiliyor olmak, hukuken sınırsız veri toplayabileceğiniz anlamına gelmez. iOS ve Android izin modeli size kamera, mikrofon, bildirim ya da konum erişimi sunar; ancak KVKK açısından bu erişimin ölçülü, belirli ve açıklanmış olması gerekir.
Somut bir senaryo düşünelim. Restoran rezervasyon uygulaması geliştiriyorsunuz. Masa rezervasyonu için ad-soyad, telefon numarası ve rezervasyon saati yeterliyse T.C. kimlik numarası istemek açıkça aşırıdır. Aynı uygulama “yakındaki şubeleri göster” özelliği için konum izni talep edecekse, kullanıcı uygulamayı ilk açtığı anda değil, bu özelliğe dokunduğu anda izin istemek daha doğru bir kurgudur.
Açık rıza kurgusu: Zorunlu işlem ile tercihe bağlı işlem ayrılmalı
Açık rıza, mobil uygulamalarda en sık hatalı uygulanan alanlardan biridir. Her veri işleme faaliyeti açık rızaya dayanmaz. Sözleşmenin kurulması veya ifası için gerekli veri işlemleri, yasal yükümlülükler ya da meşru menfaat gibi başka hukuki sebepler de olabilir. Asıl sorun, bütün akışın tek bir “Kabul ediyorum” butonuna sıkıştırılmasıdır.
KVKK uyumlu mobil uygulama yaklaşımında iki katmanlı bir yapı daha sağlıklıdır. İlk katmanda aydınlatma metni yer alır. Kullanıcıya veri sorumlusunun kim olduğu, hangi verilerin hangi amaçlarla işlendiği, kimlere aktarılabileceği ve haklarının neler olduğu sade bir dille gösterilir. İkinci katmanda ise gerekiyorsa açık rıza alınır. Pazarlama iletişimi, profil çıkarma, hassas veri kullanımı veya zorunlu olmayan analitik/çerez benzeri takip işlemleri buna örnek olabilir.
İyi bir açık rıza ekranında hangi unsurlar bulunmalı?
- Rıza metni ayrı, aydınlatma metni ayrı sunulmalı.
- Önceden işaretli kutu kullanılmamalı.
- “Hepsini kabul et” varsa, ayrı tercih seçenekleri de bulunmalı.
- Rızanın zamanı, versiyonu ve kaynağı kayıt altına alınmalı.
Örneğin bir fitness uygulamasında sağlık verileri işleniyorsa, bu veri kategorisi için açık ve belirgin bir anlatım gerekir. “Deneyimi iyileştirmek için verilerinizi kullanırız” gibi muğlak ifadeler yeterli değildir. Hangi veri, hangi özellik için, ne kadar süreyle işlenecek; bu soruların net biçimde cevaplanması gerekir.
Teknik tarafta rıza yönetimini versiyonlu tasarlamak önemlidir. Aydınlatma metni v1.2, pazarlama rızası metni v1.0 gibi etiketler kullanılabilir. Kullanıcının 2026-03-14 10:42:11 UTC anında hangi metne onay verdiği, API tarafında immutable audit kaydı olarak tutulmalıdır. Bu kayıt sonradan güncellenmemeli; her yeni tercih değişikliği yeni bir satır olarak eklenmelidir.
Loglama politikası: Güvenlik için gerekli olanı tutun, fazlasını değil
Mobil uygulamalarda loglama çoğu zaman geliştirici kolaylığı adına geniş tutulur. Oysa debug amacıyla bırakılan ayrıntılı loglar; e-posta adresi, telefon numarası, access token, adres bilgisi hatta ödeme akışıyla ilgili kritik veri parçaları içerebilir. Üretim ortamında bu yaklaşım ciddi risk taşır.
Pratik kural şudur: uygulama logları ile denetim kayıtlarını ayırın. Uygulama logları performans, hata ve servis sağlığı içindir. Denetim kayıtları ise güvenlik ve yetki takibi için tutulur. Bu iki kayıt türünün içeriği, erişim yetkisi ve saklama süresi aynı olmak zorunda değildir.
Loglama sırasında kaçınılması gereken tipik hatalar
- JWT, oturum anahtarı veya yenileme token’ını düz metin loglamak.
- API istek gövdelerini filtrelemeden komple kaydetmek.
- Hata ekran görüntülerinde kişisel veriyi maskelemeden destek ekibine iletmek.
Örnek bir API log yaklaşımı şöyle olabilir:
{
"timestamp": "2026-07-07T09:15:22Z",
"endpoint": "/api/v1/orders",
"method": "POST",
"user_id_hash": "8f4a...",
"status_code": 201,
"response_time_ms": 184,
"request_id": "req_71c2..."
}Bu örnekte kullanıcı kimliği hash ile temsil ediliyor. Sipariş içeriği, açık adres veya telefon bilgisi logda yer almıyor. Destek ve güvenlik senaryoları için çoğu durumda bu kadar veri yeterlidir.
Crash reporting araçları da ayrıca gözden geçirilmelidir. Varsayılan ayarlarda cihaz modeli, IP, kullanıcı aksiyonları veya özel hata bağlamı toplanabilir. Üçüncü taraf servis kullanıyorsanız, verinin hangi ülkede işlendiği, alt işleyen ilişkisi, aktarım koşulları ve sözleşmesel önlemler incelenmelidir. Tek bir SDK eklemek, bazen 3 farklı veri akışını beraberinde getirebilir.
Saklama ve silme politikaları: Süresiz veri tutma alışkanlığını bırakın
Birçok mobil üründe en zayıf halka saklama politikasıdır. Veri toplanır, yedeklere girer, loglara dağılır, test ortamına kopyalanır ve yıllarca kalır. Oysa KVKK açısından kişisel veriler, işlendikleri amaç için gerekli olan süre kadar muhafaza edilmelidir. Bu ilke teknik mimariye çevrilmeden uyum sağlanmış sayılmaz.
En azından şu dört katman için ayrı süre tanımlanmalıdır: uygulama veritabanı, log sistemi, yedekler, analitik platformu. Örneğin destek amaçlı uygulama loglarının 30 gün tutulması yeterliyse, bunları 365 gün saklamanın teknik gerekçesi açıkça ortaya konmalıdır. Yedeklerde veri tutulması da ayrıca değerlendirilmelidir; canlı sistemden silinen kaydın yedek döngülerinde ne kadar süre daha bulunacağı hem politika metninde hem de iç süreçlerde karşılığını bulmalıdır.
Saklama politikası dokümanında neler yer almalı?
- Veri kategorisi bazında saklama süresi.
- Süre bitince silme, yok etme veya anonimleştirme yöntemi.
- Yedeklerden geri dönüş senaryolarında uygulanacak kurallar.
- Test ve staging ortamlarında veri maskeleme standardı.
Somut bir örnek verelim. Bir e-ticaret mobil uygulamasında kullanılmayan hesapların 24 ay sonunda gözden geçirilmesi, pazarlama izinlerinin ayrı tutulması ve destek loglarının 90 gün sonunda otomatik temizlenmesi kurgulanabilir. Buradaki süreler işletmenin faaliyet alanına, sözleşmesel yükümlülüklerine ve mevzuat ihtiyaçlarına göre değişir; önemli olan, her veri sınıfı için yazılı, uygulanabilir ve denetlenebilir bir kuralın bulunmasıdır.
Silme talepleri için de teknik bir akış gerekir. Kullanıcı uygulama içinden hesap silme talebi verdiğinde bu süreç yalnızca “soft delete” ile sınırlı kalmamalı. İlgili tablolar, dosya depolama alanları, bildirim token’ları, CRM eşleşmeleri ve üçüncü taraf entegrasyonları için kuyruğa alınmış bir veri silme işi çalıştırılmalıdır. Büyük sistemlerde bu süreç genellikle 1-2 dakika içinde başlar; tamamlanma durumu ise kullanıcıya e-posta veya uygulama içi mesajla bildirilir.
Uygulama mimarisi ve güvenlik kontrolleri: Uyum teknik altyapıyla korunur
KVKK uyumlu mobil uygulama yalnızca metinlerle değil, mimari kararlarla inşa edilir. Veri aktarımında TLS 1.2+ kullanımı, hassas alanların sunucu tarafında şifrelenmesi, rol bazlı erişim kontrolü, gizli anahtarların mobil uygulama içine gömülmemesi temel seviyedeki gerekliliklerdir. Bunlar olmadan hazırlanan aydınlatma metni pratikte yetersiz kalır.
Mobil istemcide hassas veriyi mümkün olduğunca kısa süre tutmak gerekir. Kalıcı depolamaya yazılacaksa platformun güvenli alanları tercih edilmelidir. iOS Keychain ve Android Keystore gibi mekanizmalar burada öne çıkar. Access token ömrü örneğin 15 dakika ile sınırlandırılırken, refresh token yönetimi sunucu tarafında iptal edilebilir şekilde tasarlanmalıdır.
Yetkilendirme kontrolleri de kritik önem taşır. Kullanıcı A’nın kendi siparişini görebildiği, ancak kullanıcı B’nin sipariş numarasını tahmin ederek erişemediği test edilmelidir. Bu tür erişim açıkları kişisel veri ihlaline dönüşür. API katmanında resource-level authorization kontrolleri, mobil uygulama güvenliğinin vazgeçilmez parçalarındandır.
Kurumsal projelerde 2 haftalık sprintler içinde şu kontrol listesi uygulanabilir: yeni veri alanı eklendi mi, aydınlatma etkileniyor mu, log kapsamı değişti mi, üçüncü taraf SDK eklendi mi, saklama süresi tanımlandı mı? Uyum, bir defalık checklist değildir; her sürümde yeniden ele alınmalıdır.
Yayın öncesi kontrol listesi: 10 maddelik pratik çerçeve
Canlıya çıkmadan önce ekiplerin kısa ama etkili bir kontrol yapması gerekir. Aşağıdaki 10 madde, çoğu mobil proje için iyi bir başlangıç sunar:
- Toplanan tüm veri alanları envantere işlendi mi?
- Her alan için işleme amacı yazıldı mı?
- Açık rıza gerektiren işlemler ayrıştırıldı mı?
- Aydınlatma metni uygulama içinde erişilebilir mi?
- Rıza kayıtları zaman damgası ve metin versiyonuyla tutuluyor mu?
- Üretim loglarında kişisel veri maskeleme aktif mi?
- SDK ve üçüncü taraf servis veri akışları incelendi mi?
- Saklama ve silme süreleri teknik olarak uygulanıyor mu?
- Hesap silme ve veri talebi akışları test edildi mi?
- Test ortamında gerçek veri yerine maskeli veri kullanılıyor mu?
Bu maddeler tek başına hukuki görüşün yerini tutmaz. Yine de yazılım ekibinin hata payını ciddi ölçüde azaltır. Aynı zamanda son dakika revizyonlarını düşürür ve ürün çıkış takviminin korunmasına yardımcı olur.
Özetle, KVKK uyumlu mobil uygulama geliştirme işi; kullanıcı deneyimi, backend mimarisi, veri yönetişimi ve hukuk çerçevesinin kesişiminde yer alır. Başarılı ekipler bunu bir “uyum dokümanı” olarak değil, ürün tasarım standardı olarak ele alır. Veri toplama sınırlandırılır, açık rıza doğru yerde alınır, loglar temiz tutulur, saklama süresi otomasyona bağlanır. Bu şekilde kurulan sistem hem denetlenebilir olur hem de kullanıcı güvenini daha sağlam taşır.
