BT Hizmet Sağlayıcısı Değişikliği: 12 Güvenlik Kontrolü

Bir işletme, kullandığı BT hizmet sağlayıcısından memnun kalmadığında genellikle üç konuyu değerlendirir: destek kalitesi, çözüm süresi ve maliyet.

Yeni bir firmayla anlaşılır, geçiş tarihi belirlenir ve sistemlerin devredilmesi planlanır. Fakat çoğu zaman çok daha önemli bir soru gözden kaçar:

Eski hizmet sağlayıcısının şirket sistemlerine erişimi gerçekten sona erdi mi?

Güvenlik duvarının yönetici parolası, Microsoft 365 hesabının global yönetici yetkisi, sunucu yedekleri, alan adı yönetimi veya VPN erişimi hâlâ önceki firmada bulunuyor olabilir.

Yeni sağlayıcının sistemleri çalışır durumda teslim alması tek başına güvenli bir geçiş yapıldığını göstermez.

Asıl mesele, teknik altyapının kontrolünün, güvenlik sorumluluklarının ve erişim yetkilerinin eksiksiz biçimde devredilmesidir.

Bu yazıda, BT hizmet sağlayıcısı değişikliği sırasında işletmelerin dikkat etmesi gereken 12 kritik kontrolü, KVKK ve bilgi güvenliği açısından ele alıyoruz.

1. Önce sistemlerin gerçek envanterini çıkarın

Bir işletmenin hangi sistemlere sahip olduğu bilinmeden güvenli bir devir planı hazırlanamaz.

İlk yapılması gereken işlem, yönetilen tüm BT varlıklarının ve hizmetlerinin kayıt altına alınmasıdır.

Bu envanterin yalnızca bilgisayar ve sunucu listesinden oluşmaması gerekir.

Örneğin şu bilgiler bulunmalıdır:

Fiziksel ve sanal sunucular, işletim sistemleri ve görevleri
Firewall, switch, kablosuz ağ cihazları ve VPN bağlantıları
Microsoft 365, Google Workspace ve diğer bulut servisleri
Alan adları, DNS yönetimi, SSL sertifikaları ve web barındırma hizmetleri
NAS, yedekleme yazılımları ve harici depolama alanları
Kullanıcı hesapları, yönetici rolleri ve servis hesapları
Lisanslar, abonelikler ve yenileme tarihleri
Üçüncü taraf entegrasyonlar ve otomasyonlar

Buradaki kritik soru şudur:

Şirketin BT altyapısının kontrolü gerçekten şirkette mi, yoksa hizmet sağlayıcısının kişisel veya kurumsal hesaplarında mı?

Örneğin şirketin alan adı eski BT firmasının hesabında kayıtlıysa, teknik destek ilişkisi sona erse bile kritik bir bağımlılık devam eder.

Envanter çalışması bu tür bağımlılıkları görünür hâle getirir.

2. Ayrıcalıklı yönetici hesaplarını kontrol edin

BT hizmet sağlayıcıları görevlerini yerine getirebilmek için çoğunlukla yüksek yetkili hesaplara ihtiyaç duyar.

Ancak bu hesapların geçiş sonrasında kontrolsüz şekilde aktif kalması ciddi risk oluşturabilir.

Özellikle aşağıdaki yetkiler gözden geçirilmelidir:

Active Directory Domain Admin
Microsoft 365 Global Administrator
Firewall yönetici hesapları
VMware, Hyper-V veya Proxmox yönetim hesapları
NAS ve yedekleme yönetimi
DNS ve alan adı kayıt kuruluşu hesapları
Bulut platformlarının yönetici ve servis hesapları

Yeni sağlayıcıya geçişte yalnızca parolaların değiştirilmesi yeterli olmayabilir.

Eski kullanıcı hesapları, API anahtarları, erişim belirteçleri, aktif oturumlar ve üçüncü taraf yetkilendirmeleri de kontrol edilmelidir.

Önemli ayrım: Her yönetici hesabı silinmemelidir. Servislerin çalışması için kullanılan hesaplar öncelikle tespit edilmeli, sahipliği belirlenmeli ve gerekli kimlik bilgileri kontrollü biçimde yenilenmelidir.

Aksi hâlde güvenlik amacıyla yapılan bir işlem kritik bir uygulamanın durmasına neden olabilir.

3. VPN ve uzaktan erişim yetkilerini sonlandırın

Eski hizmet sağlayıcısının uzak erişim yetkileri, geçiş sürecindeki en hassas konulardan biridir.

