Bilgi Güvenliği Hedefleri Nasıl Belirlenir ve İzlenir?

“Bilgi güvenliğini artırmak” bir hedef değildir. Dönem sonunda kimse tuttu mu tutmadı mı diye cevap veremez ve denetçi bunu ilk bakışta görür. Bilgi güvenliği hedefleri, BGYS’nin işleyip işlemediğini yönetime gösteren en kısa yoldur; ama ancak ölçülebilir yazıldıklarında. Aşağıda ISO 27001 madde 6.2’ye uygun hedeflerin politika ve risk değerlendirmesinden nasıl türetileceğini, zayıf ve iyi hedef örneklerini, bir hedef planlama kartını ve hedeflerin madde 9.1 ölçümüyle bağını anlatıyoruz.

Hedeflerin politika ve risklerle ilişkisi

ISO/IEC 27001:2022 madde 6.2, bilgi güvenliği hedeflerinin ilgili fonksiyon ve seviyelerde belirlenmesini ve şu özellikleri taşımasını ister: bilgi güvenliği politikasıyla tutarlı olmak, uygulanabilir olduğunda ölçülebilir olmak, uygulanabilir bilgi güvenliği gerekliliklerini ve risk değerlendirmesi ile risk işleme sonuçlarını dikkate almak, izlenmek, iletilmek, uygun şekilde güncellenmek ve dokümante edilmiş bilgi olarak erişilebilir olmak. “İzlenmek” şartı 2022 revizyonunda açıkça eklendi.

Bu tanım hedeflerin üç kaynaktan beslendiğini söyler:

• Politika: Politikadaki taahhütler (müşteri bilgisinin gizliliği, hizmet sürekliliği gibi) hedeflerin yönünü belirler. Politikanın kendisi için bilgi güvenliği politikası nasıl yazılır rehberine bakın.
• Risk değerlendirmesi: Yüksek kalan riskler ve risk işleme planındaki büyük aksiyonlar hedefe dönüşmeye en uygun adaylardır.
• Gereklilikler: İlgili tarafların sözleşmesel ve yasal gereklilikleri (örneğin olay bildirim süresi) bir hedefin kabul eşiğini doğrudan verebilir.

Bu üç kaynaktan hiçbirine bağlanamayan hedef ya gereksizdir ya da yanlış yerdedir. Listeden çıkarın.

Ölçülebilir hedefin unsurları

Ölçülebilir hedef, okuyan herkesin dönem sonunda “tuttu mu?” sorusuna aynı cevabı verebildiği hedeftir. Bunun için şu unsurlar yazılı olmalıdır:

1. Gösterge: Neyin ölçüleceği (örneğin kritik yamaların uygulanma süresi).
2. Hedef değer ve eşik: Kabul edilen değer ve hangi değerin altında aksiyon alınacağı.
3. Kapsam: Göstergenin hangi varlık veya süreç grubu için geçerli olduğu.
4. Süre: Hedefin hangi tarihe kadar ya da hangi dönem için geçerli olduğu.
5. Veri kaynağı: Değerin hangi sistemden veya kayıttan alınacağı.
6. Sorumlu: Ölçümü yapan ve hedefin sahibi olan kişi veya rol.

Sahada en sık eksik kalan unsur veri kaynağıdır. Hedef güzel yazılmıştır, ama dönem sonunda değeri kimin, hangi rapordan çekeceği belli değildir; sonuçta biri Excel’e tahmini bir sayı girer. Kapsam da sık atlanır: “sunucular” denir, ama envanterde olmayan, bir köşede unutulmuş bir sanal makine ölçümün dışında kalır.

Madde 6.2’deki “uygulanabilir olduğunda ölçülebilir” ifadesi bazı hedeflerin niceliksel olmayabileceğini kabul eder. “Yeni ERP projesinde güvenlik gereksinimleri tasarım onayından önce dokümante edilecek” hedefi bir sayı içermez; ama tamamlanıp tamamlanmadığı açıkça doğrulanır. Niteliksel hedefte doğrulanabilir bir çıktı ve tarih yeterlidir.

Zayıf ve iyi hedef örnekleri

Tablodaki hedef değerler örnek amaçlıdır. Kendi değerlerinizi mevcut durum ölçümünüze ve risk iştahınıza göre koyun; ölçmeden konan değer ya hemen tutar ya hiç tutmaz.

