E-Fatura Arşivleme: Azure Blob'da VUK+GİB Uyumlu Saklama (2026)

Xen Bilişim ekibi · Microsoft Kayıtlı İş Ortağı · MS-100 / MS-102 / AZ-104 sertifikalı danışmanlar · 25+ yıl saha deneyimi

Özet (TL;DR): e-Fatura ve e-Arşiv faturalarının "ikinci nüsha" adı verilen elektronik kopyasını, Gelir İdaresi Başkanlığı'nın (GİB) resmi kuralına göre, mükellefler kendi bilgi işlem sistemlerinde saklayabilir — ama bu saklamanın birincil kopyası Türkiye Cumhuriyeti sınırları içinde olmak zorunda; Azure'ın Türkiye'de bir veri merkezi (bölge) bulunmadığı için Azure Blob Storage bu işte ikincil/yedek arşiv katmanı olarak devreye girer, tek başına birincil saklama çözümü olamaz. Vergi Usul Kanunu'nun (VUK) 253. maddesi 5 yıllık asgari süre öngörse de, Türk Ticaret Kanunu'nun (TTK) 82. maddesi ticari defter ve belgeler için 10 yıllık saklama zorunluluğu getiriyor; pratikte uygulanan süre bu ikisinin daha uzunu olan 10 yıldır. Bu yazıda Azure Blob Storage'ın değiştirilemez (immutable) depolama özelliğiyle 10 yıllık, silinemez/üzerine yazılamaz bir yedek e-fatura arşivini adım adım nasıl kuracağınızı, Logo/Netsis gibi yerli muhasebe programlarından faturaları otomatik aktarma yöntemini ve KVKK'nın sınır ötesi veri transferi kurallarını anlatıyoruz.

Faturalarınızın nerede ve nasıl saklandığından emin değil misiniz? Ücretsiz e-fatura arşiv değerlendirmesi alın — mevcut saklama düzeninizin VUK/TTK/GİB uyumunu birlikte kontrol edelim.

e-Fatura ve e-Arşiv faturalarda saklama (muhafaza) yükümlülüğü nedir?

Elektronik fatura sisteminde iki nüsha kavramı vardır: faturanın GİB'e veya alıcıya iletilen resmi kopyası ve mükellefin kendi arşivinde tutması gereken ikinci nüsha. GİB'in resmi e-Belge sitesine göre, "mükelleflere ait elektronik faturaların yine mükelleflere ait bilgi işlem sistemlerinde saklanması esastır" — yani faturayı kesen ya da alan şirket, bu ikinci nüshayı kendi sunucusunda, kendi bulut ortamında veya yetkili bir üçüncü tarafta muhafaza etmekle yükümlüdür.

Süre konusunda iki kanun farklı rakam verir ve bu genelde kafa karıştırır:

• VUK madde 253 — defter tutmak zorunda olanların, düzenledikleri belgeleri ilgili olduğu takvim yılını izleyen yıldan başlayarak en az 5 yıl saklamasını ister. Bu, vergi incelemesi zamanaşımı süresiyle bağlantılıdır.
• TTK madde 82 — ticari defterler, açılış/kapanış bilançoları, faaliyet raporları ve bunlara dayanak teşkil eden belgelerin (fatura dahil) 10 yıl saklanmasını şart koşar; süre son kaydın yapıldığı takvim yılının bitiminden itibaren işler.

İki kanun çakıştığında uygulanan kural basit: daha uzun olan süre esas alınır. Bu yüzden muhasebe ve vergi danışmanlığı camiasında yerleşik pratik, e-fatura ve e-arşiv faturaları 10 yıl saklamaktır — SGK ve olası hukuki uyuşmazlık riskleri de bu süreyi güvenli tarafta tutmayı destekler. Saklama sırasında faturanın bütünlüğü (değiştirilmemiş, silinmemiş, okunur olması) ve mali mühür ya da nitelikli elektronik sertifika ile onaylı kalması şart.

