Одна ніч, кілька годинників

У п'ятницю ввечері команда помічає, що частину серверів зашифровано, а в логах видно вивантаження даних. Якщо компанія працює з клієнтами в Україні, ЄС, Британії й Канаді, у неї може з'явитися не один дедлайн на повідомлення, а кілька. Вони рахуються від різних моментів, адресовані різним органам і мають різний формат. Найкоротші спливають за чотири години, а найдовші дають місяць, але стартують вони одночасно.

У цій статті два практичні результати. Перший: карта «хто, кому, за скільки годин» за тими режимами, які ми звірили з першоджерелами. Другий: схема одного процесу, який закриває всі строки одразу. Про сам план реагування на інцидент (виявлення, стримування, відновлення) читайте в окремій статті про план реагування на інциденти. Тут лише звітування перед регуляторами.

Це не юридична консультація: строки й порогові значення для вашої компанії підтвердьте з юристом і з відповідним регулятором.

Спершу про відлік

Найчастіша помилка в таких картах: рахувати від початку атаки. Норми вмикають годинник у різні моменти:

• «Дізналися». GDPR, NIS2 і CRA рахують від моменту, коли організація стала обізнана з порушенням чи значним інцидентом.

• «Класифікували». DORA вимагає первинного повідомлення протягом чотирьох годин після того, як інцидент класифіковано як серйозний, але не пізніше 24 годин від моменту, коли установа про нього дізналася.

• «Визначили, що перейшли поріг». Британське правило FCA чекає початкового звіту якнайшвидше, а за настановою FCA бажано протягом 24 годин після того, як фірма встановила, що інцидент досяг порогу.

Практичний висновок: момент «дізналися» і момент «класифікували» мають бути записані з точністю до хвилини, з іменем людини, яка їх визначила. Без цього ви не доведете, що вклалися у строк.

Карта строків по режимах

Нижче лише те, що ми звірили. У кожного режиму є умови застосування: сектор, розмір, тип даних, місце роботи. Тому читайте карту як перелік питань до вашої ситуації, а не як відповідь.

Україна

• Банки: постанова НБУ № 178 зі змінами № 24 (з 1 березня 2025). Про значний кіберінцидент банк повідомляє НБУ попередньо протягом 24 годин, проміжно протягом 72 годин, а остаточний звіт подає до одного місяця. Докладніше про вимоги НБУ: кібербезпека за вимогами НБУ.

• Постанова НБУ № 143. Вона не встановлює обов'язку самим повідомляти НБУ про інциденти; регулятор може запросити інформацію письмово. Не змішуйте її з № 178.

• Інші сфери. Небанківські установи, держсектор, персональні дані за українським законом: тут ми їх не розбираємо. Перевірте своє положення окремо.

Європейський Союз

• NIS2, стаття 23(4). Раннє попередження протягом 24 годин від моменту, коли дізналися про значний інцидент, повідомлення про інцидент протягом 72 годин, підсумковий звіт не пізніше ніж за місяць після повідомлення. Директива задає рамку, а канал і деталі визначає національний закон держави, де вас регулюють; уточнюйте їх для кожної країни окремо. Огляд: відповідність NIS2.

• DORA (для фінансових установ ЄС). Первинне повідомлення протягом чотирьох годин після класифікації й не пізніше 24 годин від моменту, коли дізналися; проміжне протягом 72 годин; фінальне протягом місяця (Делегований регламент 2025/301, стаття 5). Якщо ви ІТ-постачальник такої установи, її годинник вмикається, коли вона дізнається про подію, і ваш договір має гарантувати, що вона дізнається вчасно. Огляд: відповідність DORA.

• GDPR, стаття 33. Порушення захисту персональних даних треба повідомити наглядовому органу без невиправданої затримки й, якщо це можливо, не пізніше ніж за 72 години після того, як стало відомо. Виняток: порушення навряд чи створює ризик для прав людей. Якщо повідомили пізніше, додайте причини затримки. Обробник даних (компанія, що обробляє їх за дорученням клієнта) повідомляє клієнта без невиправданої затримки.

• CRA (Cyber Resilience Act) для виробників продуктів із цифровими елементами, тобто програмного забезпечення й пристроїв, які продаються в ЄС. З 11 вересня 2026 року: раннє попередження про активно експлуатовану вразливість чи серйозний інцидент протягом 24 годин, повідомлення протягом 72 годин, фінальний звіт не пізніше 14 днів після появи виправлення (для вразливості) або протягом місяця після 72-годинного повідомлення (для інциденту). Подається один раз через єдину платформу ENISA; її отримує CSIRT країни головного представництва, ENISA бачить повідомлення одночасно.

Британія

• UK GDPR, стаття 33. Ті самі 72 години, наглядовий орган: Офіс комісара з інформації (ICO).

