Кібербезпека та реагування на витік персональних даних

Чому кібербезпека — питання права

Технічна частина кібербезпеки — робота інженерів. Правова частина починається в момент, коли інцидент уже відбувся: саме тоді з’ясовується, хто кому що зобов’язаний, у які строки і з якими наслідками.

Три різні рівні відповідальності виникають одночасно:

• регуляторний — обов’язки перед органом із захисту даних у кожній юрисдикції, де ви обробляєте дані;
• договірний — зобов’язання перед клієнтами за договорами, зокрема перед замовниками з ЄС, які вимагають угод про обробку даних і несуть власну відповідальність перед своїми регуляторами;
• цивільний — позови осіб, чиї дані постраждали, і вимоги про відшкодування шкоди.

Для українського IT-бізнесу це питання не теоретичне, а комерційне. Витік у підрядника, який обробляє дані європейського клієнта, одразу стає проблемою цього клієнта, а отже проблемою контракту. Тому вимоги щодо безпеки й реагування на інциденти зазвичай потрапляють у договір задовго до того, як будь-який інцидент трапиться — про це в матеріалі про ключові умови SaaS-договору.

Правова рамка в Україні складається з трьох шарів: Закон «Про захист персональних даних» № 2297-VI (власне обробка даних), Закон «Про основні засади забезпечення кібербезпеки України» № 2163-VIII (система захисту, взаємодія з державними органами, CERT-UA) і Закон «Про критичну інфраструктуру» № 1882-IX для відповідних об’єктів. Для бізнесу, що працює з ЄС, поверх цього діє GDPR.

Що вимагає чинний український закон

Про чинне українське регулювання варто говорити чесно: воно застаріле. Закон № 2297-VI в останній суттєвій редакції 2010 року побудований на Директиві 95/46/ЄС, яку в ЄС скасували й замінили на GDPR ще 27 квітня 2016 року.

Що він вимагає від володільця персональних даних сьогодні:

• обробляти дані лише на визначених законом підставах і для сформульованої мети;
• забезпечувати захист даних від незаконної обробки, втрати, знищення, пошкодження (стаття 24 Закону), зокрема визначити порядок доступу до даних і відповідальну особу або структурний підрозділ;
• повідомляти суб’єкта даних про включення його даних до бази та про його права;
• задовольняти запити суб’єктів даних щодо доступу, виправлення, видалення;
• дотримуватися правил передачі даних розпорядникам і за кордон.

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

Наслідок практичний і неочевидний: для української компанії обов’язок повідомити про витік найчастіше виникає не із закону, а з договору — із угоди про обробку даних із європейським клієнтом, із політики безпеки материнської компанії, з вимог платіжних систем або сертифікації. Саме ці документи, а не Закон № 2297-VI, диктують строки й формат.

Але відсутність обов’язку повідомляти не означає відсутності обов’язку захищати. Стаття 24 Закону діє, і порушення вимог захисту даних є підставою для відповідальності незалежно від того, чи повідомили ви когось про інцидент.

Коли застосовується GDPR

Регламент (ЄС) 2016/679 застосовується екстериторіально, і більшість українських IT-компаній підпадають під нього за однією з двох конструкцій.

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

Друга: ви обробляєте дані за дорученням європейського клієнта. Тоді ви оператор (processor), і ваші обов’язки визначає стаття 28 GDPR разом із угодою про обробку даних. Типовий випадок: аутсорс-розробка або підтримка, де доступ до продакшену означає доступ до персональних даних.

Різниця між цими ролями визначає обсяг обов’язків, і її потрібно зафіксувати в договорі письмово. Найчастіша помилка — українська компанія фактично діє як контролер (сама визначає цілі обробки), а в договорі описана як оператор, що в разі інциденту обертається проти неї.

Основні вимоги GDPR, які мають значення для безпеки:

• стаття 32 — технічні та організаційні заходи, відповідні ризику: шифрування, псевдонімізація, здатність відновити доступ до даних, регулярне тестування ефективності заходів;
• стаття 30 — ведення записів про операції обробки;
• стаття 35 — оцінка впливу на захист даних (DPIA) для операцій з високим ризиком;
• стаття 37 — призначення відповідальної особи з захисту даних у визначених випадках;
• статті 33 і 34 — повідомлення про порушення безпеки даних.

