ISO 27001 Kapsam Belirleme: Sınırlar, Arayüzler ve Kapsam İfadesi

Yanlış çizilmiş bir kapsam, ISO 27001 projesini ilk aydan bozar. Risk değerlendirmesine hangi varlıkların gireceği, Uygulanabilirlik Bildirgesi’nin (SoA) hangi kontrolleri taşıyacağı, denetimin kaç gün süreceği ve belgenin üzerine ne yazılacağı bu tek karara bağlıdır. Aşağıda bilgi güvenliği yönetim sisteminin (BGYS) sınırını çizecek BGYS ve IT yöneticileri için kapsamın girdilerini, sınır türlerini, bulut ve dış kaynak arayüzlerini ve denetimde ayakta kalan bir kapsam ifadesinin nasıl yazıldığını anlatıyoruz.

Kapsamı belirleyen girdiler

ISO/IEC 27001:2022 madde 4.3 kapsam için üç girdi ister: madde 4.1’deki iç ve dış konular, madde 4.2’deki ilgili tarafların gereklilikleri ve kuruluşun kendi faaliyetleri ile başka kuruluşların yürüttüğü faaliyetler arasındaki arayüzler ve bağımlılıklar. Kapsam ayrıca dokümante edilmiş bilgi olarak erişilebilir olmalıdır. Yani iş “hangi departmanları alalım?” sorusuyla başlamaz. Doğru soru şudur: kim bizden neyin güvence altına alınmasını bekliyor?

Sahada kapsam kararını fiilen belirleyen girdiler şunlardır:

• Belge talebinin kaynağı: Müşteri sözleşmesi, ihale şartnamesi veya ana sanayi belirli bir hizmetin ya da lokasyonun belgelendirilmesini istiyorsa kapsam en az o hizmeti içermek zorundadır.
• Yasal ve düzenleyici yükümlülükler: KVKK kapsamında işlenen kişisel veriler, sektörel düzenlemeler ve sözleşmedeki gizlilik hükümleri hangi süreçlerin dışarıda bırakılamayacağını söyler.
• Bilgi akışları: Kapsamdaki hizmetin ürettiği ve tükettiği bilgi hangi sistemlerde, hangi ekiplerin elinden geçerek, hangi tedarikçilerde işleniyor?
• Kaynak ve olgunluk: İlk belgelendirmede kurumun gerçekten işletebileceği ve kanıt üretebileceği bir sınır seçin. Kâğıtta geniş, uygulamada boş bir sistem ilk denetimde dağılır.

Bağlam ve ilgili taraflar çalışması yapılmadan verilen kapsam kararı dayanaksız kalır. Bu analizin nasıl yürütüleceği için kuruluşun bağlamı ve ilgili taraflar analizi rehberine bakın.

Organizasyonel, fiziksel ve teknolojik sınırlar

Denetçi kapsamı üç eksende sorgular ve her eksende çizginin nereden geçtiğini görmek ister. Eksenler birbirinden bağımsız değildir: bir birimi kapsama aldığınız anda o birimin oturduğu bina ve kullandığı sistemler de masaya gelir.

Eksen	Tanımlanacaklar	Tipik belirsizlik
Organizasyonel	Birimler, roller, hizmetler, süreçler	Destek birimleri (İK, satın alma, hukuk) dahil mi?
Fiziksel	Adresler, sistem odaları, depolar, uzaktan çalışma	Ev ofisler ve ortak çalışma alanları
Teknolojik	Ağ segmentleri, uygulamalar, bulut kiracıları, uç cihazlar	Paylaşılan Active Directory, ortak firewall

Organizasyonel sınırda sahada en sık gördüğümüz hata, hizmeti üreten birimi alıp onu besleyen destek süreçlerini dışarıda bırakmaktır. Yazılım geliştirme hizmetini kapsama alan bir kuruluş işe alım ve ayrılışı yürüten İK’yı dışarıda bırakırsa Annex A 6.1 (ön tarama) ve 6.5 (istihdamın sona ermesi veya değişmesinden sonraki sorumluluklar) kontrollerinin kanıtını yine İK’dan getirmek zorundadır. İK kapsam dışıdır ama kontrol sahibidir. Bu ilişki arayüz olarak yazılmalıdır.

Fiziksel sınırda adres listesi yetmez. Kapsamdaki bilginin dokunduğu her yeri sayın: yedek kartuşlarının götürüldüğü ikinci lokasyon, colocation veri merkezi, arşiv deposu, uzaktan çalışanların evleri. Uzaktan çalışma kapsamdaysa fiziksel kontrollerin bir kısmı (örneğin 6.7 uzaktan çalışma, 7.9 tesis dışındaki varlıkların güvenliği) politika ve teknik tedbirle karşılanır; kilitli kapı burada işe yaramaz.

