Самые распространенные ошибки в Реестре обработок персональных данных и как их исправить

Из-за чего у компаний чаще всего возникают проблемы с Реестром?

Если Реестр — это так полезно, почему же его заполнение зачастую превращается в полосу препятствий? Мы выделяем три основные проблемы:

1) Статичный Реестр. 
Бизнес — это живой организм: вы запускаете новый A/B тест на сайте, меняете CRM-систему или нанимаете подрядчика из другой страны,. Если Реестр был составлен год назад и с тех пор не открывался, он превращается в тыкву. RoPA должен отражать фактическое положение дел, а не то, как это было год назад.

2) Шаблонное мышление. 
Часто компании просто скачивают шаблон RoPA из интернета и пытаются заполнить его, не учитывая свои реальные процессы. В итоге в Реестре есть «маркетинг», но нет ни слова о Google Tag Manager или пикселях соцсетей, которые вовсю собирают данные на сайте.

3) Отсутствие взаимодействия между отделами. 
Заполнение Реестра не та задача, которую ответственный по защите персональных данных может выполнить в одиночку. Он может не знать (и, скорее всего, не знает), какие именно cookie ставит IT-департамент и какие базы данных закупает отдел продаж. Без кросс-функционального взаимодействия Реестр всегда будет неполным, как пазл, в котором не хватает половины деталей.

В конечном счете, главная проблема в том, что к RoPA относятся как к бюрократической повинности, а не как к инструменту управления рисками. А ведь именно он помогает быстро ответить на запрос клиента об удалении данных или подготовить документы для трансграничной передачи.

В следующем блоке мы разберем, какие именно ошибки чаще всеговсплывают как результат этих проблем, и как их исправить.

Типичные ошибки в Реестре

Этот блок — самая важная часть нашего исследования. Мы в Data Privacy Office реализовали более 230 проектов для компаний самых разных отраслей: от финтеха и геймдева до медицины и производства счётчиков радиации. И каждый раз, когда мы заходим в новый проект, мы начинаем с инвентаризации процессов и составления или аудита Реестра (RoPA).

На основе наших консалтинговых аудитов мы составили рейтинг частотности ошибок — от критических системных сбоев до досадных организационных промахов.

🔴 Категория 1: Критические системные ошибки (Встречаемость: ★★★★☆ — ★★★★★)

Эти ошибки — «красная зона». Если регулятор обнаружит их, он сделает вывод, что принцип подотчётности (Accountability), закреплённый в ст. 5(2) GDPR, в компании не соблюдается.

1. Неполный список целей обработки — абсолютный лидер (★★★★★)

Это самая частая ошибка, которую мы встречаем. Компании фиксируют в Реестре только то, что лежит на поверхности: HR-процессы (приём на работу, зарплата) и основные продажи. Всё, что происходит «под капотом», часто остаётся в тени.

Что часто выпадает из поля зрения?

🔹 Маркетинговая аналитика
Установлен Google Tag Manager, работают пиксели ретаргетинга, проводятся A/B тесты.

🔹 Данные кандидатов
Обработка резюме до того, как человек стал сотрудником, — это отдельный процесс с другими сроками и основаниями, который часто забывают.

🔹 IT-безопасность
Логирование доступа к системам, сбор IP-адресов для защиты от DDoS-атак — это тоже обработка персональных данных, которую нужно легализовать.

🔹 B2B-взаимодействие
Обработка контактных данных представителей партнёров и клиентов часто игнорируется.

Почему это происходит?

Реестр заполняется юристом без опроса IT и маркетинга.

Как мы это исправляем?

Каждый проект должен начинается с детального интервью со всеми владельцами процессов. как мы проводим кросс-функциональный data mapping. Мы опрашиваем всех владельцев процессов, узнаем достоверную информацию о том, как, когда и зачем обрабатываются данные, и сверяем Реестр с публичной Политикой конфиденциальности и Cookie Notice.

💡 Совет

Спрашивайте владельцев процессов не «какие данные вы обрабатываете?», а «какие инструменты вы используете в работе?». Если маркетолог скажет «мы используем Salesforce и Google Analytics», вы автоматически получите список информационных систем и категорий данных (email, IP-адреса, cookie ID) для внесения в Реестр.

2. Отсутствие Processor RoPA (★★★★☆)

Многие компании в сфере SaaS или B2B-услуг забывают, что GDPR накладывает обязанности и на контролёров, и на процессоров. Согласно статье 30 GDPR, процессоры обязаны вести свой отдельный Реестр. Разобраться, кто есть кто, поможет наша статья о контролёрах и процессорах.

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

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

Как это исправить?

Если вы обрабатываете данные от имени клиентов, создайте Processor RoPA. Хороший лайфхак — взять строки из основного Реестра, которые описывают работу с клиентскими данными, и переформулировать их с позиции «мы делаем это по поручению».

3. Сроки хранения (★★★★☆)

Это самая «удобная» и самая опасная ловушка. В наших аудитах мы постоянно видим формулировки Indefinite (бессрочно) или As needed (по мере необходимости).

Однако с позиции европейских регуляторов такой подход недопустим. Данные должны удаляться по достижении целей.

Какие еще проблемы со сроками часто встречаются с Реестрами?

🔹 Отсутствие конкретного периода (например, «7 лет» — хорошо, «долго» — плохо).

🔹 Отсутствие триггера: написано «храним 3 года», но неясно, с какого момента — с даты сбора или с даты расторжения договора?

Как это исправить?