Важливе застереження щодо новин 2025–2026 років. Європейська Комісія 19 листопада 2025 року опублікувала пакет Digital Omnibus, частина якого (COM(2025) 837) пропонує зміни до GDPR, ePrivacy, Data Act, NIS2 і DORA. Ця частина досі залишається пропозицією і не має обов’язкової сили. Законом став лише AI-складник пакета. Тому планувати відповідність треба за чинним текстом GDPR, а не за анонсами спрощень.

Що вважається витоком

Поняття ширше, ніж здається. Порушення безпеки персональних даних за GDPR — це порушення безпеки, що призводить до випадкового або незаконного знищення, втрати, зміни, несанкціонованого розкриття даних або доступу до них. Хакерська атака — лише один зі сценаріїв.

Реальні інциденти, які юридично є витоком:

Три висновки з цього переліку. По-перше, більшість інцидентів не є атаками — це помилки конфігурації та людський фактор, тому технічні засоби без процедур не допомагають. По-друге, втрата доступності (той самий шифрувальник) є порушенням навіть якщо дані нікуди не пішли. По-третє, інцидент у підрядника є вашим інцидентом, якщо ви контролер.

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

Повідомлення: 72 години і правила в Україні

Регулятор. Стаття 33 GDPR зобов’язує контролера повідомити компетентний наглядовий орган про порушення безпеки персональних даних без неналежної затримки і, де це можливо, не пізніше ніж через 72 години після того, як йому стало про нього відомо. Виняток один: якщо порушення навряд чи призведе до ризику для прав і свобод фізичних осіб. Якщо строк пропущено, повідомлення має супроводжуватися обґрунтуванням причин затримки.

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

Постраждалі особи. Стаття 34 GDPR вимагає повідомити самих суб’єктів даних без неналежної затримки, якщо порушення ймовірно призведе до високого ризику для їхніх прав і свобод. Повідомлення не потрібне, зокрема, якщо дані були зашифровані належним чином і залишилися незрозумілими для сторонньої особи, або якщо контролер вжив заходів, які унеможливили настання високого ризику.

Оператор. Якщо порушення сталося в оператора, він повідомляє контролера без неналежної затримки — власного 72-годинного строку щодо регулятора в нього немає. На практиці угоди про обробку даних встановлюють значно жорсткіші строки, нерідко 24 години, тому орієнтуватися треба на договір.

А що в Україні. Чинний Закон № 2297-VI такого обов’язку не передбачає. Але ситуація зміниться: законопроєкт № 8153 «Про захист персональних даних», зареєстрований 25 жовтня 2022 року, прийнятий за основу в першому читанні 20 листопада 2024 року і готується до другого читання. Він побудований на логіці GDPR і, серед іншого, прямо передбачає, що контролер має повідомити контролюючий орган не пізніше ніж за 72 години після того, як йому стало відомо про порушення безпеки персональних даних, крім випадків, коли порушення малоймовірно може призвести до ризику для прав і свобод особи.

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

Поки це законопроєкт, а не закон. Але для компанії, яка працює з європейськими клієнтами, 72-годинна процедура все одно вже потрібна — а після ухвалення нового закону вона стане обов’язковою і за українським правом. Готувати її варто зараз, а не після другого читання.

План реагування на інцидент

Сімдесят дві години — це не багато. Якщо інцидент виявлено в п’ятницю ввечері, строк спливає в понеділок. Без заздалегідь підготовленого плану компанія витрачає перші дванадцять годин на з’ясування, кому дзвонити.

Робочий план складається з шести етапів.

1. Виявлення та фіксація. Хто й у який спосіб реєструє інцидент, як фіксується момент, коли компанія дізналася про нього (саме від цього моменту рахується строк), хто ухвалює рішення про запуск процедури. Цей час треба задокументувати одразу — потім довести його буде неможливо.
2. Стримування. Ізоляція скомпрометованих систем, відкликання доступів, зміна ключів і паролів, збереження логів і образів для подальшого аналізу. Важливо не знищити докази, намагаючись швидко «усе почистити».
3. Оцінка. Які категорії даних і скільких осіб торкнувся інцидент, у яких юрисдикціях вони перебувають, чи були дані зашифровані, який рівень ризику для осіб. Саме ця оцінка визначає, чи потрібне повідомлення регулятора й суб’єктів.
4. Повідомлення. Регулятор (або регулятори, якщо юрисдикцій кілька), контролер — якщо ви оператор, клієнти за договорами, за потреби суб’єкти даних, страховик за полісом кіберризиків. Шаблони повідомлень мають бути готові заздалегідь.
5. Усунення та відновлення. Закриття вразливості, відновлення з бекапів, перевірка відсутності повторного доступу.
6. Аналіз і документування. Внесення інциденту до журналу порушень, який GDPR вимагає вести незалежно від того, чи повідомляли регулятора, і висновки щодо змін у процедурах.

