# ISO/IEC 27001 Risk Analizi Nasıl Yapılır? Risk Değerlendirme, Risk İşleme ve SoA Hazırlama Rehberi

**URL:** https://securesys.com.tr/tr/bilgi-merkezi/siber-guvenlik-uyum-danismanlik/iso-27001-risk-analizi-risk-degerlendirme-soa

![ISO/IEC 27001 Risk Analizi Nasıl Yapılır? Risk Değerlendirme, Risk İşleme ve SoA Hazırlama Rehberi](/images/bilgi-merkezi/covers/cover-uyum-04.webp)

### ISO/IEC 27001 Risk Analizi Nedir?

**ISO/IEC 27001 risk analizi, bir kuruluşun bilgi güvenliğini etkileyebilecek riskleri belirlemesi, olasılık ve sonuçlarını değerlendirmesi, önceliklendirmesi ve uygun güvenlik önlemlerini seçmesi için yürüttüğü sistematik çalışmadır.**

Risk analizi, Bilgi Güvenliği Yönetim Sistemi'nin (BGYS) temel karar mekanizmalarından biridir.

Bir kurumun hangi güvenlik teknolojilerine yatırım yapacağı, hangi sistemleri öncelikle koruyacağı, hangi zafiyetleri acil olarak gidereceği ve hangi riskleri kabul edebileceği bu süreçten etkilenir.

ISO/IEC 27001:2022, bilgi güvenliği risk değerlendirmesine ilişkin gereksinimleri özellikle 6.1.2 maddesinde, risk işleme gereksinimlerini ise 6.1.3 maddesinde ele alır.

Standart bütün kuruluşlara tek bir risk puanlama formülü zorunlu tutmaz.

Kuruluşun kendi faaliyetlerine uygun, tutarlı ve karşılaştırılabilir sonuçlar üretebilen bir metodoloji oluşturmasını bekler.

**Kısa cevap:** ISO 27001 risk analizi; bilgi varlıklarını ve iş süreçlerini etkileyen risklerin tanımlanması, risk seviyelerinin belirlenmesi, uygun kontrollerin seçilmesi ve kalan risklerin yetkili kişiler tarafından değerlendirilmesi sürecidir.

### \1. ISO 27001 Risk Analizi Neden Yapılır?

Kurumsal bilgi sistemlerinde bütün tehditlerin tamamen ortadan kaldırılması mümkün değildir.

Güvenlik bütçeleri, insan kaynakları ve operasyonel kapasite sınırlıdır.

Bu nedenle kurumların hangi risklerin öncelikli olduğunu belirlemesi gerekir.

Örneğin internete açık bir VPN sistemindeki aktif istismar edilen güvenlik açığı, izole test ortamındaki düşük etkili bir yapılandırma eksikliğinden daha acil olabilir.

Benzer şekilde kritik müşteri verilerinin yedeklenmemesi, düşük öneme sahip bir uygulamadaki kullanılmayan hesabın bulunmasından daha yüksek iş etkisi oluşturabilir.

Risk analizi bu farklılıkların sistematik biçimde değerlendirilmesini sağlar.

#### Risk analizinin temel amaçları

- Kritik bilgi varlıklarını ve iş süreçlerini belirlemek.
- Olası tehditleri ve güvenlik zayıflıklarını değerlendirmek.
- Güvenlik yatırımlarını önceliklendirmek.
- Risk sahiplerini ve sorumlulukları belirlemek.
- Uygun güvenlik kontrollerini seçmek.
- Risk kabul kararlarını kayıt altına almak.
- Yönetimin bilgi güvenliği kararlarını desteklemek.
- BGYS'nin sürekli iyileştirilmesine katkı sağlamak.

Risk analizi yalnızca belgelendirme denetimi öncesinde hazırlanacak bir doküman olarak görülmemelidir.

Kurumsal karar alma süreçlerinde düzenli kullanılmalıdır.

### \2. ISO/IEC 27001 Risk Yönetimi ile Risk Analizi Arasındaki Fark

Risk analizi ve risk yönetimi birbiriyle ilişkili ancak farklı kavramlardır.

**Risk yönetimi**, risklerin belirlenmesi, değerlendirilmesi, işlenmesi, izlenmesi ve iletişimini kapsayan genel süreçtir.

**Risk analizi**, risklerin niteliğinin ve seviyesinin anlaşılmasına odaklanan değerlendirme aşamasıdır.

**Risk değerlendirmesi**, risklerin tanımlanması, analiz edilmesi ve belirlenen kriterlerle karşılaştırılarak değerlendirilmesini kapsar.

**Risk işleme**, belirlenen risklere yönelik uygun seçeneklerin seçilmesi ve uygulanmasıdır.

#### Örnek

Bir kurumun uzaktan erişim sisteminde MFA bulunmadığını düşünelim.

Risk tanımlama aşamasında yetkisiz erişim senaryosu belirlenir.

Risk analizi aşamasında olasılık ve olası iş etkisi değerlendirilir.

Risk değerlendirme aşamasında riskin kabul edilebilir seviyede olup olmadığına karar verilir.

Risk işleme aşamasında MFA uygulanması planlanabilir.

Uygulama sonrasında kalan risk yeniden değerlendirilir.

Böylece risk yönetimi bir defalık tablo çalışmasından sürekli işleyen sürece dönüşür.

### \3. ISO/IEC 27001:2022 Risk Yönetimi Gereksinimleri

ISO/IEC 27001:2022 kapsamında risk yönetimi farklı maddelerle ilişkilidir.

| Standart maddesi | Konu | Uygulama amacı |
| --- | --- | --- |
| 4.1 | Kuruluşun bağlamı | İç ve dış hususların değerlendirilmesi |
| 4.2 | İlgili taraflar | Gereksinimlerin belirlenmesi |
| 6.1.2 | Risk değerlendirmesi | Bilgi güvenliği risklerinin belirlenmesi ve değerlendirilmesi |
| 6.1.3 | Risk işleme | Risk işleme seçeneklerinin ve kontrollerin belirlenmesi |
| 8.2 | Operasyonel risk değerlendirmesi | Planlanan aralıklarla ve önemli değişikliklerde değerlendirme |
| 8.3 | Operasyonel risk işleme | Risk işleme planının uygulanması |
| 9.1 | İzleme ve ölçme | Performansın değerlendirilmesi |
| 9.3 | Yönetimin gözden geçirmesi | Risklerle ilgili yönetim değerlendirmesi |
| 10 | İyileştirme | Uygunsuzlukların giderilmesi ve sürekli iyileştirme |

Önemli bir ayrıntı, ISO/IEC 27001'in risk değerlendirmesini yalnızca varlık envanteriyle sınırlamamasıdır.

Kuruluşun bilgi güvenliği risklerini uygun şekilde tanımlaması ve değerlendirmesi gerekir.

### \4. ISO 27001 Risk Analizi Metodolojisi Nasıl Oluşturulur?

Risk analizine başlamadan önce değerlendirme yöntemi belirlenmelidir.

Aksi halde farklı ekipler aynı riski farklı kriterlerle puanlayabilir.

Bu durum sonuçların karşılaştırılmasını güçleştirir.

#### Metodolojide tanımlanması gereken alanlar

Risk değerlendirme kapsamı.

Risk tanımlama yaklaşımı.

Risk sahiplerinin belirlenmesi.

Olasılık kriterleri.

Etki kriterleri.

Risk hesaplama yöntemi.

Risk kabul kriterleri.

Risk değerlendirme sıklığı.

Önemli değişikliklerde yeniden değerlendirme koşulları.

