Baş denetçi uygulanabilirlik bildirgesini çevirir, parmağını bir satıra koyar ve "burada uyguluyoruz yazmışsınız, kanıt görebilir miyim" der. BGYS sorumlusu prosedürün var olduğunu biliyor; hatta geçen ay revize ettiğini de hatırlıyor. Ama hangi klasörde, hangi sürümde durduğunu bulması on dakika sürüyor. O on dakika denetim odasında çok uzundur ve denetçinin aklında tek bir soru bırakır. ISO 27001 Ek A kontrolleri için asıl mesele kontrolün var olup olmadığı değil, var olduğunun gösterilebilmesidir.
Uygulanabilirlik bildirgesi sistemin omurgasıdır
ISO/IEC 27001'in 6.1.3 maddesi, risk işleme sürecinin bir çıktısı olarak uygulanabilirlik bildirgesini dokümante edilmiş bilgi olarak ister. İngilizcesiyle Statement of Applicability (SoA) denen bu tablo, Ek A'daki her kontrol için üç soruyu cevaplar: uyguluyor musunuz, uygulamıyorsanız gerekçeniz ne, uyguluyorsanız nasıl uyguluyorsunuz.
Bu tabloyu bir formalite sanmak en pahalı hatadır. Denetim planı doğrudan bu tablodan çıkar. Baş denetçi kendi kafasından kontrol seçmez; sizin beyanınızdan satır seçer ve beyanınızın karşılığını sorar. Yani SoA hazırlama aslında denetim sorularını kendi elinizle yazmak demektir. Fazla iddialı yazarsanız kanıtlayamazsınız, fazla temkinli yazarsanız kapsamınız zayıf görünür.
Bildirgede en çok hata yapılan kolon, "nasıl uyguluyorsunuz" kolonudur. Buraya "uygulanıyor" yazmak hiçbir şey söylemez. Doğru içerik şudur: kontrolün karşılığı olan doküman kodu ve kontrolün işlediğini gösteren kaydın adı. Örneğin "BG-PR-04 Erişim Kontrol Prosedürü / Yetkilendirme Talep Formu ve altı aylık erişim gözden geçirme kaydı". Bu tek cümle, o satır için denetim hazırlığının tamamıdır.
Ek A'nın yapısı: dört tema, doksan üç kontrol
2022 sürümüyle birlikte ek yeniden düzenlendi. Eski sürümdeki on dört başlık, dört temaya indirildi: örgütsel kontroller (A.5), kişilere ilişkin kontroller (A.6), fiziksel kontroller (A.7) ve teknolojik kontroller (A.8). Toplam kontrol sayısı doksan üç. Eski sürümden geçiyorsanız numaralar değişti; bildirgeyi kopyalayıp yeni numaraları elle eşleştirmek birkaç günlük bir iştir ve atlanmaya çok müsaittir.
27001 Annex A listesine ilk bakan kalite yöneticileri genelde paniğe kapılır: doksan üç kontrol, doksan üç prosedür mü demek? Hayır. Kontrollerin büyük bölümü teknik yapılandırmadır ve karşılığı bir sistem ayarıdır, doküman değil. Bir kısmı ise tek bir prosedürde birlikte karşılanır. Uygulamada on beş ile yirmi arasında iyi yazılmış bilgi güvenliği prosedürleri doksan üç kontrolün tamamını kapsar.
Bir kontrolün sizin için uygulanabilir olmaması da meşrudur, yeter ki gerekçesi yazılsın. Kendi yazılımını geliştirmeyen bir üretim firmasında güvenli geliştirmeye ilişkin kontrollerin karşılığı yoktur; bildirgeye "kuruluş bünyesinde yazılım geliştirme faaliyeti yürütülmemektedir" yazarsınız ve konu kapanır. Denetçiyi rahatsız eden hariç tutma değil, gerekçesiz hariç tutmadır. ISO 27001 Ek A kontrolleri arasında sizi ilgilendirmeyenler olması normaldir; hepsini uyguluyor görünmek ise şüphe uyandırır.
Kontrol, prosedür ve kanıt aynı şey değildir
Kontrol, ulaşmak istediğiniz güvenlik amacıdır. Prosedür, o amaca nasıl ulaştığınızı anlatan metindir. Kanıt ise prosedürün gerçekten işlediğini gösteren kayıttır. Denetimde bulguların çoğu üçüncü halkadan çıkar: doküman vardır, uygulama vardır, ama uygulamanın kaydı yoktur.
Basit bir üçlü kural kurun ve her kontrol için uygulayın. Bir: kuralı anlatan doküman hangisi? İki: kuralın uygulandığını gösteren kayıt hangisi? Üç: bu kuralın gözden geçirildiğini gösteren tarih ne? Üçü de dolduğunda o satır denetime hazırdır. Üçüncü soru en çok boş kalanıdır; politikalar yazılır, bir daha açılmaz. Oysa A.5.1 kontrolü, politikaların planlı aralıklarla ya da önemli değişiklik olduğunda gözden geçirilmesini bekler.
Üçlü kuralı bildirgenin kolon yapısına da taşıyın. Standart, bildirgede belirli bir kolon düzeni dayatmaz; siz ekleyebilirsiniz. Kontrol numarası, kontrol adı, uygulanıyor mu, gerekçe, doküman kodu, kayıt adı, sorumlu ve son gözden geçirme tarihi. Sekiz kolon. Bu düzende hazırlanmış bir bildirge, denetimden önce yapılacak hazırlığın kendisi hâline gelir; eksikleri de kendiliğinden gösterir, çünkü boş hücre göze batar.
Bir üretim firmasında bildirgenin doksan üç satırının hepsinde "uygulanıyor" yazıyordu. Denetçi rastgele beş satır seçti, üçünde kanıt çıkmadı. Kapanış toplantısında bir majör, iki minör bulgu yazıldı. O günden sonra kural koyduk: bildirgeye "uygulanıyor" yazmadan önce doküman kodu ve kayıt adı kolonu doldurulmuş olacak. Boş kolonla o satır "planlanıyor" kalır. Dürüst bir bildirge, şişirilmiş bir bildirgeden her zaman daha az bulgu alır.
Hangi kontrol hangi kanıtı ister
Aşağıdaki tablo, denetimlerde en sık kanıt istenen kontrollerden bir kesit. Kontrol numaraları ISO/IEC 27001:2022 ekindeki numaralardır. Sağdaki iki kolon, o satır için bildirgenize yazmanız gereken içeriktir.
| Kontrol | Konu | Beklenen doküman | Beklenen kayıt |
|---|---|---|---|
| A.5.1 | Bilgi güvenliği politikaları | BG politikası | Yayın onayı, gözden geçirme tarihi |
| A.5.9 | Varlık envanteri | Varlık yönetim prosedürü | Güncel varlık listesi, sahipleri |
| A.5.12 | Bilginin sınıflandırılması | Sınıflandırma politikası | Sınıf atanmış doküman listesi |
| A.5.15 | Erişim kontrolü | Erişim kontrol prosedürü | Yetki talep formları, gözden geçirme |
| A.5.19 | Tedarikçi ilişkileri | Tedarikçi BG şartları | Sözleşme ekleri, değerlendirme kaydı |
| A.5.24 | Olay yönetimi planlaması | Olay müdahale prosedürü | Olay kayıtları, müdahale süreleri |
| A.6.3 | Farkındalık ve eğitim | Eğitim planı | Katılım listesi, etkinlik ölçümü |
| A.6.5 | İşten ayrılma sorumlulukları | Çıkış prosedürü | Çıkış kontrol listesi, iade tutanağı |
| A.7.10 | Depolama ortamı | Ortam kullanım talimatı | Ortam envanteri, imha tutanakları |
| A.8.13 | Bilgi yedekleme | Yedekleme prosedürü | Yedek logları, geri dönüş testi kaydı |
| A.8.32 | Değişiklik yönetimi | Değişiklik prosedürü | Onaylı değişiklik talepleri |
Tabloda dikkat edilecek nokta, kayıt kolonunun neredeyse her satırda bir tarih içermesi. Bilgi güvenliği denetiminin ritmi budur: kural bir kez yazılır, kanıt sürekli üretilir. A.8.13 satırı bunun en net örneği. Yedekleme yapılıyor olması yetmez; geri dönüş testinin yapıldığını gösteren kayıt istenir ve bu kayıt çoğu firmada yoktur.
Kanıtı denetim odasında bir dakikada bulmak
Denetime hazırlığın en pratik testi şudur: bildirgeden rastgele bir satır seçin ve kronometre tutun. O satırın dokümanına, kaydına ve son gözden geçirme tarihine ulaşmanız bir dakikayı geçiyorsa denetimde zorlanırsınız. Geçmiyorsa hazırsınız. Bu testi denetimden bir ay önce beş satırda uygulayın, çıkan eksikleri kapatın; denetim haftası boyunca yaptığınız hazırlıktan daha çok işe yarar.
Süreyi kısaltan tek şey aramayı kolaylaştırmak değil, kaydın doğru yerde durmasıdır. Kanıt e-postada, birinin bilgisayarında ya da paylaşımlı klasörün derinliklerinde duruyorsa arama süresi kişiye bağlıdır. Sistemde kontrol numarasıyla etiketlenmiş bir kayıt olarak duruyorsa süre herkes için aynıdır. Bu fark, gözetim denetimlerinin gün sayısını bile etkileyebiliyor; hazırlıklı firmada denetçi örneklemi genişletmiyor.
Bir de kanıtın okunabilir olması meselesi var. Log dosyası kanıttır ama denetçiye bin satırlık ham çıktı vermek işi kolaylaştırmaz. Erişim gözden geçirmesinin kanıtı, gözden geçirilen hesapların listesi, verilen kararlar ve gözden geçireni gösteren imzadır; ham log değil. Kanıtı hazırlarken kendinize şunu sorun: bu belgeyi ilk kez gören biri, kontrolün gerçekten işlediğini beş dakikada anlayabilir mi? ISO 27001 Ek A kontrolleri için hazırlanan dosyaların çoğu bu testten kalır.
Bildirgeyi doküman sistemine bağlamak
Bildirge ile doküman listesi ayrı iki dosyada yaşıyorsa ayrışması an meselesidir. Prosedür revize edilir, kodu değişir, bildirgede eski kod kalır. Ya da bir prosedür yürürlükten kaldırılır, bildirgede hâlâ o satır işaret eder. Denetimde bu tür bir tutarsızlık tek başına bulgu üretir, çünkü bildirge güncel olmayan bir beyandır.
Doğru kurgu, bildirgedeki her satırın doküman kaydına bağ vermesidir. Doküman revize edilince bildirgede görünen sürüm de değişir; kimse elle güncellemek zorunda kalmaz. Bu bağın kurulabilmesi için doküman ile kaydın aynı sistemde yaşaması gerekir; onay akışının nasıl kurulduğunu doküman onay iş akışı yazımızda ayrıntılı anlattık. Genel doküman disiplini için de doküman yönetimi sayfamıza bakın.
İkinci bağ risk tarafındadır. 6.1.3 maddesi kontrolleri risk işleme kararlarından türetir; yani her kontrolün arkasında bir risk satırı vardır. Risk kaydı ile kontrol kaydı birbirine bağlıysa "bu kontrolü neden uyguluyorsunuz" sorusunun cevabı ekranda durur. Risk kaydının nasıl kurulacağını risk yönetimi sayfamızda ele aldık.
En çok bulgu alınan üç alan
Başı erişim gözden geçirmesi çekiyor. Yetkiler verilir, kaydı tutulur, ama periyodik gözden geçirme yapılmaz. İşten ayrılan personelin hesabı üç ay açık kalmışsa bu tek başına majör bulgudur. İkincisi tedarikçi tarafı: hizmet aldığınız firmalara bilgi güvenliği şartlarını sözleşmeye koymamışsanız A.5.19 satırı boşta kalır. Üçüncüsü farkındalık eğitiminin etkinliği; katılım listesi vardır, ama eğitimin işe yarayıp yaramadığına dair hiçbir ölçüm yoktur.
Bu üçünün ortak özelliği, hepsinin tekrar eden bir işe dayanması. Tek seferlik iş yapılır, tekrar eden iş unutulur. Çözüm de aynı: her tekrar eden kontrolü bir hatırlatmaya bağlayın. Erişim gözden geçirmesi altı ayda bir, tedarikçi değerlendirmesi yılda bir, farkındalık eğitimi yılda bir. Sistemde tarih varsa iş kendini hatırlatır; takvimde varsa kişiye bağlıdır. Çıkan uygunsuzlukları da düzeltici faaliyet akışına düşürün, ayrı bir BGYS defteri açmayın.
Ben denetimde bildirgeden beş satır seçerim ve her biri için üç şey isterim: dokümanı, kaydı ve son gözden geçirme tarihini. Beş satırın üçünde bu üçlü eksiksiz geliyorsa sistemin geri kalanına güvenirim ve örneklemi genişletmem. İkisinde eksik çıkarsa örneklemi on satıra çıkarırım. Denetim süresini uzatan şey kontrollerin sayısı değil, kanıtın bulunma hızıdır.
Sistemi kurarken ölçüyü kaçırmamak
Kırk kişilik bir yazılım firmasında ISO 27001 Ek A kontrolleri için kurulacak dokümantasyon, on beş prosedür ve otuz kadar kayıt formuyla biter. Bunu üç yüz sayfalık bir sete çevirmenin kimseye faydası yok; kimse okumaz, kimse güncellemez ve ikinci yıl gözetim denetiminde set kendi ağırlığı altında çöker. Yazdığınız her dokümanın bir sahibi ve bir gözden geçirme periyodu olsun; sahibi olmayanı yazmayın.
Kalite tarafında zaten bir doküman sisteminiz varsa bilgi güvenliği için ikinci bir sistem kurmayın. Aynı doküman kontrolü, aynı onay akışı, aynı revizyon geçmişi burada da çalışır; eklenmesi gereken tek şey gizlilik sınıfı ve erişim kısıtıdır. PaKalite'de dokümanlara standart etiketi ve gizlilik sınıfı verilebildiği için bildirge raporu doğrudan doküman listesinden üretilir. Sınıflandırma tarafını doküman gizlilik sınıflandırması yazımızda ayrıca anlattık. Denetime hazırlık ise iç denetim programınızın bildirgeyi kapsamasıyla başlar.