Çok Lokasyonlu BT Operasyonunda Yerel Ekip ve Merkezi Uzmanlık Dengesi

Merkez ofiste çalışan bir uzman, uzak tesisteki sunucunun ekranını görebilir; fakat kabloyu, enerjiyi veya fiziksel alarmı yerinde kontrol edemez. Saha personeli ise cihazın yanında olmasına rağmen merkezi kimlik, yedekleme veya ağ standardında değişiklik yapacak bağlama sahip olmayabilir. Etkili operasyon bu iki yeteneği birbirinin alternatifi değil, aynı hizmet zincirinin parçaları olarak görür.

Temmuz 2026’da maden, tesis ve genel müdürlük benzeri farklı lokasyonlara sahip anonim bir kurum için görev dağılımını yeniden ele aldık. Amaç tüm yetkiyi merkezde toplamak veya her sahada tam uzman ekip kurmak değildi. Tekrarlanabilir yerel müdahale, merkezi standart, görünür bağımlılık ve gerektiğinde hızlı uzman eskalasyonu sağlayan dengeli bir model oluşturmaktı.

Sorunun ortaya çıkışı

Sunucu kurulumu merkez ekipteydi, ancak kurulumdan önce gerekli yerel veri hazırlığı ve fiziksel kontrol görevi açıkça atanmamıştı. Merkez işi bekliyor, saha ise talebin tamamen merkez tarafından yürütüldüğünü düşünüyordu. Benzer biçimde ağ kesintilerinde saha cihazların yanında olmasına rağmen hangi kontrolleri güvenle yapacağını bilmiyor, merkez de fiziksel durum bilgisi olmadan uzaktan teşhis yürütüyordu.

Ticket sistemi tek bir sorumlu gösteriyor, ardışık görevleri ve lokasyon bağımlılığını yansıtmıyordu. Yerel personel doğrudan farklı merkezi uzmanlara ulaşıyor, kayıt sonradan açılıyordu. Çözümler kişisel mesajlarda kaldığı için aynı arıza başka sahada yeniden araştırılıyordu. İzin, seyahat, yedek parça ve tedarikçi erişimi gibi saha gerçekleri hizmet sürelerinde hesaba katılmıyordu.

İlk belirtiler ve yanlış varsayımlar

İlk yanlış varsayım uzaktan yönetim aracı varsa yerel BT ihtiyacının ortadan kalkacağıydı. Enerji, çevresel koşul, fiber, konsol ve donanım değişimi fiziksel müdahale gerektirir. Karşıt varsayım ise her lokasyonun kendi yöntemini seçmesinin daha hızlı olduğuydu. Kısa vadeli hız; farklı yapılandırma, eksik kayıt, yedekleme boşluğu ve uzman bulunamadığında uzun kesinti olarak geri dönebiliyordu.

Bir diğer belirti görevlerin unvana göre dağıtılmasıydı. “BT personeli yapar” ifadesi yeterli değildi; bazı işler iki kişiyle fiziksel güvenlik, bazıları değişiklik onayı, bazıları üretici sertifikası gerektiriyordu. Yerel ekip merkezi onayı bürokrasi, merkez ekip saha inisiyatifini kontrol kaybı olarak görmeye başladığında sorun organizasyonel hale geldi. Ortak hizmet hedefi yeniden kurulmalıydı.

Teknik analiz

Önce hizmet ve görev envanteri çıkarıldı: kullanıcı desteği, fiziksel kontrol, ağ, sunucu, kimlik, yedekleme, uygulama, güvenlik olayı ve tedarikçi koordinasyonu. Her görev için yapılma sıklığı, gerekli yetkinlik, uzaktan yapılabilirlik, fiziksel risk, ayrıcalık seviyesi ve müdahale süresi değerlendirildi. RACI yalnızca bölüm adlarını değil, görev başlangıcı ve teslim koşullarını gösterecek ayrıntıda hazırlandı.

Yerel ekip için güvenli ilk kontrol runbook’ları oluşturuldu. Runbook, belirtiyi doğrulama, fotoğraf veya log toplama, enerji ve bağlantı kontrolü, değişiklik yapmadan eskalasyon gibi sınırları içerdi. Merkezi ekip platform sağlığı, yapılandırma standardı, ayrıcalıklı değişiklik, yedekleme ve uzman teşhisten sorumlu oldu. Ticket alt görevleri bağımlı şekilde sıralandı; bir görev tamamlanmadan sonraki ekip yanlışlıkla başlamadı.

Uygulanan çözüm veya önerilen mimari

Katmanlı destek modeli kuruldu. Yerel ekip fiziksel doğrulama, standart kullanıcı işlemleri, onaylı parça değişimi ve kanıt toplama görevlerini yürüttü. Merkezi servis masası kaydı, önceliği ve iletişimi yönetti. Platform ekipleri ağ, sunucu, kimlik ve uygulama uzmanlığını sağladı; kritik olaylarda tek bir olay yöneticisi farklı ekipleri koordine etti. Tedarikçi çağrısı kurum içi sahipliği devretmedi.

Standart yapılandırmalar, envanter, ağ ve sistem dokümanları merkezi depoda rol bazlı tutuldu. Her saha için bağlantı tamamen kesildiğinde kullanılacak iletişim ve yerel çalışma prosedürü hazırlandı. Yedek parça sınıfları kritiklik ve tedarik süresine göre sahada veya merkezde konumlandırıldı. Eğitimler genel sunum yerine gerçek runbook uygulamalarıyla yapıldı; saha ekibinin geri bildirimi tasarım kararlarına taşındı.

Alternatifler ve karar gerekçesi

Tam merkezi model standardizasyon ve uzman yoğunluğu sağlar; uzak saha erişimi, fiziksel müdahale ve bağlantı kesintisinde yavaş kalabilir. Tam yerel model çeviklik ve saha bilgisi sunar; uzmanlık tekrarına, farklı standartlara ve sınırlı kariyer yedeğine yol açabilir. Hub-and-spoke yaklaşımında merkez platform ve yönetişimi, yerel ekip kontrollü uygulamayı sahiplenir. Kurumun coğrafyası için bu denge daha sürdürülebilir bulundu.

Dış kaynak saha desteği esnek kapasite ve geniş kapsama sağlayabilir; kurumsal bağlam, erişim güvenliği ve hizmet kalitesi sözleşmeyle dikkatle yönetilmelidir. Her lokasyonda kadrolu uzman bulundurmak kritik büyük sahalarda gerekebilir, küçük noktalarda verimsiz olabilir. Karar kullanıcı sayısından tek başına çıkarılmadı; iş kritiklik, ulaşım süresi, fiziksel risk, bağlantı güvenilirliği ve iş yükü birlikte değerlendirildi.

Güvenlik ve operasyonel riskler

Yerel müdahale için geniş yönetici hesabı vermek hızlı fakat risklidir. Rol bazlı, süreli ve kayıtlı erişim kullanılmalı; ortak hesaplardan kaçınılmalı, acil durum erişimi sonradan gözden geçirilmelidir. Runbook’lar gerçek parola, özel ağ ayrıntısı veya gereksiz güvenlik kuralı içermemelidir. Tedarikçi erişimi sponsor, amaç, süre, MFA ve oturum kaydıyla yönetilmeli; iş bitince kapatılmalıdır.

