Mobil Uygulamada KVKK Uyumu Nasıl Sağlanır? Aydınlatma, Rıza, İzinler

Not: Bu yazı genel bilgilendirme amaçlıdır, hukuki danışmanlık değildir. Kendi uygulamanız için bir avukata veya veri koruma uzmanına danışın.

Talha Aslan ve ekibi olarak uygulama projelerinde bu envanteri tasarımdan önce çıkarıyoruz. Çünkü KVKK uyumu, yayından bir gün önce eklenen bir metin değildir. Ekran akışı, izin pencereleri, analitik kütüphaneleri ve sunucu konumu aynı kararın parçalarıdır. Bu rehberde aydınlatma metninin yerini, açık rızanın ne zaman gerektiğini, konum ve kamera izinlerinin gerekçesini, üçüncü taraf kütüphaneleri, hesap silmeyi ve yurt dışı aktarımı adım adım ele alıyoruz.

Kanunun kendisi kısa ve okunabilir bir metin. Bu nedenle temel maddeleri okumanızı öneriyoruz: 6698 sayılı Kişisel Verilerin Korunması Kanunu resmi mevzuat sitesinde güncel haliyle yer alıyor.

Mobil uygulamada KVKK hangi verileri kapsar?

Kanun kişisel veriyi "kimliği belirli veya belirlenebilir gerçek kişiye ilişkin her türlü bilgi" diye tanımlar. Yani yalnız ad ve telefon değil, bir kişiyle eşleştirilebilen her iz bu kapsama girer. Mobil uygulamada bu çerçeve, çoğu ekibin tahmin ettiğinden geniştir.

Örneğin bir sipariş uygulaması şu verileri işleyebilir:

• Kimlik ve iletişim: ad, e-posta, telefon, teslimat adresi.
• Hesap verisi: kullanıcı adı, şifre özeti, giriş kayıtları.
• Cihaz verisi: cihaz kimlikleri, işletim sistemi sürümü, bildirim jetonu (push token).
• Konum: anlık ya da yaklaşık konum.
• Kullanım verisi: hangi ekranı açtığı, hangi ürüne dokunduğu, oturum süresi.
• Kullanıcı içeriği: yüklediği fotoğraf, yazdığı yorum, rehberden seçtiği kişi.

Ayrıca kanun bazı verileri özel nitelikli sayar: sağlık, biyometrik ve genetik veri bunlardan bazılarıdır. Örneğin cihazın yüz tanıma ile kilit açması cihazda kalır. Ancak uygulamanız yüz görüntüsünü sunucuya taşıyıp eşleştiriyorsa, artık çok daha sıkı bir rejimin içindesiniz. Dolayısıyla envanterde her veri için "veriyi nerede tutuyoruz, veri cihazdan çıkıyor mu?" sorusunu da yanıtlayın.

Bir de bildirim jetonu ve reklam kimliği gibi teknik kimlikleri gözden kaçırmayın. Bu değerler tek başına bir isim taşımaz; ancak hesabınızdaki e-posta veya telefonla eşleştiğinde kişiyi belirlenebilir kılar. Bu yüzden onları da envantere yazın, saklama süresini belirleyin ve kullanıcı hesabını sildiğinde bu kimlikleri de temizleyin. Örneğin pazarlama bildirimi göndermeyi bırakan bir uygulama, eski jetonları sunucuda yıllarca tutmamalı.

Aydınlatma metni uygulamanın neresinde durmalı?

Aydınlatmayı, veriyi toplarken yaparsınız. Kanunun 10. maddesi, kişisel veriler elde edilirken veri sorumlusunun kimliğini, işleme amacını, verinin kimlere ve hangi amaçla aktarılabileceğini, toplama yöntemini ve hukuki sebebini, son olarak ilgili kişinin haklarını anlatmanızı ister. Mobil uygulamada bu, metnin doğru anda görünmesi demektir.

Pratikte üç katmanlı bir yerleşim öneriyoruz:

1. Kayıt ekranında, form gönderilmeden önce görünen kısa bir özet ve tam metne giden bağlantı.
2. Ayarlar veya Profil menüsünde her zaman ulaşılabilen "Gizlilik ve KVKK" bölümü.
3. Konum, kamera gibi hassas izinlerden hemen önce, yalnız o veriyi anlatan kısa bir açıklama.

