GDPR как повод для раздумий аналитика

(Из ленты Курсы бизнес анализа, тренинги и обучение бизнес аналитике| ArtofBA)

Одним из трендов современной ИТ-индустрии является персонализация услуг и сервисов, что повышает ценность персональных данных, а где ценности – там и угрозы. Правительства многих стран пытаются решить этот вопрос с помощью законов о защите персональных данных. Для ЕС таким регламентом является GDPR – General Data Protection Regulation. Рассмотрим вкратце, что это такое, чем это грозит и о чем нужно задуматься бизнес- и системным аналитикам.

Роли, права и обязанности

GDPR определяет роли, отношения и ответственности сторон в процессе работы с персональными данными.

Стороны выделены такие:

владелец данных (чаще всего это пользователь систем);
контроллер данных — компания, получающая и обрабатывающая данные для выполнения какой-то конечной цели;
процессор — компания, передающая и обрабатывающая данные для выполнения цели контроллера (без своих целей).

Основная суть GDPR: владелец данных имеет право

знать, с какой целью и какие данные о нем содержит любая система,
на защиту этих данных от несанкционированного им доступа,
отзыва этих данных.

А компании контроллеры и процессоры обязаны защитить эти данные и обеспечить реализацию прав пользователя по его запросу.

Персональные данные

Что такое персональные данные, в законах разных стран написано по-разному, но в общих чертах это набор информации, по которой из большого набора данных можно определить человека или малую группу лиц. Мария, Рыбы, Дракон, выпускница бакалавриата Института стран Азии и Африки 2018 года – в совокупности этих данных достаточно, чтоб по открытым источникам найти кто это (набор данных придуман специально для этой статьи, я не знаю, есть ли бакалавриат в ИСАА).

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

Ситуация, когда данные передаются от пользователя сразу контроллеру данных (через 1 систему), очень редка сейчас, вероятнее всего, данные польются через цепочку систем, и эти ручейки будут сливаться, разливаться, поглощаться и перемешиваться с другими потоками, как воды Волги, впадающей в Каспийское море. Но с точки зрения GDPR любое ведро с водой из этой реки должно быть защищено и определено по целям, на которые пойдет эта вода!

План действий

Итак, если вы аналитик системы, в которой есть данные пользователя, какие действия могут ожидаться от вас теперь в связи с этими данными?

Инвентаризация – какие данные вообще есть? И для какой цели они нам нужны? И если на этом этапе цель не обнаружена, можем ли мы не иметь (в первую очередь, не хранить, а еще лучше – не собирать эти данные?).
Для найденных персональных данных мы должны обеспечить надежное хранение (без возможности несанкционированного доступа) и уничтожение, как только цель их сбора будет выполнена.

А по целям? По целям мы должны убедиться, что пользователь в курсе этих целей и согласен с таким использованием его данных.

И все это – только основной сценарий!

При этом пользователь может отозвать у нас свое согласие на сбор и использование персональных данных. А может попросить нас рассказать, какие его данные есть у нас и с какой целью мы их используем. А может и сказать – забудьте про меня! Или отдайте мне обратно мои данные в машиночитаемом виде, я их отдам другим обработчикам. Или: прекратите мне слать ваш спам (маркетинговые рассылки)!

А если у нас есть передача этих данных в другую систему? Ооо, мы перед пользователем отвечаем и за себя, и за того парня, то есть должны протранслировать пользователю цели сбора другой системы и обработать запросы пользователя о его данных в обоих системах. И тут возникает множество интересных архитектурных задач (например, если мы не храним идентификаторы пользователя, чтоб обеспечить его анонимность, как же мы объясним нашим соседям, какие данные они должны удалить?).

Кто-нибудь скажет, что все эти ужасы не у нас, а в Европе. Ну ОК, но европейский закон защищает данные европейских пользователей по всему миру, а вы умеете отличать европейцев от остальных пользователей в вашей системе? И готовы урезать для них свою функциональность? Или хранить их данные только на территории ЕС? Кстати, в вашей стране тоже могут действовать законы о защите персональных данных (например, данные российских пользователей должны храниться и обрабатываться на территории России)

О боже, в каком сложном мире мы живем!

Итого:

Сначала нам нужно заявить пользователю, какие данные с какими целями мы хотим собирать.
Потом нам нужно защитить эти данные от несанкционированного доступа (а санкционирован доступ только с конкретными заявленными пользователю целями)
Как только цель, ради которой мы собирали данные, выполнена, данные надо удалить.
Как только пользователь заявил нам, что отзывает согласие на обработку, мы должны прекратить сбор данных.
Все запросы пользователя на получение накопленных нами данных о нем, удаление или экспорт его данных мы должны выполнить в 1 месячный срок. Кстати, а вы уже поняли, как вы идентифицируете пользователя? Чтоб не получилось так, что к вам пришел запрос на экспорт данных от имени пользователя, и вы отдали эти данные, но не пользователю, а мошеннику. Или сосед отомстил удалением данных посредством такого же запроса.

ОК, а если вы просто передаете данные? «Мы не храним! Мы передали и забыли!» Но в таком случае вы должны защитить каналы передачи данных и проходимость согласий и запросов пользователя к системам – контроллерам и передачу к пользователю – списков данных и целей обработки за все системы, которые стоят за вами, то есть стать полностью прозрачными для пользователя.

Чтоб обеспечить все это типовыми схемами, между компаниями контроллерами и операторами подписываются соглашения BSR, C2P или C2C соглашения.

Пример

Ну а теперь давайте попробуем применить эти знания на практике!

Допустим, мы — группа товарищей, которые затеяли сделать митап для системных и бизнес-аналитиков на интересную тему и хотим собрать наиболее активных коллег, так как мест у нас мало. Сделали страничку с кнопкой «Хочу на митап», как обычно всегда делали, а пришло супермного ответов и теперь мы детализируем информацию о кандидатах на участие: писали ли они статьи на наш сайт, являлись ли они спикерами на других митапах и активны ли в нашем телеграм-чате, мы же хотим собрать наиболее активных!

Из систем у нас есть следующее:

Страничка с кнопкой и полями ввода ФИО и e-mail’а для заявки,
Таблица, куда падают все заявки,
CMS сайта со статьями,
Самописная БД по мероприятиям (там планы, докладчики, ведущие воркшопов, волонтеры),
Бот, подсчитывающий полезную активность и токсичность участников в телеграм-чате.

В общем, все как обычно и даже чуть больше. И что же принесет нам GDPR, если мы решим ему полностью соответствовать?

Для странички с кнопкой:

В пользовательском соглашении должны быть описаны все передаваемые данные с целями их передачи,
В интерфейсе должна быть возможность отозвать согласие на передачу данных,
В интерфейсе должна быть возможность написать запрос «забудьте обо мне», «выгрузите мне мои данные», «расскажите, какие данные вы обо мне собираете и зачем» и т.д.
Нефункциональные требования по безопасности передачи данных в инфраструктуру (в таблицу с заявками).

Для таблицы с заявками и самописной БД по мероприятиям появляются нефункциональные требования по security:

Безопасная передача данных на всем пути (в том числе и трансграничная при необходимости),
Защита от несанкционированного доступа к данным,
Хранение данных европейских пользователей в Европе,

А также набор функциональных требований:

Удаление данных после осуществления цели сбора данных,
Удаление данных по запросу пользователя (в том числе и отправка запросов в смежные системы),
Выгрузка данных по запросу пользователя.

И если мы собираем эти данные (о количестве статей, рейтинге в чате, участии в подготовке мероприятий) руками, а не автоматически, то эти же требования по безопасности предъявляются и к персоналу, а людям забывать информацию еще сложнее, чем системам 🙁

Кстати, а когда вы договаривались с автором статьи о публикации, давал ли он вам согласие на то, чтоб данные об авторе, указанные в статье, использовались при выборе участников митапа? Формально, это уже другая цель, и использовав эти данные без разрешения, вы нарушили права пользователя!

Как видим, выполнение требований GDPR (а на самом деле и любых других регулирующих работу с персональными данными требований) вносит много волнующих новых действий и знаний в и без того тревожную жизнь аналитика, поэтому обсудите с руководством стратегию компании по преодолению этого вызова и не расстраивайтесь, когда не встретите понимания на первом обсуждении, ведь полный цикл принятия неизбежного это отрицание – гнев – торг – депрессия –

принятие.

И да пребудет с нами Сила!

Тренинги от «Art of Business Analysis»:

Онлайн:

Комлексный онлайн тренинг по бизнес-анализу (40 PD hours)

Power BI: Создание решения для бизнеса (16 часов)

Data Science и машинное обучение для бизнес-аналитиков (16 часов)

Оффлайн:

Комплексный тренинг по бизнес-анализу (40 PD hours)

Базовые компетенции бизнес-аналитика

Источник: GDPR как повод для раздумий аналитика