Изготвяне на план за непрекъсваемост в бизнеса

Прекъсването на ключова система рядко започва като мащабна криза. Понякога е криптиран файлов сървър, недостъпен облачен акаунт, повреден архив или липса на човек с нужния достъп. Ако обаче организацията не знае кои процеси са критични, какъв престой може да понесе и кой взема решенията, малкият технически проблем бързо се превръща във финансов, договорен и репутационен риск. Затова изготвяне на план за непрекъсваемост не е формално изискване, а управленска задача с пряко отражение върху способността на бизнеса да работи.

Какво решава планът за непрекъсваемост

Планът за непрекъсваемост на бизнеса, често наричан Business Continuity Plan или BCP, определя как организацията ще поддържа или възстанови критичните си дейности при инцидент. Той не се ограничава до ИТ инфраструктурата. В обхвата му попадат хората, помещенията, доставчиците, документите, комуникацията с клиенти и регулаторните задължения.

За една търговска компания критичният процес може да е обработването на поръчки и фактури. За счетоводна кантора – достъпът до клиентски архиви и специализиран софтуер. При производствено предприятие това може да са системите за планиране, доставките или обменът на данни с ключови партньори. Универсален шаблон не може да определи тези приоритети вместо ръководството.

Добре разработеният план дава ясен отговор на няколко практически въпроса: какво трябва да бъде възстановено първо, в какъв срок, от кои хора, с какви ресурси и как ще се докаже, че възстановяването е успешно. Точно тази яснота ограничава импровизацията в първите часове след инцидент.

Изготвяне на план за непрекъсваемост започва с анализ на въздействието

Първата работна стъпка е Business Impact Analysis – анализ на въздействието върху бизнеса. Неговата цел не е да изброи всички приложения и устройства, а да свърже технологиите с реалните бизнес процеси.

За всеки процес се оценяват последствията при прекъсване: пропуснати приходи, договорни неустойки, невъзможност за обслужване на клиенти, риск за лични данни, нарушения на нормативни срокове и репутационни щети. Важно е да се установи и зависимостта между процесите. Например възстановяването на ERP система няма да помогне достатъчно, ако служителите нямат работеща идентичност, мрежов достъп или актуални данни за клиентите.

RTO и RPO: два показателя, които не бива да се смесват

RTO – Recovery Time Objective – е максимално допустимото време за възстановяване на дадена услуга. Ако фирмата може да приема поръчки ръчно един ден, но не и три дни, RTO за системата за поръчки следва да отразява тази реалност.

RPO – Recovery Point Objective – показва колко данни организацията може да си позволи да загуби. При архивиране веднъж дневно потенциалната загуба може да достигне почти 24 часа работа. Това може да е приемливо за част от документите, но не и за транзакции, финансови записи или чувствителни клиентски данни.

По-кратките RTO и RPO обикновено изискват повече инвестиции – репликация, резервна инфраструктура, по-чести архиви и специализиран капацитет. Правилният избор не е максималната техническа защита на всяка цена, а обосновано ниво на защита за всеки критичен процес.

Определете реалистични сценарии, а не абстрактни рискове

Планът работи по-добре, когато е изграден около конкретни сценарии. Кибератака с криптиране на файлове изисква различна реакция от прекъсване на интернет свързаността, физически инцидент в офис или отказ на външен доставчик на облачна услуга. Общите принципи се припокриват, но решенията и отговорните лица не винаги са едни и същи.

Полезно е да се разгледат поне следните групи сценарии:

• компрометиране на системи, акаунти или крайни устройства;
• загуба, повреда или недостъпност на данни и документални архиви;
• отпадане на електрозахранване, свързаност, сървърна или облачна услуга;
• липса на ключови служители, доставчици или работно място;
• инциденти, свързани с лични данни и задължение за уведомяване.

За всеки сценарий трябва да има практически ред на действията: кой констатира проблема, кой активира плана, как се изолира засегнатата среда, кой одобрява възстановяването и как се комуникира с персонал, клиенти, доставчици и компетентни органи. Контактите не бива да са налични само в недостъпна вътрешна система.

