Kısaca
Sigorta bulut dönüşümü; poliçe, hasar, kanal ve analitik iş yüklerinin şirket içi veri merkezinden kamu, özel veya hibrit bulut ortamlarına planlı biçimde taşınması ve buluta uygun şekilde yeniden tasarlanmasıdır. Türkiye'de başarının anahtarı, KVKK ve sektör düzenlemelerinden doğan veri yerelliği gerekliliklerini iş yükü bazında sınıflandırıp mimariyi buna göre kurmaktır.
Sigorta bulut dönüşümü, bir sigorta şirketinin poliçe, hasar, satış kanalları, analitik ve destek sistemlerini şirket içi veri merkezlerinden bulut ortamlarına planlı biçimde taşıması ve bu sistemleri bulutun sunduğu esneklikten yararlanacak şekilde yeniden tasarlaması demektir. Amaç yalnızca sunucuların yerini değiştirmek değil; ölçeklenme, yayın hızı, iş sürekliliği ve maliyet görünürlüğü kazanmaktır.
Türkiye'de sigorta şirketleri için bu dönüşümün belirleyici başlığı veri yerelliğidir. Kişisel verilerin korunmasına ilişkin mevzuat, sektör düzenleyicisinin bilgi sistemleri ve dış hizmet alımı beklentileri ile iş ortaklarının sözleşmesel şartları, hangi verinin nerede tutulabileceğini doğrudan etkiler. Bu rehber, dağıtım modelini seçmekten iş yüklerini sınıflandırmaya kadar dönüşümün temel kararlarını ele alıyor.
Sigorta şirketlerinde bulut dönüşümü ne anlama gelir?
Bulut dönüşümü, altyapının bir hizmet olarak tüketilmesine ve uygulamaların bu modele uygun hale getirilmesine dayanan çok aşamalı bir programdır. Tek bir taşıma projesi değil; mimari, güvenlik, operasyon ve maliyet yönetimini birlikte değiştiren bir süreçtir.
Bulutta üç temel hizmet modeli bulunur:
- Altyapı hizmeti (Infrastructure as a Service, IaaS): Sanal sunucu, depolama ve ağ kaynakları kiralanır; işletim sistemi ve üzerindeki her şey şirketin sorumluluğundadır.
- Platform hizmeti (Platform as a Service, PaaS): Veritabanı, mesaj kuyruğu, konteyner platformu gibi yönetilen hizmetler kullanılır; altyapı yönetimi sağlayıcıya geçer.
- Yazılım hizmeti (Software as a Service, SaaS): Uygulamanın kendisi hizmet olarak alınır; örneğin bir çağrı merkezi veya doküman yönetimi çözümü.
Sigorta şirketlerinde dönüşüm genellikle kanal uygulamaları, test ortamları ve analitikle başlar; poliçe ve muhasebe gibi kayıt sistemleri daha sonra ve daha temkinli bir planla ele alınır.
Hangi bulut dağıtım modeli sigorta şirketine uygundur?
Tek bir doğru model yoktur; çoğu sigorta şirketi için gerçekçi hedef, iş yüklerinin hassasiyetine göre birden fazla ortamı birlikte kullanan hibrit bir yapıdır. Seçim; veri sınıfı, performans ihtiyacı, maliyet ve ekip yetkinliği birlikte değerlendirilerek yapılmalıdır.
| Model | Tanım | Güçlü yönü | Dikkat edilecek nokta |
|---|---|---|---|
| Kamu bulutu | Paylaşımlı altyapı, küresel sağlayıcı | Geniş hizmet yelpazesi, hızlı ölçeklenme | Veri merkezinin konumu ve yurt dışına aktarım değerlendirmesi |
| Yerel bulut sağlayıcı | Türkiye'de veri merkezi bulunan sağlayıcı | Veri yerelliği gerekliliklerini karşılamak kolaylaşır | Yönetilen hizmet çeşitliliği ve olgunluğu |
| Özel bulut | Şirkete ayrılmış, şirket içinde veya barındırmalı altyapı | En yüksek kontrol | Kurulum ve işletme maliyeti, ekip yükü |
| Hibrit bulut | Birden fazla modelin ortak yönetimi | Hassas veriyi içeride tutup esnekliği dışarıda kullanma | Ağ, kimlik ve izleme bütünlüğü |
Hibrit yapıda sık görülen bir desen, kişisel veri barındıran kayıt sistemlerinin yurt içindeki özel veya yerel bulutta kalması, anonimleştirilmiş veriyle çalışan analitik ve test iş yüklerinin ise daha esnek ortamlara taşınmasıdır.
Veri yerelliği sigorta şirketleri için neden kritiktir?
Veri yerelliği, verinin fiziksel olarak hangi ülkede saklandığı ve kimler tarafından nereden erişildiği sorusudur; sigorta şirketleri yoğun kişisel veri işlediği için bu soru mimari kararların merkezindedir. Poliçe sahibi, sigortalı, lehtar ve hasar dosyası bilgileri kişisel veridir; sağlık sigortası ve bazı hasar dosyalarında ise özel nitelikli kişisel veri olan sağlık verisi işlenir.
Dikkate alınması gereken başlıca çerçeveler şunlardır:
- KVKK: 6698 sayılı Kişisel Verilerin Korunması Kanunu, kişisel verilerin yurt dışına aktarımını belirli şartlara bağlar. 2024 yılında yapılan değişiklikle yeterlilik kararı, standart sözleşme ve bağlayıcı şirket kuralları gibi uygun güvence mekanizmaları düzenlendi; standart sözleşmelerin Kişisel Verileri Koruma Kurumu'na bildirilmesi gibi usul yükümlülükleri de getirildi.
- Sektör düzenlemeleri: Sigortacılık ve Özel Emeklilik Düzenleme ve Denetleme Kurumu (SEDDK), bilgi sistemlerinin yönetimi, dış hizmet alımı, iş sürekliliği ve denetim erişimi konularında beklentiler ortaya koyar. Bulut sağlayıcısı, bu beklentiler açısından bir dış hizmet sağlayıcıdır.
- İş ortağı şartları: Bankasürans ortakları ve kurumsal müşteriler, sözleşmelerinde verinin yurt içinde tutulması veya belirli güvenlik sertifikaları gibi ek şartlar talep edebilir.
- Kamu güvenlik rehberleri: Kurumun kapsamda olup olmadığına bağlı olarak Cumhurbaşkanlığı Dijital Dönüşüm Ofisi'nin Bilgi ve İletişim Güvenliği Rehberi de değerlendirilmelidir.
Veri yerelliğinde yalnızca depolama konumu değil, erişim konumu da önemlidir: veri Türkiye'deki bir veri merkezinde dursa bile yurt dışındaki bir destek ekibinin bu veriye erişmesi, aktarım olarak değerlendirilebilir. Bu nedenle sağlayıcının destek ve yönetim modeli sözleşme aşamasında netleştirilmelidir.
Mevzuatın yorumu şirketin hukuk ve uyum birimleriyle birlikte yapılmalıdır. Yazılım tarafındaki etkileri için KVKK uyumlu sigorta yazılımı ve sigorta yazılımında mevzuat uyumu yazılarımıza bakabilirsiniz.
Hangi iş yükleri önce buluta taşınmalı?
İlk taşınacak iş yükleri, veri hassasiyeti düşük, değişim sıklığı yüksek ve ölçeklenme ihtiyacı değişken olanlardır. Her iş yükü için bir taşıma stratejisi seçilmesi, dönüşümü yönetilebilir kılar.
Yaygın olarak kullanılan "6R" sınıflandırması şöyledir:
- Rehost (olduğu gibi taşıma): Uygulama değiştirilmeden sanal sunuculara taşınır. Hızlıdır, ancak bulutun avantajlarından sınırlı yararlanılır.
- Replatform (platform uyarlaması): Kod büyük ölçüde korunur, veritabanı veya çalışma ortamı yönetilen hizmetlere geçirilir.
- Refactor (yeniden tasarım): Uygulama konteyner ve servis tabanlı mimariye dönüştürülür; en fazla emeği ve en fazla kazanımı getirir.
- Repurchase (yeniden satın alma): Mevcut sistem bir SaaS çözümüyle değiştirilir.
- Retain (yerinde bırakma): Şimdilik taşınmaz; genellikle hassas veya kısa vadede değiştirilmesi riskli sistemler.
- Retire (emekliye ayırma): Artık kullanılmayan sistemler kapatılır.
Sigorta şirketlerinde sık görülen öncelik sırası; geliştirme ve test ortamları, acente portalı ve dijital satış kanalları, doküman ve bildirim servisleri, analitik platformu ve en son çekirdek poliçe ile muhasebe sistemleri şeklindedir. Çekirdek sistemin bulut uyumlu hale getirilmesi çoğu zaman bir mimari dönüşüm gerektirir; bu konuda sigortacılıkta mikroservis mimarisi yazısı yol gösterebilir.
Bulut dönüşümü adım adım nasıl planlanır?
Başarılı bir dönüşüm, teknik taşımadan önce veri sınıflandırması, hedef mimari ve yönetişim modeliyle başlar. Aşağıdaki adımlar, sigorta şirketleri için uygulanabilir bir çerçeve sunar.
- Envanter çıkarın: Uygulamaları, veritabanlarını, entegrasyonları, toplu işleri ve bağımlılıkları listeleyin.
- Veriyi sınıflandırın: Her sistemin işlediği veriyi kişisel, özel nitelikli, ticari sır ve genel olarak etiketleyin.
- Düzenleyici ve sözleşmesel gereklilikleri eşleyin: Hukuk, uyum ve bilgi güvenliği birimleriyle her veri sınıfı için izin verilen konum ve erişim modelini belirleyin.
- Hedef mimariyi tasarlayın: Dağıtım modelini, ağ topolojisini, kimlik yönetimini, yedekleme ve felaket kurtarma yapısını tanımlayın.
- Açılış alanını (landing zone) kurun: Hesap yapısı, ağ bölümleme, merkezi kayıt, şifreleme ve politika kontrollerini taşıma başlamadan hazırlayın.
- Pilot iş yüküyle başlayın: Düşük riskli bir sistemi taşıyarak süreçleri, araçları ve ekip yetkinliğini doğrulayın.
- Dalgalar halinde taşıyın: İş yüklerini bağımlılıklarına göre gruplayın; her dalga için geri dönüş planı hazırlayın.
- İşletme modelini oturtun: İzleme, olay yönetimi, maliyet takibi ve kapasite planlamasını sürekli süreçler haline getirin.
Bulutta güvenlik, maliyet ve bağımlılık nasıl yönetilir?
Bulutta güvenlik, sağlayıcı ile müşteri arasında paylaşılan bir sorumluluktur; maliyet ise tasarımla yönetilmediğinde hızla kontrolden çıkabilir. Her iki konu da dönüşümün başında yönetişim kurallarıyla güvence altına alınmalıdır.
Güvenlik
Paylaşılan sorumluluk modelinde fiziksel altyapı sağlayıcıya, veri, kimlik, erişim ve uygulama güvenliği şirkete aittir. Hassas veriler için şifreleme anahtarlarının şirketin kontrolünde olduğu modeller (Bring Your Own Key, BYOK veya donanım güvenlik modülü tabanlı çözümler) tercih edilebilir. Ayrıntılar için sigortacılıkta siber güvenlik yazımıza göz atabilirsiniz.
Maliyet
Bulut maliyeti kullanıma göre değiştiği için finans ve teknoloji ekiplerinin ortak çalıştığı bir maliyet yönetimi disiplini (FinOps) kurulmalıdır. Kaynak etiketleme, bütçe uyarıları, kullanılmayan ortamların otomatik kapatılması ve rezervasyon modelleri temel uygulamalardır.
Sağlayıcı bağımlılığı ve çıkış planı
Dış hizmet alımında düzenleyici beklentilerin önemli bir parçası, hizmetin sonlandırılması halinde verinin ve işlevin geri alınabilmesidir. Açık standartlara dayalı konteyner platformları, taşınabilir veri formatları ve belgelenmiş bir çıkış planı bu riski azaltır.
Sigorta bulut dönüşümü kontrol listesi
- Tüm uygulama ve verilerin güncel bir envanteri var mı?
- Her veri sınıfı için izin verilen saklama ve erişim konumu hukuk birimiyle belirlendi mi?
- Bulut sağlayıcısının destek ekiplerinin veriye erişim modeli sözleşmede tanımlı mı?
- Şifreleme anahtarlarının yönetimi kimde, nasıl denetleniyor?
- Denetim ve düzenleyici erişim hakları sözleşmede güvence altında mı?
- Felaket kurtarma için hedef kurtarma süresi ve veri kaybı toleransı tanımlandı mı?
- Maliyet etiketleme ve bütçe takibi ilk günden kuruldu mu?
- Sağlayıcı değişikliği veya hizmetin sonlanması için yazılı bir çıkış planı var mı?
Bulut dönüşümü teknik olduğu kadar organizasyonel bir programdır. Hedef mimari ve yol haritası için destek almak isterseniz bizimle iletişime geçebilirsiniz.
Sık sorulan sorular
Sigorta şirketleri kişisel verileri yurt dışındaki bir bulutta tutabilir mi?
Bu, KVKK'nın yurt dışına aktarım hükümlerine ve sektörel düzenlemelere uygunluğa bağlıdır. 2024 değişikliğiyle yeterlilik kararı ve standart sözleşme gibi mekanizmalar tanımlandı; ancak her aktarımın şartları ayrıca değerlendirilmelidir. Sigorta şirketinin hukuk ve uyum birimleri, veri sınıfına göre izin verilen konumları belirlemeli ve bulut sözleşmesi bu değerlendirmeye göre yapılandırılmalıdır.
Hibrit bulut sigorta şirketleri için neden sık tercih edilir?
Hibrit bulut, kişisel ve özel nitelikli veri barındıran kayıt sistemlerini yurt içinde, kontrollü ortamlarda tutarken kanal uygulamaları, test ortamları ve anonim veriyle çalışan analitik iş yükleri için bulutun esnekliğinden yararlanmayı sağlar. Böylece veri yerelliği gereklilikleri ile ölçeklenme ihtiyacı arasında denge kurulur. Başarı için ağ, kimlik ve izleme katmanlarının iki ortamda bütünleşik yönetilmesi gerekir.
Core poliçe sistemi buluta taşınmalı mı?
Taşınabilir, ancak genellikle ilk adım olmamalıdır. Core sistemler yoğun entegrasyon, toplu iş ve mali kayıt içerdiği için önce kanal, test ve analitik iş yükleriyle deneyim kazanmak daha güvenlidir. Core sistem için olduğu gibi taşıma kısa vadeli bir çözüm olabilir; asıl kazanım ise sistemin servis tabanlı ve buluta uygun bir mimariye kademeli olarak dönüştürülmesiyle elde edilir.
Bulut dönüşümü maliyetleri düşürür mü?
Her zaman değil. Bulut, değişken yükleri karşılamada ve kullanılmayan kapasiteyi kapatmada tasarruf sağlar; ancak olduğu gibi taşınan ve sürekli açık kalan iş yükleri şirket içinden daha pahalıya gelebilir. Maliyet avantajı; doğru boyutlandırma, otomatik ölçeklenme, kaynak etiketleme ve düzenli maliyet incelemesi gibi FinOps uygulamalarıyla elde edilir.
Bulut sağlayıcısı seçerken nelere bakılmalı?
Veri merkezlerinin konumu, destek ekiplerinin veriye erişim modeli, sahip olunan güvenlik sertifikaları, denetim ve düzenleyici erişim hakları, şifreleme anahtarı yönetimi seçenekleri, yönetilen hizmet çeşitliliği ve çıkış koşulları temel kriterlerdir. Bunlara ek olarak sağlayıcının Türkiye'deki destek kapasitesi ve mevcut sistemlerle entegrasyon kolaylığı da değerlendirilmelidir.