Risk raporlama yöntemi.

#### Örnek metodoloji

Kurum 1–5 arasında olasılık ve etki ölçekleri kullanabilir.

Risk seviyesi iki değerin çarpımıyla hesaplanabilir.

Ancak bu formül ISO/IEC 27001 tarafından zorunlu tutulmaz.

Kurumun seçtiği yöntemin gerekçelendirilmesi ve tutarlı uygulanması önemlidir.

### \5. Varlık Bazlı Risk Analizi Nedir?

Varlık bazlı risk analizi, bilgi varlıklarından hareketle risklerin değerlendirilmesidir.

Öncelikle varlıklar belirlenir.

Ardından bu varlıklara yönelik tehditler, zayıflıklar ve olası sonuçlar incelenir.

#### Örnek varlıklar

Veritabanı sunucuları.

Web uygulamaları.

Active Directory.

Firewall cihazları.

VPN altyapısı.

Yedekleme sistemleri.

Kaynak kod depoları.

Bulut depolama alanları.

Müşteri bilgileri.

Finansal kayıtlar.

#### Örnek

**Varlık:** Müşteri veritabanı.

**Tehdit:** Yetkisiz veri erişimi.

**Zayıflık:** Gereğinden geniş erişim yetkileri.

**Olası sonuç:** Hassas verilerin açıklanması.

**Önerilen kontrol:** Rol bazlı erişim, ayrıcalıklı hesap yönetimi ve izleme.

Bu yöntem, teknik varlıkların ayrıntılı değerlendirilmesinde kullanışlıdır.

Ancak tek başına varlık listesine odaklanılması, süreçler arası veya organizasyonel risklerin gözden kaçmasına neden olabilir.

### \6. Senaryo Bazlı Risk Analizi Nedir?

Senaryo bazlı yaklaşımda riskler belirli olaylar ve olası sonuçlar üzerinden değerlendirilir.

Bu yaklaşım iş süreçleriyle teknik güvenlik riskleri arasındaki ilişkiyi daha görünür hale getirebilir.

#### Örnek risk senaryosu

“Bir saldırganın ele geçirilmiş VPN kimlik bilgileriyle kurumsal ağa erişmesi ve kritik sunucularda yetkisiz işlem gerçekleştirmesi.”

Bu senaryoda değerlendirilmesi gereken unsurlar:

VPN kimlik doğrulama yöntemi.

MFA kapsamı.

Kullanıcı yetkileri.

Ağ segmentasyonu.

Güvenlik izleme.

Kritik sistemlere erişim.

Olası iş kesintisi.

#### Avantajı

Tek bir varlık yerine saldırı zincirinin tamamı değerlendirilebilir.

#### Önemli nokta

Varlık bazlı ve senaryo bazlı yöntemler birbirinin alternatifi olmak zorunda değildir.

Kuruluşlar iki yaklaşımı birlikte kullanabilir.

### \7. Bilgi Güvenliği Riskinin Temel Bileşenleri

Riskin değerlendirilmesinde birden fazla unsur dikkate alınabilir.

#### Tehdit

Bilgi varlığına veya iş sürecine zarar verebilecek olası olay veya aktördür.

Örnekler:

Siber saldırgan.

İç tehdit.

Donanım arızası.

İnsan hatası.

Doğal afet.

#### Zafiyet

Bir tehdidin etkisini artırabilecek güvenlik zayıflığıdır.

Örnekler:

MFA eksikliği.

Güncel olmayan yazılım.

Yanlış firewall kuralı.

Zayıf erişim politikası.

#### Olasılık

Belirli bir risk senaryosunun gerçekleşme ihtimaline ilişkin değerlendirmedir.

#### Etki

Risk gerçekleştiğinde ortaya çıkabilecek sonuçların önemidir.

#### Mevcut kontroller

Riskin olasılığını veya etkisini azaltan mevcut önlemlerdir.

#### Risk sahibi

Riskin yönetilmesine ilişkin yetki ve sorumluluğu bulunan kişi veya roldür.

Risk sahibi her zaman teknik kontrolü uygulayan kişi olmayabilir.

Örneğin finansal sistemin risk sahibi ilgili iş birimi yöneticisiyken MFA uygulamasından IAM ekibi sorumlu olabilir.

### \8. Risk Olasılığı Nasıl Puanlanır?

Örnek bir 5 seviyeli olasılık ölçeği oluşturulabilir.

| Puan | Seviye | Örnek açıklama |
| --- | --- | --- |
| 1 | Çok düşük | Gerçekleşmesi oldukça düşük görülüyor |
| 2 | Düşük | Sınırlı koşullarda gerçekleşebilir |
| 3 | Orta | Makul bir gerçekleşme ihtimali var |
| 4 | Yüksek | Tehdit koşulları güçlü, gerçekleşme ihtimali yüksek |
| 5 | Çok yüksek | Gerçekleşme ihtimali çok yüksek veya olay göstergeleri mevcut |

Bu açıklamalar kurumsal bağlama göre daha ölçülebilir hale getirilmelidir.

#### Olasılığı etkileyen faktörler

İnternete açıklık.

Bilinen istismar yöntemleri.

Tehdit istihbaratı.

Zafiyetin istismar edilebilirliği.

Saldırganın erişim gereksinimleri.

Mevcut koruma kontrolleri.

Geçmiş güvenlik olayları.

#### Örnek

İnternete açık, bilinen ve aktif istismar edilen bir zafiyete sahip kritik sistemin risk olasılığı yüksek değerlendirilebilir.

Ancak değerlendirme mevcut korumalar ve gerçek erişilebilirlik dikkate alınarak yapılmalıdır.

### \9. Risk Etkisi Nasıl Puanlanır?

Risk etkisi yalnızca maddi kayıp üzerinden değerlendirilmemelidir.

Bilginin gizliliği, bütünlüğü ve erişilebilirliği üzerindeki sonuçlar birlikte ele alınmalıdır.

#### Örnek etki matrisi

| Puan | Etki seviyesi | Örnek sonuç |
| --- | --- | --- |
| 1 | Çok düşük | Sınırlı operasyonel etki |
| 2 | Düşük | Küçük çaplı hizmet aksaması |
| 3 | Orta | Belirli süreçlerde önemli aksama |
| 4 | Yüksek | Kritik iş süreçlerinde ciddi etki |
| 5 | Çok yüksek | Kurumsal faaliyetlerde çok ağır sonuçlar |

#### Etki kategorileri

Finansal kayıp.

Operasyonel kesinti.

Kişisel veri ihlali.

Yasal ve sözleşmesel sonuçlar.

İtibar kaybı.

Müşteri etkisi.

Bilgi bütünlüğünün bozulması.

#### Örnek

Bir test sunucusunun kısa süreli erişilemez olması düşük etki oluşturabilir.

Ancak aynı kesintinin kritik ödeme altyapısında gerçekleşmesi yüksek veya çok yüksek etki doğurabilir.

Etki değerlendirmesi varlığın gerçek iş önemine göre yapılmalıdır.

### \10. ISO 27001 İçin 5×5 Risk Matrisi

5×5 risk matrisi, risklerin görsel olarak önceliklendirilmesini sağlayan örnek yöntemlerden biridir.

Aşağıdaki modelde risk puanı olasılık ve etki değerlerinin çarpımıyla hesaplanır.