Öte yandan mağazaların da kendi beklentisi var. Apple, App Store İnceleme Yönergeleri içindeki 5.1.1 maddesinde gizlilik politikası bağlantısının hem App Store Connect alanında hem de uygulama içinde kolay erişilebilir olmasını istiyor. Google Play de politika bağlantısını Play Console'daki ilgili alana ve uygulamanın içine koymanızı bekliyor. Böylece tek metinle iki mağazanın beklentisini ve kanunun bilgilendirme şartını aynı anda karşılarsınız.

Aydınlatma ile açık rızayı neden aynı ekranda birleştirmemelisiniz?

Çünkü ikisi farklı işler yapar. Aydınlatma bir bilgilendirmedir ve kullanıcıdan onay beklemez. Açık rıza ise kanunun tanımıyla "belirli bir konuya ilişkin, bilgilendirilmeye dayanan ve özgür iradeyle açıklanan rıza"dır. Tek bir "Okudum, kabul ediyorum" kutusu bu iki işi birbirine karıştırır.

Sık gördüğümüz hatalı kurgu şudur: kayıt formunun altında tek bir zorunlu kutu var; içinde üyelik sözleşmesi, aydınlatma metni, pazarlama izni ve yurt dışı aktarım onayı birlikte duruyor. Kullanıcı kutuyu işaretlemezse kayıt olamıyor. Bu durumda rıza ne belirli bir konuya ilişkin ne de özgür iradeye dayanıyor.

Doğru kurgu ise şöyle olmalı:

• Aydınlatma metni bir bağlantı ve kısa özet olarak yer alır ve onay kutusu taşımaz.
• Her rıza konusu için ayrı, varsayılanı boş bir seçenek yer alır.
• Pazarlama iletisi rızası vermeyen kullanıcı da kayıt olabilir.
• Kullanıcı verdiği rızayı daha sonra ayarlardan geri çekebilir.

Kısacası aydınlatma "bilmeniz gerekenler", rıza ise "isterseniz izin verin" ekranıdır.

Hangi işlemler için açık rıza gerekir, hangileri için gerekmez?

Her veri işleme açık rızaya dayanmak zorunda değildir. Kanunun 5. maddesi, açık rıza aranmadan işlemeye izin veren şartları sayar. Bunlar arasında sözleşmenin kurulması veya ifası için gereklilik, hukuki yükümlülük, bir hakkın tesisi ve veri sorumlusunun meşru menfaati yer alır.

Bu ayrım uygulama tasarımını doğrudan etkiler. Örneğin kullanıcının siparişini teslim etmek için adresini işlemeniz, kurduğunuz sözleşmenin ifasıyla ilgilidir. Bu nedenle adres için ayrıca rıza istemek hem gereksiz hem de yanıltıcıdır; kullanıcı rızayı geri çekerse siparişi teslim edemezsiniz.

Öte yandan pazarlama amaçlı profil çıkarma, başka şirketlerle reklam amaçlı veri paylaşımı ve zorunlu olmayan analitik gibi işlemler çoğu zaman sözleşmenin gereği değildir. Bu işlemler için genellikle ayrı açık rıza gerekir. Ancak hangi işlemin hangi şarta dayanacağı somut olaya göre değişir. Dolayısıyla son kararı hukuk danışmanınızla verin; geliştirme ekibi ise bu kararı ekran ve kod düzeyinde uygular.

Kural olarak şunu akılda tutun: zorunlu olmayan bir işlemi "rıza vermezsen uygulamayı kullanamazsın" koşuluna bağlamak, rızanın özgürlüğünü zedeler.

Hangi veriyi hangi dayanakla işlersiniz? Örnek eşleştirme tablosu

Aşağıdaki tablo, sipariş alan bir uygulama için hazırladığımız örnek senaryodur. Kesin bir hukuki görüş değildir; kendi işleme faaliyetlerinize göre uyarlamanız gerekir.

Tablonun asıl faydası, ekibin her yeni özellikte aynı soruları sormasını sağlamasıdır. Yeni bir veri alanı eklerken bu tabloya bir satır ekleyin; satırı dolduramıyorsanız o veriyi henüz toplamayın.

