Bulut Geçişinde Veri Kaybı ve Vendor Lock-in: Sağlayıcının Sorumluluğu

Kısa cevap: Bulut geçişinde veri kaybı veya sağlayıcıya bağımlılık yaşandığında sorumluluk, “bulut kullanmak müşterinin riskidir” denilerek tek cümlede çözülemez. Yedekleme, geri yükleme, veri dışa aktarımı, RPO/RTO, alt hizmetler ve geçiş desteği sözleşmede kime verilmişse önce o borç incelenir. Sağlayıcının sorumluluğu için ihlal, kusur, zarar ve nedensellik bağı somut kayıtlarla gösterilmelidir. Müşterinin kendi yedeğini almaması da tazminat hesabında etkili olabilir. En güvenli yaklaşım; göç başlamadan tam envanter, doğrulanmış yedek, geri dönüş planı ve açık formatta veri çıkışı testidir. Veriler silinme riski altındaysa delil ve kopya koruması geciktirilmemelidir.

Bulut geçişi hangi sözleşme ilişkilerini doğurur?

Bulut geçişinde çoğu zaman tek sağlayıcı yoktur. Müşteri, göç danışmanı, bulut altyapı işletmecisi, yönetilen hizmet sağlayıcısı ve yazılım üreticisi farklı edimleri üstlenebilir. Veri kopyalama hatası göç danışmanından, depolama silinmesi altyapı politikasından, erişilemeyen kayıt ise uygulamanın kapalı veri modelinden kaynaklanabilir. Bu nedenle talep yöneltmeden önce olayın teknik katmanı ve her tarafın sözleşmesel rolü ayrıştırılmalıdır.

Ana hizmet sözleşmesi, iş emri, mimari tasarım, hizmet seviyesi eki, veri işleme eki ve çevrim içi sağlayıcı koşulları birlikte değerlendirilir. Çevrim içi hükümlerin tek taraflı değiştirilebildiği durumlarda olay tarihindeki sürüm saklanmalıdır. Genel sözleşmeye aykırılık esasları bakımından sözleşmeye aykırılık nedeniyle tazminat rehberi zarar ve kusur değerlendirmesine temel sağlar.

Paylaşılan sorumluluk matrisi neden gereklidir?

Bulut sağlayıcısı fiziksel altyapıyı korurken müşterinin kullanıcı yetkileri, yanlış yapılandırma veya uygulama verisinden sorumlu olduğu modeller yaygındır. Ancak “paylaşılan sorumluluk” ifadesi hangi katmanı kimin yönettiğini göstermedikçe savunma aracı hâline gelir. Sözleşme eki; kimlik yönetimi, şifreleme anahtarları, güvenlik grupları, günlükleme, yama, yedek, zararlı yazılım koruması ve olay bildirimi için sorumlu kişiyi göstermelidir.

Göç döneminde eski ve yeni sistem birlikte çalışıyorsa ara sorumluluk ayrıca yazılır. Son senkronizasyonu kimin başlatacağı, değişikliklerin dondurulacağı saat, mutabakat raporunu kimin onaylayacağı ve başarısızlıkta hangi sisteme dönüleceği belirlenmelidir. Proje planındaki teknik “owner” ile sözleşmedeki hukuki yükümlü aynı kişi olmayabilir; iki belge uyumlu olmalıdır.

Göç öncesi sorumluluk kontrolü

• Kaynak veri sahibi ve veri kalitesi sorumlusu,
• Yedek alma ve geri yükleme testini yapacak ekip,
• Aktarım sırasında şifreleme anahtarını yönetecek taraf,
• Kayıt sayısı ve hash mutabakatını onaylayacak kişi,
• Kesinti kararı ile geri dönüş kararını verecek yetkili,
• Alt yüklenici ve veri merkezi değişimini bildirecek taraf,
• Eski ortamı silme onayını verecek kurul veya yönetici.

RPO ve RTO sözleşmede ne anlama gelir?

RPO, bir olayda kabul edilebilir veri kaybı penceresini; RTO ise hizmetin hedeflenen geri dönüş süresini ifade eder. Bunlar garanti ile hedef arasında bırakılmamalıdır. Ölçüm başlangıcı, olayın tespiti mi bildirilmesi mi; geri dönüş ise ekranın açılması mı bütün işlevlerin doğrulanması mı soruları cevaplanmalıdır.

Örneğin dört saatlik RPO, her durumda dört saatten az veri kaybı olacağı anlamına gelebilmesi için yedek sıklığı, replikasyon ve başarısız yedek uyarısı ile desteklenmelidir. RTO’ya ulaşılması da verinin tutarlı olduğu anlamına gelmez. Geri yüklenen sistemde sipariş sayısı, muhasebe toplamı ve dosya ekleri ayrı doğrulanmalıdır.