Що має бути в плані ще до інциденту: перелік ролей із іменами та резервними контактами (хто керує реагуванням, хто спілкується з регулятором, хто з клієнтами, хто з пресою), контакти зовнішніх юриста та фахівця з форензики, карта систем і даних із зазначенням, де які категорії даних зберігаються, шаблони повідомлень регулятору, клієнтам і суб’єктам даних, журнал інцидентів.

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

Відповідальність сьогодні і після реформи

Контраст між українськими та європейськими санкціями зараз разючий, і саме він визначає реальні ризики компанії.

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

GDPR. Стаття 83 Регламенту встановлює два рівні: до 10 мільйонів євро або 2 відсотки світового річного обороту за порушення, зокрема вимог статей 32–34 про безпеку і повідомлення, і до 20 мільйонів євро або 4 відсотки обороту за порушення основних принципів та прав суб’єктів даних. Застосовується більша з двох сум.

Україна після реформи. Законопроєкт № 8153 кардинально змінює підхід: санкції диференціюються залежно від тяжкості порушення та його впливу на права осіб, а їхні розміри вимірюються десятками мільйонів гривень або відсотком річного обороту компанії. Конкретні цифри в різних редакціях документа відрізнялися, і остаточні визначить друге читання, тому покладатися на жодну з опублікованих оцінок як на остаточну не варто. Напрям, однак, однозначний — від символічних сум до європейського масштабу.

Поряд із публічними санкціями діють три інші види втрат, які часто перевищують штраф:

• договірні — відповідальність перед клієнтом за угодою про обробку даних, включно з обов’язком відшкодувати його власні штрафи та витрати на повідомлення;
• цивільні — позови осіб про відшкодування матеріальної та моральної шкоди;
• комерційні — втрата контракту, провалений аудит безпеки, неможливість пройти due diligence при залученні інвестицій.

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

Профілактика: чек-лист

Юридична профілактика в цій сфері складається з документів і процедур, а не з обіцянок. Мінімальний набір для компанії, що працює з європейськими клієнтами або персональними даними українських користувачів:

1. Карта даних. Які категорії персональних даних ви обробляєте, де вони зберігаються, хто має доступ, як довго зберігаються, кому передаються. Без цього неможливо за 72 години оцінити масштаб інциденту.
2. Визначені ролі. Де ви контролер, а де оператор — зафіксовано в договорах, а не лише на словах.
3. Угоди про обробку даних із усіма підрядниками, які мають доступ до даних, із вимогами щодо безпеки, повідомлення про інциденти та субпідрядників.
4. Політика безпеки й порядок доступу до персональних даних, відповідальна особа або підрозділ — цього прямо вимагає стаття 24 Закону № 2297-VI.
5. План реагування на інцидент із ролями, контактами і шаблонами повідомлень, перевірений хоча б одним кабінетним навчанням.
6. Журнал інцидентів — ведеться завжди, незалежно від того, чи повідомляли регулятора.
7. Шифрування та мінімізація. Зашифровані дані можуть звільнити від обов’язку повідомляти суб’єктів за статтею 34 GDPR, а дані, які ви не збирали, не можуть витекти.
8. Процедура припинення доступів при звільненні — найчастіше джерело «внутрішніх» витоків.
9. Умови в договорах з клієнтами щодо межі відповідальності за інциденти, строків повідомлення та розподілу витрат.
10. Готовність до нового закону. Процедури, які вимагає законопроєкт № 8153, за змістом збігаються з GDPR, тому компанія, що відповідає GDPR, пройде перехід майже без змін.

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

Юристи практики IT-права LEGIUS готують політики захисту даних і плани реагування на інциденти, перевіряють угоди про обробку даних і супроводжують компанії під час інцидентів. Щоб перевірити готовність вашої компанії до 72-годинної процедури, запишіться на консультацію.