Архивът не е равен на възстановяване

Много организации приемат, че наличието на резервно копие автоматично гарантира непрекъсваемост. Това е опасно допускане. Архивът може да е непълен, повреден, недостъпен поради липса на права или също да е засегнат от злонамерен код. Може да липсват инструкции за възстановяване на бази данни, конфигурации, виртуални машини и връзки между приложенията.

Затова политиката за резервни копия трябва да посочва какви данни се архивират, колко често, къде се съхраняват, колко време се пазят и кой проверява резултатите. Съхранението в отделена и защитена среда намалява риска един инцидент да унищожи едновременно продукционните системи и копията им.

Необходима е и процедура за възстановяване по приоритети. Най-напред може да се възстановят идентичностите и мрежовите услуги, след това критичните приложения и данните, а накрая второстепенните системи. Последователността зависи от архитектурата и от резултатите от анализа на въздействието.

Отговорностите трябва да са изпълними в напрегната ситуация

План, който възлага всички задачи на „ИТ отдела“, не е оперативен план. В малките и средните предприятия често няма вътрешен екип с необходимата специализация или 24/7 наличност. Следва предварително да бъдат определени ръководител на инцидента, заместник, технически отговорник, лице за вътрешна и външна комуникация, отговорник по защита на данните и лица за връзка с ключови доставчици.

Всяка роля трябва да има конкретни правомощия. При ransomware например техническият екип може да изолира системите, но решението за преминаване към резервна среда, уведомяване на клиенти или временно спиране на услуга изисква управленска отговорност. Предварително договорените правила съкращават времето за реакция и намаляват риска от противоречиви действия.

Външен IT и киберсигурност партньор може да осигури специализиран капацитет за мониторинг, възстановяване и документация. Това не отменя отговорността на ръководството, но дава възможност решенията да се изпълнят методично, включително извън стандартното работно време.

Свържете непрекъсваемостта със съответствието

За организациите, които обработват лични данни, непрекъсваемостта е пряко свързана с GDPR. Регламентът изисква мерки за гарантиране на постоянна поверителност, цялостност, наличност и устойчивост на системите и услугите, както и способност за своевременно възстановяване на наличността и достъпа до данни след инцидент.

ISO 27001 разглежда непрекъсваемостта като част от управлението на информационната сигурност, а не като отделен технически документ. При субекти в обхвата на NIS2 или DORA очакванията за управление на риска, реакция при инциденти, тестване и контрол над доставчиците са още по-конкретни. Приложимостта на всяка регулация зависи от сектора, размера и ролята на организацията, но липсата на доказуеми процедури винаги затруднява проверка, одит или разследване.

Ето защо планът следва да бъде обвързан с регистъра на рисковете, политиките по информационна сигурност, процедурите за управление на инциденти, регистрите на обработване и договорите с доставчици. Така се избягва разминаването между написаното в документите и реалните технически възможности.

Тествайте плана, преди да е необходим

Нетестваният план е предположение. Тестът не трябва непременно да започва с пълно прекъсване на работата. Настолна симулация с ръководството може да провери дали хората знаят кого да потърсят и какви решения да вземат. След това техническите тестове могат да включват възстановяване на отделен файл, база данни, виртуална машина или цяла услуга в контролирана среда.

Критичният показател не е само дали данните са възстановени, а дали са възстановени в договорените RTO и RPO. Всеки тест трябва да оставя доказателства: дата, обхват, участници, измерено време, открити пропуски и коригиращи действия. Това е ценно и за управлението, и при одити по ISO 27001, GDPR или секторни изисквания.

Планът се преразглежда при промяна на софтуер, облачен доставчик, организационна структура, ключови служители или критични договори. Практиката показва, че именно тези промени правят старите процедури неизползваеми.

Непрекъсваемостта не се постига с документ в папка, а с поддържана способност за действие. Когато приоритетите, архивите, ролите и тестовете са съгласувани, организацията може да възстанови контрол над ситуацията и да защити най-важното – данните, клиентите и доверието в бизнеса.