Tedarikçi Kaynaklı Veri İhlali: Yazılım Tedarikçinizi KVKK Kapsamında Yönetmek

Tedarikçi kaynaklı veri ihlali: sorumluluk kimde kalır?

Müşteri verilerinizi tutan yazılım, barındırma veya destek tedarikçinizin sunucusuna yetkisiz erişim sağlandığında ortaya çıkan veri ihlali, KVKK açısından yine sizin ihlalinizdir. Kişisel Verileri Koruma Kanunu'nun 12. maddesi, veri sorumlusunu veri işleyen nezdinde alınması gereken tedbirlerden de müştereken sorumlu tutar. Kurul'a ve ilgili kişilere bildirim yükümlülüğü de veri sorumlusundadır.

Bu yazıda tedarikçi kaynaklı ihlallerin neden yaşandığını, veri sorumlusu ile veri işleyenin görevlerini, sözleşmeye girmesi gereken maddeleri, riski azaltan teknik kontrolleri ve bir ihlal olduğunda ilk 72 saatin nasıl yönetileceğini anlatıyoruz. Sonda yazılım tedarikçinize sorabileceğiniz on soruluk bir kontrol listesi var. Bu yazı hukuki danışmanlık değildir; somut durumunuz için hukuk danışmanınızla çalışın.

Kısaca

• KVKK m.12/2'ye göre veri sorumlusu, verilerin kendi adına başka bir kişi tarafından işlenmesi hâlinde güvenlik tedbirlerinden o kişiyle birlikte müştereken sorumludur.
• Kurul'un 2019/10 sayılı kararına göre ihlal, öğrenilmesinden itibaren en geç 72 saat içinde Kurul'a bildirilir; bu süre tedarikçi geç haber verirse kısalır.
• 2 Eylül 2026'da yayımlanan 33 ihlal duyurusunun 22'si, veri işleyen sistemlerindeki bir sunucuya yetkisiz erişimi anlatıyordu.
• Sözleşmede bildirim SLA'sı, alt işleyen listesi, denetim hakkı ve sözleşme sonunda silme gibi maddeler; teknik tarafta en az yetki, MFA ve merkezi log gerekir.
• Kanıt isteyin: politika metni değil, erişim logu, sızma testi özeti ve alt işleyen listesi gibi doğrulanabilir belgeler.

2 Eylül 2026'da ne oldu?

Kişisel Verileri Koruma Kurumu'nun veri ihlali bildirimleri sayfasında 2 Eylül 2026 tarihli 33 duyuru yer alıyor. Bunların 22'si, veri sorumlusuna ait verilerin bulunduğu veri işleyen sistemlerindeki bir sunucuya yetkisiz erişim sağlanmasını anlatıyor. İlgili Kurul kararları 02.09.2026 tarihli ve 2026/1881 ile 2026/1902 arasında numaralandırılmış.

Duyuruların çoğunda veri işleyenin ihlali veri sorumlularına 27 veya 28 Ağustos 2026'da bildirdiği belirtiliyor. Etkilenen veri kategorileri ad, soyad, e-posta, adres, telefon ve hash'lenmiş kullanıcı giriş bilgileri; etkilenen kişi ve kayıt sayısının ise net olarak belirlenemediği yazıyor. Duyurularda veri işleyenin adı geçmiyor.

Bu tablo ne anlatıyor?

Tek bir tedarikçideki tek bir olay, birbirinden bağımsız onlarca şirketi aynı anda bildirim yapmak zorunda bıraktı. Bu şirketlerin her biri kendi duyurusunda kendi adıyla yer aldı. Yani tedarikçi seçimi ve yönetimi, bir satın alma konusu değil, doğrudan bir KVKK ve itibar konusudur.

Tablo ayrıca zamanlamayı da gösteriyor: veri işleyenin bildiriminden Kurul kararlarına kadar yalnızca birkaç gün geçti. Bu kısa sürede her veri sorumlusunun etkilenen veri kategorilerini belirlemesi, karar vermesi ve bildirim formunu doldurması gerekti. Önceden hazırlanmış bir olay müdahale planı ve tedarikçiyle tanımlı bir iletişim kanalı olmayan şirketler için bu süre çok dardır.

Tedarikçi kaynaklı ihlaller neden yaşanır?

