İş Sürekliliği Planı (BCP) Nasıl Hazırlanır?

Bir kesinti yaşandığında müşteriler sunucunuzun neden çöktüğüyle değil, siparişlerinin ne zaman yola çıkacağıyla ilgilenir. İş sürekliliği planı (Business Continuity Plan, BCP) tam da bu noktaya odaklanır: teknoloji, tesis veya tedarik zincirinde ne yaşanırsa yaşansın, işletmenin en kritik faaliyetlerini kabul edilebilir bir düzeyde sürdürebilmesi. Bu rehberde BCP'yi, büyük kurumlar kadar KOBİ'lerin de uygulayabileceği pratik bir çerçeveyle ele alıyoruz.

İş Sürekliliği Planı Nedir, Neden Gereklidir?

İş sürekliliği planı, işletmenin ciddi bir kesinti sırasında ve sonrasında kritik faaliyetlerini nasıl sürdüreceğini, kimin hangi kararı vereceğini ve normale nasıl döneceğini tanımlayan belgelenmiş bir yol haritasıdır. Kapsamı yalnızca BT değildir: insanlar, çalışma alanları, tedarikçiler, müşteri iletişimi ve yasal yükümlülükler de planın parçasıdır.

BCP'nin gerekliliği birkaç noktada kendini gösterir:

• Kurumsal müşteriler, tedarikçi değerlendirmelerinde iş sürekliliği düzenlemelerinizi sorgulayabilir.
• Finans ve sağlık gibi düzenlemeye tabi sektörlerde süreklilik ve felaket kurtarma hazırlığı denetimlerin konusudur.
• Siber sigorta başvurularında yedekleme, kurtarma ve olay müdahale hazırlığına ilişkin sorular yer alır.
• En önemlisi, kriz anında karar almayı hızlandırır ve kaosu azaltır.

Bu alanda uluslararası kabul görmüş çerçeve, ISO 22301 İş Sürekliliği Yönetim Sistemi standardıdır. Belgelendirme hedeflemeseniz bile standardın yapısını izlemek, planın eksiksiz olmasına yardımcı olur.

İyi bir BCP belgesinde neler bulunur?

• Planın kapsamı, amacı ve plan sahibi.
• İş etki analizi sonuçları ve kritik süreçlerin öncelik sırası.
• Kriz ekibi, roller, yedek kişiler ve güncel iletişim bilgileri.
• Krizin hangi koşullarda ilan edileceği ve ilk saatlerde yapılacaklar.
• Her kritik süreç için alternatif çalışma yöntemleri ve kurtarma adımları.
• BT felaket kurtarma planına ve tedarikçi sözleşmelerine atıflar.
• Test takvimi, revizyon geçmişi ve onay bilgileri.

Belgeyi olabildiğince kısa ve uygulanabilir tutun. Kriz anında kimse yüzlerce sayfalık bir dokümanı okumaz; her rol sahibinin kendi bölümünü birkaç dakikada bulup uygulayabilmesi gerekir.

İş Etki Analizi (BIA) ve Risk Değerlendirmesi

BCP'nin temeli iş etki analizidir (Business Impact Analysis, BIA). BIA, bir süreç durduğunda zaman içinde ne kadar zarar oluştuğunu ortaya koyar. Her iş süreci için şu bilgiler toplanır:

• Sürecin kesintisi hangi etkileri doğurur? Gelir kaybı, sözleşme cezası, müşteri kaybı, yasal yaptırım ve itibar zararı gibi.
• Etki zamanla nasıl büyür? İlk saatte, ilk günde ve ilk haftada durum nedir?
• Kabul edilebilir en uzun kesinti süresi nedir?
• Süreç hangi kişilere, sistemlere, verilere, tedarikçilere ve tesislere bağımlıdır?
• Kesinti sırasında manuel veya alternatif bir çalışma yöntemi mümkün mü?

Risk değerlendirmesi ise bu süreçleri tehdit eden olayların olasılığını ve etkisini inceler: siber saldırılar, uzun elektrik kesintileri, deprem ve yangın, kilit personelin kaybı, ana tedarikçinin hizmet verememesi, internet bağlantısının kopması. BIA neyin korunacağını, risk değerlendirmesi ise neye karşı korunacağını söyler. İkisi birlikte değerlendirilerek öncelik listesi oluşturulur.

BIA toplantılarını BT değil, süreç sahipleri yönetmelidir. BT'nin rolü, her sürecin arkasındaki teknoloji bağımlılıklarını görünür kılmaktır. Pratikte her süreç sahibiyle yapılan kısa ve yapılandırılmış görüşmeler, uzun anket formlarından daha doğru sonuç verir.

Kritik Süreçler ve BT Bağımlılıklarının Haritalanması

