KVKK ve GDPR Teknik Uyumluluk Rehberi: Yazılım Perspektifi [2026]

KVKK ve GDPR: Türkiye'nin Yasal Çerçevesi

Türkiye'de KVKK (Kişisel Verilerin Korunması Kanunu), 2018'den beri yürürlüktedir. Avrupa'da GDPR ise 2018'de yürürlüğe girmiştir. Hem de KVKK'nın daha katı bir versiyonudur.

Temel Soru: "Biz sadece Türkiye'de faaliyet gösteriyor, neden GDPR'yi önemsemeli?"

Cevap: Eğer:

• Avrupa'da müşteri varsa
• Avrupa şubeniz varsa
• Avrupa'dan müşterin verisi işliyorsa

O zaman GDPR sizin için zorunludur. Ceza: 4% veya 20 milyon Euro (üst taraf uygulanır).

Öte yandan, sadece Türkiye'de müşteri varsa ve sadece KVKK'ya uyacaksanız bile, GDPR'den daha hafif bir yaptırım söz konusudur. Ceza: 50.000 liraya kadar (ancak Veri Koruma Kurulu'nun (VKK) düzenleyici denetimi vardır).

KVKK vs GDPR: Karşılaştırma

Alan	KVKK	GDPR	Fark
Uygulama Alanı	Türkiye	Avrupa + Türkiye (Avrupa müşteri varsa)	GDPR daha geniş
Veri Sahibi Hakları	Temel haklar	Gelişmiş haklar (unutulma hakkı vb.)	GDPR daha katı
İzin (Consent)	Yazılı onay yeterli	Açık rıza (opt-in) gerekli	GDPR daha katı
Veri İhlali Bildirimi	Bildirim gerekli	Acil bildirim (72 saat)	GDPR daha katı
Veri Koruma Görevlisi	Talep edilmez	Büyük işletmelerde zorunlu (DPO)	GDPR daha katı
Ceza	50.000 lira	4% veya 20 milyon Euro	GDPR çok daha ağır

KVKK'nın Temel Prensiplebi

1. Kanuni Esas (Lawfulness)

Kişisel verileri işlemek için yasal bir dayanak gerekir. Yasal dayanaklar:

• Kişinin açık rızası (en yaygın)
• Kanunun açıkça tanıması
• İdari veya yargı kararı
• Tarafın hayati çıkarları
• Kamu yararı

Örnek: Bir e-ticaret sitesi, müşterinin kargo adresi için açık rıza almalı.

2. Amaç Sınırlılığı (Purpose Limitation)

Veriler, belirli amaçlar için işlenmeli. Amaç dışında kullanılmamalı.

Örnekler:

• Siparişi teslim etmek için adres topla, sonra pazarlama için kullanma (yasak)
• Müşteri hizmetleri için telefon numarası al, sonra tele-pazarlama için kullanma (yasak)

3. Veri Minimizasyonu (Data Minimization)

Sadece gerekli veri topla. Gereksiz veri çalma veya saklama yok.

Örnekler:

• Siparişi teslim etmek için: Ad, Adres, Telefon gerekli; Pasaport No gerekli değil.
• Kredi kartı işlemi için: Son 4 digit gerekli; Tam KK numarası saklamama

4. Doğruluk (Accuracy)

Veriler doğru ve güncel olmalı. Yanlış veriler saklamama.

5. Saklama Süresi Sınırı (Storage Limitation)

Veriler, gerekli olduğunuz kadar saklanmalı. Amacı olmadığında silinmeli.

Örnekler:

• Müşteri 5 yıl teslim garantili ürün aldıysa, bu veriler 5 yıl saklanmalı (garanti için)
• Müşteri siparişi iptal ederse, adres 30 gün saklanmalı (iade için), sonra silinmeli

6. Bütünlük (Integrity) ve Gizlilik (Confidentiality)

Veriler, yetkisiz erişim, işlem, kayıp, hasara, imha'dan korunmalı.

Bu, teknik kontrolleri gerektiriyor: Şifreleme, erişim kontrolü, backup.

7. Sorumluluk (Accountability)

Tüm bu yükümlülükleri yerine getirdiğini ispat etmeliyiz. Kayıtlar tutmalı.