Tedarikçi kaynaklı ihlallerin büyük kısmı karmaşık saldırılardan değil, tekrar eden birkaç zayıflıktan doğar. Aşağıdaki dört örüntü, tedarikçi değerlendirmelerinde en sık sorulması gereken başlıklardır.

Paylaşılan kimlik bilgileri

Destek ekibinin tamamının kullandığı tek bir yönetici hesabı veya müşteri ortamına erişim için ortak bir şifre, hem saldırı yüzeyini büyütür hem de olay sonrası "kim ne yaptı" sorusunu cevapsız bırakır. Kod deposunda veya bir wiki sayfasında duran API anahtarları da aynı riski taşır.

Aşırı yetkili destek erişimi

Tedarikçinin destek hesabı çoğu zaman tüm müşterilerin verisine, her saat ve süresiz erişebilir. Bir destek hesabı ele geçirildiğinde etki alanı bu yüzden tek bir müşteriyle sınırlı kalmaz. 2 Eylül tablosundaki çoklu bildirimler bu riskin somut bir görüntüsüdür.

Yamasız sistemler

İnternete açık yönetim panelleri, güncellenmemiş işletim sistemleri ve bilinen açıkları olan bileşenler, tedarikçinin altyapısında sizin görmediğiniz risklerdir. Hangi bileşenin hangi sürümle çalıştığını bilmek için SBOM (yazılım malzeme listesi) ve yama SLA'sı istemek bu yüzden önemlidir.

Görünmeyen alt işleyenler

Yazılım tedarikçiniz de bulut, e-posta, log, yedekleme veya çağrı merkezi hizmetlerini başka firmalardan alır. Bu alt işleyenler sözleşmede listelenmemişse verinizin nerede durduğunu ve kimlerin erişebildiğini bilemezsiniz.

Veri sorumlusu ve veri işleyen: KVKK m.12 ne diyor?

KVKK'da veri sorumlusu, kişisel verilerin işleme amaçlarını ve vasıtalarını belirleyen kişidir; veri işleyen ise veri sorumlusunun verdiği yetkiye dayanarak onun adına veri işler. Yazılım, barındırma ve bakım tedarikçileri çoğu zaman veri işleyen konumundadır.

Müşterek sorumluluk (m.12/2)

Kanun metni açıktır: "Veri sorumlusu, kişisel verilerin kendi adına başka bir gerçek veya tüzel kişi tarafından işlenmesi hâlinde, birinci fıkrada belirtilen tedbirlerin alınması hususunda bu kişilerle birlikte müştereken sorumludur." Birinci fıkra, hukuka aykırı işlemeyi ve erişimi önlemek ve verilerin muhafazasını sağlamak için gerekli teknik ve idari tedbirleri kapsar. Üçüncü fıkra veri sorumlusuna denetim yapma veya yaptırma yükümlülüğü verir; dördüncü fıkra ise öğrenilen verilerin görevden ayrıldıktan sonra da ifşa edilmemesini düzenler.

Sorumluluk sözleşmeyle devredilemez

Kurum'un "Doğru bilinen yanlışlar" yayını da bu noktayı vurgular: güvenlik yükümlülüklerinin sözleşmeyle tedarikçiye bırakılması, veri sorumlusunun sorumluluğunu ortadan kaldırmaz. Sözleşme, sorumluluğu devretmenin değil, tedbirleri tanımlamanın ve kanıt toplamanın aracıdır.

Bildirim yükümlülüğü (m.12/5)

İşlenen verilerin kanuni olmayan yollarla başkaları tarafından elde edilmesi hâlinde veri sorumlusu bu durumu en kısa sürede ilgilisine ve Kurul'a bildirir. Kurul'un 24.01.2019 tarihli ve 2019/10 sayılı kararına göre bu süre, öğrenme tarihinden itibaren en geç 72 saat; ilgili kişilere bildirim ise makul olan en kısa süre içinde yapılmalıdır. Kurul'un 25.12.2025 tarihli ve 2025/2451 sayılı kararıyla ihlal duyurularının yayında kalma süresi en fazla 60 gün ile sınırlandı; veri sorumlusu ilgili kişilere bildirim yaptığını belgelerse duyuru daha erken kaldırılabiliyor.

Tedarikçi sözleşmesine hangi maddeler girmeli?

