Veri yerleşimini müşterilere hukuki tabirler olmadan açıklayın

Müşteriler veri yerleşimini sorduğunda ne demek istiyorlar

Bir müşteri veri yerleşimini sorduğunda genellikle üç konuda güvence arar: verileri nerede duruyor, kim görebilir ve veriler planlanmamış bir yere taşınabilir mi.

Çoğu kişi hukuki bir tanım istemez. Asıl sordukları şudur: “Verilerimiz beklenmedik bir yere gider mi ve bunu kontrol edebilir miyiz?” Bu endişeyi açıkça adlandırarak başlayın. Bu, asıl soruyu anladığınızı gösterir.

Çoğu yerleşim sorusunun ardında bu üç soru yatar:

• Verilerimiz nerede saklanıyor (hangi ülke veya bölge)?
• Kim erişebiliyor (sizin personeliniz, tedarikçileriniz, destek)?
• Bu konumdan çıkabilir mi (yedekler, loglar, analizler, destek araçları, yapay zeka işlemleri)?

Erken beklenti belirleyin. Sisteminizi net, pratik terimlerle açıklayabilirsiniz ama hukuki tavsiye vermiyorsunuz. Genelde şu kısa cümle işe yarar:

"Kontrollerimizi ve tipik veri akışlarını açıklayabilirim. Hukuk ekibiniz bunun politika ile nasıl örtüştüğünü doğrulayabilir."

Ayrıca “yerleşim”in neleri kapsayıp neleri kapsamadığını netleştirin. Yerleşim öncelikle verilerin nerede barındırıldığını ve nerelere aktarılabileceğini ilgilendirir. Her şeyi kapsayan bir taahhüt değildir.

Sadece veri yerleşimi şu sorulara cevap vermez:

• Veri saklama süresi (ne kadar süre saklanır)
• Veri sahipliği ve Fikri Mülkiyet şartları
• Güvenlik kalitesi (şifreleme, izleme, olay müdahalesi)
• Kullanıcıların yüklediği veya paylaştığı içerikler
• Müşteri verileri başka bir sisteme aktarıldıktan sonra ne olduğu

Basit dille veri yerleşimi (ve ne olmadığı)

Veri yerleşimi, müşteri verilerinin "at rest" yani veritabanlarında, dosya depolamada ve yedeklerde saklandığı ülke veya bölgedir.

Bir müşteri veri yerleşimini sorduğunda net cevap aradığı soru: “Verilerimiz günlük olarak nerede duruyor?”

Bazı kısa ayrımlar kafa karışıklığını önlemeye yardımcı olur:

• Veri yerleşimi vs veri gizliliği: gizlilik, verilerin nasıl kullanıldığı ve korunduğuyla ilgilidir (kim erişir, neden ve hangi güvenceler var), konumdan bağımsızdır. Yerleşim ise konum ile ilgilidir.
• Veri yerleşimi vs veri egemenliği: egemenlik, hangi ülke yasalarının veriye yetki iddia ettiğidir. Yerleşim, verinin nerede saklandığıdır.

Neden “bölge” bu kadar önemli? Çünkü konum gerçek yükümlülükleri ve riskleri etkiler: yasalar, sözleşme taahhütleri, denetim kanıtı, afet kurtarma tasarımı ve sınırlar ötesi transfer kuralları gibi.

Yerleşimi açıklarken somut olun. Depolama, yedekler, erişim yolları ve üçüncü taraflardan gündelik dilde bahsedin.

Ekibinizin okuyabileceği kısa bir metin

"Veri yerleşimi, verilerinizin nerede saklandığını ifade eder. Hesabınız için hedefimiz saklanan verileri seçtiğiniz bölgede tutmaktır. Bazen destek sorun giderme veya güvenlik izleme gibi operasyonlar için veriler geçici olarak hareket edebilir, ancak bunu sınırlandırıyoruz ve kimlerin erişebileceğini kontrol ediyoruz. Gerekli ülke veya bölgeyi belirtirseniz, orada nelerin saklandığını, nelerin transfer edilebileceğini ve kullandığımız kontrolleri doğrularız."

Müşteri verilerinin çıkabileceği 5 yer