Konum, kamera ve rehber iznini nasıl gerekçelendirirsiniz?

İşletim sistemi izni ile KVKK rızası aynı şey değildir. İzin penceresi, uygulamanın cihaz kaynağına teknik erişimini açar. KVKK ise o veriyi hangi amaçla ve hangi dayanakla işlediğinizi sorar. Bu yüzden iki katmanı birlikte düşünürsünüz.

Apple, 5.1.1 maddesinde izin açıklama metinlerinin (purpose string) veri kullanımını açık ve eksiksiz anlatmasını istiyor. Ayrıca uygulamanın yalnız temel işleviyle ilgili verilere erişim istemesini, mümkünse fotoğraf ve rehber için tüm arşive erişim yerine sistemin seçici penceresini kullanmasını öneriyor.

İyi bir gerekçe metni üç soruya cevap verir:

• Hangi veri? Örneğin "konumunuz".
• Hangi özellik için? Örneğin "size en yakın şubeyi göstermek için".
• Ne zaman? Örneğin "yalnız uygulamayı kullanırken".

"Daha iyi bir deneyim için konumunuza ihtiyacımız var" gibi genel bir cümle bu soruların hiçbirini yanıtlamaz. Rehber erişiminde ise dikkatli olun: rehberdeki kişiler sizin kullanıcınız değildir ve size hiç bilgi vermemişlerdir. Bu nedenle tüm rehberi sunucuya yüklemek yerine, kullanıcının tek bir kişiyi seçmesine izin veren sistem seçicisini tercih edin.

İzin isteğini ne zaman göstermelisiniz?

İzin isteğini, kullanıcı o izne ihtiyaç duyan özelliğe dokunduğu anda gösterin. Android geliştirici belgeleri de çalışma zamanı izinleri sayfasında izni bağlam içinde, kullanıcı ilgili özellikle etkileşime başladığında istemeyi öneriyor.

Uygulama ilk açıldığında art arda konum, kamera, bildirim ve rehber pencereleri çıkarmak hem kötü bir deneyimdir hem de veri minimizasyonu ilkesine aykırı bir görüntü verir. Önerdiğimiz sıra şu:

1. Kullanıcı özelliği seçer, örneğin "Fiş tara" düğmesine basar.
2. Uygulama kendi ekranında kısa bir açıklama gösterir: neden kamera, hangi görüntüyü tutacak, görüntüyü nerede saklayacak.
3. Açıklamada "Şimdi değil" seçeneği de yer alır.
4. Kullanıcı devam ederse işletim sistemi kendi izin penceresini açar.
5. Uygulama sonucu kaydeder ve izin verilmezse alternatif yolu sunar.

Bildirim izni için de aynı mantık geçerlidir. Ayrıntılar için push bildirim izni ne zaman istenmeli yazımıza bakabilirsiniz. Bu akışı sıfırdan kurmak istiyorsanız, mobil uygulama geliştirme hizmetimizde uygulamanızı biz geliştiriyor, izin akışlarını tasarımdan itibaren planlıyor ve mağazaya biz çıkarıyoruz.

Kullanıcı izni reddederse uygulama ne yapmalı?

Reddedilen izin, uygulamanın çökmesi ya da kilitlenmesi için bir sebep olmamalı. Apple yönergeleri, konum paylaşmayan kullanıcıya adresi elle girme imkânı gibi alternatifler sunmanızı öneriyor. Ayrıca kullanıcıyı gereksiz veri erişimine kandırmaya, zorlamaya veya manipüle etmeye çalışmamanızı açıkça istiyor.

Android belgeleri de aynı yönde: izin reddedilirse işlev kaybını en aza indirin, kullanıcı arayüzünü engellemeyin ve kullanıcıyı sürekli ikna etmeye çalışmayın. Üstelik Android'de kullanıcı aynı izni birden fazla kez reddederse sistem penceresi artık görünmeyebilir. Dolayısıyla izni yanlış anda istemek, o özelliği kalıcı olarak kaybetmenize yol açabilir.

