Компания теряет контроль над данными в собственных системах

На странице висит ссылка на политику, у формы стоит чекбокс, а дальше никто точно не знает, что происходит. Заявка с сайта попадает в CRM, копия уходит в почту, номер передаётся в коллтрекинг; менеджер выгружает клиентов в таблицу, бухгалтерия работает в учётной системе, а файл оказывается в облаке подрядчика и резервной копии. Через год компания не может ответить, какие данные собирает и получает, зачем они нужны, кто их видит, где они хранятся и как их удалить.

Проблему нельзя решить скачанным шаблоном политики или одним аудитом сайта. Документы и технические проверки важны, но должны описывать реальный маршрут данных во всех рабочих системах. Если маршрут неизвестен, юрист проверяет текст, техническая команда — формы, продажи — CRM, а бухгалтерия — свою систему: и все могут говорить о разных данных.

Это информационный материал о том, как собрать факты для проверки. Он не определяет применимость норм к конкретной организации, не заменяет юридическое заключение и не даёт вывода о законности конкретного сервиса, согласия, договора или трансграничного потока.

Работа с данными компании, в том числе персональными, начинается с карты фактов: от источника до получателя, цели, срока хранения и удаления.

Пройдите путь каждого типа данных и не ограничивайтесь главным сайтом. Начать можно с сайта, но в карту должны попасть также звонки и почта, CRM и ERP, электронный документооборот, таблицы, файловые хранилища, мобильные рабочие устройства, тестовые среды и внешние сервисы.

Точки сбора — формы заявки, регистрации и подписки, личный кабинет, чат, обратный звонок, загрузка файлов, cookies и аналитические идентификаторы, телефонные обращения, договоры и документы, данные сотрудников и клиентов в операционных системах. Затем — получатели: CMS, CRM, почта, телефония, система рассылок, учётная система, облачное хранилище, подрядчик, рекламная или аналитическая платформа. После этого — рабочие копии: журналы, резервные копии, тестовые среды, выгрузки и таблицы менеджеров.

Для каждой строки в реестре ответьте:

Не собирайте поля «на всякий случай». Если номер паспорта, дата рождения или лишняя информация о компании не меняют следующий шаг, их наличие увеличивает риск, объём защиты и цену ошибки.

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

Основание обработки, содержание информирования, состав согласий, работа с cookies, уведомления и локализация зависят от целей, способов сбора, используемых систем и роли участников. Согласие — одно из возможных оснований обработки, но не единственное: его выбирают для каждой цели по статье 6. Если оператор опирается на согласие, он должен уметь подтвердить его получение; с 1 сентября 2025 года такое согласие оформляют отдельно от иных подтверждаемых или подписываемых пользователем сведений и документов.

На дату проверки Закон №152-ФЗ действует с изменениями, внесёнными Федеральным законом от 26.07.2026 №265-ФЗ. Эта поправка относится к статье 12 о трансграничной передаче; она не изменила проверяемые здесь нормы о целях, основаниях, политике и защите. Для любых выводов о зарубежных сервисах, облаках или аналитике статью 12 нужно проверять отдельно по конкретному потоку — общий редакционный вывод здесь недопустим.

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

Сайт редко работает без внешних исполнителей: CRM, облако, аналитика, коллтрекинг, почтовый сервис, агентство, разработчик. Закон предусматривает, что поручение обработки другому лицу должно определять обрабатываемые данные, операции, цели, а также обязанности по конфиденциальности и безопасности.

Это не повод составлять договоры самостоятельно по статье. Это повод не ограничиваться фразой «данные у подрядчика». Запросите, какие данные получает сервис, зачем, где у него доступ, кто отвечает за настройку, какие условия зафиксированы в договоре и что происходит при смене подрядчика.

«Храним бессрочно, вдруг пригодится» — плохое правило и для права, и для операционной работы. Статья 5 требует конкретных, заранее определённых и законных целей, соответствия состава и объёма данных этим целям и хранения не дольше, чем этого требуют цели, если иной срок не установлен законом или применимым договором. По достижении цели или утрате необходимости данные уничтожают либо обезличивают, если закон не предусматривает иное.

