Mobil Uygulama Güvenliği ve KVKK: İşletme Rehberi
İşletme sahipleri için mobil uygulama güvenliği rehberi: KVKK'nın 2026 ceza tutarları, OWASP tabanlı teknik tedbirler ve ajansa sorulacak 12 kritik soru.
Mobil uygulama güvenliği Türkiye'de yasal bir yükümlülüktür: KVKK'nın 12. maddesi gereği gerekli teknik ve idari tedbirleri almayan veri sorumlularına 2026 yılında 256.357 TL ile 17.092.242 TL arasında idari para cezası kesilir. Sorumluluk, uygulamayı yaptıran işletmeye aittir; yazılım ajansına değil.
Bu cümle çoğu işletme sahibi için sürpriz olur. Uygulamayı bir ajansa yaptırırsınız, mağazaya yüklersiniz, işi bitmiş sayarsınız. Oysa KVKK karşısında "veri sorumlusu" sizsiniz: kullanıcı verisini toplama amacını ve yöntemini belirleyen taraf. Ajans, sözleşmeyle "veri işleyen" konumundadır ve sizin talimatınızla çalışır. Bu rehber, korkutmak için değil, mobil uygulama güvenliği konusunda doğru soruları sorabilmeniz için yazıldı. Aşağıda hem teknik tarafın karşılığını hem de 2026'da yürürlüğe giren yeni KVKK kurallarını bulacaksınız.
Yazıdaki hukuki başlıklar genel bilgilendirme amaçlıdır ve hukuki danışmanlık yerine geçmez. Kendi uygulamanızın veri envanteri için bir veri koruma danışmanıyla çalışmanızı öneririz.
İçindekiler
- Mobil uygulama güvenliği neden yasal bir yükümlülük?
- 2026'da mobil uygulamaları bekleyen tehditler
- Uygulamanız hangi kişisel verileri topluyor?
- Sekiz başlıkta mobil güvenlik mimarisi
- KVKK tarafında 2026'da değişen üç kural
- App Store ve Google Play ne istiyor?
- Veri ihlalinde 72 saat kuralı
- Ajansınıza sormanız gereken 12 güvenlik sorusu
- Güvenlik bütçesi ve zamanlama
- Sıkça Sorulan Sorular
Mobil uygulama güvenliği neden yasal bir yükümlülük?
6698 sayılı Kişisel Verilerin Korunması Kanunu'nun 12. maddesi, veri sorumlusuna üç görev yükler: kişisel verilerin hukuka aykırı işlenmesini önlemek, hukuka aykırı erişimi engellemek ve verilerin muhafazasını sağlamak. Kanun bunun için "uygun güvenlik düzeyini temin etmeye yönelik gerekli her türlü teknik ve idari tedbiri" ister. Yani şifreleme, erişim yetkisi ve log kaydı gibi konular teknik tercih değil, mevzuat konusudur.
Kurum bu tedbirleri Kişisel Veri Güvenliği Rehberi başlıklı yayınında ayrıntılandırır. Rehber; yetki matrisi, ağ güvenliği, veri maskeleme, yedekleme ve sızma testi gibi başlıkları tek tek sayar. Denetimde Kurul bu listeye bakar.
Tedbirsizliğin bedeli her yıl yeniden değerleme oranıyla artar. 2026 için oran %25,49 olarak belirlendi ve KVKK'nın yayımladığı idari para cezası tutarları şu bandlara ulaştı:
| Yükümlülük | 2026 alt sınır | 2026 üst sınır |
|---|---|---|
| Aydınlatma yükümlülüğü (m. 10) | 85.437 TL | 1.709.200 TL |
| Veri güvenliği yükümlülükleri (m. 12) | 256.357 TL | 17.092.242 TL |
| Kurul kararlarını yerine getirmeme (m. 15) | 427.263 TL | 17.092.242 TL |
| VERBİS kayıt ve bildirim (m. 16) | 341.809 TL | 17.092.242 TL |
| Yurt dışı aktarımda standart sözleşme bildirimi | 90.308 TL | 1.806.377 TL |
Sorumluluk zincirinin yazılı hale gelmesi de bu maddenin parçası. Ajansla aranızda bir veri işleyen sözleşmesi yoksa, Kurul karşısında "yazılımcı öyle yapmış" savunması işe yaramaz. Sözleşmede en az şu üç başlık bulunmalı: ajansın veriyi yalnızca sizin talimatınızla işleyeceği, alt yüklenici kullanımının izne bağlı olduğu ve proje bittiğinde test ortamlarındaki kişisel verilerin imha edileceği. Canlı veri tabanının bir kopyasının geliştirici bilgisayarında aylarca durması, denetimde en sık karşılaşılan bulgulardan biridir.
Tablodaki üst sınırlar teorik değildir; Kurul, ihlalden etkilenen kişi sayısına ve kusurun ağırlığına göre bandın üst tarafına çıkabilir. Bir uygulamada onlarca bin kullanıcı kaydı bulunduğunu düşünürseniz, orta ölçekli bir cezanın uygulamanın tüm geliştirme bütçesini aşması işten bile değildir.
2026'da mobil uygulamaları bekleyen tehditler
Rakamlar tabloyu net gösteriyor. Kaspersky'nin 2026 ikinci çeyrek mobil tehdit raporuna göre yalnızca üç ayda mobil cihazlarda 1.996.823 saldırı engellendi ve 304 binden fazla zararlı kurulum paketi tespit edildi. Bunların 93.574'ü mobil bankacılık truva atıydı; Trojan-Banker kategorisi %30,77 payla listenin başında yer aldı.
Saldırganların uygulamaya giriş yolu da değişti. Verizon'un 2026 Veri İhlali İnceleme Raporu, ihlallerin %31'inin zafiyet istismarıyla başladığını ve bu vektörün 19 yıl sonra ilk kez çalıntı kimlik bilgilerini geride bıraktığını ortaya koydu. Aynı raporda ihlallerin %48'inde üçüncü bir tarafın rol oynadığı, bu oranın bir önceki yıla göre %60 arttığı belirtiliyor. Uygulamanıza eklediğiniz her analytics, reklam veya chat SDK'sı bu istatistiğin parçası.
Maliyet tarafında IBM'in Cost of a Data Breach 2026 araştırması küresel ortalama ihlal maliyetini 4,99 milyon dolar olarak ölçtü; bu, bir önceki yıla göre %12'lik artışla rekor seviye. Türkiye'deki bir KOBİ için rakam elbette bu ölçekte olmaz, ancak ceza, müşteri kaybı, olay müdahalesi ve itibar onarımı kalemleri aynı sırayla işler.
Türkiye özelinde riski büyüten şey kullanım yoğunluğu. TÜİK'in 2026 Hanehalkı Bilişim Teknolojileri Kullanım Araştırması'na göre internet kullanım oranı %92,3'e, internetten alışveriş yapanların oranı %60'a çıktı. Kullanıcı tabanı genişledikçe, sızan tek bir veri tabanının etkilediği kişi sayısı da büyür.
Saldırı yüzeyinin nerede olduğunu doğru okumak da önemli. Mobil uygulama güvenliği tartışmalarında akla önce telefondaki uygulama gelse de, olayların büyük bölümü arka uçta yaşanır: korumasız bir API ucu, yetkisi geniş bir yönetim paneli ya da güncellenmemiş bir kütüphane. Uygulama mağazadan indirildiği anda saldırganın elinde de bir kopyası olur; istemci kodunu inceleyip API çağrılarını taklit etmek zor değildir. Bu yüzden ekipler istemci tarafındaki gizlemeye değil, sunucudaki yetkilendirmeye yatırım yapmalı.
Uygulamanız hangi kişisel verileri topluyor?
Güvenlik tartışması "hangi veriyi tutuyoruz" sorusuyla başlar. Çoğu ekip bu envanteri hiç çıkarmaz ve topladığından fazlasını sakladığını fark etmez. KVKK'nın veri minimizasyonu ilkesi tam da bunu hedefler: amaç için gerekmeyen veriyi toplamazsanız, korumanız gereken yüzey küçülür.
| Veri türü | Örnek | Hukuki hassasiyet |
|---|---|---|
| Kimlik ve iletişim | Ad soyad, telefon, e-posta | Genel nitelikli kişisel veri |
| Konum | GPS izi, adres, teslimat noktası | Genel, ancak sürekli takipte risk yüksek |
| Sağlık ve biyometri | Randevu notu, parmak izi, yüz verisi | Özel nitelikli; ayrı ve açık rıza gerekir |
| Finansal | Kart, IBAN, sipariş geçmişi | Dolandırıcılık hedefi; saklama süresi kritik |
| Cihaz kimlikleri | IDFA, GAID, reklam kimliği | Kişisel veri sayılır; izinsiz izleme yasak |
| Kullanım verisi | Ekran akışı, oturum süresi | Anonimleştirilmezse kişisel veriye dönüşür |
Özel nitelikli veriler ayrı bir kategori. Sağlık, biyometrik ve din bilgisi gibi veriler için kanun daha ağır koşullar arar; bunları işleyen bir randevu ya da fitness uygulaması, standart bir haber uygulamasıyla aynı güvenlik seviyesinde kalamaz. Sağlık verisi işleyen bir işletmeyseniz, online randevu sistemi rehberimizdeki KVKK bölümü bu ayrımı sektörel örneklerle açıklıyor.
Pratik kural şu: her veri alanı için "bu alanı silsem hangi özellik bozulur?" sorusunu sorun. Cevap "hiçbiri" ise, o alan veri tabanında durmamalı.
Envanteri çıkarmak sanıldığı kadar uzun sürmez. Bir tablo açın; her satıra bir veri alanı yazın ve yanına dört sütun ekleyin: hangi ekranda toplanıyor, hangi amaçla işleniyor, nerede saklanıyor, ne kadar süre tutuluyor. Geliştirici ekiple yarım günlük bir oturumda çoğu uygulamanın envanteri tamamlanır. Bu tablo sonradan hem VERBİS kaydınızın hem aydınlatma metninizin hem de mağaza beyanlarınızın kaynağı olur; üç belgeyi de aynı listeden üretince aralarındaki çelişki riski ortadan kalkar.
Saklama süresi de en az veri türü kadar önemli. "Belki lazım olur" diye tutulan üç yıllık konum geçmişi, ihlal anında zarar katsayısını doğrudan büyütür. Her veri alanı için bir imha süresi belirleyin ve bu süreyi otomatik çalışan bir işle uygulayın; elle silme sözü, denetimde kanıt değeri taşımaz.
Sekiz başlıkta mobil güvenlik mimarisi
Sektörün ortak dili OWASP Mobile Application Security Verification Standard (MASVS). Standart, mobil güvenliği sekiz kategoriye ayırır ve her kategori için doğrulanabilir kontroller tanımlar. Ajansınızın teslimatını bu sekiz başlık üzerinden değerlendirmek, mobil uygulama güvenliği için "güvenli mi?" sorusuna somut cevap almanın en hızlı yoludur.
| MASVS kategorisi | Pratikte ne demek | KVKK karşılığı |
|---|---|---|
| STORAGE | Token ve kişisel veri Keychain/Keystore'da şifreli durur | Muhafaza tedbiri (m. 12/1-c) |
| CRYPTO | AES-256 gibi standart algoritmalar, anahtar cihazda güvenli saklanır | Şifreleme tedbiri |
| AUTH | Oturum süresi, çok faktörlü doğrulama, güvenli çıkış | Yetkisiz erişimin önlenmesi |
| NETWORK | Güncel TLS, sertifika doğrulama, düz metin trafik yok | Aktarımda güvenlik |
| PLATFORM | İzinler asgari, ekran görüntüsü ve pano koruması | Amaçla sınırlılık |
| CODE | Bağımlılık taraması, girdi doğrulama, güncel kütüphaneler | Yazılım güncelliği |
| RESILIENCE | Kök/jailbreak tespiti, kod karartma, kurcalama kontrolü | Erişim güvenliği |
| PRIVACY | Veri minimizasyonu, şeffaf izin akışı, silme hakkı | Aydınlatma ve ilgili kişi hakları |
Bu kategorilerin arkasındaki en yaygın hatalar OWASP Mobile Top 10 listesinde toplanır. Listenin ilk sırasında "uygunsuz kimlik bilgisi kullanımı" yer alır: API anahtarının koda gömülmesi, sunucu parolasının uygulama paketinde taşınması gibi klasikler. İkinci sırada ise tedarik zinciri güvenliği bulunur; yani üçüncü taraf kütüphaneler.
Dört teknik detayı özellikle takip edin. Birincisi, oturum jetonu asla düz metin olarak saklanmamalı; Android tarafında bunun karşılığı Keystore ve şifreli tercih dosyaları, iOS tarafında Keychain'dir. Android güvenlik kontrol listesi bu ayrımı örneklerle gösterir. İkincisi, tüm trafik güncel TLS üzerinden akmalı ve sertifika doğrulaması kapatılmamalı. Üçüncüsü, yetki kontrolü sunucuda yapılmalı; istemcide gizlenen bir menü güvenlik önlemi sayılmaz. Dördüncüsü, kurcalanmış kopyalara karşı Play Integrity API gibi bir çalışma zamanı doğrulaması devreye alınmalı.
Arka uç tarafında iki kural öne çıkar. Birincisi, her API ucu kendi yetki kontrolünü kendisi yapmalı; "bu ekranı zaten sadece yöneticiler görüyor" varsayımı, uç noktayı doğrudan çağıran bir saldırgan karşısında hiçbir şey ifade etmez. İkincisi, istek sınırlama ve anormallik tespiti devrede olmalı. Saniyede yüzlerce doğrulama denemesi yapan bir istemciyi durduran basit bir kural, kimlik bilgisi doldurma saldırılarının çoğunu daha başlarken keser. Kayıt tutma da bu başlığın parçası: kim, ne zaman, hangi veriye erişti sorusunun cevabını veremiyorsanız, ihlal sonrası bildirimi doğru hazırlamanız da mümkün olmaz.
Üçüncü taraf kütüphaneler ise mobil uygulama güvenliğinin en çok ihmal edilen tarafı. Ortalama bir uygulama; analytics, çökme raporlama, reklam, sohbet ve ödeme için beş ila on beş harici SDK taşır. Her biri ayrı bir şirketin kodudur, ayrı veri toplar ve ayrı bir güncelleme takvimiyle ilerler. Kullandığınız SDK listesini yazılı tutun, her sürümde bağımlılık taramasını çalıştırın ve artık kullanmadığınız kütüphaneleri paketten çıkarın. Kaldırılmayan tek bir eski reklam kütüphanesi, hem zafiyet hem de beyan etmediğiniz veri paylaşımı anlamına gelir.
Teknoloji seçiminin de payı var. Native, React Native ve Flutter kanadında güvenlik yaklaşımları farklılaşır; hangi mimarinin size uyduğunu React Native, Flutter ve native karşılaştırmamızda ayrıntılı ele aldık.
KVKK tarafında 2026'da değişen üç kural
2026, mevzuat tarafında hareketli bir yıl oldu. Üç gelişme doğrudan mobil uygulamaları ilgilendiriyor. Üçü de ürün tarafında somut karşılığı olan, birkaç günlük geliştirmeyle kapatabileceğiniz maddeler; ertelendiğinde ise doğrudan idari para cezası riski doğuruyor.
Aydınlatma metni ile açık rıza artık ayrı. Kurul'un 18.02.2026 tarihli ve 2026/347 sayılı ilke kararı, 24 Mart 2026 tarihli Resmî Gazete'de yayımlandı. Kurumun kamuoyu duyurusuna göre iki metin iç içe geçmiş biçimde, tek onay kutusuyla sunulamaz. "Okudum, anladım, kabul ediyorum" tarzı birleşik onaylar; başka bir kurumun metninin kopyalanması; belirsiz, aşırı uzun ve karmaşık metinler de kararda hatalı uygulama olarak sayıldı. Uygulamanızın kayıt ekranı tek bir onay kutusuyla ilerliyorsa, bu ekran yeniden tasarlanmalı.
Anlık bildirimlerde parçalı açık rıza şart. Kurum, 14 Ocak 2026'da mobil uygulamalar üzerinden gönderilen anlık bildirimlere ilişkin bir duyuru yayımladı. Duyuruya göre kargo bildirimi almak isteyen kullanıcıyı kampanya bildirimlerini de kabul etmeye zorlamak hukuka uygun değil. Her bildirim amacı için ayrı ve bağımsız seçim imkânı sunulmalı; uygulama mimarisi de bu tercihleri saklayacak şekilde kurgulanmalı. Bu, ürün ekibinin bir hafta içinde çözebileceği bir ayarlar ekranı meselesi. Bildirim tercihlerini kullanıcı profiline bağlayın ve tercih değişikliklerini tarih damgasıyla kaydedin; Kurul bir şikâyette rızanın ne zaman alındığını sorar.
Yurt dışına aktarımda bildirim süresi işliyor. Uygulamanız Firebase, AWS veya benzeri bir bulut hizmeti kullanıyorsa büyük olasılıkla kişisel veriyi yurt dışına aktarıyorsunuz. KVKK'nın yurt dışına aktarım sayfasında açıklanan standart sözleşme yolunu seçtiyseniz, imzaların tamamlanmasından itibaren beş iş günü içinde Kuruma bildirim yapmanız gerekir. Bildirimi atlamanın 2026 karşılığı 90.308 TL'den başlıyor.
App Store ve Google Play ne istiyor?
Mağazalar, mevzuattan bağımsız bir denetim katmanı kurar. Kuralları karşılamayan uygulama yayına giremez; giren de güncelleme aşamasında geri çevrilir.
Google Play tarafında zorunlu adım Veri güvenliği formu. Toplanan ve paylaşılan her veri türünü, amacını ve şifreleme durumunu bu formda beyan edersiniz; beyan mağaza sayfanızda kullanıcıya görünür. Eksik veya yanıltıcı beyan, uygulamanın kaldırılmasına kadar giden yaptırımlara yol açar. Ayrıca hassas izinler yalnızca temel işlev için istenebilir ve uygulama içinde belirgin bir bilgilendirme gerekir.
Apple tarafında iki ayrı yükümlülük var. Birincisi, mağaza sayfasında görünen uygulama gizlilik etiketleri; üçüncü taraf SDK'ların topladığı veriyi de kapsar. İkincisi, Mayıs 2024'ten bu yana zorunlu olan gizlilik bildirimi dosyaları ve belirli API'ler için gerekçe beyanı. App Store inceleme kılavuzu ayrıca hesap oluşturmaya izin veren her uygulamanın hesap silme akışını uygulama içinde sunmasını ister.
İki mağazanın ortak beklentisi şeffaflık. İstediğiniz her izin için "bu izin olmasa hangi özellik çalışmaz?" sorusuna tek cümlelik bir cevabınız olmalı ve bu cevabı izin isteminin hemen öncesinde kullanıcıya göstermelisiniz. Konum, kamera, kişiler ve arka plan erişimi gibi hassas izinlerde inceleme ekipleri bu gerekçeyi özellikle arar. Beyanınız ile uygulamanın gerçek davranışı arasındaki en küçük fark bile ret gerekçesi olur.
Red yeme ihtimalini düşürmek için yayın öncesi kontrol listemizi kullanabilirsiniz: uygulama yayın kontrol listesi gizlilik ve izin maddelerini adım adım işaretlemenizi sağlar. Sık karşılaşılan red gerekçelerini App Store uygulama reddi yazımızda, yayın sürecinin tamamını ise mobil uygulama nasıl yayınlanır rehberimizde bulabilirsiniz.
Veri ihlalinde 72 saat kuralı
Hazırlığın en çok işe yaradığı an, kötü haberin geldiği andır. Kurul'un 24 Ocak 2019 tarihli ve 2019/10 sayılı kararı gereği veri sorumlusu, ihlali öğrendiği andan itibaren en geç 72 saat içinde Kuruma bildirim yapar. Süreyi aşarsanız gecikmenin gerekçesini de ayrıca yazarsınız. İlgili kişilere makul en kısa sürede siz haber verirsiniz.
Bu süre içinde şu adımları tamamlamış olmanız beklenir:
- Sızıntının kaynağını izole edin ve etkilenen erişim anahtarlarını iptal edin.
- Hangi veri kategorilerinin, kaç kişiyi etkilediğini kayıt altına alın.
- Log kayıtlarını koruma altına alın; delil niteliği taşırlar.
- Kuruma Veri İhlali Bildirim Formu ile başvurun.
- Etkilenen kullanıcıları sade bir dille bilgilendirin ve alınan önlemleri anlatın.
- Kök neden analizini yazın ve aynı açığın tekrarını engelleyecek değişikliği planlayın.
Bu altı adımı bir sayfaya sığdırıp ekibin erişebileceği bir yerde tutun. Kriz anında kimse uzun bir prosedür belgesini açıp okumaz; işe yarayan şey, telefon numaralarını ve ilk üç hamleyi içeren tek sayfalık bir karttır.
Planın kâğıt üzerinde kalmaması için üç şeyi önceden netleştirin: olayı kimin yöneteceği, hangi telefon numaralarının mesai dışında da açık olacağı ve hangi kararı kimin verebileceği. Sunucu erişimi tek bir geliştiricide duruyorsa ve o kişiye ulaşamıyorsanız, 72 saatin ilk yarısı yalnızca birini bulmakla geçer. Mobil uygulama güvenliği, kriz anında teknik bilgi kadar organizasyon meselesidir.
72 saatlik süre, kimin arayacağını ve hangi log'a bakılacağını kriz anında öğrenmek için çok kısadır. Bu nedenle olay müdahale planını uygulama yayına çıkmadan yazın ve yılda bir kez tatbikatla deneyin.
Ajansınıza sormanız gereken 12 güvenlik sorusu
Mobil uygulama güvenliği konusunda teknik ekibi sınamanın en kolay yolu doğru soruları sormak. Cevapların netliği, ekibin bu konuyu daha önce çalışıp çalışmadığını hemen gösterir.
- Uygulama hangi kişisel verileri topluyor ve her biri hangi özellik için gerekli?
- Oturum jetonları cihazda nerede ve nasıl şifreli saklanıyor?
- API isteklerinde yetki kontrolü sunucu tarafında mı yapılıyor?
- Hangi üçüncü taraf SDK'lar kullanılıyor ve her biri hangi veriyi dışarı gönderiyor?
- Bağımlılıklar için otomatik zafiyet taraması CI sürecinde çalışıyor mu?
- Uygulama sırları ve anahtarlar depoda mı tutuluyor, yoksa gizli anahtar yönetimi var mı?
- Verinin yurt dışına aktarıldığı hizmetler hangileri ve hukuki dayanağı ne?
- Kullanıcı hesabını uygulama içinden silebiliyor mu, silinen veri ne kadar sürede yok ediliyor?
- Yayın öncesi sızma testi yapılacak mı, raporu bize teslim edilecek mi?
- Kritik bir açık çıkarsa yama kaç günde yayınlanır ve bu süre sözleşmede yazılı mı?
- Sunucu ve veri tabanı yedekleri şifreli mi, geri dönüş provası yapıldı mı?
- Veri ihlali durumunda ajansın bildirim ve destek sorumluluğu sözleşmede tanımlı mı?
Cevapları not alın ve teklif karşılaştırmasında yan yana koyun. Deneyimli bir ekip bu soruların çoğuna hazırlıksız yanıt verir; "sonra bakarız" diyen bir ekip ise büyük ihtimalle bu maddeleri projeye hiç eklemeyecektir. Sorulardan üçü veya dördü boşta kalıyorsa, bu bir ret gerekçesi değil ama sözleşmeye eklenmesi gereken bir kapsam açığıdır.
Son iki madde çoğu teklifte hiç geçmez. Sözleşmeye eklenmesini istemek, ilerideki en pahalı tartışmayı baştan çözer. Ajans seçimini genel kriterlerle değerlendirmek isterseniz mobil uygulama yapan firmalar rehberimiz karşılaştırma başlıklarını sıralıyor.
Güvenlik bütçesi ve zamanlama
Mobil uygulama güvenliği, projenin sonuna eklenen bir kalem olduğunda pahalıya patlar. Tasarım aşamasında alınan kararlar neredeyse bedavayken, yayından sonra aynı kararı uygulamak veri taşıma ve sürüm yönetimi maliyeti doğurur.
| Aşama | Yapılacak iş | Bütçeye etkisi |
|---|---|---|
| Analiz | Veri envanteri, minimizasyon kararları | Düşük; çoğunlukla zaman maliyeti |
| Tasarım | İzin akışı, ayrı aydınlatma ve rıza ekranları | Düşük; tasarım kalemi içinde |
| Geliştirme | Şifreli saklama, TLS, yetki kontrolü | Orta; geliştirme süresine eklenir |
| Yayın öncesi | Sızma testi ve düzeltme turu | Ayrı kalem; proje büyüklüğüne bağlı |
| Yayın sonrası | Bağımlılık güncellemesi, izleme, log saklama | Aylık bakım bütçesi içinde |
Sızma testi tarafında piyasa fiyat rehberleri, tek platform için birkaç bin dolarlık bandı; iOS, Android ve arka uç API'nin birlikte test edildiği kapsamlı çalışmalar içinse on binli dolar seviyelerini işaret ediyor. Türkiye'de çalışan ekiplerde bu rakamlar daha erişilebilir kalır, ancak testin kapsamı ve raporun tekrar testi içerip içermediği fiyattan önce netleşmelidir.
Bütçeyi ölçeklerken kullanıcı sayısına değil, veri hassasiyetine bakın. Yüz bin kişinin haber okuduğu bir uygulama ile beş bin kişinin sağlık kaydını tuttuğu bir uygulamada risk profili aynı değildir. Ödeme, sağlık ve kimlik verisi işleyen projelerde mobil uygulama güvenliği kalemini toplam geliştirme bütçesinin görünür bir yüzdesi olarak ayırın; içerik ağırlıklı projelerde ise temel tedbirler ve düzenli güncelleme çoğu zaman yeterli olur. Karar verirken şu eşiği kullanabilirsiniz: veri sızarsa kullanıcıya somut bir zarar veriyorsa, bağımsız test artık isteğe bağlı değildir.
Yayın sonrası giderleri planlarken güvenlik güncellemelerini de hesaba katın. Kütüphane güncellemesi, işletim sistemi uyumu ve sertifika yenilemesi düzenli işlerdir; bu kalemlerin tipik büyüklüğünü mobil uygulama bakım maliyeti yazımızda paylaştık.
Sıkça Sorulan Sorular
Mobil uygulama güvenliğinden kim sorumlu, ajans mı işletme mi?
KVKK karşısında sorumlu taraf veri sorumlusu sıfatını taşıyan işletmedir. Yazılım ajansı veri işleyen konumundadır ve sizin talimatınızla hareket eder. Ajansın kusuru varsa aranızdaki sözleşmeye göre rücu edebilirsiniz, ancak Kurul cezayı işletmeye keser.
KVKK'ya uymayan bir uygulamanın cezası ne kadar?
2026 yılında veri güvenliği yükümlülüklerini ihlal edenler için idari para cezası 256.357 TL ile 17.092.242 TL arasında değişir. Aydınlatma yükümlülüğü ihlallerinde bant 85.437 TL'den başlar. Tutarlar her yıl yeniden değerleme oranıyla güncellenir.
Küçük bir uygulama için sızma testi şart mı?
Kullanıcı hesabı, ödeme veya kişisel veri içeren her uygulamada yayın öncesi bağımsız bir test yaptırmanızı öneririz. Bütçe kısıtlıysa en azından kimlik doğrulama, ödeme akışı ve API yetkilendirmesini kapsayan dar kapsamlı bir test yaptırın; tüm uygulamayı taramak yerine riskli üç akışa odaklanmak çok daha ucuzdur.
Aydınlatma metni ile açık rıza metnini birleştirebilir miyim?
Hayır. Kurul'un 2026/347 sayılı ilke kararı, iki metnin iç içe geçmiş şekilde veya tek onayla sunulmasını hukuka aykırı sayar. İki metin ayrı başlıklarla düzenlenmeli, açık rıza yalnızca gerçekten gerekli olduğu hallerde ayrıca alınmalıdır.
Uygulamam Firebase kullanıyor, bu bir sorun mu?
Sorun değil, ancak bir yükümlülük doğurur. Firebase gibi hizmetler kişisel veriyi yurt dışında işler; bu aktarım için KVKK'nın öngördüğü yollardan birine dayanmanız gerekir. Standart sözleşme yolunu seçerseniz imzadan itibaren beş iş günü içinde Kuruma bildirim yaparsınız.
Uygulamada hesap silme özelliği zorunlu mu?
Evet. App Store inceleme kuralları, hesap oluşturmaya izin veren uygulamaların hesap silme akışını uygulama içinde sunmasını ister. KVKK tarafında da ilgili kişinin silme talebi bir hak olduğundan, bu akışı hem mağaza kuralı hem mevzuat gereği kurmanız gerekir.
Veri ihlalini fark ettim, ilk ne yapmalıyım?
Önce sızıntının kaynağını izole edip erişim anahtarlarını iptal edin, ardından etkilenen veri kategorilerini ve kişi sayısını tespit edin. Kuruma bildirim için elinizde ihlali öğrendiğiniz andan itibaren en geç 72 saat vardır; ilgili kişilere de makul en kısa sürede haber verilir.
Mobil uygulama güvenliği için hangi standardı takip etmeliyim?
Mobil uygulama güvenliği tarafında OWASP MASVS sekiz kategorili bir doğrulama standardı sunar ve mobil için sektörde en yaygın kabul gören referanstır. Yanına OWASP Mobile Top 10 listesini koyarak en sık görülen hataları da kontrol edebilirsiniz. KVKK tarafında ise Kurumun Kişisel Veri Güvenliği Rehberi'ndeki teknik ve idari tedbirler listesini esas alın.
Güvenlik, tek seferlik bir sertifika değil, ürünün yaşam döngüsüne yayılan bir alışkanlıktır. Veri envanterini çıkarmak, izin ekranlarını ayrıştırmak ve bağımlılıkları düzenli güncellemek gibi işler birkaç günlük emekle başlar; bunları erken yapan ekipler hem mağaza reddi hem de idari para cezası riskini büyük ölçüde geride bırakır.
Mevcut uygulamanızın nerede durduğunu merak ediyorsanız, yukarıdaki 12 soruyu geliştirici ekibinize iletmek iyi bir başlangıç olur. Yeni bir proje planlıyor ya da mevcut uygulamanızı güvenlik ve KVKK açısından gözden geçirmek istiyorsanız mobil uygulama geliştirme hizmetimizi inceleyebilir, ihtiyacınızı konuşmak için bizimle iletişime geçebilirsiniz.
Bu konuda profesyonel destek mi lazım?
Projenizi ekibimizle konuşun — aynı gün dönüş, ücretsiz teklif.