Örnek senaryo: bir kurye takip uygulamasında kullanıcı konum iznini vermiyor. İyi kurgu, haritayı boş bırakmak yerine adres arama kutusunu öne çıkarır. Kullanıcı daha sonra ayarlardan izni açarsa uygulama bunu fark eder ve haritayı gösterir. Böylece KVKK açısından da temiz bir tablo oluşur: rıza vermeyen kişi hizmetin dışında kalmaz, yalnız o özelliğin konuma bağlı kısmından yararlanmaz.

Üçüncü taraf SDK'lar KVKK açısından neden risklidir?

SDK (yazılım geliştirme kiti), uygulamanıza eklediğiniz hazır kod paketidir: analitik, reklam, çökme raporlama, sosyal giriş, harita, ödeme. Her biri kendi başına veri toplayabilir ve bu verileri kendi sunucularına gönderebilir. Kullanıcı açısından ise toplayan sizsiniz.

Apple bu konuda net: uygulamadaki tüm koddan, reklam ağları ve analitik hizmetleri dahil, geliştirici sorumludur. Google Play'in Kullanıcı Verileri politikası da uygulamanızdaki üçüncü taraf kodun Play politikalarına uymasını sağlamanızı ve SDK sağlayıcılarınızın kişisel ve hassas kullanıcı verisini satmamasını güvence altına almanızı istiyor.

Pratik bir SDK denetimi şöyle ilerler:

1. Uygulamadaki tüm SDK'ları ve sürümlerini listeleyin.
2. Her birinin topladığı veri türlerini sağlayıcının belgesinden çıkarın.
3. Verinin hangi ülkedeki sunuculara gittiğini not edin.
4. Rıza gerektiren SDK'ların rıza alınmadan başlamadığını test edin.
5. Kullanılmayan SDK'ları kaldırın.

Analitik tarafında hangi olayları ölçmeniz gerektiğini mobil uygulamada hangi olaylar ölçülmeli yazımızda anlattık. Ölçüm planını küçük tutmak, aynı zamanda topladığınız veriyi de küçültür.

Teknik olarak en sağlam yöntem, rıza gerektiren SDK'ları uygulamanın açılışında değil, rıza kaydını okuduktan sonra başlatmaktır. Ayrıca bazı SDK'lar varsayılan ayarlarında reklam kimliği gibi verileri kendiliğinden toplar. Bu nedenle sağlayıcının belgesindeki veri toplama ayarlarını tek tek gözden geçirin ve ihtiyacınız olmayanları kapatın. Böylece hem KVKK beyanınız hem de mağaza beyanlarınız gerçek davranışla örtüşür.

Reklam ve izleme için neden ayrı bir onay katmanı gerekir?

Çünkü iOS tarafında mağaza kuralı, KVKK'dan bağımsız olarak ayrı bir izin ister. Apple'ın kullanıcı gizliliği ve veri kullanımı sayfasına göre, uygulamanızdaki kullanıcı verisini başka şirketlerin uygulama veya siteleriyle hedefli reklam ya da reklam ölçümü için birleştirmek izleme kapsamına girer. Bunun için App Tracking Transparency (ATT, Uygulama İzleme Şeffaflığı) çerçevesiyle izin almanız gerekir.

Apple ayrıca bu izni teşvik karşılığı istemeyi veya bir özelliği izne bağlamayı kabul etmiyor. Sistem penceresinden önce kendi açıklama ekranınızı gösterebilirsiniz; ancak bu ekran veri kullanımını şeffaf anlatmalı ve kullanıcıyı yönlendirmemelidir.

Bu durumda iOS'ta reklam amaçlı izleme için iki kapı oluşur: ATT izni ve KVKK kapsamındaki açık rıza. Biri diğerinin yerine geçmez. Örneğin kullanıcı ATT'ye izin verdi diye pazarlama iletisi rızası da vermiş olmaz. Android'de ATT benzeri bir pencere olmasa da KVKK'daki rıza ihtiyacı aynen devam eder. Bu yüzden rıza yönetimini platformdan bağımsız, sunucuda kayıt tutan tek bir yapı olarak kurmanızı öneriyoruz.

Hesap silme özelliği KVKK ile nasıl kesişir?

