Mobil Uygulamada KVKK: İzin Mimarisi ve Veri Minimizasyonu

Mobil uygulamanda kamera, konum ya da rehber erişimi isteyen her requestPermission çağrısı aslında bir KVKK sorusudur: bu veriye gerçekten ihtiyacın var mı, ne zaman sormalısın, ve kullanıcı reddederse ne olacak? 6698 sayılı Kanun'un teknik karşılığı çoğu zaman "hangi izni ne zaman göstereceğin" ve "topladığın veriyi ne kadar sakladığın" gibi mimari kararlarda gizlidir. Bu yazıda geliştiricinin sorumluluk sınırını, izin mimarisini kuran teknik desenleri ve platform kurallarıyla KVKK'nın kesiştiği noktaları somut kod örnekleriyle ele alacaksın.

💡 Pro Tip: Bir izin talebini eklemeden önce kendine şunu sor: "Bu özelliği izin olmadan da çalıştırabilir miyim?" Android'in resmi izin rehberi geliştiricileri önce buna bakmaya çağırıyor.

İçindekiler

• Geliştiricinin sorumluluk sınırı nerede başlar
• İzin mimarisi: ne zaman, hangi bağlamda sormalı
• Veri minimizasyonu desenleri: picker API'leri ve cihaz-içi işleme
• Log ve analitikte kişisel veri sızıntısı
• Üçüncü taraf SDK envanteri çıkarmak
• İhlal anında teknik hazırlık
• Platform kurallarıyla KVKK'nın kesiştiği noktalar
• SSS
• Mobil uygulamada KVKK uyumu için ne yapılmalı?
• Açık rıza ekranı nasıl tasarlanır?
• Veri minimizasyonu teknik olarak nasıl uygulanır?
• Uygulamamda hangi verilerin kişisel veri sayıldığını nasıl anlarım?
• İzin reddedilirse uygulama ne yapmalı?
• Sonuç
• Kaynaklar

Geliştiricinin sorumluluk sınırı nerede başlar

KVKK'nın 5. maddesi, kişisel veri işlemenin yalnızca kanunda sayılan hukuka uygunluk sebeplerinden biri varsa mümkün olduğunu söyler; açık rıza bunlardan sadece bir tanesidir. Kurum'un kendi ifadesiyle, "İlgili kişinin açık rızasının varlığı... hallerinden birinin varlığı durumunda ilgili kişinin kişisel verilerinin işlenmesi mümkün bulunmaktadır." Bu cümle pratikte şunu değiştirir: her veri toplama noktasında "rıza ekranı koyayım, hallederim" refleksi hukuken yanlıştır.

Kanun bir adım daha ileri gidiyor: açık rıza dışında bir dayanak zaten mevcutken (örneğin bir sözleşmenin ifası için zorunlu veri) yine de kullanıcıya rıza ekranı gösterip onay almak, "aldatıcı ve hakkın kötüye kullanımı niteliğinde" sayılıyor. Yani gereksiz rıza ekranı eklemek "daha güvenli" değil, tam tersine hukuken sorunlu bir davranış olabilir.

Geliştirici olarak sorumluluk sınırın burada başlıyor: hangi veriyi, hangi hukuki sebeple işlediğini bilmeden bir izin ekranı tasarlayamazsın. Pratik akış şu olmalı — önce "bu veriye neden ihtiyacım var" sorusunu ürün/hukuk ekibiyle netleştir, sonra hangi hukuki sebebe (sözleşme, meşru menfaat, açık rıza) dayandığına karar ver, ancak ondan sonra ekranı kodla.

Kanun'un 12. maddesi bu sınırı bir adım daha genişletiyor: veri sorumlusu, kişisel verilerin kendi adına başka bir gerçek veya tüzel kişi (örneğin bir SDK sağlayıcısı) tarafından işlenmesi halinde, gerekli tedbirlerin alınması hususunda bu kişilerle birlikte müştereken sorumludur. Yani bir analitik SDK'sının cihaz kimliğini topladığı andan itibaren o veri akışının hukuki sorumluluğu da senin uygulamana bulaşır — "SDK'nın kendi işi" savunması KVKK karşısında geçerli değildir.

