Tasarımdan Gizlilik (Privacy by Design): Yazılım Ekipleri İçin Uygulama Rehberi

Sonradan Eklenen Gizlilik Pahalıdır

Canlıya alınmış bir üründe “bu alanı neden topluyoruz?” sorusu sorulduğunda, cevabı bulmak çoğu zaman haftalar sürer: veri tabanı şeması, raporlar, entegrasyonlar ve yedekler o alana göre kurulmuştur. Privacy by design yaklaşımı, bu soruyu kod yazılmadan önce sormayı önerir. Böylece gizlilik, bir uyum projesi değil geliştirme sürecinin sıradan bir adımı haline gelir.

Bu rehberde temel ilkeleri, gereksinim aşamasında veri analizini, varsayılan ayarlar ve veri minimizasyonunu, kod incelemesi ile testi ve sürüm notlarında gizliliği adım adım ele alıyoruz. Yazının sonundaki kontrol listesini sprint süreçlerinize doğrudan uyarlayabilirsiniz.

Tasarımdan Gizliliğin İlkeleri

Tasarımdan gizlilik kavramı 1990'larda Kanada'da, Ontario Bilgi ve Gizlilik Komiserliği bünyesinde geliştirilmiş ve yedi temel ilkeyle tanımlanmıştır. Avrupa Birliği Genel Veri Koruma Tüzüğü (GDPR) ise bu yaklaşımı 25. maddesinde “tasarım yoluyla ve varsayılan olarak veri koruma” başlığıyla bağlayıcı bir yükümlülüğe dönüştürmüştür.

Önleyici olmak: Sorun ortaya çıktıktan sonra düzeltmek yerine riski baştan öngörmek.

Varsayılan olarak gizlilik: Kullanıcı hiçbir ayar değiştirmese bile verisinin korunuyor olması.

Tasarıma gömülü gizlilik: Gizliliğin mimarinin parçası olması, sonradan eklenen bir katman olmaması.

Tam işlevsellik: Gizlilik ile işlevsellik arasında sıfır toplamlı bir seçim yapmamak.

Uçtan uca güvenlik: Verinin toplanmasından imhasına kadar tüm yaşam döngüsünün korunması.

Görünürlük ve şeffaflık: Verinin nasıl işlendiğinin doğrulanabilir ve açıklanabilir olması.

Kullanıcıya saygı: Kullanıcı çıkarlarını merkeze alan tasarım.

KVKK'da “tasarımdan gizlilik” başlıklı ayrı bir madde yoktur. Ancak 6698 sayılı Kanun'un 4. maddesindeki genel ilkeler (belirli, açık ve meşru amaç; amaçla bağlantılı, sınırlı ve ölçülü olma; gerekli süre kadar muhafaza) ve 12. maddedeki veri güvenliği yükümlülüğü, uygulamada ancak tasarım aşamasında düşünüldüğünde karşılanabilir. Kişisel Verileri Koruma Kurumu da yapay zekâ alanındaki tavsiyelerinde sistemlerin tasarımdan itibaren veri koruma ilkesine göre geliştirilmesini ve yönetilmesini açıkça önermektedir. Kişisel Veri Güvenliği Rehberi ise yeni sistemlerin tedariği ve geliştirilmesinde güvenlik gereksinimlerinin baştan göz önüne alınmasını ister.

Gereksinim Aşamasında Veri Analizi

Tasarımdan gizliliğin en ucuz uygulandığı an, bir özelliğin kullanıcı hikâyesi yazılırken gelir. Her yeni özellik için kısa bir veri analizi, sonradan yapılacak büyük düzeltmelerin önüne geçer. Bu analizde yanıtlanacak sorular şunlardır:

Hangi veri?: Özellik hangi kişisel veri alanlarını topluyor, üretiyor veya kullanıyor? Aralarında özel nitelikli kişisel veri var mı?

Neden?: Her alan hangi amaca hizmet ediyor? Amaç olmadan toplanan alan listeden çıkarılır.

Hangi hukuki sebep?: Sözleşmenin ifası, hukuki yükümlülük, meşru menfaat veya açık rıza; ürün ekibinin tek başına karar vermemesi, KVKK sorumlusuna danışması gereken nokta budur.

Nereye gidiyor?: Veri hangi servislere, üçüncü taraf API'lere veya yurt dışındaki altyapıya aktarılıyor?

Ne kadar süre?: Veri ne zaman silinecek veya anonimleştirilecek; bu kural kodda nasıl uygulanacak?

Kim görecek?: Hangi roller veriye erişecek; destek ekibi maskelenmiş görünüm mü kullanacak?

Bu soruların cevabı, özelliğin kabul kriterlerine eklenmelidir. Böylece “gizlilik gereksinimi” de test edilebilir bir kabul kriteri olur. Yüksek riskli işlemelerde (yoğun profilleme, özel nitelikli veri, yeni teknoloji) bu kısa analiz daha kapsamlı bir etki değerlendirmesine dönüştürülmelidir. Yurt dışındaki bulut ve API hizmetleri için yurt dışına veri aktarımı rehberi yazımıza bakabilirsiniz.

Varsayılan Ayarlar ve Minimizasyon