RPO/RTO ihlalinin sonucu hizmet kredisi, düzeltme planı, ek yedek veya fesih olarak kademeli düzenlenebilir. Kritik hizmetlerde tekrar eden başarısız testler, olay meydana gelmeden de sözleşmeye aykırılık sayılabilir. Yılda en az bir kontrollü felaket kurtarma tatbikatının kapsamı ve raporu sözleşmede belirlenmelidir.

Veri kaybı fark edilince hangi adımlar atılmalı?

İlk refleks rastgele geri yükleme veya üzerine yazma olmamalıdır. Olay komuta kaydı açılır; etkilenen hesap, bölge, veri tabanı, zaman aralığı ve son bilinen sağlıklı kopya belirlenir. Otomatik yaşam döngüsü ve silme işleri durdurulur. Erişim günlükleri, yönetim paneli olayları, yedek kataloğu ve faturalama kayıtlarının koruma altına alınması istenir.

1. Kaybın kapsamını değiştirmeden salt okunur görüntü veya snapshot alın.
2. Sağlayıcıya sözleşmedeki acil kanaldan kayıt açın ve kayıt numarasını saklayın.
3. Son başarılı yedek ile geri yükleme testinin tarihini doğrulayın.
4. Kişisel veri etkisi varsa veri ihlali değerlendirmesini ayrı başlatın.
5. İş sürekliliği için geçici sistemi devreye alın; delilleri ezmeyin.
6. Zarar kalemlerini olay günü itibarıyla ayrı maliyet merkezinde kaydedin.

Kişisel veri ihlali ile sözleşmesel veri kaybı aynı süreç değildir. Bir olay her ikisini doğurabilir; Kuruma ve ilgili kişilere bildirim yükümlülüğü ile sağlayıcıya karşı tazminat talebi farklı hukuk yollarıdır. Kişisel veri zararlarının özel çerçevesi için kişisel veri ihlalinde tazminat yazısı incelenebilir.

Yedekleme ve geri yükleme borcu nasıl kurulmalı?

Sağlayıcının altyapı replikasyonu, müşterinin bağımsız yedeği ile aynı şey değildir. Replikasyon, yanlış silme veya bozuk veriyi diğer bölgeye de taşıyabilir. Sözleşmede tam ve artımlı yedek sıklığı, saklama süresi, coğrafi ayrılık, şifreleme, değişmez kopya, geri yükleme sırası ve test periyodu yazılmalıdır.

“Müşteri yedeğinden sorumludur” hükmü varsa sağlayıcının ayrıca sattığı yedek hizmetinin kapsamı daralmış sayılmaz. Ürün ekranında “günlük yedek” vaadi ile genel koşuldaki kapsam dışılık çelişirse belgelerin öncelik sırası önem kazanır. Müşterinin makul yedek almaması zararın artmasına katkı olarak tartışılabilir; buna karşılık sağlayıcının açık taahhüdünü tamamen ortadan kaldırmaz.

Geri yükleme testi üretim verisini riske atmadan ayrı ortamda yapılmalı, başarısı raporlanmalıdır. Yedeğin mevcut görünmesi değil, kullanılabilir ve tutarlı olması aranır. Şifreleme anahtarının kaybı halinde veri teknik olarak var olsa bile erişilemez olabileceğinden anahtar yedeği de planın parçasıdır.

Vendor lock-in hangi hükümlerle azaltılır?

Vendor lock-in, bir sağlayıcıdan ayrılmanın teknik, hukuki veya ekonomik olarak aşırı zorlaşmasıdır. Yalnız özel teknoloji kullanılması değil; veri formatının kapalı tutulması, aşırı çıkış ücreti, kısa dışa aktarım penceresi, eksik dokümantasyon ve yönetici hesabının sağlayıcıda kalması da bağımlılık yaratır.

Çıkış maddesinde veri setleri, format, şema, meta veri, dosya ekleri, loglar ve yapılandırma tanımlanmalıdır. Sağlayıcının standart egress ücretleri başlangıçta bilinmeli; olağanüstü artış veya fesih sonrası danışmanlık bedeli sınırlandırılmalıdır. Geçiş desteğinin saat kotası, yanıt süresi ve yeni sağlayıcıyla iş birliği borcu belirtilmelidir.

Taşınabilirlik testi