Tek bir merkezi uzmana bağımlılık izin veya kriz döneminde hizmeti durdurabilir. Yetkinlik matrisi, çapraz eğitim, nöbet ve güncel dokümantasyon bu riski azaltır. Yerel ekip güvenli çalışma sınırını aşmamalı; özellikle endüstriyel sahada BT müdahalesi fiziksel iş güvenliği prosedürlerine tabidir. KPI’lar yalnızca kapanış süresini değil tekrar açılma, eskalasyon kalitesi, doküman güncelliği ve kullanıcı etkisini ölçmelidir.

Çıkarılan Dersler

Kontrol Listesi

Bütçe döneminde güvenlik ihtiyaçları çoğu kez üretici adları, lisans adetleri ve yenileme tarihleriyle masaya gelir. Böyle bir tablo finans açısından somut görünür; ancak hangi iş riskini ne ölçüde azalttığı sorulduğunda cevap vermek zorlaşır. Bir kurumda endpoint yönetimi, SIEM, e-posta güvenliği, NDR, DAM ve BAS talepleri aynı döneme yığılmış, operasyon kapasitesi ise hiç hesaplanmamıştı.

28 Kasım 2025 ve 22 Temmuz 2026 tarihli değerlendirmelerde bütçeyi “hangi ürünü alalım?” sorusundan çıkarıp “hangi kontrolü hangi hizmet seviyesiyle işleteceğiz?” sorusuna taşıdık. Bu bakış teknoloji seçimini ortadan kaldırmaz; onu doğru sıraya koyar. Yönetim de lisans terminolojisi yerine risk, süreklilik ve sorumluluk üzerinden karar verebilir.

Sorunun ortaya çıkışı

Mevcut araçların bir kısmı düşük kullanımdayken yeni ürün talepleri artıyordu. Bazı kontroller iki farklı platformda örtüşüyor, bazı kritik alanlarda ise teknoloji bulunduğu halde alarmı izleyecek ekip veya süreç bulunmuyordu. Yenileme maliyetleri ayrı, proje kurulum bedelleri ayrı dosyalarda tutulduğu için toplam sahip olma maliyeti görülemiyordu. Sonuç, bütçe kesintisinde hangi kalemin hangi riski taşıdığının açıklanamamasıydı.

İhtiyaçları varlık ve tehdit senaryosuna bağlayınca tartışma değişti. “NDR alalım” ifadesi yerine ağdaki yönetilmeyen varlıklarda görünürlük ve anomali tespiti ihtiyacı; “DAM alalım” yerine kritik veri tabanı faaliyetlerinin izlenmesi ve sorumluluk ayrılığı yazıldı. Aynı kontrolün mevcut SIEM, veri tabanı denetimi veya süreç iyileştirmesiyle ne kadar karşılanabildiği değerlendirilmeden yeni alıma geçilmedi.

İlk belirtiler ve yanlış varsayımlar

En görünür belirti, önceki yıl alınan lisansların kapsam ve kullanım oranının bilinmemesiydi. İlk yanlış varsayım daha fazla ürünün doğrusal biçimde daha fazla güvenlik sağlayacağıydı. Oysa her yeni platform entegrasyon, veri saklama, alarm ayarı, eğitim, vardiya ve tedarikçi yönetimi yükü getirir. İşletme kapasitesi artmıyorsa güvenlik ekibi farklı konsollardaki gürültüyü yönetmeye başlar.

İkinci yanlış varsayım satın alma bedelini toplam maliyet kabul etmekti. Kurulum danışmanlığı, altyapı, veri aktarımı, API entegrasyonu, eğitim, sertifika, bakım, destek ve yenileme hesaba katılmadığında sonraki dönem sürprizleri oluşur. Bulut hizmetlerinde tüketim, günlük hacmi veya kullanıcı artışı; cihaz tabanlı çözümlerde kapasite ve yaşam döngüsü ayrıca modellenmelidir. Ticari fiyat paylaşmadan senaryo bazlı tahmin yapmak mümkündür.

Teknik analiz

Bütçe modelini varlık, risk, kontrol hedefi, mevcut kapsama, hedef kapsama ve başarı göstergesi alanlarıyla kurduk. Her talep önleme, tespit, müdahale veya kurtarma katmanlarından birine bağlandı. Kontrolün tek başına mı, mevcut platform genişlemesiyle mi, yönetilen hizmetle mi karşılanacağı incelendi. Aynı risk için üst üste lisanslanan özellikler ve hiç sahibi olmayan kontroller böyle görünür oldu.

CAPEX ve OPEX ayrımı muhasebe sınıflandırmasının ötesinde ele alındı. İlk yatırım düşük olsa bile veri hacmiyle büyüyen hizmetin üç yıllık maliyeti; cihaz yatırımında ise bakım, yenileme ve uzmanlık ihtiyacı hesaplandı. Ayrıca “yapmama maliyeti” uydurma tek bir parasal değerle değil, kesinti senaryosu, mevzuat etkisi, kurtarma süresi ve risk iştahı üzerinden yönetimin anlayacağı aralıklarla sunuldu.

Uygulanan çözüm veya önerilen mimari

Üç yıllık yol haritasında önce temel hijyen ve görünürlük, ardından gelişmiş tespit ve sürekli doğrulama kabiliyetleri sıralandı. Kimlik, varlık envanteri, uç nokta, e-posta, log, yedekleme ve olay müdahalesi için asgari kontrol düzeyi tanımlandı. NDR, DAM veya BAS gibi ileri kabiliyetler, veri kaynağı ve müdahale süreci hazır olduğunda devreye girecek şekilde bağımlılıklara bağlandı.

Her yatırım için iş sahibi, teknik sahibi, işletme modeli ve hizmet göstergesi yazıldı. İç ekip, yönetilen hizmet ve hibrit seçenekler vardiya ihtiyacı ile uzmanlık sürekliliğine göre karşılaştırıldı. Bütçe kurulu önüne marka sıralaması değil, kontrol seçenekleri ve beklenen sonuç çıktı. Ürün seçimi daha sonra teknik gereksinim, entegrasyon, destek, veri yerleşimi ve çıkış planını içeren değerlendirmeyle yapıldı.

Alternatifler ve karar gerekçesi

En iyi ürünleri ayrı ayrı seçmek belirli alanlarda derinlik sağlar, fakat entegrasyon ve yetkinlik yükünü artırabilir. Tek üretici platformu ortak yönetim ve veri paylaşımını kolaylaştırabilir; buna karşılık işlevsel boşluk, bağımlılık ve pazarlık esnekliği riski taşır. Kararımız “tek platform” veya “best of breed” dogmasına dayanmadı; kritik kontrol kalitesi ile ekibin sürdürülebilir işletme kapasitesini birlikte tarttı.

Tamamen iç kaynakla işletme kurumsal bilgi birikimini güçlendirir ancak kesintisiz izleme ve uzman tutundurma maliyeti yaratır. Yönetilen hizmet hızlı kapasite sağlar fakat sorumluluğu ortadan kaldırmaz; kapsam, veri erişimi ve eskalasyon kalitesi dikkatle yönetilmelidir. Bazı temel kontrolleri içeride, yoğun uzmanlık veya vardiya gerektiren işleri ölçülebilir hizmet seviyesiyle dışarıda tutan hibrit yaklaşım daha gerçekçi bulundu.

