10 yıldır yazılım geliştiren biri olarak şunu çok net öğrendim: “Sadece özellik geliştiriyoruz” sandığın bir iş, bir anda “kişisel veri” meselesine dönüşebiliyor. Bir form alanı, bir log kaydı, bir analytics etiketi, bir yedekleme dosyası… Hepsi bir anda hukuki sorumluluk doğuruyor. GDPR ve KVKK: Yazılımcıların Bilmesi Gerekenler başlığı bu yüzden teorik değil, günlük işimizin tam ortasında.
Bu yazıda sana net bir sözüm var. Kişisel veri koruma mevzuatının yazılım geliştirme süreçlerine etkileri ve uyumluluk gereksinimleri rehberi gibi ilerleyeceğiz. KVKK ve GDPR nedir? Yazılım projelerine etkileri neler, yazılım geliştirmede veri koruma uyumluluğu (privacy by design) nasıl sağlanır, gerçek projelerde kişisel veri işleme ve güvenlik best practices nelerdir, yazılım ekipleri için veri koruma uyumluluk checklist ve süreçleri nasıl kurulur? Hepsini sohbet eder gibi anlatacağım. Hukuki metin dili yerine, geliştiricinin anlayacağı pratik dil kullanacağım.
GDPR ve KVKK Nedir?
GDPR (General Data Protection Regulation) Tanımı
GDPR, Avrupa Birliği’nin kişisel verilerin korunmasına yönelik düzenlemesidir. AB’de yaşayan kişilerin verisini işleyen sistemleri etkiler. Yani şirketin nerede olduğu kadar, verisi işlenen kişinin nerede olduğu da önemlidir. Bu yüzden “biz Türkiye’deyiz, bizi ilgilendirmez” cümlesi bazen yanlış çıkar.
KVKK (6698 Sayılı Kişisel Verilerin Korunması Kanunu) Tanımı
KVKK, Türkiye’de kişisel verilerin korunmasını düzenleyen kanundur. Türkiye’de faaliyet gösteren birçok yazılım projesi için temel çerçeveyi belirler. KVKK, veri işleyen her ekibin süreçlerini etkileyecek kadar geniş bir kapsama sahiptir.
GDPR ve KVKK’nın Ortaya Çıkış Amacı
Amaç basit: kişisel verinin kontrolünü bireye vermek ve kurumların veri işleme süreçlerine düzen getirmek. “Veriyi topladım, istediğim gibi kullanırım” dönemi bitti. Artık “neden topladın, ne kadar sakladın, nasıl korudun” soruları var.
Kimleri Kapsar?
Genel kural şu: kişisel veriyi işleyen herkesi. Bir uygulama geliştiriyorsan, bir CRM yazıyorsan, bir e-ticaret altyapısı kuruyorsan, hatta basit bir üyelik sistemi yapıyorsan bile kapsama girebilirsin. Kod yazmak çoğu zaman veri işlemek demektir.
Kişisel Veri Kavramı
Kişisel Veri Nedir?
Kişisel veri, kimliği belirli veya belirlenebilir gerçek kişiye ilişkin her türlü bilgidir. İsim, telefon, e-posta klasik örnekler. Ama tek başına isim olmasa bile, bir kişiyi tanımlamaya yarayan kombinasyonlar da kişisel veri sayılabilir.
Özel Nitelikli Kişisel Veriler
Sağlık verisi, biyometrik veri, dini inanç, siyasi görüş gibi daha hassas veriler özel nitelikli sayılır. Bu verilerde koruma ve işleme şartları daha sıkıdır. Yazılım tarafında en küçük hata bile daha büyük risk doğurabilir.
Anonim, Pseudonym ve Maskelenmiş Veri
Anonim veri, kişiye geri döndürülmesi pratikte mümkün olmayan veridir. Pseudonym (takma kimlik) yaklaşımı, kişiyi doğrudan göstermeyen ama uygun anahtarla geri çözülebilen veridir. Maskelenmiş veri ise görünümü gizler ama tamamen anonim olmayabilir. Burada ince bir detay var: maskelenmiş veya pseudonym veri hâlâ risk taşıyabilir, bu yüzden “tamamen güvendeyiz” diye düşünmek doğru olmayabilir.
Teknik Açıdan Kişisel Veri Örnekleri
IP adresi, cihaz kimliği, çerez kimliği, konum verisi, kullanıcı davranış kayıtları, oturum token’ı, support ticket içerikleri… Bunlar çoğu geliştiricinin ilk etapta “kişisel veri” diye düşünmediği ama pratikte öyle olan örneklerdir.
GDPR ve KVKK Arasındaki Temel Farklar
Kapsam ve Uygulama Alanı
GDPR, AB odaklıdır ama AB vatandaşı veya AB’de bulunan kişilerin verisi işleniyorsa kapsam genişler. KVKK ise Türkiye odaklıdır. Çok uluslu ürünlerde çoğu ekip iki düzenlemeyi birlikte ele alır.
Hukuki Dayanaklar
Her iki düzenlemede de veri işlemenin dayanağı olması gerekir. Açık rıza bunlardan sadece biridir. Sözleşme gerekliliği, hukuki yükümlülük, meşru menfaat gibi dayanaklar da olabilir. Burada kritik konu, dayanağı netleştirmek ve bunu dokümante etmektir.
Veri Sahibi Hakları
Kişi, verisine erişmek isteyebilir, düzeltmek isteyebilir, silinmesini isteyebilir, taşınabilirlik talep edebilir. Yazılım tarafında bu haklar “feature” gibi ele alınmalı. Yoksa sonradan eklemek zor olur.
Ceza ve Yaptırım Farkları
Yaptırımların ölçeği ve uygulama biçimi farklılık gösterebilir. Ancak geliştirici açısından pratik sonuç aynı: veri yanlış yönetilirse kurum risk alır, ekip zor durumda kalır, itibar kaybı olur. Bu yüzden mevzuatı “hukukçular halletsin” diyerek kenara atmak iyi bir fikir değil.
Yazılımcılar Neden GDPR ve KVKK’yı Bilmek Zorunda?
Kod = Veri İşleme
Bir kullanıcı kaydı aldığında veri işliyorsun. Log yazdığında veri işliyorsun. E-posta gönderdiğinde veri işliyorsun. Analytics entegre ettiğinde veri işliyorsun. Yani kod, çoğu zaman veri işleme motorudur.
Yanlış Implementasyonun Hukuki Sonuçları
Yanlış yetkilendirme, hatalı silme, gereksiz veri toplama, yanlış saklama süresi, üçüncü taraflara kontrolsüz veri aktarımı gibi hatalar hukuki sonuç doğurabilir. Üstelik bu hatalar genelde “küçük bir karar” gibi başlar.
“Ben Sadece Kod Yazıyorum” Yanılgısı
Bu yanılgıyı çok gördüm. Ama gerçek hayatta yazdığın kod, şirketin veri işleme biçimini belirler. Bu yüzden GDPR ve KVKK: Yazılımcıların Bilmesi Gerekenler aslında “meslek sorumluluğu” konusudur.
Teknik Kararların Hukuki Etkisi
Veriyi nerede tutuyorsun, ne kadar süre saklıyorsun, kim erişebiliyor, nasıl şifreliyorsun, hangi üçüncü taraflara gönderiyorsun? Bunların hepsi teknik karar gibi görünür ama doğrudan uyumluluğu etkiler.
Yazılım Perspektifinden Veri Sorumluluğu
Veri Sorumlusu ve Veri İşleyen Kavramları
Veri sorumlusu, verinin neden ve nasıl işleneceğine karar veren taraftır. Veri işleyen ise veri sorumlusu adına veriyi işleyen taraftır. Bir projede rol dağılımı sözleşmelerle netleşir, ama yazılımın tasarımı bu rolleri fiilen etkileyebilir.
Yazılımcı Hangi Rolde Yer Alır?
Geliştirici çoğu zaman doğrudan “veri sorumlusu” olmaz, ama sistemin veri işleme şeklini kurar. Bu yüzden teknik tasarımda sorumluluk payı vardır. Özellikle güvenlik ve erişim kontrolü tarafında geliştirici kritik roldedir.
SaaS, Cloud ve Third-party Servisler
SaaS kullanırken veriyi bir servis sağlayıcıya aktarırsın. Cloud kullanırken veri merkezleri, bölge seçimi, yedekleme ve loglama süreçleri devreye girer. Third-party analytics, e-posta servisleri, destek sistemleri de aynı şekilde veri aktarımı demektir. “Sadece entegre ettim” cümlesi, veri akışını değiştirdiğin gerçeğini ortadan kaldırmaz.
Open Source Kullanımında Veri Riski
Open source kütüphaneler çok faydalı. Ama bazı kütüphaneler telemetri toplayabilir, hata raporu gönderebilir veya yanlış konfigürasyonla veri sızdırabilir. Bu yüzden kütüphane seçiminde güvenlik ve veri akışı kontrolü önemlidir.
Açık Rıza ve Hukuki Dayanaklar
Açık Rıza Nedir, Ne Değildir?
Açık rıza, bilgilendirilmiş, özgür iradeyle verilmiş ve belirli bir amaç için alınmış onaydır. “Kullanıyorsan kabul etmiş sayılırsın” gibi yaklaşımlar çoğu zaman sorun çıkarır. Ayrıca rıza, her işleme için tek çözüm değildir.
Açık Rıza Gerekmeyen Durumlar
Bazen sözleşmenin kurulması, hukuki yükümlülük veya meşru menfaat gibi dayanaklar kullanılabilir. Burada doğru karar, hukuk ve ürün ekibiyle birlikte netleştirilmelidir. Geliştirici olarak senin görevin, seçilen dayanağın teknik karşılığını doğru uygulamaktır.
Checkbox, Modal ve UI Hataları
En sık gördüğüm hatalar: önceden işaretli checkbox, belirsiz metin, “kabul etmezsen devam edemezsin” baskısı, tek ekranla her şeye onay alma. UI tasarımı, rızanın kalitesini belirler. Bu yüzden frontend ekibi bu konuyu ciddiye almalı.
Loglama ve Rıza İspatı
Rıza aldıysan ispatlaman gerekebilir. Bu da rıza kaydını güvenli şekilde saklamak demektir. Ne zaman alındı, hangi metne onay verildi, hangi sürümdeydi? Bu bilgiler kontrol altında olmalı. Ama rıza loglarken gereksiz kişisel veri biriktirmemeye de dikkat et.
Yazılım Geliştirme Sürecinde Dikkat Edilmesi Gerekenler
Privacy by Design ve Privacy by Default
Privacy by design, tasarımın başından itibaren veri korumayı düşünmek demektir. Privacy by default ise varsayılan ayarların en korumacı şekilde gelmesidir. Yani kullanıcı bir şey yapmadan bile sistem minimum veriyle çalışmalı. Yazılım geliştirmede veri koruma uyumluluğu (privacy by design) nasıl sağlanır sorusunun ana cevabı burada.
Minimum Veri Toplama Prensibi
En sevdiğim ve en işe yarayan ilke bu. “İleride lazım olur” diye veri toplayıp saklamak, hem risk hem maliyettir. Gerçek projelerde kişisel veri işleme ve güvenlik best practices içinde bu ilke bir numaradır.
Veri Saklama Süreleri
Veriyi sonsuza kadar saklamak iyi bir fikir değil. Saklama süresi belirlenmeli, otomatik silme veya anonimleştirme süreçleri kurulmalı. “Arşiv dursun” yaklaşımı, uyumluluk tarafında çoğu zaman sorun çıkarır.
Test Ortamlarında Gerçek Veri Kullanımı
Staging ortamına üretim verisi dump etmek, çok sık yapılan ama çok riskli bir hata. Erişim kontrolleri zayıf olabilir, loglar açık olabilir, üçüncü taraflara istemeden veri akabilir. Test için sentetik veri üretmek veya anonimleştirme kullanmak daha güvenlidir.
Backend, Frontend ve DevOps Perspektifi
Backend’de Kişisel Veri Yönetimi
Backend tarafında veri modelleme, erişim kontrolü, şifreleme, saklama süresi ve silme süreçleri kritik. Ayrıca API’lerin “gereğinden fazla veri” döndürmesi çok yaygın bir problemdir. İhtiyaç kadar veri döndürmek hem performans hem uyumluluk için iyi bir alışkanlıktır.
Frontend’de Formlar, Cookie’ler ve Tracking
Formlar gereksiz alanlarla doluysa gereksiz veri toplarsın. Cookie ve tracking tarafında da şeffaflık ve tercih yönetimi önemlidir. Bir kullanıcının izlenmeyi kapatma hakkı, teknik olarak uygulanabilir olmalı.
Loglar, Monitoring ve APM Araçları
Loglar genelde “kimse bakmıyor” sanılır ama incident anında herkes loglara bakar. O yüzden loglarda kişisel veri sızması sık yaşanır. E-posta, telefon, token, adres, hatta hata mesajı içinde gizli veri… Bunları maskeleme ve filtreleme alışkanlığı şart.
CI/CD, Cloud ve Backup Sistemleri
Yedekler unutulan bir risk alanıdır. Veri silme talebi geldiğinde, yedeklerdeki verinin durumu ne olacak? Ayrıca CI/CD logları, artifact’ler, container image’ları içinde yanlışlıkla veri kalabilir. DevOps süreçlerinde veri koruma kontrol listesi bu yüzden önemlidir.
Veri Güvenliği ve Teknik Önlemler
Şifreleme (Encryption) ve Hashing
Şifreleme, veriyi saklarken ve taşırken korur. Hashing ise özellikle parola gibi veriler için doğru yöntemdir. Burada ince nokta şu: hash ve şifreleme aynı şey değil. Parola gibi veriler geri çözülememeli, yani hashlenmelidir.
Access Control ve Yetkilendirme
Yetkilendirme hataları veri ihlallerinin başında gelir. Rol bazlı erişim, least privilege yaklaşımı ve düzenli yetki denetimi temel olmalı. Özellikle admin panelleri, destek ekranları ve raporlama sistemleri bu konuda risklidir.
Veri İhlali (Data Breach) Yönetimi
İhlal olabilir. Önemli olan, ne kadar hızlı fark ettiğin ve nasıl yönettiğin. Log ve izleme altyapısı bu yüzden sadece performans için değil, güvenlik için de kurulur.
Incident Response Süreçleri
Olay müdahale süreci, “kimin ne yapacağı”nı önceden belirler. Bu süreç yoksa kriz anında kaos çıkar. Ayrıca sosyal mühendislik saldırıları da veri ihlallerinin önemli bir kaynağıdır. Bu konuda sosyal mühendislik saldırıları yazısı ekibe farkındalık kazandırabilir.
Veri Sahibi Hakları ve Teknik Yansımaları
Veri Erişim ve Düzeltme Hakkı
Kullanıcı “benim verim ne” diye sorduğunda cevap verebilmelisin. Bu, rapor üretmek ve veri doğruluğunu sağlamak demektir. Teknik olarak veri modeli ve audit izleri önem kazanır.
Veri Silme (Right to be Forgotten)
Silme talebi, sadece ana tabloda satır silmek değildir. Loglar, cache, arama indeksleri, yedekler, üçüncü taraf servisler… Hepsini düşünmek gerekir. Bu yüzden “silme” özelliği baştan planlanmalı.
Veri Taşınabilirliği
Veriyi kullanıcıya taşınabilir formatta verme ihtiyacı olabilir. Bu, API ve veri modelini etkiler. Export formatı, kimlik doğrulama ve hız limitleri gibi konular devreye girer.
API ve Sistemlerde Uygulama Zorlukları
En büyük zorluk, dağıtık sistemlerde verinin izini sürmektir. Mikroservislerde hangi servis hangi veriyi tutuyor? Event akışında veri nerelere gidiyor? Bu sorulara cevap veremeyen sistemlerde uyumluluk zorlaşır.
Yaygın Hatalar ve Yanılgılar
“Sadece Email, Kişisel Veri Sayılmaz”
Bu yanlış. E-posta çoğu zaman kişisel veridir. Hatta tek başına bile kişiyi belirleyebilir. “Sadece e-posta” diye küçümsemek, risk doğurur.
Loglar Kişisel Veri İçermez Yanılgısı
Loglarda çoğu zaman kişisel veri olur. Hele hata anında “debug için her şeyi yazalım” yaklaşımı varsa. Token, header, request body, form içeriği… Bunlar logda kalabilir. Bu yüzden log sanitization pratik bir zorunluluktur.
Test ve Staging Ortamlarını Önemsememek
Staging ortamları genelde daha gevşek korunur. Bu da risk yaratır. Gerçek veri kullanımı, zayıf şifreler, açık paneller, eski image’lar… Hepsi birer açık kapıdır.
Üçüncü Parti Araçları Körü Körüne Kullanmak
Analytics, chat widget, APM, e-posta servisleri… Hepsi veri aktarımıdır. “Herkes kullanıyor” demek yeterli değil. Veri ne gidiyor, nerede tutuluyor, ne kadar saklanıyor, nasıl siliniyor? Bunları bilmek gerekir.
Yazılımcılar için Pratik GDPR & KVKK Checklist’i
Kod Yazarken Sorulması Gereken Sorular
Bu veriye gerçekten ihtiyacım var mı? Veriyi hangi amaçla topluyorum? Kim erişecek? Ne kadar süre saklayacağım? Üçüncü tarafa gidiyor mu? Silme talebi gelirse ne olacak? Bu sorular, yazılım ekipleri için veri koruma uyumluluk checklist ve süreçleri içinde en temel adımlardır.
Güvenli ve Uyumlu Yazılım Alışkanlıkları
Varsayılan kapalı izinler, minimum veri, maskeleme, şifreleme, erişim kontrolü, düzenli güvenlik güncellemesi, test ortamında sentetik veri. Bunlar alışkanlık olursa uyumluluk bir “ek yük” olmaktan çıkar.
Dokümantasyon ve Şeffaflık
Veri envanteri tutmak, veri akışlarını çizmek, hangi servis neyi işliyor göstermek çok işe yarar. Bu sadece hukuk için değil, ekip içi iletişim için de önemlidir. Yeni bir geliştirici geldiğinde “veri nerede” sorusuna hızlı cevap verebilmek büyük rahatlık sağlar.
Sürekli Denetim ve Güncelleme
Uyumluluk bir kere yapılmaz. Ürün değiştikçe veri akışı değişir. Yeni entegrasyon eklenir, yeni log sistemi kurulur, yeni cache açılır. Bu yüzden düzenli denetim ve güncelleme şart.
Sonuç: GDPR ve KVKK Yazılımcının Konusu mu?
Hukuk + Yazılım Kesişimi
Evet, yazılımcının konusu. Çünkü hukuk metinleri sistemde “butona” dönüşür, “sil” endpoint’ine dönüşür, “rıza” ekranına dönüşür, “log maskesi”ne dönüşür. GDPR ve KVKK: Yazılımcıların Bilmesi Gerekenler başlığının özü tam olarak bu.
Proaktif ve Sorumlu Geliştirici Olmak
Proaktif geliştirici, riskleri baştan görür. Gereksiz veriyi toplamaz, güvenliği tasarımın içine koyar, test ortamlarında veri disiplinini korur, üçüncü tarafları sorgular. Bu yaklaşım, ekibi de rahatlatır.
Güven ve Sürdürülebilir Yazılım Üretimi
Kullanıcı güveni zor kazanılır, kolay kaybedilir. Veri güvenliği ve uyumluluk, sürdürülebilir ürün geliştirmenin temelidir. Kısa vadeli hız için bu konuları ertelemek, uzun vadede daha büyük maliyet çıkarır.
Sonuç ve Çağrı
Özetle, GDPR ve KVKK: Yazılımcıların Bilmesi Gerekenler sadece hukuki bir başlık değil; tasarım, geliştirme, test, DevOps ve ürün yönetimini etkileyen bir pratikler bütünü. Kişisel veri koruma mevzuatının yazılım geliştirme süreçlerine etkileri ve uyumluluk gereksinimleri rehberi arıyorsan, burada anlattıklarımı bir başlangıç çerçevesi olarak kullanabilirsin. Ekip içinde küçük bir checklist ile başla, veri akışını çıkar, logları temizle, saklama sürelerini belirle. Sonra adım adım olgunlaştır.
Eğer ekipçe uyumluluk sürecini oturtmak, teknik kontrol listelerini çıkarmak veya güvenli geliştirme süreçlerini güçlendirmek istersen hizmetler sayfamıza göz atabilirsin. Bizi daha yakından tanımak için hakkımızda sayfası da seni bekliyor.
Ve “KVKK/GDPR uyumluluk eğitimi yakınımda” diye arıyorsan, pratik örneklerle birlikte konuşmak ve ekip kültürünü güçlendirmek için seni Diyarbakır Yazılım Topluluğu içine davet ediyoruz. Sorularını getir, birlikte netleştirelim.
Sık Sorulan Sorular
GDPR ve KVKK nedir ve temel farkları nelerdir?
GDPR, Avrupa Birliği’nin kişisel veri koruma düzenlemesidir. KVKK ise Türkiye’deki kişisel verilerin korunmasına yönelik kanundur. Kapsam, uygulama alanı, bazı haklar ve yaptırım süreçlerinde farklılıklar olabilir. Çok uluslu projelerde ikisi birlikte değerlendirilir.
Yazılım geliştiriciler GDPR ve KVKK’ya uyum sağlamak için neler yapmalı?
Privacy by design yaklaşımıyla başlamak, minimum veri toplamak, saklama sürelerini belirlemek, şifreleme ve erişim kontrolü uygulamak, logları maskelemek, test ortamında gerçek veriden kaçınmak ve veri akışını dokümante etmek temel adımlardır.
Kişisel verilerin korunmasında yazılımcıların sorumlulukları nelerdir?
Geliştirici, sistemin veri işleme biçimini inşa ettiği için sorumluluk taşır. Güvenli implementasyon, doğru yetkilendirme, veri minimizasyonu, silme süreçleri, üçüncü taraf entegrasyon kontrolü ve incident response hazırlığı bu sorumluluklar arasındadır.
Yazılım projelerinde veri işleme ve depolama süreçleri nasıl düzenlenir?
Veri envanteri çıkarılır, veri akışları belirlenir, hukuki dayanaklar netleştirilir, saklama süreleri tanımlanır, erişim ve şifreleme politikaları uygulanır. Ayrıca silme, erişim, düzeltme gibi veri sahibi haklarını destekleyen teknik akışlar kurulmalıdır.
GDPR ve KVKK uyum eğitimi veya kursu yakınımda nerede bulunur?
GDPR ve KVKK uyum eğitimi veya kursu yakınımda diye arıyorsan, pratik senaryolarla öğrenmek ve ekipçe farkındalık kazanmak için Diyarbakır Yazılım Topluluğu iyi bir başlangıç noktasıdır.