Нові правила закону про захист персональних даних в Інтернеті у Європі

25 травня 2018 року набувають чинності правила нового Закону про захист персональних даних в Інтернеті для користувачів, які перебувають на території Європейської економічної зони. Нові правила позначаються абревіатурою GDPR (The General Data Protection Regulation, Загальні правила захисту даних) і поширюються на всіх гравців Інтернету, які беруть участь в збиранні, зберіганні або обробці персональних даних. Хоча закон прийнятий для захисту європейських даних, глобальний характер Інтернету означає, що GDPR встановлює стандарт конфіденційності даних у всьому світі. Практично всі великі інтернет-компанії, включаючи Google, Facebook і Twitter, підпадають під дотримання вимог GDPR.

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

GDPR покликаний забезпечувати більший захист персональних даних людини, включаючи, але не обмежуючись, його релігійними або політичними переконаннями. Штрафи за недотримання правил досить великі: до 20 млн. євро, або 4% від загального обороту (в розрахунок береться більша сума) за порушення. Крім того, GDPR дає користувачам право на компенсацію будь-якого матеріального та/або нематеріального порушення GDPR.

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

До кого застосовуються правила GDPR?

GDPR застосовується до даних, які збираються, обробляються та/або зберігаються в Європі незалежно від того, де зібрані дані. Якщо у вас є інтернет-магазин з інформаційної розсилкою, і хоча б один передплатник з ЄС підписався на неї, тоді вас стосуються правила GDPR.

Одним із значних умов GDPR є те, що тепер заборонена передача даних за межі ЄС в будь-яку країну, яку ЄС не вважає відповідну законам про захист персональних даних. Якщо ви передаєте особисті дані за межі ЄС для обробки або зберігання, то ви повинні отримати явну згоду на це від користувача, якому належать дані.

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

Які дані повинні бути захищені?

Існує два основних типи даних, які по GDPR повинні бути захищені: особисті і делікатні.

Особисті дані – це будь-які дані, які ідентифікують людину. Ваше ім’я, адреса електронної пошти, місце розташування, біометричні дані, логін (інші онлайн-ідентифікатори) – все це є особистими даними.
Делікатні дані – це те, що на думку ЄС більш особисте, ніж ім’я. Етнічне походження, релігійні переконання, сексуальні переваги, політичні погляди, кримінальна історія – все це можна віднести до делікатних даних. Нові правила покликані приділяти більше уваги захисту і делікатних даних.

Хоча може виникнути колізія в випадках, коли особисті дані стають делікатними. Наприклад, адреса електронної пошти – це особисті дані, але якщо адреса електронної пошти типу «fanat-trampa-2018@…», з якої можна зробити висновок про політичні уподобання користувача, тоді ці дані вже відносяться до делікатних. Подібні випадки, швидше за все, будуть розглядатися регулюючими органами в кожному конкретному випадку.

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

Краща тактика тут полягає в тому, щоб ніколи не запитувати більше даних, ніж вам потрібно – чим менше даних ви зберігаєте, тим менше ризику їх втратити.

Права користувача за вимогами GDPR

У будь-якій ситуації, коли ви запитуєте дані користувача, спочатку запитайте себе: як це вплине на права власника цих даних?

GDPR визначає наступні офіційні права, якими володіють власники даних:

Право бути поінформованим
Право доступу
Право на виправлення
Право на об’єкт
Право на перенесення даних
Право на видалення даних
Право не піддаватися автоматичному прийняттю рішень
Право обмежити обробку даних

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

Практичні кроки щодо забезпечення відповідності вимогам

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

Загальні правила захисту даних визначаються методом «Проектована конфіденційність» (PBD – Privacy by Design). PBD має на увазі, що конфіденційність не забезпечується законним дотриманням, а скоріше повинна прийматися організацією як підхід за замовчуванням.

PBD вважає, що конфіденційність, скомпрометована одного разу, не може бути відновлена, і тому слід заздалегідь передбачити і запобігти загрозам конфіденційності. Проектована конфіденційність визначається 7-ма принципами:

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

Оцінка впливу на конфіденційність (PIA)

Основним компонентом PBD і вимогою відповідності GDPR є оцінка впливу на конфіденційність (PIA).

Будь-цифровий продукт повинен мати PIA. В ідеалі PIA – це онлайн-документ, який росте в міру розробки продукту (відповідно до третього принципу PBD).

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

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

Визначте потребу в PIA: Опишіть сферу дії вашого проекту. Опишіть, які дані можуть знадобитися. Опишіть, наскільки делікатними можуть бути дані.
Документуйте очікувані потоки даних: як користувачі будуть розкривати дані, як вони будуть передаватися і зберігатися, чи будуть вони оброблені, і якщо так, то як? Визначте всіх, хто буде використовувати дані, включаючи керівництво і розробників. Розгляньте використання даних в майбутньому. Як довго будуть зберігатися дані? Як користувач може змінювати або видаляти свої дані?
Процедура погодження документів: як ви зареєструєте згоду користувача? Як ви перевірите згоду? Якщо згоду прямо не вказано, чи існує юридично обґрунтована основа для збору даних?
Визначення ризиків: який ризик від даних для окремих осіб? Чи збираються якісь непотрібні дані? Чи є резервні копії даних, резервні копії мають однаковий рівень безпеки? Хто має доступ до даних, як щодо стажистів, як щодо третіх сторін? Що робити, якщо дані губляться, змінюються, розкриваються, використовуються неправильно? Оцініть будь-які ризики, включаючи юридичні ускладнення і втрату репутації.
Визначення рішень: розробіть способи скорочення і, по можливості, усунення ризиків конфіденційності. Оцініть вартість рішень з точки зору часу та інвестицій. Як рішення впливають на конфіденційність користувачів і проект? Чи існують належні процедури для обробки порушення даних? Чи існують належні процедури для дотримання правових процедур, таких як судова ухвала про розкриття інформації?