• FCA, політика PS26/2 (з 18 березня 2027). Єдині правила звітування про операційні інциденти для фірм із дозволом FCA, платіжних сервісів та інших. Більшість фірм подає один короткий звіт без оновлень. Для вужчого кола діє розширена схема: початковий звіт якнайшвидше (FCA очікує в межах 24 годин після того, як встановлено перевищення порогу, і не радить чекати цього строку), оновлення при суттєвих змінах, фінальний звіт протягом 30 робочих днів після вирішення. Платіжні сервіси подають початковий звіт протягом чотирьох годин після першого виявлення. Окремо фірми щорічно подають реєстр матеріальних домовленостей з третіми сторонами.

• Законопроєкт про кібербезпеку й стійкість (Cyber Security and Resilience Bill). Ще не закон, тому цифр не наводимо.

Канада

• PIPEDA, розділ 10.1. Про порушення захисту персональних даних, що створює реальний ризик значної шкоди, треба повідомити федерального комісара з приватності й постраждалих. Звіт подають «якнайшвидше» після того, як організація визначила, що порушення сталося. Числа годин у законі немає.

• OSFI (федерально регульовані фінустанови). Про технологічний чи кіберінцидент повідомляють протягом 24 годин, а якщо можна, то раніше.

• CCSPA (закон про захист критичних кіберсистем). Закон ухвалено 15 червня 2026. Оператор, визначений законом, звітує в Communications Security Establishment про інцидент у строк, який встановить регламент, але не більше 72 годин, і одразу після цього повідомляє свого регулятора. Чи набули чинності положення про звітування, перевірте на момент, коли плануєте процес.

США, для повноти

CIRCIA вимагатиме звітувати про суттєві кіберінциденти й виплату викупу. Але CISA ще не завершила правило, і до його чинності обов'язку звітувати за CIRCIA немає. Закон визначає 72 години для інциденту й 24 години для виплати викупу.

Чому п'ять окремих процесів не працюють

Типовий сценарій: український офіс повідомляє НБУ чи клієнта, юрист у Брюсселі готує звіт для CSIRT, британський менеджер пише в ICO. Кожен бере факти з власного чату. У результаті два регулятори отримують різні версії: в одному звіті «доступ без вивантаження даних», в іншому «дані вивантажено». А коли регулятори порівняють звіти, питання буде вже до довіри, а не лише до строку.

Тому рішення не в тому, щоб знати п'ять процедур. Воно в тому, щоб мати одну базу фактів і одну класифікацію, з якої п'ять звітів збираються як різні вигляди того самого.

Один процес, що закриває всі строки

Усе нижче це наша практична рекомендація, а не вимога конкретної норми. Базова логіка проста: рішення на вході одне, а різняться тільки адресат і форма.

1. Один момент відліку

Призначте роль, яка записує «час, коли ми дізналися» і «час, коли ми класифікували». Один запис у спільному журналі, не в особистих повідомленнях. Для кожного режиму з карти вище саме цей час лишається базою, від якої рахують строк. Окремо записуйте момент, коли інформація дійшла до людини, що має право класифікувати: затримка між «побачив адміністратор» і «знає керівництво» часто з'їдає найбільше часу.

2. Класифікація за кількома питаннями

Складіть коротку анкету, яку заповнює інцидент-менеджер за першу годину. Приклади питань:

• Чи зачеплені персональні дані й чиї (громадян ЄС, Британії, Канади, України)?

• Чи постраждали сервіси клієнтів, які є фінустановами або операторами критичної інфраструктури?

• Чи йдеться про продукт, який ми продаємо в ЄС, або про вразливість у ньому?

• Яка юридична особа, у якій країні, зачеплена?

• Чи є ознаки виплати викупу?

Результат анкети: перелік режимів, у яких годинник уже йде, і час, коли спливає найближчий. Додайте правило: якщо відповідь «не знаємо», рахуємо так, ніби «так», доки не з'ясуємо.

3. Хто вирішує

Потрібні три імені із заступниками:

• Інцидент-менеджер. Веде хронологію й заповнює анкету.

• Той, хто ухвалює рішення про повідомлення. Зазвичай керівник безпеки (CISO) або член вищого керівництва, з правом сказати «повідомляємо» без додаткових погоджень.

• Юрист або зовнішній радник на зв'язку. Підтверджує, який саме поріг перейдено, і перевіряє формулювання.

Головне правило: людина, що ухвалює рішення, доступна цілодобово. Інцидент у п'ятницю о 22:00 не може чекати понеділка.

4. Матриця й шаблони

Матриця це таблиця у вашій внутрішній документації (на сайт таблицю не переносимо). Рядок на кожен режим: регулятор, коли годинник стартує, строк, канал подання, хто подає, посилання на шаблон, чи потрібна згода клієнта. Приклад одного рядка: «НБУ, інцидент значний, 24 години від визначення, канал подання за порядком НБУ, подає CISO, шаблон такий-то».

Шаблони будуйте як ядро плюс адаптери. Ядро: що сталося, коли виявили, які системи й дані зачеплено, які наслідки для клієнтів, що вже зроблено, контакти. Адаптер додає поля, яких вимагає конкретний регулятор. Ядро заповнюється один раз, а розходження між звітами стають неможливими.

