GDPR и 152-ФЗ одновременно: где режимы расходятся и как удовлетворить оба

Последние два месяца у нас идёт проект, который мы в шутку называем «два регулятора за одни деньги». Клиент - российская компания, работающая с европейскими партнёрами и их сотрудниками. Данные граждан ЕС у них есть, данные граждан РФ тоже есть. Соответственно - и GDPR с мая 2018 года, и 152-ФЗ уже сейчас. Задача звучала просто: провести аудит и понять, где мы, что нужно закрыть и в каком порядке. На практике оказалось интереснее.

Забегая вперёд: два режима в значительной части совместимы, но там, где они расходятся, просто «взять самое строгое из двух» не всегда работает. Иногда требования буквально противоречат друг другу по механике, и нужно искать конструкцию, которая удовлетворяет обоим.

Где режимы легко совмещаются

Начнём с хорошего. По большинству базовых вещей GDPR и 152-ФЗ говорят примерно одно и то же, просто разными словами:

• Принцип минимизации данных - собирай только то, что нужно для конкретной цели. Оба режима требуют обоснования каждой категории данных.
• Уведомление об утечке - и Роскомнадзор по 152-ФЗ, и надзорный орган по GDPR ждут сообщений об инцидентах. Сроки разные (об этом ниже), но сам механизм похож.
• Права субъекта - доступ к своим данным, исправление, возражение против обработки. В 152-ФЗ это статья 14-17, в GDPR - статьи 15-21. Реализовать один внутренний процесс для обработки таких запросов - вполне реально.
• Технические меры - шифрование, контроль доступа, журналирование. Здесь требования пересекаются настолько, что выполнение одного набора мер в большинстве случаев автоматически закрывает второй.

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

Где начинаются расхождения

Первое - согласие. Это самое болезненное место. По 152-ФЗ согласие может быть конклюдентным - то есть человек своими действиями выражает согласие, не подписывая никакой бумаги. По GDPR требования к согласию жёстче: оно должно быть однозначным, добровольным, конкретным и отзываемым. Галочка «я согласен» по умолчанию стоящая - это не согласие по GDPR. Использование сервиса как подразумеваемое согласие - тоже, в большинстве интерпретаций, не то.

На практике мы увидели у клиента формы, которые с точки зрения 152-ФЗ были вполне корректными, а по GDPR - нет. Решение: переработать под более строгий стандарт GDPR, что автоматически закрывает 152-ФЗ тоже. Но это требует переработки всех форм сбора данных, включая внутренние HR-формы для европейских сотрудников.

Второе - сроки уведомления об утечке. По GDPR - 72 часа с момента обнаружения утечки до уведомления надзорного органа. 152-ФЗ конкретного срока уведомления регулятора об инцидентах не устанавливает - обязанность уведомлять Роскомнадзор о нарушениях в явном виде в законе не закреплена. Для клиента с данными и тех и других граждан это означает: нужен единый процесс реагирования на инцидент, ориентированный на требование GDPR как самое жёсткое. Иначе в суете с выяснением «под какой режим попадает эта утечка» можно пропустить 72-часовое окно GDPR.

Мы зафиксировали это как требование к процессу: при обнаружении любого инцидента с ПДн - немедленная эскалация, квалификация по обоим режимам параллельно, не последовательно.

Третье - сроки хранения. Это самое тонкое расхождение. 152-ФЗ в части коммерческих отношений прямо не запрещает долгое хранение - важно обоснование цели. GDPR жёстче: нет актуальной цели - нет данных, удаляй. При этом есть отечественные требования, по которым часть документов с ПДн нужно хранить определённый срок по налоговому или трудовому законодательству. Налоговый кодекс говорит одно, GDPR говорит другое.

С этим мы возились дольше всего. Решение не универсальное - нужно разбирать по категориям данных: что относится к налоговым обязательствам (там есть законное основание для хранения по GDPR тоже), что относится к маркетингу (там срок диктует GDPR), что к HR (там отдельная история с трудовым законодательством).

Что получилось по итогу

Архитектура обработки данных у клиента в результате делится на три слоя:

• Данные с обязательным сроком хранения по российскому законодательству - храним с документальным обоснованием, которое закрывает законное основание и по GDPR (legal obligation, статья 6(1)(c)).
• Данные на основе согласия - переработанные формы по стандарту GDPR, которые автоматически корректны и по 152-ФЗ.
• Данные для бизнес-операций - legitimate interest по GDPR плюс необходимость исполнения договора, с соответствующим обоснованием.

Отдельно пришлось выстраивать реестр обработки данных - по GDPR это Records of Processing Activities, по 152-ФЗ это фиксация в политике обработки ПДн. Форматы разные, но смысловая нагрузка схожая: кто, что, зачем, сколько хранит, кому передаёт. Сделали единый внутренний реестр с атрибутами, которые покрывают оба требования.

Где мы сейчас

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

Наблюдение, которое вынесем как практическое: компаниям, работающим на два регуляторных периметра одновременно, имеет смысл начинать аудит не с вопроса «соответствуем ли мы 152-ФЗ», а с вопроса «какие данные у нас есть и зачем». Ответ на второй вопрос закрывает оба режима куда эффективнее, чем попытки отдельно галочить каждый чеклист.

До мая 2018 года остаётся меньше восьми месяцев. Для компаний с европейскими клиентами или партнёрами это не абстрактная дата в далёком будущем.