Sorumluluk sınırının bir diğer boyutu, rızanın kalıcı bir onay olmadığıdır. Kurum'un açıklamasına göre "verilen açık rıza geri alınabilir" ve bu noktada "ispat yükümlülüğü veri sorumlusuna aittir." Bu, teknik tarafta doğrudan bir gereksinime dönüşür: uygulaman, bir kullanıcının belirli bir işleme türü için rıza verip vermediğini — ve verdiyse ne zaman, hangi metne rıza verdiğini — geriye dönük olarak kanıtlayabilmeli. Rıza durumunu yalnızca bir Bool bayrağıyla (hasConsented = true) tutmak bu ispat yükünü karşılamaz; en azından zaman damgası, rıza metninin versiyonu ve rızanın hangi kanaldan (uygulama içi ekran, web formu, e-posta onayı) alındığı bilgisi kayıt altına alınmalı. Aşağıdaki bölümde bu izin mimarisinin zamanlama tarafına geçiyoruz.

İzin mimarisi: ne zaman, hangi bağlamda sormalı

İzin talebinin _zamanlaması_ kadar hukuki bir konu yok gibi görünür ama aslında öyle. Apple'ın App Store İnceleme Rehberi'nin 5.1.1(iv) maddesi net bir kural koyuyor: uygulamalar kullanıcının izin ayarlarına saygı göstermeli ve gereksiz veri erişimine zorlamamalı — örnek verilen senaryo şu: "fotoğrafları sosyal ağa gönderme özelliği olan uygulamalar, kullanıcı fotoğraf yüklemeden önce mikrofon erişimi de istememeli" (çeviri). Android tarafında da aynı ilke resmi rehberde geçiyor: izin, kullanıcı ilgili özelliği kullanmaya başladığı anda ve o bağlamda istenmelidir — uygulama açılışında toplu izin isteme deseni önerilmiyor.

Aşağıdaki Swift örneği, konum iznini "uygulama açılışında" değil, kullanıcı haritayı ilk açtığı anda ve neden istendiğini açıklayan bir ön-ekranla birlikte istiyor:

1import CoreLocation
2 
3final class LocationPermissionCoordinator: NSObject, CLLocationManagerDelegate {
4    private let manager = CLLocationManager()
5 
6    // Yalnızca kullanıcı "Yakınımdaki mağazalar" özelliğine dokunduğunda çağrılır.
7    // Uygulama açılışında ya da onboarding sırasında ÇAĞRILMAZ.
8    func requestWhenUserOpensMapFeature() {
9        switch manager.authorizationStatus {
10        case .notDetermined:
11            manager.requestWhenInUseAuthorization()
12        case .denied, .restricted:
13            // Apple 5.1.1(iv): reddedilirse manuel adres girişi gibi bir alternatif sun.
14            presentManualAddressFallback()
15        default:
16            break
17        }
18    }
19}

Android tarafında aynı bağlamsal yaklaşım, resmi izin rehberinin önerdiği gibi, izni özelliğin kullanıldığı ekranda ve gerekçesiyle birlikte gösterir:

1class MapFeatureFragment : Fragment() {
2    private val locationPermission = registerForActivityResult(
3        ActivityResultContracts.RequestPermission()
4    ) { granted ->
5        if (!granted) showManualAddressFallback()
6    }
7 
8    // Kullanıcı "Yakınımdaki mağazalar" sekmesine geçtiğinde çağrılır — açılışta DEĞİL.
9    fun onMapTabSelected() {
10        if (ContextCompat.checkSelfPermission(requireContext(), Manifest.permission.ACCESS_FINE_LOCATION)
11            != PackageManager.PERMISSION_GRANTED
12        ) {
13            showRationaleDialog { locationPermission.launch(Manifest.permission.ACCESS_FINE_LOCATION) }
14        }
15    }
16}

Bu iki örnekte ortak olan şey: izin isteği, kullanıcının o an yapmaya çalıştığı işle doğrudan bağlantılı. Android'in resmi rehberinin vurguladığı gibi, kullanıcılar bir izin talebinin _neden_ geldiğini biliyorsa çok daha rahat davranıyor.