Faturalarınızı nerede saklayabilirsiniz? Türkiye sınırı kuralı ve Azure'ın yeri

Burada çoğu bulut mimarisi tartışmasının atladığı kritik bir kural var. GİB'in resmi e-Belge sitesi şunu açıkça yazıyor: "Elektronik faturaların muhafazasının Türkiye Cumhuriyeti sınırları içerisinde ve Türkiye Cumhuriyeti kanunlarının geçerli olduğu yerlerde yapılması zorunludur. Bu zorunluluk yurt dışında ikincil bir arşivleme yapılmasına engel teşkil etmez."

Bunun pratik anlamı iki maddede özetlenebilir:

• Birincil (asıl) saklama Türkiye sınırları içinde olmalı. Kendi sunucunuz, Türkiye'de barındırılan bir veri merkezi ya da GİB'den yazılı izinli bir yerli saklama hizmeti sağlayıcısı bu şartı karşılar.
• İkincil/yedek arşivleme yurt dışında serbesttir. Yani birincil kopyanız Türkiye'de dururken, felaket kurtarma (disaster recovery) ve uzun vadeli ek arşiv amacıyla yurt dışındaki bir buluta ikinci bir kopya koymanız yasal olarak engellenmiyor.

Peki Azure Blob Storage nereye oturuyor? Microsoft'un resmi bölge listesine göre (2026-08 itibarıyla) Azure'ın Türkiye'de bir bölgesi (veri merkezi) bulunmuyor; İstanbul'a en yakın seçenekler Hollanda merkezli West Europe ve Polonya merkezli Poland Central bölgeleridir. Bu yüzden Azure Blob Storage'ı e-fatura arşivinizin tek ve birincil deposu yapmak GİB'in Türkiye sınırı şartını karşılamaz. Doğru mimari, Türkiye'de duran bir birincil sistemin yanına, Azure'ı kanunen izin verilen ikincil/yedek arşiv katmanı olarak eklemektir — aşağıdaki bölümde bu mimariyi kuruyoruz.

Doğru mimari: Türkiye'deki birincil sistem + Azure Blob ikincil arşiv

Önerilen katmanlı yapı şöyle işler:

1. Birincil katman (Türkiye içi): Muhasebe/ERP programınızın (Logo Tiger, Netsis, Mikro vb.) kendi e-fatura/e-arşiv modülü ya da özel entegratörünüz, faturaların ikinci nüshasını zaten Türkiye'de saklıyor olmalı — çoğu özel entegratör (yerleşik pratik olarak) bu hizmeti sözleşmenize dahil sunar.
2. İkincil katman (Azure Blob): Birincil sistemden faturaların XML (UBL-TR formatı) ve varsa PDF görünümlerinin bir kopyasını otomatik olarak Azure Blob Storage'a aktarırsınız. Bu katman felaket kurtarma, denetim kolaylığı ve tek bir sağlayıcıya bağımlı kalmama (vendor lock-in riskini azaltma) sağlar — genel felaket kurtarma mantığı, Azure Backup ile sanal makine yedeklemede anlattığımız yaklaşımla aynı ailededir.
3. Değişmezlik (immutability) katmanı: Azure tarafındaki kopyayı, aşağıda kuracağımız kilitli zamana dayalı saklama politikası (locked time-based retention policy) ile 10 yıl boyunca silinemez/üzerine yazılamaz hale getirirsiniz — bu da hem VUK/TTK uyumuna hem de olası bir fidye yazılımı (ransomware) saldırısına karşı ek güvence sağlar.