| Olasılık / Etki | 1 | 2 | 3 | 4 | 5 |
| --- | --- | --- | --- | --- | --- |
| 5 | 5 | 10 | 15 | 20 | 25 |
| 4 | 4 | 8 | 12 | 16 | 20 |
| 3 | 3 | 6 | 9 | 12 | 15 |
| 2 | 2 | 4 | 6 | 8 | 10 |
| 1 | 1 | 2 | 3 | 4 | 5 |

#### Örnek risk sınıflandırması

| Puan | Risk seviyesi | Örnek yaklaşım |
| --- | --- | --- |
| 1–4 | Düşük | İzleme ve rutin değerlendirme |
| 5–9 | Orta | Planlı iyileştirme |
| 10–16 | Yüksek | Öncelikli risk işleme |
| 17–25 | Kritik | Acil yönetim değerlendirmesi |

Bu eşikler örnek olarak verilmiştir.

Kuruluşun risk iştahı, iş etkisi ve değerlendirme metodolojisine göre değiştirilmelidir.

**Önemli:** 5×5 matris, kesin olasılık hesaplaması değildir. Sayısal puanlar uzman değerlendirmesini destekleyen kategorik göstergeler olarak kullanılmalıdır.

### \11. Risk Puanı Nasıl Hesaplanır?

Örnek bir kurumda kritik veritabanı sunucusunun yedekleme sürecinin bulunmadığını varsayalım.

#### Risk senaryosu

Donanım arızası veya fidye yazılımı nedeniyle kritik verilerin kaybedilmesi.

#### Değerlendirme

Olasılık: 4.

Etki: 5.

**Risk puanı = 4 × 5 = 20**

Örnek risk matrisine göre sonuç kritik seviyededir.

#### Risk işleme önerisi

Yedekleme politikasının oluşturulması.

Kritik verilerin düzenli yedeklenmesi.

Yedek erişimlerinin sınırlandırılması.

Çevrimdışı veya değiştirilemez yedek seçeneklerinin değerlendirilmesi.

Geri yükleme testlerinin yapılması.

Bu faaliyetlerin tamamlanmasının ardından risk yeniden değerlendirilmelidir.

### \12. Doğal Risk, Mevcut Risk ve Kalan Risk Nedir?

Risk değerlendirmesinde farklı risk durumları kullanılabilir.

#### Doğal risk (Inherent Risk)

Belirlenen risk senaryosunun, değerlendirme metodolojisinde tanımlanan koruma varsayımları altında, ilgili kontroller dikkate alınmadan önceki risk seviyesidir.

#### Mevcut risk (Current Risk)

Hâlihazırda uygulanmakta olan kontroller dikkate alındığında ortaya çıkan risk seviyesidir.

#### Kalan risk (Residual Risk)

Planlanan risk işleme faaliyetleri uygulandıktan sonra geriye kalan risk seviyesidir.

#### Örnek

**Risk:** VPN hesabının ele geçirilmesi.

**Doğal risk:** 20.

**Mevcut risk:** 16.

**Planlanan kontroller:** Phishing-resistant MFA, erişim kısıtlaması ve izleme.

**Hedeflenen kalan risk:** 6.

Buradaki değerler örnektir.

Kalan riskin 6 seviyesine düşeceği yalnızca kontrol satın alınmasıyla varsayılamaz.

Kontroller uygulandıktan sonra etkinlikleri doğrulanmalı ve risk yeniden değerlendirilmelidir.

### \13. Risk Kabul Kriterleri Nasıl Belirlenir?

Kuruluşlar bütün riskleri sıfıra indiremeyeceğinden kabul edilebilir risk seviyelerini tanımlamalıdır.

#### Risk kabul kriterleri

Risk seviyesi.

İş etkisi.

Yasal yükümlülükler.

Sözleşmesel gereksinimler.

Mevcut güvenlik kontrolleri.

Risk işleme maliyeti.

Kurumsal risk iştahı.

#### Örnek politika

Düşük riskler tanımlanan yetkilerle kabul edilebilir.

Orta riskler için risk sahibi değerlendirmesi gerekir.

Yüksek riskler için üst yönetim onayı veya risk işleme planı gerekebilir.

Kritik risklerde acil aksiyon ve üst yönetim değerlendirmesi uygulanabilir.

Bu model yalnızca örnektir.

Kuruluşun gerçek yetki matrisi ve risk kabul kriterleri açıkça tanımlanmalıdır.

#### Kritik nokta

Yasal bir gereksinimin ihlal edilmesi yalnızca risk kabul formu imzalanarak meşru hale getirilemez.

Risk kabul kararları uygulanabilir yükümlülüklerle uyumlu olmalıdır.

### \14. Risk Sahibi Kimdir?

Risk sahibi, belirli bir riskin yönetilmesine ilişkin yetki ve sorumluluğa sahip kişi veya roldür.

ISO/IEC 27001 risk sahiplerinin belirlenmesini gerektirir.

#### Örnek

**Risk:** Müşteri veritabanına yetkisiz erişim.

**Risk sahibi:** İlgili iş süreci veya hizmetten sorumlu yönetici.

**Kontrol uygulayıcısı:** Veritabanı ve IAM ekipleri.

**İzleme:** Bilgi Güvenliği / SOC.

**Risk kabulü:** Kurumsal yetki matrisinde tanımlanan yetkili.

Risk sahibinin belirlenmesi, bulguların yalnızca BT ekiplerinde beklemesini önlemeye yardımcı olur.

### \15. ISO 27001 Risk Envanteri Nasıl Hazırlanır?

Risk envanteri, tanımlanan risklerin merkezi olarak kayıt altına alındığı çalışma alanıdır.

Excel, GRC yazılımı veya kurumsal risk yönetim platformu kullanılabilir.

#### Önerilen risk envanteri alanları

Risk ID.

İş süreci.

Varlık.

Risk senaryosu.

Tehdit.

Zafiyet veya risk kaynağı.

Olası sonuç.

Risk sahibi.

Mevcut kontroller.

Olasılık.

Etki.

Risk seviyesi.

Risk işleme kararı.

Planlanan aksiyon.

Aksiyon sahibi.

Hedef tarih.

Kalan risk.

Risk kabul durumu.

Son değerlendirme tarihi.

#### Örnek risk kayıtları

| Risk ID | Risk senaryosu | Olasılık | Etki | Puan |
| --- | --- | --- | --- | --- |
| R-001 | VPN hesabının ele geçirilmesi | 4 | 5 | 20 |
| R-002 | Kritik sunucuda yama eksikliği | 4 | 4 | 16 |
| R-003 | Yedeklerin geri yüklenememesi | 3 | 5 | 15 |
| R-004 | Yetkisiz bulut dosya paylaşımı | 3 | 4 | 12 |
| R-005 | Kaynak kodda gizli anahtar bulunması | 4 | 4 | 16 |
| R-006 | Tedarikçi hesabının kötüye kullanılması | 3 | 4 | 12 |

Bu kayıtlar örnek senaryolardır.

Gerçek puanlar kurumun sistemleri, tehdit koşulları ve mevcut kontrolleri dikkate alınarak belirlenmelidir.

### \16. Risk İşleme Planı Nasıl Hazırlanır?

Risk işleme planı, belirlenen risklerin hangi faaliyetlerle yönetileceğini açıklar.

Planın uygulanabilir ve takip edilebilir olması gerekir.

#### Temel alanlar

Risk ID.

Risk seviyesi.

Risk işleme seçeneği.

Planlanan kontrol.

Sorumlu.

Kaynak ihtiyacı.

Hedef tarih.

Başarı kriteri.

Doğrulama yöntemi.

Kalan risk değerlendirmesi.

#### Örnek