Sözleşme imzalanırken küçük bir örnek veri dışa aktarılıp bağımsız ortamda açılmalıdır. Bir dosyanın indirilmesi yeterli değildir: kimlikler, ilişkiler, zaman damgaları, ekler ve silme işaretleri korunuyor mu kontrol edilir. Uygulama özel API kullanıyorsa sürüm desteği ve kullanım limitleri exit planına bağlanır. Müşteri, yalnız son gün sağlayıcının hazırlayacağı dönüşüme güvenmemelidir.

Veri konumu, alt sağlayıcı ve KVKK aktarımı

Kişisel verinin yurt dışındaki veri merkezinde tutulması veya yurt dışındaki destek ekibince erişilmesi, KVKK bakımından aktarım değerlendirmesi gerektirebilir. Veri merkezi adı, ülke, yedek bölgesi ve alt işleyen listesi güncel tutulmalıdır. Teknik şifreleme tek başına her aktarımı hukuk dışı bırakmaz veya kendiliğinden hukuka uygun hâle getirmez.

6698 sayılı Kanun’daki güncel yurt dışı aktarım mekanizmalarından somut akışa uygun olanı kurulmalıdır. Standart sözleşme kullanılacaksa taraf, veri kategorisi ve aktarım faaliyeti doğru eşleştirilmelidir. Sağlayıcının bölgeyi tek taraflı değiştirmesi halinde ön bildirim ve müşterinin itiraz veya fesih hakkı bulunmalıdır.

Hangi zararlar ve sorumluluk sınırları tartışılır?

Veri yeniden oluşturma maliyeti, dış uzman ücreti, geçici sistem, operasyon durması, doğrulanmış müşteri iadeleri ve bazı durumlarda kazanç kaybı talep konusu olabilir. Her kalem için gerçek ödeme, makuliyet ve olayla nedensellik gösterilmelidir. Varsayımsal şirket değer kaybı, somut mali kayıttan daha zor ispatlanır.

Sözleşmeler çoğu kez sorumluluğu son on iki aylık ücretle sınırlar ve dolaylı zararı hariç tutar. Tavanın hangi iddialara uygulandığı, olay başına mı toplam mı olduğu ve veri kaybı, gizlilik, fikrî hak, kasıt veya ağır kusur istisnaları incelenir. Türk Borçlar Kanunu’ndaki sorumsuzluk anlaşmalarına ilişkin emredici sınırlar saklıdır. Zarar gören müşteri de zararı büyütmemek için makul geçici önlemleri almalıdır.

Bildirim süresi, zamanaşımı ve ön başvuru

Bulut olayları için sözleşmede çok kısa itiraz veya kredi talep süresi bulunabilir. Olay kaydı açılması, tazminat ihtarı ve veri ihlali bildirimi birbirinin yerine geçmez. Sağlayıcıya gönderilecek yazıda olay zamanı, etkilenen hizmet, korunması istenen kayıtlar, ön zarar ve talep açık olmalıdır. Teknik inceleme tamamlanmadıysa haklar saklı tutularak ek rapor süresi istenebilir.

Sözleşmeye aykırılıkta uygulanacak zamanaşımı, ilişkinin hukuki niteliği ve talep türüne göre belirlenir; özel süre yoksa genel süre gündeme gelebilir. Fikrî hak, haksız fiil veya kişisel veri talepleri aynı başlangıç ve süreye tabi olmayabilir. Sözleşmedeki kısa bildirim hükmü de kanuni zamanaşımıyla karıştırılmamalıdır.

Tacirler arasındaki para alacağı veya tazminat davasından önce kural olarak arabulucuya başvurulur. Veri kopyasının teslimi ya da silmenin durdurulması gibi para dışı ve acil talepler ayrıca incelenir. Arabuluculuk başvurusu hazırlanırken teknik olay çizelgesi ve zarar tablosu, genel ifadelerden daha yararlıdır.

Görev, yetki ve uygulanacak hukuk

İki ticari işletme arasındaki bulut hizmeti uyuşmazlığı çoğunlukla asliye ticaret mahkemesinin görev alanındadır. Geçerli tahkim şartı varsa hakem heyeti yetkili olabilir. Sağlayıcının yabancı olması, Türkiye’de hiçbir yol bulunmadığı anlamına gelmez; hukuk seçimi, yetki şartı, ifa yeri ve kararın icra edileceği ülke birlikte değerlendirilir.

Bulut sunucusunun bulunduğu ülke ile sözleşmenin ifa yeri veya yetkili mahkeme her zaman aynı değildir. Standart çevrim içi şartlarda yabancı mahkeme seçimi bulunuyorsa hükmün taraf sıfatları ve kurulma biçimi incelenir. Acil delil veya tedbir için esas uyuşmazlığı görecek merci dışında verinin bulunduğu yer mahkemesinin yetkisi de somut olaya göre gündeme gelebilir.

