Yazılım firmaları için ISO 27001 risk değerlendirmesi, önce ölçülebilir kabul kriterleri belirlemek, ardından kaynak kod, CI/CD hattı, bulut altyapısı, açık kaynak bağımlılıklar ve müşteri verisi etrafındaki senaryoları olasılık ve etkiye göre puanlamak demektir. ISO/IEC 27001:2022 bunu 6.1.2 maddesinde tanımlar ve her riskin bir sahibi olmasını, sonuçların tekrarlanabilir olmasını ister. Genel şablonlardaki "yangın, sel, virüs" listesi bir yazılım firmasının asıl risklerini göstermez; bu rehberdeki adımlar ve örnek tablo bu boşluğu kapatmak için hazırlandı.
Bu yazı SaaS ürünü işleten, müşteriye proje bazlı yazılım geliştiren veya kurulum tipi ürün satan firmalar için yazıldı. ISO 27001 sürecinin tamamını merak ediyorsanız ISO 27001 belgesi rehberimiz genel çerçeveyi verir; burada yalnızca risk değerlendirmesine odaklanıyoruz.
İçerik
Standart risk değerlendirmesinden tam olarak ne ister?
ISO/IEC 27001:2022'nin 6.1.2 maddesi şu şartları koyar:
- Risk kabul kriterleri ile değerlendirme kriterlerinin belirlenmesi (a).
- Tekrarlanan değerlendirmelerin tutarlı, geçerli ve karşılaştırılabilir sonuç üretmesi (b).
- Kapsam içindeki bilginin gizlilik, bütünlük ve erişilebilirliğinin kaybıyla ilgili risklerin belirlenmesi ve her riske bir risk sahibi atanması (c).
- Olası sonuçların ve gerçekleşme olasılığının analiz edilip risk seviyesinin belirlenmesi (d).
- Sonuçların kabul kriterleriyle karşılaştırılıp önceliklendirilmesi (e).
6.1.3 risk işleme seçeneklerini, Uygulanabilirlik Bildirgesi'ni (SoA) ve risk sahiplerinin onayını; 8.2 ve 8.3 ise değerlendirmenin planlı aralıklarla ve önemli değişikliklerde tekrar yapılmasını ve sonuçların saklanmasını düzenler.
Standart varlık tabanlı bir yöntem zorunlu kılmaz. ISO/IEC 27005:2022, olay (senaryo) tabanlı ve varlık tabanlı yaklaşımları birlikte anlatır. Yazılım firmalarında süreç ve senaryo tabanlı yaklaşım genellikle daha anlamlı sonuç verir, çünkü "sunucu" gibi tekil varlıklar yerine "kaynak koddan canlıya giden hat" gibi uçtan uca akışlar risk taşır.
Adım 1: Kapsamı ve rolünüzü netleştirin
Risk listesine geçmeden önce üç soruya cevap verin:
- Ne satıyorsunuz? SaaS'ta erişilebilirlik ve çok kiracılı veri ayrımı öne çıkar; proje bazlı geliştirmede müşteri ortamlarına erişim ve teslim edilen kodun güvenliği; kurulum tipi üründe ise güncelleme paketlerinin bütünlüğü.
- KVKK açısından rolünüz ne? SaaS sağlayıcısı çoğu durumda müşterisi adına kişisel veri işleyen konumundadır. KVKK'nın 12. maddesinin ikinci fıkrası, veri sorumlusunun veri işleyenle birlikte güvenlik tedbirlerinden müştereken sorumlu olduğunu söyler; bu yüzden müşterileriniz sizden sözleşme ve kanıt ister.
- Hangi ilgili taraf şartları var? Müşteri sözleşmelerindeki güvenlik maddeleri, hizmet seviyesi taahhütleri ve kamu ihalelerinin şartları 4.2 kapsamında listelenir ve risk kriterlerini doğrudan etkiler.
Adım 2: Metodolojiyi ve kabul kriterini yazın
Denetimlerde sık görülen bulgu, olasılık ve etki seviyelerinin tanımsız bırakılmasıdır. "3" puanın ne anlama geldiği yazılı değilse, iki farklı kişi aynı riske farklı puan verir ve 6.1.2 b) şartı karşılanmaz. Aşağıda bir yazılım firmasına uyarlanmış örnek tanımlar var; kendi kuruluşunuza göre değiştirin.
| Seviye | Olasılık tanımı | Etki tanımı (yazılım firması) |
|---|---|---|
| 1 Çok düşük | Beklenmez, sektörde nadiren görülür | Tek bir iç sisteme sınırlı, müşteriye yansımayan etki |
| 2 Düşük | Birkaç yılda bir olabilir | Kısa süreli iç kesinti, sınırlı düzeltme eforu |
| 3 Orta | Yılda bir olabilir | Tek müşteriyi etkileyen olay, hizmet seviyesi ihlali riski |
| 4 Yüksek | Yılda birkaç kez olabilir | Birden fazla müşteriyi etkileyen kesinti veya veri ifşası, KVKK bildirimi gerektirebilecek olay |
| 5 Çok yüksek | Düzenli olarak yaşanır veya zaten yaşanmıştır | Müşteri verisinin toplu ifşası, kaynak kodun sızması, sözleşme feshi ve yasal yaptırım riski |
Risk skoru = Olasılık x Etki (1-25). Örnek kabul kriteri:
- 1-6 düşük: Kabul edilebilir, mevcut kontrollerle izlenir.
- 8-12 orta: Risk sahibi tarafından işleme planı hazırlanır, bir sonraki gözden geçirmeye kadar uygulanır.
- 15-25 yüksek: Üst yönetime raporlanır, öncelikli işleme planı açılır; kabul edilecekse gerekçesi ve onayı yazılı olur.
Etki puanını gizlilik, bütünlük ve erişilebilirlik için ayrı ayrı verip en yükseğini almak, özellikle SaaS'ta erişilebilirlik risklerinin gözden kaçmasını önler.
Adım 3: Süreçleri ve varlıkları çıkarın
Bir yazılım firmasında risk taşıyan bileşenler genellikle şunlardır:
- Kaynak kod depoları ve dal koruma kuralları
- CI/CD hattı, derleme sunucuları ve bu hatta tanımlı sırlar (API anahtarları, sertifikalar, bulut erişim anahtarları)
- Açık kaynak ve üçüncü taraf kütüphaneler
- Üretim, test ve geliştirme ortamları; üretim veritabanları ve yedekleri
- Bulut hesapları, kimlik ve erişim yönetimi yapılandırması
- Geliştirici bilgisayarları ve uzaktan çalışma ortamı
- Müşteri destek ve talep sistemleri (destek kaydına eklenen ekran görüntüleri ve veri dökümleri)
- Kodlama asistanları ve diğer yapay zekâ araçları
- Dış kaynaklı geliştirici ve danışmanlar
Envanteri çıkarırken her bileşene bir sahip atayın; aynı kişi risk sahibi olarak da düşünülebilir. Envanter hazırlığı için BGYS varlık envanteri hazırlama yazımız pratik bir şablon sunar.
Adım 4: Yazılım firmasına özgü risk senaryoları
Senaryoyu "Tehdit + açıklık + etkilenen bilgi + sonuç" biçiminde yazmak, puanlamayı tutarlı hale getirir. Örnek: "Ayrılan bir geliştiricinin kişisel erişim anahtarı iptal edilmediği için kaynak kod deposuna dışarıdan erişilmesi ve kodun ifşa olması."
Sahada karşılaşılan tipik yazılım riskleri ve ilgili ISO/IEC 27001:2022 Ek-A kontrolleri:
- Kaynak koda yetkisiz erişim: A.8.4 (kaynak koda erişim), A.5.18 (erişim hakları), A.6.5 (çıkış sonrası sorumluluklar)
- Depoda veya CI/CD'de açık metin sır: A.5.17 (kimlik doğrulama bilgileri), A.8.28 (güvenli kodlama)
- Bağımlılıkta kritik açıklık: A.8.8 (teknik açıklıkların yönetimi), A.5.21 (BİT tedarik zincirinde güvenlik)
- Üretim verisinin testte kullanılması: A.8.33 (test bilgisi), A.8.31 (ortamların ayrılması), A.8.11 (veri maskeleme)
- Bulut yanlış yapılandırması: A.5.23 (bulut hizmetleri), A.8.9 (yapılandırma yönetimi)
- Geliştiricinin üretime kalıcı yönetici erişimi: A.8.2 (ayrıcalıklı erişim), A.5.3 (görevler ayrılığı)
- Güvensiz kodun canlıya çıkması: A.8.25 (güvenli geliştirme yaşam döngüsü), A.8.26 (uygulama güvenlik gereksinimleri), A.8.29 (geliştirme ve kabulde güvenlik testi)
- Onaysız değişikliğin canlıya alınması: A.8.32 (değişiklik yönetimi)
- Yapay zekâ araçlarına müşteri verisi veya kod girilmesi: A.5.10 (kabul edilebilir kullanım), A.8.12 (veri sızıntısını önleme)
- Dış kaynaklı geliştiricinin güvenlik şartına uymaması: A.8.30 (dış kaynaklı geliştirme), A.5.20 (tedarikçi sözleşmelerinde güvenlik)
- Hizmet kesintisi ve veri kaybı: A.8.13 (yedekleme), A.8.14 (yedeklilik), A.5.30 (iş sürekliliği için BİT hazırlığı)
- Kişisel veri ihlalinin geç fark edilmesi: A.5.24-A.5.26 (olay yönetimi), A.5.34 (kişisel verilerin korunması), A.8.16 (izleme)
Adım 5: Örnek risk tablosu
Aşağıdaki tablo metodolojinin nasıl uygulandığını göstermek için hazırlanmış bir şablondur. Puanlar örnektir ve belirli bir kuruluşu yansıtmaz; kendi değerlendirmenizde kendi kanıtlarınıza göre puan verin.
| No | Risk senaryosu | O | E | Skor | Karar | Planlanan kontroller (Ek-A) | Risk sahibi | Artık skor |
|---|---|---|---|---|---|---|---|---|
| R-01 | Ayrılan geliştiricinin depo erişim anahtarı açık kalır, kod sızar | 3 | 5 | 15 | İşle | SSO ile depo erişimi, çıkışta otomatik iptal, çeyreklik erişim gözden geçirmesi (A.8.4, A.5.18, A.6.5) | Mühendislik müdürü | 5 |
| R-02 | CI/CD değişkenlerinde veya depoda açık metin bulut anahtarı | 4 | 5 | 20 | İşle | Sır yönetim aracı, commit öncesi sır taraması, anahtar rotasyonu (A.5.17, A.8.28) | DevOps sorumlusu | 8 |
| R-03 | Kullanılan bir açık kaynak kütüphanede kritik açıklık | 4 | 4 | 16 | İşle | Bağımlılık taraması, SBOM, yama süresi hedefi (A.8.8, A.5.21) | Ürün teknik lideri | 8 |
| R-04 | Üretim veritabanı kopyasının test ortamında maskesiz kullanılması | 3 | 4 | 12 | İşle | Maskeleme betiği, test verisi prosedürü (A.8.33, A.8.11, A.8.31) | Veri tabanı sorumlusu | 4 |
| R-05 | Nesne depolama alanının yanlışlıkla herkese açık bırakılması | 2 | 5 | 10 | İşle | Hesap düzeyinde genel erişim engeli, yapılandırma denetimi (A.5.23, A.8.9) | Bulut altyapı sorumlusu | 5 |
| R-06 | Yetkilendirme hatası (IDOR) nedeniyle kiracılar arası veri erişimi | 3 | 5 | 15 | İşle | Güvenli kod incelemesi, yetkilendirme testleri, yıllık uygulama sızma testi (A.8.26, A.8.28, A.8.29) | Ürün teknik lideri | 5 |
| R-07 | Tek bölgede çalışan SaaS'ın bölgesel kesintiden etkilenmesi | 2 | 4 | 8 | İşle | Bölgeler arası yedek, geri dönüş tatbikatı (A.8.13, A.8.14, A.5.30) | Operasyon müdürü | 4 |
| R-08 | Destek ekibinin müşteri kayıtlarını onaysız yapay zekâ aracına yapıştırması | 3 | 4 | 12 | İşle | Kabul edilebilir kullanım kuralı, onaylı araç listesi, farkındalık (A.5.10, A.8.12, A.6.3) | Destek müdürü | 6 |
| R-09 | Ofis içi yazıcıdan basılan sözleşmenin masada unutulması | 2 | 2 | 4 | Kabul | Mevcut temiz masa kuralı yeterli (A.7.7) | İdari işler | 4 |
Tablo okunurken dikkat edilmesi gereken iki nokta var. R-09 gibi düşük skorlu riskler kabul edilir ama listeden silinmez; denetçi kabul kararını ve kimin verdiğini görmek ister. R-02 gibi yüksek skorlu bir riskte artık skorun neden düştüğü, planlanan kontrollerin olasılığı mı etkiyi mi azalttığı açıklanabilmelidir.
Adım 6: Risk işleme planı ve SoA
Her "İşle" kararı için risk işleme planında kontrol, sorumlu, bitiş tarihi ve kaynak yazılır. Planın Ek-A kontrolleri SoA'ya aktarılır. SoA'da uygulanan her kontrolün en az bir riske bağlanabilmesi ve hariç tutulan kontrollerin gerekçesinin yazılı olması gerekir. Örneğin yalnızca kendi ekibinizle geliştirme yapıyorsanız A.8.30'u hariç tutabilirsiniz; ama serbest çalışan bir geliştiriciyle bile çalışıyorsanız bu gerekçe geçersiz kalır. Ayrıntılar için risk işleme ve SoA rehberimize bakabilirsiniz.
6.1.3'teki not, Ek-A'nın kapsayıcı bir liste olmadığını hatırlatır. Yazılım firmalarında sıkça ihtiyaç duyulan bazı teknik önlemler, örneğin SBOM üretimi veya imzalı derlemeler, Ek-A'da ayrı bir kontrol olarak geçmez; bunları A.8.25 ve A.8.28 altında tanımlamak veya ek kontrol olarak SoA'ya eklemek mümkündür. NIST SP 800-218 (Secure Software Development Framework) bu önlemler için iyi bir referanstır.
Adım 7: Risk sahibinin onayı ve artık risk
6.1.3 f), risk sahiplerinin işleme planını ve artık riskleri onaylamasını ister. Denetimlerde sık görülen bulgu, tabloyu hazırlayan kişiyle onaylayan kişinin aynı olması veya onayın hiçbir yerde kayıtlı olmamasıdır. Onayı toplantı tutanağı, iş takip sistemindeki onay kaydı veya imzalı tablo ile belgeleyin.
Adım 8: Ne zaman yeniden değerlendirmelisiniz?
8.2, değerlendirmenin planlı aralıklarla ve önemli değişiklik önerildiğinde veya gerçekleştiğinde yapılmasını ister. Yazılım firmalarında tipik tetikleyiciler:
- Yeni bir veri kategorisini (ör. sağlık veya ödeme verisi) işleyen özellik
- Yeni bulut sağlayıcısı, yeni bölge veya yurt dışına veri aktarımı
- Yeni dış kaynaklı geliştirici veya kritik SaaS tedarikçisi
- Sızma testinde veya olayda ortaya çıkan yeni bir saldırı yolu
- Müşteri sözleşmesine eklenen yeni güvenlik şartı
Bu tetikleyicileri değişiklik yönetimi sürecinize (A.8.32) bir onay kutusu olarak eklemek, risk tablosunun güncel kalmasının en pratik yoludur.
Sahada karşılaşılan tipik hatalar
- Risk listesini internetten indirilen genel bir şablondan kopyalamak; "deprem" var, "sır sızıntısı" yok.
- Olasılık puanını tahminle vermek; sızma testi bulguları, olay kayıtları ve bağımlılık tarama sonuçları gibi mevcut kanıtları kullanmamak.
- Geliştirme ekibini sürece dahil etmemek; riskleri yalnızca kalite veya uyum sorumlusunun yazması.
- Artık risk sütununu boş bırakmak veya işleme sonrası skoru gerekçesiz düşürmek.
- Tabloyu belgelendirme denetiminden sonra bir yıl boyunca açmamak.
Risk değerlendirmesi kontrol listesi
- Kapsam, ürün modeli ve KVKK'daki rolünüz yazılı.
- Olasılık ve etki seviyeleri yazılım bağlamında tanımlı; kabul eşiği sayısal olarak belirtilmiş.
- Kaynak kod, CI/CD, bulut, bağımlılıklar, test verisi ve yapay zekâ kullanımı senaryo olarak listede.
- Her riskin adı konmuş bir sahibi var.
- Puanlar mümkün olduğunca kanıta (tarama, test, olay kaydı) dayanıyor.
- Her "İşle" kararının kontrol, sorumlu ve tarih içeren bir planı var.
- SoA ile risk işleme planı çapraz kontrol edildi.
- Artık riskler risk sahiplerince onaylandı ve onay kaydı saklandı.
- Yeniden değerlendirme tetikleyicileri değişiklik sürecine eklendi.
- Risk tablosunun sürüm geçmişi tutuluyor.
Sıkça Sorulan Sorular
Risk değerlendirmesi için özel bir yazılım kullanmak zorunlu mu?
Hayır. ISO/IEC 27001:2022 bir araç şartı koymaz; iyi kurgulanmış bir tablo yeterlidir. Önemli olan metodolojinin yazılı olması, sonuçların tekrarlanabilir olması ve sürüm geçmişinin tutulmasıdır. Risk sayısı arttıkça ve işleme planları birden fazla ekibe dağıldıkça iş takip sistemine veya bir GRC aracına geçmek takibi kolaylaştırır.
Varlık tabanlı mı senaryo tabanlı mı yöntem seçmeliyiz?
Standart ikisini de kabul eder. ISO/IEC 27005:2022 her iki yaklaşımı açıklar. Yazılım firmalarında riskler genellikle uçtan uca akışlarda (koddan canlıya, müşteri talebinden veriye) oluştuğu için senaryo tabanlı yaklaşım daha anlamlı sonuç verir. Varlık envanteri yine gereklidir, çünkü A.5.9 kontrolü envanteri ayrıca ister.
Kaç risk yazmak yeterlidir?
Standart bir sayı belirlemez. Denetçi sayıya değil, kapsamdaki önemli süreçlerin ve bilgi türlerinin temsil edilip edilmediğine bakar. Yüzlerce satırlık kopyalanmış bir liste yerine, kuruluşunuzun gerçek ürün ve altyapısını yansıtan, sahibi ve planı net senaryolar tercih edilmelidir.
Sızma testi sonuçları risk değerlendirmesine nasıl yansır?
Test bulguları olasılık puanının en somut kanıtıdır. Kritik bir yetkilendirme açığı bulunduysa ilgili senaryonun olasılığı yükselir; açık kapatılıp yeniden test edildiğinde artık skor düşürülür ve gerekçesi test raporuyla gösterilir. Bu nedenle test bulgularının risk numaralarıyla eşleştirilmesi önerilir.
KVKK riskleri ayrı bir tabloda mı tutulmalı?
Zorunlu değildir. Kişisel verileri etkileyen senaryoları aynı tabloda işaretlemek ve A.5.34 ile KVKK'nın 12. maddesine bağlamak genellikle yeterlidir. Veri ihlali bildirimleri için Kurul'un 2019/10 sayılı kararında öngörülen 72 saatlik süre, olay müdahale senaryolarınızda dikkate alınmalıdır.
Risk değerlendirmesi ne sıklıkla güncellenmeli?
Standart belirli bir sıklık yerine planlı aralık ve önemli değişiklik şartı koyar. Çoğu kuruluş en az yılda bir tam gözden geçirme yapar ve değişiklik tetikleyicilerinde ilgili satırları günceller. Hızlı sürüm çıkaran ekiplerde çeyreklik kısa bir gözden geçirme, tablonun gerçeği yansıtmasına yardımcı olur.
Kaynaklar
- ISO/IEC 27001:2022, ISO/IEC 27002:2022 ve ISO/IEC 27005:2022 (iso.org)
- NIST SP 800-30 Rev. 1, Guide for Conducting Risk Assessments (nist.gov)
- NIST SP 800-218, Secure Software Development Framework (nist.gov)
- OWASP Application Security Verification Standard (owasp.org)
- 6698 sayılı Kişisel Verilerin Korunması Kanunu, madde 12; KVK Kurulu'nun 24.01.2019 tarihli ve 2019/10 sayılı kararı (kvkk.gov.tr)
Risk değerlendirmenizi ürününüzün gerçek mimarisine göre kurmak isterseniz ISO 27001 danışmanlık hizmetimiz kapsamında metodoloji, risk tablosu ve SoA'yı ekibinizle birlikte hazırlıyoruz. Olasılık puanlarını kanıta dayandırmak için sızma testi hizmetimiz ile uygulamanızı ve bulut yapılandırmanızı test edebiliriz; yazılım ekipleri için kaynak koda erişimli testin avantajlarını white box pentest yazımızda anlattık. Bize 0533 370 01 43 numaralı telefondan veya iletişim sayfamızdan ulaşabilirsiniz.
Hazırlayan: ISO 27001 Danışmanlık Uzman Ekibi