Güvenlik ve operasyonel riskler

Bütçe dokümanı güvenlik açıklarını, planlanan yatırımları ve mevcut koruma boşluklarını ortaya çıkarabilir. Dağıtımı sınırlanmalı, yönetim sürümünde gereksiz teknik ayrıntılar çıkarılmalı ve tedarikçiler birbirlerinin ticari veya mimari bilgilerine erişmemelidir. Teklif değerlendirmelerinde gerçek günlük örnekleri, kullanıcı bilgileri ve ağ ayrıntıları yerine anonimleştirilmiş gereksinim ve güvenli test verileri kullanılmalıdır.

Operasyonel olarak en büyük risk rafta kalan üründür. Canlıya geçiş ölçütleri, eğitim, dokümantasyon, alarm sahipliği ve periyodik kontrol bütçenin parçası değilse yatırım yalnızca lisans envanterini büyütür. Ayrıca yenileme döneminde verinin dışarı alınması, entegrasyonların taşınması ve hizmet kesintisi gibi çıkış riskleri değerlendirilmelidir. Kontrol etkinliği yılda en az planlı aralıklarla gözden geçirilmelidir.

Çıkarılan Dersler

Kontrol Listesi

Personel tag’lerinden oluşan konum olayları merkezi uygulamada görünmeye başladığında teknik ekip sistemi çalışır kabul edebilir. Sözleşme ekine gelindiğinde ise “müşteri veri sorumlusudur, tedarikçi veri işleyendir” cümlesi tek başına yetersiz kalır. Uygulama üreticisi bulut telemetrisi alıyor, entegratör uzaktan destek veriyor ve başka bir sağlayıcı yedek tutuyorsa gerçek veri zinciri daha uzundur.

9 Temmuz 2026 tarihinde anonim bir endüstriyel IoT projesi için yaptığımız çalışmada hukuki unvanları varsayımla değil, fiili karar ve veri akışıyla eşleştirdik. Bu yazı hukuki görüş yerine geçmez; hukuk, bilgi güvenliği, operasyon ve tedarik ekiplerinin aynı soruları sormasını sağlayan pratik bir çerçevedir. Kesin yükümlülükler ilgili mevzuat ve sözleşme bağlamında uzmanlarla doğrulanmalıdır.

Sorunun ortaya çıkışı

Müşteri saha ihtiyacını tanımlıyor, üretici yazılımı sağlıyor, uygulayıcı cihazları kuruyor ve destek ekibi sisteme erişiyordu. Taslak DPA yalnızca iki taraf içerdiği için alt yüklenici, barındırma ve uzaktan destek rolleri görünmüyordu. Hangi tarafın hangi veri kategorisine eriştiği, veriyi ne kadar tuttuğu ve sözleşme bittiğinde nasıl sileceği açık değildi.

Personel kimliği ile tag eşleştirmesi işveren sisteminden geliyor, konum olayları IoT platformunda işleniyor ve raporlar başka kurumsal uygulamalara aktarılıyordu. Teknik mimari diyagramı cihaz bağlantısını gösterse de hukuki veri akışını göstermiyordu. Projenin canlıya geçiş tarihi yaklaşırken ihlal bildirimi, ilgili kişi talebi ve veri dışa aktarımı için kimin ne yapacağı cevaplanamıyordu.

İlk belirtiler ve yanlış varsayımlar

İlk yanlış varsayım yazılım üreticisinin otomatik olarak veri sorumlusu olduğuydu. Rol, ürün sahipliğinden çok kişisel veri işleme amaç ve vasıtaları üzerindeki fiili karara bağlıdır. Başka bir yanlış varsayım verinin cihaz seri numarasından oluştuğu için kişisel olmadığıydı. Tag bir çalışanla eşleştirildiğinde ve konum/zaman olayı üretildiğinde veri bağlamı kişiyi belirlenebilir kılabilir.

DPA imzalanınca tüm yükümlülüklerin tamamlandığı düşüncesi de sorun yarattı. Sözleşmedeki silme süresi uygulamada bir iş akışına bağlanmamış, yedeklerden silmenin teknik sınırları açıklanmamıştı. Alt işleyen değişikliğinde bildirim yöntemi yoktu. Destek hesapları ortak kullanılıyor ve erişim kayıtları kişi bazında tutulamıyordu. Kâğıt üzerindeki kontrol, operasyonel karşılık bulmadığında güvence sağlamaz.

Teknik analiz

Önce veri envanteri oluşturuldu: personel kimliği veya takma kimlik, tag eşleştirmesi, zaman ve bölge olayı, araç ilişkisi, cihaz telemetrisi, destek kaydı ve kullanıcı günlükleri. Her veri için kaynak, amaç, işleme işlemi, erişen taraf, barındırma yeri, aktarım ve saklama süresi yazıldı. Bu tablo, taraf rollerini sözleşme başlığından daha doğru biçimde görünür kıldı.

Karar matrisiyle işleme amacını, zorunlu alanları, saklama süresini ve raporlama kullanımını kimin belirlediği incelendi. Yalnızca talimatla hizmet veren taraf veri işleyen olarak, kendi bağımsız amacı için karar alan faaliyet ise ayrıca değerlendirildi. Alt işleyen listesi, veri merkezleri, uzaktan destek konumları ve yedekleme zinciri doğrulandı. Hukuk ekibi teknik akışı bu envanter üzerinden yorumladı.

Uygulanan çözüm veya önerilen mimari

Müşteri tarafında işleme amacı ve saha politikası için hesap verebilir veri sahibi belirlendi. Teknoloji sağlayıcı ile uygulayıcının hangi faaliyetlerde talimatla hareket ettiği sözleşme ekinde ayrıştırıldı; onaylı alt işleyenler listeye alındı. DPO veya ilgili gizlilik irtibatı, güvenlik olay kontağı ve operasyon sorumlusu isim yerine rol bazında tanımlandı; personel değişiminde süreç kesilmedi.

Teknik mimaride veri minimizasyonu uygulandı. Gereksiz kimlik alanları IoT platformuna taşınmadı, rol bazlı erişim ve kişi bazlı yönetici hesapları kullanıldı. Saklama süreleri uygulama, rapor, log ve yedek için ayrı yapılandırıldı. İlgili kişi talebi, düzeltme, dışa aktarma ve sözleşme sonu silme senaryoları masa başı tatbikatla test edildi; mümkün olmayan adımlar şeffaf biçimde kayda alındı.

Alternatifler ve karar gerekçesi

Tüm veriyi müşteri ortamında tutmak aktarım zincirini sadeleştirebilir; üretici desteği, güncelleme ve yedekleme yine erişim yaratabilir. SaaS modelinde işletim kolaylığı ve ölçek sağlanabilir, fakat alt işleyen, veri konumu ve çıkış planı daha ayrıntılı incelenmelidir. On-premises etiketi tek başına hukuki rolü veya güvenliği belirlemediği için fiili erişim üzerinden değerlendirme yaptık.