GDPR'nin Ek Prensipleri

KVKK'ya ek olarak, GDPR şu prensipleri getirir:

1. Right to Be Forgotten (Unutulma Hakkı)

Veri sahibi, verilerinin silinmesini talep edebilir. İşletme, onu silinmeli (istisnaları hariç).

Örnek: Müşteri, "Hesabımı sil" derse, tüm veriler (ad, adres, geçmiş siparişler) silinmeli.

İstisna: Yasal yükümlülük varsa (mali hesaplar 5 yıl saklanmalı) silinmez.

2. Data Portability (Veri Taşınabilirliği)

Veri sahibi, verilerini başka işletmeye taşıyabilmeli.

Örnek: Müşteri, "Verilerimizi indirmek istiyorum" derse, tüm veriler makine-okur formatında (JSON, CSV) verilmeli.

3. Right of Access (Erişim Hakkı)

Veri sahibi, ne veriler saklandığını, kim tarafından işlendiğini bilmeli.

4. Right to Rectification (Düzeltme Hakkı)

Veriler yanlış ise düzeltmeyi talep edebilir.

Teknik Uyumluluk: Yazılımda Ne Yapılmalı?

1. Veri Şifreleme

At Rest (Saklı Veriler)

Veritabanında saklanan veriler şifreli olmalı:

Standart: AES-256

Uygulama:

• Tüm kişisel veriler şifreli
• Şifreleme anahtarı, veri tabanından ayrı bir yerde saklanmalı (Hardware Security Module veya Secrets Management)
• Eski veri silinirken, şifreleme anahtarı da silinmeli

Teknik Kontrol: Şifreleme iki seviyede uygulanabilir. Veritabanı yazılımı tarafından otomatik şifreleme yapılabilir veya uygulamadan gelen veriler şifreli halde veritabanına yazılabilir. Uygulama seviyesinde şifreleme daha güvenlidir çünkü veritabanı yöneticisi veya yetkisiz kişiler veritabanına erişse bile, veriler şifreli kalır. Bu nedenle uygulama seviyesinde şifreleme tavsiye edilmektedir.

In Transit (İletim Sırasında)

Veri, istemci ile sunucu arasında iletilirken şifreli olmalı:

Standart: TLS 1.3

Uygulama:

• HTTPS (HTTP değil)
• Self-signed sertifika değil, CA imzalı sertifika
• Weak cipher suites (DES, RC4) değil, güçlü olanlar (AES-GCM)

2. Erişim Kontrolü

Sadece yetkili kişiler, gerekli verilere erişebilmeli.

Role-Based Access Control (RBAC)

Roller tanımla (Admin, Manager, Employee) ve her role için izinleri set et.

Attribute-Based Access Control (ABAC)

Daha granular kontrol: "Sadece kendi departmanının verisi görebilir" gibi.

Least Privilege

Varsayılan olarak herkesi yasakla, sonra ihtiyaca göre izin ver.

Örnek:

• Müşteri: Sadece kendi sipariş geçmişini görebilir
• Satış Temsilcisi: Atandığı müşterileri görebilir
• Satış Müdürü: Tüm satış temsilcilerin müşterilerini görebilir
• Admin: Tüm verileri görebilir (ancak bu kontrol edilmeli)

3. Consent Management (İzin Yönetimi)

Müşteriden izin aldığınızda, bunu sistematik olarak yönetmelisiniz.

Consent Tracking

• Müşteri hangi tarihte hangi amaçlarla izin verdi?
• Hangi versiyonu kabul etti?
• Nasıl geri çekebilir?

Teknik:
Veritabanında:

• consent_id
• user_id
• consent_type (marketing, analytics, etc.)
• granted_date
• withdrawal_date (eğer geri çekildiyse)
• ip_address (kanıt için)
• consent_version (versiyonu değişirse takip için)

Explicit Consent (Açık Rıza)

GDPR için, varsayılan olarak "hayır" başlayıp, müşteri "evet" kliklamalı. Opt-in denir.

Uygulamada:

• Checkbox önceden işaretli olmamalı
• Şartlar gizli yazı olmamalı (açık olmalı)
• Müşteri bilinçli olmalı

