Risk İşleme Planı Nasıl Hazırlanır? Seçenekler ve Takip

Risk değerlendirmesi bitmiş, yirmi yüksek risk listelenmiş, toplantı tutanağı imzalanmış. Altı ay sonra açık aksiyonlara baktığınızda hiçbirinin sahibi, tarihi veya bütçesi yok. Risk değerlendirmesi hangi risklerin önemli olduğunu söyler; risk işleme planı bu risklerle ne yapılacağını, kim tarafından, ne zamana kadar ve hangi kaynakla yapılacağını belirler. ISO/IEC 27001:2022 madde 6.1.3 bu adımı işleme seçeneklerinin belirlenmesinden Uygulanabilirlik Bildirgesi’ne (SoA) ve risk sahibi onayına kadar tanımlar; madde 8.3 ise planın uygulanmasını ve sonuçlarının kaydını ister. Aşağıda kâğıtta kalmayan, izlenebilir bir planın nasıl kurulduğunu anlatıyoruz.

Risk işleme seçenekleri

ISO/IEC 27005:2022 dört temel seçenek tanımlar. Türkçe uygulamada farklı adlarla anılabilirler; adı değil anlamı net olmalıdır:

Seçenek	Ne yapar?	Tipik örnek
Kaçınma	Riske yol açan faaliyeti bırakır veya değiştirir	Müşteri verisinin kişisel cihazlarda işlenmesini tamamen yasaklamak
Azaltma (değiştirme)	Kontrollerle olasılığı veya etkiyi düşürür	MFA, ağ segmentasyonu, değişmez yedek
Paylaşma (transfer)	Etkinin bir kısmını başka tarafa aktarır	Siber sigorta, sözleşmesel sorumluluk, yönetilen hizmet
Kabul (tutma)	Riski bilinçli olarak olduğu gibi üstlenir	Düşük etkili bir zafiyeti izlemeye almak

Bir risk için birden fazla seçenek birlikte kullanılır. Fidye yazılımı senaryosunda olasılığı düşüren kontroller (e-posta filtreleme, yama yönetimi), etkiyi düşüren kontroller (çevrimdışı veya değişmez yedek, geri yükleme testi) ve finansal etkiyi paylaşan bir sigorta poliçesi aynı planda yer alabilir. Tek seçenekli plan genellikle eksik plandır.

Seçenek seçiminde karar sırası

Seçeneği belirlerken şu soruları sırayla sorun:

1. Risk kabul kriterlerinin içinde mi? Evetse ve yetkili kişi onaylıyorsa kabul yeterlidir. Kriterler risk kabul kriterleri çalışmasında tanımlanmış olmalıdır.
2. Faaliyet iş için gerçekten gerekli mi? Değilse kaçınma çoğu zaman en ucuz ve en etkili seçenektir. Kullanılmayan bir dış erişim kanalını kapatmak, onu korumaya çalışmaktan kolaydır. Sahada firewall üzerinde yıllardır açık duran, kimsenin sahiplenmediği port yönlendirmeleri bunun tipik örneğidir. Kapatın, risk gider.
3. Kontrol maliyeti beklenen etkiyle orantılı mı? Azaltma, kontrol maliyetinin olası etkiyle kıyaslanmasını gerektirir. Kıyas nitel olabilir ama kayda geçmelidir.
4. Etki parasal olarak aktarılabilir mi? Paylaşma yalnızca finansal etkiyi aktarır. Yasal sorumluluk, müşteri güveni ve operasyonel kesinti kuruluşta kalır. Hizmet dış kaynağa verildiğinde bile risk sahipliği ve hesap verebilirlik kuruluşta devam eder.
5. Kontrol devreye girene kadar ne olacak? Kalıcı çözüm aylar sürecekse geçici telafi edici önlem (ek izleme, erişim kısıtlaması) planda ayrı satır olarak yer almalıdır. Aradaki boşluk da bir risktir.

Plan tablosunda olması gereken alanlar

Risk işleme planı ayrı bir doküman olabilir ya da bilgi güvenliği risk değerlendirmesi sonucunda oluşan risk kaydının sütunları olarak tutulabilir. Biçim ne olursa olsun, her aksiyonda şu alanlar bulunmalıdır:

Alan	Açıklama
Risk No / seçenek	Bağlı risk ve seçilen işleme seçeneği
Aksiyon	Doğrulanabilir sonuç içeren somut iş tanımı
İlgili kontrol	Annex A veya kurum içi kontrol referansı
Sorumlu	Aksiyonu yürüten kişi (risk sahibinden farklı olabilir)
Kaynak / bütçe	Onaylı bütçe kalemi, iş gücü veya “mevcut kaynak”
Hedef tarih	Kilometre taşlarıyla birlikte bitiş tarihi
Beklenen kalıntı risk	Aksiyon tamamlandığında hedeflenen O × E
Durum ve kanıt	Planlandı / sürüyor / tamamlandı / gecikti + kanıt bağlantısı

Planın kalitesini aksiyon cümlesi belirler. “Erişim güvenliği iyileştirilecek” bir aksiyon değildir; ne zaman bittiğini kimse söyleyemez. “VPN erişimi olan tüm hesaplarda MFA zorunlu hale getirilecek; istisna listesi BGYS yöneticisince onaylanacak” bir aksiyondur ve tamamlandığı doğrulanabilir. Doğrulanamayan aksiyon kapanmaz.

Örnek plan satırları

Risk / aksiyon	Kontrol	Sorumlu / tarih	Kalıntı hedef
R-07 Fidye yazılımı: yedeklerin domain dışı, değişmez depoya alınması	A 8.13	Sistem yöneticisi / Q1	3×5 → 2×3
R-07 Fidye yazılımı: çeyreklik geri yükleme testi ve kaydı	A 8.13	Sistem yöneticisi / sürekli	—
R-11 Tedarikçi uzaktan erişimi: kalıcı VPN hesaplarının talep bazlı erişime dönüştürülmesi	A 5.19, A 8.5	Network sorumlusu / Q2	4×4 → 2×4
R-15 Kişisel cihazlarda müşteri çizimi: BYOD erişiminin kaldırılması	A 8.1	BT müdürü / Q1	Risk kapanır (kaçınma)

Kontrol numaraları ISO/IEC 27001:2022 Annex A’ya göredir: 5.19 tedarikçi ilişkilerinde bilgi güvenliği, 8.1 kullanıcı uç nokta cihazları, 8.5 güvenli kimlik doğrulama, 8.13 bilgi yedekleme. R-07’deki ikinci satıra dikkat: yedeğin değişmez depoya alınması tek seferlik bir iş, geri yükleme testi ise sürekli bir faaliyettir. İkisini aynı satıra yazarsanız, ilki bittiğinde ikincisi de “tamamlandı” görünür. Tedarikçi riskinin kapsamlı değerlendirmesi ayrı bir süreç ister; ayrıntılar tedarikçi bilgi güvenliği risk değerlendirmesi rehberinde.

SoA ile bağlantı

Madde 6.1.3 b) ve c), işleme için gerekli kontrollerin belirlenmesini ve Annex A ile karşılaştırılarak gerekli bir kontrolün atlanmadığının doğrulanmasını ister. Madde 6.1.3 d) bu sonucu Uygulanabilirlik Bildirgesi’ne taşır. Bağlantı şöyle kurulur:

• Plandaki her kontrol referansı SoA’da “uygulanabilir” olarak görünmelidir.
• SoA’da kontrolün dahil edilme gerekçesi olarak ilgili risk numaraları yazılabilir; denetçiye en kısa izlenebilirlik yolu budur.
• SoA’da “uygulanıyor” yazan ama planda açık aksiyonu olan bir kontrol tutarsızlıktır. Uygulama durumu sütununu “kısmen uygulanıyor, R-11 aksiyonu açık” gibi gerçeği yansıtacak şekilde doldurun.
• Bir risk kaçınma ile kapandığında, yalnız o risk için seçilmiş kontrollerin SoA’daki gerekçesi yeniden gözden geçirilir.

SoA’nın kendi yapısı ve hariç tutma gerekçeleri için ISO 27001 SoA nedir rehberine bakabilirsiniz.

Kalıntı risk ve risk sahibi onayı

Madde 6.1.3 f), risk sahiplerinin hem planı onaylamasını hem de kalıntı riskleri kabul etmesini ister. Pratikte iki ayrı onay anı vardır:

1. Plan onayı: Risk sahibi aksiyonların, bütçenin ve tarihlerin yeterli olduğunu kabul eder. Bu onay yoksa plan, BT ekibinin iyi niyetli iş listesidir.
2. Kalıntı risk kabulü: Aksiyonlar tamamlandıktan sonra risk yeniden puanlanır. Gerçekleşen kalıntı risk beklenenden yüksekse risk sahibi ya ek işlem ister ya da gerçekleşen değeri kabul eder.