Personel adını sistemde tutmak raporlamayı kolaylaştırır; takma kimlik kullanmak gereksiz ifşayı azaltır fakat yetkili eşleştirme hizmeti gerektirir. Operasyon ekranında açık kimliğin gerçekten gerekli olduğu roller ayrıştırılarak çoğu görünümde minimizasyon tercih edildi. Saklama süresini “sözleşme boyunca” bırakmak kolaydı; iş güvenliği, operasyon, talep ve yasal ihtiyaçlara göre veri türü bazında süre belirlemek daha savunulabilir oldu.

Güvenlik ve operasyonel riskler

Ortak destek hesapları, kontrolsüz uzak erişim ve üretim verisinin test ortamına kopyalanması başlıca risklerdir. Tedarikçi erişimi talep, onay, süre, MFA ve kayıtla yönetilmeli; testte anonim veya sentetik veri kullanılmalıdır. Güvenlik yükümlülükleri “uygun önlem alınır” gibi belirsiz ifadelerle bırakılmamalı; erişim, şifreleme, yama, yedek ve olay işbirliği sorumlulukları doğrulanabilir olmalıdır.

Sınır ötesi veri aktarımı yalnızca ana uygulama barındırmasına bakılarak değerlendirilemez; telemetri, destek, log analizi ve yedekleme de zincire dahildir. Alt işleyen değişiklikleri izlenmezse onaylı mimari fark edilmeden değişebilir. Sözleşme sonundaki silme belgesi teknik doğrulamayla desteklenmeli, yedeklerdeki gecikmeli silme açıklanmalıdır. Mevzuat değişiklikleri için dönemsel hukuk ve envanter gözden geçirmesi planlanmalıdır.

Çıkarılan Dersler

Kontrol Listesi

Denetçi kullanıcı yetki listesini istediğinde uygulamadan alınan ilk çıktı binlerce satırdı. Teknik rol kodları, servis hesapları, kapalı kullanıcılar ve gereksiz kişisel alanlar aynı dosyadaydı. Dosyayı doğrudan paylaşmak hızlı görünüyordu; fakat ne iş yetkisini açıklıyor ne de raporun belirli tarihte tam olduğunu kanıtlıyordu. Üstelik denetim için gerekmeyen veriyi de açığa çıkarıyordu.

İyi bir yetki listesi yalnız dış denetçiye cevap vermek için değil, erişim sahibinin karar verebilmesi için hazırlanır. Kim, hangi uygulamada, hangi iş rolüne, hangi gerekçeyle ve hangi onayla erişiyor sorularını yanıtlamalıdır. Teknik ayrıntı gerektiğinde ek kanıt olarak korunabilir; ana rapor anlaşılır, izlenebilir ve veri minimizasyonuna uygun olmalıdır.

Sorunun ortaya çıkışı

ERP çıktısında aynı kişinin birden fazla teknik rolü, miras alınmış grup üyeliği ve geçmiş hesap kayıtları vardı. İK listesindeki ad ve birimlerle eşleşme yalnız isim üzerinden yapıldığı için benzer adlar ve değişen soyadlar hata yaratıyordu. Bazı roller menü kodu olarak görünüyordu; süreç sahibi bunların ödeme, satınalma veya stok açısından ne sağladığını anlayamıyordu. Kanıtın kapsam ve kesim tarihi de yazılı değildi.

İlk belirtiler ve yanlış varsayımlar

“Sistemden çıktıysa doğrudur” varsayımı ilk riskti. Rapor filtresi, saat dilimi veya pasif kullanıcı ayarı sonucu değiştirebilir. Excel’de yinelenen satırları silmek temizleme gibi görünse de çoklu şirket veya kapsam bilgisini kaybettirebilir. Denetçinin bütün teknik ve kişisel alanlara ihtiyacı olduğu da doğru değildir. İstenen kontrol amacı netleştirilmeden fazla veri paylaşmak güvenlik sağlamaz.

Teknik analiz

Önce rapor nüfusunu aktif insan kullanıcı, ayrıcalıklı hesap, servis hesabı ve pasif hesap olarak sınıflandırdık. Kararlı çalışan ve hesap anahtarlarıyla İK verisi eşleştirildi. Teknik roller iş rolü sözlüğüne bağlandı; rol kapsamı şirket, tesis veya maliyet merkezi düzeyinde korundu. Yetki çakışmaları için görev ayrılığı kuralları çalıştırıldı. Kaynak sorgu, filtre, kesim zamanı ve satır sayısı kanıt paketine eklendi.

Uygulanan çözüm veya önerilen mimari

Ana raporda maskelenmiş kullanıcı kimliği, birim, hesap durumu, iş rolü, kapsam, rol sahibi ve son gözden geçirme tarihi yer aldı. Ayrıcalıklı ve servis hesapları ayrı sekmede, farklı onay kriterleriyle gösterildi. Süreç sahipleri rolü sürdür, kaldır veya araştır seçenekleriyle değerlendirdi; sessizlik onay sayılmadı. İstisnalar gerekçe, telafi edici kontrol ve bitiş tarihiyle kaydedildi. Son dosya değişmez depoda sürümlendi.

Alternatifler ve karar gerekçesi

IGA aracı düzenli kampanya, otomatik kanıt ve rol analizi sağlar; küçük kapsamda lisans ve uygulama yükü yüksek olabilir. Kontrollü sorgu ve tablo yöntemi düşük hacimde geçerlidir, ancak tekrarlanabilirlik ve dört göz kontrolü gerekir. Ekran görüntüsü arayüz durumunu gösterebilir fakat tam nüfusu kanıtlamaz. Mevcut olgunlukta otomatik export, doğrulama ve sahip onayını birleştiren yaklaşımı seçtik.

Güvenlik ve operasyonel riskler

Yetki raporunun kendisi hassas güvenlik verisidir. Paylaşım rol bazlı ve süreli yapıldı; kişisel e-posta, telefon ve gereksiz kimlik alanları çıkarıldı. Dosya e-posta eki yerine kontrollü depoda sunuldu. Formül ve eşleştirme hatasına karşı bağımsız kontrol uygulandı. Denetim sonrası kopyaların saklama süresi belirlendi. Bulgu kapatmak için yetki aceleyle kaldırılmadan önce iş etkisi ve acil geri dönüş yolu doğrulandı.

Çıkarılan Dersler

Kontrol Listesi

ERP projesinde ürün sahibi rolü oluşturulduğunda ilk soru görev tanımından önce organizasyon kutusunun nereye çizileceği oldu. Finans altında olursa operasyonun, BT altında olursa iş ihtiyaçlarının geri planda kalacağından endişe ediliyordu. PMO ise takvim ve kapsam disiplinini korumak istiyordu. Aslında tek bir raporlama çizgisinin bütün bu beklentileri çözmesini istemek sorunun kendisiydi.

ERP kurumsal bir üründür: iş süreçlerini taşır, teknik bir platform üzerinde çalışır ve sürekli yatırım kararı gerektirir. Ürün sahibi backlog önceliği ve değer gerçekleşmesini yönetirken süreç sahiplerinin kararını devralmamalı, BT mimari ve güvenlik sorumluluğunu da üstlenmemelidir. Etkili model, idari bağlılık kadar karar haklarını ve forumları açıkça tanımlar.

Sorunun ortaya çıkışı

