GDPR (или «Регламент») содержит несколько оснований для обработки персональных данных. Эти основания можно условно разделить на две большие группы. Это обработка на основании личного согласия носителя (владельца) персональных данных, и обработка на иных основаниях. В данной статье рассматриваются условия правильного оформления согласия на обработку персональных данных, и не затрагиваются особенности обработки по иным основаниям.
Статья представляет собой краткую выжимку и мою интерпретацию Руководства по согласию в соответствии с Регламентом 2016/679 (Guidelines on consent under Regulation 2016/679) («Руководство») и некоторых документов, на которые есть ссылки в Руководстве.
Как правильно оформить
Согласие на обработку персональных данных – это средство безопасности, которое дает вашей компании свободу (пусть и ограниченную) в сфере обращения с персональными данными.
Существуют базовые условия, которым должно отвечать согласие на обработку персональных данных. Несоблюдение любого из них может привести к ситуации, когда полученное согласие окажется полностью или частично недействительным, а ваша компания – под угрозой штрафов.
Штрафы GDPR за неправильно оформленное согласие: до 20 млн. евро или 4 % от глобального оборота компании за предшествующий финансовый год, в зависимости от того, что выше (Статья 83(5)(a) Регламента).
Четыре базовых условия правильно оформленного согласия: согласие дается свободно, является конкретным, информированным и выражено недвусмысленно. Дополнительное, пятое условие: согласие должно быть явно выраженным при особых обстоятельствах.
Рассмотрим каждое из условий подробнее.
Согласие дается свободно
Согласие считается данным свободно, если у владельца персональных данных есть реальный выбор, дать его или нет, и на каких условиях. Для определения степени свободы применяются критерии: привязки к условиям, дисбаланса возможностей (или полномочий) между владельцем данных (частным лицом) и контролером (тем, кто их обрабатывает); возможности дробления целей, в отношении которых дается согласие; негативных последствий отказа дать согласие.
Привязка к условиям
Согласие не является свободным, если согласие представляет собой часть договора, которая не подлежит обсуждению или изменению по инициативе владельца данных. Обрабатываемые данные не являются необходимыми для оказания услуги или заключения (выполнения) договора. Без дачи согласия человек не может получить основную услугу, заключить или исполнить договор. Или же услуга будет оказана в усеченном виде, на более худших условиях (например, ограниченный функционал).
Если договор допускает обсуждение или изменение его условий, размещение текста согласия в тексте договора вместе с иной информации все равно считается неправильным способом информирования о запросе согласия. Подробнее см. Согласие является информированным.
Пример из Руководства: Сервис по редактированию фотографий запрашивает согласие на обработку геолокационных данных о месте нахождения человека. Сервис уведомляет пользователя, что данные о месте нахождения собираются в целях изучения поведения пользователя и рекламирования товаров и услуг. Очевидно, что сама по себе услуга редактирования не требует сбора геолокационных данных, и в этом случае выданное согласие может быть признано недействительным.
На мой взгляд, в ситуации, описанной выше, допустимы исключения. Геолокационные данные для сервиса обработки фотографий могут быть включены в согласие, если предоставляется отдельная услуга редактирования фотографий с привязкой к местности, в которой была сделана фотография. Представим, что пользователю интересно, чтобы сервис сам указывал на фотографии точное название местности, где она была сделана. Это возможно в режиме реального времени (автоматическое редактирование в момент снимка) или пользователь соглашается, что сервис будет запоминать место, в котором была сделана фотография, и затем будет предлагать название местности для редактирования.
Во всех случаях, когда планируется обработка данных, выходящих за пределы явно и однозначно необходимых для предоставления сервиса или заключения/выполнения договора, такая обработка должна быть связана с оказанием дополнительной услуги. Несогласие с обработкой дополнительных данных, не нужных для работы основного сервиса, может приводить только к невозможности использования дополнительного сервиса, но не основного.
Дисбаланс возможностей
В более выгодном положении всегда находятся органы власти и им подобные структуры. Дисбаланс возможностей присутствует в отношениях работодателя и работника. Регламент и Руководство рассматривают человека, который дает согласие, как изначально находящегося в неравных условиях. Если ваша компания принимает на работу (в любой форме) частное лицо из Евросоюза, к оформлению его согласия на обработку персональных данных необходимо относится очень серьезно. Это особенно актуально для компаний, активно использующих перевод сотрудников в офисы в странах Евросоюза. Таким компаниям стоит иметь в виду, что их сотрудники из России, Украины или других стран СНГ, получая легальный статус для пребывания в ЕС, автоматически подпадают под защиту правил GDPR.
Пример: Часто применяемый для программистов (и иных удаленных сотрудников) способ учета рабочего времени через регулярные скриншоты с монитора. Для исключения или хотя бы минимизации риска принуждения сотрудника к согласию на отслеживание данных с его экрана, желательно в любой договор с таким сотрудником или независимым исполнителем (подрядчиком) включать условие о мониторинге рабочего времени через данные экрана. В этом случае обработка полученных данных будет проводиться уже не на основании согласия, а на другом легитимном основании – необходимости выполнения заключенного договора (Статья 6(1)(b) Регламента).
Если же данное условие по какой-либо причине не включено в договор, то при получении согласия вашего сотрудника необходимо будет обосновать, что такая практика является широко распространённой в среди работодателей: Заключение 15/2011 об определении согласия / Opinion 15/2011 on the definition of consent. При всей очевидности для вас этого факта, не гарантировано, что при конфликте контролирующий орган не потребует каких-то документальных подтверждений такой практики.
В соответствии с Правом Европейского Союза, заключения не относятся к обязательным для применения нормам права. Вместе с тем, они содержат определенные примеры и толкования правил Регламента. Заключения предоставляют всем участникам обработки персональных данных лицам и государствам ЕС унифицированный подход к применению норм GDPR. (Даже если заключения были выпущены до принятия GDPR, они послужили основной для разработки Регламента и могут приниматься во внимание контролирующими органами и судами).
Я бы рекомендовал всегда заранее обсуждать вопросы мониторинга с сотрудником. Желательно убедиться, что использование скриншотов не будет вынужденным для него и не повлияет на случайный сбор каких-либо персональных данных, не требующихся для выполнения работы по договору.
Пример: Сотрудник вынужден использовать личный компьютер не только для работы на вашу компанию, но, скажем, и для наблюдения за инвалидом, или престарелым членом семьи в режиме реального времени. В этой ситуации лучше обеспечить его дополнительным, рабочим компьютером. Иначе вы рискуете случайно собрать данные о третьих лицах. Просто же ограничить сотрудника в праве использовать Интернет или внутреннюю сеть для личных нужд нельзя, такое ограничение требует серьезных оснований.
(Подробнее о нюансах обработки персональных данных в электронных коммуникациях можно узнать из Рабочего документа по наблюдению за электронными коммуникациями на рабочем месте / Working document on the surveillance of electronic communications in the workplace).
В любых отношениях, где присутствует дисбаланс возможностей, лучше избегать обработки данных на основании согласия. Вместо использования согласия старайтесь тщательнее продумать ваши бизнес-процессы и указывать случаи обработки персональных данных в договорах, которые вы заключаете. Согласие зачастую является сложным в оформлении и неудобным инструментом в системе «работодатель — работник». Вашей компании придется всегда быть готовой пройти тест на свободу воли ваших сотрудников при выдаче согласия.
Перечень случаев дисбаланса открытый и не ограничен работодателями или органами власти. Дисбаланс возможностей между вашей компанией и частным лицом из Евросоюза может быть там, где отказ от дачи согласия на ваших условиях ведет к любым негативным последствиям для такого лица. В том числе, к дополнительным материальным издержкам.
Пример: Ваша компания продает товары или предоставляет сервисы, которые сложно заменить в силу и уникальности или даже вашей более выгодной цены по сравнению с конкурентами. Отказ в даче согласия на ваших условиях не позволит покупателю из Евросоюза выгодно купить у вас данный товар или воспользоваться вашим сервисом. В результате, ему придется заплатить за них дороже другому поставщику.
Дробление целей
Если есть возможность разделить цели получения согласия – их нужно разделить. Как правило, такая возможность всегда есть. У человека должен быть простой и понятный выбор: дать или не дать согласие по конкретной цели обработки.
Пример: Пользователь согласен, чтобы вы рассылали ему сведения об обновлении вашего программного продукта. Но не согласен, чтобы вы передавали его данные вашим партнерам. В такой ситуации нельзя формулировать запрос вот так:
«В целях обновления продукта я настоящим соглашаюсь на получение от /.../ уведомлений о выходе новых версий, в том числе получать уведомления об обновлённом/добавленном функционале, реализуемом партнерами /.../, для чего соглашаюсь с тем, что /.../ может передавать мои персональные данные своим партнерам по своему выбору».
Я рекомендую при получении согласия (и в целом при обработке на любых иных основаниях) максимально дробить (детализировать) виды собираемых данных, цели их получения и всю иную необходимую информацию. Это поможет вам не только избежать обвинений в сборе данных неким массивом, без конкретизации, но и понять, что и зачем вы собираете, используете и храните, как долго это нужно хранить. При получении любых запросов на изменение или удаление данных вы всегда сможете оперативно их изменить или удалить, без вреда для остальных данных.
Если же вы включили персональные данные в единый документ (договор или какую-либо громоздкую форму, анкету и т.п.), то для их удаления или изменения вам потребуется выполнить множество формальностей. Начиная от повторного подписания (одобрения) такого документа у самого владельца данных, до повторного прохождения процедуры согласования внутри собственной компании.
Негативные последствия
Их не должно быть. Человек может отказаться дать согласие в отношении персональных данных, которые явно не являются необходимыми для оказания ему какой-либо услуги, исполнения договора. И это не должно приводить к отказу в оказании ему услуги или к ее оказанию на худших условиях.
Избежать негативных последствий просто. Повторюсь, что любые данные, которые не нужны для работы основного сервиса, могут обрабатываться на основании согласия, даваемого в отношении какой-либо дополнительного сервиса или дополнительной привилегии (льготы, скидки и пр.), которую предоставляет ваша компания. Я бы рекомендовал для тех данных, которые вы хотите собрать и обрабатывать, но не уверены, точно ли они необходимы для работы основного сервиса, выделить из основного функционала какой-то дополнительный (если это технически возможно). И привязать получение дополнительных данных к возможности получить расширенный функционал.
Согласие является конкретным
Конкретность обеспечивается соблюдением следующих условий:
- цели, для которых обрабатываются данные, должны быть конкретными, ясно выраженными и обоснованными;
- согласие должно запрашиваться с дроблением целей (здесь повторяется требования о дроблении, см. выше); и
- информация, предоставляемая при получении согласия, должна четко отделяться от информации по остальным вопросам (см. также Согласие является информированным).
Пример из Руководства: Оператор кабельного телевидения собирает персональные данные пользователей и направляет им персональные предложения о новых фильмах, на основе пользовательских предпочтений. Спустя время, оператор решает допустить третьих лиц демонстрировать целевую рекламу своим пользователям, тоже на основе пользовательских предпочтений. Здесь оператору нужно получить новое согласие от своих пользователей, в отношении новой и самостоятельной цели.
Рассмотрим, как правильно указывать и формулировать цели обработки данных в соответствии с Регламентом. Рекомендации по определению целей можно найти в Заключении 03/2013 по ограничению целей (Opinion on purpose limitation).
Цель обработки не должна быть сформулирована неявно (размыто) или слишком обобщенно. В частности, формулировки «улучшение пользовательского поведения», «в маркетинговых целях», «в целях безопасности информационных технологий» или «для будущих исследований» обычно не являются правильными в рамках GDPR. В то же время, Заключение 03/2013 рекомендует всегда сверяться с каждым конкретным случаем получения согласия. Излишняя детализация может привести к обратному эффекту – информация о цели дачи согласия будет перегружена сложными для понимания терминами. Это, в свою очередь, нарушит одно из фундаментальных требований Регламента – использовать понятный и простой язык любых документов по обработке персональных данных.
В Приложении 3 к Заключению 03/2013 приводятся примеры, как можно формулировать цели в зависимости от ситуации.
Пример A: Местный магазин, торгующий одеждой и рассылающий свои каталоги о новых коллекциях ограниченному количеству местных жителей. В этом случае допускается указать просто «маркетинг» в качестве цели для сбора данных об именах, адресах и телефонах клиентов, т.к. у магазина ограниченный круг покупателей, все покупатели хорошо понимают, что речь идет только о получении каталога с одеждой. При этом каталог позволяет купить коллекции, которые еще не поступили в широкую продажу и не доступны другим покупателям. Т.е. речь идет о дополнительной услуге, отказавшись от которой покупатели все равно смогут приобрести ту же одежду, только позднее.
Пример B: Если речь идет о глобальной торговой площадке, собирающей множество данных и использующей сложную аналитику пользователей и их поведения для таргетированной рекламы и персональных предложений, необходимо детализировать каждую цель обработки данных; в том числе, указать критерии принятия автоматизированных решений на основе профилей пользователей.
Заключение 03/2013 советует применять многоуровневые или «слоеные» (layered) уведомления о целях обработке данных, а именно:
Пример C: На здании размещены таблички, позволяющие немедленно уведомить посетителей о том, что ведется видеонаблюдение. Таблички содержат краткую информацию об обработке: ссылку на веб-сайт и/или имя компании, ответственной за нее. На самом же сайте размещена подробная Политика, регламентирующая обработку данных и права владельцев персональных данных. Такой прием позволяет в дружественной и простой манере оперативно информировать об обработке персональных данных.
Многоуровневый способ информирования сегодня применяется все большим числом офф- и онлайн сервисов. Например, при телефонном разговоре с банками воспроизводится автоматическое уведомление о записи разговора. При заходе на страницу веб-сайта посетитель видит короткое уведомление о сборе куки, в котором содержится ссылка к Политике конфиденциальности или же к Политике обработке куки. Если дальнейшие действия посетителя веб-сайта предполагают сбор иных данных (например, при заполнении формы), вновь запрашивается согласие на обработку и дается ссылка на документ с подробной информацией.
Согласие является информированным
Руководство рекомендует минимальный набор сведений, которые должен получить владелец данных перед тем, как дать свое согласие. Это информация о:
- том, кто собирает данные (контролере), позволяющая его идентифицировать;
- целях обработки;
- видах обрабатываемых данных;
- праве на отзыв согласия;
- как данные используются для принятия автоматизированных решений (если такие принимаются);
- о возможных рисках передачи данных лицам из стран вне Евросоюза, без адекватного уровня защиты персональных данных и без принятых мер защиты.
Остановлюсь на паре пунктов, на которые не всегда обращают внимание.
Во-первых, информация о том, кто собирает и/или обрабатывает данные. Я рекомендую, чтобы эта информация была легко доступна из запроса на дачу согласия, и была бы достаточна для идентификации в соответствии с личным законом соответствующего государства, применимым к той или иной компании. Нужно убедиться, что на сайте или в Политике конфиденциальности есть прямое указание наименования, адреса и/или идентификационных номеров вашей компании. Указать просто фирменное наименование вашей компании недостаточно. Если же данные будут обрабатываться группой компаний, нужно перечислить все компании такой группы.
Под личным законом понимается закон государства, которым регулируется статус юридического или иного лица, определяется требования к наименованию, порядку регистрации, и т.д.
Во-вторых, манера (способ) информирования. Запрос на согласие должен содержать достаточно информации и использовать краткий язык, понятный среднестатистическому человеку. Недопустимо, чтобы согласие было скрыто в тексте, в том числе путем конструкций вроде «я осознаю, что…» и аналогичных им. Отсылки на многостраничные Политики обработки персональных данных и аналогичные документы, если при этом основная информация не дается в легкой и понятной форме в момент получения согласия, тоже недопустимо.
Рекомендуется выделять текст согласия соответствующим заголовком.
Пример: Для сервисов мобильных приложений, где размер экрана существенно затрудняет прочтение документов, особенно таких, как лицензии на пользование сервисом и пр., я бы рекомендовал запрос на согласие вынести в отдельную страницу (экран). Не беда, если ваше приложение дважды или трижды запросит пользователя проставить отметки в чек-боксе о согласии на обработку их данных, и о согласии с условиями лицензии. Хуже, если вы сделаете согласие разделом в конце многостраничного документа, пролистать (не говорю уже о «прочитать») который даже до середины сможет не каждый. Тогда есть риск, что ваш запрос будет признан ущербным с точки зрения надлежащего информирования, а само согласие – несвободным.
Согласие выражено недвусмысленно
Это требование тесно связано с требованием об информированности и, в частности, со способом информирования / запроса на дачу согласия. Согласие должно быть дано путем заявления или четкого утвердительного действия. Молчание или бездействие не может считаться согласием. В этом случае предполагается, что согласие не дано.
Формы согласия (путем заявления) включают в себя не только заявления в письменной форме. Это может быть все что угодно, в том числе запись устных переговоров. При записи разговора обязательно информирование о сборе данных и о том, что запрашивается согласие.
Встречаются ситуации, когда сервис или веб-сайт запрашивает согласие онлайн через заранее отмеченный чек-бокс, и что-то вроде кнопки «Далее». Вместо собственноручного проставления отметки о согласии используется отметка, проставленная сервисом (веб-сайтом) по умолчанию. Здесь согласие считается выраженным неопределенно, т.к. для отказа от согласия пользователю онлайн сервисов необходимо провести отмену заранее предустановленных одобрений.
Часто такими предустановленными чек-боксами «грешат» сервисы по бронированию билетов, отелей и прочие. Одновременно с бронированием билета они проставляют ваше согласие с покупкой страховок от отмены рейса, потери, страхование жизни и прочие услуги. Оставим за рамками данной статьи законность такого способа продажи дополнительных услуг. Важно то, что даже если клиент согласится (случайно) с покупкой такой страховки, вряд ли он мог дать свое информированное и недвусмысленное согласие на передачу своих данных третьим лицам (страховым компаниям и прочим).
Согласие должно быть явно выраженным при особых обстоятельствах
Для ряда случаев Регламент GDPR требует, чтобы согласие было явно выраженным. Как правило, это ситуации сбора специальных категорий данных (например, о здоровье), передачи в третьи страны без адекватного уровня защиты персональных данных, или принятия автоматизированных решений в отношении владельца данных. Здесь рекомендуется (хотя не требуется в жесткой форме) оформлять согласие в виде документа (формы), подписанного владельцем данных. Согласие может выражаться и иными способами: направлением фото документа, электронного письма и т.д. Допускается фиксировать согласие путем записи устных переговоров, если во время разговора сообщается вся необходимая информация.
Пример из Руководства: Для специальных ситуаций рекомендуется применение двух- или многоуровневых подтверждений согласия. Например, в отдельном электронном письме указывается, для каких специальных целей запрашивается согласие, какие данные будут обрабатываться. Пользователя просят направить ответное письмо со словами «Я согласен». Это позволяет убедиться, что пользователь не случайно проставил отметку в чек-боксе или направил ответное письмо, не дочитав запрос до конца.
Отзыв согласия
Как лучше реализовать механизм отзыва согласия
Помните, что отзыв согласия должен быть реализован таким же легким способом, каким давалось согласие. Хотя Регламент не требует, чтобы механизм отзыва согласия на 100 % совпадал с механизмом его подтверждения.
Пример из Руководства: При покупке билетов на музыкальный фестиваль согласие на обработку данных в целях маркетинга подтверждалось путем клика «Да» или «Нет». Но для отзыва согласия требуется позвонить в офис продавца билетов с 8 утра до 5 вечера. Это недопустимая ситуация в рамках GDPR, нарушающая условие о легкости отзыва согласия.
Не забывайте, что информация о праве человека отозвать свое согласие должна быть предоставлена ему до получения согласия, в самом запросе о согласии. Одновременно, необходимо сообщить, как реализовать это право. Это означает, что самый простой и эффективный способ сообщить об этом – просто предложить механизм отзыва в самом тексте запроса, в личном кабинете, в мобильном приложении или в ином сервисе. Механизм отзыва согласия должен быть интуитивно понятным человеку.
«Механизм отзыва согласия должен быть интуитивно понятным человеку» — тот случай, когда опытный UX-designer просто необходим.
Пример: Использование в электронных письмах ссылки «Отписаться от рассылки» («Unsubscribe») для отказа от получения уведомлений – простой и удобный способ. Он позволяет быстро найти любое письмо и отозвать согласие. Можно добавить отдельную кнопку или ссылку в личном кабинете пользователя. С понятным текстом, вроде «Отказаться от обработки персональных данных». Далее вы можете или просто удалить все данные пользователя, или же предложить ему опции, какие данные удалить, а какие оставить.
Очевидно, что какие-то оставшиеся данные в отсутствие удаленных данных могут стать бесполезными. Об этом нужно заранее предупредить пользователя, что будут удалены все связанные данные, а не только выбранные.
Пример: Можно отдельно удалить данные платежной карты клиента интернет-магазина без ущерба для контактных данных. Но если удалить все контактные данные, включая ФИО пользователя, то данные платежной карты без них не нужны. Так как не понятно, кому и куда доставлять товар.
Что делать после отзыва согласия
После отзыва согласия ваша компания должна незамедлительно остановить обработку таких данных, если нет иных оснований для ее продолжения. Все действия по обработке персональных данных, которые были совершены до момента отзыва согласия, считаются законными. Но только в том случае, если согласие было изначально оформлено правильно.
Пример: Данные, ранее полученные на основании согласия, впоследствии стали необходимы для выполнения условий заключенного договора или их необходимо хранить в соответствии с требованиями законодательства: налогового, финансового или трудового и любого другого (Статья 6(1)(b) Регламента).
Именно в такой ситуации становится очевидной польза от максимального дробления целей обработки данных и самих данных, которые вы можете собирать и обрабатывать. Разобравшись, какие данные и для каких целей вы обрабатываете, вы легко поймете, на каких основаниях должна вестись обработка: на основании согласия или же есть другие основания, не зависящие от него.
ВАЖНО! Нельзя произвольно менять основания обработки данных.
Это один из тонких моментов GDPR, на который указывается в Руководстве. Основание для обработки данных должно быть выбрано вашей компанией (и сообщено владельцу данных) до начала обработки. Нельзя произвольно менять основания обработки персональных данных.
Пример из Руководства: Если окажется, что согласие было оформлено с нарушением правил GDPR, и данные собирались на основании недействительного согласия, нельзя ретроспективно заменить согласие на иное основание; например – наличие законного интереса в ведении бизнеса через рекламные рассылки (Статья 6(1)(f) Регламента).
Здесь остается открытым вопрос, что делать, если вдруг согласие было оформлено неправильно, но данные вы обязаны хранить и передавать каким-либо контролирующим органам на основании требований местного закона? На мой взгляд, это может быть неустранимым риском, т.к. вам придется выбирать, что нарушить: местный закон или правила GDPR.
Запрет произвольной замены оснований для обработки данных показывает, насколько важно тщательно продумать бизнес-процессы в вашей компании перед тем, как приступить к обработке персональных данных в соответствии с GDPR.
Следует помнить, что при отозванном согласии, если ваша компания продолжает обрабатывать данные на ином основании и изменились цели обработки, вы обязаны уведомить об этом владельца персональных данных (Статьи 13 и 14 Регламента).
Согласие получено: как работать дальше
Здесь все просто. Нужны постоянный мониторинг и актуализация. Согласие – не статичный документ, а часть динамической системы данных. Любое изменение, связанное с получением новых данных или использованием уже имеющихся, но для иных целей (например, планируется передача третьим лицам), требует обновления ранее полученного согласия. Если вам удалось выстроить логичную систему обработки персональных данных, включая понятные связи между категориями (видами) данных, целями и основаниями их обработки, конкретными действиями по обработке, сроками и иными элементами, вам не составит труда оперативно запросить новое согласие. В идеале данный процесс должен быть автоматизированным.
Краткие выводы:
Можно оптимально подойти к согласию ваших пользователей, партнеров, клиентов, на обработку их персональных данных, если следовать известным в среде программистов принципам DRY, KISS и, особенно YAGNI. Если интерпретировать эти принципы на язык GDPR, то:
DRY:
Дробите систему (т.е. согласие как единый документ или как набор подтверждений) на максимально простые элементы. Например, используйте чек-боксы напротив каждого вида персональных данных с пояснением цели обработки и/или ссылкой на конкретное место в Политике обработки персональных данных, дающее дополнительные сведения вашему пользователю. Это будет для всех удобным и понятным решением. Пользователь всегда может выбрать, с чем согласится, а с чем – нет.
Если нужно будет использовать собранные данные для новой цели, вы просто добавите эту новую цель (и отдельный чек-бокс для нее). Если что-то требует пояснения, можно дать прямую ссылку на разъясняющий текст. Предоставьте человеку возможность через сортировку легко найти цели обработки его данных, сроки хранения, кому и какие данные могут передаваться и на каких условиях. Большие документы желательно строить с использованием перекрестных ссылок, чтобы избежать повторения текста.
KISS:
Четко формулируйте цели обработки персональных данных, в отношении которых вы хотите получить согласие их владельца. Пишите простым и понятным языком. Избегайте ненужных обобщений данных, целей их обработки, сроков хранения и пр. в единый пул/документ или несколько массивных пулов/документов. Не забывайте, что доступность и понятность документов обычному человеку, регламентирующих обработку персональных данных, – одно из фундаментальных требований в Регламенте GDPR.
YAGNI:
Не собирайте больше данных, чем вам необходимо. Реально необходимо. Много данных, это не только ваш актив, но и пассив. Данные, в отношении которых вы получили согласие, требуют регулярного внимания. Это еще одно общее фундаментальное требование GDPR: персональные данные должны быть адекватными, связанными с целями обработки и необходимыми для них (пункт 39 Вводной части Регламента).
Уже собранные данные нужно регулярно проверять на актуальность, на соответствие целям обработки (цели могут изменяться, дополняться), обеспечивать безопасность хранения и удалять, как только они объективно становятся ненужными. Согласитесь, случайная утечка только паспортных данных или же данных платежных карт (не говоря о данных специальных категорий) влечет разные по тяжести последствия для самих людей и для вашей компании, ответственной за обработку этих данных.