| Alan | Açıklama |
| --- | --- |
| Risk ID | R-001 |
| Risk | VPN hesabının ele geçirilmesi |
| Mevcut risk | Kritik |
| İşleme yöntemi | Azaltma |
| Kontrol | MFA ve erişim kısıtlaması |
| Sorumlu | IAM / Ağ Güvenliği |
| Hedef | Kritik hesapların tamamında MFA |
| Kanıt | MFA kapsam raporu ve erişim testleri |
| Kalan risk | Uygulama sonrası değerlendirilecek |

Risk işleme planında yalnızca “MFA uygulanacak” ifadesinin bulunması yeterli olmayabilir.

Hangi hesaplarda, ne zaman ve nasıl doğrulanacağı belirlenmelidir.

### \17. Risk İşleme Seçenekleri Nelerdir?

Riskler için farklı işleme seçenekleri kullanılabilir.

#### Risk azaltma

Güvenlik kontrolleriyle riskin düşürülmesidir.

Örnek: İnternete açık yönetim arayüzünün kapatılması.

#### Riskten kaçınma

Risk oluşturan faaliyetin sonlandırılması veya değiştirilmesidir.

Örnek: Güvenli hale getirilemeyen eski bir hizmetin kullanım dışı bırakılması.

#### Risk paylaşma

Belirli risk sonuçlarının sözleşmesel, operasyonel veya finansal mekanizmalarla paylaşılmasıdır.

Örnek: Siber sigorta.

#### Risk kabulü

Riskin uygun yetkiyle ve belirlenen kriterlere göre kabul edilmesidir.

Örnek: Düşük etkili ve uygun şekilde izlenen bir riskin kabul edilmesi.

Risk işleme kararlarının gerekçeleri kayıt altına alınmalıdır.

### \18. ISO 27001 SoA Nedir?

**Uygulanabilirlik Bildirgesi (Statement of Applicability – SoA), bilgi güvenliği risklerini işlemek için gerekli kontrolleri, bu kontrollerin seçilme gerekçelerini, uygulanma durumlarını ve Ek A kontrollerinden hariç tutulanların gerekçelerini gösteren BGYS dokümanıdır.**

ISO/IEC 27001:2022 Madde 6.1.3 kapsamında önemli bir gereksinimdir.

SoA, risk değerlendirmesi ve risk işleme planıyla ilişkili olmalıdır.

#### SoA'nın cevaplaması gereken sorular

Hangi kontroller gerekli?

Bu kontroller neden seçildi?

Kontroller uygulanıyor mu?

Ek A'daki hangi kontroller hariç tutuldu?

Hariç tutma gerekçeleri neler?

#### Önemli ayrım

SoA, yalnızca 93 Ek A kontrolünün işaretlendiği tablo olarak görülmemelidir.

Risklerin işlenmesi için Ek A dışında gerekli görülen kontroller de bulunabilir.

### \19. SoA Nasıl Hazırlanır?

SoA hazırlama süreci risk değerlendirmesi ve risk işleme kararlarıyla birlikte yürütülmelidir.

#### Adım 1: Riskleri belirleyin

Bilgi güvenliği riskleri kayıt altına alınır.

#### Adım 2: Risk işleme kararlarını oluşturun

Risklerin nasıl ele alınacağı belirlenir.

#### Adım 3: Gerekli kontrolleri seçin

Risk işleme için uygun kontroller belirlenir.

#### Adım 4: Ek A ile karşılaştırın

Gerekli kontrollerin atlanmadığından emin olmak için Ek A referans kontrolleriyle karşılaştırma yapılır.

#### Adım 5: Uygulanabilirlik gerekçelerini oluşturun

Kontrollerin neden gerekli olduğu açıklanır.

#### Adım 6: Uygulama durumunu belirleyin

Kontrolün uygulanıp uygulanmadığı kayıt altına alınır.

#### Adım 7: Hariç tutma gerekçelerini açıklayın

Ek A kontrollerinden hariç tutulanlar için gerekçeler belirtilir.

#### Adım 8: Güncel tutun

Risklerde, kapsamda veya kontrollerde önemli değişiklik olduğunda SoA gözden geçirilir.

### \20. Örnek ISO 27001 SoA Tablosu

Aşağıdaki tablo, uygulama yaklaşımını göstermek amacıyla hazırlanmıştır.

| Kontrol | Kontrol konusu | Gerekçe | Durum |
| --- | --- | --- | --- |
| A.5.9 | Bilgi ve diğer ilişkili varlıkların envanteri | Varlık görünürlüğü | Uygulanıyor |
| A.5.15 | Erişim kontrolü | Yetkisiz erişimin azaltılması | Uygulanıyor |
| A.5.23 | Bulut hizmetleri güvenliği | Bulut risklerinin yönetimi | Kısmi |
| A.8.8 | Teknik zafiyet yönetimi | Bilinen açıkların azaltılması | Uygulanıyor |
| A.8.12 | Veri sızıntısının önlenmesi | Hassas veri koruması | Planlandı |
| A.8.13 | Bilgi yedekleme | Veri kurtarma | Uygulanıyor |
| A.8.15 | Loglama | Olay izlenebilirliği | Uygulanıyor |
| A.8.28 | Güvenli kodlama | Yazılım güvenliği | Kısmi |

Buradaki “kısmi” ve “planlandı” ifadeleri örnek iç takip durumlarıdır.

SoA'nın standartta gerekli görülen uygulama durumu bilgisini açıkça karşılaması gerekir.

#### Önemli nokta

Bir kontrolün gerekli olup henüz uygulanmamış olması, otomatik olarak hariç tutulabileceği anlamına gelmez.

Bu durumda uygulama eksikliği ve risk işleme planı uygun şekilde yönetilmelidir.

### \21. SoA'da Kontrol Hariç Tutma Nasıl Yapılır?

Ek A'daki bazı kontrollerin belirli bir kuruluşun kapsamına uygulanabilir olmadığı değerlendirilebilir.

Ancak hariç tutma kararları gerekçelendirilmelidir.

#### Örnek senaryo

Bir kuruluşun belirli bir fiziksel faaliyet alanı bulunmadığı varsayılsın.

Bu durumda ilgili fiziksel kontrolün uygulanabilirliği değerlendirilebilir.

Ancak kuruluşun uzaktan çalışan personeli, cihazları, bulut altyapısı veya tedarikçi bağımlılıkları bulunuyorsa fiziksel güvenlik risklerinin tamamen ortadan kalktığı varsayılamaz.

#### Yanlış yaklaşım

“Bulut kullanıyoruz, fiziksel güvenlik kontrollerinin tamamı uygulanmaz.”

#### Daha doğru yaklaşım

“İlgili fiziksel güvenlik kontrollerinin uygulanabilirliği BGYS kapsamı, varlıklar, çalışma modeli ve tedarikçi sorumlulukları dikkate alınarak ayrı ayrı değerlendirilmiştir.”

Hariç tutma gerekçeleri risk değerlendirmesiyle tutarlı olmalıdır.

### \22. Risk Envanteri ile SoA Arasındaki İlişki

Risk envanteri ve SoA birbirinden bağımsız iki belge değildir.

Risk envanteri hangi risklerin bulunduğunu gösterir.

Risk işleme planı bu riskler için ne yapılacağını belirler.

SoA ise gerekli kontrollerin seçilme gerekçelerini ve uygulama durumlarını gösterir.

#### Örnek ilişki

**Risk:** R-003 – Kritik verilerin geri yüklenememesi.

**Risk işleme kararı:** Azaltma.

**Planlanan faaliyet:** Yedekleme ve geri yükleme testleri.