Proje ekibinde ERP product owner, iş analistleri, uygulama danışmanları, PMO, süreç sahipleri ve altyapı ekibi vardı. Talepler farklı yöneticilerden doğrudan geliyor, öncelik toplantıdaki en güçlü sese göre değişiyordu. Ürün sahibi bütçe üzerinde yetkisiz, sonuçtan sorumlu görünüyordu. Teknik borç işleri iş listesinde geri kalırken bazı birim istekleri ortak veri modelini bozacak özelleştirmelere dönüşüyordu.

İlk belirtiler ve yanlış varsayımlar

Rolü BT’ye bağlamanın onu teknik proje yöneticisi, finansa bağlamanın finans temsilcisi yapacağı düşünüldü. Oysa davranışı asıl belirleyen hedefler ve karar mekanizmasıdır. Product owner’ın bütün süreç kararlarını tek başına vereceği varsayımı da yanlıştı; mevzuat ve operasyon hesabını süreç sahipleri taşır. Her anlaşmazlığı steering committee’ye taşımak ise komiteyi günlük backlog toplantısına dönüştürür.

Teknik analiz

RACI yerine yalnız görev listesi değil, karar hakları matrisi hazırladık. Backlog sırası ürün sahibinde; süreç politikası ilgili iş sahibinde; mimari, entegrasyon ve güvenlik standartları BT’de; bütçe ve büyük kapsam değişikliği yönlendirme komitesindeydi. PMO plan, bağımlılık ve risk görünürlüğünü sağladı. Ürün sahibinin performans hedefleri teslim tarihi kadar kullanıcı benimsemesi, süreç sonucu, veri kalitesi ve teknik borç dengesini içerdi.

Uygulanan çözüm veya önerilen mimari

İdari raporlama dijital dönüşüm veya BT liderliğinde konumlandı; iş yönü için süreç sahiplerinden oluşan ürün konseyiyle güçlü matris kuruldu. Aylık steering committee bütçe, kapsam ve çözülemeyen riskleri ele aldı. Haftalık ürün forumu backlog ve bağımlılıkları yönetti. Ürün sahibi tek talep giriş noktası olmadı; talepler standart kanaldan toplandı ve değer, risk, zorunluluk ve efor ölçütleriyle sıralandı.

Alternatifler ve karar gerekçesi

ERP ağırlıklı olarak finans sistemi ise CFO altında ürün sahipliği işe yakın olabilir; yine de BT mimari kontrolü gerekir. Teknoloji yoğun entegrasyon ortamında CIO altında konumlandırma sürdürülebilirlik sağlar, ancak iş hedefleri ortak KPI ile korunmalıdır. Bağımsız dönüşüm ofisi çapraz süreçlerde tarafsızlık sunar fakat kalıcı işletme modeli belirsiz kalabilir. Kurumun yapısına göre çizgi değişebilir; değişmemesi gereken karar haklarının açıklığıdır.

Güvenlik ve operasyonel riskler

Aşırı merkezi ürün sahipliği görev ayrılığı ve süreç onaylarını zayıflatabilir. Tek kişiye bağlı bilgi, izin veya ayrılıkta karar boşluğu yaratır; vekalet ve dokümantasyon tanımlandı. Ürün sahibine üretim ortamında sınırsız teknik yetki verilmedi. Tedarikçiyle ticari ve teknik kararlar kayıtlı forumlarda alındı. Backlogda güvenlik, yasal zorunluluk ve yaşam döngüsü işleri görünür kapasite payına sahip oldu.

Çıkarılan Dersler

Kontrol Listesi

Dijital dönüşüm ekibi kurulurken iki ayrı pozisyon için iş vardı, fakat başlangıç hacmi iki tam zamanlı rolü doldurmuyordu. Aynı kişinin hem gereksinim görüşmelerini yürütmesi hem de plan, risk ve toplantı takibini yapması önerildi. Küçük ekiplerde bu yaklaşım pratik olabilir; ancak “şimdilik birlikte” kararı sınırları yazılmazsa kalıcı ve aşırı yüklü bir role dönüşür.

İş analisti problemi, süreç ve gereksinimi derinleştirir. PMO rolü ise portföy görünürlüğü, standart, bağımlılık, risk ve karar ritmini korur. İki rol ortak bilgi kullanır, fakat odak ve bağımsızlık ihtiyacı farklıdır. Birleştirme kararı unvan tartışmasıyla değil, gerçek iş yükü, proje karmaşıklığı ve kontrol ihtiyacıyla verilmelidir.

Sorunun ortaya çıkışı

Ekip aynı anda birkaç dijitalleşme girişimi yürütüyordu. Gereksinim toplantıları, süreç şemaları, test senaryoları, haftalık durum raporu, risk kaydı ve tedarikçi takibi için tek koordinasyon noktası isteniyordu. Ayrı roller bütçe açısından erken görünürken işler yöneticiler arasında paylaşıldığında standart kayboluyordu. Birleşik rol, başlangıç için sahiplik sağladı; sürdürülebilir sınırları ayrıca tasarlamak gerekti.

İlk belirtiler ve yanlış varsayımlar

İki rolün de toplantı ve dokümantasyon yapması aynı iş oldukları izlenimini verdi. Oysa analist gereksinimin doğruluğunu sorgularken PMO teslimatın plan ve yönetişim kalitesini izler. Bir kişinin bütün toplantılara girmesi iletişimi hızlandırabilir, fakat odak değiştirme maliyeti yaratır. Ayrıca kendi hazırladığı gereksinimin ilerlemesini bağımsız raporlamak iyimserlik yanlılığına açık olabilir.

Teknik analiz

Sorumlulukları haftalık saat, uzmanlık ve kontrol ihtiyacına göre ayırdık. Süreç keşfi, gereksinim, kabul kriteri ve UAT desteği BA tarafında; portföy takvimi, risk standardı, karar kaydı, bağımlılık ve yönetim raporu PMO tarafındaydı. Proje sayısı, paydaş sayısı, tedarikçi yoğunluğu ve kritik teslimatlar kapasite göstergesi oldu. Rolün onay vermediği, kolaylaştırdığı noktalar açıklandı.

Uygulanan çözüm veya önerilen mimari

Başlangıçta birleşik rol kuruldu, fakat haftalık kapasite iki iş kovasında ayrı izlendi. Gereksinim onayını süreç sahibi, proje durum doğrulamasını sponsor veya portföy yöneticisi yaptı. Ortak şablonlar ve tek karar günlüğü çift çalışmayı azalttı. Derin analiz günleri toplantısız bloklandı. Üç aylık gözden geçirmede kapasite, geciken analiz, rapor kalitesi ve yeni proje hattına göre rolün ayrılması değerlendirildi.

Alternatifler ve karar gerekçesi

BA’yı süreç ekiplerine dağıtıp merkezi hafif PMO kurmak iş bilgisine yakınlık sağlar; yöntem tutarlılığı için topluluk yapısı gerekir. Dış analist pik dönemi karşılayabilir, fakat kurumsal bilginin içeride kalması sağlanmalıdır. Tam teşekküllü PMO erken aşamada bürokrasi yaratabilir. Birleşik rolü geçiş modeli olarak seçtik; ayrışma eşiğini proje sayısı, kritik yol çatışması ve sürekli kapasite aşımıyla önceden tanımladık.

