Finansal Bir Kuruluşta IT’yi Kurmak: Sahadaki Gerçekler ve Adım Adım Rehber

Yazar: Şükür Muhacir | IT Genel Müdür Yardımcısı, Fair Teknoloji A.Ş.

Bir finansal kuruluşta IT yöneticisi olmak, diğer sektörlerden köklü biçimde ayrışır. Burada teknik yetkinlik yetmez; regülatör baskısı, denetim takvimi, iş sürekliliği zorunluluğu ve çok katmanlı güvenlik gereksinimleri aynı anda yönetilmek zorundadır. Hem bir katılım bankası hem de birden fazla finansal teknoloji şirketi için IT altyapısını kurma ve yönetme sürecinden geçen biri olarak, bu yazıda hiç kimsenin size söylemeyeceği gerçekleri ve izlenmesi gereken adımları paylaşmak istiyorum.

1. Başlamadan Önce: Mevzuatı Okuyun

Çoğu IT yöneticisi teknik mimariyle başlar. Bu hata olur.

Finansal kuruluşlar, bankacılık denetim otoritelerinin yayımladığı bilgi teknolojileri yönetmeliklerine tabidir. Bu belgeler; ortam ayrılığı (geliştirme, test, üretim), değişiklik yönetimi, veri yönetimi, erişim kontrolü, iş sürekliliği, felaket kurtarma ve denetim izi gibi temel başlıkları kapsar. Bunları okumadan atacağınız her teknik adım ilerleyen dönemde ya yeniden yapılmak ya da pahalı biçimde yamaya çalışılmak zorunda kalacaktır.

Yapmanız gerekenler:

  • İlgili düzenleyici otorite mevzuatını baştan sona okuyun ve bir kontrol listesi çıkarın.
  • Uyum ekibinizle (varsa) veya uyum danışmanınızla birlikte bir boşluk analizi (gap analysis) yapın.
  • Teknik kararlarınızı bu liste üzerine oturtun; tersini değil.

Uluslararası çerçevelerden de yararlanmak istiyorsanız NIST Cybersecurity Framework, ISO/IEC 27001 ve sektörünüze özgü standartlar iyi başlangıç noktalarıdır. Ancak yerel mevzuat her zaman önceliklidir.

2. IT Yönetişim Yapısını Kurun

IT altyapısından önce, IT yönetişimini kurmanız gerekir. Bu iki farklı şeydir.

Yönetişim şu soruları cevaplar: Kararlar kim tarafından nasıl alınır? Değişiklikler nasıl onaylanır? Olaylar nasıl raporlanır? Politikalar kim tarafından hazırlanır ve kim tarafından uygulanır?

Bir finansal kuruluşta IT yöneticisi olarak konumlanırken şunları net biçimde tanımlamalısınız:

  • IT politika ve prosedür seti: Erişim yönetimi, değişiklik yönetimi, olay yönetimi, yedekleme ve felaket kurtarma, tedarikçi yönetimi politikaları olmazsa olmaz başlangıç belgelerinizdir.
  • Rol ve sorumluluk matrisi: Kim neye yetkili, kim neyin sahibi? Özellikle birden fazla şirketi kapsayan bir yapıda bu matris hayat kurtarır.
  • Üst yönetim bağlantısı: Denetimler sırasında öğreneceksiniz ki üst yönetimin IT politikalarını onaylamış ve sahiplenmiş olması, teknik kontrollerin varlığı kadar önemli. Bunu baştan sağlayın.

3. Altyapı Mimarisini Doğru Kurun

Ortam Ayrılığı

Bu konu hem teknik hem de regülatif bir zorunluluktur. Geliştirme, test ve üretim ortamları birbirinden fiziksel veya sanallaştırma düzeyinde ayrılmış olmalıdır. Uygulamacıların doğrudan üretim ortamına müdahale edemediği, her değişikliğin bir onay sürecinden geçtiği bir yapı kurmazsanız hem güvenlik açığı yaratırsınız hem de denetimde ciddi bulgularla karşılaşırsınız.

Sahada gördüğüm en yaygın hata: yazılım ekibinin acil gerekçesiyle üretim ortamına doğrudan erişim yapması. Bu bir defada bile olsa, belgelenmiş, izlenmiş ve onaylanmış bir sürecin dışına çıkmak anlamına gelir.