Zayıf hedef	Sorun	İyi yazılmış hedef (örnek)
Farkındalığı artırmak	Ölçüt ve süre yok	Yıl sonuna kadar tüm personelin yıllık farkındalık eğitimini tamamlaması; oltalama simülasyonunda bağlantıya tıklama oranının ilk ölçümün yarısına inmesi
Yamaları zamanında yapmak	“Zamanında” tanımsız	İnternete açık sistemlerde kritik güvenlik yamalarının yayımdan itibaren 14 gün içinde uygulanması; her çeyrekte bu sürenin aşıldığı sistem sayısının raporlanması
Yedeklemeyi iyileştirmek	Çıktı belirsiz	Kritik sistemlerin her biri için çeyrekte en az bir geri yükleme testi yapılması ve sonuçların RTO hedefiyle karşılaştırılması
Hiç olay yaşanmaması	Kontrol edilemez, raporlamayı caydırır	Bildirilen güvenlik olaylarının sınıflandırmasının 1 iş günü içinde tamamlanması
Tedarikçileri denetlemek	Kapsam ve sıklık yok	Kritik olarak sınıflanan tedarikçilerin tamamı için yıllık güvenlik değerlendirmesinin Eylül sonuna kadar tamamlanması

“Hiç olay yaşanmaması” tipi hedef özellikle zararlıdır. Kuruluşun kontrolünde değildir ve olay bildirimini bastırma yönünde istenmeyen bir baskı yaratır: ekipler küçük olayları kayda geçirmemeye başlar. Ölçülmesi gereken, olay yönetimi sürecinin hızı ve kalitesidir. Sessizlik güvenlik değildir.

Yedekleme satırı da ayrıca not edilmeli. Yedekleme yazılımında “başarılı” görünen iş, geri yüklenebilir veri anlamına gelmez; sahada en çok karşılaşılan durum, iş yeşil yanarken uygulama tutarlılığının (VSS, veritabanı log zinciri) bozuk olmasıdır. Hedefin “yedek alındı” değil “geri yükleme test edildi” diye yazılmasının sebebi budur.

Hedef planlama kartı

Madde 6.2, hedeflere nasıl ulaşılacağının planlanmasında beş sorunun cevabını ister: ne yapılacak, hangi kaynaklar gerekecek, kim sorumlu olacak, ne zaman tamamlanacak ve sonuçlar nasıl değerlendirilecek. Bu beş soruyu her hedef için tek bir kartta toplayın; uygulama da denetim de kolaylaşır.

Hedef No       : BGH-2026-03
Hedef          : Kritik sistemlerin her biri için çeyrekte en az
                 bir geri yükleme testi; sonuç RTO ile karşılaştırılır
Kaynak         : Risk R-014 (fidye yazılımı sonrası geri dönüş),
                 politika md. 4 (hizmet sürekliliği)
Ne yapılacak   : 1) Kritik sistem listesinin güncellenmesi
                 2) Test takviminin hazırlanması
                 3) İzole test ortamının ayrılması
Kaynaklar      : Test ortamı için depolama alanı, ayda 1 gün BT emeği
Sorumlu        : Sistem Yöneticisi (uygulama), BGYS Yöneticisi (izleme)
Tamamlanma     : Dönem sonu; çeyreklik ara kontrol
Değerlendirme  : Test kayıtları; test edilen / planlanan sistem sayısı;
                 ölçülen geri dönüş süresi ile RTO farkı
Raporlama      : Çeyreklik BGYS raporu, yıllık YGG

Kart hedefin hangi risk ve politika maddesinden geldiğini gösterdiği için izlenebilirliği de sağlar. Hedef sayısını sınırlı tutun. Yönetimin gerçekten takip edebileceği birkaç anlamlı hedef, yirmi satırlık ve kimsenin açmadığı bir listeden daha çok iş görür.

İzleme, ölçme ve raporlama

Hedefler madde 6.2’de, ölçüm madde 9.1’de tanımlıdır. 9.1 neyin izlenip ölçüleceğini, hangi yöntemle, ne zaman, kim tarafından yapılacağını ve sonuçların ne zaman, kim tarafından analiz edilip değerlendirileceğini belirlemeyi ister. Planlama kartındaki “değerlendirme” satırı 9.1’in bu sorularına verilmiş cevabın kendisidir. Ölçüm sonuçları dokümante edilmiş bilgi olarak saklanmalıdır.

Ölçüm tasarımında rehber olarak ISO/IEC 27004 (bilgi güvenliği yönetimi — izleme, ölçme, analiz ve değerlendirme) kullanılabilir. Sahadan pratik öneriler:

• Veriyi mümkün olduğunca sistemden alın: yama yönetimi aracının raporu, yedekleme yazılımının iş geçmişi, eğitim platformunun tamamlama listesi. Elle doldurulan tablo hem hata üretir hem güvenilirlik sorusu doğurur.
• Ölçüm yöntemini sabitleyin. Dönem ortasında “kritik yama” tanımı değişirse eğilim anlamını kaybeder.
• Hedef göstergesiyle risk göstergesini karıştırmayın. Anahtar risk göstergeleri (KRI) riskin büyüdüğüne dair erken uyarı verir; hedef ise yönetim sisteminin taahhüdünü ölçer. Ayrım için KRI tasarımı rehberine bakın.
• Raporu karar için hazırlayın: değer, eşik, eğilim ve önerilen aksiyon. Bu rapor yönetimin gözden geçirmesine doğrudan girdi olur.

Madde 9.3.2, yönetimin gözden geçirmesinde bilgi güvenliği hedeflerinin karşılanma durumunun eğilimleriyle birlikte değerlendirilmesini zorunlu tutar. Toplantının nasıl kurgulanacağı yönetimin gözden geçirmesi (YGG) rehberinde anlatılıyor.

Hedefin tutturulamaması durumunda yapılacaklar

Tutturulamayan hedef tek başına uygunsuzluk değildir. Denetçinin baktığı, kuruluşun durumu fark edip etmediği ve ne yaptığıdır. Önerdiğimiz sıra:

1. Sapmayı erken yakalayın: Aylık veya çeyreklik ara kontrol noktası yoksa sapma ancak dönem sonunda görülür. O zaman da iş işten geçmiştir.
2. Nedeni analiz edin: Kaynak eksikliği mi, yanlış hedef değeri mi, süreç sorunu mu? Kontrolün çalışmaması gibi süreç kaynaklı nedenler madde 10.2 kapsamında düzeltici faaliyete dönüşebilir.
3. Kararı kayda alın: Kaynak artırma, süre uzatma veya hedefi revize etme kararı yetkili yönetim tarafından verilmeli ve gerekçesiyle yazılmalıdır.
4. Hedefi sessizce değiştirmeyin: Hedef değerin dönem sonunda karar kaydı olmadan düşürülmesi denetimde ciddi soru işareti yaratır. Madde 6.2’deki “uygun şekilde güncellenmek” şartı güncellemenin bilinçli ve kayıtlı olmasını gerektirir.

Kontrol listesi

• Her hedefin politika, risk veya gereklilik kaynağı yazılı mı?
• Gösterge, hedef değer, süre, veri kaynağı ve sorumlu tanımlı mı?
• Planlama kartında ne, kaynak, sorumlu, süre ve değerlendirme yöntemi var mı?
• Hedefler ilgili çalışanlara iletildi mi ve bunun kanıtı var mı?
• Ölçüm sonuçları saklanıyor ve YGG’ye raporlanıyor mu?

Hedefleri ve göstergeleri yönetim raporlamasıyla birlikte tasarlamak için YGG ve KPI tasarımı hizmetimize, hedefleri BGYS kurulumunun parçası olarak ele almak için BGYS kurulumu sayfasına bakabilirsiniz. Standardın resmi tanıtımı ISO/IEC 27001 sayfasındadır.

Sık sorulan sorular

Kaç adet bilgi güvenliği hedefi belirlemeliyiz?

Standart bir sayı vermez. Yönetimin düzenli takip edebileceği, politika ve önemli risklerle doğrudan bağlantılı az sayıda hedef, uzun ve takip edilmeyen bir listeden daha çok iş görür.

Her hedef sayısal olmak zorunda mı?

Hayır. Madde 6.2 hedeflerin uygulanabilir olduğunda ölçülebilir olmasını ister. Niteliksel hedef de kabul edilir; ancak tamamlanıp tamamlanmadığı açıkça doğrulanabilmeli ve bir tamamlanma tarihi bulunmalıdır.

Hedef tutturulamazsa denetimde uygunsuzluk yazılır mı?

Tutturulamayan hedef tek başına uygunsuzluk değildir. Sapmanın fark edilmemesi, nedeninin analiz edilmemesi veya hedefin kayıtsız biçimde değiştirilmesi ise madde 6.2, 9.1 veya 10.2 kapsamında bulguya yol açabilir.

Hedefler ile KPI’lar aynı şey mi?

Değil. KPI bir göstergedir; hedef ise bu göstergeye bağlanmış değer, süre, sorumlu ve plan içerir. Bir hedef bir veya birkaç KPI ile izlenebilir, ama her KPI bir hedef değildir.