Kanunun 7. maddesi, işleme sebebi ortadan kalkan verilerin resen veya ilgili kişinin talebi üzerine silinmesini, yok edilmesini ya da anonim hale getirilmesini ister. Mağazalar ise bunu somut bir ürün şartına çeviriyor.

Apple, 5.1.1(v) maddesinde hesap oluşturmayı destekleyen uygulamaların hesap silmeyi de uygulama içinden sunmasını şart koşuyor. Konuyu ayrıntılı olarak Apple'ın zorunlu hesap silme kuralı yazımızda anlattık. Google Play de hesap silmenin uygulama içinden kolay bulunabilir olmasını ve ayrıca uygulama dışından, örneğin bir web adresinden başlatılabilmesini istiyor. Play'e göre hesabı geçici olarak dondurmak veya devre dışı bırakmak hesap silme sayılmıyor.

KVKK açısından burada dikkat etmeniz gereken nokta saklama zorunluluklarıdır. Fatura gibi bazı kayıtları başka kanunlar gereği bir süre tutmanız gerekebilir. Bu durumda hesabı silersiniz, yasal olarak tutmanız gereken kayıtları ayırır, erişimi kısıtlar ve süre dolunca bu kayıtları da imha edersiniz. Google Play de güvenlik veya mevzuat gereği tuttuğunuz verileri gizlilik politikasında açıklamanızı istiyor.

Yurt dışına veri aktarımı mobil uygulamada nasıl ortaya çıkar?

Çoğu ekip yurt dışı aktarımı yalnız "sunucumuz yurt dışında mı?" sorusuyla ele alır. Oysa mobil uygulamada aktarım çok daha sessiz gerçekleşir: bulut barındırma, analitik SDK'sı, çökme raporlama, e-posta gönderim servisi, bildirim altyapısı ve müşteri destek araçları verileri farklı ülkelerdeki sunuculara taşıyabilir.

Kanunun 9. maddesi, aktarım için önce yeterlilik kararını, yeterlilik kararı yoksa uygun güvenceleri arar. Uygun güvencelerden biri, Kurulun ilan ettiği standart sözleşmedir; kanun bu sözleşmenin imzalandıktan sonra belirli bir süre içinde Kuruma bildirilmesini öngörür. Arızi aktarımlar için ise ayrı ve dar istisnalar yer alır. Süreler ve usuller değişebileceği için güncel hükmü resmi metinden ve Kurumun duyurularından kontrol edin.

Uygulama tarafında yapmanız gerekenler ise şunlardır:

• Her servis sağlayıcının veriyi hangi bölgede işlediğini öğrenin.
• Mümkünse veri bölgesi seçebilen servisleri tercih edin.
• Aydınlatma metninde aktarımın amacını ve alıcı gruplarını belirtin.
• Servis sağlayıcılarla yaptığınız sözleşmeleri hukuk danışmanınıza inceletin.

Apple ve Google mağaza kuralları sizden ne istiyor?

KVKK Türkiye'deki hukuki çerçeveyi çizer; mağazalar ise yayın koşullarını belirler. İkisi çoğu noktada örtüşür ama aynı değildir. Mağaza incelemesini geçmek KVKK uyumu anlamına gelmez; tersi de doğrudur.

Apple tarafında öne çıkan beklentiler şunlar: uygulama içinde ve App Store Connect'te gizlilik politikası bağlantısı, veri toplamaya rıza, rızayı geri çekmenin kolay bir yolu, veri minimizasyonu, izin ayarlarına saygı, uygulama içi hesap silme ve izleme için ATT. Ayrıca her yeni sürümde gizlilik uygulamalarınızı App Store Connect'te beyan etmeniz gerekiyor. Bu beyanı nasıl hazırlayacağınızı App Store gizlilik etiketleri yazımızda anlattık.

Google Play tarafında ise gizlilik politikası, beklenmeyen veri erişimi için uygulama içi belirgin açıklama (prominent disclosure), açık bir eylemle verilen onay, hesap silme ve SDK sorumluluğu öne çıkıyor. Play, kullanıcının açıklama ekranından geri tuşuyla ya da başka bir yere dokunarak çıkmasını onay saymıyor. Veri güvenliği bölümünü doldururken Google Play veri güvenliği formu rehberimiz işinizi kolaylaştırır.