Veri minimizasyonu desenleri: picker API'leri ve cihaz-içi işleme

Apple'ın 5.1.1(iii) maddesi açık: uygulamalar yalnızca temel işlevle ilgili veriye erişim istemeli, mümkün olduğunda tam erişim yerine sistemin sunduğu picker veya share sheet kullanılmalı. Bu, "tüm fotoğraf kütüphanesine erişim iznine ihtiyacım var" yerine, kullanıcının yalnızca seçtiği fotoğrafları paylaşan bir arayüzle çalışmak demek. iOS'ta bunun karşılığı PHPickerViewController: bu bileşen çalıştığında uygulaman NSPhotoLibraryUsageDescription iznine hiç ihtiyaç duymadan, kullanıcının seçtiği görselleri alır — sistem izin diyaloğu bile göstermez, çünkü erişim kütüphaneye değil, kullanıcının seçimine verilir.

1import PhotosUI
2 
3final class AvatarPickerController: NSObject, PHPickerViewControllerDelegate {
4    func presentPicker(from viewController: UIViewController) {
5        var config = PHPickerConfiguration()
6        config.selectionLimit = 1
7        config.filter = .images
8        let picker = PHPickerViewController(configuration: config)
9        picker.delegate = self
10        // NSPhotoLibraryUsageDescription GEREKMEZ — picker sandbox dışında çalışır,
11        // uygulama yalnızca kullanıcının seçtiği tek görsele erişir.
12        viewController.present(picker, animated: true)
13    }
14 
15    func picker(_ picker: PHPickerViewController, didFinishPicking results: [PHPickerResult]) {
16        picker.dismiss(animated: true)
17        // results.first?.itemProvider ile seçilen tek görseli yükle.
18    }
19}

Veri minimizasyonunun ikinci ayağı, veriyi hiç sunucuya göndermeden cihazda işlemek. Android'in resmi izin rehberi bunu doğrudan tavsiye ediyor: "birçok kullanım senaryosu izin deklare etmeden karşılanabilir" (çeviri) diyor ve geliştiricileri önce gerçekten ihtiyaç olup olmadığını değerlendirmeye çağırıyor. Örneğin bir yüz-tanıma tabanlı filtre özelliği, kamera karesini sunucuya yüklemek yerine cihaz üzerinde ML Kit/Core ML ile işleyip yalnız sonucu (örneğin "gülümseme skoru: 0.82") saklayabilir — bu durumda ham görüntü hiçbir zaman cihazdan çıkmaz ve KVKK madde 12 kapsamındaki "veri güvenliği" yükümlülüğünün büyük bölümü kendiliğinden karşılanır, çünkü aktarılan veri yoktur.

Log ve analitikte kişisel veri sızıntısı

Veri minimizasyonu yalnızca izin ekranlarıyla ilgili değil; en sık kaçırılan sızıntı noktası log satırları ve analitik olaylarıdır. Apple'ın 5.1.1(ii) maddesi net: veri "anonim sayılsa bile" (çeviri) kullanıcı rızası gerekir ve ücretli işlev bu rızaya bağlı olamaz. Pratikte bu, Logger.debug("user email: \(user.email)") gibi bir satırın crash-reporting SDK'sına e-posta adresini taşıdığı anlamına gelir — bu satır teknik olarak debug logu olsa da hukuken bir veri işleme faaliyetidir.

1// YANLIŞ: e-posta ham haliyle log'a ve crash SDK'sına gidiyor.
2Logger.debug("checkout failed for \(user.email)")
3 
4// DOĞRU: kimliklendirici alan loglanmadan önce maskeleniyor,
5// hata ayıklama için gereken bağlam (hata kodu) korunuyor.
6func maskedEmail(_ email: String) -> String {
7    guard let atIndex = email.firstIndex(of: "@") else { return "***" }
8    let domain = email[atIndex...]
9    return "***\(domain)"
10}
11Logger.debug("checkout failed for \(maskedEmail(user.email)), code=\(error.code)")

