ISO 27001:2022 denetimine girecek her BGYS yöneticisinin masasında aynı dosya vardır: risk kaydı (risk register). Bu yazıda sıfırdan kurulabilir, 40+ örnek riskle doldurulmuş, hem Excel’de hem ServiceNow’da çalışan bir BGYS risk kaydı şablonunu anlatıyor; risk puanlama mantığını, matris hesaplamalarını ve denetçi itirazlarına karşı sağlam bir yapıyı adım adım paylaşıyoruz.
BGYS Risk Kaydı Nedir?
BGYS risk kaydı; bir kuruluşun bilgi varlıklarına yönelik tehditleri, zafiyetleri, risk değerlendirme sonuçlarını ve uygulanan kontrolleri tek bir yapılandırılmış belgede toplayan canlı dokümandır. ISO/IEC 27001:2022 standardının madde 6.1.2 (Bilgi güvenliği risk değerlendirme süreci) ve madde 6.1.3 (Bilgi güvenliği risk işleme) şartlarının tek bir dokümanda somutlaşmış halidir.
Hızlı Tanım: Risk kaydı, ISO 27001 denetçisinin ilk 10 dakikada istediği, BGYS’nin “kalbi” sayılan dokümandır. İçinde net bir risk sahibi, ölçülebilir skor, seçilmiş kontrol ve kalan (residual) risk yoksa, sertifika riske girer.
İyi yapılandırılmış bir risk kaydı dört temel soruyu cevaplar: Neyi koruyoruz? (varlık), Neye karşı koruyoruz? (tehdit), Ne kadar hasar görürsek? (etki ve olasılık), Ne yapıyoruz? (kontrol ve işleme planı). Bu dört soruya açık cevap vermeyen bir kayıt, şablon değil görüntüdür.
Risk Kaydının Zorunlu Alan Yapısı
Aşağıdaki 18 alan, ISO 27001:2022 denetimlerinde sorgulanan ve bir risk kaydının eksiksiz sayılabilmesi için içermesi gereken minimum veri setidir. Her alan, hem denetçi sorusuna hem de yönetim raporlamasına hizmet eder.
📋 Risk Kaydı Alan Mimarisi
Bu 18 alanlık mimarinin üç önemli özelliği var: hiyerarşik okunabilir (tanımla → analiz et → işle → izle), denetlenebilir (her alan bir ISO 27001 şartına referans verir) ve aksiyon üretir (kalan skor yönetim kurulu raporlarına doğrudan girer).
5×5 Risk Matrisi ve Puanlama Yöntemi
Risk skorlama için Türkiye’deki BGYS uygulamalarında en çok tercih edilen yöntem 5×5 kalitatif matristir. Olasılık ve etki değerleri 1–5 arasında puanlanır, çarpımları ham risk skorunu verir (1–25 aralığı). Skor ne kadar yüksekse, müdahale önceliği o kadar yüksektir.
🎯 5×5 Bilgi Güvenliği Risk Matrisi
| Olasılık ↓ / Etki → | ETKİ DERECESİ | ||||
|---|---|---|---|---|---|
| 1 Önemsiz |
2 Düşük |
3 Orta |
4 Yüksek |
5 Kritik |
|
| 5 – Kesin | 5 | 10 | 15 | 20 | 25 |
| 4 – Muhtemel | 4 | 8 | 12 | 16 | 20 |
| 3 – Olası | 3 | 6 | 9 | 12 | 15 |
| 2 – Düşük | 2 | 4 | 6 | 8 | 10 |
| 1 – Nadir | 1 | 2 | 3 | 4 | 5 |
Olasılık Kriterleri (1–5)
| Puan | Seviye | Tanım |
|---|---|---|
| 1 | Nadir | 5 yılda bir veya daha seyrek gerçekleşebilir |
| 2 | Düşük | 2–5 yıl içinde gerçekleşme olasılığı var |
| 3 | Olası | Yılda bir kez gerçekleşebilir |
| 4 | Muhtemel | Yılda birden fazla gerçekleşebilir |
| 5 | Kesin | Aylık / sürekli gerçekleşme beklentisi |
Etki Kriterleri (1–5)
| Puan | Finansal Etki | Operasyonel / İtibar Etkisi |
|---|---|---|
| 1 | < 50.000 TL | İç etki, müşteri görünmez |
| 2 | 50.000 – 500.000 TL | Sınırlı hizmet kesintisi (< 4 saat) |
| 3 | 500.000 – 2.5M TL | Müşteri etkisi, SLA ihlali |
| 4 | 2.5M – 10M TL | Kamuya açık olay, basın yansıması |
| 5 | > 10M TL | KVKK cezası, iş sürekliliği tehdidi, lisans kaybı |
40+ Örnek Riskle Hazır Şablon
Aşağıdaki tablo; yazılım, finansal hizmet ve üretim sektörlerindeki orta-büyük ölçekli kuruluşların risk kayıtlarında tekrar eden 42 örneği derliyor. Her risk; ISO 27001:2022 Ek A kontrol numarasıyla eşleştirilmiş ve skorlanmıştır. Şablonunuzu kendi ortamınıza göre uyarlarken skorları sabit almayın; kendi bağlamınıza göre yeniden hesaplayın.
| ID | Risk | Kategori | Ol. | Et. | Skor | Ek A Kontrolü |
|---|---|---|---|---|---|---|
| 🛡️ SİBER GÜVENLİK (11 risk) | ||||||
| R-001 | Oltalama (phishing) yoluyla kurumsal e-posta ele geçirme | Siber | 4 | 4 | 16 | A.6.3, A.8.23 |
| R-002 | Fidye yazılımı (ransomware) ile üretim sistemlerinin şifrelenmesi | Siber | 3 | 5 | 15 | A.8.7, A.8.13 |
| R-003 | Kritik sunucuda yama eksikliği nedeniyle RCE zafiyeti | Siber | 4 | 4 | 16 | A.8.8, A.8.9 |
| R-004 | Web uygulamasında SQL injection ile müşteri veritabanı sızıntısı | Siber | 3 | 5 | 15 | A.8.28, A.8.26 |
| R-005 | DDoS saldırısı ile müşteriye açık servislerin kesintiye uğraması | Siber | 3 | 4 | 12 | A.8.14, A.8.20 |
| R-006 | Ayrıcalıklı hesapların (admin) MFA’sız kullanımı | Siber | 4 | 5 | 20 | A.5.15, A.8.2, A.8.5 |
| R-007 | Zayıf parola politikası nedeniyle kaba kuvvet (brute-force) saldırısı | Siber | 3 | 3 | 9 | A.5.17, A.8.5 |
| R-008 | Güvensiz API entegrasyonu ile yetkisiz veri erişimi | Siber | 3 | 4 | 12 | A.8.21, A.8.26 |
| R-009 | Uç nokta güvenliği eksikliği (EDR olmaması) | Siber | 3 | 4 | 12 | A.8.7, A.8.1 |
| R-010 | Log toplama ve SIEM eksikliği nedeniyle olayın geç tespiti | Siber | 4 | 3 | 12 | A.8.15, A.8.16 |
| R-011 | Şifrelenmemiş yedeklerin sızdırılması | Siber | 2 | 5 | 10 | A.8.13, A.8.24 |
| 🔐 ERİŞİM VE KİMLİK YÖNETİMİ (6 risk) | ||||||
| R-012 | Ayrılan personelin hesabının zamanında devre dışı bırakılmaması | Erişim | 4 | 3 | 12 | A.5.18, A.6.5 |
| R-013 | Paylaşılan (shared) hesap kullanımı | Erişim | 3 | 4 | 12 | A.5.16, A.8.2 |
| R-014 | Erişim haklarının periyodik gözden geçirilmemesi | Erişim | 3 | 3 | 9 | A.5.18 |
| R-015 | Privileged Access Management (PAM) çözümü eksikliği | Erişim | 3 | 5 | 15 | A.8.2, A.8.18 |
| R-016 | Yanlış görev ayrılığı (SoD ihlali) nedeniyle iç suistimal | Erişim | 2 | 4 | 8 | A.5.3 |
| R-017 | Uzaktan çalışma VPN onaylarının izlenmemesi | Erişim | 3 | 3 | 9 | A.6.7, A.8.1 |
| 🔗 TEDARİKÇİ VE ÜÇÜNCÜ TARAF RİSKLERİ (6 risk) | ||||||
| R-018 | Kritik SaaS sağlayıcısının güvenlik ihlali yaşaması (supply chain) | Tedarikçi | 3 | 5 | 15 | A.5.19, A.5.21, A.5.22 |
| R-019 | Tedarikçi sözleşmelerinde bilgi güvenliği maddelerinin eksikliği | Tedarikçi | 3 | 3 | 9 | A.5.20 |
| R-020 | Tedarikçi risk değerlendirmesinin hiç yapılmaması | Tedarikçi | 4 | 3 | 12 | A.5.19 |
| R-021 | Bulut sağlayıcıda KVKK uyumsuz yurt dışı veri aktarımı | Tedarikçi | 4 | 4 | 16 | A.5.23, A.5.34 |
| R-022 | Alt yüklenicilerin (4th party) görünmezliği — Nth-party risk | Tedarikçi | 4 | 4 | 16 | A.5.21, A.5.22 |
| R-023 | Dış yazılım geliştirme ekibinde kaynak kodu sızıntısı | Tedarikçi | 2 | 5 | 10 | A.8.4, A.8.30 |
| ⚖️ UYUM VE HUKUKİ RİSKLER (5 risk) | ||||||
| R-024 | KVKK kapsamında veri ihlali bildirimi süresinin (72 saat) kaçırılması | Uyum | 3 | 5 | 15 | A.5.31, A.5.34, A.6.8 |
| R-025 | VERBİS kayıt ve güncelleme eksikliği | Uyum | 3 | 3 | 9 | A.5.31 |
| R-026 | Fikri mülkiyet haklarının (yazılım lisansı) ihlali | Uyum | 2 | 4 | 8 | A.5.32 |
| R-027 | Sözleşmeli gizlilik (NDA) yükümlülüklerinin ihlali | Uyum | 2 | 4 | 8 | A.6.6 |
| R-028 | Elektronik kanıt saklama (log tutma süresi) mevzuat uyumsuzluğu | Uyum | 3 | 3 | 9 | A.5.33, A.8.15 |
| 👥 İNSAN KAYNAĞI KAYNAKLI RİSKLER (5 risk) | ||||||
| R-029 | Kritik rol çalışanının ani ayrılması ve bilgi kaybı | İK | 3 | 4 | 12 | A.6.1, A.5.9 |
| R-030 | İç tehdit (disgruntled employee) kaynaklı veri ifşası | İK | 2 | 5 | 10 | A.6.4, A.8.10 |
| R-031 | Bilgi güvenliği farkındalık eğitimlerinin yetersizliği | İK | 4 | 3 | 12 | A.6.3 |
| R-032 | İşe alım sürecinde geçmiş doğrulaması yapılmaması | İK | 2 | 3 | 6 | A.6.1 |
| R-033 | Shadow AI: çalışanların izinsiz GenAI araçlarına veri yapıştırması | İK/Siber | 4 | 4 | 16 | A.5.10, A.5.34, A.6.3 |
| 🏢 FİZİKSEL VE ÇEVRESEL RİSKLER (4 risk) | ||||||
| R-034 | Veri merkezinde yangın / su baskını | Fiziksel | 1 | 5 | 5 | A.7.5, A.7.11 |
| R-035 | Ofiste yetkisiz ziyaretçi erişimi | Fiziksel | 3 | 2 | 6 | A.7.2, A.7.6 |
| R-036 | Elektrik kesintisinin UPS/jeneratör eksikliğiyle uzaması | Fiziksel | 2 | 4 | 8 | A.7.11, A.7.12 |
| R-037 | Taşınabilir cihaz (laptop, USB) kaybı veya çalınması | Fiziksel | 3 | 3 | 9 | A.7.9, A.8.24 |
| 🔄 İŞ SÜREKLİLİĞİ RİSKLERİ (3 risk) | ||||||
| R-038 | DR (felaket kurtarma) testinin hiç yapılmamış olması | Süreklilik | 3 | 5 | 15 | A.5.29, A.5.30, A.8.14 |
| R-039 | Yedeklerin düzenli test edilmemesi (restorasyon başarısız olabilir) | Süreklilik | 3 | 5 | 15 | A.8.13 |
| R-040 | Kritik sistemler için RTO/RPO hedeflerinin tanımsız olması | Süreklilik | 3 | 4 | 12 | A.5.29, A.5.30 |
| 🤖 YAPAY ZEKA KAYNAKLI RİSKLER (2 risk) | ||||||
| R-041 | Kurumsal GenAI kullanımında prompt injection saldırıları | AI/Siber | 3 | 4 | 12 | A.5.10, A.8.26 |
| R-042 | AI model çıktılarının önyargı/halüsinasyon içermesi | AI/Uyum | 3 | 3 | 9 | ISO 42001 uyumu |
📊 42 Risk – Kategori Dağılımı
Siber güvenlik en büyük risk kategorisi olsa da; tedarikçi ve uyum riskleri birleştiğinde toplamın %26’sına ulaşıyor. BGYS yöneticileri bu alanları ihmal etmemeli.
ServiceNow Alan Eşlemeleri
ServiceNow GRC (Governance, Risk, Compliance) modülü kullanıyorsanız, Excel şablonundaki alanları ServiceNow tablolarına doğru eşlemek denetim hazırlığınızı otomatikleştirir. Aşağıdaki tablo; yaygın kullanılan sn_risk_risk ve sn_grc_control tablolarına 18 alanın eşlemesini gösteriyor.
| Excel Alan Adı | ServiceNow Tablosu | ServiceNow Alan Adı | Tür |
|---|---|---|---|
| Risk ID | sn_risk_risk | number | String (otomatik) |
| Risk Adı | sn_risk_risk | short_description | String (160) |
| Risk Açıklaması | sn_risk_risk | description | Text |
| Kategori | sn_risk_risk | category | Choice |
| Bilgi Varlığı | sn_risk_risk | asset | Reference (cmdb_ci) |
| Varlık Sahibi | sn_risk_risk | asset_owner | Reference (sys_user) |
| Olasılık | sn_risk_risk | likelihood | Choice (1–5) |
| Etki | sn_risk_risk | impact | Choice (1–5) |
| Ham Skor | sn_risk_risk | inherent_score | Integer (hesaplanır) |
| İşleme Stratejisi | sn_risk_risk | response_strategy | Choice |
| Ek A Kontrolü | sn_grc_control | name / ref_ctrl | Reference (M2M) |
| Kalan Skor | sn_risk_risk | residual_score | Integer |
| Risk Sahibi | sn_risk_risk | owner | Reference (sys_user) |
| Gözden Geçirme Tarihi | sn_risk_risk | review_date | Date |
=OLASILIK*ETKİ formülüyle eşit çıkar. Böylece her iki ortamda tutarlı skor elde edersiniz.
Denetçi Tuzaklarından Kaçınma Rehberi
ISO 27001:2022 gözetim denetimlerinde risk kaydı üzerinden açılan uygunsuzlukların %80’i aşağıdaki sekiz hatadan birine ya da birkaçına dayanır. Her birini tanıyıp önlem alırsanız denetim oturumunuz kısalır ve majör uygunsuzluk riski neredeyse sıfıra iner.
Risk sahibi “Bilgi Güvenliği Ekibi” yazmak
Risk sahibi gerçek bir kişi olmalı — isim soyisim. Ekip adı yazmak, hesap verebilirliği ortadan kaldırır ve denetçi için kırmızı bayraktır.
Skorların hiç güncellenmemesi
1 yıl önce girilmiş ve aynı kalan skorlar; dinamik olmayan bir risk yönetimi göstergesidir. En az 3 ayda bir gözden geçirme izi olmalı.
Kalan (residual) skor = Ham skor
Kontrol uyguladığınızı iddia ediyorsanız kalan skor mutlaka düşmeli. Aynı kalıyorsa kontrolün etkinliği yok demektir; ya kontrol ekle ya stratejiyi “Kabul Et” olarak değiştir.
SoA ile risk kaydının tutmaması
Risk kaydında “uygulanıyor” dediğiniz her kontrol, Uygulanabilirlik Bildirgesinde (SoA) de “Applied” olmak zorunda. Çapraz kontrol yapılmazsa denetçi yakalar.
Tehdit-zafiyet karmaşası
“Parola yönetimi” bir zafiyet, “kaba kuvvet saldırısı” ise tehdittir. İkisini aynı hücreye yazmayın. Ayrı alanlarda net tanımlayın.
Risk kabul kriterinin yazılı olmaması
“Skoru 9’un altındaki risklerin kabulü onaylanmıştır” gibi üst yönetim imzalı kabul eşiği olmadan hiçbir riski “Kabul Et” olarak işleyemezsiniz.
Kopyala-yapıştır kontrol listesi
Her riskin altında 20 farklı Ek A kontrolünün listelenmesi, kontrolün gerçekte uygulanmadığının işaretidir. Her risk için 2–4 odaklı kontrol seçin.
Varlık envanteri ile bağ kurmamak
Risk kaydı, varlık envanterinizdeki gerçek CI’lara (configuration item) bağlı olmalı. “Kritik veritabanı” gibi genel ifadeler yerine CMDB referansı verin.
Risk Kaydınızın Hazır Olduğundan Emin misiniz?
Secure Fors, ISO 27001:2022 uyumlu BGYS risk kaydınızı baştan sona kurar, mevcut kaydınızı denetim öncesi 5 iş gününde gözden geçirir ve ServiceNow GRC’ye göçünüzü yönetir.
Ücretsiz Ön Değerlendirme Al →Sık Sorulan Sorular
BGYS risk kaydı ne sıklıkla güncellenmelidir?
ISO 27001:2022 standardı spesifik bir sıklık belirtmese de, en iyi uygulama tüm kaydın en az yılda bir tam gözden geçirilmesi, yüksek ve kritik risklerin ise 3 ayda bir güncellenmesidir. Ayrıca büyük bir değişiklik (yeni sistem, yeni tedarikçi, olay yaşanması) olduğunda ilgili riskler anında güncellenmelidir.
Risk kaydı Excel’de mi yoksa GRC yazılımında mı tutulmalı?
50’nin altında riski olan küçük kuruluşlar için Excel yeterlidir. 50 riskin üzerinde, birden fazla risk sahibi olan ya da birden çok lokasyonda faaliyet gösteren kuruluşlar ServiceNow GRC, RSA Archer, LogicGate gibi GRC yazılımlarına geçmelidir. GRC platformları otomatik hatırlatma, versiyon kontrolü ve raporlama açısından denetim hazırlığını hızlandırır.
5×5 yerine 3×3 veya 4×4 risk matrisi kullanılabilir mi?
Evet, kullanılabilir. ISO 27001:2022 belirli bir matris boyutu zorunlu kılmaz. Ancak 3×3 matris çok kaba sonuç üretir ve yüksek hacimli organizasyonlarda risklerin büyük çoğunluğu aynı orta skor grubunda toplanır. 5×5 matris, Türkiye’deki BGYS uygulamalarının de facto standardıdır ve denetçiler tarafından en iyi bilinen modeldir.
Kalan (residual) risk skoru neye göre hesaplanır?
Kalan risk skoru, uygulanan kontrollerin etkinliği değerlendirilerek hesaplanır. En yaygın yöntem; kontrollerin zayıflatıcı etkisini olasılık veya etki değerlerinden belirli puan düşürmek (örnek: güçlü MFA + PAM kombinasyonu yetkisiz erişim olasılığını 4’ten 2’ye indirir). Bazı kuruluşlar ise kontrol olgunluğunu yüzdesel olarak (örnek %60 etkin) modelleyip ham skoru bu oranla çarpar.
Varlık bazlı mı yoksa süreç bazlı mı risk değerlendirmesi yapmalıyım?
ISO 27001:2022 her iki yaklaşımı da kabul eder. Varlık bazlı yaklaşım, küçük ve orta ölçekli BT ağırlıklı şirketler için daha pratiktir. Süreç bazlı yaklaşım ise hizmet odaklı, çok lokasyonlu veya finansal hizmet kurumları için uygundur. Karma yaklaşım da yaygındır: kritik iş süreçleri ana risk grubu olarak alınır, her süreç altındaki kritik varlıklar ayrı satırlar olarak yönetilir.
Tedarikçi riskleri ayrı bir kayıtta mı tutulmalı?
Olgun TPRM programına sahip kuruluşlar tedarikçi riskleri için ayrı bir TPRM risk kaydı yönetir ve kurumsal BGYS risk kaydına yalnızca en kritik tedarikçi risklerini özet olarak aktarır. Yeni başlayan kuruluşlar ise tek bir kayıt altında “Tedarikçi” kategorisinde tutabilir. ISO 27001:2022 Ek A’daki A.5.19–A.5.23 tedarikçi kontrolleri her iki yaklaşımda da uygulanabilir.
Sonuç
İyi bir BGYS risk kaydı; tablo değil, yönetim aracıdır. Üç özelliği onu diğerlerinden ayırır: denetlenebilir alan yapısı, ölçülebilir puanlama mantığı ve aksiyona dönüşen kalan risk skoru. Bu yazıdaki 42 örnek riski kendi bağlamınıza uyarlayarak hızlıca başlayabilir, ServiceNow’a geçişte alan eşleme tablosunu doğrudan kullanabilir ve denetçi tuzaklarına düşmeden ilk denetiminizden temiz çıkabilirsiniz.
Risk kaydı, BGYS olgunluğunuzun turnusol testidir. Skorlarınız güncel, sahipleri gerçek kişi ve kontrolleriniz SoA ile birebir örtüşüyorsa, sertifika denetiminiz teknik bir süreç olmaktan çıkıp bir üst yönetim raporlama seansına dönüşür.
Yayın: Secure Fors | Kategori: Bilgi Güvenliği Yönetim Sistemi | Okuma Süresi: 12 dk
Etiketler: #BGYS #ISO27001 #RiskYönetimi #ServiceNow #RiskRegister #BilgiGüvenliği #SoA #KVKK
