Veri ikametgahı (data residency): verileriniz fiziksel olarak nerede duruyor?

Perşembe öğleden sonra. On kişilik bir hizmet firmasının satış sorumlusu, altı haftadır üzerinde çalıştığı büyük müşteriden bir dosya alıyor: altmış satırlık tedarikçi bilgi güvenliği formu. On dördüncü satırda tek bir soru var — müşteri verileri hangi ülkede, hangi veri merkezinde tutuluyor? Sorumlu kurucuya soruyor, kurucu CRM sağlayıcısına yazıyor, üç gün sonra gelen cevap bir bulut sağlayıcının adından ibaret. Bu bir cevap değil. Form iki hafta bekliyor, alıcı tarafındaki hukuk birimi süreci beklemeye alıyor, ve altı haftalık iş teknik bir eksiklik yüzünden değil, cevaplanamayan tek bir soru yüzünden soğuyor.

Veri ikametgahı, kurumsal satışta artık ürün özelliklerinden önce sorulan bir sorudur; ama çoğu KOBİ'de cevabı kimse tam olarak bilmez. Bu yazıda sırayla şunları ele alıyoruz: ikametgah, egemenlik ve yerelleştirme kavramlarının neden aynı şey olmadığını, verinizin gerçekte kaç ayrı yerde kopyalandığını, Türkiye'de yurt dışına aktarımın hangi mekanizmayla işlediğini, sunucular burada cümlesinin ne kadar bilgi taşıdığını, tedarikçiye sorulması gereken soruları, gecikme ve performans tarafını, veri sınıflandırmanın neden ilk adım olduğunu, yapay zekâ eklentilerinin bu kararı nasıl sessizce bozduğunu, yedekleme ile ikametgahın çatıştığı noktayı ve satış masasında bu soruya nasıl hazırlıklı olunacağını.

1Kayıt2Sunucu3Yedek4Alt işleyen5Destek

İkametgah, egemenlik ve yerelleştirme aynı şey değildir

Üç kavram sürekli birbirinin yerine kullanılıyor ve karışıklık pahalıya patlıyor. Veri ikametgahı (data residency) fiziksel bir gerçektir: verinin yazıldığı diskin hangi ülkede durduğu. Veri egemenliği (data sovereignty) hukuki bir gerçektir: o veriye hangi ülkenin yargı yetkisi uzanabildiği. Veri yerelleştirmesi (data localization) ise bir yükümlülüktür: mevzuatın belirli veri türlerinin ülke içinde tutulmasını zorunlu kılması. Bir veri Türkiye'de durabilir ama başka bir hukuka tabi bir şirket tarafından işletiliyorsa egemenlik başka yerdedir.

Fark önemli, çünkü müşteriniz formda ikametgahı sorarken aslında egemenliği merak eder. Sorunun arkasındaki gerçek endişe şudur: bu veriye benim bilgim dışında, benim tabi olmadığım bir hukuk üzerinden erişilebilir mi? Cevabınız yalnızca bir şehir adıysa, sorulan soruya değil, kolay olana cevap vermiş olursunuz. Formu dolduran kişi bunu genellikle fark eder ve dosya bir tur daha döner.

Veriniz tek bir sunucuda durmuyor

Ana veri tabanı, verinin bulunduğu yerlerin yalnızca birincisidir. Bir müşteri kaydı oluşturulduğu anda kaç ayrı yere kopyalandığını çoğu firma hiç saymamıştır, ve sayınca şaşırır. Aşağıdaki listenin her satırı ayrı bir ikametgah kararıdır; bir tanesi bile farklı bir ülkedeyse cevabınız değişir.

• Yedekler: Günlük yedeklerin tutulduğu bölge, çalışan sistemin bölgesiyle aynı olmak zorunda değildir ve pratikte çoğu zaman değildir.
• Loglar ve hata izleme: Hata kayıtları müşteri adı, e-posta ve bazen mesaj içeriği taşır; bu kayıtlar genellikle ayrı bir servise, sıklıkla ayrı bir ülkeye akar.
• E-posta ve SMS gönderimi: Sistemden çıkan her bildirim, alıcının adresini bir gönderim sağlayıcısının sunucularından geçirir.
• Analitik ve ürün kullanım ölçümü: Kullanıcı davranışını izleyen araçlar kişisel veri taşıyabilir; taşımadığını varsaymak yerine kontrol edin.
• Destek ekranı: Sağlayıcının destek ekibi bir sorunu incelemek için üretim verisine bakabiliyorsa, o kişinin bulunduğu ülke de zincirin parçasıdır.
• Yapay zekâ özellikleri: Özetleme, sınıflandırma veya öneri üreten her özellik, kayıt içeriğini bir model sağlayıcısına gönderiyor olabilir.
• Test ve demo kopyaları: Gerçek veriyle doldurulmuş test ortamları, üretim verisinin en sık unutulan ikizidir.