Bir veri işleme sözleşmesi (DPA), tedarikçinin verinizi hangi amaçla, nerede ve hangi tedbirlerle işleyeceğini yazılı hale getirir. Aşağıdaki tablo, sözleşmeye girmesi gereken başlıca maddeleri ve tedarikçiden isteyebileceğiniz kanıtları özetliyor. Bildirim süresi gibi değerler kanunda yazmaz; 72 saatlik Kurul süresine sığmak için sizin belirlemeniz gereken iç hedeflerdir.

Madde / kontrol	Neden önemli?	İstenecek kanıt
Veri işleme sözleşmesi (DPA)	İşleme amacı, veri kategorileri ve tedbirler yazılı olur	İmzalı DPA, veri envanteri eki
Alt işleyen listesi ve onay şartı	Verinin kimde ve hangi ülkede durduğunu bilirsiniz	Güncel alt işleyen listesi, değişiklik bildirimi süreci
İhlal bildirim SLA'sı (ör. 24 saat)	72 saatlik Kurul süresine analiz ve karar zamanı kalır	Olay müdahale prosedürü, iletişim kişileri listesi
Denetim hakkı	m.12/3 kapsamındaki denetim yükümlülüğünü yerine getirirsiniz	Denetim raporu veya bağımsız denetim özeti
Şifreleme (aktarımda ve depolamada)	Ele geçirilen verinin okunmasını zorlaştırır	Şifreleme ve anahtar yönetimi açıklaması
Erişim logları ve saklama süresi	Olay sonrası kimin neye eriştiğini gösterir	Örnek log kaydı, saklama süresi taahhüdü
Sözleşme sonunda iade ve silme	İlişki bittiğinde veri tedarikçide kalmaz	Silme tutanağı veya imha sertifikası
Sızma testi raporları	Bilinen açıkların kapatıldığını gösterir	Son sızma testinin yönetici özeti ve kapanış durumu
SBOM ve yama SLA'sı	Kritik açıklarda etkilenip etkilenmediğinizi hızla bilirsiniz	Güncel SBOM, kritik yama süresi taahhüdü

Hangi teknik kontroller ihlal riskini azaltır?

Sözleşme maddeleri ancak teknik kontrollerle somutlaşır. Aşağıdaki kontroller, hem tedarikçiden istemeniz hem de kendi sisteminizde uygulamanız gereken asgari settir.

En az yetki ve süreli destek erişimi

Destek erişimi kişiye özel hesaplarla, yalnız gereken müşteri ortamına ve süreli (just-in-time) verilmeli; iş bitince otomatik kapanmalı. Rol tasarımı için RBAC ile erişim modeli tasarımı yazımız iyi bir başlangıç noktası.

MFA ve tek oturum açma

Yönetim panellerine ve destek araçlarına erişim çok faktörlü kimlik doğrulamayla korunmalı. Müşteri portallarında oturum güvenliğini SSO ve oturum güvenliği yazımızda ayrıntılı ele aldık.

Gizli anahtar kasası

API anahtarları, veritabanı şifreleri ve sertifikalar kodda veya dokümanlarda değil, bir secrets vault içinde tutulmalı, düzenli olarak ve her olaydan sonra döndürülmeli.

Merkezi log ve alarm

Kişisel veriye erişim, yetki değişiklikleri ve toplu dışa aktarımlar merkezi olarak loglanmalı; olağandışı hacim veya saat dışı erişim alarm üretmeli. Log yoksa ihlalin kapsamını belirlemek de mümkün olmaz.

Veri minimizasyonu ve ortam ayrımı

Tedarikçiye yalnızca işin gerektirdiği veri verilmeli. Test ve geliştirme ortamlarında canlı veri değil, maskelenmiş veri kullanılmalı. Yapay zeka servislerine giden veri için de aynı kural geçerli; KVKK uyumlu AI Ops katmanı yazımız bu konuyu işliyor.

Mevcut tedarikçilerinizi nereden başlayarak gözden geçirmelisiniz?

Çoğu şirkette tedarikçi listesi satın alma, BT ve iş birimleri arasında dağınıktır. İlk adım, kişisel veriye erişen tüm tedarikçileri tek bir listede toplamaktır: yazılım ve SaaS sağlayıcıları, barındırma firmaları, bakım ve destek ekipleri, çağrı merkezi ve pazarlama ajansları.

Riske göre önceliklendirin