Güvenlik ve operasyonel riskler

Tek kişide gereksinim, rapor ve tedarikçi iletişiminin toplanması bilgi ve süreklilik riski yaratır. Belgeler kişisel klasörde değil ortak kontrollü alanda tutuldu, vekil belirlendi. Ticari değerlendirme ve kapsam onayı rolün tek başına vereceği kararlar olmadı. Fazla iş yükünün riskleri yeşil raporlama baskısıyla gizlenmemesi için kapasite görünür kılındı. Hassas proje bilgisine erişim her iki sorumluluk için de ihtiyaç kadar sınırlandı.

Çıkarılan Dersler

Kontrol Listesi

Bir ERP programında ilk aylarda takvim düzenli ilerliyor, çalışma grupları toplanıyor ve danışman ekip teslimatlarını yapıyordu. Buna rağmen kapsam dışı talepler birikiyor, süreç sahipleri kritik kararlara imza atmıyor ve bütçeyi etkileyen konular haftalarca bekliyordu. Sorun proje ekibinin çalışmaması değildi; karar alması gereken yönetim katmanının nasıl çalışacağının tanımlanmamış olmasıydı.

Uzun yıllar çok lokasyonlu yapılarda gördüğüm ortak nokta şu oldu: yönlendirme komitesinin değeri üye sayısıyla değil, çözebildiği engellerle ölçülür. Bu çalışma ilk olarak 22 Temmuz 2026 tarihinde ele alındı. Buradaki model tek bir kuruma özgü değil; sponsor, operasyon, finans, BT ve proje yönetimi arasında uygulanabilir bir karar düzeni kurmayı amaçlıyor.

Sorunun ortaya çıkışı

Çok lokasyonlu bir kurumun dijital dönüşüm programında her iş birimi projeyi kendi önceliğiyle yorumluyordu. Finans kontrol ve raporlama bütünlüğünü, operasyon kesintisiz üretimi, BT sürdürülebilir mimariyi, tedarik tarafı ise sözleşmedeki teslimatı korumaya çalışıyordu. Bu hedeflerin hiçbiri yanlış değildi; fakat aralarında seçim yapacak yetkili bir mekanizma olmadığı için günlük proje toplantıları stratejik kararların taşındığı verimsiz oturumlara dönüştü.

Komite kurulması gündeme geldiğinde ilk eğilim bütün yöneticileri davet etmekti. Böyle bir liste temsil sorununu azaltıyor gibi görünse de karar sorumluluğunu dağıtıyordu. Bazı katılımcılar bilgi almak, bazıları karar vermek, bazıları da yalnızca kendi bölümünü savunmak için masadaydı. Önce komitenin amacını “proje durumunu dinlemek” yerine “kapsam, bütçe, öncelik ve kritik risklerde karar vermek” olarak yeniden tanımladık.

İlk belirtiler ve yanlış varsayımlar

İlk belirti, aynı konunun üç toplantı boyunca açık kalmasıydı. Proje yöneticisi karar bekliyor, süreç sahibi üst yönetim desteği arıyor, sponsor ise konunun teknik ekipçe çözülebileceğini düşünüyordu. Bir başka belirti de kapsam değişikliklerinin resmi onay olmadan iş paketlerine girmesiydi. Takvim sapması görünür olduğunda sorun danışman kapasitesine bağlandı; oysa ekip, kararı verilmemiş işleri bekliyordu.

En yaygın yanlış varsayım, sponsorun tek başına bütün iş kararlarını vereceğidir. Sponsor yönü ve önceliği belirler, ancak süreç etkisini operasyon sahibi; mali sonucu finans; mimari ve güvenlik etkisini BT değerlendirmelidir. Diğer yanlış varsayım her toplantıya bütün uzmanların katılması gerektiğidir. Uzmanlar gündem maddesi için davet edilebilir; kalıcı üyelik ise karar yetkisi ve hesap verebilirlikle sınırlı tutulmalıdır.

Teknik analiz

Önce karar envanteri çıkardık: kapsam değişikliği, ek bütçe, süreç tasarımı, veri sahipliği, mimari istisna, risk kabulü ve canlıya geçiş onayı. Her karar türü için öneren, değerlendiren, onaylayan ve bilgilendirilen roller belirlendi. Böylece RACI tablosu yalnızca sunum malzemesi olmaktan çıktı; komite gündeminin hangi eşikte devreye gireceğini gösteren operasyonel bir araç haline geldi.

Komitenin çekirdek yapısı yönetici sponsor, ilgili ana süreç sahipleri, finans temsilcisi, BT yöneticisi ve proje/program yöneticisinden oluştu. PMO karar kaydını, riskleri ve takvimi hazırladı; oy sahibi gibi davranmadı. Her gündem maddesinde karar talebi, seçenekler, etki, öneri ve son karar tek sayfalık formatta sunuldu. Kırmızı-sarı-yeşil rapor yerine gecikmenin iş etkisini ve gereken yönetim kararını öne çıkardık.

Uygulanan çözüm veya önerilen mimari

Aylık olağan komite ve gerektiğinde kısa olağanüstü oturum düzeni kurduk. Operasyonel ekip haftalık çalışmaya devam ederken yalnızca yetki sınırını aşan maddeleri eskale etti. Gündemin ilk bölümü önceki kararların gerçekleşme durumuna, ikinci bölümü yeni karar taleplerine, son bölümü ise en önemli risk ve bağımlılıklara ayrıldı. Sunum süresini kısaltıp karar süresini artırmak toplantı kalitesinde belirgin fark yarattı.

Kapsam veya bütçe değişikliği, sözlü mutabakatla değil standart değişiklik kaydıyla ilerledi. Talebin iş değeri, toplam sahip olma etkisi, takvim sonucu, veri ve güvenlik etkisi birlikte değerlendirildi. Komite karar veremediğinde eksik bilginin sahibi ve tamamlanma tarihi belirlendi. Böylece “değerlendirilecek” ifadesi süresiz bir bekleme alanına dönüşmedi; projenin denetlenebilir hafızası oluştu.

Alternatifler ve karar gerekçesi

Tek sponsor modeli hızlıdır ve küçük, düşük riskli projelerde yeterli olabilir. Ancak kurum çapında süreç ve veri değişikliği yaratan programlarda tek kişinin ayrıntılı etkileri görmesi zordur. Geniş katılımlı kurul ise temsil gücü sağlar fakat gündem kalabalığı, düşük katılım ve belirsiz sorumluluk üretir. Bu nedenle küçük çekirdek komite ile gündeme göre çağrılan uzmanların dengeli modelini seçtik.

Haftalık komite seçeneğini de değerlendirdik. Kriz döneminde yararlı olsa da olağan düzende yöneticileri operasyonel ayrıntıya çekiyor ve proje ekibinin inisiyatifini azaltıyordu. Aylık ritim, tanımlı eskalasyon eşiği ve acil toplantı hakkı daha dengeli oldu. Kararın gerekçesi toplantı takviminden çok, doğru seviyedeki kararın doğru sürede alınmasını sağlamaktı.

Güvenlik ve operasyonel riskler