Yerleşim soruları, verinin nerede görünebileceğini karıştırdıklarında karmaşıklaşır. Başta “yerleri” adlandırmak geri kalan konuşmayı kolaylaştırır.

1) Depolama ("ev")

Depolama, veri kimse aktif olarak kullanmıyorken durduğu yerdir: veritabanları, dosya yüklemeleri, nesne depolama (dokümanlar, görseller) ve bazen loglar.

2) Yedekler ve çoğaltmalar ("güvenlik kopyaları")

Yedekler, hata, yazılım hatası veya kesinti sonrası kurtarma için alınan kopyalardır. Çoğaltmalar ise performans ve kullanılabilirlik için ekstra kopyalardır. Yerleşim açısından, başka bir bölgede bulunan kopya da müşteri verisidir.

3) İşleme ("çalışma tezgâhı")

İşleme isteklerin ele alındığı yerdir: uygulama sunucuları, arka plan işleri, API geçitleri ve kısa ömürlü önbellekler. Bir istek çalışırken veri geçici olarak bellekte veya geçici dosyalarda bulunabilir.

4) Yönetici erişimi ("insan katmanı")

Destek ve mühendislik ekipleri herhangi bir yerden çalışabilir, fakat bu otomatik olarak verinin oraya taşındığı anlamına gelmez. Müşterilerin asıl sorduğu: personel müşteri verisini görebilir mi, hangi kurallara göre ve hangi kayıtlarla?

5) Üçüncü taraf hizmetler ("yardımcılar")

Bir üçüncü taraf, sizin adınıza müşteri verilerini depolayabiliyor, işleyebiliyor veya erişebiliyorsa önemlidir (genellikle alt işleyici olarak adlandırılır). Yaygın örnekler e-posta gönderimi, hata takip, analiz, ödeme sistemleri ve AI model sağlayıcılarıdır.

Çoğu durumu kapsayan basit bir hikâye:

Kullanıcı bir sözleşme yükler (depolama), bu gece yapılan yedeklemeye kopyalanır (yedek), sistem ana alanları çıkarır (işleme), destek bir sorun için salt-okunur erişimle inceleme yapar (yönetici), ve hatadan kısa bir kesit izleme aracına gönderilir (üçüncü taraf).

Somutlaştırın: hangi veriden bahsediyoruz?

"Verilerimiz nerede saklanıyor?" sorusu, müşteri yüklediği içerik, fatura kayıtları, loglar veya geçici işlem verileri gibi farklı veri türlerine göre çok farklı anlamlar taşıyabilir.

Pratik bir cevap yöntemi veriyi üç kategoriye ayırmaktır:

• Müşteri içeriği: müşterinin ürüne kasıtlı olarak koyduğu şeyler (dosyalar, kayıtlar, mesajlar, dokümanlar, görseller, gönderilen metin). Birçok müşteri oluşturulan çıktıları da içerik sayar.
• Servis verisi: hesabı çalıştırmak için gereken veriler (hesap profili, fatura ve faturalar, plan seviyesi, roller, kimlik doğrulama olayları, temel kullanım toplamları). Genellikle hata logları ve performans metrikleri gibi tanı bilgileridir.
• Geçici veriler: servis çalışırken oluşturulan kısa ömürlü veriler (bellekteki işlem verileri, kısa önbellekler, kuyruklar, geçici dosyalar). Uzun süreli depolama için değildir ama kısa süreliğine bir bölgede bulunabilir.

Yazılı olarak adlandırmanın hızlı yolu

Yanıt verirken şu sırayı izleyin: (1) müşteri içeriği, (2) servis verisi, (3) geçici işlem verisi.

Aşağıdaki tabloyu belge veya e-postada yeniden kullanabilirsiniz:

Örnek ifade:

"Proje içeriğiniz seçilen bölgede kalır. Faturalama ve hesap kayıtları servis verisidir ve ayrı olarak saklanabilir. İşleme sırasında bazı geçici veriler bellekte veya önbelleklerde kısa süreyle bulunabilir, sonra süresi dolar."

E-postalarda ve belgelerde yeniden kullanabileceğiniz basit diyagramlar