Çünkü şirket ağına fiziksel olarak gelmeden erişim sağlayan bu bağlantılar, unutulduklarında uzun süre fark edilmeyebilir.

Kontrol edilmesi gereken başlıca alanlar şunlardır:

SSL VPN ve IPsec VPN kullanıcıları
Site-to-site VPN tünelleri
RDP ve SSH erişimleri
Uzak destek yazılımları
Firewall üzerinde tanımlı özel erişim kuralları
Kalıcı uzaktan yönetim ajanları
Zero Trust veya üçüncü taraf uzaktan erişim platformları

Burada yalnızca aktif kullanıcı listesine bakmak yeterli değildir.

Bazı bağlantılar ortak hesap, sertifika veya cihaz bazlı kimlik doğrulama üzerinden çalışabilir.

Geçiş planında her erişimin sahibi, amacı, sonlandırılma tarihi ve doğrulama sonucu kayıt altına alınmalıdır.

Yeni sağlayıcının erişimi test edilmeden eski bağlantıların kontrolsüz biçimde kaldırılması hizmet kesintisine neden olabilir. Bu nedenle kapatma işlemleri planlı ve doğrulanabilir olmalıdır.

4. KVKK kapsamında veri işleme ilişkisini yeniden değerlendirin

BT hizmet sağlayıcısı değişikliği yalnızca teknik bir operasyon değildir.

Hizmet sağlayıcısının çalışan e-postalarına, müşteri kayıtlarına, personel dosyalarına, finansal bilgilere veya başka kişisel verilere erişebilmesi, kişisel veri güvenliği açısından da değerlendirme gerektirir.

6698 sayılı Kişisel Verilerin Korunması Kanunu'nun 12. maddesi, veri sorumlusuna kişisel verilerin güvenliğini sağlamak için gerekli teknik ve idari tedbirleri alma yükümlülüğü getirir.

Ayrıca veri sorumlusu adına veri işleyen bir hizmet sağlayıcısı söz konusuysa, veri güvenliği yükümlülükleri kapsamında tarafların sorumlulukları önem kazanır.

Bu nedenle geçiş sırasında şu sorular yanıtlanmalıdır:

Eski sağlayıcı hangi kişisel verilere erişebiliyordu?
Verilerin kopyaları veya yedekleri sağlayıcının sistemlerinde bulunuyor mu?
Hizmet ilişkisinin sona ermesiyle hangi verilerin iade edilmesi veya silinmesi gerekiyor?
Yeni sağlayıcının hangi verilere erişmesi gerçekten gerekli?
Gizlilik, alt yüklenici kullanımı ve güvenlik yükümlülükleri sözleşmelerde yeterince tanımlı mı?
Veri aktarımı söz konusuysa aktarımın yasal dayanağı ve koşulları değerlendirildi mi?

Her BT hizmet sağlayıcısı her durumda otomatik olarak aynı hukuki sıfata sahip değildir. Veri sorumlusu ve veri işleyen rolleri, yapılan işlemlerin niteliğine göre değerlendirilmelidir.

KVKK uyumu yalnızca gizlilik sözleşmesi imzalamak değildir. Erişim yetkilerinin sınırlandırılması, veri işleme faaliyetlerinin kontrolü ve alınan önlemlerin uygulanması da sürecin parçasıdır.

5. Yedeklerin sahipliğini ve geri dönüş kabiliyetini doğrulayın

Geçiş sırasında sık karşılaşılan sorunlardan biri, şirketin yedeklerinin nerede tutulduğunun veya nasıl geri yükleneceğinin tam olarak bilinmemesidir.

Eski hizmet sağlayıcısı, yedekleme sistemini kendi hesabı üzerinden yönetmiş olabilir.

Böyle bir durumda işletme yedekleme hizmeti aldığını düşünse de yedeklere bağımsız erişim sağlayamayabilir.

Kontrol listesi:

Yedekleme hedeflerinin sahibi kim?
Bulut yedekleme hesabına kimler erişebiliyor?
Şifreleme anahtarları kimde?
Yedekleme zamanlamaları ve saklama politikaları neler?
En son başarılı geri yükleme testi ne zaman yapıldı?
Yedekler üretim ortamından mantıksal veya fiziksel olarak ayrılmış mı?
Geri yükleme için eski sağlayıcının hesabına ihtiyaç var mı?

Yedek bulunması, geri dönüşün garanti olduğu anlamına gelmez.

Yeni sağlayıcı, kritik sistemlerden seçilen örnekler için kontrollü geri yükleme testleri gerçekleştirmeli ve sonucu belgelemelidir.

