План реагування на інциденти: як компанії створити практичний план для кіберінцидентів
План реагування на інциденти описує, як організація діє з моменту появи перших ознак кіберінциденту до моменту стабілізації роботи, забезпечення доказів, виконання необхідної звітності та впровадження висновків у вигляді конкретних заходів. План має бути достатньо стислим, щоб його можна було використовувати в умовах стресу, але водночас достатньо детальним, щоб усунути сумніви щодо ролей, каналів зв'язку та прийняття рішень.
Що має охоплювати план реагування на інциденти?
План має стосуватися подій, які можуть вплинути на конфіденційність, цілісність, доступність або автентичність систем та інформації організації. Прикладами є віруси-вимагачі (ransomware), викрадення облікових записів, витік даних, DDoS-атаки, компрометація постачальника, неправильна конфігурація, саботаж та масштабні збої в роботі.
Визначте єдину точку входу для сповіщень, навіть якщо природа події не є точно визначеною. Співробітник не повинен самостійно вирішувати, чи є подія «інцидентом» з юридичної точки зору, перш ніж повідомити про неї внутрішньо.
Ролі та повноваження щодо прийняття рішень – визначте до початку інциденту
Інциденти часто загострюються, коли всі чекають на вказівки одного керівника. Тому визначте ролі заздалегідь. Невелика організація може поєднувати кілька ролей, але відповідальність все одно має бути чіткою.
| Роль | Відповідальність |
|---|---|
| Керівник інциденту | Координує загальну картину, пріоритети, рішення та графік нарад. |
| Технічно відповідальний | Аналіз, локалізація, логи, усунення наслідків та відновлення. |
| Власник бізнес-процесу | Оцінює вплив на бізнес, критичні послуги та допустимий час простою. |
| Юридичний відділ/захист даних | Оцінює зобов’язання щодо звітності, інформування та договірні зобов’язання. |
| Комунікації | Координує внутрішню та зовнішню інформацію. |
| Керівництво | Приймає рішення, що виходять за межі повноважень групи реагування. |
Також задокументуйте заступників, чергові номери телефонів та способи збору групи реагування, якщо звичайні системи зв’язку не працюють.
Потік реагування на інциденти у восьми кроках
- Виявлення та реєстрація. Створіть ID інциденту, зафіксуйте час, особу, що повідомила, та перші спостереження.
- Тріаж. Швидко оцініть, які системи, дані, користувачі та послуги можуть бути порушені.
- Класифікація та ескалація. Встановіть попередній рівень серйозності та активуйте відповідні ролі.
- Локалізація. Обмежте збитки, не знищуючи при цьому докази та не ускладнюючи відновлення.
- Аналіз. Визначте ймовірну причину, часову шкалу, шлях проникнення та обсяг.
- Усунення. Усуньте причину, закрийте вразливість і переконайтеся, що загроза більше не існує.
- Відновлення. Контрольовано поверніть сервіси до роботи та посильте моніторинг.
- Пост-аналіз. Задокументуйте першопричину, рішення, висновки та заходи з покращення.
Створіть просту модель класифікації
Класифікація має підтримувати прийняття рішень, а не ставати складною бальною моделлю. Оцінюйте, наприклад:
- чи не працює критично важливий бізнес-процес,
- скільки користувачів/клієнтів постраждало,
- чи могли бути розголошені персональні дані або інша конфіденційна інформація,
- чи має зловмисник привілейований доступ,
- чи поширюється інцидент,
- чи постраждали постачальники або інші організації,
- чи виникає необхідність регуляторної звітності.
Визначте, який рівень загрози автоматично залучає керівництво, юристів, офіцера із захисту даних або зовнішнього партнера з реагування на інциденти.
Зберігайте логи та докази, не зупиняючи реагування
Під тиском часу легко видалити або перезаписати важливу інформацію. Тому план повинен вказувати, хто саме відповідає за збереження відповідних логів, знімків системи (snapshots), часових шкал, електронних листів, подій облікових записів та інших технічних підтверджень. Документуйте, хто, що і коли зробив.
Потребу в доказах потрібно збалансувати з вимогою обмежити шкоду, що завдається в поточний момент. У разі серйозних інцидентів може знадобитися рання залучення зовнішніх фахівців із форензики.
Комунікація та зовнішня звітність
Створіть окремі списки контактів для державних органів, постачальника послуг з реагування на інциденти, страхової компанії (кіберстрахування), критично важливих ІТ-постачальників, керівництва та відділу комунікацій. Підготуйте шаблони для першого внутрішнього звіту та для ключових етапів прийняття рішень.
Для організацій, що підпадають під дію закону про кібербезпеку, існують спеціальні правила звітування про значні інциденти. Закон встановлює термін для первинного повідомлення не пізніше ніж через 24 години після того, як суб’єкт дізнався про інцидент, з подальшим поданням звіту відповідно до термінів, визначених для типу діяльності. Деталі розглядаються окремо в посібнику щодо циклу NIS2 24/72 години.
Відновлення – це більше, ніж просто ввімкнення систем
Визначте критерії, за яких сервіс може бути знову відкритий для роботи. Переконайтеся, що вразливість усунуто, привілейовані облікові записи захищені, відновлені дані є достовірними, а моніторинг посилено протягом певного періоду.
Зв’яжіть черговість відновлення з аналізом впливу на бізнес (BIA) та планом забезпечення безперервності діяльності. Прочитайте BIA крок за кроком та що має містити план безперервності.
Пост-аналіз: зробіть навчання обов'язковим
Після інциденту організація повинна задокументувати першопричину, те, що спрацювало, що затримало роботу та які елементи контролю потрібно змінити. Кожен захід повинен мати відповідальну особу та дедлайн. Після цього обов’язково перевірте виконання цих завдань.
Тестуйте план до того, як він знадобиться
План реагування на інциденти, який ніколи не проходив практичних випробувань, майже завжди містить помилкові номери телефонів, нечіткі повноваження або припущення про системи, яких більше не існує. Проводьте принаймні регулярні командно-штабні навчання (table-top exercises), де керівництво, ІТ, бізнес-підрозділи та відповідні допоміжні функції мають реагувати на реалістичний сценарій.
Варіюйте сценарії: вимагачі, скомпрометований SaaS-постачальник, витік адміністративного облікового запису або тривалий простій. Оновлюйте план після кожного тренування.
Чек-лист для плану
- Єдиний чіткий канал внутрішнього оповіщення
- Ролі, заступники та повноваження
- Контактні дані, доступні навіть у неробочий час
- Рівні серйозності та критерії ескалації
- Кроки локалізації, аналізу та відновлення
- Процедури для логів та доказів
- Точка прийняття рішення для NIS2 та іншої обов'язкової звітності
- Точка прийняття рішення щодо GDPR/інциденту з персональними даними
- Відповідальність за внутрішню та зовнішню комунікацію
- Зв’язок із BIA та планом безперервності діяльності
- Пост-аналіз із відповідальними особами за впровадження покращень
- Інтервали для тренувань та оновлення плану
Вам потрібно задокументувати потік реагування на інциденти?
Пакет шаблонів NIS2 2026 від Mallbutiken містить інтегровані шаблони, зокрема для реагування на інциденти, звітування, управління ризиками, безперервності та безпеки постачальників. Ціна в магазині: 199 шведських крон.
Переглянути пакет шаблонів NIS2Пов’язані посібники
Читайте також заходи безпеки NIS2, звітування про інциденти 24/72 години та план безперервності діяльності.
Джерела та додаткова література
Цей посібник надає загальну інформацію. План інцидентів повинен бути адаптований до систем, операційної діяльності, договорів та застосовних вимог звітності конкретної організації.
