Самая распространённая ошибка при оценке соответствия GDPR — обращать внимание только на всплывающее окно Cookie и страницу политики конфиденциальности. Для специалистов по контролю качества или управлению безопасностью важно не то, «написано ли что-то», а то, «собираются ли данные на законных основаниях, предоставляется ли понятная информация, обеспечивается ли надлежащая передача данных и можно ли это доказать».
Если сайт ориентирован на пользователей из ЕС или фактически обрабатывает персональные данные граждан ЕС, при самостоятельной проверке рекомендуется сначала обратить внимание на четыре момента: какие персональные данные собираются, на каком основании, кому они передаются и может ли пользователь отозвать согласие или запросить удаление данных. Такой порядок очень практичен, поскольку на многих сайтах тексты внешне оформлены полно, а реальные проблемы возникают в формах, кодах аналитики и сторонних плагинах.
Проще говоря, базовое соответствие определяется не красотой страницы, а тем, можете ли вы проследить путь данных от момента их поступления на сайт до хранения, использования, передачи и удаления.
Нет. Политика конфиденциальности — лишь часть обязанности по информированию, а не само соответствие требованиям.
Политика конфиденциальности, пригодная для практического использования, как минимум должна отвечать на несколько ключевых вопросов: кто обрабатывает данные, какие данные обрабатываются, какова цель обработки, каково правовое основание, как долго хранятся данные, передаются ли они третьим лицам или за пределы страны, а также как пользователь может реализовать право на доступ, исправление, удаление и возражение против обработки.
Однако проблема многих сайтов заключается не в том, что информация «не написана», а в том, что написанное «не соответствует фактическим действиям». Например, на странице указано, что данные используются «только для ответа на обращение», но в действительности данные из формы синхронизируются с CRM, платформой email-маркетинга и инструментами рекламного ретаргетинга. Или указано, что данные «не передаются третьим лицам», хотя фактически загружаются внешние чаты, карты, видео и аналитические скрипты. Такое несоответствие документации реальным действиям само по себе является фактором высокого риска.
Потому что ключевое значение имеет не сам факт появления окна, а поведение сайта по умолчанию. Если необязательные Cookie записываются на устройство до получения согласия пользователя, даже идеально оформленное окно не решает проблему.
При проверке рекомендуется разделять Cookie на две категории:
Также следует обратить внимание на три детали: хорошо ли видна кнопка отказа, можно ли выбирать категории разрешений и может ли пользователь изменить свой выбор позднее. Возможность только принять, но не отказаться, а также глубоко спрятанный вход для отказа — распространённые проблемы.