Amaç yalnızca veri kaybını engellemek değil, olası bir olay sonrasında iş süreçlerinin ne kadar sürede yeniden çalışabileceğini de anlamaktır.

6. Alan adı, DNS ve bulut aboneliklerinin sahipliğini netleştirin

Şirketin internet alan adı veya kurumsal bulut aboneliği, farkında olunmadan önceki hizmet sağlayıcısının hesabına bağlı olabilir.

Bu durum zaman içinde ciddi operasyonel sorunlara dönüşebilir.

Örneğin alan adı yenileme bildirimi yalnızca eski BT firmasına gidiyorsa, sözleşmenin sona ermesinden aylar sonra web sitesi veya e-posta hizmetleri risk altına girebilir.

Bu nedenle özellikle şu kontroller yapılmalıdır:

Domain kayıt sahibi ve yetkili iletişim bilgileri
DNS yönetim paneli
Microsoft 365 tenant sahipliği
Google Workspace süper yönetici hesapları
SSL sertifikası ve yenileme süreçleri
Hosting, bulut ve yedekleme abonelikleri
Fatura ve lisans sahipliği

Hedef, kritik servislerin mümkün olduğunca şirket adına açılmış ve şirketin kontrol ettiği hesaplar üzerinden yönetilmesidir.

7. Log kayıtlarını ve güvenlik geçmişini koruyun

Bir hizmet sağlayıcısı değiştiğinde yalnızca sistemlerin mevcut durumu değil, güvenlik geçmişi de önemlidir.

Firewall logları, kullanıcı oturumları, VPN bağlantıları, sunucu olay kayıtları ve kritik değişiklik geçmişi yeni ekibin altyapıyı anlamasını kolaylaştırabilir.

Ayrıca bazı kayıtlar mevzuat, sözleşme veya iç politika gereğince belirli sürelerle saklanmak zorunda olabilir.

Bu noktada 5651 sayılı Kanun ve ilgili ikincil düzenlemelerin hangi faaliyet ve yükümlülüklere uygulandığı ayrıca değerlendirilmelidir. Her işletmenin tüm logları için tek ve aynı saklama süresi bulunduğu varsayılmamalıdır.

Kontrol edilmesi gerekenler:

Kayıtların nerede saklandığı
Kayıtlara kimin erişebildiği
Bütünlük doğrulama mekanizmaları
Zaman senkronizasyonu
Saklama ve silme politikaları
Geçmiş güvenlik olaylarına ilişkin açık aksiyonlar

Eski loglama sisteminin kapatılması, yeni sistemin doğru çalıştığı doğrulanmadan yapılmamalıdır.

8. Güvenlik duvarı ve ağ yapılandırmasını kayıt altına alın

Yeni BT sağlayıcısı ağın yalnızca çalıştığını değil, nasıl yapılandırıldığını da anlamalıdır.

Özellikle firewall üzerinde yıllar içinde eklenmiş geçici kurallar, kullanılmayan port yönlendirmeleri veya unutulmuş VPN tanımları bulunabilir.

Devir sırasında aşağıdaki unsurlar gözden geçirilmelidir:

Firewall konfigürasyon yedekleri
NAT ve port yönlendirme kuralları
VLAN ve IP adres planları
WAN bağlantıları
İnternet çıkış politikaları
Ağ cihazlarının yazılım sürümleri
Yönetim arayüzlerinin erişim sınırları
Güncel ağ topolojisi

Bu çalışma yalnızca dokümantasyon üretmek için yapılmaz.

Aynı zamanda mevcut güvenlik açıklarını ve gereksiz erişim yollarını belirlemek için önemli bir fırsattır.

9. Üçüncü taraf entegrasyonları ve servis hesaplarını unutmayın

Bazı erişimler doğrudan kullanıcı hesaplarına bağlı değildir.

Muhasebe yazılımı, CRM, ERP, yedekleme, web sitesi veya otomasyon sistemleri, servis hesapları ve API anahtarları üzerinden birbirleriyle haberleşebilir.

Örneğin eski BT sağlayıcısı tarafından oluşturulmuş bir entegrasyon anahtarı hâlâ aktif olabilir.

Bu nedenle:

API anahtarları
OAuth izinleri
Servis hesapları
Webhook bağlantıları
Otomatik görevler
Dış uygulama yetkilendirmeleri

kontrol edilmelidir.