Bu liste kötümser değil, gerçekçi. Yapılacak iş de karmaşık değil: her satırın karşısına bir ülke yazın. Yazamadığınız satır, cevabınızdaki gerçek boşluktur ve müşterinin güvenlik ekibi tam olarak orayı sorar. Tek sayfalık bu tablo, çoğu firmanın hiç sahip olmadığı en değerli uyum belgesidir.

Türkiye'de yurt dışına aktarım nasıl işler?

Kişisel verilerin yurt dışındaki bir sunucuda işlenmesi, Türkiye mevzuatında serbest bir tercih değil, koşullara bağlı bir aktarımdır. Mekanizma kabaca şöyle çalışır: aktarımın dayanacağı bir hukuki zemin olmalıdır. Bu zemin bazı hâllerde ilgili kişinin açık rızası, bazı hâllerde taraflar arasında imzalanan standart sözleşme veya taahhütname, grup şirketleri arasında ise bağlayıcı kurumsal kurallar biçiminde kurulur. Uygulamada açık rıza rutin bir operasyonel çözüm değildir; rıza her an geri çekilebildiği için üzerine kalıcı bir altyapı kurulamaz.

Pratik sonuç şudur: sözleşmenizde sağlayıcının alt işleyen listesi, bu listede değişiklik olduğunda size bildirim yükümlülüğü ve verinin hangi bölgede işleneceği yazılı olmalıdır. Bu üç madde yoksa, ikametgah taahhüdünüz sözlü bir güvenceden ibarettir. Mevzuatın kendi durumunuza nasıl uygulanacağı işinizin niteliğine ve işlediğiniz veri türüne göre değişir; kurumsal bir müşteriye taahhüt vermeden önce hukuk danışmanınıza veya mali müşavirinize danışın. Kişisel veri işlemenin CRM tarafındaki bütün çerçevesini KVKK uyumlu CRM yazısında topladık.

Veri sorumlusu mu, veri işleyen mi?

Bu ayrım formlarda en sık yanlış doldurulan yerdir. Müşteri verisini toplayan ve amacını belirleyen taraf sizsiniz; CRM sağlayıcınız sizin talimatınızla işleyen taraftır. Yani müşteriniz size sorduğunda sorumluluk sizde kalır, sağlayıcıya devredilmez. Kayıt yükümlülüğünün kimi kapsadığını ve nasıl işlediğini VERBİS kaydı yazısında ayrıntılı ele alıyoruz.

Sunucular burada cümlesi ne kadar bilgi taşır?

Yaygın kanı, sunucuların ülke içinde olmasının meseleyi kapattığıdır. Çoğu durumda bu doğru değildir, ve ters yönde de doğru değildir. Ülke içindeki bir veri merkezinde barındırılan bir sistem, yurt dışındaki bir destek mühendisinin sınırsız üretim erişimiyle çalışıyorsa, verinin fiziksel konumu koruma sağlamaz. Tersine, başka bir ülkede barındırılan ama erişimi talep bazlı, süreli ve kayıtlı olan bir sistem çok daha savunulabilir bir tablo sunar.

Verinin hangi ülkede durduğu, ona kimin hangi hukuk altında erişebildiği kadar önemli değildir.

Bu yüzden ikametgah sorusunun ciddi cevabı üç parçalıdır: konum, erişim ve kayıt. Konum nerede durduğudur. Erişim kimin hangi koşulda açabildiğidir — kalıcı yetki yerine talep üzerine açılan, süresi dolunca kapanan erişim modeli buradaki standarttır. Kayıt ise her erişimin izinin tutulmasıdır. Üçü birlikte olduğunda cevabınız bir cümle değil, bir tablo hâline gelir. Erişimin rol bazlı nasıl daraltılacağını rol ve yetki yönetimi yazısında anlatıyoruz.