Depolama ve Sunucu Mimarisi

Finansal verilerin tutulduğu bir altyapıda depolama çözümü seçimi kritiktir. Kapasiteyi bugün değil, iki-üç yıl sonrası için planlayın. Disk doluluk oranlarını sürekli izleyin ve eşik uyarıları kurun. Bir sistem yöneticisinin sabah işe geldiğinde bir uyarı görmesi değil, sistemin kendisinin sizi gece yarısı uyarması gerekir.

Mimariyi oluştururken şu bileşenler için plan yapın:

  • Birincil veri merkezi: Üretim sistemleri, kritik uygulama sunucuları, merkezi depolama
  • İkincil site (DRS – Disaster Recovery Site): Fiziksel olarak ayrı konumda, kritik sistemlerin anlık ya da düzenli aralıklarla güncellenen kopyası
  • Yedekleme altyapısı: DRS’den bağımsız, tercihen coğrafi olarak farklı bir konumda

4. Felaket Kurtarma Planı: Kağıt Üzerinde Değil, Test Edilmiş Olsun

Felaket kurtarma planı (DR/DRS) hazırlamak, bunu hayata geçirmekten çok daha kolaydır. Finansal kuruluşlar için düzenleyici otoriteler bu planların yalnızca belgelenmiş değil, düzenli olarak test edilmiş olmasını bekler.

Planınızı oluştururken her kritik sistem için iki metrik tanımlamanız gerekir:

  • RTO (Recovery Time Objective): Sistemin kesintiden sonra ne kadar sürede ayağa kalkması gerekiyor?
  • RPO (Recovery Point Objective): Sistem kurtarıldığında en fazla ne kadar veri kaybedilebilir?

Bu metrikleri iş birimiyle birlikte belirleyin, IT’nin tek başına değil. Muhasebe sistemi için bir saatlik veri kaybını kabul edilemez bulan iş birimi, bunu söylemezse siz bilemezsiniz.

Planın içinde mutlaka şunlar yer almalıdır:

  • Her kritik sistem için geri yükleme adımları ve sırası (runbook)
  • Kimin ne zaman ne yapacağını gösteren rol matrisi
  • İletişim planı (kimle, nasıl, hangi kanaldan iletişim kurulacak)
  • Yılda en az bir kez yapılacak tatbikat takvimi

Felaket kurtarma tatbikatları, süreçleri tekrarlanabilir ve yönetilebilir kılmak için standart şablonlar üzerinde çalışılmasını ve her senaryo için onay adımları içeren iş akışları oluşturulmasını gerektirir.

5. Siber Güvenlik: Olgunlukla Başlayın, Süreçle İlerleyin

Bir finansal kuruluşta siber güvenlik yöneticisi sizi sıfır noktasından hedef noktasına götürmesi gereken bir olgunluk yolculuğudur. Tek seferlik kurulum değil, sürekli iyileştirme sürecidir.

Nerede Olduğunuzu Bilin

Bir siber güvenlik olgunluk değerlendirmesi, mevcut durumunuzu politika bütünlüğü, erişim yönetimi, izleme, yedekleme ve olay müdahale hazırlığı gibi alanlarda ölçer; ardından belirli bir hedef olgunluk düzeyine ulaşmak için bir yol haritası oluşturulur.

Sahada bu değerlendirmeyi yaptığımda, çoğu zaman teknik kontrollerin kısmen kurulmuş ancak belgelenmemiş, belgelenmiş ancak test edilmemiş ya da test edilmiş ancak güncel tutulmamış olduğunu gördüm. Olgunluk yalnızca teknoloji satın almak değildir.

Kimlik ve Erişim Yönetimi (IAM/PAM)

Bir kimlik-önce strateji; tek oturum açma (SSO), çok faktörlü kimlik doğrulama (MFA), koşullu erişim ve ayrıcalıklı erişim yönetimini (PAM) kapsayan bir yaklaşımla, olgunluk yol haritasının en yüksek etkili önceliklerinden birini oluşturur.

Uygulamada şunu söyleyebilirim: çalışan işe başladığında ne kadar hızlı sisteme erişim alıyorsa, işten ayrıldığında da o kadar hızlı erişimi kaldırılmalıdır. Bu çift yönlü hız, regülatif denetimlerde en çok sorulan konular arasındadır.