Teknolojik sınırda asıl baş ağrısı paylaşılan altyapıdır. Kapsam tek bir iş birimini içerse bile o birim aynı Active Directory ormanını, aynı e-posta kiracısını ve aynı çekirdek firewall’u kullanıyorsa bu bileşenler fiilen kapsamın içindedir. Domain admin herkesin domain admin’idir. Kapsamı teknik olarak daraltmanın gerçekçi yolu ağ segmentasyonudur; ama denetçi segmentasyonun gerçekten çalıştığının kanıtını, yani ACL’leri, firewall kural setini ve erişim testlerini görmek ister.

Arayüzler ve bağımlılıklar

Madde 4.3(c) kapsamı “içerisi” ve “dışarısı” diye ikiye bölmekle yetinmez; ikisi arasındaki bağlantı noktalarının tanımlanmasını ister. Arayüz, kapsamdaki bir süreçle kapsam dışındaki bir birim ya da dış kuruluş arasında bilgi, hizmet veya sorumluluk alışverişinin olduğu noktadır. Her arayüz için aşağıdaki alanları taşıyan bir arayüz kaydı tutun; denetimde ilk açılacak dokümanlardan biri budur:

Arayüz	Taraf	Akan bilgi/hizmet	Güvence yöntemi
Bulut e-posta ve dosya	SaaS sağlayıcı	Tüm yazışma ve dokümanlar	Sözleşme, sağlayıcı belgeleri, kiracı yapılandırması
Yönetilen firewall	MSP	Ağ erişim politikası	Hizmet sözleşmesi, değişiklik kaydı, erişim gözden geçirme
Bordro	Kapsam dışı İK	Personel kişisel verisi	İç hizmet anlaşması, erişim yetkileri
Veri merkezi	Colocation	Fiziksel barındırma	Sağlayıcının belgesi ve kapsamı, giriş kayıtları

Dış kaynakta kural basittir: süreç dışarı verilir, sorumluluk verilmez. Annex A 5.19–5.22 (tedarikçi ilişkileri) ve 5.23 (bulut hizmetlerinin kullanımı) kontrolleri, dış kaynaklı her arayüz için gereksinimlerin sözleşmeye yazılmasını ve hizmetin izlenmesini bekler. Yönetilen firewall örneğinde MSP’nin yaptığı kural değişikliğinin sizin değişiklik kaydınızda görünmesi gerekir; görünmüyorsa denetçi bunu bulur. Bir bulut sağlayıcının ISO 27001 belgesine dayanıyorsanız belgenin kapsam ifadesini mutlaka okuyun: kullandığınız hizmeti ve bölgeyi gerçekten kapsıyor mu?

Dar ve geniş kapsam karşılaştırması

Kapsam genişliği bir strateji kararıdır. Tek doğru yoktur; seçim kurumun hedefine, kaynağına ve müşterinin ne beklediğine göre yapılır.

Kriter	Dar kapsam	Geniş kapsam
Kurulum süresi	Kısa, odaklı	Uzun, çok paydaşlı
Denetim süresi ve maliyet	Daha düşük	Çalışan sayısı ve lokasyonla artar
Arayüz yönetimi	Çok sayıda arayüz, karmaşık kanıt	Az arayüz, daha sade sınır
Müşteri algısı	Kapsam ifadesi okunduğunda sınırlı görünebilir	Kurum genelinde güvence
Risk	Kapsam dışı alanlardan sızan riskler görünmez kalır	Olgunlaşmamış birimler uygunsuzluk üretir

Paylaşılan altyapının yoğun olduğu ortamlarda dar kapsam sanıldığı kadar dar kalmaz. Her yeni arayüz yeni bir kanıt dosyası demektir. Orta ölçekli kuruluşlarda sağlıklı bir başlangıç, ilk belgelendirmeyi müşteriye dönük ana hizmet ve onu taşıyan BT altyapısıyla yapmak, kapsamı gözetim döngülerinde planlı olarak genişletmektir.

Kapsam dışı bırakmanın denetimdeki sonuçları

İki farklı “dışarıda bırakma” sürekli karıştırılır. Birincisi kapsam sınırıdır: bir birimin veya lokasyonun BGYS dışında olması. İkincisi Annex A kontrollerinin hariç tutulmasıdır: SoA’da gerekçesiyle yapılır ve risk değerlendirmesine dayanmak zorundadır. Madde 4–10 gereklilikleri hiçbir şekilde hariç tutulamaz. Denetçi iki durumu da şu sorularla sınar:

• Kapsam dışı birim kapsamdaki bilgiye erişiyor mu? Erişiyorsa bu erişim nasıl kontrol ediliyor?
• Hariç tutulan kontrolün gerekçesi gerçek mi, yoksa “uygulamıyoruz” demenin kibar hâli mi?
• Kapsam ifadesi müşteriyi yanıltacak kadar geniş görünüyor mu?

Hariç tutma gerekçelerinin SoA’ya nasıl yazılacağı ISO 27001 SoA rehberinde ayrıntılı anlatılıyor.

Örnek kapsam ifadeleri

Kapsam dokümantasyonu iki katmanlıdır: belgenin üzerine yazılacak kısa kapsam ifadesi ve sınırları, arayüzleri, hariç tutmaları açıklayan kapsam dokümanı. Kısa ifade hizmeti, lokasyonu ve SoA sürümüne atfı içermelidir. Aşağıdaki ifadeler kurgusal örneklerdir:

Örnek 1 (hizmet odaklı): “[Şehir] genel merkezinden sunulan yönetilen BT altyapı hizmetlerinin tasarımı, işletimi ve desteğine ilişkin bilgi güvenliği yönetim sistemi; [tarih] tarihli Uygulanabilirlik Bildirgesi sürüm 1.2’ye uygun olarak.”

Örnek 2 (kurum geneli): “[Kuruluş]’un [şehir] merkez ofisi ve [şehir] üretim tesisinde yürütülen tüm faaliyetleri destekleyen bilgi sistemleri ve süreçleri; Uygulanabilirlik Bildirgesi sürüm 2.0.”

Zayıf ifadelerin ortak derdi belirsizliktir. “BT departmanı” bir birim söyler ama hangi hizmetin güvence altında olduğunu söylemez; “tüm bilgi varlıkları” ise hiçbir sınır çizmez. Kapsam dokümanında ayrıca şunlar bulunmalıdır:

• Dahil olan birimler, roller ve yaklaşık personel sayısı
• Lokasyonların adresleri ve her lokasyonda yürütülen faaliyet
• Kapsamdaki ana sistem ve uygulamalar, bulut kiracıları
• Arayüz kaydına atıf ve kapsam dışı bırakılanların gerekçesi
• Onaylayan yönetici, onay tarihi ve doküman sürümü

Kapsam değişikliği yönetimi

Kapsam yazılıp rafa kaldırılan bir doküman değildir. Yeni lokasyon, şirket satın alımı, bir hizmetin buluta taşınması ya da ana tedarikçinin değişmesi kapsamı doğrudan etkiler. Sahada en sık karşılaştığımız tablo şudur: e-posta buluta taşınmış, dosya sunucusu kapatılmış, ama kapsam dokümanı ve varlık envanteri hâlâ eski sunucuyu gösteriyor. ISO 27001:2022’de eklenen madde 6.3 (değişikliklerin planlanması), BGYS’deki değişikliklerin planlı yapılmasını ister. Kapsam değişikliği için önerdiğimiz sıra:

1. Değişikliğin bağlam ve ilgili taraflar üzerindeki etkisini değerlendirin.
2. Arayüz kaydını ve varlık envanterini güncelleyin.
3. Yeni kapsam için risk değerlendirmesini yapın ve SoA’yı revize edin.
4. Değişikliği yönetimin gözden geçirmesine girdi olarak sunun ve onaylatın.
5. Belgelendirme kuruluşunu bilgilendirin; kapsam genişletmesi genellikle gözetim veya ayrı bir ek denetim ile değerlendirilir.

Bildirilmeden genişletilmiş bir faaliyet için belge kullanmak, müşteriye verilen güvencenin dayanağını ortadan kaldırır. Kapsam daraltıldığında da belge üzerindeki ifade güncellenmelidir. Belge gerçeği yansıtmalı.

Kapsam kararını BGYS kurulumunun diğer adımlarıyla birlikte görmek için BGYS kurulum rehberi genel çerçeveyi verir. Mevcut durumunuzu kapsam seçeneklerine göre ölçmek için ISO 27001 gap analizi, kapsamı sahada işletmek için BGYS kurulumu ve uygulama danışmanlığı sayfalarına bakabilirsiniz. Standardın resmi tanıtımı ISO’nun ISO/IEC 27001 sayfasında yer alır.

Sık sorulan sorular

Kapsamı sadece bir departmanla sınırlamak mümkün mü?

Mümkün. Ancak o departmanın kullandığı paylaşılan altyapı (kimlik yönetimi, e-posta, ağ) ve destek süreçleri arayüz olarak tanımlanmalı, bu arayüzlerdeki kontroller kanıtlanmalıdır. Çok dar bir kapsam arayüz sayısını artırır ve kanıt yükünü büyütebilir.

Annex A kontrollerini kapsam dışı bırakabilir miyiz?

Annex A kontrolleri risk değerlendirmesine dayanan ve SoA’da yazılı bir gerekçeyle hariç tutulabilir. Madde 4 ile 10 arasındaki yönetim sistemi gereklilikleri ise hariç tutulamaz.

Bulut hizmetlerini kullanıyorsak bulut sağlayıcı kapsamımıza girer mi?

Sağlayıcının kendisi kapsamınıza girmez; arayüz olarak tanımlanır. Kiracı yapılandırması, kimlik ve erişim yönetimi, veri sınıflandırması gibi müşteri tarafı sorumluluklar ise kapsamınızdadır ve kanıtı sizden istenir.

Belgelendirme sonrasında kapsamı genişletebilir miyiz?

Evet. Değişiklik planlı yapılır: risk değerlendirmesi ve SoA güncellenir, yönetim onayı alınır, belgelendirme kuruluşu bilgilendirilir. Genişletme genellikle gözetim denetimiyle birlikte veya ayrı bir ek denetimle değerlendirilir.