**İlgili Ek A kontrolü:** A.8.13 – Bilgi yedekleme.

**SoA gerekçesi:** Kritik iş verilerinin kaybı ve erişilemezlik riskinin azaltılması.

**Kanıt:** Yedekleme politikası ve geri yükleme testi sonuçları.

Bu ilişki sayesinde denetim sırasında kontrolün neden seçildiği açıklanabilir.

### \23. Risk Analizinde Teknik Zafiyet Verileri Nasıl Kullanılır?

Zafiyet tarama sonuçları risk değerlendirmesine önemli girdi sağlayabilir.

Ancak tarama raporundaki her bulgu otomatik olarak ayrı bir kurumsal risk kaydı oluşturmak zorunda değildir.

Benzer bulgular uygun risk senaryoları altında değerlendirilebilir.

#### Kullanılabilecek veriler

CVSS puanı.

Zafiyetin istismar edilebilirliği.

CISA KEV gibi doğrulanmış istismar bilgileri.

EPSS gibi olasılıksal önceliklendirme göstergeleri.

Varlığın internete açıklığı.

Varlık kritiklik seviyesi.

Mevcut güvenlik kontrolleri.

#### Örnek

CVSS puanı yüksek bir zafiyet, dış erişime kapalı ve güçlü segmentasyonla korunan bir sistemde bulunabilir.

Başka bir sistemde daha düşük CVSS puanına sahip ancak internete açık ve aktif istismar edilen bir zafiyet bulunabilir.

Kurumsal önceliklendirme yalnızca CVSS değerine göre yapılmamalıdır.

Gerçek tehdit maruziyeti ve iş etkisi birlikte değerlendirilmelidir.

### \24. Sızma Testi Bulguları Risk Analizine Nasıl Aktarılır?

Sızma testleri teknik güvenlik zayıflıklarının gerçek saldırı senaryolarıyla değerlendirilmesine yardımcı olur.

Test sonuçları BGYS risk yönetimi sürecine aktarılabilir.

#### Örnek

Sızma testinde bir web uygulamasında yetki kontrolü eksikliği tespit edildi.

**Teknik bulgu:** Broken Access Control.

**Risk senaryosu:** Yetkisiz kullanıcının başka müşterilere ait kayıtlara erişmesi.

**İş etkisi:** Hassas veri açıklanması ve sözleşmesel sonuçlar.

**Risk sahibi:** Uygulama veya iş süreci sahibi.

**Kontrol:** Yetkilendirme mekanizmasının düzeltilmesi.

**Doğrulama:** Yeniden sızma testi.

#### Kritik nokta

Teknik bulgunun kapatılması ile riskin kabul edilebilir seviyeye düşmesi aynı şey olmayabilir.

İlgili risk senaryosu yeniden değerlendirilmelidir.

### \25. ISO 27001 Risk Analizinde Bulut Güvenliği

Bulut altyapıları farklı risk senaryoları oluşturabilir.

#### Örnek riskler

Herkese açık depolama alanları.

Gereğinden geniş IAM yetkileri.

Yetkisiz OAuth uygulamaları.

Bulut yönetici hesaplarının ele geçirilmesi.

Yanlış ağ güvenliği yapılandırmaları.

Yetersiz loglama.

Kontrolsüz veri paylaşımı.

#### Örnek senaryo

Bir bulut depolama alanının yanlışlıkla herkese açık hale getirilmesi.

**Tehdit:** Yetkisiz veri erişimi.

**Zayıflık:** Yanlış erişim yapılandırması.

**Etki:** Hassas verilerin açıklanması.

**Kontrol:** Güvenli varsayılan yapılandırmalar, sürekli yapılandırma izleme ve erişim denetimi.

#### Sorumluluk modeli

Bulut güvenliğinde hizmet sağlayıcının ve müşterinin sorumlulukları hizmet modeline göre değişebilir.

Risk değerlendirmesi bu ayrımı dikkate almalıdır.

### \26. ISO 27001 Risk Analizinde Tedarikçi Güvenliği

Tedarikçiler kurumsal bilgi güvenliği üzerinde doğrudan etki oluşturabilir.

Özellikle kritik sistemlere erişen veya hassas veri işleyen tedarikçiler değerlendirilmelidir.

#### Örnek riskler

Tedarikçi hesabının ele geçirilmesi.

Kontrolsüz uzaktan erişim.

Tedarikçi kaynaklı veri ihlali.

Hizmet kesintisi.

Yetersiz güvenlik yükümlülükleri.

#### Değerlendirme kriterleri

Tedarikçinin işlediği veri türleri.

Erişim yetkileri.

Hizmetin kritiklik seviyesi.

Güvenlik kontrolleri.

Sözleşmesel yükümlülükler.

Olay bildirim süreçleri.

İş sürekliliği kabiliyeti.

#### Örnek kontrol

Tedarikçi erişimlerinin belirli sürelerle sınırlandırılması ve MFA ile korunması.

Tedarikçi güvenliği, yalnızca sözleşme imzalanmasıyla tamamlanan bir süreç değildir.

### \27. ISO 27001 Risk Analizinde İnsan Kaynaklı Riskler

İnsan kaynaklı riskler teknik kontrollerle birlikte değerlendirilmelidir.

#### Örnek riskler

Phishing.

Sosyal mühendislik.

Yanlış alıcıya veri gönderimi.

Yetki kötüye kullanımı.

Hatalı sistem yapılandırması.

İşten ayrılan personelin erişiminin açık kalması.

#### Örnek senaryo

Bir çalışanın sahte giriş sayfasına kurumsal kimlik bilgilerini girmesi.

**Olası sonuç:** Hesap ele geçirilmesi.

**Kontroller:** Phishing-resistant MFA, e-posta güvenliği, farkındalık ve anormal oturum izleme.

#### Önemli yaklaşım

Risklerin yalnızca kullanıcı hatası olarak sınıflandırılması yeterli değildir.

Sistem tasarımının ve güvenlik kontrollerinin insan hatalarını nasıl sınırlandırdığı da değerlendirilmelidir.

### \28. Yapay Zekâ Sistemleri ISO 27001 Risk Analizine Nasıl Dahil Edilir?

Kuruluşların yapay zekâ sistemleri kullanması yeni bilgi güvenliği riskleri oluşturabilir.

#### Örnek riskler

Hassas verilerin yetkisiz AI servislerine aktarılması.

Prompt Injection.

Kontrolsüz AI Agent işlemleri.

Model erişim anahtarlarının sızması.

RAG veri kaynaklarının manipüle edilmesi.

Yapay zekâ tedarikçisi kaynaklı veri güvenliği sorunları.

#### Örnek risk senaryosu

Çalışanların gizli müşteri dokümanlarını onaylanmamış yapay zekâ hizmetlerine yüklemesi.

**Risk kaynağı:** Kontrolsüz Shadow AI kullanımı.

**Olası sonuç:** Hassas bilgilerin yetkisiz üçüncü taraf sistemlerine aktarılması.

**Kontrol:** Onaylı AI hizmetleri, veri sınıflandırma, DLP ve AI Gateway politikaları.

#### ISO/IEC 42001 ilişkisi

Yapay zekâ yönetişimi ve yapay zekâya özgü etkilerin yönetilmesi için ISO/IEC 42001 ayrıca değerlendirilebilir.

ISO/IEC 27001 bilgi güvenliği risklerinin yönetilmesini desteklerken ISO/IEC 42001 daha geniş yapay zekâ yönetimi gereksinimlerini ele alır.

