ISO 27001 Uygulanabilirlik Bildirgesi (SoA) Nasıl Hazırlanır?

Bir ISO/IEC 27001 Aşama 1 veya Aşama 2 belgelendirme denetimine girdiğinizde, baş denetçinin toplantı odasında bilgisayarını açtıktan sonra sizden ilk isteyeceği evrak şaşmaz: "Lütfen güncel Uygulanabilirlik Bildirgenizi (Statement of Applicability - SoA) görebilir miyiz?"

Çünkü SoA belgesi, kurumunuzun Bilgi Güvenliği Yönetim Sistemi (BGYS) kapsamının, risk kararlarının ve teknik güvenlik olgunluğunun özet karnesidir. Denetçi, yüzlerce sayfalık prosedürü okumadan önce SoA'yı eline alır ve denetim boyunca hangi departmana gideceğini, hangi sunucuyu açtıracağını, hangi logları isteyeceğini bu tabloya bakarak planlar.

Peki, ISO 27001 Uygulanabilirlik Bildirgesi (SoA) nedir, nasıl hazırlanır ve denetçilerin en çok dikkat ettiği noktalar nelerdir? ISO/IEC 27001:2022'nin 93 kontrolüne göre adım adım açıklıyorum.

---

1. Uygulanabilirlik Bildirgesi (SoA) Nedir?

Standardın Madde 6.1.3 d) bendi uyarınca kuruluş;

1. Gerekli kontrolleri belirlemeli,
2. Bu kontrolleri Ek A'daki kontrollerle karşılaştırmalı,
3. Hangi kontrollerin seçildiğini ve neden seçildiğini gerekçelendirmeli,
4. Hangi kontrollerin hariç tutulduğunu (uygulanmadığını) ve hariç tutulma gerekçelerini dokümante etmelidir.

İşte bu şartın karşılandığı resmi dokümana Uygulanabilirlik Bildirgesi (Statement of Applicability - SoA) denir.

---

2. SoA Tablosunda Bulunması Gereken 4 Temel Sütun

Profesyonel bir SoA dokümanı, ISO 27001:2022'deki 93 kontrolün her biri için şu 4 bilgiyi net olarak içermelidir:

Sütun 1: Ek A Kontrol Numarası ve Kontrol Başlığı

Yeni 2022 sürümündeki 4 tema (Madde 5 Organizasyonel, Madde 6 İnsan Kaynakları, Madde 7 Fiziksel, Madde 8 Teknolojik) bazında kontrol maddesi (Örn: A.8.12 Veri Sızıntısı Önleme).

Sütun 2: Uygulanabilirlik Durumu (Evet / Hayır)

Kontrolün kurumunuzun BGYS kapsamı dahilinde uygulanıp uygulanmadığı (Uygulanabilir - EVET veya Hariç Tutuldu - HAYIR).

Sütun 3: Seçilme veya Hariç Tutulma Gerekçesi

Bu sütun denetçinin en kritik inceleme alanıdır. Gerekçeler genellikle şu 4 kategoriden birine dayanmalıdır:

1. Risk Değerlendirmesi Sonucu (RTP): "Risk analizi sonucunda yüksek çıkan veri kaybı riskini azaltmak amacıyla seçilmiştir."
2. Yasal / Mevzuat Şartı: "6698 sayılı KVKK ve 5651 sayılı kanun zorunlulukları nedeniyle seçilmiştir."
3. Sözleşmesel Yükümlülük: "Müşteri güvenlik sözleşmeleri ve NDA maddeleri uyarınca seçilmiştir."
4. Kurumsal İş İhtiyacı / İyi Uygulama: "Hizmet sürekliliği ve kurumsal itibarın korunması amacıyla uygulanmaktadır."

Sütun 4: Uygulama Durumu ve Referans Doküman / Kanıt

Kontrolün hangi politika, prosedür veya teknik araçla hayata geçirildiği belirtilmelidir (Örn: "Bilgi Güvenliği Politikası Madde 4.2, Uç Nokta DLP Yazılımı (Symantec/Trellix), Günlük Engelleme Raporları").

---

3. Kontroller Nasıl Hariç Tutulur? (İstisna Mantığı)

Birçok kurum denetime hazırlanırken şu hataya düşer: "Zor veya maliyetli olan kontrolleri SoA'da 'Hayır' diyerek hariç tutalım, denetimde sorulmasın."

Bu yaklaşım denetçinin doğrudan Majör Uygunsuzluk yazmasına neden olur. Çünkü bir kontrolü hariç tutabilmek için o kontrolün kurumun faaliyet alanında fiziken ve operasyonel olarak bulunmadığını kanıtlamanız gerekir.

Geçerli Hariç Tutma Örnekleri:

• A.8.28 Güvenli Kodlama (Secure Coding): Kurumunuz hiçbir şekilde yazılım geliştirmiyorsa, tüm yazılımları hazır paket (COTS) veya SaaS olarak satın alıyorsa, bu madde "Kurumumuz bünyesinde yazılım geliştirme faaliyeti yürütülmemektedir" denilerek meşru bir şekilde hariç tutulabilir.
• A.7.11 Hizmet Alanlarının Güvenliği (Securing Offices, Rooms and Facilities): Veri merkezi barındırmayan ve yalnızca paylaşımlı hazır ofis (serviced office) kullanan mikro ölçekli bir danışmanlık şirketi, sunucu odası kontrollerini belirli gerekçelerle sınırlayabilir.

Geçersiz Hariç Tutma Örnekleri:

• "Bütçemiz yetmediği için A.8.12 DLP kontrolünü hariç tuttuk." ❌ (Kabul edilmez; risk varsa alternatif bir kontrol kurgulamalısınız).
• "Şirketimizde parola unutulmadığı için erişim kontrolünü hariç tuttuk." ❌ (Kabul edilmez).

---

4. Denetçilerin SoA İncelemesinde En Sık Yakaladığı 3 Hata

1. Risk Analizi ile SoA Arasındaki Uyumsuzluk: Risk analizinde "Veri sızıntısı riski: YÜKSEK" olarak puanlanmışken, SoA tablosunda A.8.12 kontrolüne "HAYIR - Uygulanmıyor" yazılmışsa denetçi bunu ilk dakikada yakalar.
2. Doküman Var, Kanıt Yok: SoA'da "A.5.15 Erişim Kontrolü: Uygulanıyor" yazılmıştır. Denetçi "Son 3 ayda işten ayrılan personelin erişim haklarının iptal edildiğine dair formu ve Active Directory logunu görebilir miyiz?" dediğinde sistemde kayıt bulunamazsa SoA geçersiz sayılır.
3. Eski 2013 Maddelerinin Kullanılması: SoA dokümanında hâlâ A.12.6.1 veya 114 kontrol listeleniyorsa, denetçi dokümanı Aşama 1'de doğrudan reddeder.

---

Denetime Eksiksiz Bir SoA İle Girin

Uygulanabilirlik Bildirgesi, denetimde başarılı olmanın pusulasıdır. Doğru gerekçelendirilmiş ve yaşayan kanıtlarla desteklenmiş bir SoA, denetim stresini yarı yarıya azaltır ve baş denetçiye sisteminize ne kadar hâkim olduğunuzu gösterir.

Kurumunuzun SoA dokümanını ISO 27001:2022 standardına göre sıfırdan oluşturmak, mevcut bildirgeyi denetçi gözüyle revize etmek ve hariç tutmaları gerekçelendirmek için ISO/IEC 27001 BGYS Danışmanlığı hizmetimizden destek alabilirsiniz.