Küçük bir diyagram genellikle bir paragraftan daha hızlı yerleşim sorularını cevaplar. Telefon ekranında okunaklı tutun ve nerede saklandığını ile nelerin hareket edebileceğine odaklanın.

Diyagram 1: Tek bölge, ana veri “evleri” ile

Müşterinin “her şey Bölge A'da kalıyor” gibi basit bir ifade istediğinde bunu kullanın.

Customer
  |
  | use app
  v
[Region A]
  - App servers (process)
  - Database (store)
  - Backups (copy, store)

Altına bir cümle ekleyin:

"Tüm müşteri içeriği Bölge A'da saklanır ve yedekler de Bölge A'da tutulur."

Diyagram 2: İki bölge (birincil ve felaket kurtarma)

Bekleme bölgesi varsa bunu kullanın. Okları açıklayıcı yapın.

           normal use
Customer  -----------\u003e  [Primary Region]
                             - App (process)
                             - DB (store)
                             - Backups (copy)
                                  |
                                  | encrypted copy
                                  v
                         [DR Region]
                             - Backup copy (store)
                             - Standby (no access unless failover)

Müşteri transferlere hassassa, oku ne taşıdığı (örneğin “şifrelenmiş yedek kopyası”) ve ne sıklıkta (örneğin “günlük”) etiketleyin.

Diyagram 3: Bir kullanıcı eylemi, temas noktaları olarak gösterilmiş

Kullanıcı "Dosyam nereye gidiyor?" veya "Kaydet tıklayınca bir şey bölgeden çıkar mı?" diye sorduğunda bunu kullanın.

User uploads a file
  1) App server (process upload)
  2) Object storage (store file)
  3) Database (store metadata)
  4) Backup system (copy for recovery)
User views the file
  5) App server (read)
  6) Object storage (send)

Etiketleme kuralları ile başınızı belaya sokmayın:

• Kısaltmalardan kaçının. "Veritabanı" yazın, "DB" demeyin; "felaket kurtarma" yazın, "DR" demeyin.
• Müşterilerin tanıyacağı fiilleri kullanın: sakla, kopyala, işle, gönder, sil.
• Her kutunun üzerine bölge adını yazın, sadece başlığa koymayın.
• Bir şey bölgeden çıkabiliyorsa bir ok çizin ve adlandırın.
• Bir şeyin olmadığını belirtmek gerekiyorsa (örneğin, "analitik ihracı yok"), diyagramın yakınında açıkça yazın.

Adım adım nasıl açıklanır (tekrar kullanılabilir bir komut-metin)

Sakin, tekrarlanabilir bir metin hukuki ifadelerden uzak tutar ve tahminleri azaltır.

Her aramada veya e-postada takip edilecek metin

1. Bir netleştirici soru ile başlayın: "Hangi kurala uymaya çalışıyorsunuz — belirli bir ülke, bir bölge (örneğin AB) yoksa dahili bir politika mı?"

2. Onlarla veriyle neyi kastettiklerini hizalayın: "İçerik, kullanıcı hesapları, dosyalar, loglar, yedekler veya analizler mi diye soruyorsunuz?"

3. Varsayılan konumu bir cümleyle belirtin: "Varsayılan olarak uygulama verileriniz, ortamınızın konuşlandırulduğu bölgede saklanır."

4. Nelerin hareket edebileceğini ve nedenini açıklayın. Pratik olun: destek sorun giderme, kurtarma tasarımı (geri yükleme/failover) ve üçüncü taraflar. Eğer bir şey asla bölgeden çıkmıyorsa söyleyin. Belirli koşullarda çıkabiliyorsa, bu koşulları adlandırın.

5. Müşterinin seçebileceği kontrolleri teklif edin. Müşterinin seçebileceği (bölge seçimi, erişim kontrolleri) ve kendilerinin yapabileceği (dışa aktarma, geri yükleme) şeylere odaklanın.

Sonra temiz bir sonraki adımla bitirin:

"Size neyin sabit kaldığını, nelerin hareket edebileceğini ve hangi kontrollerin olduğunu kısa bir yazılı özet halinde göndereceğim. Düzeltmelerle yanıtlayın."

Yazılı özette neler olmalı

Beşi geçmesin:

• Müşteri gereksinimi (ülke/bölge ve hangi veri türleri)
• Depolama konumu (varsayılan ve seçilen bölge)
• İzin verilen transferler (destek, kurtarma, üçüncü taraflar)
• Müşteri kontrolleri (bölge seçimi, erişim, dışa aktarma, anlık görüntüler)
• Açık sorular (onlardan halen ihtiyacınız olan herhangi bir bilgi)

Kopyalayıp yapıştırabileceğiniz net ifadeler

Müşteriler iki cevap ister: verileri nerede yaşıyor ve hiç hareket ediyor mu. Bu iki fikri ayırın:

"Veriler X'te bulunur. Yalnızca Z nedeniyle Y'ye taşınabilir."

"Her zaman" ve "asla" ile dikkatli olun. Yedekler, kesintiler ve destek işleri sırasında mutlak ifadeler kullanacaksanız emin olun.

Göndermeye hazır üç cevap

• Kısa cevap (e-posta veya sohbet) "Müşteri verileriniz bulut altyapımızda [BÖLGE/ÜLKE] içinde saklanır. Yalnızca [ÖZEL NEDEN, örn. felaket kurtarma veya onaylı destek] için bu bölgenin dışına taşınabilir ve sadece aşağıda listelenen kontroller ile olur."

• Detaylı cevap (satın alma veya BT için) "Veriler normal kullanım için [BÖLGE/ÜLKE] içinde saklanır: uygulama verileri, veritabanı kayıtları ve dosya yüklemeleri. Yedekler [YEDEK BÖLGESİ] içinde saklanır ve [SÜRE] kadar tutulur. Veriler yalnızca bir sorunu çözmek gerektiğinde ve sınırlı erişim ile [DESTEK/DIAGNOSTİK KONUM] 'a geçici olarak taşınabilir. Eğer alt işleyiciler kullanıyorsak (örneğin bulut barındırma veya AI model sağlayıcıları), bunları ve hangi bölgelerde çalıştıklarını listeleriz."

• Güvenlik incelemesi cevabı (resmi, ama sade İngilizce yerine açık Türkçe) "Yerleşim açıklamamız şunları kapsar: (1) üretim verilerinin nerede saklandığı, (2) yedekler ve felaket kurtarma kopyalarının nerede saklandığı, (3) kimlerin veriye erişebileceği ve erişimin nasıl kaydedildiği, ve (4) hangi üçüncü tarafların veriyi işleyebileceği."

Belgelerinizde saklayabileceğiniz doldurulabilir şablon

Bunu tek bir doğruluk kaynağı olarak kullanın, sonra bölümleri cevaplara kopyalayın:

• Bölge (prodüksiyon): [BÖLGE/ÜLKE], [CLOUD], [TENANT YAPILANDIRMASI]
• Yedekler: [BÖLGE] içinde saklanır, [AT REST/IN TRANSIT] şifreli, saklama [GÜN]
• Destek erişimi: [KİM], [NE ZAMAN], [ONAY GEREKİYOR MU?], [KAYITLAMA]
• Felaket kurtarma: [FELAKET KURTARMA BÖLGESİ], "sadece kesintiler sırasında kullanılır"
• Alt işleyiciler: [LİSTE], gerekiyorsa AI model sağlayıcıları dahil

Eğer bir satır bilinmiyorsa, tahmin etmeyin. Bildiğiniz şeyi söyleyin, neyi teyit ettiğinizi ve ne zaman geri döneceğinizi belirtin.

Kaçınılması gereken yaygın hatalar ve ifade tuzakları

Güveni kaybetmenin en hızlı yolu kendinden emin ama belirsiz görünmektir. Bu hatalar takip eden uzun güvenlik incelemelerini tetikler.

En yaygın hatalar

"Uyumluyuz" deyip verinin nerede saklandığını söylememek. Müşteriler genellikle bir cümle ister: hangi verinin hangi ülke veya bölgede saklandığı ve bunun yapılandırılabilir olup olmadığı.

Hesaplama konumunu depolama konumu ile karıştırmak. Bir uygulama bir yerde çalışırken veritabanı, dosya depolama veya analiz başka bir yerde olabilir. Sadece "uygulama nerede çalışıyor" derseniz yanlış yönlendirmiş olabilirsiniz.