### \29. Risk Analizi Ne Sıklıkla Güncellenmelidir?

ISO/IEC 27001 risk değerlendirmelerinin planlanan aralıklarla ve önemli değişiklikler ortaya çıktığında gerçekleştirilmesini gerektirir.

Bütün kurumlar için aynı sabit değerlendirme sıklığı zorunlu tutulmaz.

#### Yeniden değerlendirme gerektirebilecek durumlar

Yeni uygulama devreye alınması.

Bulut altyapısına geçiş.

Kritik güvenlik olayı.

Yeni tedarikçi entegrasyonu.

Önemli organizasyonel değişiklik.

Yeni yasal yükümlülük.

Kritik güvenlik açığı.

Yeni yapay zekâ sisteminin kullanılması.

İş sürekliliği mimarisinin değiştirilmesi.

#### Örnek yaklaşım

Kapsamlı risk değerlendirmesi yıllık planlanabilir.

Kritik sistemlerde daha sık değerlendirme yapılabilir.

Önemli değişiklikler ise planlanan periyottan bağımsız olarak risk değerlendirmesini tetikleyebilir.

Bu yaklaşım kurumun risk profiline göre uyarlanmalıdır.

### \30. Risk Analizi Denetiminde Hangi Kanıtlar İstenebilir?

ISO/IEC 27001 denetiminde risk yönetimi sürecinin yalnızca dokümante edilmiş olması değil, uygulanması da değerlendirilir.

#### Örnek kanıtlar

Risk değerlendirme metodolojisi.

Risk kabul kriterleri.

Risk envanteri.

Risk değerlendirme sonuçları.

Risk işleme planı.

SoA.

Risk sahibi kayıtları.

Risk işleme onayları.

Kalan risk değerlendirmeleri.

Kontrol uygulama kanıtları.

Yönetim kararları.

Güncelleme kayıtları.

#### Örnek denetim soruları

Bu risk nasıl belirlendi?

Risk sahibi kim?

Olasılık neden 4 seçildi?

Hangi mevcut kontroller dikkate alındı?

Bu kontrol neden gerekli?

Risk işleme faaliyetinin tamamlandığı nasıl doğrulandı?

Kalan risk kim tarafından kabul edildi?

Risk yönetimi sürecinin bu sorulara tutarlı cevap verebilmesi gerekir.

### \31. ISO 27001 Risk Analizinde En Sık Yapılan 10 Hata

#### \1. Başka kurumun risk envanterini aynen kullanmak

Her kuruluşun varlıkları, süreçleri ve tehdit maruziyeti farklıdır.

#### \2. Bütün risklere aynı puanı vermek

Riskler gerçek koşullara göre değerlendirilmelidir.

#### \3. Risk sahibini belirlememek

Sorumluluğu olmayan risklerin yönetilmesi güçleşir.

#### \4. Yalnızca teknik risklere odaklanmak

İnsan, süreç, fiziksel güvenlik ve tedarikçi riskleri de önemlidir.

#### \5. Risk analizini yılda bir kez hazırlayıp güncellememek

Önemli değişikliklerde değerlendirme yapılmalıdır.

#### \6. Risk işleme planını oluşturmamak

Risk puanlaması tek başına risk yönetimi değildir.

#### \7. Kalan riski otomatik düşürmek

Kontrollerin etkinliği doğrulanmalıdır.

#### \8. SoA'yı risk işleme kararlarından bağımsız hazırlamak

Kontrol seçimleri gerekçelendirilmelidir.

#### \9. Risk kabulünü yetkisiz kişilere yaptırmak

Yetki ve sorumluluklar açık olmalıdır.

#### \10. Risk analizini yönetim kararlarına dahil etmemek

Risk değerlendirmesi kaynak tahsisini ve güvenlik önceliklerini desteklemelidir.

### \32. ISO 27001 Risk Analizi ile ISO/IEC 27005 İlişkisi

ISO/IEC 27005, bilgi güvenliği risk yönetimine ilişkin rehber sunar.

ISO/IEC 27001 risk yönetimi gereksinimlerini belirlerken ISO/IEC 27005 uygulama yaklaşımının geliştirilmesinde kullanılabilir.

#### ISO/IEC 27005'in katkı sağlayabileceği alanlar

Risk yönetimi bağlamı.

Risk tanımlama.

Risk analizi.

Risk değerlendirme.

Risk işleme.

Risk iletişimi.

Risk izleme ve gözden geçirme.

#### Önemli ayrım

ISO/IEC 27001 belgelendirmesi için ISO/IEC 27005'in birebir belirli bir yönteminin uygulanması zorunlu değildir.

Kuruluş uygun bir risk değerlendirme metodolojisi seçebilir.

### \33. ISO 27001 Risk Analizi ile NIST CSF 2.0 İlişkisi

NIST Cybersecurity Framework 2.0, siber güvenlik risklerinin yönetilmesini destekleyen altı fonksiyon içerir.

GOVERN.

IDENTIFY.

PROTECT.

DETECT.

RESPOND.

RECOVER.

#### Örnek eşleştirme

Risk yönetişimi GOVERN ile ilişkilidir.

Varlık ve risk belirleme IDENTIFY kapsamında değerlendirilebilir.

Risk azaltıcı kontroller PROTECT ile ilişkilidir.

Güvenlik izleme DETECT fonksiyonunu destekler.

Olay müdahale RESPOND kapsamında ele alınır.

Kurtarma planları RECOVER ile ilişkilidir.

ISO/IEC 27001 ve NIST CSF 2.0 birlikte kullanılabilir.

Ancak biri diğerinin otomatik eşdeğeri değildir.

### \34. Risk Analizi ile İş Sürekliliği Arasındaki İlişki

Bilgi güvenliği risklerinin önemli bir bölümü hizmetlerin erişilebilirliğini etkileyebilir.

Bu nedenle risk analizi iş sürekliliği süreçleriyle ilişkilendirilmelidir.

#### Örnek senaryolar

Veri merkezi kesintisi.

Fidye yazılımı saldırısı.

Kritik bulut hizmetinin erişilemez hale gelmesi.

Yedekleme sisteminin çalışmaması.

Tedarikçi kaynaklı hizmet kesintisi.

#### İş Etki Analizi (BIA)

İş Etki Analizi, kritik süreçlerin kesintiye uğraması durumunda oluşabilecek sonuçları değerlendirmeye yardımcı olur.

BIA sonuçları risk değerlendirmesine önemli girdiler sağlayabilir.

#### Örnek

Kritik ödeme hizmetinin dört saatlik kesintisi, kurumun faaliyetlerine göre yüksek iş etkisi oluşturabilir.

Ancak bu süre ve etki her kurum için aynı değildir.

İş sürekliliği hedefleri kurumsal ihtiyaçlara göre belirlenmelidir.

### \35. Risk Analizi Sonuçları Yönetim Kuruluna Nasıl Sunulmalıdır?

Üst yönetim raporları yalnızca teknik risk puanlarından oluşmamalıdır.

Risklerin iş etkisi ve alınması gereken kararlar açık biçimde gösterilmelidir.

#### Önerilen yönetim raporu

Toplam değerlendirilen risk sayısı.

Kritik risk sayısı.

Yüksek risk sayısı.

Risk işleme faaliyetlerinin durumu.

Hedef süresi aşılmış aksiyonlar.

Kalan riskler.

Risk kabul kararları.

Kaynak ihtiyaçları.

Öncelikli yatırım alanları.

#### Örnek yönetim özeti

