Kuruluşun Bağlamı ve İlgili Taraflar Analizi Nasıl Yapılır?

Madde 4.1 ve 4.2 standardın en kısa bölümüdür ve en çok kâğıt üzerinde kalan bölümüdür. Pek çok kuruluşta bağlam analizi bir kez doldurulmuş bir SWOT tablosundan, ilgili taraflar listesi de “müşteriler, çalışanlar, tedarikçiler” satırlarından ibarettir. Denetçi bu tabloyu açar, kapsamla ve risk kaydıyla bağını sorar, cevap gelmez. Aşağıda bu iki maddeyi kapsam, risk değerlendirmesi ve hedeflere gerçekten bağlanan bir çalışmaya çevirmek için yöntemi, örnek tabloyu ve kanıt önerilerini veriyoruz.

Bağlam analizinin amacı

Bağlam analizi BGYS’nin “neden” sorusunu cevaplar. Madde 4.1, kuruluşun amacıyla ilgili olan ve BGYS’nin amaçlanan sonuçlarına ulaşma yeteneğini etkileyen iç ve dış konuların belirlenmesini ister. Standardın notu bu konuların ISO 31000:2018 madde 5.4.1’deki dış ve iç bağlamla ilişkili olduğunu belirtir. 2024’te yayımlanan Değişiklik 1 ile madde 4.1’e kuruluşun iklim değişikliğinin ilgili bir konu olup olmadığını belirlemesi, madde 4.2’ye de ilgili tarafların iklim değişikliğiyle ilgili gereklilikleri olabileceğine dair not eklendi; bu değişikliğin projeye etkisi 2022 ve 2024 değişikliği rehberinde ayrıca anlatılıyor.

Analizin çıktısı üç yerde kullanılır:

• Kapsam (4.3): Hangi hizmet, lokasyon ve süreçlerin BGYS’ye gireceği. Kapsam kararının ayrıntıları için ISO 27001 kapsam belirleme rehberine bakın.
• Risk ve fırsatlar (6.1.1): Standart, planlama yapılırken 4.1’deki konuların ve 4.2’deki gerekliliklerin dikkate alınmasını açıkça ister.
• Yönetimin gözden geçirmesi (9.3.2): İç ve dış konulardaki, ilgili tarafların ihtiyaçlarındaki değişiklikler zorunlu girdidir.

Bu üç bağdan biri kopuksa analiz sadece bir dosyadır. Denetçi bunu ilk sorusunda anlar.

İç ve dış konuların belirlenmesi

Konuları toplamak için yaygın araçlar dış konular için PESTLE (politik, ekonomik, sosyal, teknolojik, yasal, çevresel), iç konular için SWOT’un güçlü ve zayıf yönler bölümüdür. Hangi aracı seçtiğiniz fark etmez. Fark eden, her konunun bilgi güvenliği açısından sonucunun yazılmasıdır. “Dijitalleşme artıyor” cümlesi analize hiçbir şey katmaz; “müşteri portalı 2. çeyrekte buluta taşınacak, kimlik yönetimi ve veri yerleşimi kararları gerekecek” cümlesi ise risk değerlendirmesine doğrudan girdi olur.

Tür	Konu örneği	Bilgi güvenliği sonucu
Dış – yasal	KVKK ve sektörel düzenlemeler	Kişisel veri envanteri, ihlal bildirimi süreci
Dış – teknolojik	Fidye yazılımı tehdidinin sektörde yoğunlaşması	Yedek erişim ayrımı, geri yükleme testi
Dış – ekonomik	Ana müşterinin tedarikçi güvenlik denetimi başlatması	Kanıt hazırlığı, kapsam genişletme
İç – yapı	BT ekibinin iki kişiden oluşması	Görevler ayrılığının sınırlı olması, telafi edici kontrol
İç – teknoloji	Destek süresi bitmiş sunucu işletim sistemleri	Yama yönetimi riski, geçiş planı
İç – kültür	Saha personelinin ortak hesap kullanma alışkanlığı	Kimlik doğrulama ve farkındalık önlemi

Tablodaki iç konular sahada sürekli karşımıza çıkan tiplerdir. Destek süresi bitmiş bir Windows Server ya da eski bir SLES sürümü üzerinde çalışan kritik bir uygulama, yama alamadığı için kendi başına bir risk kaynağıdır ve bağlam analizinde açıkça yazılmalıdır. Üretimde vardiya terminallerinde ortak kullanıcı hesabı da aynı şekilde: kayıtlar kimin işlem yaptığını göstermez, olay incelemesi orada tıkanır.