Tedarikçiye hangi soruları sormalısınız?

Güvenlik formu size geldiğinde geç kalmışsınızdır; asıl form, sağlayıcı seçerken sizin doldurmanız gerekendir. Beş soru çoğu durumu kapatır, ve her birinin iyi cevabının nasıl göründüğü bellidir.

Soru	İyi cevap neye benzer	Zayıf cevap
Birincil veri hangi ülkede işleniyor?	Ülke ve bölge adı, sözleşmede yazılı	Bulutta tutuluyor
Yedekler nerede duruyor?	Bölge adı ve saklama süresi	Otomatik olarak yedekleniyor
Destek üretim verisine erişiyor mu?	Talep bazlı, süreli, kayıtlı erişim	Sadece gerektiğinde bakıyoruz
Alt işleyen listesi yayında mı?	Herkese açık liste ve değişiklik bildirimi	İstenirse paylaşabiliriz
Bölge değiştirebilir miyim?	Tanımlı süreç ve öngörülen kesinti	Teknik olarak mümkün

Cevapların yazılı olması, içeriklerinden neredeyse daha önemlidir. Sözlü verilen bir bölge taahhüdü, sağlayıcı altyapısını taşıdığında hiçbir şey ifade etmez. Barındırma modelinin genel mantığını ve yerel kuruluma göre farklarını bulut tabanlı CRM yazısında ele aldık.

Gecikme ve performans: ikametgahın teknik yüzü

İkametgah kararı yalnızca hukuki değil, günlük deneyimi doğrudan etkileyen bir karardır. Veri ile kullanıcı arasındaki fiziksel mesafe her tıklamaya gidiş dönüş süresi olarak eklenir. Aynı kıtada bu fark hissedilmez; kıtalar arasında liste açma, arama ve kaydetme adımlarında fark edilir hâle gelir. Sahada telefonla çalışan bir ekip için bu, formun doldurulup doldurulmaması arasındaki eşiktir.

Daha az bilinen nokta şudur: bölge seçimi yapışkandır. Çoğu platformda bölge, hesap kurulurken belirlenir ve sonradan değiştirilmesi veri taşıma operasyonu gerektirir; bu da kesinti, yeniden doğrulama ve entegrasyonların yeniden bağlanması demektir. Yani ikametgah, sonradan ayarlanacak bir tercih değil, kurulum anında verilecek bir karardır. Büyük bir müşterinin sizi bölge değiştirmeye zorlaması, hesap yaşlandıkça daha pahalı hâle gelir.

Her veri aynı korumaya ihtiyaç duymaz

İkametgah tartışması genellikle bütün veriyi tek bir kütle gibi ele alarak başlar, ve bu yüzden gereğinden pahalı biter. Oysa CRM'inizdeki verinin hassasiyeti eşit değildir. Kimlik bilgileri, iletişim bilgileri, finansal kayıtlar, davranışsal veri ve serbest metin notlar farklı risk taşır. En hassas kategori genellikle beklenmedik olanıdır: serbest metin notlar. Kimse oraya ne yazıldığını denetlemez, ve pratikte sağlık, borç veya kişisel durum bilgisi en çok orada birikir.

Sınıflandırma yaptıktan sonra çoğu firma şunu görür: katı ikametgah gereksinimi yalnızca kayıtların bir bölümü için geçerlidir. Bu da kararı ucuzlatır. İkinci ucuzlatıcı ise silmektir; taşınmayacak veri, korunması gerekmeyen veridir. Hangi kaydın ne kadar süre tutulacağını önceden yazmanın yöntemini veri saklama ve silme politikası yazısında anlatıyoruz.

Yapay zekâ özellikleri bu kararı sessizce bozar

Bir CRM'e eklenen özet çıkarma, konuşma analizi veya otomatik sınıflandırma özelliği, çalışması için kayıt içeriğini bir model sağlayıcısına göndermek zorundadır. Bu gönderim çoğu zaman başka bir ülkeye yapılır ve kullanıcı arayüzünde bunu gösteren tek bir satır bile bulunmayabilir. Aylardır özenle korunan bir ikametgah taahhüdü, bir düğmenin açılmasıyla ortadan kalkar.