İspat yükü ve delil tablosu

Müşteri kaybolan verinin olaydan önce varlığını, sağlayıcının üstlendiği borcu, kaybı ve zararını göstermelidir. Sağlayıcı; müşterinin yanlış yapılandırması, izin verilen risk veya sözleşmeye uygun geri yükleme savunmasına dayanıyorsa ilgili teknik kayıtları sunar. Deliller farklı tarafların sisteminde olduğundan erken koruma yazısı kritik önem taşır.

İhtiyati tedbir ve delil tespiti

Sağlayıcının hesabı kapatacağı, kısa saklama süresindeki logları sileceği veya tek kalan yedeğin üzerine yazılacağı yönünde somut risk varsa ihtiyati tedbir ve delil tespiti değerlendirilebilir. Talep, korunacak hesabı, veri kümesini, tarih aralığını ve işlemi teknik olarak anlaşılır biçimde sınırlamalıdır. “Bütün bulutun kopyalanması” gibi ölçüsüz bir istem hem uygulanamaz hem üçüncü kişi verilerini etkileyebilir.

Mahkeme yaklaşık ispat ve teminat arayabilir. Bağımsız uzmanla alınan sistem görüntüsünün bütünlüğü, hash ve teslim zinciriyle belgelenmelidir. Tedbir alınması, tazminat davasının kazanılacağı anlamına gelmez; yalnız mevcut durumu veya delili korur.

Üç bulut uyuşmazlığı senaryosu

Senaryo 1: Göçte son iki günlük siparişler eksik

Kesim saatinden sonra eski sisteme gelen siparişler yeni ortama aktarılmamıştır. Danışman “müşteri değişikliği dondurmadı”, müşteri ise artımlı senkronizasyonun teklif kapsamında olduğunu söyler. Proje planı, son senkronizasyon işi, kayıt toplamları ve onay tutanağı karşılaştırılır. Eksik siparişler eski sistemde duruyorsa önce güvenli kopya ve tamamlama yapılır; zarar, gerçekten iade veya yeniden işlem gerektiren kayıtlarla hesaplanır.

Senaryo 2: Yedek görünüyor fakat geri yüklenemiyor

Panelde otuz günlük yedek listesi vardır; fidye saldırısından sonra hiçbir kopya açılmaz. İncelemede yedek hizmetinin kapsamı, son test raporu, şifreleme anahtarı, hata uyarıları ve müşterinin bağımsız kopya yükümlülüğü araştırılır. Sadece ekranda yeşil işaret bulunması yeterli teknik teslim sayılmayabilir. Kurtarma çalışması sürerken bozuk kopyaların üzerine yazılmaması sağlanır.

Senaryo 3: Çıkış ücreti proje bedelini aşıyor

Müşteri sağlayıcı değiştirmek ister; platform büyük egress ücreti ve zorunlu danışmanlık paketi çıkarır. Olay tarihindeki tarife, fiyat artış bildirimi, sözleşmedeki çıkış desteği ve verinin standart araçla çekilip çekilemediği incelenir. Ücretin yüksek olması tek başına hukuka aykırılık sonucu doğurmaz; öngörülebilirlik, sözleşme ve dürüstlük kuralı bağlamında değerlendirme yapılır. Önce örnek dışa aktarım alınarak teknik bağımlılık ölçülür.

Bulut sözleşmesi ve göçünde sık yapılan on hata

1. Replikasyonu yedek sanmak: Hatalı silme veya bozulma bütün kopyalara yayılabilir.
2. RPO/RTO’yu tanımsız bırakmak: Hedefin ne zaman ve neye göre ölçüleceği bilinmez.
3. Geri yükleme testi yapmamak: Var görünen yedeğin açılmadığı ancak olay günü anlaşılır.
4. Sorumluluğu “paylaşılan” diye geçmek: Yapılandırma, anahtar ve log görevleri sahipsiz kalır.
5. Eski sistemi erken silmek: Mutabakat bitmeden tek doğrulama kaynağı ortadan kaldırılır.
6. Çıkış formatını yazmamak: Veri alınsa bile yeni sisteme aktarılamayabilir.
7. Egress ücretini incelememek: Sağlayıcı değiştirme ekonomik olarak imkânsızlaşabilir.
8. Alt sağlayıcı ülkesini izlememek: Veri aktarım ve güvenlik düzeni haber verilmeden değişebilir.
9. Olay sırasında logların üzerine yazmak: Hızlı müdahale adına sorumluluk delili kaybedilir.
10. Bütün kaybı ciroyla eşitlemek: Gerçek zarar, nedensellik ve tasarruf edilen gider ayrı hesaplanmalıdır.