Bu erişimleri plansız biçimde kapatmak entegrasyonları bozabilir. Önce bağımlılıklar belirlenmeli, ardından gerekli anahtarlar yenilenmeli ve kullanılmayan yetkiler kaldırılmalıdır.

10. Yetki değişikliklerini kayıt altına alın

Güvenli bir geçişin en önemli unsurlarından biri, yapılan değişikliklerin kanıtlanabilir olmasıdır.

Örneğin bir VPN hesabının kapatıldığı yalnızca sözlü olarak bildirilmemeli; işlem tarihi, sorumlu kişi ve doğrulama sonucu kaydedilmelidir.

Basit bir devir takip tablosu bile büyük fark yaratır:

| Kontrol | Sorumlu | Doğrulama kanıtı | |---|---|---| | VPN yetkilerinin kaldırılması | Sistem yöneticisi | Hesap ve bağlantı denetimi | | Global Admin kontrolü | Bulut yöneticisi | Rol atama raporu | | Firewall yönetici erişimleri | Ağ yöneticisi | Yönetici listesi | | Yedekleme erişimi | Yedekleme sorumlusu | Geri yükleme test kaydı | | DNS sahipliği | Yetkili kişi | Kayıt kuruluşu hesap kontrolü | | API anahtarları | Uygulama sorumlusu | Anahtar değişim kaydı |

Bu kayıtlar hem operasyonel takibi kolaylaştırır hem de sonraki güvenlik denetimleri için somut kanıt oluşturur.

11. Yeni hizmet sağlayıcısını güvenlik açısından değerlendirin

Eski sağlayıcıdan güvenli şekilde ayrılmak kadar, yeni sağlayıcıyla doğru başlangıç yapmak da önemlidir.

Burada yalnızca teknik uzmanlık veya fiyat kriteri yeterli değildir.

Yeni hizmet sağlayıcısına şu sorular yöneltilebilir:

Yönetici erişimlerini nasıl yönetiyorsunuz?
MFA hangi sistemlerde zorunlu?
Müşterilerin erişim yetkilerini birbirinden nasıl ayırıyorsunuz?
Yapılan değişiklikleri nasıl kayıt altına alıyorsunuz?
Güvenlik olayı yaşandığında bildirim ve müdahale süreciniz nedir?
Sözleşme sona erdiğinde hesap, parola ve veri devir süreciniz nasıl işliyor?
Alt yüklenici kullanıyorsanız erişimlerini nasıl kontrol ediyorsunuz?
Yedekleme ve geri yükleme testleri nasıl yürütülüyor?

Bu yaklaşım, NIST'in siber tedarik zinciri risk yönetimi çerçevesiyle de uyumludur.

NIST SP 800-161 Rev. 1, kuruluşların tedarikçilerinden kaynaklanan siber riskleri belirlemesini, değerlendirmesini ve yönetmesini ele alır. 2026 yılında yayımlanan NIST SP 1326 rehberi de tedarikçi seçimindeki özenli inceleme sürecine odaklanmaktadır.

Özetle yeni BT hizmet sağlayıcısı seçimi yalnızca destek sözleşmesi değil, aynı zamanda bir tedarikçi güvenliği kararıdır.

12. Devir teslimi tek bir günde tamamlanmış saymayın

Teknik erişimlerin devredilmesi, geçiş sürecinin sona erdiği anlamına gelmez.

Yeni sağlayıcının mevcut altyapıyı doğrulaması, hatalı yapılandırmaları belirlemesi ve operasyonel süreçlerin sorunsuz çalıştığından emin olması gerekir.

İşletmenin büyüklüğüne ve sistemlerin karmaşıklığına göre değişmekle birlikte, aşağıdaki örnek geçiş planı kullanılabilir.

Geçiş öncesi

Sistem ve erişim envanteri hazırlanır.
Kritik hesapların sahipliği doğrulanır.
Yedekleme durumu kontrol edilir.
Mevcut sağlayıcıyla devir kapsamı netleştirilir.
Kesinti riski taşıyan işlemler için geri dönüş planı oluşturulur.

Geçiş günü

Yeni sağlayıcının yetkileri kontrollü şekilde tanımlanır.
Eski sağlayıcının erişimleri belirlenen sırayla kaldırılır.
Kritik servislerin çalışması test edilir.
Hesap ve erişim değişiklikleri belgelenir.
Acil durum iletişim kişileri doğrulanır.

Geçiş sonrası ilk 30 gün