Mobil uygulamada KVKK kontrol listesi: yayından önce neleri doğrulamalısınız?

Aşağıdaki listeyi her büyük sürümden önce ekibinizle birlikte gözden geçirin. Bir madde "bilmiyoruz" ile cevaplanıyorsa, o madde açık iştir.

1. Veri envanteri güncel mi, her veri bir amaca bağlı mı?
2. Her işleme faaliyeti için hukuki sebebi belirlediniz mi?
3. Aydınlatma metni kayıttan önce ekrana geliyor ve ayarlarda duruyor mu?
4. Açık rıza konuları ayrı ve varsayılanı boş seçenekler mi?
5. Rıza vermeyen kullanıcı temel hizmeti kullanabiliyor mu?
6. Rızayı geri çekmek, vermek kadar kolay mı?
7. Her izin isteği bağlam içinde ve açıklamalı mı?
8. İzin reddinde alternatif yol çalışıyor mu?
9. Tüm SDK'ları listelediniz mi, rıza gerektirenler rızadan önce başlamıyor mu?
10. Uygulama içi hesap silme ve web üzerinden silme talebi çalışıyor mu?
11. Yurt dışı aktarım yapan servisler ve dayanakları belli mi?
12. Mağaza beyanları (gizlilik etiketi, veri güvenliği) uygulamanın gerçek davranışıyla örtüşüyor mu?

Ayrıca son maddeyi teknik olarak test edin. Uygulamanın ağ trafiğini bir test cihazında izlemek, beyan ettiğinizle gerçekte gönderilen veriyi karşılaştırmanın en sağlam yoludur.

Mobil uygulamada KVKK konusunda en sık hangi hataları görüyoruz?

Sahada en sık karşılaştığımız hatalar teknik değil, kurgu hatalarıdır. Örnek senaryolar üzerinden özetleyelim:

• Web sitesinin aydınlatma metnini olduğu gibi uygulamaya kopyalamak. Oysa uygulama konum, kamera ve bildirim jetonu gibi sitede olmayan verileri işler.
• Tüm onayları tek kutuya toplamak ve kutuyu zorunlu yapmak.
• Analitik ve reklam SDK'larını rızadan önce, uygulamanın ilk saniyesinde başlatmak.
• İzinleri ilk açılışta topluca istemek.
• Hesap silme düğmesini yalnız bir e-posta adresine yönlendirmek.
• Rızayı geri çekme seçeneği sunmamak ya da onu derinlere gömmek.
• Mağaza beyanlarını bir kez doldurup SDK eklendikçe güncellememek.

Bu hataların ortak noktası, uyumun geliştirme bittikten sonra düşünülmesidir. Bu yüzden veri kararlarını tasarım aşamasına taşımak, sonradan yapılan düzeltmelerden çok daha ucuzdur. Web tarafındaki benzer hatalar için KVKK ve GDPR uyumlu web sitesi rehberimize de göz atabilirsiniz.

Rızayı geri çekme ve ilgili kişi başvurularını nasıl yönetirsiniz?

Kanunun 11. maddesi kullanıcıya bir dizi hak tanır: verisinin işlenip işlenmediğini öğrenme, bilgi talep etme, işleme amacını öğrenme, aktarıldığı üçüncü kişileri bilme, düzeltme ve silme isteme ile itiraz etme bunlardan bazılarıdır. Apple da rızayı geri çekmenin kolay ve anlaşılır bir yolunu istiyor.

Uygulamada bunu iki parçaya bölmenizi öneriyoruz. Birinci parça, ayarlardaki "İzinlerim" ekranıdır. Kullanıcı burada pazarlama, kişiye özel reklam ve isteğe bağlı analitik gibi rızalarını tek dokunuşla açıp kapatır. İkinci parça ise başvuru kanalıdır: kullanıcı verisinin bir kopyasını isteyebilir, düzeltme ya da silme talep edebilir.