Yapılacak iş üç adımlı. Birincisi, hangi yapay zekâ özelliğinin hangi veriyi nereye gönderdiğini envanterinize yazmak. İkincisi, bu özellikleri kayıt tipi bazında kapatabildiğinizden emin olmak; hepsi ya da hiçbiri seçeneği çoğu şirket için kullanılamaz. Üçüncüsü, ekibin kendi başına bulduğu araçları görünür kılmak — kimse izin istemeden bir müşteri listesini bir sohbet aracına yapıştırdığında ikametgah kararınız zaten bozulmuştur. Bu alandaki riskleri ve pratik sınırları yapay zekâ ve müşteri verisi yazısında ele alıyoruz.

Yedekleme ve felaket kurtarma ikametgahla nerede çatışır?

Yedeklemenin mantığı ile ikametgahın mantığı doğal olarak birbirine terstir. İyi bir felaket kurtarma planı, yedeği ana sistemden coğrafi olarak uzağa koymak ister; katı bir ikametgah gereksinimi ise onu ülke sınırının içinde tutmayı zorunlu kılar. Tek veri merkezi bölgesi bulunan ülkelerde bu gerçek bir gerilimdir ve genellikle aynı ülkede ikinci bir bölge veya aynı bölge içinde ayrı bir tesis ile çözülür.

Kararı verirken iki sayıyı birlikte konuşun: ne kadar veri kaybını göze alabilirsiniz ve ne kadar sürede ayağa kalkmanız gerekir. Bu iki eşik netleşmeden ikametgah tartışması havada kalır. Yedekleme ve kurtarma tarafının bütün çerçevesini yedekleme ve felaket kurtarma yazısında, kurumsal olmayan bir ekibin uygulayabileceği temel güvenlik adımlarını ise KOBİ için siber güvenlik yazısında bulabilirsiniz.

Satış masasında bu soruya nasıl hazır olunur?

Kurumsal alıcının güvenlik formu, satış sürecinin en öngörülebilir sürprizidir: her zaman gelir ve her zaman beklenmedik bir anda gelir. Hazırlığın tamamı tek bir sayfadır — verinin nerede durduğunu, kimin eriştiğini, hangi alt işleyenlerin devrede olduğunu ve saklama sürelerini gösteren bir veri haritası. Bu sayfa hazırsa form bir günde döner; hazır değilse iki hafta gider.

Hızın kendisi bir sinyaldir. Alıcının güvenlik ekibi cevabınızın içeriğinden çok, cevabınızın gecikmesinden sonuç çıkarır: geç gelen cevap, sürecin şirket içinde tanımlı olmadığını düşündürür. Bu formların nasıl yanıtlanacağını ve hangi cevapların süreci hızlandırdığını güvenlik ve uyum soru formları yazısında ayrıca ele alıyoruz.

Çıkış planı ve nereden başlamalı

İkametgah sorusunun sonunda her zaman bir çıkış sorusu durur: bu sağlayıcıdan ayrılmam gerekirse verimi nasıl ve hangi formatta alırım? Cevap, sözleşmede tanımlı bir dışa aktarma hakkı ve makine tarafından okunabilir bir format olmalıdır. Ekran görüntüsü veya sayfalanmış PDF, dışa aktarma sayılmaz. Bu bağımlılığın nasıl azaltılacağını tedarikçiye bağımlılık ve veri taşınabilirliği yazısında anlatıyoruz.

Başlamak için bir hafta yeter. İlk gün bir tablo açın ve sütunları şöyle kurun: veri türü, hangi sistem, hangi ülke, kim erişiyor, ne kadar saklanıyor. İkinci gün CRM'inizi, üçüncü gün e-posta ve gönderim araçlarınızı, dördüncü gün analitik ve yapay zekâ eklentilerinizi yazın. Beşinci gün boş kalan hücreleri sağlayıcılara sorun. Haftanın sonunda elinizde, çoğu rakibinizin sahip olmadığı bir belge olur — ve bir sonraki güvenlik formu geldiğinde onu doldurmak yarım saat sürer.

Verinizin nerede durduğunu bilmek, onu tek bir yerde toplamakla başlar; dağınık tablolar ve kişisel gelen kutularına yayılmış müşteri bilgisinin ikametgahı zaten tanımsızdır. Rocketly'de müşteri kayıtları, iletişim geçmişi, belgeler ve yetkiler tek bir kurulumda toplanıyor; ücretsiz hesap açarak kendi veri haritanızı çıkarmaya başlayabilirsiniz.