- 01KVKK kişisel verinin mutlaka Türkiye'de tutulmasını şart koşmaz; yurt dışı aktarımında Kanun'un 9. maddesindeki mekanizmalardan biri uygulanmalıdır.
- 0219 Eylül 2026 itibarıyla Kurul yeterli korumanın bulunduğu ülkeler için henüz bir belirleme yayımlamamıştır.
- 03Standart sözleşme yurt dışı aktarımında uygun güvence yöntemlerinden biridir ve imzadan itibaren 5 iş günü içinde Kuruma bildirilmelidir.
- 04Altı aylık sınır yedek saklama süresi değildir; saklama ve imha politikası bulunan veri sorumlularında periyodik imha işlemleri arasındaki azami süredir.
- 05Kurumun teknik rehberi erişim, log, ağ güvenliği, şifreleme, yedekleme ve düzenli sızma testi gibi tedbirleri risk temelli olarak ele alır.
Kısaca
KVKK uyumlu bulut altyapısı diye tek bir sertifika veya zorunlu mimari yoktur. Uyum; hangi kişisel veriyi neden işlediğinizi, verinin nerede tutulduğunu, kimlerin erişebildiğini, hangi güvenlik tedbirlerinin uygulandığını ve işleme şartları sona erdiğinde verinin nasıl imha edildiğini gösterebilmenize bağlıdır. Dynamis Teknoloji, Raff platformunu sıfırdan geliştiren ekip olarak altyapı incelemesini veri akışı, erişim, kayıt ve yedek zinciri üzerinden yürütür.
KVKK uyumu veri konumundan önce veri akışını bilmekle başlar
İlk iş, kişisel verinin hangi sistemlere girdiğini ve hangi sistemlerden çıktığını göstermektir. Kanunun 12. maddesi veri sorumlusuna kişisel verilerin hukuka aykırı işlenmesini ve erişilmesini önleme, ayrıca verilerin muhafazasını sağlama yükümlülüğü getirir. Kurum da tek bir güvenlik modeli olmadığını; alınacak tedbirlerin veri sorumlusunun yapısına, faaliyetine, riskine ve işlenen verinin niteliğine göre belirlenmesi gerektiğini açıkça belirtir.
Bu nedenle "veri Türkiye'de, o halde KVKK uyumlu" yaklaşımı eksiktir. Türkiye'deki bir sunucuda paylaşılan yönetici hesabı kullanılıyor, log tutulmuyor veya yedeklere erişim sınırsızsa veri konumu tek başına sorunu çözmez.
Teknik envanteri şu dört soruyla çıkarın:
- Kişisel veri hangi uygulama, veritabanı, dosya alanı ve yedekte bulunuyor?
- Bu sistemlere hangi kullanıcı, servis hesabı ve yönetici erişebiliyor?
- Verinin başka bir ülkeye veya başka bir hizmet sağlayıcıya aktarımı var mı?
- İşleme amacı sona erdiğinde asıl veri ve kopyaları hangi süreçle siliniyor, yok ediliyor veya anonim hale getiriliyor?
Dynamis'te ilk altyapı kontrolünü bu dört sorunun sistem karşılıklarını çıkararak başlatıyoruz. Politika metnindeki veri kategorisi ile gerçek sunucu, depolama ve yedek envanteri aynı şeyi tarif etmiyorsa önce bu fark kapatılır.
Yurt dışı aktarım veri merkezinin adresinden daha geniştir
KVKK kişisel verinin mutlaka Türkiye'de tutulmasını zorunlu kılmaz. Ancak kişisel verinin yurt dışına aktarılması Kanunun 9. maddesindeki şartlara tabidir.
1 Haziran 2024'te yürürlüğe giren yeni sistem üç basamaklıdır:
- Aktarım yapılacak ülke, sektör veya uluslararası kuruluş için yeterlilik kararı varsa aktarım bu karar kapsamında yapılabilir.
- Yeterlilik kararı yoksa standart sözleşme, bağlayıcı şirket kuralları veya Kanunda sayılan diğer uygun güvencelerden biri kullanılabilir.
- Yeterlilik kararı ve uygun güvence yoksa yalnızca Kanunda sınırlı sayıda sayılan arızi hâllerden biri varsa aktarım yapılabilir.
19 Eylül 2026 itibarıyla Kurum, "yeterli korumanın bulunduğu ülkeler" için henüz bir belirleme yayımlamamıştır. Bu nedenle yurt dışındaki bir genel bulut bölgesinde kişisel veri tutuyorsanız aktarım mekanizmasını ayrıca belgelemeniz gerekir.
Standart sözleşme kullanılıyorsa imzadan itibaren 5 iş günü içinde Kuruma bildirim yapılmalıdır. Kurum bunun için elektronik bildirim modülü de sunmaktadır.
Yurt dışı aktarımı yalnızca ana veritabanına bakarak değerlendirmeyin. Şu bileşenleri de kontrol edin:
- Yedek ve arşiv depolaması
- Log ve gözlemlenebilirlik hizmetleri
- Destek erişimleri
- SaaS yönetim panelleri
- Dosya paylaşım ve hata takip sistemleri
- Felaket kurtarma bölgeleri
Türkiye'deki bir uygulamanın loglarını yurt dışındaki bir hizmete göndermek veya yedeğini yabancı bir bölgede tutmak da aktarım değerlendirmesine girebilir.
Teknik tedbirler riskinize göre seçilir
Kurumun Kişisel Veri Güvenliği Rehberi tek bir ürün veya mimari zorunlu tutmaz. Rehber; yetki matrisi, yetki kontrolü, erişim logları, kullanıcı hesap yönetimi, ağ güvenliği, uygulama güvenliği, şifreleme, sızma testleri, saldırı tespit ve önleme sistemleri, yedekleme ve veri maskeleme gibi tedbirleri sayar.
Bulut altyapısında bu tedbirleri uygulanabilir kontrollere dönüştürün:
| Kontrol alanı | Teknik uygulama | Kanıt |
|---|---|---|
| Kimlik ve erişim | Kişiye özel hesap, rol bazlı yetki, çok faktörlü doğrulama | Yetki matrisi, kullanıcı listesi, erişim değişikliği kayıtları |
| Log | Yönetici ve kritik veri erişimlerinin merkezi kaydı | Merkezi log kayıtları, log erişim yetkileri |
| Ağ güvenliği | Ağ segmentasyonu, gereksiz internet erişiminin kapatılması | Ağ şeması, güvenlik duvarı kuralları |
| Şifreleme | Aktarım ve saklama sırasında uygun şifreleme | Anahtar yönetim modeli, sertifika ve disk ayarları |
| Yama yönetimi | İşletim sistemi ve uygulama açıklarının düzenli kapatılması | Yama kayıtları, zafiyet tarama sonuçları |
| Sızma testi ve zafiyet taraması | Risk ve sistem değişikliklerine göre planlı test | Test raporu, bulgu ve kapatma kaydı |
| Yedekleme | Yetkisi sınırlı, geri dönüşü test edilen yedek | Yedek politikası, geri dönüş testi kayıtları |
Kurumun rehberi sızma testi ve zafiyet taramasının düzenli yapılmasını ister; ancak tüm kuruluşlar için sabit "yılda bir kez" frekansı belirlemez. Test sıklığını risk, sistem değişikliği ve kendi güvenlik politikanıza göre belirleyin.
Bulut sistemlerinde iki kademeli kimlik doğrulama da Kurumun kararlarında ve rehber yaklaşımında önemli bir kontroldür. Özellikle uzaktan yönetim erişiminde yalnızca parola kullanmak yerine ikinci faktör uygulayın.
Log kaydı yalnızca toplamak değil, ilişkilendirebilmektir
Logların amacı "log tutuyoruz" demek değil, bir olayda kimin ne yaptığını gösterebilmektir. Paylaşılan yönetici hesapları bu ilişkiyi bozar.
Her yöneticinin ayrı hesabı olmalı; kritik değişiklik ve erişimler zaman, kullanıcı ve kaynak bilgisiyle kaydedilmelidir. Log sisteminin kendisine erişim de sınırlandırılmalıdır. Mümkün olduğunda logları uygulama sunucusundan ayrı bir sisteme gönderin; böylece tek bir sunucudaki yetki artışı hem veriyi hem de olay kaydını aynı anda etkileyemez.
Log saklama süresi için KVKK'da tüm sistemlere uygulanacak tek bir sayı yoktur. Süreyi hukuki yükümlülük, olay müdahale ihtiyacı, veri minimizasyonu ve kendi saklama politikanızla birlikte belirleyin.
Şifreleme anahtar yönetimiyle birlikte anlamlıdır
Şifreleme kişisel veri güvenliğinde önemli bir teknik tedbirdir ancak tek başına yeterli değildir. Anahtarın kimde olduğu, nasıl döndürüldüğü ve hangi yöneticilerin anahtara erişebildiği de tasarımın parçasıdır.
Disk şifrelemesi, veritabanı şifrelemesi ve aktarım sırasında TLS farklı riskleri azaltır. Hangi katmanın gerekli olduğu iş yüküne göre değişir. Özel nitelikli kişisel veriler veya yüksek etkili sistemlerde anahtar yönetimini veri erişiminden ayrı bir yetki alanına ayırmak daha güçlü kontrol sağlar.
Dynamis özel bulut projelerinde veri, ağ ve yönetim erişimini ayrı katmanlar olarak ele alır; şifreleme anahtarının da aynı yönetici hesabında toplanmaması hedeflenir.
Yedeklerde saklama süresi ile imha periyodunu karıştırmayın
KVKK mevzuatında "kişisel veri içeren yedek en fazla 6 ay tutulabilir" şeklinde genel bir kural yoktur. Altı aylık sınır, saklama ve imha politikası bulunan veri sorumlularının periyodik imha işlemleri arasındaki en uzun süredir.
Saklama süresi ise verinin işlenme amacı ve ilgili hukuki yükümlülüklere göre belirlenir. Bir veri sınıfını beş yıl saklamanız gerekiyorsa, yedek kopyalar için de bu hukuki ve teknik gereksinimi dikkate alan bir politika kurabilirsiniz. Ancak işleme şartları ortadan kalktığında veri ilk periyodik imha döngüsünde silinmeli, yok edilmeli veya anonim hale getirilmelidir.
Yedek mimarisinde şu ayrımı yazılı hale getirin:
| Konu | Sorulacak soru |
|---|---|
| Saklama süresi | Bu veri neden ve ne kadar süre tutuluyor? |
| Periyodik imha | İşleme şartı bittiğinde en geç hangi imha döngüsünde işlenecek? |
| Yedek erişimi | Kim geri yükleme yapabilir? |
| Geri dönüş | Silinmesi gereken veri eski yedek geri yüklendiğinde nasıl yeniden silinecek? |
| Yurt dışı aktarım | Yedek hangi ülkede veya bölgede tutuluyor? |
Eski bir yedeği üretime geri yüklemek, daha önce silinmiş kişisel verileri tekrar aktif sisteme getirebilir. Bu nedenle geri dönüş prosedürüne "yeniden imha" adımı ekleyin.
Özel bulut ile genel bulut arasındaki karar kontrol ihtiyacına bağlıdır
KVKK özel bulutu zorunlu tutmaz ve genel bulutu yasaklamaz. Karar; veri sınıfı, erişim modeli, yurt dışı aktarım ihtiyacı, anahtar yönetimi ve denetim kanıtlarına göre verilmelidir.
| Durum | Daha uygun başlangıç noktası |
|---|---|
| Veri konumu üzerinde doğrudan kontrol isteniyor | Türkiye'de özel bulut veya uygun yerel altyapı |
| Yurt dışı genel bulut kullanılacak | Kanun 9 aktarım mekanizması + teknik tedbirler |
| Çok sıkı ağ ayrımı ve özel erişim modeli gerekiyor | Özel bulut veya izole edilmiş mimari |
| Global servislerden yararlanmak gerekiyor | Aktarım dayanağı ve veri akış haritası ile genel/hibrit bulut |
| Kişisel veri ve kişisel olmayan iş yükleri ayrılabiliyor | Hibrit mimari |
Veriyi Türkiye'de tutmak yurt dışı aktarım yükünü azaltabilir; fakat erişim, log, şifreleme, saklama ve imha sorumluluklarını ortadan kaldırmaz.
Uygulamada Dynamis altyapı tarafını kanıtlanabilir hale getirir
Dynamis'in rolü hukuki uygunluk görüşü vermek değil, hukuk ve uyum ekibinizin belirlediği gereksinimleri teknik kontrollere dönüştürmektir. Veri sorumlusu sıfatı, işleme amacı ve aktarım hukuki sebebi sizin tarafınızda değerlendirilmelidir.
Özel bulut yönetim platformu ile Türkiye'de konumlandırılan altyapılarda erişim sınırları, ağ segmentasyonu, log toplama, yedek politikası ve yönetim katmanını birlikte tasarlayabiliriz. Kullanılan altyapının ISO 27001 sertifikalı olması süreç için bir güven sinyali olabilir; ancak sertifika Dynamis'in veya Raff'ın KVKK uyumunu otomatik olarak kanıtlamaz.
Dynamis'in kendi ISO 27001 çalışması hazırlık sürecindedir. Bu nedenle içerikte "ISO 27001 sertifikalı Dynamis" veya "KVKK sertifikalı altyapı" gibi ifadeler kullanmıyoruz.
Sık yapılan hatalar
Veri Türkiye'de olduğu için uyumlu saymak: Veri konumu yalnızca bir değişkendir. Erişim, log, şifreleme ve saklama politikası ayrıca çalışmalıdır.
Altı ay kuralını saklama süresi sanmak: Altı ay, periyodik imha aralığının üst sınırıdır. Her veri için zorunlu saklama tavanı değildir.
Yurt dışı yedeği envantere almamak: Yedek, log veya destek sistemi kişisel veri taşıyorsa aktarım değerlendirmesine dahil edilmelidir.
Paylaşılan yönetici hesabı kullanmak: Olay kaydını gerçek kişiye bağlamayı zorlaştırır. Kişiye özel hesap ve uygun ikinci faktör kullanın.
Sızma testini yıllık takvim kutusu gibi görmek: Rehber düzenli test ister. Sıklığı sistem değişikliği, risk ve güvenlik politikasına göre belirleyin.
Sertifikayı mevzuat uyumunun yerine koymak: ISO 27001 bilgi güvenliği yönetimini destekler; veri işleme hukuki sebebini, aydınlatma yükümlülüğünü veya yurt dışı aktarım mekanizmasını sizin yerinize çözmez.
Sırada ne var
- KVKK uyumlu yedekleme: saklama süresi ve imha: kişisel veri saklama süresi, 6 aylık periyodik imha ve backup retention ayrımını uygulayın.
- Yedek geri yükleme testi: aylık restore planı: kişisel veri içeren yedekleri test ortamına geri döndürürken RPO/RTO ve veri temizleme sürecini doğrulayın.
- 3-2-1 yedekleme kuralı ve felaket kurtarma planı: yedek, geri dönüş ve kopya ayrımını planlayın.
- Veri yerelleştirme nedir? KVKK'da yurt dışı aktarım: veri konumu, standart sözleşme ve yurt dışı aktarım mekanizmalarını ayrı değerlendirin.
- Özel bulut mu, genel bulut mu? KVKK açısından karar: teknik kontrollerden önce workload için doğru cloud modelini belirleyin.
- AWS alternatifi: hangi iş yükü nerede kalmalı?: KVKK ve veri konumu gereksinimi olan workload'ların AWS, hibrit veya özel bulut yerleşimini karşılaştırın.
- AWS'den çıkış: maliyeti düşüren bulut göçü: veri konumu ve bulut göçünü aynı mimaride değerlendirin.
- Microsoft SPLA nedir?: Windows iş yüklerinde lisans sorumluluğunu altyapı sorumluluğundan ayırın.
- Özel bulut yönetim platformu: teknik kontrolleri Türkiye'de konumlanan özel altyapıya uygulayın.
Kaynaklar
Kaynaklar
- 1.Veri Güvenliğine İlişkin YükümlülüklerKişisel Verileri Koruma Kurumu · 2026-09-19
- 2.Yurt Dışına AktarımKişisel Verileri Koruma Kurumu · 2026-09-19
- 3.Standart Sözleşme Bildirim Modülü Hakkında Kamuoyu DuyurusuKişisel Verileri Koruma Kurumu · 2026-09-19
- 4.Kişisel Verilerin Silinmesi, Yok Edilmesi veya Anonim Hale Getirilmesi Hakkında YönetmelikKişisel Verileri Koruma Kurumu · 2026-09-19
- 5.Kişisel Veri Güvenliği Rehberi (Teknik ve İdari Tedbirler)Kişisel Verileri Koruma Kurumu · 2026-09-19
Sık sorulan sorular
KVKK uyumu için verim Türkiye'de mi durmalı?
Hayır. KVKK kişisel verinin mutlaka Türkiye'de tutulmasını şart koşmaz. Yurt dışı aktarımında Kanun'un 9. maddesindeki aktarım mekanizmalarından biri uygulanmalıdır; veri konumu tek başına uyum sağlamaz.
KVKK ve ISO 27001 aynı şey mi?
Hayır. KVKK kişisel veri işleme ve güvenliği için hukuki yükümlülükler getirir; ISO 27001 bilgi güvenliği yönetim standardıdır. ISO 27001 kontrolleri süreci destekleyebilir ancak sertifika tek başına KVKK uyumu anlamına gelmez.
KVKK teknik tedbirler nelerdir?
Kurumun rehberi yetki matrisi, erişim kontrolü, kullanıcı hesap yönetimi, erişim logları, ağ ve uygulama güvenliği, şifreleme, yedekleme, güvenlik duvarları, sızma testleri ve veri maskeleme gibi tedbirleri sayar.
Yedeklerdeki kişisel veri ne zaman silinmeli?
Yedekteki veri için saklama süresi işleme amacı ve hukuki yükümlülüğe göre belirlenir. İşleme şartları ortadan kalkınca veri ilk periyodik imhada silinir, yok edilir veya anonimleştirilir; periyodik imha aralığı en fazla 6 aydır.
Hangi durumda özel bulut seçilmeli?
Veri konumu, ağ ayrımı, anahtar yönetimi veya fiziksel altyapı üzerinde daha fazla kontrol gerekiyorsa özel bulut değerlendirilebilir. KVKK özel bulutu zorunlu kılmaz; seçim risk, veri sınıfı ve yurt dışı aktarım modeline göre yapılmalıdır.