Özellikle ayrıcalıklı erişim yönetimi ve SIEM gibi ileri seviye çözümleri hayata geçirmek, servis yönetimi, varlık envanteri ve kimlik yaşam döngüsü gibi temel IT işlevleri yeterince olgunlaşmadan gerçekten etkili olmaz. Bu nedenle temelden başlayın.

SIEM ve Güvenlik İzleme

SOC’un yol haritasında felaket kurtarma önlemleri de bulunmalıdır. Bir sistem ele geçirildiğinde ve saldırı başarılı olduğunda, bu önlemler saatler ile günler arasındaki farkı belirler.

Güvenlik izlemenin konsolidasyonu — SIEM/SOAR ile net SLA’ler içeren oyun kitapları — olgunluk yol haritasının temel makro girişimlerinden birini oluşturur.

SIEM kurmanın ötesinde, hangi olayın gerçekten alarm tetiklemesi gerektiğini tanımlamanız gerekir. Çok gürültülü bir SIEM, analistleri körleştirir.

SOC ve NOC: İkisi de Gereklidir, İkisi de Farklıdır

NOC öncelikle hizmet ve uygulama dağıtımı, operasyon, bakım ve operasyonel ya da doğal afetlerden kurtarmayla ilgilenirken; SOC, siber tehditlere karşı güvenlik mimarisini oluşturur ve sürekli iyileştirir.

Küçük ve orta ölçekli finansal kuruluşlar için bu iki işlevi bir arada yürütmek mümkün olmakla birlikte, rolleri ve sorumlulukları birbirinden net biçimde ayırmanız gerekir. NOC, sistemlerin çalışıp çalışmadığına bakar; SOC, onlara kimin ne amaçla eriştiğini izler.

6. Değişiklik Yönetimi: En Çok İhmal Edilen Kontrol

Bir finansal kuruluşta değişiklik yönetimi olmaksızın yapılan her teknik müdahale bir risktir. Bu kural; sunuculara, ağ cihazlarına, uygulamalara ve veri tabanlarına eşit biçimde uygulanır.

Etkin bir değişiklik yönetimi süreci şunları kapsamalıdır:

  • Değişiklik talebi ve etki analizi
  • Teknik ve yönetimsel onay
  • Uygulama planı ve geri alma (rollback) prosedürü
  • Değişiklik sonrası doğrulama
  • Tüm sürecin kayıt altına alınması

Denetçiler, değişikliklerin kayıt altında olup olmadığını sorar. Ama daha önemlisi: bir üretim sistemi bozulduğunda geri dönme yeteneğinizi bu kayıtlar belirler.

7. Tedarikçi Yönetimi: Sözleşme Masasında Kazanın

Bir finansal kuruluşun IT altyapısı kaçınılmaz olarak birden fazla tedarikçiye dayanır. Donanım, yazılım, bulut hizmetleri, güvenlik çözümleri, bakım anlaşmaları… Bu tedarikçilerle kurduğunuz ilişkinin kalitesi, sistemlerinizin kalitesi kadar önemlidir.

Tedarikçi yönetiminde dikkat edilmesi gerekenler:

  • SLA’ları operasyonel ihtiyaçlarınıza göre tanımlayın: Bir ödeme altyapısı için iki saatlik yanıt süresi ile bir iç raporlama aracı için iki saatlik yanıt süresi aynı anlama gelmez.
  • Sözleşme kapsamını net tutun: Mevzuat değişikliklerinden kaynaklanacak geliştirme maliyetleri kimin sorumluluğundadır? Bu soru, ilerleyen dönemde ciddî anlaşmazlıklara yol açar.
  • Tedarikçi bağımlılığını (vendor lock-in) yönetin: Kritik sistemlerde tek tedarikçiye bağımlı olmak hem risktir hem de müzakere gücünüzü azaltır.
  • NOC, tedarikçi, serbest çalışan ve yüklenici ilişkilerini yönetmek zorundadır; çünkü bu ilişkiler ağ kullanılabilirliği ve performans SLA’larının tutulmasına doğrudan etki eder.

8. Çok Şirketli Yapılarda IT Yönetimi