Beklenen kalıntı riski planlama aşamasında yazmanın nedeni budur: aksiyonun işe yarayıp yaramadığını ölçecek referans noktası verir. Yeniden puanlamada olasılığı düşüren kontrolün gerçekten çalıştığına dair kanıt arayın. MFA politikası açılmış ama yirmi hesap istisna grubunda unutulmuşsa, kontrol kurulmuştur ama çalışmıyordur. “Kuruldu” ile “çalışıyor” aynı şey değil.

Plan ilerlemesinin takibi

Risk işleme planlarının çoğu kötü yazıldığı için değil, takip edilmediği için başarısız olur. İşleyen bir takip düzeni için:

• Tek kaynak kullanın: Aksiyonları ayrı bir Excel’de, ticket sisteminde ve toplantı notlarında tutmak tutarsızlık üretir. Aksiyonları mevcut iş takip aracında açıp risk numarasıyla etiketleyin; plan bu kayıtları referans göstersin.
• Aylık durum gözden geçirmesi: BGYS yöneticisi açık aksiyonları sorumlularla gözden geçirir; gecikenler için yeni tarih ve gecikme nedeni yazılır.
• Eskalasyon kuralı: Hedef tarihi belirlenen süreyi aşan veya ikinci kez ertelenen aksiyonlar risk sahibine ve üst yönetime raporlanır.
• Kanıtı kapanışta isteyin: “Tamamlandı” durumu ancak kanıt bağlantısıyla (yapılandırma ekran görüntüsü, sistem raporu, onay kaydı) işaretlenir.
• Gösterge kullanın: Gecikmiş aksiyon sayısı, yüksek riskler için ortalama kapanma süresi gibi göstergeler YGG’ye girdi olur. Gösterge tasarımı anahtar risk göstergeleri rehberinde ele alınıyor.

Sahada sık görülen hatalar

• Bütün risklerin “azaltma” ile işaretlenmesi; kaçınma ve kabulün hiç düşünülmemesi
• Bütçe gerektiren aksiyonların bütçe onayı alınmadan plana yazılması
• Sorumlu olarak kişi yerine departman adı yazılması
• Tamamlanan aksiyon sonrası riskin yeniden puanlanmaması
• Plan değişikliklerinin (tarih ertelemesi, kapsam daraltma) risk sahibine bildirilmemesi

Sorumlu sütununda “BT” yazıyorsa, o aksiyonun sahibi yok demektir. Departman iş yapmaz; kişi yapar.

Risk işleme planının SoA ile birlikte kurgulanması ve takip düzeninin oturtulması, ISO 27001 risk analizi, risk işleme ve SoA çalışmasının ana çıktılarındandır. İşleme seçeneklerinin standart tanımları için ISO/IEC 27005:2022 birincil kaynaktır.

Sık sorulan sorular

Risk işleme planı ayrı bir doküman olmak zorunda mı?

Hayır. ISO/IEC 27001 risk işleme planının oluşturulmasını ve belgelenmiş bilgi olarak tutulmasını ister, biçim belirtmez. Risk kaydına eklenen sütunlar veya iş takip sistemindeki etiketli kayıtlar da yeterlidir; aksiyon, sorumlu, tarih ve onay izlenebilmelidir.

Risk transfer edildiğinde risk sahibi değişir mi?

Hayır. Sigorta veya dış kaynak kullanımı finansal ya da operasyonel etkinin bir kısmını aktarır; riskin sahipliği ve hesap verebilirlik kuruluşta kalır. Risk sahibi transferin yeterliliğini ve kalan riski değerlendirmeye devam eder.

Tamamlanan aksiyondan sonra risk ne zaman yeniden puanlanmalı?

Aksiyon kapandıktan ve kontrolün çalıştığına dair kanıt alındıktan sonra. Kontrolün devreye alınması ile etkin çalışması farklı şeylerdir; kalıntı risk, kontrolün fiilen işlediği gösterildiğinde güncellenir.

Plan ile SoA arasında tutarsızlık olursa ne olur?

Belgelendirme denetiminde sık sorgulanan noktalardandır. SoA’da uygulanıyor görünen bir kontrolün planda açık aksiyonu varsa denetçi hangisinin doğru olduğunu sorar. SoA’daki uygulama durumunu planın güncel durumuyla eşleştirmek bu riski belirgin şekilde azaltır.