BIA sonucunda öne çıkan kritik süreçler, teknoloji bağımlılıklarıyla birlikte haritalanmalıdır. Örneğin bir üretim firmasında sevkiyat süreci; ERP'deki sipariş kayıtlarına, depo barkod sistemine, e-irsaliye entegrasyonuna, etiket yazıcılarına, internet bağlantısına ve etki alanı hizmetlerine bağlıdır. Bunlardan biri çalışmazsa süreç durur.

Haritalama için pratik bir yöntem:

1. Her kritik süreç için kullanılan uygulamaları listeleyin.
2. Her uygulamanın çalıştığı sunucuyu, veritabanını ve bağımlı olduğu altyapı hizmetlerini (kimlik doğrulama, DNS, lisans sunucusu, ağ bağlantısı) yazın.
3. Dış bağımlılıkları ekleyin: SaaS hizmetleri, entegratörler, banka bağlantıları, bakım ve destek firmaları.
4. Tek hata noktalarını işaretleyin: tek internet hattı, yalnızca bir kişinin bildiği bir parola, tek kopyası olan bir yapılandırma.
5. Her bağımlılığın kurtarma hedefini süreçten türetin: sürecin en geç dört saat içinde yeniden işler hale gelmesi gerekiyorsa, bağımlı her sistemin de bu süre içinde geri getirilebilmesi gerekir.

Geçici çalışma yöntemlerini önceden tasarlayın

Sistemler geri gelene kadar işin tamamen durması gerekmez. Birçok kritik süreç için basit ama önceden hazırlanmış geçici yöntemler tanımlanabilir: siparişlerin düzenli olarak dışa aktarılan bir liste üzerinden takip edilmesi, sevkiyat belgelerinin alternatif bir yöntemle hazırlanması, çağrı merkezinin mobil hatlara yönlendirilmesi veya kritik raporların son güncel kopyasının güvenli bir yerde tutulması gibi. Bu yöntemlerin işe yaraması için hangi verinin, hangi formatta ve ne sıklıkla hazır tutulacağı planda yazılı olmalı ve ilgili çalışanlar bunları tatbikatta en az bir kez denemiş olmalıdır. Sistemler geri geldiğinde geçici yöntemlerle yürütülen işlemlerin ana sisteme nasıl aktarılacağı da unutulmamalıdır.

Bu harita, BT tarafındaki felaket kurtarma planının doğrudan girdisidir. Üretim tesislerinde operasyonel teknoloji (OT) ile BT sistemleri arasındaki bağımlılık özellikle dikkat ister; bu konudaki yaklaşımımızı sanayi ve imalat sektörü sayfamızda bulabilirsiniz.

Veri Merkezi ve Altyapı Yedekliliği

Kritik süreçlerin sürekliliği, altyapıdaki tek hata noktalarının azaltılmasına bağlıdır. Sunucu odası veya veri merkezi düzeyinde değerlendirilmesi gereken başlıklar şunlardır:

• Enerji: UPS kapasitesi ve süresi, jeneratör varlığı ve düzenli bakımı, uzun kesintide sistemlerin kontrollü kapanma senaryoları.
• Soğutma ve ortam: Klimaların yedekliliği, sıcaklık ve su baskını sensörleri, uzaktan uyarı mekanizmaları.
• Ağ ve bağlantı: Farklı altyapıları kullanan iki internet hattı, yedekli güvenlik duvarı ve çekirdek anahtar. Bu konuyu kesintisiz ağ tasarımı rehberimizde detaylandırdık.
• Sunucu ve depolama: Sanallaştırma kümeleri, yedekli güç kaynakları, RAID ve kritik sistemler için replikasyon.
• Yedekleme: Tesis dışı ve değiştirilemez kopyalar sayesinde binaya erişilemediğinde bile verinin güvende olması.
• Tesis dışı barındırma: Kritik iş yüklerinin profesyonel bir veri merkezinde veya bulutta çalıştırılması, ofisteki fiziksel risklerden bağımsızlık sağlar.

Yedeklilik maliyetlidir ve her sistem için gerekli değildir. BIA'da kritik çıkan süreçlerin bağımlı olduğu bileşenlere öncelik vermek, bütçenin en çok fark yaratacak yere gitmesini sağlar.

Bulut ve SaaS hizmetleri de bu değerlendirmenin dışında kalmamalıdır. E-posta, dosya paylaşımı veya muhasebe buluttaysa, ofisin internet bağlantısı kesildiğinde bu hizmetlere nasıl erişileceği, sağlayıcıda bir kesinti yaşanırsa hangi geçici yöntemlerin kullanılacağı ve bu verilerin bağımsız bir yedeğinin olup olmadığı planda cevaplanmalıdır. Altyapının bir kısmının başka bir firmaya devredilmiş olması, süreklilik sorumluluğunun da devredildiği anlamına gelmez.

Kriz İletişimi ve Rol Dağılımı

Krizler çoğu zaman teknik yetersizlikten değil, kimin ne yapacağının belirsizliğinden büyür. Planda şu roller açıkça tanımlanmalıdır:

• Kriz yönetim ekibi lideri: Krizi ilan eder, öncelikleri belirler, acil harcama kararlarını verir.
• BT kurtarma sorumlusu: Felaket kurtarma prosedürlerini yürütür, iç ekibi ve dış destek firmalarını koordine eder.
• İletişim sorumlusu: Çalışanlara, müşterilere, tedarikçilere ve gerekirse kamuoyuna yapılacak açıklamaları hazırlar.
• İş birimi temsilcileri: Kendi süreçlerinde alternatif çalışma yöntemlerini devreye alır.
• Hukuk ve uyum sorumlusu: Kişisel veri ihlali söz konusuysa KVKK kapsamındaki bildirim yükümlülüklerini yönetir.

Her rol için bir yedek kişi belirleyin. İletişim planında güncel telefon listesi, kurumsal e-posta çalışmazsa kullanılacak alternatif kanal, müşterilere yönelik hazır mesaj şablonları ve fiziksel toplanma yeri bulunmalıdır. Çalışanların evden çalışabilmesi için uzaktan erişim altyapısının, lisansların ve dizüstü bilgisayarların hazır olması da kriz senaryolarının önemli bir parçasıdır.

Mesaj şablonları önceden yazılmalıdır; kriz anında sıfırdan metin hazırlamak hem zaman kaybettirir hem de tutarsız açıklamalara yol açar. Şablonlarda ne olduğu, müşteriyi nasıl etkilediği, ne zaman yeni bilgi verileceği ve kime ulaşılabileceği yer almalıdır.

Tatbikat, Test ve Sürekli İyileştirme

Kâğıt üzerindeki plan ancak denendiğinde güvenilir hale gelir. Test programı kademeli olmalıdır:

1. Plan okuması: Rol sahipleri planı okur ve kendi bölümlerini doğrular.
2. Masa başı tatbikat: Gerçekçi bir senaryo, örneğin pazartesi sabahı tüm sunucuların şifrelendiğinin fark edilmesi, adım adım konuşulur. Karar noktaları, iletişim akışı ve bilgi eksikleri ortaya çıkar.
3. Teknik kurtarma testi: Kritik sistemler DR ortamında ayağa kaldırılır ve süreler ölçülür.
4. Kapsamlı tatbikat: Bir iş birimi alternatif lokasyondan veya evden, yedek sistemlerle belirli bir süre boyunca çalışır.

Her tatbikattan sonra kısa bir değerlendirme toplantısı yapın; neyin işe yaradığını, neyin aksadığını ve kimin neyi ne zamana kadar düzelteceğini kaydedin. Plan; organizasyon değişikliklerinde, yeni sistemler devreye girdiğinde, tedarikçi değiştiğinde ve gerçek bir olay yaşandıktan sonra güncellenmelidir. ISO 22301 yaklaşımında olduğu gibi planla, uygula, kontrol et ve önlem al döngüsüyle yönetilen bir BCP canlı kalır.

Sık Yapılan Hatalar ve BCP Kontrol Listesi

• BCP'yi yalnızca BT'nin sorumluluğu olarak görmek ve iş birimlerini sürece katmamak.
• Planı bir kez yazıp rafa kaldırmak; iletişim listelerinin ve prosedürlerin zamanla eskimesi.
• Tüm senaryoları sistemlerin çökmesi üzerine kurup binaya veya kilit personele erişilemeyen durumları atlamak.
• Kritik tedarikçilerin kendi süreklilik düzenlemelerini sorgulamamak.
• Planı yalnızca kesintiden etkilenebilecek bir sistemde, örneğin dosya sunucusunda saklamak.

Kontrol listesi:

1. İş etki analizi yapıldı ve kritik süreçler, kabul edilebilir kesinti süreleriyle birlikte belirlendi mi?
2. Her kritik sürecin teknoloji ve tedarikçi bağımlılıkları haritalandı mı?
3. Kriz ekibi, roller ve yedek kişiler tanımlandı mı?
4. Alternatif iletişim kanalları, güncel iletişim listesi ve mesaj şablonları hazır mı?
5. BT tarafındaki felaket kurtarma planı bu hedeflerle uyumlu mu?
6. Son tatbikat ne zaman yapıldı ve bulgular kapatıldı mı?
7. Plan, ana sistemler çalışmadığında da erişilebilecek bir yerde saklanıyor mu?

Sonuç

İş sürekliliği planı bir krizi tamamen önleyemez, ama onun işletmeyi ne kadar sarsacağını büyük ölçüde belirler. IT danışmanlık hizmetlerimiz kapsamında iş etki analizinden tatbikatlara kadar BCP sürecini sizinle birlikte kurgulayabilir, teknik altyapıyı bu hedeflere göre tasarlayabiliriz. Hazırlık durumunuzu birlikte değerlendirmek için ücretsiz bir ön görüşme ayarlayalım.