Karar ve kanun yolu

İlk derece kararına karşı istinaf, sonrasında temyiz imkânı kararın niteliği ve o tarihte geçerli parasal sınırlara göre belirlenir. Sınırlar değiştiğinden sabit rakama güvenilmemelidir. Tahkim şartı varsa hakem kararına karşı başvuru yolları ve icra usulü farklıdır. Teknik bilirkişi raporuna süresinde, veri seti ve hesap yöntemi gösterilerek itiraz edilmesi gerekir.

Dosya ön incelemesi için gerekli kayıtlar

Türkiye’nin her yerinden çevrim içi inceleme için ana sözleşme, olay tarihindeki çevrim içi koşullar, mimari şema, RPO/RTO eki, yedek ve geri yükleme raporları, göç planı, mutabakat çıktıları, loglar, destek yazışmaları ve mali zarar tablosu hazırlanmalıdır. Cari hizmet faturaları ayrıca tartışmalıysa fatura ve cari hesap alacağı rehberi delil tasnifinde yardımcı olabilir. Ön inceleme, teknik neden ve hukuki yükümlüyü eşleştirmeyi amaçlar; sonuç taahhüdü içermez.

Bulut geçişi ve vendor lock-in hakkında sık sorulan sorular

1. Bulut sağlayıcısı bütün veri kayıplarından sorumlu mudur?

Hayır. Sözleşmedeki yükümlülük, olayın nedeni, kusur ve müşterinin sorumlulukları birlikte incelenir.

2. “Günlük yedek” verinin kesin geri geleceği anlamına mı gelir?

Tek başına değil. Saklama, bütünlük, anahtar ve geri yükleme testinin kapsamı belirleyicidir.

3. RPO ile RTO arasındaki fark nedir?

RPO kabul edilen veri kaybı penceresine, RTO hizmetin geri dönüş hedef süresine ilişkindir.

4. Müşteri kendi yedeğini almadıysa hiç tazminat isteyemez mi?

Otomatik olarak bu sonuç çıkmaz. Sağlayıcının taahhüdü ve müşterinin zarara katkısı ayrı değerlendirilir.

5. Vendor lock-in hukuka aykırı mıdır?

Her teknik bağımlılık hukuka aykırı değildir. Sözleşme, şeffaflık, çıkış imkânı ve ücretlerin öngörülebilirliği incelenir.

6. Sağlayıcı veri çıkışı için ücret isteyebilir mi?

Sözleşmede öngörülen makul egress veya destek ücreti olabilir. Sonradan yaratılan veya belirsiz ücret ayrıca değerlendirilir.

7. Verinin yurt dışındaki yedeği de aktarım sayılır mı?

Kişisel verinin yurt dışında tutulması veya erişilebilir olması, somut akışa göre yurt dışı aktarım hükümlerini gündeme getirebilir.

8. Loglar kaç yıl saklanmalıdır?

Tek bir genel süre yoktur. Mevzuat, sözleşme, güvenlik amacı ve veri minimizasyonu birlikte değerlendirilir.

9. Veri silinmeden ihtiyati tedbir alınabilir mi?

Somut ve yakın risk ile yaklaşık ispat varsa değerlendirilebilir. Talep ölçülü ve teknik olarak uygulanabilir olmalıdır.

10. Tazminat davasından önce arabuluculuk gerekir mi?

Ticari para alacağı ve tazminat taleplerinde kural olarak gerekir. Acil veri koruma veya para dışı talepler ayrı incelenir.

11. Bulut göçü tamamlandıktan sonra eski ortam ne zaman silinir?

Kayıt mutabakatı, kabul, geri dönüş penceresi ve yasal saklama kontrolü tamamlandıktan sonra yetkili onayla silinmelidir.

Resmî kaynaklar

• 6098 sayılı Türk Borçlar Kanunu
• 6102 sayılı Türk Ticaret Kanunu
• 6698 sayılı Kişisel Verilerin Korunması Kanunu
• 6100 sayılı Hukuk Muhakemeleri Kanunu
• Kişisel Verileri Koruma Kurumu: Yurt dışı aktarım standart sözleşmeleri

Son kontrol tarihi: 19 Eylül 2026

Yazar: Av. Emirhan Keskin

Bu içerik genel bilgilendirme amacı taşır. Bulut mimarisi, sözleşme eki, veri akışı ve kayıp nedeni görülmeden kesin sorumluluk değerlendirmesi yapılamaz. Metin hukuki sonuç garantisi vermez.