4. Data Minimization (Veri Minimizasyonu)

Yazılımda, her form alanını sorgula: "Bu veri gerçekten gerekli mi?"

Örnek: Sağlık portalında:

• Gerekli: Ad, Soyad, TC No, Telefon, Adres
• Gereksiz: Boy, Kilo (hastalık türü başka türlüyse)
• Gereksiz: Meslek, Eğitim Durumu (tıbbi tedavi için)

Yazılım tasarımında:

• Form'da sadece gerekli alanlar
• Veritabanında gereksiz kolonlar değil
• API'den geri dönen veri, gereksiz alanları içermemeli

5. Audit Logging (Denetim Günlüğü)

Tüm veri erişim ve işlemlerinin log'u tutulmalı:

Neyin Log'u Tutulmalı:

• Veri erişimi (kim ne görmüştür)
• Veri değiştirilmesi (kim ne değiştirmiştir)
• Veri silinmesi (kim ne silmiştir)
• Başarısız erişim denemeleri
• System events (backup, restore)

Log'un İçermesi Gereken:

• Timestamp (ne zaman)
• User ID (kim)
• Action (ne yapıldı)
• Data Element (hangi veri)
• IP Address (nereden)
• Success/Failure (başarılı mı)

Koruma:
Log'lar kendileri hassas veridir. Koruma altında tutulmalı:

• Merkezi log toplama (SIEM)
• Tümdengelme koruması (write-once read-many - WORM)
• Şifreleme
• Erişim kontrolü

6. Data Retention Policies (Veri Saklama Politikaları)

Yazılımda, hangi veri ne kadar süre saklanacağını tanımlamalıdır. Aktif müşteri verileri kontrat süresi plus 2 yıl saklanmalı. İşlem yapmayan müşteri verileri son işlemden 5 yıl saklanmalı. Silinen müşteri verileri 30 gün saklanmalı (iade için), sonra silinmeli. Başarılı ödeme işlemleri 7 yıl saklanmalı (vergi nedeniyle), başarısız işlemler 6 ay. Tüm login işlemleri 90 gün, başarısız giriş denemeleri 30 gün saklanmalıdır.

Sistem, otomatik olarak bu politikaları uygulamalıdır. Belirli aralıklarla program tasarlanan işler çalışıp eski verileri otomatik siler, yenileme mekanizması işler ve her silme işleminin kaydı tutulur.

7. Data Breach Notification (İhlal Bildirimi)

Eğer veri ihlali meydana gelirse:

KVKK: Veri Koruma Kurulu'na bildirilmeli
GDPR: Veri Koruma Kurulu'na 72 saat içinde, veri sahibine 30 gün içinde

Teknik Olarak:

• Monitoring sistemi, anormal aktiviteyi tespit etmeli
• Alert sistemi, derhal uyarmalı
• Incident response plan, bildirime hızlıca cevap vermelidir

8. Privacy by Design

GDPR, "Privacy by Design" talep etmektedir. Yazılımın tasarımı itibaren güvenliği öngörülmeli.

Uygulamada:

• Veri minimizasyonu tasarımda başlar (gereksiz alan ekleme)
• Encryption-first yaklaşım (hassas veriler şifreli depolanır)
• Consent flow, tasarımda basit ve anlaşılır (müşteri bilinçli seçim yapabilir)
• Deletion flow, otomatik (müşteri sil derse, otomatik silinir)

9. Data Protection Impact Assessment (DPIA)

Yeni bir proje başlatırken veya büyük bir değişiklik yapılırken, etki değerlendirmesi yapılmalı:

• Hangi veriler işlenecek?
• Risikler nedir?
• Kontroller nelerdir?
• Etki nedir?

Yazılımda:

• DPIA şablonları
• Risk matrisleri
• Mitigation planları

Uyumluluk Kontrolü (Audit)

İç Denetim

Yazılımı geliştiren şirket, kendisi kontrol etmelidir:

• Veri şifreleme yapılmış mı?
• Erişim kontrolleri set edilmiş mi?
• Log'lar tutulmuş mu?
• Silme politikaları uygulanmış mı?

Frekans: En az yılda bir kez