Обычно да. Формы напрямую собирают имя, адрес электронной почты, номер телефона, название компании и должность, а иногда также бюджет, закупочную потребность, регион и файлы вложений. Если по этим сведениям можно идентифицировать человека, они подпадают под действие требований GDPR.
Проверить соответствие формы требованиям можно по следующей логике:
Многие команды тщательно прорабатывают уведомления во внешней части сайта, но автоматическая пересылка писем из административной почты, длительное хранение экспортированных файлов форм и совместное использование тестовых аккаунтов остаются слабыми местами с точки зрения безопасности и соответствия требованиям.
Как минимум необходимо обеспечить, чтобы их можно было «увидеть, объяснить и отключить». К распространённым сторонним инструментам относятся системы аналитики, рекламные пиксели, онлайн-консультанты, подписки на рассылки, CDN, видеоплееры, плагины карт и компоненты социальных сетей. Они не обязательно являются незаконными; проблема в том, что многие компании вообще не знают, какие именно данные эти инструменты получают.
При самостоятельной проверке не следует ограничиваться анализом исходного кода страницы. Важнее проверить фактические сетевые запросы, момент загрузки скриптов и направление передачи данных. Специалистов по управлению безопасностью обычно интересует содержание следующей таблицы:
Распространённое заблуждение заключается в том, что если сервер сайта находится не в Европе, то GDPR якобы не имеет к компании особого отношения. На самом деле важно учитывать не только местонахождение сервера, но и то, предлагаются ли товары или услуги пользователям из ЕС либо отслеживается ли их поведение.
Например, поддержка языков ЕС, размещение рекламы в Европе, приём платежей в евро, сбор обращений европейских посетителей и ретаргетинг могут привести к применению GDPR. Для сайтов, привлекающих клиентов из других стран, чем более полной является маркетинговая цепочка, тем менее допустимо понимать соответствие требованиям как простое «добавление юридической страницы». Создание сайта, SEO, размещение рекламы и сбор аналитики изначально являются единой цепочкой, поэтому способы сбора данных во внешней части сайта, правила хранения данных во внутренней системе и права доступа сторонних интерфейсов лучше рассматривать вместе. Именно это часто необходимо синхронно прорабатывать до запуска комплексных проектов по созданию сайтов и маркетингу.
Сначала следует составить перечень, а затем сопоставить документацию с системой. Проверка только документации не выявит техническую реализацию, а проверка только системы не позволит полноценно оценить правовые основания обработки.
Практичный подход заключается в том, чтобы сначала составить перечень операций обработки данных: точка входа на странице, название поля, цель сбора, принимающая система, место хранения, срок хранения, способ удаления и соответствующие третьи лица. Затем этот перечень необходимо сопоставить с политикой конфиденциальности, настройками Cookie, конфигурацией прав доступа, журналами операций и соглашениями с поставщиками.
Некоторые команды тщательно разрабатывают внутренние документы, но в системе по-прежнему остаются неочищенные архивы старых форм, неотозванные аккаунты уволенных сотрудников и реальные данные клиентов, скопированные в тестовую среду. Для специалистов по безопасности такие вопросы зачастую важнее текста на странице и требуют первоочередного внимания.
Не все вопросы можно решить устными объяснениями, поэтому всё, что можно зафиксировать, следует фиксировать. К важным материалам относятся: записи о согласии на Cookie, история версий политики конфиденциальности, перечень сторонних инструментов, записи об операциях обработки данных, порядок обработки пользовательских запросов, распределение прав доступа к аккаунтам, а также записи об удалении или обезличивании данных.
Есть один практический момент: при редизайне сайта, подключении нового плагина или изменении полей формы соответствие требованиям часто незаметно нарушается. Если журнал изменений ведётся поверхностно, последующий поиск причин занимает много времени. Даже для маркетинговых страниц следует включать тексты о конфиденциальности, стратегию отслеживания событий и изменения интерфейсов в перечень проверок перед запуском.
Кстати, если внутренние учебные материалы или информационный контент затрагивают регламентированные процессы, необходимо также учитывать корректность их размещения и соответствие сценарию использования. Например, такой материал, как Исследование финансового управления капитальным строительством в больницах в условиях новой системы бухгалтерского учёта, сам по себе не обязательно создаёт высокий риск, если размещён только на информационной странице. Важно прежде всего проверить, содержит ли страница форму, скрипты отслеживания, сбор контактных данных при скачивании или переходы по внешним ссылкам.
Это зависит от уровня риска, но принцип однозначен: если речь идёт о продолжающемся незаконном сборе данных или обработке, уже запущенной без согласия, сначала нужно контролировать риск, а затем дополнять документацию.
В первую очередь необходимо обрабатывать следующие ситуации:
Такие проблемы нельзя решить только изменением политики конфиденциальности. Сначала следует приостановить соответствующие скрипты, отключить поля, ограничить доступ и прекратить синхронизацию, а затем дополнить информацию для пользователей, получить необходимые разрешения и восстановить учётные записи. Именно такой порядок является правильным.
Нет. Соответствие сайта GDPR — не разовое состояние, а результат постоянного обслуживания. Особенно это касается маркетинговых сайтов: они часто изменяются, используют множество плагинов и целевых страниц, а их рекламные цепочки бывают длинными. То, что соответствует требованиям сегодня, не обязательно будет соответствовать им в следующем месяце.
Надёжный подход — встроить проверки в повседневные процессы: проверять сайт перед запуском новой страницы, при подключении нового стороннего инструмента, при изменении полей формы и дополнительно проводить общий пересмотр раз в квартал. Для специалистов по управлению безопасностью наиболее ценна не способность наизусть цитировать положения, а наличие механизма, который выявляет отклонения, позволяет отслеживать ответственность и своевременно вносить исправления.
В итоге всё сводится к одной практичной формулировке: чтобы понять, соответствует ли сайт требованиям GDPR, нужно сначала спросить не «достаточно ли полно оформлена страница», а «откуда поступили эти персональные данные, куда они направляются, почему их можно обрабатывать и кто может это доказать». Если прояснить эти четыре вопроса, общее состояние соответствия сайта требованиям станет практически понятным.
Связанные статьи
Связанные продукты