Komite belgeleri bütçe, denetim bulgusu, tedarikçi değerlendirmesi ve güvenlik riski içerebilir. Bu nedenle karar kayıtları rol bazlı erişilen kurumsal depoda tutulmalı; kişisel e-posta zincirlerinde veya kontrolsüz mesaj gruplarında paylaşılmamalıdır. Tutanaklar gerekli ayrıntıyı taşımalı, fakat gerçek kimlik bilgileri, özel ağ yapısı veya sistem sırları gibi proje kararı için gereksiz teknik bilgilerden arındırılmalıdır.

Operasyonel açıdan en büyük risk komitenin mikro yönetime kaymasıdır. Her küçük konu yukarı taşınırsa ekip sorumluluk alamaz; yalnızca büyük kararlar taşınır ama sonuçlar izlenmezse kurul sembolik kalır. Üye vekâletleri, karar yeter sayısı, risk kabul yetkisi ve acil durum yöntemi baştan yazılmalıdır. Ayrıca sponsor değişikliği halinde açık kararların ve taahhütlerin devri planlanmalıdır.

Çıkarılan Dersler

Kontrol Listesi

Bir güvenlik denetimi tamamlandığında masada kapsamlı bir rapor, çok sayıda tavsiye ve doğal olarak yüksek bir beklenti vardı. İlk bakışta yapılacak iş basit görünüyordu: maddeleri tabloya aktarmak ve her satıra bir tarih yazmak. Birkaç hafta sonra “SIEM kurulmalı” veya “ayrıcalıklı hesaplar korunmalı” gibi ifadelerin ne zaman tamamlanmış sayılacağı konusunda herkesin farklı düşündüğü ortaya çıktı.

Denetim ile iyileştirme programı arasındaki boşluk çoğu zaman teknoloji eksikliğinden değil, iş tanımının belirsizliğinden doğar. 1 Aralık 2025 ile Temmuz 2026 arasında ele aldığımız çalışmada raporu satın alma listesine çevirmek yerine, riski ölçülebilir kontrollere bağlayan bir portföy yaklaşımı kullandık. Kurum ayrıntıları anonimdir; yöntem farklı ölçekteki yapılara uyarlanabilir.

Sorunun ortaya çıkışı

Denetim raporunda uç nokta görünürlüğü, merkezi günlük yönetimi, ayrıcalıklı erişim, ağ kontrolü, felaket kurtarma ve izleme hizmeti gibi birçok başlık bulunuyordu. Tavsiyelerin bazıları teknoloji yatırımı, bazıları politika, bazıları insan kaynağı gerektiriyordu. Hepsi aynı öncelikte ve aynı satır yapısında izlenince yüksek riskli kısa işler ile uzun dönüşüm projeleri birbirinden ayrılamadı.

Yönetim kapanış tarihi görmek, teknik ekip ise bağımlılıkları anlatmak istiyordu. İş birimleri süreç değişikliklerinin kendilerine düşen kısmını bir BT görevi olarak algılıyordu. Denetçi önerisinin kelimesi kelimesine aksiyon adı yapılması da sahiplik sorununu büyüttü. Önce her bulgunun hangi varlığı, iş sürecini ve tehdit senaryosunu etkilediğini yeniden değerlendirmek gerekti.

İlk belirtiler ve yanlış varsayımlar

İlk yanlış varsayım, ürün alındığında bulgunun kapanacağıydı. Lisans satın alınmış fakat log kaynakları bağlanmamış bir SIEM ya da kasaya alınmamış ayrıcalıklı hesaplarla kurulmuş bir PAM, kontrolün çalıştığını kanıtlamaz. Benzer şekilde prosedür yayımlamak da çalışanların uyguladığı veya istisnaların izlendiği anlamına gelmez. Kapanış, teslimattan değil kontrol etkinliğinden ölçülmelidir.

Diğer belirti tarihlerin sürekli ötelenmesiydi. Satırın sahibi “BT” yazıldığı için hiçbir kişi veya kurul sonuçtan doğrudan sorumlu değildi. Bütçe onayı, tedarik, mimari tasarım, veri sahibi onayı ve kullanıcı eğitimi tek faaliyet gibi görülüyordu. Gecikmenin nedeni görünmeyince ekip performansı tartışılıyor, gerçek bağımlılıklar ise yönetim gündemine taşınmıyordu.

Teknik analiz

Her bulguyu önce risk ifadesine çevirdik: tehdit, etkilenen varlık, mevcut zayıflık ve olası iş etkisi. Ardından mevcut kontrolü, hedef kontrolü ve aradaki boşluğu yazdık. NIST veya ISO 27001 eşlemesi ortak dil sağladı; ancak çerçeve referansı tek başına öncelik belirlemedi. Kurumun varlık değeri, maruziyeti, yasal yükümlülüğü ve mevcut telafi edici kontrolleri birlikte ele alındı.

Aksiyon kartında hesap verebilir sahibi, uygulayıcı ekip, kilometre taşları, bütçe gereksinimi, hedef tarih, bağımlılık, başarı ölçütü ve beklenen kanıt yer aldı. Örneğin merkezi loglama için “ürün kuruldu” değil; kritik kaynak kapsamı, zaman senkronizasyonu, alarm akışı, saklama politikası ve örnek olay doğrulaması tanımlandı. Böylece yüzde ilerleme öznel beyana değil tamamlanmış çıktılara dayandı.

Uygulanan çözüm veya önerilen mimari

Portföyü hızlı kazanımlar, temel kabiliyetler ve çok yıllı dönüşümler olarak üç ufka ayırdık. Yapılandırma düzeltmeleri ile politika güncellemeleri kısa çevrimde ilerlerken EDR, SIEM, PAM, NAC veya DR gibi başlıklar ayrı proje kartlarına dönüştü. Ortak mimari, insan kaynağı ve tedarik bağımlılıkları tek yol haritasında gösterildi; aynı ekibin eş zamanlı taşıyamayacağı işler gerçekçi biçimde sıralandı.

Aylık yönetişim toplantısında yalnızca geciken tarihler değil, kalan risk ve kanıt kalitesi görüşüldü. Kontrol sahibi iş biriminden, teknik teslim sahibi ise ilgili ekipten seçildi. Tamamlanan maddeler örneklem testi, kayıt incelemesi veya masa başı tatbikatla doğrulandı. Risk geçici olarak kabul edildiyse onaylayan merci, bitiş tarihi ve telafi edici önlem kayda geçirildi.

Alternatifler ve karar gerekçesi

Denetim maddelerini olduğu gibi takip etmek hızlı başlangıç sağlar ve denetçi diliyle uyumludur; fakat çakışan tavsiyeleri, ortak bağımlılıkları ve risk değerini gizler. Tamamen yeni bir kurumsal risk programı kurmak ise daha tutarlı olabilir, ancak ilk iyileştirmeleri geciktirebilir. Biz rapor izlenebilirliğini koruyup birden çok bulguyu ortak kontrol projelerine bağlayan hibrit modeli tercih ettik.

Tüm doğrulamayı dış danışmana bırakmak bağımsızlık sağlar, buna karşılık sürekli operasyon bilgisini zayıflatır ve takvimi dış kaynağa bağımlı kılar. Yalnızca iç doğrulama daha çeviktir fakat iyimser değerlendirme riski taşır. Kritik bulgularda bağımsız örneklem, diğerlerinde iç kontrol testi ve dönemsel güvence incelemesi kullanılması maliyet ile güvenilirlik arasında daha dengeli sonuç verdi.