Продовжуйте розробляти і розширювати PIA протягом усього терміну служби вашого продукту.

Призначення співробітника щодо захисту даних

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

Обов’язкова згода

Відсутність «ні» не означає «так». Згідно з 2-м принципом PBD, умова конфіденційності повинна прийматися за замовчуванням.

Згідно 4-му принципу PBD, ви не можете сказати, що користувач може використовувати систему тільки в тому випадку, якщо він погодиться порушити своє право на недоторканність приватного життя. Користувачі мають право на згоду, але вони також мають право не погоджуватися.

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

Відповідно до GDPR, згода ретельно визначається для забезпечення захисту прав користувачів:

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

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

Написання публічної заяви про конфіденційність

Більшість веб-сайтів розміщують загальну заяву про конфіденційність, але відповідність вимогам GDPR вимагає набагато більш конкретної декларації про конфіденційність.

Щоб відповідати принципам 6 і 7 PBD, ваш сайт, додаток або послуга повинні мати публічну заяву про конфіденційність (PPS), написану простою мовою, яка повинна бути зрозумілою користувачам.

Ваше PPS повинно містити наступну інформацію:

Які дані ви збираєте: переконайтеся, що ви перелічуєте всі дані, які ви збираєте, а не тільки очевидні; включаючи IP-адреси, часові пояси, мови за замовчуванням і т.п.
Чому ви збираєте ці дані: для кожної частини даних поясніть, чому ви її збираєте, і чому ви розглядаєте її як розумну та необхідну.
Які дані є обов’язковими: Перерахуйте будь-які дані, які є обов’язковими. Наприклад, якщо замість імені користувача потрібно вказувати адресу електронної пошти користувача, скажіть про це.
З якими третіми сторонами ви ділитеся даними: в розділі «GDPR» ви не можете публікувати спільну заяву про спільне використання з третіми особами, ви повинні вказати, які дані будуть передані, якій третій стороні, і з якою метою.
Звідки ще ви отримуєте дані: Якщо ви збираєте дані з інших джерел, вкажіть, звідки ви їх отримуєте і як ви їх використовуєте.
Як довго ви будете зберігати дані: будьте конкретні, як довго дані будуть існувати у вашій системі. Ви видалите дані, як тільки користувач перестане бути клієнтом? Якщо ви маєте намір зберігати дані на невизначений термін, скажіть про це.
Як користувач може скористатися своїми правами: Поясніть, як користувач може дізнатися, які його дані у вас є, і як користувач може запросити оновлення даних або їх видалення.

Зазвичай прийнято завірення типу «Ми не будемо ділитися вашими даними з будь-якою третьою стороною», але це не так для більшості компаній. Незалежно від того, чи то аналітика або веб-хостинг, ми ділимося величезною кількістю даних від імені наших користувачів, а GDPR вимагає від нас взяти на себе відповідальність за це. Не робіть обіцянок, які ви не можете виконати.

GDPR для веб-дизайну

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

Ввести повідомлення в момент отримання даних. Це звичка повідомляти користувачам про дані, які ви збираєте, в момент збору. Наприклад, під полем підписки на розсилку новин поясніть, що ви запитуєте адресу електронної пошти для надсилання маркетингових (рекламних) матеріалів, і ви також записуєте IP-адресу користувача, щоб він міг підтвердити свою згоду. Це гарантує, що відповідно до принципу 6 PBD користувачі знають, які дані ви берете, з якою метою, і у них не повинно виникати бажання перечитати повний текст політики конфіденційності (але завжди вказуйте посилання на повну публічну заяву про конфіденційність, щоб користувач міг отримати додаткову інформацію).
Щоб дотримуватися 2-го принципу PBD, при отриманні згоди прапорці чекбоксу не повинні бути попередньо проставлені.
Мінімізуйте кількість даних, які ви записуєте. Наприклад, дані місця розташування часто записуються з більшою точністю, ніж потрібно. Якщо вам потрібно знати область, в якій хтось знаходиться, з цього не випливає, що вам потрібно знати місто або район міста.
Коли ви записуєте дані користувача, переконайтеся, що ви записуєте спосіб надання згоди, його дату і час. Увімкніть опцію для позначки згоди в якості скасованої, якщо вам потрібно видалити дані в майбутньому.
Псевдонімізуйте дані там, де це можливо, шляхом заміни ідентифікаційних даних, таких як ім’я або адреса електронної пошти, анонімними ідентифікаторами.
Розділіть дані там, де це можливо, щоб особисті дані, такі як налаштування програми, не зберігалися разом з даними безпеки, такими як імена користувачів та паролі.
Раніше стандартна практика покладалася на адресу електронної пошти в якості імені користувача. Подумайте про те, чи має це сенс у вашому випадку. Ця практика може піддавати особисті дані потенційному розкриттю або неправильному використанню.
Переконайтеся, що жодна частина вашого користувацького інтерфейсу не відображує особисті дані. Якщо ваш користувацький інтерфейс вказує, що хтось увійшов в систему, використовуйте найменш конфіденційні дані. Наприклад, аватар користувача менш делікатний, ніж його ім’я, яке менш делікатне, ніж його адреса електронної пошти.
Чи може зловмисний користувач скомпрометувати дані, викликавши помилку? Наприклад, якщо користувач вводить адресу електронної пошти в формі «Забули адресу електронної пошти», чи буде форма видавати повідомлення, що нагадування про пароль було відправлено на певний є-мейл (і, відповідно, розкривати дані, що у певного користувача є обліковий запис)?