“Kurumsal uzaktan erişim altyapısında MFA kapsamının yetersiz olması nedeniyle yetkisiz erişim riski yüksek seviyede değerlendirilmiştir. Kritik hesaplarda MFA uygulamasının tamamlanması ve erişim kayıtlarının merkezi olarak izlenmesi önerilmektedir.”

Bu ifade yalnızca “Risk puanı 20” bilgisinden daha fazla karar desteği sağlar.

### \36. ISO 27001 Risk Yönetimi KPI'ları

Risk yönetimi sürecinin etkinliği ölçülebilir göstergelerle takip edilebilir.

#### Risk değerlendirme kapsamı

Değerlendirilen kritik iş süreçlerinin toplam kritik süreçlere oranı.

#### Risk işleme tamamlama oranı

Tamamlanan risk işleme faaliyetlerinin planlanan faaliyetlere oranı.

#### Hedef süresi aşılmış riskler

Belirlenen hedef tarihi geçmiş açık risk işleme faaliyetlerinin sayısı.

#### Risk kabul gözden geçirme oranı

Planlanan dönemde yeniden değerlendirilen risk kabul kararlarının oranı.

#### Kritik risk azaltma oranı

Başlangıçta kritik seviyede bulunan ve doğrulanmış kontrollerle daha düşük seviyeye indirilen risklerin oranı.

#### Önemli nokta

Risk sayısının azalması her zaman güvenliğin arttığı anlamına gelmez.

Risklerin envanterden çıkarılması veya görünürlüğün azalması da benzer sonuç üretebilir.

Bu nedenle metrikler bağlamıyla birlikte yorumlanmalıdır.

### \37. ISO 27001 Risk Yönetiminde Otomasyon

Büyük kurumlarda yüzlerce veya binlerce risk kaydı bulunabilir.

Manuel takip süreçleri zamanla yetersiz hale gelebilir.

#### Otomasyon alanları

Varlık envanteri entegrasyonu.

Zafiyet verilerinin ilişkilendirilmesi.

Risk sahibi atama.

Aksiyon takibi.

Hedef tarih uyarıları.

Kontrol kanıtlarının toplanması.

Yönetim raporlaması.

Risk değişiklik geçmişi.

#### Örnek

Bir zafiyet yönetimi platformunda kritik güvenlik açığı tespit edildiğinde ilgili varlığın sahibi belirlenebilir.

Bulguyla ilişkili risk kaydı oluşturulabilir veya mevcut kayıt güncellenebilir.

Aksiyon ilgili ekibe atanabilir.

Düzeltme sonrası doğrulama sonucu kayda eklenebilir.

#### Dikkat edilmesi gerekenler

Otomatik risk puanları uzman değerlendirmesinin yerine geçmemelidir.

Veri kalitesi, yanlış pozitifler ve iş bağlamı dikkate alınmalıdır.

### \38. Örnek Uygulama: 100 Çalışanlı Kurumda Risk Analizi

100 çalışanı bulunan, hibrit çalışma modeli kullanan bir kuruluş düşünelim.

#### Altyapı

Active Directory.

Microsoft 365.

VPN.

Firewall.

Dosya sunucuları.

ERP.

Müşteri veritabanı.

Yedekleme altyapısı.

Bulut uygulamaları.

#### İlk değerlendirme

Kritik sistemler belirlenir.

Kullanıcı ve yönetici hesapları incelenir.

İnternete açık servisler değerlendirilir.

Yedekleme ve geri yükleme süreçleri incelenir.

Bulut erişimleri kontrol edilir.

#### Örnek riskler

| Risk | İlk değerlendirme | Önerilen kontrol |
| --- | --- | --- |
| Yönetici hesabında MFA eksikliği | Kritik | MFA ve erişim kısıtlaması |
| Yedek geri yükleme testinin bulunmaması | Yüksek | Düzenli kurtarma testi |
| Destek dışı işletim sistemi | Yüksek | Güncelleme veya izolasyon |
| Kontrolsüz SaaS paylaşımı | Yüksek | Erişim ve veri paylaşım politikası |
| Tedarikçi VPN hesabı | Orta/Yüksek | Süreli erişim ve izleme |

Risk seviyeleri örnek niteliğindedir.

Gerçek değerlendirme mevcut kontroller ve iş etkisi üzerinden yapılmalıdır.

#### Çıktılar

Risk envanteri.

Risk işleme planı.

SoA.

Önceliklendirilmiş iyileştirme listesi.

Yönetim raporu.

Bu çıktılar BGYS'nin uygulanabilir hale gelmesine katkı sağlar.

### \39. ISO 27001 Risk Analizi İçin 30 Günlük Çalışma Planı

#### Gün 1–5: Hazırlık

BGYS kapsamının incelenmesi.

Risk metodolojisinin belirlenmesi.

Risk sahiplerinin tanımlanması.

#### Gün 6–10: Varlık ve Süreç Analizi

Kritik varlıkların belirlenmesi.

İş süreçlerinin değerlendirilmesi.

Tedarikçi bağımlılıklarının incelenmesi.

#### Gün 11–20: Risk Değerlendirmesi

Risk senaryolarının oluşturulması.

Olasılık ve etki puanlaması.

Mevcut kontrollerin değerlendirilmesi.

Risklerin önceliklendirilmesi.

#### Gün 21–25: Risk İşleme

Kontrol seçimleri.

Risk işleme planı.

Sorumluluklar.

Hedef tarihler.

#### Gün 26–30: SoA ve Yönetim Değerlendirmesi

SoA'nın hazırlanması.

Risk sahipleriyle doğrulama.

Yönetim değerlendirmesi.

Risk kabul ve işleme kararlarının kayıt altına alınması.

Bu süre örnek planlamadır.

Karmaşık altyapılarda çalışma daha uzun sürebilir.

### \40. ISO 27001 Risk Analizi Öncesi Kontrol Listesi

- BGYS kapsamı tanımlandı mı?
- Risk değerlendirme metodolojisi hazır mı?
- Risk kabul kriterleri belirlendi mi?
- Risk sahipleri tanımlandı mı?
- Kritik iş süreçleri belirlendi mi?
- Varlık envanteri güncel mi?
- Tehdit senaryoları oluşturuldu mu?
- Mevcut kontroller değerlendirildi mi?
- Olasılık kriterleri tanımlandı mı?
- Etki kriterleri tanımlandı mı?
- Risk puanlama yöntemi tutarlı mı?
- Risk işleme seçenekleri değerlendirildi mi?
- Risk işleme planı hazırlandı mı?
- Kontrol sorumluları belirlendi mi?
- Hedef tarihler tanımlandı mı?
- SoA risk işleme kararlarıyla ilişkilendirildi mi?
- Kalan risk değerlendirmesi planlandı mı?
- Risk kabul yetkileri tanımlandı mı?
- Risk güncelleme koşulları belirlendi mi?
- Denetim kanıtları yönetiliyor mu?

Bu kontrol listesi ISO/IEC 27001 risk yönetimi uygulamalarına hazırlık için kullanılabilir.

### \41. SECURESYS ISO 27001 Risk Analizi ve BGYS Danışmanlığı

SECURESYS, kurumsal bilgi güvenliği çalışmalarında risk bazlı değerlendirme ve teknik doğrulama yaklaşımını esas alır.

ISO/IEC 27001 risk analizi ve BGYS danışmanlığı çalışmalarında kurumun mevcut altyapısı, iş süreçleri ve güvenlik gereksinimleri birlikte ele alınabilir.

#### Risk değerlendirme metodolojisi

Kuruluşun faaliyetlerine uygun risk kriterlerinin ve değerlendirme yönteminin oluşturulması desteklenir.