Окремо готуйте перший, «неповний» варіант. Ранні звіти за природою невеликі: вони не вимагають повного розслідування, а лише того, що відомо. Шаблон, у якому можна написати «невідомо, перевіряємо», потрібен до інциденту.

5. Журнал рішень

Журнал це не лише хронологія подій. Записуйте кожне рішення: що було відомо, хто вирішив, що вирішив і чому. Особливо рішення «не повідомляти»: коли ви вважаєте, що поріг не перейдено, треба мати запис, на чому ґрунтується висновок. GDPR прямо вимагає пояснювати причини, якщо повідомили після 72 годин. Журнал також дає матеріал для фінального звіту й подальшого аналізу.

6. Тренування

Раз на рік проведіть tabletop-вправу (обговорення сценарію за столом без реальних дій). Дайте команді вигадану ситуацію й запитайте: хто вирішує? Які режими вмикаються? Кому йде перший лист? Часто вправа показує, що в матриці бракує людини на вихідні чи що в договорі з постачальником немає строку повідомлення. Цього набагато краще дізнатися на вправі.

Умовний приклад (вигаданий)

Київська компанія розробляє хмарну платформу для фінустанов. Її клієнти: банк в ЄС і платіжна компанія з Британії. У п'ятницю о 22:10 моніторинг фіксує несанкціонований доступ до бази, у якій є персональні дані клієнтів банку. О 22:40 інцидент-менеджер записує час відліку й заповнює анкету: персональні дані громадян ЄС (GDPR, компанія як обробник), клієнт це фінустанова з ЄС (DORA, годинник клієнта вмикається, коли він дізнається), платіжний клієнт у Британії (його власні правила). Рішення «повідомляємо клієнтів» ухвалює CISO в межах години. Клієнти отримують лист за шаблоном-ядром, далі кожен подає свій звіт регулятору. Цифри й послідовність тут ілюстративні; важливо, що всі ці дії заздалегідь розписані.

Типові помилки

• Рахувати від початку атаки, а не від визначеного нормою моменту. Це дає хибне відчуття, що часу більше або менше, ніж є.

• Сподіватися на «єдине вікно». Для CRA така платформа вже діє, а в решті режимів звітують окремо.

• Покладатися на постачальників без договору. Якщо вашому клієнту-фінустанові треба повідомити регулятора за дні чи години, а ви повідомляєте його «коли розберемося», він спізниться.

• Починати з шаблону регулятора, а не з бази фактів. Тоді звіти розходяться.

• Не мати відповідальної особи на вихідні.

• Забути, що люди мовчать. Годинник не запуститься, поки співробітник, який помітив підозрілу активність, не сказав про неї; процес має робити так, щоб казати було безпечно.

З чого почати

Не з нового інструмента. Візьміть минулий інцидент або вигаданий і пройдіть його по картці: коли ми дізналися, хто класифікував, які режими вмикалися, хто подавав, скільки часу пройшло. Результат покаже, де у вашому процесі найслабше місце. Далі складіть матрицю для режимів, що стосуються вашої компанії, і призначте трьох людей із заступниками.

Якщо хочете разом переглянути, які годинники можуть вмикатися у вашій компанії й чи вистачить вам людей та шаблонів, ми допоможемо з побудовою процесу в межах управління кіберризиками. Поговоримо.

Часті запитання

З якого моменту починається відлік?

Залежить від норми. GDPR, NIS2 і CRA рахують від моменту, коли організація дізналася. DORA має два орієнтири: чотири години після класифікації і не пізніше 24 годин від моменту, коли дізналися. FCA чекає звіту після того, як фірма встановила перевищення порогу. Тому записуйте обидва моменти.

Чи потрібно повідомляти всіх регуляторів про кожен інцидент?

Ні. Кожен режим має поріг: «значний» інцидент у NIS2, «серйозний» у DORA, ризик для прав людей у GDPR, «реальний ризик значної шкоди» у PIPEDA. Класифікація якраз і потрібна, щоб визначити, які пороги перейдено.

Що робити, якщо інформації ще мало?

Подавати те, що відомо, і чітко позначити невідоме. Ранні звіти (раннє попередження в NIS2, початковий звіт у DORA й FCA) розраховані на неповні дані, повніші версії йдуть у проміжних і фінальних звітах.

Чи можна подати один звіт у всі органи?

Зазвичай ні. Виняток CRA: виробник подає одне повідомлення через єдину платформу, а CSIRT і ENISA отримують його. В інших режимах звітують окремо кожному адресату, тому корисно мати одне ядро фактів.

Хто в компанії має ухвалювати рішення про повідомлення?

Людина з повноваженнями сказати «повідомляємо» без довгого погодження: часто CISO або член керівництва, з юридичною підтримкою. Головне, щоб вона була доступна цілодобово й мала заступника.

Чи стосується це малого бізнесу?

Залежить від режиму. Багато вимог прив'язані до сектора, розміру чи типу даних, а GDPR застосовується незалежно від розміру, якщо ви обробляєте персональні дані. Почніть із карти питань про вашу ситуацію й підтвердьте відповіді з юристом.