Teknik olarak dikkat etmeniz gereken nokta, rıza değişikliğinin yalnız cihazda kalmamasıdır. Kullanıcı rızasını geri çektiğinde sunucudaki rıza kaydını güncellemeli, pazarlama listelerini ve reklam kitlelerini bu kayda göre ayıklamalısınız. Ayrıca her rıza işlemini tarih, sürüm ve kanal bilgisiyle saklayın. Böylece bir şikâyet ya da denetim durumunda kimin neye, hangi metni görerek onay verdiğini gösterebilirsiniz.

Uygulama mağazadan kaldırılırsa ne olur?

Gizlilik kurallarına aykırılık, mağaza tarafında uygulamanın reddedilmesine ya da yayından kaldırılmasına yol açabilir. En sık görülen sebepler eksik gizlilik politikası bağlantısı, beyanla örtüşmeyen veri toplama, belirgin açıklama olmadan hassas izin kullanımı ve eksik hesap silme akışıdır.

Böyle bir durumda paniğe kapılmadan önce mağazanın gönderdiği bildirimi dikkatle okuyun. Bildirim genellikle hangi politika maddesine atıf yaptığını belirtir. Ardından uygulamanın gerçek davranışını beyanlarınızla karşılaştırın, eksik akışı düzeltin ve yeni sürümü gönderin. İtiraz süreci için Google Play uygulama kaldırıldı yazımızda adım adım bir yol haritası paylaştık.

Ancak şunu unutmayın: mağaza sorunu çözülse bile KVKK yükümlülükleri ayrı bir başlıktır. Mağaza incelemesinden geçen bir uygulama, yine de kullanıcı şikâyeti veya Kurul incelemesiyle karşılaşabilir. Bu nedenle iki taraftaki düzeltmeyi birlikte planlayın.

Geliştirme ekibine hangi soruları sormalısınız?

Uygulamanızı bir ajansa ya da serbest geliştiriciye yaptırıyorsanız, KVKK uyumunu sözleşmeye ve teklif kapsamına yazdırın. Aksi halde bu işler "kapsam dışı" kalır. Teklif aşamasında şu soruları sorun:

1. Veri envanterini kim çıkaracak ve hangi aşamada?
2. Rıza yönetimi ekranı ve sunucu tarafı kayıt kapsamda mı?
3. Hangi SDK'ları kullanacaksınız ve her birinin veri akışını nasıl belgeleyeceksiniz?
4. Hesap silme hem uygulama içinden hem webden çalışacak mı?
5. Sunucular ve servisler hangi bölgede olacak?
6. Mağaza gizlilik beyanlarını kim hazırlayacak?

Kaynak kodun ve hesapların mülkiyeti de bu konuşmanın parçasıdır; ayrıntıları mobil uygulamanın kaynak kodu kime ait yazımızda bulabilirsiniz. Bu soruların cevabını tek elden almak isterseniz, mobil uygulama geliştirme ekibimizden teklif alın: uygulamanızı biz geliştirir, mağazaya biz çıkarırız; aydınlatma ve rıza ekranlarını, izin akışlarını ve hesap silmeyi baştan kapsama dahil ederiz. Metinlerin hukuki son kontrolünü ise sizin hukuk danışmanınızla birlikte yaparız.

Mobil uygulamada KVKK uyumunu nasıl sürdürürsünüz?

Uyum, yayın günü tamamlanan bir iş değildir. Her yeni özellik, her yeni SDK ve her servis sağlayıcı değişikliği veri envanterinizi değiştirir. Dolayısıyla süreci sürüm döngünüze bağlamanız gerekir.

Önerdiğimiz düzen basit:

• Her özellik talebinde "yeni veri topluyor mu?" sorusunu zorunlu alan yapın.
• Her sürümden önce SDK listesini ve mağaza beyanlarını karşılaştırın.
• Aydınlatma metnine bir sürüm numarası verin ve değişiklik geçmişini tutun.
• Yılda en az bir kez bütün akışı bir test cihazında baştan sona deneyin.

Kısacası mobil uygulamada KVKK uyumu, ekran tasarımı, kod ve hukuk metninin aynı masada konuşulmasıyla mümkün olur. Bu düzeni bir kez kurarsanız, mağaza incelemeleri de, kullanıcı başvuruları da öngörülebilir hale gelir. Son olarak hatırlatalım: bu rehber genel bilgilendirmedir; kendi uygulamanız için hukuki görüşü bir uzmandan alın.