"Yan verileri" unutmak. Yedekler, loglar, çökme raporları ve destek talepleri genellikle ana veritabanı kadar önemlidir.

İstisnalar varken "veri asla çıkmaz" demek. Gerçek sistemlerde olay müdahalesi, onaylı destek iş akışları, isteğe bağlı felaket kurtarma ve üçüncü taraf araçlar gibi kenar durumlar vardır. İstisnaları düz Türkçe ile açıklayamıyorsanız mutlak ifadelerden kaçının.

Bulut "bölgesi" otomatik olarak "sınır ötesi erişim yok" anlamına gelmez. Veri bir bölgede saklansa bile, belirli kontroller altında başka yerlerden personel veya sistemler erişebiliyor olabilir. Müşteriler genellikle bu ayrımı önemser.

Daha güvenli ifade kalıpları:

• "Müşteri içeriği seçilen dağıtım konumunda saklanır. Yedekler, çapraz konum felaket kurtarmayı etkinleştirmediğiniz sürece aynı konumda tutulur."
• "Destek erişimi sınırlıdır ve kaydedilir. Erişim için kullanılan onay sürecini açıklayabiliriz."
• "Belirli işlevler için üçüncü taraf hizmetler kullanıyoruz. Gönderilen veri ve zamanlamasını doğrularız."

Bir müşteriye yanıtlamadan önce hızlı kontrol listesi

Politika metniyle başlamayın. Önce bir veya iki cümle ile söyleyebileceğiniz birkaç gerçek ile başlayın, sonra sadece sorarlarsa detay ekleyin.

Önce yapılacak 5 kontrol

• Birincil depolama konumu: Müşterinin ana veritabanı ve dosya depolaması hangi ülke/bölgede?
• Yedekler ve saklama: Yedekler nerede tutuluyor, ne kadar süre korunuyor ve kim geri yükleyebiliyor?
• Çoğaltma ve failover: Sistem başka bir bölgeye kopya veya taşıma yapabilir mi (performans, kesinti kurtarma, bakım)? Hangi koşullarda?
• İnsan erişim yolları: Kim müşteri verisine erişebilir, nereden ve hangi onay/kayıt mekanizmaları var?
• Veriye dokunan üçüncü taraflar: Hangi tedarikçiler veriye dokunuyor (bulut barındırma, e-posta/SMS, analiz, AI model sağlayıcıları) ve ne aldıkları?

Bunlardan sonra, müşterinin seçebileceği kontrolleri düz Türkçe ile açıklayın: neyi seçebilirler (bölge), neyi kendileri yapabilir (dışa aktarma) ve neyi talep edebilirler.

Göndermeden önce son kontrol

Cevabınızın bu üç soruyu yanıtladığından emin olun:

• "Verilerim günlük olarak nerede duruyor?"
• "Burasından çıkabilir mi, ne zaman?"
• "Rastgele erişimi veya rastgele transferleri ne engelliyor?"

Tekrar kullanılabilir somut ifade:

"Birincil verileriniz [bölge] içinde saklanır. Yedekler [bölge] içinde [süre] kadar tutulur. Veri yalnızca [failover/çoğaltma kuralı] durumunda başka bir bölgeye taşınır. Erişim [roller] ile sınırlıdır ve kaydedilir. Alt işleyicilerimiz [tedarikçiler] ve amaçları için listelenmiştir."

Örnek: gerçek bir müşteri sorusuna cevap (basit senaryo)

Almanya'dan bir müşteri e-posta atıyor: "Verilerimiz AB'de mi kalır? Bir kesinti olursa veriyi başka bir yere taşır mısınız?"

3 cümlelik cevap (kopyala/yapıştır)

Evet - uygulamanızı ve veritabanınızı bir AB bölgesinde barındırabiliriz, böylece saklanan müşteri verileriniz orada kalır.

Bir kesinti sırasında, önceden onaylı bir failover kurulumunu kabul etmedikçe verinizi otomatik olarak başka bir ülkeye taşımayız.