Для каждой категории данных должен быть указан срок и событие-триггер. Например: «30 дней с момента удаления аккаунта» или «6 лет с момента увольнения сотрудника». Если срок пока не определён, честно пишите «TBC» (To Be Confirmed) и назначайте ответственного за уточнение.

Если вы храните данные для архива или статистики, это допустимо по ст. 89(1) GDPR, но это также должно быть четко зафиксировано в Реестре.

4. Трансграничные передачи (★★★★☆)

Здесь мы видим комбо из двух ошибок: либо страны не названы вообще, либо отсутствуют гарантии защиты.

Что мы чаще всего видим в Реестрах?

🔹 Отсутствие конткретных стран
Вместо конкретных стран пишут «EU/Azure», «USA and others» или «Глобально». Регуляторы требуют называть страны поимённо: США, Индия, Сингапур.

🔹 Отсутствие гарантий
Столбец с механизмами защиты (SCCs, BCR, решение об адекватности) пуст.

🔹 Использование устаревших фреймворков
До сих пор в некоторых Реестрах мы встречаем ссылки на Safe Harbor — фреймворк, который перестал действовать ещё в 2015 году!

Как исправить?

Проверить договоры с вендорами на наличие DPA (Data Processing Agreement) и актуальных SCCs (Standard Contractual Clauses). С 2023 года для США также актуален EU-US Data Privacy Framework. Что изменилось для передачи данных в США с 2023 года — читайте в нашем обзоре DPF.

💡 Совет

Если вы передаете за рубеж только часть данных (например, 5 категорий из 10), укажите это в Реестре — это поможет не перегружать договоры с контрагентами лишними списками.

🟡 Категория 2: Регулярные ошибки (Встречаемость: ★★★☆☆)

Эти ошибки делают ваш комплаенс «бумажным». На проверке они покажут, что Реестр — это формальность, которая не соответствует реальности.

1. Отсутствие информации о веб-сайте (★★★☆☆)

Сайт — один из главных источников сбора данных, но в Реестре он часто отсутствует.

Как проверить себя?

Откройте DevTools в браузере (F12) и посмотрите вкладку «Application» -> «Cookies». Если вы видите там такие обозначения, как _ga, _ym_uid или __cf_bm, значит, ваш сайт собирает IP-адреса и идентификаторы устройств.

Что с этим делать?

Каждому виду веб-аналитики и трекинга нужна отдельная строка в Реестре с указанием цели, правового основания (согласие через куки-баннер) и категорий данных. Подробнее о рисках Google Analytics для GDPR — в отдельном разборе.

2. Формальное описание технических мер (TOMs) (★★★☆☆)

Зачастую графа про меры безопасности в Реестре либо пуста, либо содержит общие фразы типа «Industry standard» или «ISO 27001».

Однако ссылка на сертификат не объясняет, как защищена конкретная база данных. Регуляторы хотят видеть конкретные контроли.

Как это исправить?

Вместо общих фраз пишите конкретику: шифрование данных «в покое» (at rest) и при передаче, использование многофакторной аутентификации (MFA), ролевая модель доступа (RBAC), регулярные бэкапы.

3. Слишком общие категории данных (★★★☆☆)

Использование расплывчатых терминов типа User Data или Personal Information — плохая практика.

Как делать правильно?

Детализируйте до конкретных типов: «адреса электронной почты», «история транзакций», «логи посещений». Сверяйтесь с тем, что реально хранится в ваших таблицах базы данных. Включайте всё: от ФИО и даты рождения до данных о доходах и медицинских сведений, если они обрабатываются.

Дробите процессы до атомарного уровня. Например, «Организация маркетинговой рассылки» и «Анализ поведения пользователей на сайте для улучшения SEO» — это две разные строки с разными основаниями и сроками.

🟢 Категория 3: Организационные ошибки и неточности в документации (Встречаемость: ★★☆☆☆)

Эти ошибки реже приводят к огромным штрафам, но они — верный признак того, что за Реестром никто не следит.

1. Статичность реестра (★★☆☆☆)

Реестр создан один раз и с тех пор не менялся. Нет даты обновления, нет версий, нет плана пересмотров.

Как это исправить?

Реестр должен развиваться вместе с бизнесом. Запустили новый продукт? Появилась версия 1.1. Добавьте в шапку поля «Дата последнего обновления» и «Ответственное лицо». Введите цикл пересмотра: минимум раз в год, а лучше — раз в квартал или при каждом изменении процессов.

2. Правовое основание не привязано к целям (★★☆☆☆)

Часто в Реестре просто перечисляют все шесть оснований из ст. 6 GDPR (согласие, договор, законный интерес и т.д.) через запятую для всех строк.

Проблема в том, что субъект данных не может реализовать своё право на возражение, если не понимает, на каком основании вы используете его данные.

Как это исправить?

Каждой цели — своё основание. Например: для зарплаты — «Контракт» или «Требование закона»; для маркетинговой рассылки — «Согласие» или «Легитимный интерес» (с обязательным проведением LIA). Выбор правового основания для рассылок — тема отдельного разбора с примерами.

3. Неразбериха с представителями (EU Representative) (★★☆☆☆)

Для компаний вне ЕС, работающих на европейском рынке, наличие представителя в Союзе — обязательное требование (Art. 27 GDPR).

Иногда при проверке Реестра мы видим, что поля пустые или в нем указан адрес головного офиса где-нибудь в Сингапуре.

Как делать правильно?

Представитель должен быть физически зарегистрирован в одной из стран ЕС. Внесите его контакты (адрес, email) в Реестр сразу после подписания договора. Помните, что после Брекзита Великобритания и ЕС — это разные юрисдикции, и вам могут понадобиться два разных представителя.