Her tedarikçiyi üç soruyla puanlayın: Hangi veri kategorilerine erişiyor? Kaç kişinin verisine erişiyor? Erişimi kalıcı mı, süreli mi? Özel nitelikli veriye veya tüm müşteri tabanına kalıcı erişimi olan tedarikçiler listenin başına yazılır ve ilk değerlendirme onlarla yapılır.

Erişimi teknik olarak doğrulayın

Sözleşmede yazanla sistemde olan çoğu zaman farklıdır. Kimlik yönetimi ve VPN kayıtlarından tedarikçi hesaplarını çıkarın; kullanılmayan, ortak veya süresiz hesapları kapatın. Bu tek çalışma bile çoğu zaman en büyük riski ortadan kaldırır.

Tedarikçinin ihlal bildirimi neleri içermeli?

Sözleşmede bildirim süresinin yanında içeriği de tanımlayın: olayın fark edildiği zaman, etkilenen sistemler, veri kategorileri, tahmini kişi ve kayıt sayısı, alınan ilk önlemler ve tedarikçi tarafındaki irtibat kişisi. Bu bilgiler, Kurul'a yapacağınız bildirimin iskeletini oluşturur.

İhlal olduğunda ilk 72 saat nasıl yönetilir?

72 saatlik süre, veri sorumlusunun ihlali öğrendiği anda başlar. Tedarikçi olayı fark ettikten sonra size ne kadar geç haber verirse sizin analiz ve karar süreniz o kadar kısalır. Bu yüzden zaman çizelgesi önceden yazılmalı ve sözleşmedeki bildirim SLA'sına bağlanmalıdır.

• T0 (öğrenme): Olay kaydı açılır, karar sahibi ve KVKK irtibat kişisi devreye girer, tedarikçiden yazılı olay raporu istenir.
• T0 + 24 saat: Tedarikçi erişimi gerekirse kesilir; ilgili anahtar, şifre ve token'lar döndürülür; loglar ve imajlar delil olarak korunur.
• T0 + 48 saat: Etki analizi yapılır: hangi kişi grupları, hangi veri kategorileri, yaklaşık kaç kayıt.
• En geç T0 + 72 saat: Kurul'a bildirim yapılır. Bilinmeyen bilgiler varsa gerekçesiyle belirtilir ve sonradan tamamlanır.
• Sonrası: İlgili kişilere makul en kısa sürede bildirim, kök neden analizi ve sözleşme ile kontrol revizyonu.

Kurum'un teknik ve idari tedbirler üzerine hazırladığı video, ekiplerin ortak bir dil oluşturması için faydalı:

Yazılım tedarikçinize sormanız gereken 10 soru

Bu soruları yeni bir tedarikçi seçerken ve mevcut tedarikçilerin yıllık değerlendirmesinde kullanabilirsiniz. Her cevap için bir kanıt isteyin:

1. Verimize hangi kişiler, hangi hesaplarla ve hangi koşullarda erişebiliyor?
2. Destek erişimi kişiye özel mi, süreli mi ve MFA ile korunuyor mu?
3. Alt işleyenleriniz kimler, veri hangi ülkelerde duruyor ve değişiklikleri bize nasıl bildiriyorsunuz?
4. Bir ihlal fark ettiğinizde bize en geç kaç saat içinde, hangi kanaldan ve hangi bilgilerle haber veriyorsunuz?
5. Kişisel veriye erişim logları tutuluyor mu, ne kadar süre saklanıyor ve bize sunulabiliyor mu?
6. Veriler aktarımda ve depolamada şifreleniyor mu, anahtarları kim yönetiyor?
7. Son sızma testi ne zaman yapıldı ve kritik bulgular kapatıldı mı?
8. Yazılımınızın SBOM'unu paylaşabilir misiniz, kritik yamaları kaç gün içinde uyguluyorsunuz?
9. Test ve geliştirme ortamlarında canlı kişisel veri kullanılıyor mu?
10. Sözleşme sona erdiğinde verilerimizi nasıl iade ediyor, siliyor ve bunu nasıl belgeliyorsunuz?

Olay müdahale: rolleri ve iletişim kişilerini önceden belirleyin.

Gizli anahtarlar kodda değil, kasada durmalı.

Tedarikçi denetimi: politika değil, kanıt isteyin.

Aksiyon Soft nasıl yardımcı olur?