Microsoft bu özelliği "yaz-bir-kez-oku-çok-kez" (WORM — Write Once, Read Many) modeli olarak adlandırıyor: bir kez yazılan veri, belirlediğiniz süre boyunca ne kullanıcı ne de sistem yöneticisi tarafından silinebiliyor ya da değiştirilebiliyor. Microsoft'un resmi belgelerine göre bu özellik, finans sektöründe SEC 17a-4(f) ve FINRA gibi en katı saklama denetimlerinden geçmiş — yani sadece "arşivleme" değil, denetime dayanıklı bir arşivleme sağlıyor.

Adım adım kurulum: Azure Blob Storage'da değişmez 10 yıllık arşiv container'ı

Aşağıdaki adımlar Microsoft'un resmi Azure CLI dokümantasyonuna dayanıyor. Devam etmeden önce bir Azure aboneliğiniz ve az komut satırı aracının kurulu olması gerekir.

1. Adım 1 — Depolama hesabı (storage account) oluşturun. "Genel amaçlı v2" (general-purpose v2) tipinde, LRS ya da GRS yedeklilik seçeneğiyle bir depolama hesabı açın. Arşiv katmanına taşıma yapacağınız için hesabın yedeklilik ayarının LRS, GRS ya da RA-GRS olması gerekir — ZRS/GZRS arşiv katmanını desteklemez.
2. Adım 2 — Arşiv container'ını oluşturun. Örneğin efatura-arsiv-2026 adında ayrı bir container açın; her yılın faturalarını ayrı bir container'da tutmak, ileride retention süresi dolduğunda temizliği kolaylaştırır.
3. Adım 3 — Faturaları yükleyin, ardından erişim katmanını (tier) belirleyin. Yeni yüklenen bloblar için varsayılan katman genelde "Hot"tur; arşiv amacıyla saklanan, sık erişilmeyen faturalar için "Cool", "Cold" ya da "Archive" katmanına taşımak depolama maliyetini belirgin biçimde düşürür (aşağıda "Maliyet" bölümünde detaylandırıyoruz).
4. Adım 4 — Container'a zamana dayalı saklama politikası (time-based retention policy) tanımlayın. Retention süresini gün cinsinden verirsiniz; 10 yıl için yaklaşık 3.650 gün kullanılır:

   az storage container immutability-policy create \
       --resource-group <kaynak-grubu> \
       --account-name <depolama-hesabi> \
       --container-name efatura-arsiv-2026 \
       --period 3650

   Bu komut çalıştığında politika henüz kilitsiz (unlocked) test aşamasındadır — silebilir ya da süresini değiştirebilirsiniz.
5. Adım 5 — Politikayı test edin, sonra kilitleyin. Testi tamamladıktan sonra (Microsoft 24 saat içinde kilitlemeyi öneriyor), politikanın ETag değerini alıp kilitleme komutunu çalıştırırsınız:

   etag=$(az storage container immutability-policy show \
       --account-name <depolama-hesabi> \
       --container-name efatura-arsiv-2026 \
       --query etag --output tsv)
   
   az storage container immutability-policy lock \
       --resource-group <kaynak-grubu> \
       --account-name <depolama-hesabi> \
       --container-name efatura-arsiv-2026 \
       --if-match $etag

   Kilitlendikten sonra bu politika silinemez — yalnızca süresi uzatılabilir (kısaltılamaz), en fazla 5 kez. Bu geri dönüşsüzlük, tam da VUK/TTK'nın istediği "faturaya dokunulamaz" garantisini veriyor.
6. Adım 6 — Soft delete'i (yumuşak silme) de açık tutun. Microsoft, immutability politikasından önce blob soft delete'in etkinleştirilmesini öneriyor; bu, retention süresi dolmadan yanlışlıkla silinen bir dosyanın geri kurtarılabilir kalmasını sağlar.
7. Adım 7 — Yaşam döngüsü (lifecycle) kuralı ile Archive katmanına otomatik taşıma kurun. Faturalar yüklendikten belli bir süre sonra (ör. 180 gün) otomatik olarak Archive katmanına geçecek şekilde bir "blob lifecycle management" kuralı tanımlayın — böylece manuel katman değiştirme yapmanıza gerek kalmaz.