Dış Denetim

Bağımsız denetçiler, uyumluluk kontrol ettiklerinde:

• Yazılım taraması
• Penetrasyon testi
• Dokümantasyon incelemesi
• İnsan görüşmesi

Sertifikasyon: ISO 27001 (bilişim güvenliği)

Uyumluluk Kontrol Listesi

Yazılım projenizde, aşağıdakileri kontrol edin:

Tasarım Aşaması

• [ ] Veri minimizasyonu uygulandı mı?
• [ ] Şifreleme stratejisi belirlendi mi?
• [ ] Erişim kontrol modeli seçildi mi?
• [ ] Saklama politikaları tanımlandı mı?
• [ ] Veri sahibi hakları nasıl sağlanacak?

Geliştirme Aşaması

• [ ] Veri at-rest şifreli mi?
• [ ] Veri in-transit TLS üzerinde mi?
• [ ] Erişim kontrolleri kod seviyesinde uygulandı mı?
• [ ] Consent tracking sistemi var mı?
• [ ] Audit logging çalışıyor mu?
• [ ] Silme API'si mevcutta mı?

Test Aşaması

• [ ] Güvenlik testleri yapıldı mı?
• [ ] GDPR/KVKK uyumluluk testleri yapıldı mı?
• [ ] Verilerin doğru silindiği test edildi mi?
• [ ] Log'ların yazıldığı test edildi mi?

Canlı Aşama

• [ ] Yapılandırma kontrol edebilir mi?
• [ ] Monitoring sistemi kurulu mu?
• [ ] Incident response planı var mı?
• [ ] DPO (Veri Koruma Görevlisi) atandı mı?

Pratik Örnek: E-Ticaret Sitesi

Bir e-ticaret sitesi, GDPR/KVKK'ya uyum sağlamak için:

Müşteri Kaydı

Müşteri kaydında açık rıza alınmalıdır. Pazarlama e-postalarını almak için ayrı bir onay kutucuğu bulunmalı ve bu kutucuk önceden işaretli olmamalıdır. Şartlar ve koşullar açıkça görünür olmalı. Kayıt tamamlandığında müşteriye bilgilerin kaydedildiğine dair onay mesajı gönderilmelidir.

Sipariş

Müşteri adres bilgileri şifreli şekilde depolanmalıdır. Ödeme işlemlerinde kredi kartı numarası saklanmamalı, bunun yerine ödeme sağlayıcıdan gelen bir token kullanılmalıdır. Vergi kayıtları ve sipariş geçmişi 7 yıl saklanmalıdır (yasal zorunluluk). İade adresi sadece 30 gün saklanmalı, sonrasında silinmelidir.

Pazarlama

Müşteri pazarlama e-postalarını almamaya karar verirse, bağlantıda hemen unsubscribe olması gerekir. Aynı gün içinde e-posta gönderimi durdurulmalı ve veritabanında unsubscribe tarihi kaydedilmelidir.

Veri Taşınabilirliği

Müşteri "Verilerimi indir" butonuna tıkladığında, tüm veriler makine-okur formatında (JSON gibi) indirilmeli. Parola hash'i dışında tüm veriler verilmeli. İndirilen veriler 30 gün içinde sistem üzerinden silinmelidir.

Sonraki Adımlar

GDPR/KVKK uyumluluk, yazılım geliştirmenin tamamlayıcı bir parçasıdır. Ama tek başına yazılım yeterli değildir - organizasyonel süreçler de şart:

• Veri Koruma Politikaları
• Çalışan Eğitimi
• DPO Atanması
• Denetim Süreci

Yazılım güvenliği genel olarak Siber Güvenlik ve Yazılım Güvenliği Hizmetleri rehberimizde ele alınmaktadır. Ayrıca Güvenli Yazılım Geliştirme Yaşam Döngüsü yazısında, tasarımdan itibaren güvenlik entegrasyonu anlatılmaktadır.

Smart Maple, yazılım projelerinizin GDPR/KVKK uyumluluğundan emin olmalarına yardımcı olur. Yazılımınızın uyumluluk kontrolü için smart-maple.com adresinden danışmanlık hizmetlerimiz hakkında daha fazla bilgi alın.