#### Kurumsal risk envanteri

Bilgi güvenliği risklerinin tanımlanması, kayıt altına alınması ve önceliklendirilmesi sağlanır.

#### Risk işleme planı

Belirlenen riskler için uygulanabilir teknik ve idari kontrol önerileri geliştirilir.

#### SoA hazırlama

ISO/IEC 27001:2022 Ek A kontrolleri risk işleme kararlarıyla ilişkilendirilir.

#### Teknik güvenlik değerlendirmesi

Sistem, ağ, uygulama ve bulut güvenliği alanlarında teknik doğrulama çalışmaları gerçekleştirilebilir.

#### Sızma testi ve zafiyet yönetimi

Teknik güvenlik bulgularının kurumsal risk yönetimine dahil edilmesi desteklenir.

#### SOC ve güvenlik izleme

Güvenlik olaylarının izlenmesi, değerlendirilmesi ve ilgili risk senaryolarının güncellenmesine katkı sağlanabilir.

#### Yönetim raporlaması

Risk sonuçları teknik ayrıntıların yanında iş etkisi ve öncelikli karar alanlarıyla birlikte raporlanır.

**SECURESYS yaklaşımında risk analizi yalnızca denetim için hazırlanmış bir tablo değil, kurumsal güvenlik yatırımlarını ve iyileştirme faaliyetlerini yönlendiren bir yönetim aracıdır.**

#### Sık Sorulan Sorular (SSS)

#### \1. ISO 27001 risk analizi nedir?

Kuruluşun bilgi güvenliği risklerini belirlemesi, analiz etmesi, değerlendirmesi ve uygun risk işleme kararları oluşturması için yürüttüğü sistematik süreçtir.

#### \2. ISO 27001 risk analizi zorunlu mudur?

Evet. Bilgi güvenliği risk değerlendirmesi ISO/IEC 27001 yönetim sistemi gereksinimlerinin temel bileşenlerinden biridir.

#### \3. ISO 27001 risk analizi nasıl yapılır?

Risk kriterleri belirlenir, riskler tanımlanır, olasılık ve etkiler değerlendirilir, riskler önceliklendirilir ve risk işleme kararları oluşturulur.

#### \4. ISO 27001 risk matrisi kaç seviyeli olmalıdır?

Standart tek bir matris boyutu zorunlu tutmaz. Kuruluş uygun ve tutarlı bir değerlendirme yöntemi belirlemelidir.

#### \5. 5×5 risk matrisi nedir?

Olasılık ve etki için beşer seviyenin kullanıldığı örnek risk değerlendirme aracıdır.

#### \6. Risk puanı nasıl hesaplanır?

Yaygın örnek yöntemlerden biri olasılık ile etki değerlerinin çarpılmasıdır. Ancak ISO/IEC 27001 bu formülü zorunlu kılmaz.

#### \7. Doğal risk nedir?

Değerlendirme metodolojisinde tanımlanan varsayımlar altında, belirli koruma kontrolleri dikkate alınmadan önceki risk seviyesidir.

#### \8. Kalan risk nedir?

Risk işleme faaliyetleri sonrasında geriye kalan risk seviyesidir.

#### \9. Risk sahibi kimdir?

Belirli bir riskin yönetilmesine ilişkin yetki ve sorumluluğu bulunan kişi veya roldür.

#### \10. Risk kabulü kim tarafından yapılır?

Kuruluşun tanımladığı yetki matrisi kapsamında uygun yetkiye sahip kişi veya yönetim tarafından yapılmalıdır.

#### \11. SoA nedir?

Uygulanabilirlik Bildirgesi, gerekli güvenlik kontrollerini, seçilme gerekçelerini, uygulama durumlarını ve Ek A hariç tutma gerekçelerini gösterir.

#### \12. SoA'da 93 kontrolün tamamı bulunmalı mıdır?

Ek A referans kontrollerinin uygulanabilirliği ve hariç tutma gerekçeleri değerlendirilmelidir. Ayrıca risk işleme için gerekli görülen diğer kontroller de dikkate alınmalıdır.

#### \13. ISO 27001 risk analizi yılda bir kez mi yapılmalıdır?

Standart bütün kurumlar için tek bir yıllık sıklık zorunlu tutmaz. Planlanan aralıklarla ve önemli değişikliklerde değerlendirme yapılmalıdır.

#### \14. Sızma testi risk analizinin yerine geçer mi?

Hayır. Sızma testi teknik güvenlik zayıflıklarını değerlendirir. Kurumsal risk analizi ise daha geniş bilgi güvenliği risklerini kapsar.

#### \15. CVSS puanı ISO 27001 risk puanı mıdır?

Hayır. CVSS teknik zafiyet ciddiyetine ilişkin göstergedir. Kurumsal risk değerlendirmesinde iş etkisi ve diğer faktörler ayrıca dikkate alınır.

#### \16. ISO 27001 risk analizi Excel ile yapılabilir mi?

Evet. Excel uygun bir kayıt ve değerlendirme aracı olabilir. Ancak metodolojinin tutarlı uygulanması, kayıtların güncel tutulması ve yetkilendirme önemlidir.

#### \17. ISO 27001 risk analizi ile ISO 27005 aynı şey midir?

Hayır. ISO/IEC 27001 yönetim sistemi gereksinimlerini tanımlar. ISO/IEC 27005 bilgi güvenliği risk yönetimine ilişkin rehber sunar.

#### \18. Risk analizi neden sürekli güncellenmelidir?

Yeni sistemler, tehditler, güvenlik olayları ve organizasyonel değişiklikler risk seviyelerini etkileyebilir.

#### \19. Risk işleme planında neler bulunmalıdır?

Risk, seçilen işleme yöntemi, planlanan kontroller, sorumlular, hedef tarihler ve doğrulama yaklaşımı gibi bilgiler bulunmalıdır.

#### \20. ISO 27001 risk analizi danışmanlığı ne sağlar?

Risk metodolojisinin oluşturulması, risklerin değerlendirilmesi, risk işleme planlarının hazırlanması ve SoA çalışmalarının geliştirilmesine destek sağlar.

### Sonuç: ISO 27001 Risk Analizi, Kurumsal Güvenlik Kararlarının Temelidir

ISO/IEC 27001 risk analizi, yalnızca bilgi güvenliği denetimlerinde sunulacak bir tablo olarak değerlendirilmemelidir.

Doğru uygulandığında kurumun güvenlik önceliklerini belirleyen önemli bir yönetim mekanizmasına dönüşür.

Kritik bilgi varlıkları ve iş süreçleri belirlenmelidir.

Risk senaryoları gerçek kurumsal koşullara göre oluşturulmalıdır.

Olasılık ve etki kriterleri tutarlı uygulanmalıdır.

Mevcut güvenlik kontrolleri değerlendirilmelidir.

Risk işleme kararları açık biçimde tanımlanmalıdır.

SoA, risk işleme süreciyle ilişkili olmalıdır.

Kalan riskler doğrulanmalı ve uygun yetkiyle değerlendirilmelidir.

Risk yönetimi sonuçları üst yönetime anlaşılır biçimde sunulmalıdır.

En önemlisi, risk değerlendirmeleri güncel tutulmalıdır.

**Başarılı bir ISO/IEC 27001 risk analizi, yalnızca hangi risklerin bulunduğunu göstermez; kurumun hangi risk için ne yapması gerektiğini, kimin sorumlu olduğunu ve iyileştirmenin nasıl doğrulanacağını da ortaya koyar.**