KVKK ve Veri Yurt Dışına Aktarım: Bulut Kullanırken Nelere Dikkat Edilmeli?

Kısa cevap: Yurt dışında sunucusu olan bir bulut hizmeti kullanmak, KVKK açısından veri aktarımıdır ve kendi hukuki dayanağını gerektirir. En sık atlanan nokta yedekler: üretim verisi Türkiye'de olup yedeği başka ülkede duran bir mimari, sorunun yalnızca yarısını çözmüştür.

"Verimiz Türkiye'de" cümlesini çok duyuyoruz. Sorduğumuzda genelde üretim veritabanının bulunduğu yer kastediliyor. Sonra devam ediyoruz: yedekler nerede? Log'lar hangi servise gidiyor? Destek ekibi nereden bağlanıyor? Cevaplar çoğu zaman farklı ülkeleri gösteriyor.

Bu yazı, bulut kullanan bir kurumun aktarım açısından nerelere bakması gerektiğini anlatıyor.

Aktarım nerede başlar

Kişisel verinin yurt dışındaki bir sunucuya kaydedilmesi aktarımdır. Ama sadece o değil. Pratikte gözden kaçan dört kanal var:

Yedekler ve replikalar. Felaket kurtarma kopyanız yurt dışındaysa, veri orada duruyor demektir. Kurumların çoğu üretim tarafını doğru kurup bu tarafı atlıyor.

Log ve telemetri. Uygulama hatalarını toplayan servis, kullanıcı analitiği, hatta bazı izleme araçları kişisel veri taşıyabilir ve genelde yurt dışına gider. Bir hata kaydının içinde e-posta adresi ya da IP varsa, o kayıt kişisel veri içeriyor demektir.

Uzaktan destek erişimi. Tedarikçinizin yurt dışındaki destek ekibi sisteme bağlanıp veriye erişiyorsa, bu da bir aktarımdır; veri fiziksel olarak yerinde dursa bile.

SaaS entegrasyonları. CRM, e-posta, dosya paylaşımı, hatta bir form aracı. Bunların çoğu yurt dışında barındırılıyor ve kimse bunları "veri aktarımı" başlığı altında düşünmüyor.

Hangi mekanizmayla aktarılıyor?

Bu tarafta 2024'te önemli bir değişiklik oldu ve pek çok kurum hâlâ eski tabloya göre çalışıyor. Kişisel Verilerin Yurt Dışına Aktarılmasına İlişkin Usul ve Esaslar Hakkında Yönetmelik 10 Temmuz 2024'te Resmî Gazete'de yayımlanarak yürürlüğe girdi ve aktarım araçlarını netleştirdi.

Sıralama önemli. Önce yeterlilik kararı aranıyor: Kurul'un yeterli korumaya sahip saydığı bir ülkeye aktarım yapıyorsanız ek bir araca ihtiyaç yok. Böyle bir karar yoksa uygun güvence sağlayan araçlara geçiliyor:

Standart sözleşme.

Bağlayıcı şirket kuralları.

Taahhütname ve Kurul izni.

Standart sözleşmenin operasyonel bir tuzağı var ve en çok burada takılınıyor: sözleşmeyi imzalamak yetmiyor, imza tarihinden itibaren beş iş günü içinde Kurul'a bildirim yapmak zorunlu. Bu süre kaçırıldığında dayanağın kendisi sorunlu hâle geliyor. Bulut sözleşmeleri hukuk biriminde imzalanıp teknoloji tarafında devreye alındığı için, bildirim ikisinin arasında kalıp unutuluyor.

Bunun pratik sonucu şu: yurt dışına aktarım artık bir kerelik hukuki mesele değil, takvimi olan bir süreç. Her yeni SaaS aboneliği, aynı zamanda beş iş günlük bir sayaç başlatıyor olabilir.

Ayrıca iki uyarı:

Açık rıza operasyonel bir çözüm değildir. Rıza her zaman geri alınabilir ve bir çalışanın rızasını geri alması durumunda o kişinin verisini bulut sisteminizden çıkarmanız gerekir. Bir altyapı kararını geri alınabilir bir izne dayandırmak, kırılgan bir kurgu üretir. Yönetmelik de açık rızayı istisnai ve arızi durumlar için konumlandırıyor.

Mekanizma seçimi bir kere yapılıp bırakılmaz. Ülke değerlendirmeleri ve Kurul kararları değişebilir; bugün geçerli bir dayanak, iki yıl sonra gözden geçirilmeyi gerektirebilir.

Sözleşmede aranması gerekenler

Bulut tedarikçinizle sözleşmede şu maddelerin yazılı olması, denetimde işinizi görecek olan şeydir:

Verinin bulunduğu ülke ve tesis. Bölge adı düzeyinde değil, mümkünse tesis düzeyinde. "Avrupa bölgesi" ifadesi, hangi ülke olduğunu söylemez.

Yedeklerin konumu. Ayrı bir madde olarak. Üretimle aynı taahhüt kapsamında olduğunu varsaymayın.

Alt işleyen listesi ve değişiklik bildirimi. Tedarikçiniz kendi tedarikçilerini kullanıyor olabilir. Bu listenin verilmesi ve değiştiğinde size bildirilmesi gerekir.

Destek erişim politikası. Kimler, hangi ülkeden, hangi durumda verinize erişebiliyor. Erişim kaydı tutuluyor mu.

İhlal bildirim süresi. Bir veri ihlalinde size ne kadar sürede haber verilecek. Sizin Kurul'a bildirim süreniz var; tedarikçiniz sizi geç haberdar ederse o süreye yetişemezsiniz. Kaydın kendisinin ne kadar tutulacağını log saklama süreleri yazısında ele aldık.

Sözleşme sonu veri iadesi ve imhası. Ayrılırken veriniz nasıl geri verilecek, kopyalar ne zaman silinecek, silindiği nasıl belgelenecek.

Veri envanteri olmadan hiçbiri işlemez

Yukarıdaki maddelerin hepsi, hangi verinin nerede olduğunu bilmenizi varsayıyor. Kurumların çoğunda bu envanter ya yok ya da bir kez yapılıp güncellenmemiş.

Envanter çıkarmanın en pratik yolu sistemden değil süreçten başlamak: bir müşteri kaydı hangi sistemlere giriyor, hangi ekipler görüyor, nereye kopyalanıyor. Teknik envanter bu haritanın üzerine oturuyor.

Eclit'in görüşü

Veri yerelleştirme, Türkiye'de yerel altyapı işleten sağlayıcıların lehine bir düzenleme; ve biz o taraftayız, bunu açıkça söyleyelim. Ama "her şeyi Türkiye'de tutun" demek doğru tavsiye değil.

Doğru yaklaşım veriyi sınıflandırmak: kişisel veri ve düzenlemeye tabi veri yerelde, geri kalanı maliyet ve yetenek neredeyse orada. Her şeyi yerele çekmek, uyum sorunu olmayan iş yükleri için gereksiz maliyet üretir; her şeyi dışarı vermek ise çözülemeyecek bir uyum borcu.

Ayrımı baştan yapmak, sonradan ayırmaktan hem ucuz hem güvenlidir. Yapay zekâ tarafında aynı ayrımın nasıl kurulacağını GPU satın almak mı kiralamak mı ve egemen yapay zekâ yazılarında, bankacılıktaki sert karşılığını BDDK bulut bilişimi dış hizmet sayıyor yazısında anlattık.

Kaynaklar

KVKK, Kişisel Verilerin Yurt Dışına Aktarılması Rehberi

KVKK ve GDPR uyumu

Bu yazı genel bilgilendirme amacıyla hazırlanmıştır, hukuki görüş değildir. Aktarım mekanizmanızı ve dayanağınızı kendi hukuk danışmanınızla belirlemenizi öneririz; güncel Kurul kararları için KVKK'nın kendi yayınlarına başvurun.