Eğer tek bir kuruluş için değil, bir holding ya da grup yapısı için IT yönetiyorsanız karmaşıklık üssel olarak artar.

Bu yapıda başarılı olmak için:

  • Merkezi politika, yerel uygulama: Temel güvenlik politikaları, yedekleme standartları ve değişiklik yönetimi merkezi olarak tanımlanmalı; ancak her şirketin operasyonel gereksinimleri yerel düzeyde karşılanmalıdır.
  • Konsolide izleme: Her şirket için ayrı izleme panoları kurmak yerine, konsolide bir görünüm oluşturun. Bir sistemin hangi şirkete ait olduğundan bağımsız olarak tek bir ekrandan anlık durum görülebilmelidir.
  • Hizmet kataloğu oluşturun: IT’nin hangi hizmeti hangi şirkete, hangi koşullarda ve hangi maliyetle sunduğunu tanımlayan bir hizmet kataloğu, hem iç hesap verebilirlik hem de üst yönetimle iletişim açısından son derece değerlidir.
  • Maliyet dağılımını şeffaf tutun: Paylaşılan altyapının maliyeti adil ve izlenebilir biçimde dağıtılmalıdır.

9. IT Ekibini Kurmak: Teknik Yetkinlik Yetmez

Finansal kuruluşlarda IT ekibi kurarken yalnızca teknik beceri değil, regülatif farkındalık da kritiktir. Bir sistem yöneticisinin yedekleme rutinini yürütmesi yetmez; neden yürüttüğünü, hangi mevzuat maddesine dayandığını ve kayıtların nasıl tutulacağını da bilmesi gerekir.

Kadro yapısında en azından şu rollerin karşılanmış olması beklenir:

  • Ağ ve sistem yönetimi
  • Siber güvenlik (SOC/NOC operasyonu dahil)
  • Felaket kurtarma ve iş sürekliliği koordinasyonu
  • Uygulama altyapısı / DevOps (yazılım geliştirmeden bağımsız)
  • IT uyum ve denetim koordinasyonu

Bu rollerin tamamını başlangıçta tek kişide toplamak zorunda kalabilirsiniz. Bu gerçekçidir; ancak uzun vadede hangi rollerin içselleştirileceğini, hangilerinin dış kaynak ya da yönetilen hizmet modeline geçileceğini planlayın.

10. Sürekli İyileştirme: Bitiş Noktası Yoktur

Finansal hizmetler sektöründe uyum iş yükü son dönemde ciddi biçimde artmıştır; kurumlar risk değerlendirmelerini gerçekleştirmek, kapsamlı bilgi güvenliği önlemleri uygulamak ve güvenlik risklerini sürekli izlemek zorundadır.

Bu gerçekle yüzleşmeniz gerekiyor: bir finansal kuruluşta IT’yi “kurup bitirmek” diye bir kavram yoktur. Mevzuat değişir, tehdit ortamı gelişir, iş modeli büyür, denetçi beklentileri artar.

Peki ne yapmalısınız?

  • Yıllık siber güvenlik olgunluk değerlendirmesi yapın. Mevcut durumu puanlayın, hedef durumu tanımlayın, aradaki farkı kapatmak için önceliklendirilmiş bir yol haritası oluşturun.
  • Düzenleyici değişiklikleri takip edin. Mevzuat güncelleme takibini bir kişinin değil, bir sürecin sorumluluğu haline getirin.
  • Tatbikatları denetim olarak değil, öğrenme fırsatı olarak görün. Bir felaket kurtarma tatbikatında sorun çıkması, sistemin başarısız olduğunu değil; bunu gerçek bir kriz anından önce keşfettiğinizi gösterir.
  • Üst yönetimi bilgilendirin, teknik boğmayın. IT’nin değerini hata sayısı ile değil, önlenen riskler ve sağlanan süreklilik üzerinden anlatın.

Son Söz

Bir finansal kuruluşta IT yönetmek, hem mühendislik hem yönetim hem de uyum disiplinlerini aynı anda yürütmek demektir. Sabah denetçinin sorusunu yanıtlarken öğleden sonra depolama kapasitesi alertiyle ilgilenebilir, akşam bir tedarikçi anlaşmazlığını çözüyor olabilirsiniz.

