2013 versiyonuyla ilk denetimler bu sıralar başlıyor, herkes
merakla denetçiler acaba hangi konulara önem verecek diye bekliyor. Denetçiler
ise çoktan standart bulgularım neler olabilir diye düşünmeye başladı bile.
İşte size standart bir bulgu listesi, ilk yıl en az %75’i denetçilerin
işini rahatlıkla görür:
- 4.1 Organizasyonun anlaşılması ve çevresel koşullar: Standart maddesi içeriğinde doğrudan bu konuyu vurgulamasa da sadece maddenin adı nedeniyle organizasyonun faaliyet alanları, organizasyon yapısı, temel tedarik zinciri ve sürekli müşterileri gibi bilgilerin olmaması denetçilerin bu bilgilerin eksikliği ile ilgili bulgu yazmasına neden olabilecektir. Özellikle de denetçi ISO 9001 sevdalısıysa. ISO 9001’iniz varsa ve meşhur kalite el kitabında bu konuları belirttiyseniz bu bulguyu savuşturabilirsiniz.
- Dış ve iç gereksinimler: Bu bulgu çok aşikar, zaten 2013 versiyonunda en belirgin görünen farklılıklardan birisi. Eğer 2005 versiyonunda son derece net vurgulanan bilgi varlıkları ile ilgili iş ve yasal gereksinimleri tanımladıysanız çözüme oldukça yakınsınız. Bunu yapmadığınız halde denetimlerde sorun yaşamadıysanız denetçinize sıkı sıkıya sarılın, hiçbirşey yapmadan belge sahibi olmaya devam edebilirsiniz, kırılmayın ama bu makaleyi okuyarak zamanınızı harcamanıza da gerek yok. Denetçi arkadaşlar ise bu maddeden şöyle bir bulgu üretebilir; “Tamam iş ve yasal gereksinimleri yazmışsınız, ama hangisi iç gereksinim hangisi dış gereksinim olduğunu belirtmemişsiniz”. Ayrıca bu ihtiyaçları yazarken kullandığınız dil de denetçi tarafından bulgu aracı olarak kullanılabilir, yani gereksinim ifadeleri gereksinimin kaynağını çıkarmaya imkan vermeyebilir.
- 4.2 İlgili tarafların / paydaşların ihtiyaç ve beklentilerinin anlaşılması: İlgili taraflar kavramı da daha önceki versiyonda önemli bir yeri olmayan ancak bu versiyon ile net biçimde ifade edilen kavram. Çok mu önemli, hayır. Ama net bir bulgu kapısı. İlgili taraflar nelerdir diye sorulduğunda elbette elinizden geleni ardınıza koymayacak bir şeyler sayacaksınız. Ama bu “şunları bir yazıverseniz ne de güzel olacak” tarzı bir bulgudan sizi kurtaramayacak.
- 4.2.b İlgili tarafların bilgi güvenliği gereksinimlerinin belirlenmesi: İşte size güzel bir kombo bulgu. Madde 4.1’deki iç ve dış gereksinimlerin belirlenme şartı ile bu maddede belirtilen bu gereksimlerin hangi taraflarla ilgili olduğunun belirtilmesi şartı birleştiğinde denetçi acımasız bir bulgu üretecek ve diyecek ki; “evet gereksinimlerini yazmışsın, bunları iç ve dış diye de ayırmışsın, ama kim bu iç kim bu dış”. Denetlenen arkadaşlar, gördüğünüz gibi denetçi olmak için bilim adamı olmaya gerek yok, bu kadar kolay. Ama standardı denetim sırasında okuyorsanız veya onu bile yapmıyorsanız denetçiyi olduğundan daha zeki algılamanız olası.
- Üst yönetim: 2013 versiyonunda defalarca üst yönetim ifadesi geçiyor. Ama hepimizin bildiği gibi üst yönetim bilgi güvenliği risklerinden korkmaz, bu riskler defteri kebir’e zarar olarak yazılmadığı için onlara işlemez. Bu nedenle de yönetim gözden geçirme toplantıları bütçe ayırma yetkisi olmayan, iş riskleri hakkında yeterince bilgi sahibi olamayan ama işinde uzman kahraman teknik ekipler içinde halledilir. Denetçiler üst yönetim ifadelerini hain bir bulgu aracı olarak kullanabilir mi? Belgelendirme şirketi denetçileri kullanamaz, ama düzenleyici kurum denetçileri (namı diğer murakıplar) ISO27001’e hakimse keyifle kullanır. İç denetçiler bu bulguyu yazmayı en tatlı rüyalarında görür, ama tabiat kanunları izin vermez. Dolayısıyla iç denetimlerde problem olmaz.
- 5.1.b BGYS gereksinimlerinin iş süreçleri ile entegrasyonu: ISO denetçilerinin bu madeni keşfetmeleri biraz zaman alabilir. Ama CobiT denetçileri bu maddeyi 100 metreden vurabilir. Yine denetçiler için vurması kolay ama denetlenenler için koruması çok zor bir hedef. Konu ISO27001 denetimi olduğu için sıkıntı olmayabilir, iç ve dış gereksinimleri risk analizi ile ilişkilendirdiyseniz meseleyi halledebilirsiniz. Ama birgün iş hedefleri ile bilgi güvenliği hedeflerini bir excel dosyası üzerinde yan yana yazmak zorunda kalabilirsiniz. O gün geldiğinde bol şans, kurumda yeterince süre çalışmış ve yazılmamışı yazma (kaba tabirle uydurma) konusunda zorlanmayan arkadaşları bulmaya bakın.
- 6.1.2.c.2 Risk sahiplerinin belirlenmesi: Risk sahibi kavramı 2013 versiyonu ile gelen yeni bir kavram. Daha önce bildiğiniz gibi varlık sahibi kavramı vardı. Varlık vurgusu ortadan kalkınca varlık sahibi kavramı da yok oldu, ama yerine başka bir sahip geldi. Sanırım 27001 standardının yazarları sahiplik konusunun önemine oldukça inanıyor. Ne var ki risk sahibinin ne olduğu halen bir muamma. Daha önce varlık sahipliği, kontrol sahipliği, veri sahipliği, süreç sahipliği gibi kavramları duyduk. 2013 versiyonu yeni bir kavramı bize hediye etti, ama ne olduğunu net biçimde tanımlamadan. Birşey tanımlanmadığında ne olduğunu hepimiz biliyoruz, kaos. Benim risk sahibinin ne olduğu konusunda bir fikrim var, ama bu benim fikrim. Siz de farklı farklı fikirlere sahip denetçilerle karşılaşacaksınız, şimdiden kolay gelsin. Tartışmaya benim de katkım olsun, benim aklıma gelen iki alternatifi paylaşayım. Birincisi standart yazarlarının varlık sahipliği ortadan kalktığında bu kavramın yerine koyacak bir kavram aradığı ve varlık kelimesini kullanmamak için de bu kavramı icat ettiği varsayımına dayanıyor. Buna göre her bir risk senaryosu için zarara uğrayacak şeyin (süreç veya varlık) sahibi olarak yorumlayabiliriz risk sahipliğini. Diğer alternatif, risk sahipliği kavramının 6.1.3.f’teki risk işleme planı ve artık riski onaylama ile ilgili maddede geçmesine dayanıyor. Bu görev daha önceki standartta yönetime aitti. Şimdi de böyle olması gerektiğini varsayarsak risk sahipleri yönetim kademesinden kişiler olmalı diye düşünebiliriz. Standart yazarları kusura bakmasınlar ama bu durumda bizim bir delinin kuyuya taşı atması ve kırk akıllının çıkaramaması hikayesindeki deli rolünü üstlenmiş görünüyorlar.
- İletişim 2005 versiyonunda da vurgulanan bir konuydu. 7.4 iletişim maddesi ise neyin, ne zaman, kiminle, kim tarafından ve hangi süreçlerle ilgili olarak iletişiminin yapılması gerektiğinin belirlenmesi şartını getiriyor. Sizi bilmem ama bu benim kulağıma dokümantasyon işi gibi geliyor. Diğer alanlarda durum fena değilse denetçi için günü kurtaracak bir bulgu olabilir.
- Biraz zorlama olur, ama 8.1 operasyonel planlama ve kontrol maddesinin ikinci paragrafı canını sıktığınız denetçiler için bir bulgu vesilesi olabilir. Bu madde güvenlikle ilgili süreçlerin planlandığı gibi işletildiğine ilişkin güvence verecek nitelikte dokümantasyon şartı getiriyor. Küçük işletmeler için biraz insafsız bir bulgu olur, ama geniş bir organizasyon için bu maddenin bulgu doğurma ihtimali var.
- Madde 8.1’in son paragrafı dış kaynak kullanılan süreçlerin belirlenmesi ve kontrol edilmesi şartını içeriyor. Tedarikçi riskleri elbette 2005 versiyonunda da ISO27002 dokümanında yer alan kontroller nedeniyle önemliydi. Ancak yönetim sistemi standardında bu kadar net yer almış değildi. Tedarikçi risk yönetimini uygulama maalesef çok kolay değil, çok fazla iş gücü gerektiriyor. Bu kısıt nedeniyle tedarikçi risklerini gerektiği gibi yöneten pek fazla kurum yok. Bu durum da bu konuda bir bulguyu cepte saymamıza imkan tanıyabilir.
- A.6.1.5 Proje yönetiminde bilgi güvenliği
- A.14.2.8 Sistem güvenlik testleri (evet, 27001 denetiminde de olsa artık daha fazla sızma testi yaptırmıyorsunuz bulgusu göreceğiz)
ISO27001’in 2005 versiyonunda bulunan standart
gereksinimleri bu makalenin konusunun dışındadır. Bu makalede geçiş dolayısıyla
denetçilerin önünde hazır bekleyen duran toplara değindik.
Makalede kullandığım standart madde adları TSE’nin dokümanı
ile örtüşmeyebilir.