Kendi ekibiniz Azure CLI'ye hakim değilse endişelenmeyin — Xen ekibiyle 15 dakikalık ücretsiz teknik görüşme ayarlayıp kurulumu birlikte planlayabiliriz.

Logo Tiger, Netsis, Mikro gibi yerli ERP'lerden faturaları otomatik aktarma

Türkiye'deki KOBİ'lerin büyük çoğunluğu e-fatura/e-arşiv süreçlerini Logo Tiger, Netsis Fusion, Mikro Fly ya da bir özel entegratör paneli üzerinden yürütüyor. Bu sistemlerin çoğu, faturaları XML ve PDF olarak bir klasöre (yerel disk, ağ sürücüsü ya da FTP) periyodik olarak dışa aktarma özelliği sunar. Bu çıktıyı Azure Blob'a taşımanın üç yaygın yolu var:

• Power Automate ile klasör izleme: Yerel/ağ klasörüne yeni bir dosya düştüğünde (Logo Tiger'ın "e-fatura giden/gelen" klasörü gibi), bir akış tetiklenip dosyayı otomatik olarak Azure Blob container'ına yükler. Kod yazmadan kurulabilir, orta ölçekli firmalar için yeterlidir.
• AzCopy ile zamanlanmış senkronizasyon: Daha yüksek hacimli firmalarda, gece belirli saatte çalışan bir AzCopy görevi, o günün fatura klasörünü toplu olarak Blob'a senkronize eder — API entegrasyonu gerektirmez, sadece dosya sistemi erişimi yeterlidir.
• Doğrudan API entegrasyonu: Özel entegratörünüzün ya da ERP'nizin bir REST API'si varsa, faturalar oluşturulduğu anda gerçek zamanlı olarak Blob'a yazılabilir — en az gecikme, en fazla geliştirme çabası gerektiren seçenek.

Hangi yöntemi seçerseniz seçin, önemli olan iki şeyin korunması: fatura dosyasının mali mühür/imza bütünlüğünün bozulmadan taşınması ve dosya adlandırma düzeninin (fatura numarası, tarih, vergi kimlik no gibi alanlar içeren) denetimde kolay aranabilir kalmasıdır. Microsoft güvenlik ve uyumluluk ekibimiz bu entegrasyonları kurarken veri bütünlüğü kontrollerini de sürece dahil eder.

KVKK ve sınır ötesi veri transferi: Azure'da arşivlenen faturalar için ne yapmalı

Faturalarda genelde müşteri/tedarikçi adı, adresi, vergi kimlik numarası gibi kişisel veri sayılabilecek bilgiler bulunur. Faturaların bir kopyasını yurt dışındaki bir Azure bölgesine (West Europe, Poland Central vb.) taşımak, 6698 sayılı Kişisel Verilerin Korunması Kanunu (KVKK) kapsamında bir sınır ötesi (yurt dışına) veri transferi sayılır. Bunun için pratikte iki yol var:

• KVKK Kurulu'nun onayladığı Standart Sözleşme: Veri sorumlusu (sizin şirketiniz) ile veri işleyen (Microsoft) arasında KVKK'nın öngördüğü standart sözleşme metni imzalanır; bu mekanizma 2024'ten itibaren aktif olarak kullanılıyor ve ayrıca Kurul iznine gerek bırakmıyor.
• Açık rıza: Daha küçük ölçekli ya da münferit transferlerde ilgili kişilerden açık rıza alınması yolu da mevzuatta yer alır, ama kurumsal ölçekte Standart Sözleşme daha sürdürülebilir bir çözümdür.

Bu adımı atlamak, doğru teknik mimariyi kursanız bile şirketi KVKK açısından riske sokar — bu yüzden Azure'a ikincil arşiv taşımadan önce KVKK uyum sürecinizin (VERBİS kaydı, Standart Sözleşme, veri işleme envanteri) bu yeni veri akışını kapsayacak şekilde güncellendiğinden emin olun. Veri sınıflandırma ve saklama etiketleriyle bu süreci nasıl daha görünür hale getirebileceğinizi Microsoft Purview veri yönetişimi rehberimizde ayrıntılı anlattık.

Maliyet: Archive katmanı neden bu kadar ucuz, bedeli ne?

Microsoft'un resmi belgelerine göre Azure Blob Storage dört ana erişim katmanı sunar: Hot (sık erişilen veri, en yüksek depolama maliyeti ama en düşük erişim maliyeti), Cool (en az 30 gün saklanacak, seyrek erişilen veri), Cold (en az 90 gün saklanacak, çok seyrek erişilen veri) ve Archive (en az 180 gün saklanacak, neredeyse hiç erişilmeyecek veri — depolama maliyeti en düşük katman).

10 yıllık bir e-fatura arşivi tam olarak Archive katmanının hedeflediği senaryodur: veriye yılda belki birkaç kez (bir vergi denetiminde ya da hukuki bir talepte) ihtiyaç duyulur, geri kalan zamanda sadece güvenle "orada durması" yeterlidir. Bunun karşılığında ödediğiniz bedel erişim gecikmesidir: Archive katmanındaki bir dosyayı okumak için önce "rehydrate" (yeniden ısıtma) işlemi gerekir ve bu, Microsoft'un resmi belgelerine göre önceliğinize bağlı olarak 15 saate kadar sürebilir. Ayrıca bir blobu Archive katmanına taşıdıktan sonra 180 günden önce silerseniz ya da başka bir katmana geçirirseniz erken silme (early deletion) ücreti işler — bu yüzden Archive'ı yalnızca gerçekten uzun süre dokunmayacağınız veriler için kullanın. Güncel GB başına fiyatlar bölgeye ve döviz kuruna göre değiştiği için tam rakamı Azure fiyat hesaplayıcısından güncel kurla teyit etmenizi öneririz — kur riskini biz üstleniyoruz, TL bazlı net bir bütçe çıkarmak isterseniz bize yazın.

Yaygın hatalar ve riskler

• Azure'ı tek/birincil arşiv sanmak. Yukarıda anlattığımız gibi, Türkiye sınırı kuralı nedeniyle bu GİB uyumsuzluğu yaratır. Azure her zaman ikincil katman olmalı.
• Politikayı kilitlemeyi unutmak. Kilitlenmemiş (unlocked) bir retention politikası teknik olarak silinebilir/değiştirilebilir durumdadır — denetimde "değiştirilemez arşiv" iddianız geçerli olmaz.
• Retention süresini kısa tutmak. Kilitli bir politikanın süresi sonradan kısaltılamaz, sadece uzatılabilir (en fazla 5 kez). Baştan 10 yıl (3.650 gün) yerine "3 yıl yeter" diye düşünüp sonradan TTK'nın 10 yıllık şartıyla karşılaşmak yaygın bir hata.
• Archive katmanından erken silme. 180 günden önce silme/taşıma erken silme ücretine tabi olur; bütçe planlarken bunu hesaba katmayan firmalar sürpriz fatura ile karşılaşır.
• Mali mühür bütünlüğünü kaybetmek. Dosyaları taşırken format dönüştürme (ör. XML'i farklı bir formata çevirme) mali mührü geçersiz kılabilir; taşıma sürecinde dosyaları olduğu gibi (bit-for-bit) kopyalamak gerekir.
• KVKK sınır ötesi transfer adımını atlamak. Teknik kurulum doğru olsa bile, Standart Sözleşme veya açık rıza mekanizması olmadan yurt dışına veri taşımak ayrı bir uyumsuzluk riski yaratır.

Saha vakası: Tekstil ihracatçısı, 40 kişilik ofis — 7 yıllık dağınık fatura arşivini toparlama

Marmara bölgesinde faaliyet gösteren, yıllık birkaç bin fatura kesen bir tekstil ihracatçısı firma, 2018'den bu yana kullandığı özel entegratörün panelinden faturaları zaman zaman manuel olarak indirip farklı bilgisayarlara, harici disklere ve bir Google Drive hesabına dağınık biçimde kaydediyordu. Firma, bir gümrük denetimi sürecinde üç yıl öncesine ait belirli faturaları hızlıca bulamadığını fark edince Xen ekibinden destek istedi.

İlk tespit: mevcut düzende ne tek bir merkezi arşiv vardı, ne de saklanan kopyaların üzerine yazılmadığına dair bir garanti. Google Drive'daki dosyalar teorik olarak silinebilir ya da değiştirilebilirdi — GİB'in aradığı "değiştirilemez, ibraz edilebilir" ikinci nüsha standardını karşılamıyordu. Ayrıca kişisel Google hesabında kurumsal mali veri tutulması, hem KVKK hem iş sürekliliği açısından ayrı bir risk oluşturuyordu (personel işten ayrılırsa erişim kaybı riski gibi).

Kurulan çözüm: özel entegratör panelindeki mevcut Türkiye içi saklama birincil katman olarak korundu; buna ek olarak Azure Blob Storage'da yıllık container'lar açılarak son 3 yılın faturaları toplu şekilde, sonraki yıllar ise aylık otomatik AzCopy senkronizasyonuyla ikincil arşive taşındı. Her container'a 3.650 günlük kilitli retention politikası uygulandı. Süre: kurulum ve geçmiş veri taşıma dahil yaklaşık 3 hafta. Karar noktaları: (1) hangi yılların container'da mı ayrı ayrı mı tutulacağı, (2) Cool mü Archive mı katman seçileceği (firma yılda 1-2 kez denetim amaçlı erişim ihtiyacı öngördüğü için Cool tercih edildi, Archive'ın 15 saatlik gecikmesi risk olarak görüldü), (3) KVKK Standart Sözleşme sürecinin şirketin mevcut Microsoft 365 aboneliği kapsamında zaten imzalı olup olmadığının teyidi. Sonuç: bir sonraki denetimde istenen 2 yıl önceki faturalar 10 dakikadan kısa sürede, tam ve eksiksiz biçimde ibraz edildi. Xen ekibinin rolü: mimari tasarım, container/retention kurulumu, geçmiş veri taşıma script'i ve KVKK süreç teyidi. Uyarı: bu bir tek seferlik proje değil — yeni faturalar için otomatik akışın sürekli çalıştığından periyodik olarak emin olunmalı.

Sıkça Sorulan Sorular (SSS)

e-Fatura ve e-Arşiv faturaları kaç yıl saklamak zorundayım?

VUK madde 253'e göre asgari 5 yıl, ama Türk Ticaret Kanunu madde 82 ticari belgeler için 10 yıl saklama şartı getiriyor. İki süre çakıştığında daha uzun olan (10 yıl) esas alınır; muhasebe camiasında yerleşik pratik de budur.

Faturalarımı doğrudan Azure Blob Storage'da saklayabilir miyim, başka bir şeye gerek var mı?

Hayır, tek başına yeterli değil. GİB'in kuralına göre birincil saklama Türkiye Cumhuriyeti sınırları içinde olmalı; Azure'ın Türkiye'de bir veri merkezi bulunmadığı için Azure Blob'u yalnızca ikincil/yedek arşiv katmanı olarak kullanabilirsiniz, birincil kopyanız Türkiye içinde (kendi sisteminiz ya da yerli bir saklama hizmeti sağlayıcısı) durmalı.

Kendi faturalarımı Azure'da saklamak için GİB'den ayrı bir izin almam gerekiyor mu?

Hayır. GİB'in yazılı izin şartı, başka mükelleflere saklama hizmeti satan kuruluşlar içindir. Kendi faturalarınızı kendi bilgi işlem sisteminizin bir parçası olarak (Azure dahil) saklıyorsanız ayrı bir GİB izni gerekmez; sorumluluk yine sizde kalır.

Azure Blob Storage'da "değişmez (immutable) depolama" tam olarak ne sağlıyor?

Kilitli bir zamana dayalı saklama politikası (locked time-based retention policy) tanımladığınızda, o container'daki dosyalar belirlediğiniz süre boyunca (ör. 3.650 gün / 10 yıl) hiç kimse tarafından — sistem yöneticisi ve Microsoft destek ekibi dahil — silinemez veya üzerine yazılamaz hale gelir. Bu, denetimde "faturaya sonradan dokunulmadı" garantisi vermenizi sağlar.

Archive katmanına taşınan bir faturaya acil ihtiyacım olursa ne kadar sürede erişebilirim?

Microsoft'un resmi belgelerine göre Archive katmanından bir dosyayı okunabilir hale getirmek (rehydrate) önceliğinize bağlı olarak birkaç saatten 15 saate kadar sürebilir. Yılda birkaç kez erişim bekliyorsanız, biraz daha pahalı ama anında erişilebilir Cool ya da Cold katmanını tercih etmek daha pratik olabilir.

Faturalarımın bir kopyasını yurt dışındaki Azure bölgesine taşımak KVKK'ya aykırı mı?

Aykırı değil, ama ayrı bir uyum adımı gerektiriyor. Faturalar kişisel veri sayılabilecek bilgiler içerdiği için, KVKK Kurulu'nun onayladığı Standart Sözleşme mekanizmasıyla (veya ilgili kişilerden açık rıza alarak) bu sınır ötesi transferi mevzuata uygun hale getirmeniz gerekir.

Logo Tiger veya Netsis kullanıyorum; Azure'a aktarım için özel bir entegrasyon mu yazdırmam gerekiyor?

Zorunlu değil. Çoğu firma için Power Automate ile klasör izleme ya da zamanlanmış AzCopy senkronizasyonu, kod geliştirmeden kurulabilecek kadar yeterlidir. Yüksek hacimli, gerçek zamanlı ihtiyaçlarda API entegrasyonu daha uygun olabilir.

Sonuç: Azure Blob, doğru yerde kullanılırsa güçlü bir yedek arşiv katmanı

e-Fatura ve e-Arşiv faturalarınızın 10 yıllık saklama yükümlülüğünü karşılamak için Azure Blob Storage değerli bir araç — ama yalnızca doğru rolde kullanıldığında. Birincil saklamanızı Türkiye sınırları içinde tutup, Azure'ın değişmez depolama özelliğini felaket kurtarma ve denetime dayanıklı bir ikincil arşiv katmanı olarak eklemek, hem GİB'in Türkiye sınırı şartını hem VUK/TTK'nın 10 yıllık saklama zorunluluğunu hem de günümüzün siber güvenlik risklerini (ransomware, yanlışlıkla silme) aynı anda karşılayan bir yaklaşım.

Kurulumun teknik kısmı (immutability policy, lifecycle yönetimi, ERP entegrasyonu) birkaç saatlik bir iş; asıl zaman alan kısım doğru mimariyi ve KVKK sürecini baştan doğru kurgulamak. Bu yazıdaki adımları kendi ekibinizle uygulayabilir, ya da uçtan uca kurulumu bize bırakabilirsiniz.

Microsoft İstanbul — Xen Bilişim ekibi olarak, kurumunuzun e-fatura/e-arşiv arşivleme mimarisini VUK/TTK/GİB ve KVKK uyumlu şekilde kurma, Azure Blob immutable storage yapılandırması ve yerli ERP entegrasyonunda uçtan uca destek sağlıyoruz. İletişim sayfamızdan ücretsiz mimari değerlendirmenizi alın.