Analitik SDK'lara giden olay özelliklerinde de aynı disiplin gerekir. trackEvent("purchase", properties: ["email": user.email, "phone": user.phone]) gibi bir çağrı, analitik sağlayıcısını da veri işleyen konumuna sokar — madde 12 gereği bu üçüncü tarafla aranızda müşterek sorumluluk doğar. Olay özelliklerinde yalnızca iş amacına hizmet eden alanları (ürün kimliği, tutar, para birimi) taşımak, kimliklendirici alanları ise hiç göndermemek gerekir.

Üçüncü taraf SDK envanteri çıkarmak

Madde 12'nin "veri işleyenle müştereken sorumluluk" hükmü, uygulamana eklediğin her SDK'nın ne topladığını bilmeni zorunlu kılar. Apple'ın 5.1.1(i) maddesi bunu gizlilik politikası seviyesinde talep ediyor: politika, hangi verinin toplandığını ve üçüncü taraflarla nasıl paylaşıldığını açıkça belirtmeli. Bunu manuel takip etmek yerine, bağımlılık listesini periyodik tarayan basit bir script işe yarar:

1#!/usr/bin/env bash
2# Podfile.lock içindeki SDK'ları listeleyip elle tutulan
3# gizlilik envanteriyle karşılaştırır; yeni eklenenleri işaret eder.
4set -euo pipefail
5 
6grep -E '^[[:space:]]{2}- ' Podfile.lock | sed -E 's/^[[:space:]]*-[[:space:]]+//;s/ \(.*//' | sort -u > /tmp/current-sdks.txt || true
7 
8echo "Yeni eklenen SDK'lar (envanterde yok):"
9comm -23 /tmp/current-sdks.txt sdk-privacy-inventory.txt || true

sdk-privacy-inventory.txt, ekibin elle tuttuğu "SDK adı → topladığı veri → gizlilik politikasında beyan edildi mi" tablosudur; script yalnızca yeni eklenen ve henüz envantere girmemiş bağımlılıkları işaret eder. Amaç otomatik bir hukuki karar üretmek değil, "bu SDK'yı kim, ne zaman, hangi veri gerekçesiyle ekledi" sorusuna hızlı cevap verebilmektir.

İhlal anında teknik hazırlık

Kanun'un 12. maddesi, işlenen kişisel verilerin kanuni olmayan yollarla başkaları tarafından ele geçirilmesi halinde veri sorumlusunun "bu durumu en kısa sürede ilgilisine ve Kurula" bildirmekle yükümlü olduğunu söylüyor. Burada dürüst olmak gerekiyor: kanun metninde kesin bir gün sayısı geçmiyor — "en kısa sürede" ifadesi teknik ekibe net bir SLA vermez, bu yüzden bildirim süresinin somut karşılığı için Kurul'un ilgili kararlarına/tebliğlerine bakılmalı ve bu konuda hukuk ekibinle netleşmelisin. Teknik tarafta yapabileceğin, o "en kısa süre"yi gerçekten kısaltacak altyapıyı önceden kurmak.

Bu altyapının üç pratik bileşeni var. Birincisi, yukarıda bahsedilen veri envanteri — hangi tablonun kişisel veri içerdiğini ve hangi hukuki sebeple toplandığını önceden bilmek, olay anında "etki alanı" sorusunu araştırmaktan kurtarır. İkincisi, erişim kayıtlarının (audit log) tutulması: bir veri tabanı tablosuna kim, ne zaman, hangi sorguyla eriştiği kaydedilmiyorsa, bir ihlal şüphesinde "kaç kullanıcı etkilendi" sorusuna cevap vermek ciddi ölçüde zorlaşır. Üçüncüsü, ilgili kişiye bildirim gönderecek kanalın (e-posta, push bildirim) olay anında çalışır durumda olduğundan emin olmak — bu kanalın kendisi devre dışıysa, "en kısa sürede bildirim" yükümlülüğünü yerine getirecek teknik araç elinde olmaz.

Bunun ilk adımı, hangi tablonun kişisel veri içerdiğini önceden işaretlemek — ihlal anında "hangi veriler etkilendi" sorusuna dakikalar içinde cevap verebilmek için:

1{
2  "dataInventory": [
3    {
4      "table": "users",
5      "fields": ["email", "phone", "full_name"],
6      "classification": "personal_data",
7      "legalBasis": "contract_performance"
8    },
9    {
10      "table": "analytics_events",
11      "fields": ["event_name", "product_id", "amount"],
12      "classification": "non_personal",
13      "legalBasis": null
14    },
15    {
16      "table": "location_history",
17      "fields": ["lat", "lng", "recorded_at", "user_id"],
18      "classification": "personal_data",
19      "legalBasis": "explicit_consent"
20    }
21  ]
22}

Bu envanter dosyası bir CI adımında doğrulanabilir: yeni bir migration users veya location_history gibi işaretli tablolara sütun eklediğinde, envanterin de güncellenip güncellenmediğini kontrol eden basit bir script, ihlal anında "bu sütun ne zamandır var, hangi hukuki sebeple toplanıyor" sorusunu saniyeler içinde cevaplar. İhlal hazırlığının teknik tarafı büyük ölçüde budur: olay anında araştırmaya değil, önceden hazırlanmış bir haritaya bakmak.

Platform kurallarıyla KVKK'nın kesiştiği noktalar

KVKK'nın hukuki gerekliliği ile Apple/Google'ın mağaza kuralları çoğu noktada aynı yöne işaret ediyor, ama aynı şey değiller — biri kanun, diğeri sözleşmesel bir inceleme politikası. Apple'ın 5.1.1(viii) maddesi, kullanıcının doğrudan verdiği açık rıza olmadan, kamuya açık kaynaklar dahil, kişisel veri derleyen (compile eden) uygulamaları yasaklıyor — bu, KVKK madde 5'in "açık rıza veya başka bir hukuki sebep" şartıyla aynı ruhu taşıyor ama mağaza incelemesi yalnızca "App Store'da yayınlanabilir mi" sorusuna cevap verir, KVKK ihlali riskini ortadan kaldırmaz.

Benzer şekilde Apple'ın 5.1.1(i) maddesindeki gizlilik politikası şartları (hangi veri toplanıyor, üçüncü taraflarla paylaşım, saklama/silme politikası, rızanın nasıl geri çekileceği) KVKK madde 10'daki aydınlatma yükümlülüğüyle büyük ölçüde örtüşüyor — ikisini tek bir gizlilik politikası metninde karşılamak mümkün, ama metnin KVKK'nın istediği tüm unsurları (veri sorumlusunun kimliği, işleme amacı, aktarım, toplama yöntemi ve hukuki sebep, ilgili kişinin hakları) içerdiğinden ayrıca emin olman gerekir; mağaza şablonu bunu otomatik garanti etmez.

SSS

Mobil uygulamada KVKK uyumu için ne yapılmalı?

Önce hangi veriyi hangi hukuki sebeple işlediğini netleştirmelisin — madde 5'e göre açık rıza yalnızca sebeplerden biri, gereksiz yere her veri için rıza ekranı eklemek "hakkın kötüye kullanımı" sayılabilir. Bunun ardından madde 10 kapsamında aydınlatma metni hazırlamalı, madde 11'deki hakları (öğrenme, düzeltme, silme, itiraz) kullanıcıya teknik olarak da sunmalı ve madde 12 gereği eklediğin her üçüncü taraf SDK için müşterek sorumluluk bilinciyle bir veri envanteri tutmalısın.

Açık rıza ekranı nasıl tasarlanır?

Kurum'un yayımladığı açıklamaya göre geçerli bir açık rızanın üç unsuru var: belirli bir konuya ilişkin olması, bilgilendirmeye dayanması ve özgür iradeyle açıklanması. Pratikte bu, "tüm verilerinizi işleyebilir miyiz" gibi genel nitelikli — Kurum'un tabiriyle "battaniye rıza" — ekranların hukuken geçersiz sayıldığı anlamına gelir; her rıza ekranı tek bir işleme amacına özgü ve geri çekilebilir olmalı.

Veri minimizasyonu teknik olarak nasıl uygulanır?

Apple'ın 5.1.1(iii) maddesinin önerdiği gibi, tam kaynak erişimi yerine sistemin sunduğu picker/share-sheet bileşenlerini (iOS'ta PHPickerViewController, Android'de sistem foto seçici) kullanmak izin gerektirmeden veri erişimini sınırlar. Mümkün olduğunda işlemeyi cihaz üzerinde (Core ML, ML Kit) yapıp yalnız sonucu sunucuya taşımak, ham veriyi hiç aktarmadan aynı işlevi sağlar.