GDPR'ın 25. maddesinin ikinci fıkrası, varsayılan olarak yalnızca her belirli amaç için gerekli olan kişisel verilerin işlenmesini ister ve bu yükümlülüğün toplanan verinin miktarı, işlemenin kapsamı, saklama süresi ve erişilebilirlik için geçerli olduğunu belirtir. Aynı mantık, KVKK'nın ölçülülük ilkesiyle de örtüşür. Yazılım ekipleri için bunun somut karşılıkları şunlardır:

Minimizasyonun teknik araçları da bu aşamada seçilmelidir: takma ad kullanımı (pseudonymization), alan düzeyinde şifreleme, toplama yerine türetilmiş veri (ör. doğum tarihi yerine “18 yaş üstü” bilgisi) ve analitikte kişi düzeyi yerine toplu metrikler.

Gizlilik Dostu Varsayılanlar

Kod İncelemesi ve Test

Gereksinimde alınan kararların koda doğru yansıdığını kod incelemesi ve testler doğrular. Mevcut kod inceleme şablonuna birkaç gizlilik sorusu eklemek, ayrı bir süreç kurmaktan çok daha etkilidir:

Loglama: Yeni kod kişisel veri, parola veya oturum anahtarı logluyor mu? Maskeleme kuralı uygulanmış mı?

Yeni alanlar: Veri tabanına eklenen alanlar veri envanterinde ve gereksinim analizinde yer alıyor mu?

Üçüncü taraf bileşenler: Eklenen kütüphane veya SDK veri topluyor ya da dışarı gönderiyor mu?

Erişim kontrolü: Uç noktalar yetki kontrolü yapıyor mu; bir kullanıcı kimliği değiştirilerek başka kullanıcının verisine erişilebiliyor mu?

Silme: Hesap silme veya saklama süresi dolduğunda veri tüm tablolardan, önbelleklerden ve arama dizinlerinden kalkıyor mu?

Test tarafında iki kural öne çıkar. Birincisi, test ve geliştirme ortamlarında gerçek müşteri verisi yerine sentetik veya maskelenmiş veri kullanmaktır. İkincisi, gizlilik gereksinimlerini otomatik testlere dönüştürmektir: örneğin log çıktısında e-posta kalıbı bulunursa başarısız olan bir test ya da silinen kullanıcının verisinin hiçbir uç noktadan dönmediğini doğrulayan bir entegrasyon testi. Loglardaki riskleri log maskeleme KVKK yazımızda, güvenlik testlerinin kapsamını ise sızma testi ve zafiyet taraması yazımızda ele aldık.

Sürüm Notlarında Gizlilik

Şeffaflık ilkesi yalnızca aydınlatma metinleriyle sınırlı değildir. Bir sürüm yeni bir veri alanı topluyor, yeni bir alt işleyen ekliyor veya verinin kullanım amacını değiştiriyorsa, bu değişiklik hem iç ekipler hem de gerekirse kullanıcılar için görünür olmalıdır.

İç sürüm notu: Her sürümde “kişisel veri etkisi” başlığı; yeni alanlar, yeni aktarımlar, değişen saklama süreleri ve kaldırılan veriler.

Uyum tetikleyicisi: Bu başlık doluysa KVKK sorumlusuna otomatik bildirim; aydınlatma metni, veri envanteri ve gerekiyorsa VERBİS kaydı güncellemesinin değerlendirilmesi.

Kullanıcıya bildirim: Veri işleme amacı veya kapsamı değişiyorsa kullanıcıya anlaşılır bir dille bildirim; açık rızaya dayanan işlemelerde gerekirse yeniden rıza.

Müşteriye bildirim: B2B yazılımlarda müşteri adına veri işleniyorsa, yeni alt işleyenler ve veri konumu değişiklikleri sözleşmedeki bildirim kurallarına göre müşteriye iletilir.

Bu disiplin, ISO/IEC 27701 gibi gizlilik yönetim sistemi standartlarında beklenen kayıt ve değişiklik yönetimi pratikleriyle de örtüşür. Standart hakkında bilgi için ISO 27701 danışmanlığı sayfasını inceleyebilirsiniz.

Kontrol Listesi (İndirilebilir)

Aşağıdaki liste, indirilebilir kontrol listesinin özetidir. Her maddeyi “Evet / Kısmen / Hayır” olarak işaretleyip eksikleri sprint planına ekleyebilirsiniz.

Liste bir hukuki değerlendirmenin yerini tutmaz; özellikle hukuki sebep ve yurt dışı aktarım soruları için KVKK sorumlusunun onayı alınmalıdır. Somut olay özelinde hukuki değerlendirme alınmalıdır.

Tasarımdan Gizlilik Kontrol Listesi Özeti

Sonuç ve Sonraki Adım

Privacy by design, yazılım ekiplerinden ayrı bir uyum projesi değil, mevcut geliştirme sürecine eklenen birkaç doğru soru ister: bu veriyi neden topluyoruz, varsayılan ayar ne olmalı, kod bu kararı doğru uyguluyor mu ve değişikliği kimlere bildirmeliyiz? KVKK'nın genel ilkeleri ve veri güvenliği yükümlülüğü, ancak bu sorular tasarım aşamasında sorulduğunda sürdürülebilir biçimde karşılanabilir.

İlk adım olarak bir sonraki sprintte tek bir özelliği bu kontrol listesiyle geliştirin ve ekibin geri bildirimine göre listeyi uyarlayın. Bilişim ve yazılım şirketlerine özgü diğer KVKK riskleri için sektör sayfamızı inceleyebilirsiniz.

Sık Sorulan Sorular