Standart nedir
ISO 22301, iş sürekliliği yönetim sisteminin (İSYS) şartlarını tanımlar. Mevcut baskı 2019'dur. 9001, 14001, 45001 ve 27001 ile aynı 10 maddelik iskelete oturur.
Standardı diğerlerinden ayıran unsurlar 8. maddede toplanıyor ve iki tanesi bu standarda özgü:
Bunlardan ilki iş etki analizidir; hangi faaliyetin ne kadar süre durabileceğini ve kesinti uzadıkça etkinin nasıl büyüdüğünü belirler. İkincisi tatbikat ve test şartıdır; yazılan planların kâğıt üzerinde kalmadığının kanıtlanmasını zorunlu kılar.
ISO 31000 ile ilişkisi tamamlayıcıdır: risk yönetimi olayın olmasını engellemeye çalışır, iş sürekliliği olay olduktan sonra ne yapılacağını kurgular. İkisi aynı riskleri farklı açıdan ele alır.
ISO 27001'in erişilebilirlik boyutuyla da belirgin bir örtüşme var. Ancak 22301'in kapsamı daha geniştir: yalnızca bilgi sistemlerini değil tesisin, personelin, tedarikçilerin ve süreçlerin sürekliliğini de içine alır. Bilgi işlem tarafındaki felaket kurtarma planı, bu sistemin yalnızca bir parçasıdır.
İş etki analizi
Sistemin çekirdeğini oluşturan çalışmadır ve her kritik faaliyet için tek bir soruyla ilerler: bu faaliyet durursa zaman geçtikçe etki nasıl büyür? Sorunun cevabı bir tek sayı değil, kesinti süresine göre değişen bir eğridir.
Etkinin zamanla doğrusal artmadığı BIA'nın temel bulgusudur. İlk saatler tolere edilebilir; belirli bir eşikten sonra etki hızlanır — sözleşme cezaları devreye girer, müşteri kaybı kalıcılaşır, itibar zarar görür.
Analiz sırasında her faaliyet için dört bilgi toplanır: faaliyetin ürettiği çıktı, bağımlı olduğu kaynaklar (personel, sistem, tesis, tedarikçi), ona bağımlı olan diğer faaliyetler ve kesinti süresine göre etkinin nasıl büyüdüğü. Son madde olmadan kurtarma hedefi belirlenemez.
MTPD, RTO ve RPO
| Kısaltma | Açılımı | Anlamı | Kim belirler |
|---|---|---|---|
| MTPD | Maximum Tolerable Period of Disruption | Kesintinin kabul edilemez hale geldiği süre | BIA sonucu — bulunur |
| RTO | Recovery Time Objective | Hedeflenen kurtarma süresi | Yönetim kararı — seçilir |
| RPO | Recovery Point Objective | Göze alınabilecek maksimum veri kaybı süresi | Yönetim kararı — seçilir |
RTO zamanla, RPO ise veriyle ilgilidir ve ikisi birbirinden bağımsız kararlardır. Bir sistem dört saatte yeniden ayağa kalkabilir ama son yirmi dört saatlik veri kaybolmuş olabilir; bu durumda RTO dört saat, RPO ise yirmi dört saattir. Farklı yatırım gerektirdikleri için ayrı ayrı karara bağlanmaları gerekir.
Çözümlü örnek
BIA — takip ve sevk sistemi kesintisi
Sistem kesintisinin süreye göre kümülatif finansal etkisi ölçüldü.
| Kesinti süresi | Kümülatif kayıp (mn TL) | Saat başına ortalama | Etki niteliği |
|---|---|---|---|
| 1 saat | 0,4 | 0,40 | Operasyonel yavaşlama |
| 4 saat | 2,1 | 0,53 | Sevk gecikmesi |
| 8 saat | 5,8 | 0,72 | Vardiya kaybı, birikme |
| 24 saat | 19,5 | 0,81 | Teslimat taahhüdü ihlali başlıyor |
| 48 saat | 52,0 | 1,08 | Sözleşme cezaları, kurumsal müşteri kaybı |
| 72 saat | 98,0 | 1,36 | İtibar zararı, kalıcı müşteri kaybı |
| 168 saat | 240,0 | 1,43 | Pazar payı kaybı |
Artış = 1,36 ÷ 0,40 = 3,4 kat ⇒ etki doğrusal değil, hızlanan
Bu tablo BIA'nın neden gerekli olduğunu gösteriyor. "Sistem çökerse saatte şu kadar kaybederiz" cümlesi yanlıştır — kayıp hızı süreye bağlı olarak değişir.
MTPD belirleme
Üst yönetim, kabul edilemez kayıp eşiğini 50 milyon TL olarak belirledi.
Doğrusal ara değer: 24 + (50,0 − 19,5) ÷ (52,0 − 19,5) × 24 = MTPD ≈ 46,5 saat
RTO seçimi
Seçilen RTO = 24 saat
Güvenlik payı = (46,5 − 24) ÷ 46,5 = %48,4
24 saat seçilmesinin gerekçesi: eşiğin yarısına yakın bir pay bırakıyor ve kurtarma tahmininin sapması durumunda hâlâ MTPD'nin altında kalınıyor.
RPO seçimi
Sistem saatte yaklaşık 20.000 işlem kaydı üretiyor (günlük 480.000 gönderi).
| Yedekleme yöntemi | RPO | Kaybolabilecek kayıt | Maliyet |
|---|---|---|---|
| Günlük tam yedek | 24 saat | 480.000 | En düşük |
| 4 saatte bir artımlı | 4 saat | 80.000 | Orta |
| 15 dakikada bir | 0,25 saat | 5.000 | Yüksek |
| Sürekli replikasyon | ~0 | ~0 | En yüksek |
Kritik nokta: kaybolan her kayıt bir gönderinin takip bilgisidir. 480.000 kaydın kaybolması, o gönderilerin nerede olduğunun bilinmemesi demektir — bu, sistemin ayağa kalkmasından bağımsız, ayrı ve daha uzun süren bir kriz üretir. Bu yüzden RTO iyi ama RPO kötü olan bir kurtarma planı, çoğu zaman işe yaramaz.
Süreklilik stratejileri
| Kaynak | Strateji | Kargo operasyonunda karşılığı |
|---|---|---|
| Bilgi sistemi | Yedekli altyapı, felaket kurtarma merkezi | İkincil veri merkezi, çevrimdışı çalışma modu |
| Tesis | Alternatif lokasyon | Yakın aktarma merkezine yönlendirme planı |
| Personel | Çapraz eğitim, vekâlet | Kritik rollerin yedeklenmesi |
| Tedarikçi | Alternatif tedarikçi | İkinci taşeron anlaşması, çerçeve sözleşme |
| Süreç | Manuel çalışma modu | Sistem yokken kâğıt üzerinden sevk — RTO'yu fiilen uzatır |
Son satır önemlidir: geçici manuel mod, RTO'yu karşılamanın en ucuz yoludur. Sistem 24 saat içinde ayağa kalkacaksa ve bu süreyi kâğıt üzerinden idare edebiliyorsan, milyonluk yedek altyapıya gerek olmayabilir. Ama manuel modun önceden yazılmış, denenmiş ve personelin eğitilmiş olması gerekir; kriz anında icat edilmez.
Tatbikat
Standart planların test edilmesini ve düzenli tatbikat yapılmasını zorunlu tutar. Yazılı bir plan tek başına uygunluk kanıtı sayılmaz, çünkü bir planın kriz anında işleyip işlemeyeceği ancak denendiğinde görülebilir.
| Tatbikat türü | Kapsamı | Kesinti riski |
|---|---|---|
| Masa başı (tabletop) | Senaryo üzerinden tartışma | Yok |
| Yürüyüş (walkthrough) | Adımların fiilen gözden geçirilmesi | Çok düşük |
| Simülasyon | Gerçek koşullarda kısmi devreye alma | Orta |
| Tam devreye alma | Gerçek geçiş testi | Yüksek |
Sık karşılaşılan hatalar
Kurtarma hedefini iş etki analizi yapmadan belirlemek. MTPD bilinmeden seçilen bir RTO'nun dayanağı yoktur ve denetimde ilk sorulacak şey bu dayanaktır.
RTO ile RPO'yu karıştırmak. Biri kesintinin ne kadar süreceğini, diğeri ne kadar verinin kaybedilebileceğini tanımlar. Ayrı kararlardır ve farklı çözümler gerektirir.
Planı yazıp test etmemek. Denenmemiş bir plan, kriz anında çalışıp çalışmayacağı bilinmeyen bir plandır. Tatbikatın asıl çıktısı da planın onaylanması değil, ortaya çıkan eksiklerdir.
Kapsamı yalnızca bilgi sistemleriyle sınırlamak. Standart tesis, personel ve tedarikçi sürekliliğini de kapsar; bilgi işlem tarafındaki felaket kurtarma planı tek başına bir iş sürekliliği yönetim sistemi değildir.
Bağımlılıkları haritalamamak. Bir faaliyetin kurtarma süresi, bağımlı olduğu kaynağın kurtarma süresinden kısa olamaz. Zincir her zaman en yavaş halkanın hızıyla ilerler.
Tedarikçinin sürekliliğini varsaymak. Kritik bir tedarikçinin kendi iş sürekliliği yapısı sorgulanmadığında, kuruluşun planı görünmeyen bir noktadan kırılır.