Bu kaotik görünen tablonun içinde düzeni sağlayanın ne olduğunu sahada öğrendim: belgelenmiş süreçler, net sorumluluklar ve sistemin sizi uyarmasına izin veren bir izleme altyapısı.

Teknolojiyi doğru seçmek önemlidir. Ama neyi neden kurduğunuzu bilerek ilerlemek, çok daha önemlidir.

Bu makale, birden fazla finansal kuruluşun IT altyapısını kurma ve yönetme deneyiminden ve ilgili uluslararası kaynaklardan yararlanılarak hazırlanmıştır.

Kaynakça

Düzenleyici Uyum & Çerçeveler

Ion247 — How to Ensure Your Financial Services IT Infrastructure Meets Regulatory Compliance
https://www.ion247.com/insights/how-to-ensure-your-financial-services-it-infrastructure-meets-regulatory-compliance/

Arctic Wolf — A Simplified Regulatory Checklist for Financial Institutions
https://arcticwolf.com/blog/a-simplified-regulatory-checklist-for-financial-institutions/

InnReg — Fintech Compliance Checklist: Essential Guide
https://www.innreg.com/blog/fintech-compliance-checklist-essential-guide/

Results Technology — The Ultimate Banking Regulatory Compliance Checklist
https://www.resultstechnology.com/blog/the-ultimate-banking-compliance-checklist/

SOC / NOC & Felaket Kurtarma

Check Point — What is a Network Operations Center (NOC)?
https://www.checkpoint.com/cyber-hub/network-security/what-is-a-network-operations-center-noc/

Splunk — NOCs vs. SOCs: Network & Security Operations Centers Compared
https://www.splunk.com/en_us/blog/learn/noc-vs-soc.html

Fortinet — What is a Security Operations Center (SOC)?
https://www.fortinet.com/resources/cyberglossary/what-is-soc

Cutover — The Technology Operations Guide to IT Disaster Recovery
https://cutover.com/content-hub/technology-operations-guide-it-disaster-recovery

ITU Online — Building a Robust Disaster Recovery Plan for Critical IT Infrastructure
https://www.ituonline.com/blogs/building-a-robust-disaster-recovery-plan-for-critical-it-infrastructure/

Siber Güvenlik Olgunluğu & IAM / PAM / SIEM

Cyber Advisors — Measuring & Improving Cyber Maturity in Financial Services
https://blog.cyberadvisors.com/measuring-and-improving-cyber-maturity-in-financial-services-a-roadmap-for-2025

Security Architect — How to Assess Security Maturity and Roadmap Improvements
https://security-architect.com/how-to-assess-security-maturity-and-roadmap-improvements/

SearchInform — How SIEM Enhances Identity and Access Management
https://searchinform.com/articles/cybersecurity/measures/siem/use-cases/iam/

Wikipedia — Privileged Access Management
https://en.wikipedia.org/wiki/Privileged_access_management

Getsahl — SAMA Cybersecurity Framework Checklist
https://getsahl.io/sama-cybersecurity-framework-checklist-a-complete-guide-for-financial-institutions-in-2025/

BDDK & Türk Mevzuatı

BDDK — Bankaların Bilgi Sistemleri ve Elektronik Bankacılık Hizmetleri Hakkında Yönetmelik (15.03.2020 tarihli, 31069 sayılı Resmî Gazete)
https://www.bddk.org.tr/Mevzuat/Liste/50

BDDK — Bilgi Sistemleri ve İş Süreçleri Bağımsız Denetimi Hakkında Yönetmelik
https://www.bddk.org.tr/Duyuru/EkGetir/850?ekId=778

ProCompliance — Bankaların Bilgi Sistemleri ve Elektronik Bankacılık Hizmetleri Hakkında Yönetmeliği Yayımlandı
https://www.procompliance.net/bankalarin-bilgi-sistemleri-ve-elektronik-bankacilik-hizmetleri-hakkinda-yonetmeligi-yayimlandi/

Hukuk ve Bilişim Dergisi — Bankaların Bilgi Sistemleri ve Elektronik Bankacılık Hizmetlerinde Bilgi Güvenliği Yaklaşımı
https://www.hukukvebilisimdergisi.com/bankalarin-bilgi-sistemleri-ve-elektronik-bankacilik-hizmetlerinde-bilgi-guvenligi-yaklasimi/