GDPR data breach: план дій та повідомлення регулятора

Коли мова йде про data breach, першими зазвичай згадують справу Ashley Madison, діяльність угруповання Lizard Squad або атаку на Equifax. Проте реальна практика складається переважно не з гучних інцидентів за участю мільйонних компаній, які оперують великими базами даних, а з порушень, що трапляються у повсякденній діяльності звичайних учасників ринку. Хоча масштаби таких інцидентів можуть бути різними, їх об’єднує одна спільна риса: значна частина цих порушень є такими, яким можна або запобігти або шляхом належного реагування убезпечити компанію від великих штрафів, а суб’єктів даних від ризиків для їхніх прав та свобод. 

General Data Protection Regulation (GDPR) висуває низку вимог до компаній щодо впровадження технічних та організаційних заходів, спрямованих на запобігання data breaches. Водночас навіть найбільш комплексні превентивні заходи не гарантують, що інцидент не станеться. Саме тому GDPR та практика регуляторів відстоюють ризикоорієнтований підхід та приділяють не менше уваги тому, наскільки організація готова до data breach та як саме вона діятиме у разі його виникнення. Що саме потрібно робити після виявлення data breach, коли виникає обов’язок повідомляти регулятора та суб’єктів даних і як правильно оцінити ризики для їхніх прав і свобод – розберемо у цій статті.

Що таке data breach за GDPR?

За ст. 4(12) GDPR data breach означає порушення безпеки, що призводить до випадкового або незаконного знищення, втрати, зміни, несанкціонованого розкриття персональних даних або несанкціонованого доступу до них, які передаються, зберігаються або обробляються в інший спосіб. Натомість WP29 у Висновку 03/2014 щодо повідомлення про data breach розкриває зміст цього поняття через три наступні категорії: 

• data breach, що стосується порушення конфіденційності даних: випадкове або несанкціоноване розкриття персональних даних або доступ до них; 
• data breach, що стосується цілісності даних: випадкова або несанкціонована зміна персональних даних; 
• data breach, що стосується доступності даних: випадкова або несанкціонована втрата доступу до персональних даних або їх знищення.

Важливо підкреслити, що не кожен інцидент безпеки буде автоматично вважатися data breach у розумінні GDPR. Для кваліфікації певного інциденту безпеки як data breach, такий інцидент повинен стосуватися персональних даних та  виражатися у неможливості контролера забезпечити обробку персональних даних у відповідності з принципами за ст. 5 GDPR. Типові приклади data breaches включають несанкціонований доступ хакера до бази даних клієнтів, випадкове надсилання працівником конфіденційних даних не тій особі, крадіжка ноутбука, що містить незашифровані персональні дані, неправильно налаштоване хмарне сховище, до якого надано публічний доступ, атака програм-вимагачів, унаслідок якої системи та дані стають недоступними тощо.

Data breach є. Обов’язок повідомляти – не завжди

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

1. Повідомлення наглядового органу 

Стаття 32 GDPR чітко передбачає, що контролер та процесор повинні впроваджувати належні технічні та організаційні заходи для забезпечення належного рівня безпеки персональних даних. Це inter alia включає здатність своєчасно виявляти, реагувати на порушення та повідомляти про них. В контексті data breaches контролер залишається повністю відповідальним та несе обов’язок повідомлення наглядового органу про порушення у разі потреби. Відповідно незалежно від моделі розподілу відносин в компанії, питання повідомлення наглядового органу про data breach має бути врегульоване між суб’єктами залученими до обробки персональних даних. 

У випадку залучення процесора до обробки даних Data Processing Agreement має містити положення щодо обов’язку процесора «сприяти контролеру у забезпеченні дотримання обов’язків, передбачених статтями 32–36, з урахуванням характеру обробки та інформації, доступної процесору» за ст. 28(3)(f) GDPR. Водночас у разі спільного контролерства, необхідно визначити компанію відповідальну за здійснення повідомлення на рівні Joint Controllership Agreement. 

Як вже було зазначено, обов’язок повідомляти наглядовий орган про data breach виникає лише у разі наявності ризику для прав та свобод суб’єктів даних. У фокусі такої оцінки мають передусім бути наслідки, в тому числі матеріальні, нематеріальні, репутаційні тощо, data breach для суб’єктів даних. EDPB у Guidelines 9/2022 щодо повідомлення про data breach за GDPR при встановленні наявності ризику рекомендує враховувати такі фактори як тип data breach, характер, чутливість та обсяг персональних даних, важкість ідентифікації особи, суворість наслідків для особи, спеціальні характеристики суб’єктів даних, а також кількість суб’єктів, які зазнають впливу. 

В будь-якому разі золотим правилом цього розділу є тлумачення будь-яких сумнівів на користь наявності ризиків, оскільки на відмінну від неповідомлення, повідомлення навіть за відсутності ризиків не тягне за собою юридичної відповідальності. 

Правило 72 годин 

Поширеним міфом є вважати, що відлік 72 годин за ст. 33 GDPR починається з того моменту, коли відбувся сам data breach. На щастя для контролерів, GDPR прив’язує відлік часу для повідомлення наглядового органу з моментом обізнаності контролера з фактом наявності data breach. 

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

У разі встановлення необхідності повідомлення наглядового органу про data breach, контролер за ст. 33(3) GDPR має надати таку інформацію: 

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

Важливо зазначити, що “правило 72 годин” не є абсолютним і містить кілька винятків: 

1. З урахуванням характеру та обсягу data breaches, контролер може надавати відповідну інформацію поступово (“фазами”), якщо протягом 72 годин він не мав змоги зібрати всі деталі щодо певного інциденту. Про це контролер може зазначити у самому повідомленні.
2. Бувають випадки, коли існують обгрунтовані причини, з яких контролер не повідомив наглядовий орган протягом 72 годин. Таке прострочення може бути прийнятним, наприклад, коли контролер протягом короткого періоду часу зазнає кількох подібних data breaches, які однаковим чином стосуються великої кількості суб’єктів даних. Контролер може дізнатися про одне порушення та, розпочавши його розслідування, але ще до подання повідомлення, виявити додаткові подібні порушення, що мають різні причини. Залежно від обставин контролеру може знадобитися певний час для встановлення масштабу таких порушень. Тому замість того, щоб повідомляти про кожне порушення окремо, контролер може підготувати одне змістовне повідомлення, яке охоплюватиме кілька дуже подібних порушень, навіть якщо вони мають різні причини. 

2. Повідомлення суб’єктів даних 

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

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

При цьому, стаття 34(3) GDPR встановлює винятки, коли безпосереднє повідомлення суб’єктів даних не вимагається, якщо виконується будь-яка з таких умов:

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

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

Варто зауважати, що ці винятки можуть тлумачитися наглядовими органами досить вузько і потребують належної оцінки on a case-by-case basis. 

Документування – грунт, база і основа 

Відповідно до ст. 5(2) GDPR контролер несе відповідальність за дотримання принципів GDPR, та повинен бути здатним продемонструвати таке дотримання (“підзвітність”). Цей основоположний принцип GDPR є особливо важливим в контексті data breaches, оскільки у випадку прийняття рішення про неповідомлення наглядового органу або суб’єктів даних та у разі подальших інцидентів, контролеру буде необхідно довести регулятору належне виконання всіх законодавчо передбачених процедур.  

Крім цього, ст. 33(5) GDPR додатково встановлює обов’язок контролера документувати будь-які порушення безпеки персональних даних із зазначенням обставин, пов’язаних з таким порушенням, його наслідків та вжитих заходів щодо усунення наслідків. 

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

План дій замість висновків 

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