Aksiyon Soft olarak geliştirdiğimiz ve bakımını üstlendiğimiz sistemlerde bu soruların cevaplarını yazılı ve kanıtlı olarak veriyoruz. Yeni bir projede süreç bir keşif çalışmasıyla başlar: veri envanteri, erişim modeli ve tedarikçi zinciri çıkarılır. Ardından rol tabanlı erişim, log ve alarm içeren bir MVP kurulur, iki haftalık sprint demolarıyla ilerlenir; canlı geçiş sonrasında hypercare ve SLA'lı destek verilir.

Mevcut sistemleriniz için bakım ve destek hizmetimiz kapsamında erişim, log ve yama süreçlerini devralabiliyor; yeni ihtiyaçlar için kurumsal yazılım çözümleri geliştiriyoruz. Rol ve yetki yönetimi için rol tabanlı kurumsal yönetim ve self-servis çözümümüzü kullanıyoruz. Bir değerlendirme öncesinde güvenlik değerlendirmesi öncesi kontrol listemize de göz atabilirsiniz. Merkezimiz Samsun'da; Türkiye genelinde uzaktan çalışıyor, gerektiğinde planlı yerinde ziyaretler yapıyoruz.

Sık sorulan sorular

Tedarikçimizdeki bir veri ihlalini Kurul'a kim bildirir?

Bildirim yükümlülüğü veri sorumlusundadır. 2 Eylül 2026 duyurularında da veri işleyendeki tek bir olay için her veri sorumlusu kendi adıyla bildirim yaptı. Tedarikçinin görevi size hızlı ve eksiksiz bilgi vermektir.

72 saatlik süre ne zaman başlar?

Kurul'un 2019/10 sayılı kararına göre süre, veri sorumlusunun ihlali öğrendiği andan itibaren işler. Tedarikçinin size ne zaman haber verdiği bu yüzden kritik; sözleşmede bir bildirim süresi tanımlamak bu riski azaltır.

Tüm bilgiler netleşmeden bildirim yapılabilir mi?

Evet. 72 saat içinde bilinmeyen bilgiler varsa, bunların gerekçesiyle birlikte belirtilmesi ve sonradan tamamlanması mümkündür. 2 Eylül duyurularında da etkilenen kişi sayısının net olarak belirlenemediği yazıyordu.

Sözleşmeye "tüm sorumluluk tedarikçidedir" yazmak yeterli mi?

Hayır. KVKK m.12/2 müşterek sorumluluk öngörür ve Kurum da sorumluluğun sözleşmeyle devredilemeyeceğini belirtir. Sözleşme tedbirleri tanımlamak, kanıt istemek ve rücu ilişkisini düzenlemek için kullanılmalıdır.

Küçük bir yazılım tedarikçisinden bu kadar kanıt istemek gerçekçi mi?

Kanıtın biçimi ölçeğe göre değişebilir; bağımsız denetim raporu yerine bir sızma testi özeti veya örnek log kaydı yeterli olabilir. Önemli olan iddianın doğrulanabilir olmasıdır.

İhlal duyurusu ne kadar süre yayında kalır?

Kurul'un 2025/2451 sayılı kararına göre en fazla 60 gün. Veri sorumlusu ilgili kişilere bildirim yaptığını belgelerse duyuru daha erken kaldırılabilir.

Kaynaklar

• Kişisel Verileri Koruma Kurumu — Kamuoyu Duyurusu: veri ihlali bildirimleri ve ilanı (20.01.2026)
• Kişisel Verileri Koruma Kurumu — Veri İhlali Bildirimleri (2 Eylül 2026 duyuruları)
• Kişisel Verileri Koruma Kurumu — Veri Güvenliğine İlişkin Yükümlülükler (KVKK m.12)
• Kişisel Verileri Koruma Kurumu — Kişisel Verilerin Korunması Hakkında Doğru Bilinen Yanlışlar (PDF)
• CyberArts — KVKK gündemi: uyum süreleri, düzenlemeler ve 33 veri ihlali (09.09.2026)

Projenizi konuşalım

Yazılım tedarikçilerinizin erişim modelini gözden geçirmek, sözleşme ve kanıt listenizi teknik tarafla eşleştirmek veya mevcut sisteminize log, MFA ve rol tabanlı erişim eklemek istiyorsanız bizimle iletişime geçin. İlk görüşmede tedarikçi zincirinizi birlikte çizip en riskli üç noktayı belirleyelim.