Güvenlik ve operasyonel riskler

Aksiyon planının kendisi hassas bir belgedir; zayıf kontrolleri, kritik varlıkları ve henüz giderilmemiş açıkları topluca gösterir. Erişim en az ayrıcalıkla sınırlandırılmalı, yönetim sunumlarında teknik ayrıntı azaltılmalı ve tedarikçilere yalnızca görevleri için gerekli bölüm verilmelidir. Kanıt dosyalarında gerçek parola, anahtar, özel ağ bilgisi veya gereksiz kişisel veri tutulmamalıdır.

Operasyonel risklerden biri aynı anda çok sayıda güvenlik ürününü devreye almaktır. Entegrasyon, alarm ayarı, eğitim ve olay müdahalesi kapasitesi hazırlanmadan kurulan araçlar görünürde kapsam yaratır, gerçekte gürültü üretir. Diğer risk denetim kapanışını nihai hedef sanmaktır. Tehdit, sistem ve iş süreci değiştikçe kontrol sahipleri etkinliği dönemsel olarak yeniden ölçmelidir.

Çıkarılan Dersler

Kontrol Listesi

Yüklenici erişimlerinde sorun çoğu zaman ilk gün değil, iş bittikten aylar sonra ortaya çıkar. Proje ekibi dağılmış, sponsor değişmiş ve geçici denilen hesap hâlâ çalışıyor olabilir. Bu tabloyu düzeltmenin yolu her talebi tek tek hatırlamak değil, ortak minimum standardı sürece yerleştirmektir.

20 Temmuz 2026 tarihinde mevcut prosedürü güçlendirirken teknik kontrol listesini sözleşme ve veri yönetişimiyle birleştirdik. Standart, küçük bakım firmasından uzun süreli danışmana kadar riskle orantılı çalışmalı; düşük riskli işi gereksiz bürokrasiyle durdurmamalıydı.

Prosedürü hazırlarken erişim isteyen tarafın dilini de sadeleştirdik. İş sahibi ağ segmenti veya teknik rol adı bilmek zorunda değildi; hangi işi yapacağını, hangi veriye ihtiyaç duyduğunu ve ne zamana kadar çalışacağını açıklaması yeterliydi. Teknik ekip bu ihtiyacı uygun erişim paketine çevirdi. Böylece güvenlik formu uzmanlık sınavına dönüşmedi, buna karşılık “her yere erişsin” gibi belirsiz talepler kabul edilmedi. Ölçüm tarafında açılış süresi kadar süresi dolmuş hesap, sponsorsuz kimlik ve gözden geçirmede kaldırılan gereksiz yetki sayısını takip ettik.

Sorunun ortaya çıkışı

Farklı iş birimleri yüklenici hesaplarını e-posta, telefon veya servis talebiyle açtırıyordu. Taleplerde sistem, veri sınıfı ve süre bilgisi tutarlı değildi. BT hesabı açsa bile sözleşme bitişinden haberdar olmuyor, satınalma kaydı ile kimlik kaydı eşleşmiyordu.

Minimum standart talep, risk sınıflandırma, onay, sağlama, izleme, gözden geçirme ve kapanış aşamalarını tanımladı. Her aşamanın sahibi belirlendi; güvenlik kontrolü yalnızca BT’nin son dakikada uyguladığı teknik engel olmaktan çıkarıldı.

İlk belirtiler ve yanlış varsayımlar

VPN erişiminin güvenli bağlantı sağladığı için yeterli olduğu düşünülüyordu. Oysa doğru kişiyi, yönetilen cihazı, izinli hedefi ve zaman aralığını ayrıca doğrulamak gerekir. MFA da aşırı yetkiyi veya paylaşılmış hesabı güvenli hale getirmez.

Tedarikçi şirketin güvenilir olması, her çalışanının süresiz erişim alabileceği anlamına gelmez. İsimli hesap, güncel personel listesi ve ayrılan personelin hızlı bildirimi gerekir. Ortak hesaplar izlenebilirliği bozar; acil durum dışında kullanılmamalı ve istisna olarak yönetilmelidir.

Teknik analiz

Talepte iş gerekçesi, hedef sistem, gerekli rol, veri sınıfı, cihaz sahipliği, lokasyon ve süre zorunlu tutuldu. Risk arttıkça güvenlik incelemesi, yönetilen sıçrama noktası, oturum kaydı veya daha dar zaman penceresi eklendi. Ayrıcalıklı erişim normal kullanıcı erişiminden farklı onaylandı.

Kimlik federasyonu mümkünse yaşam döngüsünü kolaylaştırabilir; yine de yerel yetkilendirme ve erişim gözden geçirmesi gerekir. Loglar kim, ne zaman, hangi kaynağa erişti sorularını yanıtlamalıdır. Periyodik inceleme yalnızca hesap varlığını değil, rolün hâlâ gerekli olup olmadığını sorgulamalıdır.

Uygulanan çözüm veya önerilen mimari

Servis kataloğunda risk bazlı yüklenici erişim formu oluşturuldu. Sözleşme veya gizlilik şartı doğrulanmadan teknik sağlama başlamadı. Onaylanan rol hazır erişim paketinden verildi; elle eklenen yetkiler gerekçeli istisna oldu.

Kimlik sistemi bitiş tarihinde otomatik askıya alma yaptı, sponsor incelemesi uzatma için zorunlu tutuldu. Kapanışta oturumlar, gruplar, anahtarlar, cihaz sertifikaları ve uygulama yetkileri kontrol edildi. Rapor, satınalma ve sözleşme envanteriyle düzenli karşılaştırıldı.

Alternatifler ve karar gerekçesi

Her yükleniciye aynı ağır kontrolü uygulamak kolay yönetilir görünse de düşük riskli erişimlerde verimsizdir. Tamamen vaka bazlı karar ise tutarsızlık yaratır. Üç risk seviyesi ve her seviyeye bağlı minimum kontrol seti dengeli sonuç verdi.

Doğrudan VPN yerine uygulama yayını, sıçrama sunucusu veya kimlik tabanlı erişim bazı senaryolarda daha dar kapsam sağlar. Seçim ürün modasına göre değil, hedef sistemin niteliği, oturum izleme ihtiyacı ve saha bağlantı koşullarına göre yapıldı.

Güvenlik ve operasyonel riskler

Üçüncü taraf cihazında zararlı yazılım, paylaşılan kimlik bilgisi veya yetersiz yama seviyesi kuruma taşınabilir. Cihaz koşulu uygulanamıyorsa erişim izole çalışma alanı üzerinden sınırlandırılmalıdır. Hassas veri indirme ve dışa aktarma ayrıca kontrol edilmelidir.

Aşırı bürokrasi kullanıcıyı kontrol dışı araçlara yöneltebilir. Süreç hızlı, ölçülebilir ve acil erişim için kayıtlı istisna içermelidir. Log saklama, oturum kaydı ve kişisel veri konuları sözleşme ve mevzuatla uyumlu olmalıdır.

Çıkarılan Dersler

Kontrol Listesi