Большинство компаний уже знают базовые требования законодательства о персональных данных.
На сайте опубликована политика. У пользователей берут согласия. В Роскомнадзор направлено уведомление. Назначен ответственный за обработку ПДн.
На первый взгляд кажется, что этого достаточно.
Но практика проверок 2026 года показывает другую картину: контролирующие органы все меньше смотрят на документы как на отдельный комплект и все больше пытаются понять, как персональные данные реально двигаются внутри компании.
В одной из недавних проверок крупного бизнеса прокуратура анализировала не только локальные акты компании, но и используемые IT-системы, содержание баз данных, договоры с подрядчиками, трансграничные передачи, сроки хранения, формы согласий и фактический доступ третьих лиц к данным.
И нарушения обнаружились именно там, где документы перестали совпадать с реальностью.
Одна из типичных зон риска — иностранные IT-системы.
Бизнес подключает CRM, HR-сервис, облачное хранилище, аналитику, систему технической поддержки или корпоративную платформу международной группы. Для сотрудников это просто очередной рабочий инструмент. Для специалиста по персональным данным первый вопрос будет другим: куда физически и юридически уходят данные?
В рассмотренной нами проверке фактическая передача персональных данных иностранной компании существовала значительно раньше, чем компания оформила необходимые регуляторные процедуры.
Это хороший пример того, почему нельзя начинать с документов. Сначала надо выяснить: какие данные → кому передаются → в какую страну → для какой цели → на каком основании.
И только после этого определять, какие уведомления и документы необходимы.
Особенно опасна ситуация, когда иностранный сервис подключил отдельный департамент, а юристы или ответственный за ПДн вообще о нем не знают.
Еще одна распространенная попытка упростить систему: «Давайте напишем, что все персональные данные хранятся пять лет». Или 10 лет. Или 75 лет.
Но универсального срока для всего массива персональных данных компании обычно не существует.
Резюме кандидата, кадровые документы сотрудника, запись телефонного разговора, заявка клиента, маркетинговое согласие, договор и данные пользователя в CRM возникают для разных целей и могут иметь разные сроки хранения.
В рассмотренной проверке прокуратура отдельно сопоставила сроки, закрепленные во внутренних документах компании, с нормативными требованиями к хранению отдельных категорий документов.
Для части сведений сроки оказались некорректными, для части — вообще не были определены.
Отсюда простой вопрос для внутреннего аудита: можете ли вы для каждого массива данных объяснить, почему храните его именно столько? Если ответ — «потому что так написано в нашей политике», этого недостаточно.
Наверное, самая опасная фраза в проектах по персональным данным: «Но у нас же есть согласие».
Сам факт наличия согласия еще не означает, что оно юридически работает.
В одном из эпизодов проверки документы существовали, но прокуратура обнаружила, что в формах отсутствовала часть необходимых сведений: не был полностью определен состав обрабатываемых данных, не были отражены отдельные участники обработки, возникли вопросы к срокам.
Есть и другая проблема: согласие может быть хорошим в день его разработки и устареть через несколько месяцев.
Например, первоначально процесс выглядел так: форма на сайте → компания. Через год получилось: форма → CRM → сервис рассылки → call-центр → аналитическая система → внешний подрядчик. Но согласие осталось прежним.
В итоге пользователь соглашается с одной моделью, а бизнес фактически работает по другой.
Поэтому при аудите нужно проверять не документ сам по себе, а весь маршрут: в какой точке собираются данные → что происходит после нажатия кнопки → в какие системы они попадают → кто получает доступ.
Очень типичная история. Маркетинг подключает сервис рассылок. HR покупает систему для сотрудников. Отдел продаж — CRM. Бухгалтерия передает данные внешнему подрядчику. Служба поддержки подключает call-центр.
С точки зрения бизнеса все эти решения логичны. Но одновременно появляется новая точка обработки персональных данных.
И основной договор на оказание услуг здесь не всегда решает вопрос.
При проверке контролирующий орган может выяснять: какие именно данные получил подрядчик; зачем он их получил; что с ними делает; где хранит; кто имеет доступ; что произойдет с базой после прекращения договора.
В анализируемом нами кейсе прокуратура последовательно изучала целый ряд внешних сервисов и сопоставляла договорные конструкции с фактическими массивами данных.
В отдельных случаях необходимые условия об обработке появились уже после того, как подрядчик начал работать с персональными данными.
Поэтому полезное правило для бизнеса очень простое: доступ к ПДн — последняя стадия подключения подрядчика, а не первая. До этого нужно определить его роль и проверить договорную модель.
На мой взгляд, это самая серьезная проблема.
У крупного бизнеса могут быть прекрасно написанные документы по ПДн. Но задайте руководителям простой вопрос: где находятся персональные данные работников?
Ответ может оказаться неожиданно длинным: кадровая система, 1С, корпоративная почта, CRM, облачный диск, медицинский сервис, система командировок, Excel у HR, база бухгалтерского подрядчика, система пропусков, иностранный корпоративный сервис.
Причем часть этих систем могла вообще не попасть в первоначальный аудит.
В реальной прокурорской проверке контролирующий орган отдельно анализировал, какие именно сведения находились внутри корпоративных и облачных систем, а затем сопоставлял это с документами компании.
И обнаружил, что фактический IT-ландшафт шире того, который был описан внутри системы ПДн.
Вот здесь и находится главное отличие современного аудита персональных данных от проверки документов. Сегодня недостаточно открыть папку и проверить: политика — есть; согласия — есть; приказ — есть. Нужно уметь нарисовать карту движения данных.
Условно логику контролирующего органа можно представить так:
откуда получили данные → зачем → какие именно → на каком основании → куда записали → кому передали → сколько храним → как удаляем.
И каждый следующий ответ должен совпадать с предыдущим.
Например, если политика говорит, что данные не передаются третьим лицам, а в CRM есть интеграция с внешним call-центром, возникает вопрос. Если согласие предусматривает один перечень данных, а в базе собирается другой — вопрос. Если во внутренних документах указаны одни IT-системы, а сотрудники используют еще пять сервисов — снова вопрос.
Именно поэтому нарушения часто обнаруживаются не внутри одного документа, а между документами и процессами.
Обычно проблема не в небрежности. Компания просто развивается быстрее документов.
Сначала появляется новый продукт. Затем — новая CRM. Потом подключается аналитика. Маркетинг берет SaaS. Компания открывает иностранную структуру. HR меняет систему.
При этом документы по ПДн могут обновляться раз в несколько лет.
В результате через некоторое время существует две реальности: юридическая — в политике и локальных актах; фактическая — в IT-системах и бизнес-процессах.
И проверяющий орган начинает именно с их сопоставления.
Начинать я бы советовала не с переписывания политики. Сначала нужно восстановить фактическую картину.
Шаг 1. Собрать все категории субъектов. Сотрудники, кандидаты, клиенты, пользователи, представители контрагентов, посетители сайта.
Шаг 2. Найти все места хранения данных. Проверить CRM, ERP, 1С, HR-системы, облачные диски, почту, сервисы рассылок, call-центр, системы аналитики, SaaS, таблицы и базы подрядчиков.
Шаг 3. Нарисовать движение данных. По каждому процессу: получили → записали → передали → использовали → сохранили → удалили.
Шаг 4. Проверить подрядчиков. Нужно понять не просто, подписан ли договор, а что именно контрагент делает с ПДн.
Шаг 5. Проверить сроки хранения. И отдельно — может ли используемая система технически удалить данные тогда, когда вы обещаете это сделать.
Шаг 6. И только после этого обновлять документы. Политика, согласия, положения и договоры должны описывать существующую архитектуру, а не создавать параллельную юридическую реальность.
Мы часто видим подход: «В прошлом году нам уже сделали документы по 152-ФЗ».
Но за год компания могла подключить три новых сервиса, изменить регистрацию пользователей, сменить CRM и передать часть процессов подрядчикам.
Формально документы остаются. Фактически они уже описывают другую компанию.
Поэтому работа с персональными данными должна быть не разовой подготовкой документов, а change management.
Подключили новый сервис — проверили ПДн. Появился подрядчик — проверили передачу. Изменили форму регистрации — проверили основания и согласия. Запустили новую функцию — обновили карту данных.
Именно такой подход гораздо лучше готовит компанию к реальной проверке, чем толстая папка локальных актов.
Как правильно выстроить работу с ПДн- мы разбирали на одном из вебинаров
.
Если сегодня попросить вашу компанию за час показать: какие ПДн вы собираете, где они находятся, зачем нужны, кто к ним имеет доступ, каким подрядчикам они передаются и когда удаляются — сможете ли вы это сделать?
Если нет, то именно с этого нужно начать аудит.