Hangi AB ülkelerinin/ bölgelerinin kabul edilebilir olduğunu (ve hangilerinin olmadığını) belirtirseniz, kesin barındırma konumunu hesap için doğrular ve dökümante ederiz.

Ayrıntı isteyebilirlerse ek (isteğe bağlı)

"Verinin AB'de saklandığını" söylediğimizde, ana depolama sistemlerinin nerede çalıştığını kastediyoruz: uygulama servisleri, veritabanı ve dosya depolama.

Kesintiler için iki yaygın yaklaşım vardır:

• Tek bir AB bölgesinde kalmak: yerleşim açısından en basit, fakat tüm bölge etkilenirse kurtarma daha uzun sürebilir.
• AB içinde AB failover: servis, birincil bölge kapalıysa ikinci bir AB bölgesine geçebilir; bu kullanılabilirliği artırır ama olay sırasında verinin ikinci AB bölgesinde işlenebileceği anlamına gelir.

Müşterilerin genelde önem verdiği pratik notlar:

• Yedekler ve anlık görüntüler onayladığınız bölgelerde saklanır.
• Destek erişimi kontrollüdür ve barındırma bölgesini değiştirmez.
• Siz veri veya kaynak kodunu dışa aktarmadıkça veriler platformdan çıkmaz.

Son adım: onlara kabul edilebilir bölgeleri (ör. "sadece AB, isteğe bağlı olarak ikinci bir AB bölgesine failover") teyit etmelerini isteyin ve seçimi onboarding belgelerine kaydedin.

SSS ve sonraki adımlar (ekip için ve müşteriler için)

SSS: Veri tam olarak nerede saklanır (bölge vs ülke)? Açık ifade: veri seçilen bir bulut bölgesinde saklanır. Bir bölge bir coğrafyaya karşılık gelir ama her zaman tek bir ülke anlamına gelmez. Müşteri belirli bir ülke istiyorsa hangi bölgenin bu gereksinimi karşıladığını teyit edin.

SSS: Destek veya sorun giderme sırasında veri taşınır mı? Çoğu destek işi müşteri içeriğini başka bir yere kopyalamayı gerektirmez. Nadir bir durumda geçici erişim veya müşteri tarafından sağlanan örnek gerekiyorsa, bunu açıkça söyleyin: kim erişir, ne kadar süre tutulur ve nasıl silinir.

SSS: Yedekler aynı bölgede mi kalır? Müşteriler genellikle yedeklerin birincil veriyle birlikte tutulmasını bekler. Yedekler bölge içinde ise bunu açıkça söyleyin. Felaket kurtarma kopyaları başka yerde saklanabiliyorsa, bunu belirtin ve seçeneği açıklayın.

SSS: Loglar, analizler ve e-posta bildirimleri ne olur? İşte kafa karışıklığının sık olduğu yer. Veritabanı bir yerde kalsa bile destekleyici veriler loglar, performans metrikleri, denetim kayıtları ve e-postalar (şifre sıfırlama gibi) içerebilir. Bu verilerin kişisel veri içerip içermediğini, nerede saklandığını ve müşterinin neyi yapılandırabileceğini belirtin.

SSS: Müşteriler hangi kontrolleri açabilir veya talep edebilir? Gerçekte destekleyebileceğiniz kontrolleri listeleyin, örneğin:

• Başta dağıtım bölgesini seçme
• Ekip erişimini sınırlama (rol tabanlı erişim, en az ayrıcalık)
• Veri, log ve yedek saklama kurallarını belirleme
• Anlık görüntüler ve geri alma ile saklama kuralları
• Gerektiğinde veri veya kaynak kodunu dışa aktarma

Sonraki adımlar Yerleşim gereksinimlerini erken yakalayın (ülke, bölge, yedekler, destek erişimi) ve dağıtımdan önce yazın.

Eğer Koder.ai (koder.ai) gibi bir platform kullanıyorsanız, AWS'de belirli ülkelerde uygulama çalıştırabilir ve kaynak kodu dışa aktarma, anlık görüntüler/geri alma gibi özellikleri destekler. Bu ayrıntılar, müşterinin hangi kontrolleri elinde tutacağını ve kurtarma işlemlerinin nasıl işleyeceğini belgelendirirken önemlidir.