Uygulamamda hangi verilerin kişisel veri sayıldığını nasıl anlarım?

E-posta, telefon, tam ad gibi doğrudan tanımlayıcılar açık örnektir; konum geçmişi, cihaz kimliğiyle eşlenmiş davranışsal veri ve özel nitelikli veriler (sağlık, biyometrik veri gibi — Kurum'un sınırlı saydığı ve kıyasla genişletilemeyen liste) de kapsama girer. Şüpheli alanlar için "bu veri tek başına ya da başka veriyle birleşince bir kişiyi tanımlayabiliyor mu" sorusunu sormak iyi bir başlangıç noktasıdır, ama nihai sınıflandırma için hukuk ekibiyle çalışmalısın.

İzin reddedilirse uygulama ne yapmalı?

Apple'ın 5.1.1(iv) maddesi açık bir örnek veriyor: kullanıcı konum paylaşmayı reddederse uygulama manuel adres girişi gibi bir alternatif sunmalı — özelliği tamamen kilitlemek ya da kullanıcıyı izni vermeye zorlayan tekrarlı diyaloglarla yormak kabul edilmiyor. Aynı yaklaşım KVKK'nın rızanın "özgür iradeyle" verilmesi şartıyla da örtüşüyor: baskı altında alınan onay geçerli bir rıza sayılmaz.

Sonuç

Mobil uygulamada KVKK uyumu, tek seferlik bir "gizlilik ekranı" işi değil; izin isteğinin zamanlamasından log satırlarındaki alan adlarına kadar uzanan sürekli bir mimari disiplin. iOS Security Best Practices 2024 rehberi bu disiplinin güvenlik tarafını, iOS Keychain ve Güvenlik ise hassas verinin cihazda nasıl saklanması gerektiğini tamamlıyor. Ağ trafiğinde benzer bir minimizasyon yaklaşımı için iOS Network Security Advanced rehberine, ATT ve izleme izinlerine özgü detaylar için iOS Privacy Compliance & ATT yazısına bakabilirsin. Android tarafında izin ve gizlilik sandbox'ı değişikliklerini Android 15 Developer Rehberi: Privacy Sandbox kapsıyor, crash/analitik verisinin nasıl temiz tutulacağına dair pratik detaylar ise iOS Crash Reporting ve Analytics yazısında.

Kanunun madde numaraları ve platform kurallarının madde numaraları elbette güncel kalmaya devam edecek şekilde değişebilir — bu yazıdaki teknik desenler (bağlamsal izin isteği, picker kullanımı, log maskeleme, SDK envanteri) ise mimari seviyede kalıcı, çünkü hangi hukuki metin değişirse değişsin veri minimizasyonu prensibi aynı kalıyor. Bu yazı teknik bir rehberdir, hukuki tavsiye değildir; kendi uygulamandaki nihai değerlendirme için bir hukuk uzmanına danış.

Kaynaklar

• KVKK — Kişisel Veriler — Kanun'un 5. maddesi ve hukuka uygunluk sebepleri hakkında resmi açıklama.
• KVKK — Açık Rıza Alırken Dikkat Edilecek Hususlar — açık rızanın üç unsuru ve "battaniye rıza" kavramı.
• KVKK — Aydınlatma Yükümlülüğü — madde 10 kapsamındaki bilgilendirme şartları.
• KVKK — İlgili Kişinin Hakları — madde 11 kapsamındaki haklar listesi.
• KVKK — Özel Nitelikli Kişisel Veriler — sınırlı sayma ile belirlenen özel kategori veriler.
• KVKK — Veri Güvenliğine İlişkin Yükümlülükler — madde 12 ve ihlal bildirim yükümlülüğü.
• Apple App Store Review Guidelines — 5.1 Privacy — veri toplama rızası, minimizasyon ve gizlilik politikası şartları.
• Android Developers — Requesting Permissions — bağlamsal izin isteme ve minimizasyon rehberi.