Kullanılmayan erişimler yeniden taranır.
Loglar ve güvenlik uyarıları gözden geçirilir.
Yedeklerden geri dönüş testleri gerçekleştirilir.
Kritik sistemlerdeki açık aksiyonlar tamamlanır.
Envanter, yetki matrisi ve işletim dokümantasyonu güncellenir.

Bu 30 günlük süre yasal bir zorunluluk değil, örnek bir operasyonel doğrulama takvimidir.

BT hizmet sağlayıcısı değişikliğinde ISO 27001 yaklaşımı neden önemlidir?

ISO/IEC 27001 yaklaşımının temelinde, bilgi güvenliği risklerinin sistematik biçimde yönetilmesi bulunur.

Hizmet sağlayıcısı değişikliği de risk değerlendirmesine konu olması gereken önemli operasyonel değişikliklerden biridir.

Özellikle tedarikçi ilişkileri, erişim kontrolü, varlık yönetimi, olay yönetimi ve değişiklik yönetimi gibi süreçler birlikte ele alınmalıdır.

ISO 27001 sertifikasına sahip olmak her geçişin otomatik olarak güvenli olduğu anlamına gelmediği gibi, sertifikası bulunmayan her işletmenin güvensiz olduğu da söylenemez.

Önemli olan, kontrollerin gerçekten uygulanması ve sürdürülebilir olmasıdır.

Sonuç: BT firmasını değiştirmek kolay, kontrolü güvenli devralmak önemlidir

BT hizmet sağlayıcısı değişikliği çoğu işletmede teknik destek ilişkisinin yenilenmesi olarak görülür.

Oysa bu süreç, şirketin bilgi varlıklarının kimler tarafından yönetildiğinin ve hangi erişimlerin devam ettiğinin yeniden değerlendirilmesi anlamına gelir.

Eksik bir devir; unutulmuş yönetici hesaplarına, kontrolsüz uzaktan erişimlere, erişilemeyen yedeklere veya belirsiz veri işleme sorumluluklarına yol açabilir.

Güvenli bir geçiş için üç temel ilke öne çıkar:

Envanter: Hangi sistemlerin, verilerin ve erişimlerin bulunduğunu bilmek.

Kontrol: Yönetici yetkilerini, veri erişimlerini ve teknik sorumlulukları doğru kişilere devretmek.

Doğrulama: Yapılan işlemlerin gerçekten tamamlandığını test edip belgelemek.

BT hizmet sağlayıcısı değişikliğinde başarılı sonuç, yalnızca bilgisayarların ve internetin çalışmaya devam etmesi değildir.

Başarılı sonuç; şirketin kendi altyapısının, verilerinin ve yönetim yetkilerinin kontrolünü kaybetmeden geçişi tamamlamasıdır.

RelGen Teknoloji ile güvenli BT altyapısı ve uyumluluk

RelGen Teknoloji olarak işletmelerin mevcut BT altyapılarının değerlendirilmesi, sistem ve ağ yönetimi, erişim kontrolleri, yedekleme süreçleri ve bilgi güvenliği uygulamaları konusunda teknik destek ve danışmanlık sunuyoruz.

Mevcut BT sağlayıcınızla çalışma modelinizi gözden geçiriyorsanız veya altyapınızın güvenlik durumunu değerlendirmek istiyorsanız, ihtiyaçlarınıza uygun teknik yaklaşımı birlikte belirleyebiliriz.

İlgili hizmetlerimiz:

Kaynaklar ve ileri okuma

Kişisel Verileri Koruma Kurumu: Veri Güvenliğine İlişkin Yükümlülükler ve Kişisel Veri Güvenliği Rehberi (Teknik ve İdari Tedbirler).

https://www.kvkk.gov.tr/Icerik/2040/Veri-Guvenligine-Iliskin-Yukumlulukler

NIST SP 800-161 Rev. 1, Update 1: Cybersecurity Supply Chain Risk Management Practices for Systems and Organizations.

https://csrc.nist.gov/pubs/sp/800/161/r1/upd1/final

NIST SP 1326 (2026): Cybersecurity Supply Chain Risk Management Due Diligence Assessment Quick-Start Guide.

https://doi.org/10.6028/NIST.SP.1326

Not: Bu yazı genel teknik ve idari güvenlik bilgilendirmesi amacıyla hazırlanmıştır. KVKK kapsamındaki yükümlülükler, sözleşme ilişkileri ve sektörel düzenlemeler somut olay özelinde ayrıca değerlendirilmelidir.

BT Hizmet Sağlayıcısı Değişirken Siber Güvenlik ve KVKK: 12 Kritik Kontrol