Срок и действие зависят от основания прекращения. Для достижения цели, отзыва согласия, требования субъекта и неправомерной обработки закон устанавливает разные правила и исключения. Не обещайте «удаление за 30 дней» как общий ответ: конкретный сценарий нужно сверять с действующей статьёй 21 и специальными нормами. Удаление записи из CRM не доказывает уничтожение в почте, логах, тестовых средах и резервных копиях.

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

Заранее опишите путь запроса пользователя и путь инцидента: кто принимает обращение, кто ищет данные по реестру, кто согласует изменение, кто фиксирует исполнение. Без карты это превращается в поиск по чатам и папкам.

SSL защищает передачу, но не отвечает на вопрос, зачем данные собрали, куда их передали и прекратили ли обработку.

При сборе персональных данных граждан России, в том числе через интернет, часть 5 статьи 18 запрещает выполнять перечисленные в ней операции — запись, систематизацию, накопление, хранение, уточнение и извлечение — с использованием баз данных за пределами России, кроме прямо указанных законом случаев. Это правило локализации нельзя подменять фразой «всё должно быть только в России» и нельзя трактовать как готовый вывод о каждом сервисе.

Последующая трансграничная передача регулируется отдельно статьёй 12, которую изменили 26 июля 2026 года. Для конкретного решения нужно установить роль сервиса, страну и расположение баз, какие данные и операции выполняются, что происходит до и после передачи, какие исключения и договорные условия применимы. Редакционный материал не может дать универсальное разрешение или запрет для облака, аналитики, CDN или CRM.

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

По общему правилу оператор до начала обработки уведомляет Роскомнадзор о намерении обрабатывать персональные данные; исключения перечислены законом и зависят от ситуации, а не от размера бизнеса. Здесь нельзя обещать читателю, что его случай точно относится к исключению. Актуальный способ подачи и формы проверяют на портале Роскомнадзора.

Обязанность уведомить регулятора в течение 24 часов и представить результаты внутреннего расследования в течение 72 часов относится к установленному факту неправомерной или случайной передачи, предоставления, распространения либо доступа к персональным данным, повлёкшему нарушение прав субъектов. Не каждая недоступность сайта, неудачный вход или техническая ошибка автоматически являются таким инцидентом.

Карта данных устаревает при каждом новом виджете, форме, экспортной таблице, рекламной метке, интеграции, подрядчике или рабочем сервисе. Поэтому у неё нужен процесс обновления. Маркетинг сообщает о новом канале и форме, разработка — о передаче и хранилище, продажи — о новой обработке в CRM, бухгалтерия и операционные команды — об учётных и документных системах, ИБ — об ограничениях доступа, юрист — о правовой оценке. Один человек не обязан делать всё, но один владелец должен знать, что карта пересмотрена.

Включите проверку data flow в обычную приёмку изменения. Перед релизом задайте короткие вопросы: появились ли новые поля, cookies, получатели, цели, доступы, сроки хранения или внешние передачи? Если да, изменение не закрывается только скриншотом страницы. Ему нужны обновлённая запись в реестре и, где необходимо, правовая и техническая проверка.

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

Заранее определите, какая запись покажет исполнение: задача в системе, журнал удаления, подтверждение обработчика, запись об ограничении доступа, документ по правилам Роскомнадзора. Формат зависит от способа обработки и уничтожения; приказ Роскомнадзора №179 устанавливает требования к подтверждению уничтожения. Поэтому устная отметка сотрудника и удаление одной карточки не являются достаточной моделью для всего контура.

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

Передайте им не общий вопрос «соответствует ли сайт 152-ФЗ», а рабочий пакет:

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

Выберите один маршрут с наибольшим риском: заявка с файлом, регистрация в кабинете, передача заказа партнёру или выгрузка клиентской базы для работы. Пройдите его как пользователь или сотрудник, затем как менеджер и администратор. Зафиксируйте каждый экран, поле, запрос, получателя, уведомление, запись в CRM или учётной системе, журнал и копию. После этого удалите тестовую запись по согласованной процедуре и отметьте, где подтверждение невозможно получить.

Один такой проход не доказывает соответствие всего сайта. Но он даёт команде фактический материал, с которого можно начать инвентаризацию, а не спорить о шаблонах и предположениях.

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

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

Этот первый проход не подтверждает законность обработки и не заменяет отдельную правовую или ИБ-оценку конкретной организации, её сервисов и потоков данных. Технический путь между формой и системами обычно строится через API-обмен; защитные контроли этого маршрута разобраны в статье о безопасности сайта.