Konuları yalnız BT ekibiyle toplamayın. Üretim, satış, İK, hukuk ve finans temsilcileriyle yapılan yarım saatlik görüşmeler, masa başında yazılmış listeden çok daha gerçekçi sonuç verir. Her konuya bir kaynak (görüşme, sözleşme, mevzuat, olay kaydı) ekleyin; denetimde analizin nereden geldiğini gösterirsiniz.

İlgili taraflar ve gereklilikleri

Madde 4.2 üç adım ister: (a) BGYS ile ilgili tarafları belirlemek, (b) bu tarafların ilgili gerekliliklerini belirlemek ve (c) bu gerekliliklerden hangilerinin BGYS aracılığıyla ele alınacağını belirlemek. Üçüncü adım 2022 revizyonunda eklendi ve sahada en çok atlanan adımdır. Her gerekliliği BGYS’ye almak zorunda değilsiniz. Ama hangisini neden almadığınızı bilmek zorundasınız.

Filtre olarak tek bir soru yeter: bu taraf bilgi güvenliğiyle ilgili bir kararımızdan etkilenir mi, ya da bizi etkileyebilir mi? Gereklilikler üç kaynaktan gelir:

1. Yasal ve düzenleyici: Mevzuattan doğan, pazarlığa kapalı gereklilikler.
2. Sözleşmesel: Müşteri sözleşmeleri, gizlilik anlaşmaları, tedarikçi sözleşmeleri, sigorta poliçesi şartları.
3. Beklentiler: Yazılı olmayan ama karşılanmadığında ilişkiyi bozan talepler; örneğin çalışanların uzaktan erişimin kesintisiz çalışmasını beklemesi.

Örnek ilgili taraflar tablosu

Aşağıdaki tablo orta ölçekli bir üretim veya hizmet şirketi için kurgusal bir örnektir. Kendi tablonuzda “BGYS’de mi?” sütununu boş bırakmayın; “hayır” cevabının gerekçesi de bir kayıttır.

İlgili taraf	Gereklilik	Kaynak	BGYS’de mi?
Kurumsal müşteriler	Gizlilik, olay bildirimi süresi	Sözleşme eki	Evet – olay yönetimi süreci
Kişisel veri sahipleri	Verinin hukuka uygun işlenmesi	KVKK	Evet – kişisel veri kontrolleri
Çalışanlar	İzlemenin şeffaf olması	Aydınlatma metni, iç politika	Evet – kabul edilebilir kullanım
BT hizmet sağlayıcısı	Erişim için açık talimat	Hizmet sözleşmesi	Evet – tedarikçi erişim süreci
Sigorta şirketi	MFA ve yedekleme beyanı	Siber poliçe soru formu	Evet – kontrol kanıtı
Yönetim kurulu	Bütçenin öngörülebilir olması	İç beklenti	Kısmen – YGG’de raporlanır
Bina yönetimi	Ortak alan kamera kayıtları	Kira sözleşmesi	Hayır – kapsam dışı, gerekçe yazılı

Sigorta satırına ayrıca dikkat edin. Siber poliçe soru formunda “tüm uzaktan erişimlerde MFA var” diye işaretlenmiş bir kutu, sahada VPN’in bir kısmının hâlâ yalnız parola ile çalıştığı ortamlarda sık görülür. Bu bir beyan riskidir. Formu dolduran ile firewall’u yöneten aynı tabloya bakmalıdır.

Tabloya her satırı ilgili kontrol, prosedür veya hedefe bağlayan bir referans sütunu ekleyin; izlenebilirlik buradan kurulur. Gerekliliklerin yazılı dokümanlara dönüşmesi için yapılan ISO 27001 dokümantasyon hazırlama çalışması da bu tablodan beslenir.

Analizin risk ve hedeflere bağlanması

Bağlam ve ilgili taraflar analizi risk değerlendirmesinin girdisidir, kendisi bir risk kaydı değildir. Bağ şu şekilde kurulur:

• Her iç/dış konu ve her gereklilik için “karşılanmazsa ne olur?” diye sorulur. Cevap, risk kaydında bir senaryo veya mevcut bir riskin olasılık/etki gerekçesi olarak yer alır.
• Yasal ve sözleşmesel gereklilikler Annex A 5.31 (yasal, mevzuat, düzenleyici ve sözleşmesel gereklilikler) kontrolünün kanıt listesini oluşturur.
• Önemli gereklilikler bilgi güvenliği hedeflerine dönüşür. Müşteri sözleşmesindeki bildirim süresi, olay müdahale süresine ilişkin ölçülebilir bir hedefin dayanağıdır; hedef yazımının ayrıntıları bilgi güvenliği hedefleri rehberinde.
• Fırsatlar da kaydedilir: yeni bir müşteri talebi BGYS kapsamını genişletmenin gerekçesi olabilir.

Risk değerlendirmesinin yöntemi ve kayıt örnekleri için BGYS risk analizi rehberine bakabilirsiniz. İzlenebilirliği göstermenin pratik yolu, ilgili taraflar tablosunda risk kimliği ve hedef kimliği sütunları tutmaktır. Denetçi bir sözleşme maddesinden başlar, hangi riskle ve hangi kontrolle karşılandığını tek satırda görür. Soru biter.

Güncelleme sıklığı ve kanıtı

Standart bağlam analizi için sabit bir sıklık tanımlamaz; ancak 9.3.2 gereği her yönetimin gözden geçirmesinde değişiklikler değerlendirilmelidir. Bu yüzden analizi en az YGG döngüsüyle aynı sıklıkta gözden geçirin ve ayrıca şu olaylarda tetikleyin:

• Yeni bir müşteri sözleşmesi veya mevcut sözleşmede güvenlik ekinin değişmesi
• Yeni mevzuat ya da mevcut mevzuatta değişiklik
• Organizasyon yapısında, lokasyonlarda veya ana BT altyapısında büyük değişiklik
• Kuruluşu veya sektörü etkileyen ciddi bir güvenlik olayı

4.1 ve 4.2 için standart dokümante edilmiş bilgi zorunluluğu koymaz. Ancak kapsamın (4.3) dokümante edilmesi zorunludur ve kapsamın bu girdilere dayandığını göstermenin en güvenilir yolu analizi yazılı tutmaktır. Denetimde kabul gören kanıtlar: sürüm ve tarih taşıyan analiz dokümanı, analiz için yapılan görüşmelerin kısa notları, YGG tutanağında değişikliklerin görüşüldüğünü gösteren madde ve analizden doğan aksiyonların takip kaydı.

Sık yapılan hatalar

• Her kuruluşa uyabilecek, şirkete özgü olmayan konular yazmak
• İlgili taraf listesi olup gereklilik sütununun boş kalması
• Gerekliliklerden hangilerinin BGYS ile ele alındığının belirtilmemesi
• Analizin son güncelleme tarihinin ilk belgelendirme tarihinde takılı kalması

Bu çalışmayı BGYS kurulumunun parçası olarak yürütmek isterseniz ISO 27001 BGYS kurulumu hizmetimizin kapsamına bakabilirsiniz. Standardın resmi tanıtımı ISO/IEC 27001 sayfasında bulunur.

Sık sorulan sorular

Bağlam analizi için PESTLE ve SWOT kullanmak zorunlu mu?

Hayır. Standart belirli bir araç istemez. PESTLE ve SWOT konuları sistematik toplamaya yardım eder; asıl olan her konunun bilgi güvenliği sonucunun yazılması ve kapsam, risk ve hedeflerle ilişkilendirilmesidir.

İlgili tarafların tüm gerekliliklerini BGYS’ye almak gerekir mi?

Gerekmez. Madde 4.2, gerekliliklerden hangilerinin BGYS aracılığıyla ele alınacağının belirlenmesini ister. Dışarıda bırakılan gereklilikler için kısa bir gerekçe yazmak, denetimde kararın bilinçli verildiğini gösterir.

Bağlam analizi ne sıklıkla güncellenmeli?

Standart sabit bir sıklık vermez. Yönetimin gözden geçirmesi değişiklikleri girdi olarak istediği için analizi en az YGG döngüsüyle birlikte gözden geçirin; yeni sözleşme, mevzuat değişikliği veya büyük organizasyonel değişiklikte ayrıca güncelleyin.

İklim değişikliği bilgi güvenliğiyle nasıl ilişkilendirilir?

2024 değişikliği, kuruluşun iklim değişikliğinin ilgili bir konu olup olmadığını belirlemesini ister. Bilgi güvenliği açısından sel, aşırı sıcak ve enerji kesintisinin veri merkezi ve iş sürekliliğine etkisi değerlendirilebilir; ilgili değilse bu sonuç gerekçesiyle kaydedilir.