План безперервності бізнесу (BCP) і план відновлення після катастроф (DRP): союзники у стійкості страхової компанії
В останні роки страхові компанії України функціонують у середовищі, яке важко назвати передбачуваним або контрольованим. Повномасштабна війна, регулярні кібератаки, перебої в енергопостачанні, ризики фізичного знищення офісів і дата-центрів — усе це не просто загрози. Це — нова норма. І в цій новій нормі компанії, які не підготувалися до сценаріїв катастроф, опиняються не лише під ризиком фінансових втрат, але й втрати довіри клієнтів, ділової репутації, ліцензії або самого існування. Саме тому поняття BCP (Business Continuity Plan — план безперервності бізнесу) та DRP (Disaster Recovery Plan — план відновлення після катастрофи) стають не формальністю, а критично важливими елементами управління ризиками.
BCP і DRP — це не просто документи, створені для «галочки» перед регулятором. Вони — як протипожежна сигналізація: краще, щоб не знадобилися, але якщо сталося — вони можуть врятувати компанію. BCP відповідає на запитання: «Що ми робимо, якщо бізнес-процеси припиняються?». DRP — це конкретна технічна інструкція: «Як ми відновимо системи, дані, комунікації?». Без першого — втрачається контроль. Без другого — паралізується операційна діяльність.
План безперервності бізнесу — це стратегічний документ, який описує, як компанія забезпечить роботу основних функцій у разі надзвичайної ситуації. Сюди входить: визначення критичних процесів, оцінка впливу їх зупинки (BIA — business impact analysis), встановлення пріоритетів відновлення, та розрахунок RTO (Recovery Time Objective — час, протягом якого функція має бути відновлена) і RPO (Recovery Point Objective — максимальний обсяг втрати даних, який компанія може дозволити).
DRP — це операційне продовження BCP, що стосується ІТ-інфраструктури. Він охоплює резервування даних, дублювання серверів, автоматичне перемикання на резервні майданчики, інструкції для технічного персоналу, перевірку цілісності баз даних та тестування на відновлюваність. Наприклад, якщо головний сервер в Києві знищено або зламано — DRP визначає, як швидко і куди має бути переміщено функції: у Львів, у хмару, на резервний дата-центр.
Розглянемо приклад. Якщо у компанії не працює система електронного врегулювання збитків понад 6 годин, втрачається можливість обробляти заявки клієнтів. Це — прямі втрати в грошах, репутації та відповідність вимогам НБУ. У BCP буде вказано, що цей процес критичний, а RTO для нього — 4 години. Тобто, протягом 4 годин компанія має відновити можливість працювати із запитами клієнтів. DRP забезпечить технічне виконання: відновлення баз даних, VPN-доступів, відновлення резерву.
Формально, BCP охоплює весь бізнес, у тому числі персонал, постачальників, партнерів, локації, транспорт. DRP — лише технології. Але саме DRP дозволяє реалізувати вимоги BCP щодо часу і якості відновлення. Без DRP жоден план безперервності не зможе бути ефективним. І навпаки, DRP без BCP — технічна фантазія без бізнес-контексту.
BCP і DRP: Порівняльна таблиця
Критерій | BCP | DRP | Коментар |
Призначення | Забезпечити продовження роботи | Відновити ІТ-функціональність | BCP охоплює всі аспекти бізнесу, DRP — лише ІТ |
Основна аудиторія | Менеджмент, операційні команди | IT-фахівці, адміністратори | Відповідні команди повинні діяти злагоджено |
Фокус | Процеси, люди, локації | Сервери, дані, комунікації | DRP — підплан BCP |
Період оновлення | 1 раз на рік або після змін | Після змін в ІТ-інфраструктурі | Мають бути синхронізовані |
Тестування | Симуляції, desktop-ревізії | Failover-тестування, відновлення копій | Рекомендується мін. раз на рік |
Практичні формули та показники
🔸 Формула оцінки втрат у разі зупинки процесу:
Втрати (грн) = Кількість працівників, залучених до процесу × Середньогодинна ставка × RTO (годин)
Наприклад: 5 працівників × 400 грн/год × 4 год = 8 000 грн прямих втрат + іміджеві збитки.
🔸 Формула для визначення критичності системи (приклад KRI):
Індекс критичності = (Обсяг даних у системі / Загальний обсяг) × (Частота використання / Добове навантаження)
Ризиковими вважаються системи з індексом > 0,6.
🔸 Орієнтовні RTO:
• CRM-система — до 4 год
• ERP/Бухгалтерія — до 12 год
• Email/Корп. комунікації — до 1 год
• Вебсайт — до 8 год (якщо клієнтський портал).
Типові помилки і як їх уникнути
- Відсутність тестування: BCP/DRP розроблено, але жодного разу не перевірено на практиці.
- Недостатній зв’язок між бізнес-функціями та ІТ: BCP запланував 4 години на відновлення, а DRP — лише 12.
- Неактуальні контактні особи: змінилась команда — в планах стара інформація.
- Відсутність мультисценарного підходу: план розрахований лише на відключення електроенергії, але не враховує знищення офісу або DDoS-атаку.
- Слабке залучення керівництва: плани створено ІТ-відділом без участі бізнесу.
Поради:
- проведіть desktop-тестування хоча б раз на рік. Запросіть керівників напрямів, дайте змодельовану ситуацію — «знищено головний офіс» — і подивіться, як реагує команда. Це дешево, швидко і часто показує неочевидні слабкості.
- Призначте BCP-координатора з функцією нагадування і перевірки
- Включіть BCP/DRP у внутрішні тренінги
Таким чином, що означає для компанії наявність затвердженого плану BCP/DRP? Це перевірка того, чи компанія має формально затверджений і дієвий план, який допоможе продовжити або швидко відновити діяльність у разі серйозних інцидентів — катастроф, збоїв, кібератак, війни, втрати доступу до офісу чи IT-систем.
«Наявність BCP/DRP», в контексті ризик-менеджменту, як KRI або контрольна точка свідчить про зрілість компанії щодо управління операційними та ІТ-ризиками. BCP/DRP стають «реанімаційною аптечкою» для компанії. У страхових компаніях це важливо не лише для ІТ, а й для функцій врегулювання, клієнтського сервісу, резервів і фінансової звітності.