ISO 22301 denetiminde madde madde istenen kanıtlar: iş etki analizi, risk değerlendirmesi, süreklilik stratejileri, tatbikat kaydı ve RTO/RPO restore testi.
Hızlı Özet (TL;DR)
ISO 22301, deprem, yangın, sel gibi doğal afetlerin yanı sıra fidye yazılımı, elektrik kesintisi veya kritik sunucu arızaları gibi operasyonel felaketler karşısında kurumların işlerini asgari düzeyde de olsa sürdürebilme yeteneğini belgeleyen uluslararası İş Sürekliliği Yönetim Sistemi (İSYS) standardıdır. Savunma sanayii, bankacılık ve otomotiv ana tedarikçileri için ISO 22301 belgelendirmesi, tedarik zincirinde aksama yaşanmayacağının en büyük garantisidir. Başarılı bir denetimden geçmek için yalnızca yazılı prosedürler değil; İş Etki Analizi (BIA) tabloları, canlı tatbikat tutanakları ve zaman tutulmuş RTO/RPO yedekten dönme (restore) test kanıtları sunulmalıdır.
ISO 22301 Denetiminde Başdenetçinin Bakış Açısı: Kağıttan Kanıta Geçiş
Birçok işletme ISO 22301 sürecini yalnızca kalite departmanının hazırladığı klasörlerden ibaret sanarak denetimlerde majör uygunsuzluklarla karşılaşmaktadır. Oysa akredite belgelendirme denetçileri, standart maddelerini incelerken dokümanların sahadaki bilgi teknolojileri (BT) ve üretim altyapısıyla birebir örtüşüp örtüşmediğini sorgular.
Özellikle savunma sanayii ve imalat siber güvenlik denetimlerinde veya otomotiv ana sanayii (OEM) tedarikçi teftişlerinde denetçi şu temel soruyu sorar: “Fabrikanızdaki ana sunucu odası bu gece tamamen devre dışı kalırsa veya tüm sanal sunucularınız fidye yazılımıyla şifrelenirse, müşterinize söz verdiğiniz sevkiyatı kaç saat içinde ve hangi alternatif sistem üzerinden devam ettirebilirsiniz?” Bu sorunun yanıtı varsayımlarla değil, teknik metriklerle ve test loglarıyla verilmek zorundadır.
ISO 22301 Denetiminde Aranan Temel Unsurlar ve Madde Madde Kanıtlar
Denetim esnasında Madde 8 (Operasyon) başlığı altında denetçiye ibraz edilmesi gereken zorunlu çıktılar ve teknik kanıtlar şunlardır:
| Standart Maddesi | Başlık | Beklenen Çıktı ve Doküman | Denetçinin İncelediği Saha Kanıtı |
|---|---|---|---|
| Madde 8.2.2 | İş Etki Analizi (BIA) | Hangi süreçlerin durmasının kurumu ne kadar zarara soktuğunun hesaplanması | Departman bazlı RTO, RPO, MTPD (Azami Kabul Edilebilir Kesinti Süresi) ve MBCO (Asgari İş Sürekliliği Hedefi) matrisleri |
| Madde 8.2.3 | Risk Değerlendirmesi | Siber saldırı, donanım arızası, enerji kesintisi ve tesis risklerinin puanlanması | Tek hata noktalarının (SPOF - Single Point of Failure) tespiti ve azaltım aksiyon planları |
| Madde 8.3 | İş Sürekliliği Stratejileri | İkiz veri merkezi (DRC), bulut yedekleme, yedek internet hattı, alternatif tedarikçi kanalları | Yedekleme topolojisi, 3-2-1-1 kuralı mimarisi, jeneratör yakıt sözleşmeleri ve SLA kontratları |
| Madde 8.4 | İş Sürekliliği Planları (BCP) | Kriz anında kimin, hangi sırayla ne yapacağını belirleyen görev dağılım kartları | Kriz yönetim ekibi iletişim listesi, acil durum eskalasyon şeması ve sistem ayağa kaldırma (Runbook) kılavuzları |
| Madde 8.5 | Tatbikat ve Testler | Yılda en az bir kez senaryo bazlı kriz tatbikatı yapılması ve raporlanması | Tarih/saat damgalı restore test ekran görüntüleri, kronometre tutanakları ve tatbikat sonrası düzeltici faaliyet (DÖF) kayıtları |
Madde 8.2.2: İş Etki Analizi (BIA) ve MTPD / MBCO Hesaplaması
İş Etki Analizi, ISO 22301 sisteminin omurgasıdır. Kurumdaki her kritik iş süreci (üretim planlama, CNC işleme, kalite kontrol, sevkiyat/e-irsaliye, muhasebe) için kesintinin zamana bağlı finansal, yasal ve itibar etkisi ölçülür. Burada iki kritik parametre belirlenir:
- MTPD (Maximum Tolerable Period of Disruption - Azami Kabul Edilebilir Kesinti Süresi): Bir sürecin, şirketin varlığını veya ana müşteri sözleşmesini tehlikeye atmadan durabileceği en uzun süredir. Örneğin; JIT (Tam Zamanında) teslimat yapan bir yan sanayi firmasında sevkiyat/e-irsaliye sisteminin MTPD değeri 8 saat iken, Ar-Ge eğitim portalının MTPD değeri 2 hafta olabilir.
- MBCO (Minimum Business Continuity Objective - Asgari İş Sürekliliği Hedefi): Kriz anında tam kapasiteye dönene kadar şirketin hayatta kalması için gereken minimum üretim veya hizmet yüzdesidir (örneğin normal kapasitenin %40’ı).
Madde 8.2.3 ve 8.3: Tek Hata Noktalarının (SPOF) Ortadan Kaldırılması
Denetçiler sistem odası ve ağ topolojisini incelerken “Tek Hata Noktası” (Single Point of Failure) ararlar. Eğer fabrikanızda çok güçlü bir sunucu var ancak tek bir switch üzerinden ağa bağlanıyorsa veya tek bir internet servis sağlayıcı (ISP) hattı kullanılıyorsa, BIA tablosunda yazdığınız “2 saatlik kurtarma hedefi” gerçekçi bulunmaz. Kurumsal süreklilik için yedekli güvenlik duvarı (High Availability Firewall) mimarisi, çift fiber/metro internet hattı ve RAID/SAN yedekliliği strateji dokümanlarında kanıtlanmalıdır.
RTO ve RPO Değerlerinin Belirlenmesi ve Teknik Doğrulaması
İş Etki Analizi sonucunda her bilgi sistemi ve veritabanı için iki temel mühendislik metriği tanımlanır:
- RTO (Recovery Time Objective - Kurtarma Süresi Hedefi): Bir sunucunun, sanallaştırma kümesinin veya ERP sisteminin çöktükten sonra en fazla kaç dakika veya saat içinde yeniden çalışır hale getirileceğidir. RTO değeri hiçbir zaman MTPD değerinden büyük olamaz ($RTO < MTPD$).
- RPO (Recovery Point Objective - Kurtarma Noktası Hedefi): Felaket anında geriye dönük en fazla kaç dakikalık veya saatlik veri kaybına tahammül edilebileceğidir. Bu metrik doğrudan yedekleme (backup) ve replikasyon sıklığını belirler.
Örneğin; BIA dokümanında ERP veritabanı için RPO = 1 saat ve RTO = 2 saat yazılmışsa, denetçi BT yöneticisinden yedekleme yazılımının (Veeam, Acronis vb.) ekranını açmasını ister. Eğer yedekleme görevi yalnızca gece 24:00’te günde bir kez çalışacak şekilde ayarlanmışsa, gerçek RPO 24 saattir ve bu durum denetimde doğrudan Majör Uygunsuzluk sebebidir.
Denetimde En Çok Sorulan Kanıt: Canlı RTO/RPO Restore Testi ve Tatbikat Kayıtları
ISO 22301 Madde 8.5 kapsamında bu hedeflerin sadece kağıt üzerinde kalmadığı, periyodik yedekten dönme (restore) testleriyle ve senaryo tatbikatlarıyla ispatlanması istenir. Kusursuz bir tatbikat ve restore test raporu şu somut kanıtları içermelidir:
1. Yedekten Dönme (Restore) Test Tutanakları
Alınan yedeklerin çalışıp çalışmadığı yalnızca “Backup Successful” (Yedekleme Başarılı) e-postasıyla kanıtlanamaz. Yedek dosyasının bozuk (corrupted) olmadığını ve hedeflenen RTO süresinde açılabildiğini göstermek için izole bir test ortamına (Sandbox VLAN) sanal makine geri yükleme testi yapılır:
- Test Başlangıç Zamanı: Örneğin Saat 10:00’da 850 GB boyutundaki ERP sanal sunucu yedeğinin geri yükleme işlemi başlatılır ve ekran görüntüsü alınır.
- Test Bitiş ve Doğrulama Zamanı: Saat 11:18’de sanal sunucunun açıldığı, SQL veritabanı servislerinin başladığı ve ERP arayüzüne giriş yapılarak son kesilen faturanın görüntülendiği ekran görüntüsüyle belgelenir.
- Sonuç Kanıtı: Hedeflenen RTO 2 saat (120 dakika) iken, fiili kurtarma süresi 78 dakika olarak ölçülmüş ve hedef doğrulanmıştır.
2. Fidye Yazılımı ve Felaket Senaryosu Masa Başı / Canlı Tatbikatları
Yılda en az bir kez kriz yönetim ekibinin katılımıyla gerçekçi bir felaket senaryosu (örneğin: “Salı günü saat 14:00’te üretim sunucuları fidye yazılımıyla şifrelendi ve ana sistem odasında elektrik panosu yandı”) tatbik edilir. Tatbikat raporunda; olayın fark edilme süresi, kriz komitesinin toplanma tutanağı, değiştirilemez (Immutable) yedeklerden veya felaket kurtarma merkezinden (DRC) sistemlerin devreye alınma adımları ve tatbikat sırasında fark edilen aksaklıklar (örneğin yedek sunucuda lisans anahtarının eksik çıkması) şeffaf biçimde kaydedilir. Denetçiler “hiçbir sorun çıkmadı” denilen yapay raporlar yerine, eksikliklerin tespit edilip düzeltici faaliyet (DÖF) açıldığı gerçekçi tatbikat kayıtlarına tam puan verir.
İş sürekliliği odaklı güvenli sunucu ve yedekleme altyapıları için Sunucu ve Yedekleme Hizmetleri ve Ortak Dosya Sunucusu ve Yedekleme sayfalarımızı inceleyebilir, yasal kayıt bütünlüğü için KVKK ve 5651 Yasal Loglama çözümlerimizden yararlanabilirsiniz.
Sıkça Sorulan Sorular
ISO 27001 belgemiz var, yine de ISO 22301 denetimi için ayrı tatbikat yapmalı mıyız?
Evet. ISO 27001 Bilgi Güvenliği Yönetim Sistemi içinde iş sürekliliği (Ek-A 5.29 ve 5.30 maddeleri) yalnızca bilgi güvenliği kesintileri bağlamında özet olarak yer alır. ISO 22301 ise çok daha kapsamlıdır; yalnızca BT sistemlerini değil, üretim hatlarını, tedarik zincirini, insan kaynağını ve lojistik süreçlerini de kapsayan uçtan uca İş Etki Analizi (BIA) ve ölçülebilir RTO/RPO tatbikatları şart koşar.
Yedeklerimizi harici diske (NAS) alıyoruz, ISO 22301 denetimi için yeterli midir?
Aynı sistem odası içinde duran ve ağa standart SMB protokolüyle bağlı olan bir NAS cihazı ISO 22301 denetiminde tek başına yeterli kabul edilmez. Yangın, su baskını veya ağ üzerinden yayılan bir fidye yazılımı hem ana sunucuyu hem de yanındaki NAS cihazını aynı anda yok edebilir. Standardın Madde 8.3 gereksinimini karşılamak için 3-2-1-1 yedekleme kuralı uygulanmalı; en az bir kopya fiziksel olarak farklı bir lokasyonda (Off-site / Bulut) ve silinemez (Immutable / Air-Gapped) formatta tutulmalıdır.
RTO ve RPO sürelerini ne kadar düşük tutarsak denetimde o kadar iyi puan mı alırız?
Hayır, aksine gerçekçi olmayan hedefler denetimde uygunsuzluk almanıza yol açar. Örneğin 5 Terabaytlık bir dosya sunucusu için standart gigabit ağ ve tekil NAS altyapısıyla “RTO: 15 dakika, RPO: 0 dakika” yazarsanız, denetçi bunun fiziksel veri transfer hızıyla imkansız olduğunu anında tespit eder. Önemli olan sıfıra yakın rakamlar yazmak değil; işletmenin gerçek risk iştahına uygun, maliyet-fayda dengesi gözetilmiş ve canlı restore testleriyle %100 kanıtlanabilen hedefler belirlemektir.