CRM и лид-формы: как настроить поля, источники и интеграции без лишних передач персональных данных

Полное руководство для бизнеса в условиях ужесточённого 152-ФЗ

Зачем это важно прямо сейчас

Каждый день тысячи российских компаний собирают персональные данные через сайты, рекламные кабинеты ВКонтакте, Telegram-боты, колл-центры и CRM-системы. Кажется, всё просто: клиент оставил заявку, менеджер её обработал. Но между этими двумя действиями разворачивается целый ИТ-пейзаж: форма на сайте → вебхук → CRM → интеграция с мессенджером → аналитический сервис → email-рассылка. На каждом этапе данные куда-то уходят, где-то копируются, в каком-то поле оседают навсегда.

До 2025 года бизнес мог относиться к этому вопросу достаточно спокойно: максимальный штраф за утечку составлял 60 000 рублей [6]. Сегодня ситуация принципиально иная. Федеральный закон №420-ФЗ от 30 ноября 2024 года ввёл оборотные штрафы, уголовную ответственность для должностных лиц и совершенно другую цену ошибки [2]. Параллельно выросла интенсивность проверок: эксперты прогнозируют массовые плановые проверки Роскомнадзора именно в 2026 году [7].

Эта статья — практическое руководство для маркетологов, product-менеджеров, IT-специалистов и руководителей бизнеса. Мы разберём, как устроен жизненный цикл персональных данных в типичной CRM-экосистеме, где возникают риски и что конкретно нужно изменить в настройках форм, полях и интеграциях, чтобы работать в правовом поле.

Часть 1. Правовой ландшафт: что изменилось и почему это важно

1.1. Ключевые изменения 2024–2025 годов

Российское законодательство о персональных данных переживает наиболее активный период изменений за всё время существования 152-ФЗ. Перечислим ключевые точки, напрямую влияющие на работу с CRM.

Федеральный закон №420-ФЗ (вступил в силу 30 мая 2025 года) кардинально пересмотрел статью 13.11 КоАП. Теперь базовый штраф для юридических лиц составляет от 150 до 300 тысяч рублей (ранее — 60–100 тысяч). За повторное нарушение — оборотный штраф: от 1 до 3% совокупной годовой выручки, но не менее 25 млн и не более 500 млн рублей [2]. Параллельный закон №421-ФЗ ввёл уголовную ответственность по новой статье 272.1 УК РФ — вплоть до 10 лет лишения свободы за особо тяжкие случаи [8].

Ещё одно важное изменение: с 1 сентября 2025 года согласие на обработку ПДн должно оформляться как отдельный документ — его нельзя «вшивать» в общее пользовательское соглашение или политику конфиденциальности [5]. Для большинства форм это означает необходимость их переработки.

Наконец, с того же 1 сентября 2025 года вступила в силу статья 13.1 152-ФЗ, введённая законом №233-ФЗ: она устанавливает особые правила обработки обезличенных ПДн. Данные, приведённые в обезличенную форму по установленным методикам, могут обрабатываться без согласия субъекта — что открывает легальные возможности для аналитики при правильной технической реализации [9].

1.2. Кто является оператором: главное заблуждение бизнеса

Распространённое заблуждение: «Мы просто используем чужую CRM, значит, ответственность на её разработчике». Это не так.

Согласно ч. 2 ст. 3 152-ФЗ, оператором персональных данных является тот, кто определяет цели и способы обработки. Разработчик облачной CRM предоставляет инструмент — он не знает, чьи данные вы туда вносите и зачем. Именно компания-пользователь CRM является оператором и несёт все юридические обязательства [10]. Единственный вариант разделить ответственность — заключить с провайдером CRM письменное соглашение о поручении обработки ПДн в соответствии с ч. 3 ст. 6 152-ФЗ [10].

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

1.3. Принцип минимизации как операционный принцип

Статья 5 152-ФЗ закрепляет принцип, который кажется очевидным, но массово нарушается на практике: «Содержание и объём обрабатываемых персональных данных должны соответствовать заявленным целям обработки» [3]. Проще говоря — не собирайте то, что вам не нужно.

Роскомнадзор фиксирует устойчивую тенденцию к избыточному сбору данных, особенно в маркетинговых отделах [11]. Типичная ситуация: форма запрашивает дату рождения и адрес регистрации, хотя на самом деле нужны только имя и телефон для перезвона. Каждое лишнее поле — это дополнительный объём ответственности, дополнительная поверхность для утечки и потенциальный повод для штрафа.

Часть 2. Анатомия CRM-формы: что и зачем спрашивать

2.1. Типология полей: необходимые, полезные и лишние

При проектировании лид-формы или CRM-карточки полезно разделить все поля на три группы.

Необходимые поля — без них невозможно достичь заявленной цели обработки. Например, для записи на консультацию это имя, телефон или email. Без них вы не сможете связаться с клиентом — значит, сбор обоснован.

Полезные поля — информация, которая улучшает качество обработки, но не является обязательной. Источник перехода (UTM-метка), тип запроса, предпочтительное время звонка. Такие поля можно включать, но они должны быть необязательными для заполнения, а в согласии нужно явно указать цель их сбора.

Лишние поля — данные, которые «было бы интересно знать», но которые не используются ни в каком процессе. Паспортные данные для подписки на рассылку, дата рождения для первичного обращения, место работы для записи на ремонт. Каждое такое поле — прямое нарушение принципа минимизации [3] и риск крупного штрафа.

Практическое правило: для каждого поля в форме или CRM-карточке задайте вопрос «Какой конкретный бизнес-процесс использует эти данные?». Если ответа нет — поле нужно убрать.

2.2. Настройка обязательных и необязательных полей

В большинстве современных CRM-систем — Битрикс24, amoCRM, МегаПлан — есть возможность гибко управлять обязательностью полей. Это важно не только с точки зрения UX, но и с точки зрения 152-ФЗ.

В Битрикс24, например, поля CRM-формы можно настраивать индивидуально: делать обязательными только то, что действительно нужно, скрывать поля при определённых условиях (условная логика показа), задавать правила дедупликации [12]. Это позволяет создать минималистичную форму для первичного контакта и более детальную — для последующих этапов воронки, когда отношения с клиентом уже установлены.

Отдельно стоит вопрос о полях, которые не отображаются пользователю, но заполняются автоматически. Скрытые поля с UTM-метками, источником перехода, IP-адресом — это тоже персональные данные в широком смысле, особенно если они привязаны к конкретному физическому лицу. Они должны быть отражены в согласии и политике конфиденциальности.

2.3. Настройка согласия на обработку ПДн в форме

С 1 сентября 2025 года согласие оформляется строго как отдельный документ. На практике это означает несколько требований к форме [5]:

Чекбокс с согласием должен быть неотмеченным по умолчанию — пользователь должен поставить галочку самостоятельно. Вариант «нажимая кнопку "Отправить", вы соглашаетесь…» формально допустим, но сопряжён с риском: Роскомнадзор может счесть такую форму согласия недостаточно явной.

Текст согласия должен содержать: наименование оператора с реквизитами, перечень конкретных полей, которые собираются, цели обработки каждой категории данных, сроки хранения, перечень третьих лиц, которым передаются данные (включая CRM-провайдера, если он является обработчиком), а также контактные данные для отзыва согласия [13].

В Битрикс24 есть встроенный конструктор соглашений: поля формы автоматически подтягиваются в текст согласия, указываются третьи лица, сроки хранения [14]. Важный нюанс: по умолчанию все поля формы, включая поле «Комментарий», попадают в перечень ПДн в согласии — это нужно проверять и при необходимости корректировать.

Часть 3. Источники лидов: карта рисков

3.1. Сайт и посадочные страницы

Сайт — первичная точка сбора данных для большинства бизнесов. Здесь возникает сразу несколько рисков.

Первый — технический: сайт должен работать по HTTPS, иначе данные из форм передаются в открытом виде [15]. Второй — аналитический: счётчики веб-аналитики (в первую очередь это касается Google Analytics) передают пользовательские данные на серверы иностранных компаний, что трактуется как трансграничная передача ПДн. Для работы с такими сервисами необходимо уведомление Роскомнадзора [16]. Безопасной альтернативой остаются Яндекс.Метрика и российские аналоги.

Третий риск — формы обратной связи, встроенные в сторонние конструкторы (в том числе иностранные). Если данные из такой формы уходят на зарубежные серверы до попадания в CRM — это нарушение требований о локализации. Рекомендуется использовать Яндекс.Формы, Tilda Forms или нативные формы российских CRM.

3.2. Рекламные кабинеты: ВКонтакте и другие

Лид-формы в ВКонтакте позволяют собирать данные прямо в социальной сети и передавать их в CRM через API-интеграцию или вебхуки. С точки зрения 152-ФЗ важно следующее.

Во-первых, пользователь ВКонтакте уже дал согласие на обработку своих данных самой социальной сети — но не вашей компании. Когда данные передаются в вашу CRM, именно вы становитесь оператором и должны обеспечить наличие оснований для обработки. Лид-форма ВКонтакте включает встроенный чекбокс согласия — убедитесь, что его текст корректно указывает вашу организацию как оператора.

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

3.3. Мессенджеры: серая зона

Использование Telegram и WhatsApp для коммуникации с клиентами — отдельная юридическая история. Оба сервиса являются иностранными и хранят данные переписки на зарубежных серверах. Роскомнадзор формально трактует это как трансграничную передачу данных [16].

На практике массового правоприменения в отношении использования мессенджеров для бизнес-коммуникаций пока нет — регулятор сам не выработал единой позиции [16]. Однако ситуация может измениться, и бизнесу стоит заранее оформить уведомление в РКН об использовании этих сервисов.

Важный момент: когда сообщения из Telegram или WhatsApp попадают в CRM через интеграцию, они становятся частью вашей базы данных. С этого момента на них распространяются все требования 152-ФЗ, включая требования о локализации — данные физически хранятся уже в вашей CRM, которая должна быть на российских серверах [4].

3.4. Офлайн-источники: визитки, звонки, выставки

Данные, полученные офлайн — с визиток на выставке, из заявок по телефону, из бумажных анкет — часто «теряются» в воронке документирования. Бизнес вносит их в CRM, не задумываясь об основаниях. Между тем, даже для таких данных нужно письменное или электронное согласие, если цель обработки выходит за рамки исполнения договора.

При внесении данных из офлайн-источников в CRM рекомендуется фиксировать в карточке лида: источник получения данных и дату. Это поможет при возможных проверках доказать законность обработки.

Часть 4. Интеграции: где данные уходят без вашего ведома

4.1. Типичная экосистема интеграций и её риски

Современная CRM редко работает изолированно. Типичная связка для среднего бизнеса: CRM ↔ IP-телефония ↔ сервис email-рассылки ↔ аналитическая платформа ↔ чат-боты ↔ коллтрекинг ↔ сервис SMS-уведомлений.

Каждая такая интеграция — это потенциальная передача ПДн третьему лицу. По закону для этого необходимо либо согласие субъекта данных (с явным указанием получателей), либо заключённое соглашение о поручении обработки по ч. 3 ст. 6 152-ФЗ [10]. На практике большинство компаний не имеют ни того, ни другого для большинства своих интеграций.

Критически важная проблема — это «теневые данные» (shadow data): ситуация, когда компания не знает точного перечня мест, куда попадают данные из CRM [17]. Маркетолог подключил «временную интеграцию на тест» — она осталась активной на год. Разработчик добавил новое поле в карточку сделки — оно попало в выгрузку к подрядчику. DevOps-команда скопировала базу в тестовое окружение — там реальные ПДн [17]. По данным аналитиков, именно эти неконтролируемые копии и интеграции становятся основным источником утечек [17].

4.2. Как правильно оформить передачу данных подрядчику

Если вы передаёте обработку ПДн внешнему подрядчику (call-центру, агентству рассылок, интегратору), требуется заключить договор поручения обработки. Он должен содержать: перечень передаваемых данных и категорий субъектов, цели и объём обработки, обязанность подрядчика соблюдать конфиденциальность и обеспечивать безопасность, условия о том, что данные хранятся на серверах в РФ [15].

Простая API-интеграция без такого договора — это передача данных без правового основания. Роскомнадзор при проверке рассмотрит её как нарушение.

4.3. Иностранные сервисы: что можно, что нельзя

Требование о локализации данных (ч. 5 ст. 18 152-ФЗ) существует давно, но именно сейчас оно начинает применяться всерьёз [4]. Суть: первичная запись, систематизация, накопление и хранение ПДн граждан РФ должны осуществляться на серверах, физически расположенных в России.

Это означает, что следующие сценарии создают риск: Google Forms как основной инструмент сбора заявок (данные хранятся на серверах Google за рубежом), Notion или Airtable как база данных клиентов, использование иностранных ESP (Mailchimp, SendGrid) без российского буфера [4].

Безопасные альтернативы, которые уже используют российские компании: Яндекс.Формы вместо Google Forms, Яндекс.Метрика вместо Google Analytics, DashaMail, UniSender или Sendsay вместо иностранных ESP, отечественные CRM на собственном хостинге или российских облаках.

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

Часть 5. Практическая настройка: пошаговые рекомендации

5.1. Аудит существующих форм и полей

Прежде чем что-то менять, нужно понять текущее состояние. Рекомендуемый алгоритм:

Инвентаризация форм. Составьте полный список всех форм сбора данных: формы на сайте, лид-формы в рекламных кабинетах, боты в мессенджерах, офлайн-анкеты, телефонные скрипты, где оператор вносит данные вручную. Для каждой формы зафиксируйте: URL/расположение, перечень полей, обязательность полей, наличие согласия, куда уходят данные после заполнения.

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

Карта потоков данных. Нарисуйте (хотя бы на листе бумаги) схему: откуда приходит лид → в какую систему попадает → кто ещё получает эти данные → где они хранятся в итоге. Для большинства компаний этот шаг откроет неприятные сюрпризы.

5.2. Чек-лист настройки лид-формы

Минимальный набор полей. Используйте только те поля, без которых физически невозможно достичь цели формы. Для первичного лида — имя и один контакт (телефон или email). Дополнительные поля добавляйте на следующих этапах воронки.

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

Согласие как отдельный чекбокс. Он должен быть незаполненным по умолчанию. Текст согласия или ссылка на него — рядом с чекбоксом, доступна до отправки формы. В тексте явно указаны: оператор, перечень данных, цели, третьи лица (включая CRM-провайдера), сроки хранения, контакт для отзыва.

Техническая защита. Форма работает по HTTPS. Данные из формы не отправляются в системы аналитики (например, не передавайте email в Google Analytics как параметр события).

Логирование согласий. CRM должна сохранять: дату и время получения согласия, версию текста согласия, которую принял пользователь. Это необходимо для доказательства законности обработки при возможной проверке.

5.3. Чек-лист настройки интеграций

Реестр интеграций. Создайте таблицу: название интеграции → сервис-получатель → какие поля передаются → правовое основание (согласие / договор поручения) → дата последней проверки.

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

Минимизация передаваемых полей. В настройках каждой интеграции проверьте, какие конкретно поля передаются. Часто сервисы по умолчанию передают всё — ограничьте только необходимым минимумом. Например, для сервиса SMS-рассылки нужен только телефон, не нужны email, имя в полном объёме и история сделок.

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

Проверка локализации. Уточните у каждого сервиса-получателя: где физически хранятся передаваемые данные? Если ответ — за рубежом, это требует либо уведомления РКН, либо замены на российский аналог.

5.4. Работа с источниками в CRM

Правильная настройка источников лидов в CRM помогает не только в маркетинге, но и в compliance. Зная точный источник каждого лида, вы знаете: какое именно согласие было получено (в лид-форме ВК согласие одно, на сайте — другое), какие данные были собраны изначально, нужно ли дозапрашивать согласие при переходе лида на следующий этап.

Рекомендуется создать в CRM отдельное поле «Тип согласия» или «Версия согласия» — и заполнять его автоматически при создании лида из конкретного источника. Это позволит быстро найти все лиды с согласиями определённой версии, если потребуется их перезапросить после изменения текста.

Часть 6. Типичные ошибки и как их избежать

6.1. Ошибка 1: «Галочка по умолчанию»

Согласие с заранее проставленной галочкой — нарушение. Суды и Роскомнадзор придерживаются позиции, что согласие должно быть активным действием субъекта [5]. Исправление: всегда оставляйте чекбокс пустым, форму без проставленной галочки нельзя отправить.

6.2. Ошибка 2: Одно общее согласие на всё

Если вы планируете передавать данные партнёрам, делать рассылку и звонить — это три разных цели обработки. С 2025 года для каждой нужно отдельное согласие [5]. Объединять всё в один пункт — риск.

6.3. Ошибка 3: Хранение данных бессрочно

152-ФЗ требует уничтожения ПДн по достижении цели обработки. Лид, который не конвертировался и по которому прекратилась коммуникация, должен быть удалён из CRM по истечении срока, указанного в согласии [13]. Настройте автоматическое архивирование и удаление.

6.4. Ошибка 4: Новые поля в CRM без анализа последствий

Разработчик добавил поле «Паспортные данные» в карточку клиента для нового бизнес-процесса — и это автоматически попало в выгрузку к call-центру. Классический случай появления новых рисков без ведома compliance-офицера. Исправление: любое добавление нового поля в CRM должно проходить через проверку: передаётся ли это поле куда-либо ещё? Нужно ли обновить согласие?

6.5. Ошибка 5: Копирование шаблонных документов из интернета

Политика конфиденциальности, «взятая из интернета», не описывает реальные процессы вашей компании, не упоминает конкретные системы и интеграции, содержит устаревшие нормы. Роскомнадзор при проверке первым делом смотрит на соответствие политики реальности [18]. Исправление: документы должны отражать реальную картину — кто, где, зачем и с чьего согласия обрабатывает данные.

6.6. Ошибка 6: Отсутствие реестра интеграций

«Мы точно не знаем, какие API-подключения активны» — это фраза, которую произносит большинство IT-руководителей при первом аудите. Данные утекают через забытые интеграции, устаревшие вебхуки, тестовые окружения с реальными данными [17]. Исправление: ведите актуальный реестр всех интеграций с проверкой не реже раза в квартал.

Часть 7. Кейсы и примеры

7.1. Кейс: минимизация полей повышает конверсию и снижает риски

Практика показывает, что длинные формы — больше 3–4 полей — критически снижают конверсию [19]. Бизнес, который убирает лишние поля, одновременно получает два результата: рост заполняемости форм и снижение объёма ПДн, ответственность за которые несёт компания. Это тот редкий случай, когда требования закона полностью совпадают с интересами бизнеса.

7.2. Кейс: иностранные сервисы как источник риска

В 2022 году компании, использовавшие иностранные CRM и ESP, столкнулись с блокировкой аккаунтов после ухода зарубежных сервисов из России. Они потеряли не только доступ к инструменту, но и клиентскую базу [11]. Сегодня к этому риску добавился юридический: использование иностранных баз данных влечёт штраф от 150 тысяч рублей только за сам факт нарушения локализации [4].

7.3. Кейс: «временная» интеграция с аналитическим сервисом

Маркетолог подключил импорт лидов в зарубежную аналитическую платформу «на пробу». Данные уходили туда год — никто не проверял. При аудите выяснилось, что в выгрузку попадали имена, телефоны и email нескольких тысяч клиентов. Правового основания для этой передачи не было. Итог — необходимость уведомления субъектов об инциденте и полная переработка документации.

Часть 8. Тренды и будущее регулирования

8.1. Автоматизированный контроль со стороны регулятора

С 2025 года Роскомнадзор внедряет системы автоматического анализа, которые позволяют дистанционно выявлять нарушения — отсутствие политики ПДн, использование зарубежных скриптов аналитики, некорректные формы согласия [7]. Это переводит контроль из режима «пожаловались — проверили» в режим постоянного мониторинга.

8.2. Privacy by Design как стандарт

Мировая тенденция, которая постепенно приходит в Россию — проектирование систем с учётом защиты данных с самого начала, а не «добавление compliance поверх» [20]. На практике это означает: при добавлении нового поля в CRM или новой интеграции вопрос «а куда уйдут эти данные и есть ли у нас основание?» должен задаваться автоматически, до любых технических изменений.

8.3. Обезличивание как инструмент аналитики

Новая статья 13.1 152-ФЗ создаёт легальный механизм для работы с обезличенными данными в аналитических целях [9]. Компании, которые научатся правильно отделять аналитические задачи от задач, требующих работы с реальными ПДн, получат конкурентное преимущество: они смогут строить полноценную аналитику, не увеличивая объём юридической ответственности.

Что делать прямо сейчас

Работа с персональными данными в CRM — это не разовая задача, а непрерывный процесс. ИТ-ландшафт постоянно меняется: подключаются новые интеграции, появляются новые поля, добавляются новые источники лидов. Каждое такое изменение потенциально создаёт новые риски.

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

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

Третий шаг — настроить процесс: чтобы каждое новое поле, каждая новая интеграция проходили минимальную проверку на соответствие требованиям 152-ФЗ до запуска, а не после.

Как «Пятый фактор» помогает контролировать ПДн в CRM и не только

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

Именно её решает платформа «Пятый фактор» (5factor.ru) — on-premise система для автоматического обнаружения, инвентаризации и контроля персональных данных в корпоративных системах. Она работает с базами данных, хранилищами, почтой, Active Directory/LDAP, CRM, 1С и API, давая компании живую «карту ПДн»: где и какие данные есть, кто их владелец, что изменилось с момента последней проверки.

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

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

Источники

[1] Федеральный закон №152-ФЗ «О персональных данных», ст. 3, ч. 2 — https://www.consultant.ru/document/cons_doc_LAW_61801/

[2] КонсультантПлюс. С 30 мая 2025 года ужесточена ответственность в области персональных данных — https://www.consultant.ru/document/cons_doc_LAW_490308/3b904c06ca00c18b687ec94295a0a967ddc5cce7/

[3] Федеральный закон №152-ФЗ, ст. 5. Принципы обработки персональных данных — https://www.consultant.ru/document/cons_doc_LAW_61801/96fbc469f91f57235cc842a85e0516a99f23dc85/

[4] VC.ru — Персональные данные 2025: штраф до 15 млн ₽ и запрет зарубежных баз — https://vc.ru/legal/2186769-personalnye-dannye-2025-izmeneniya-i-shtrafy

[5] KLerk.ru — 152-ФЗ о персональных данных: требования для бизнеса в 2026 году — https://www.klerk.ru/blogs/roskom24/674017/

[6] RTM Group — Изменения в законе о персональных данных с 2025 года: новые штрафы за утечки — https://rtmtech.ru/articles/novye-shtrafy-za-utechki-pdn/

[7] РБК Компании — Новые требования к персональным данным в 2026 — https://companies.rbc.ru/news/lIWDgweSHr/novyie-trebovaniya-k-personalnyim-dannyim-v-2026-chto-teper-obyazatelno/

[8] Центр информационной безопасности — Утечка данных: штрафы до 500 млн и тюремный срок — https://belinfonalog.ru/company/news/aktualnoe/ugolovnaya-otvetstvennost-za-utechki-chto-dolzhny-znat-rukovoditeli/

[9] sec.ussc.ru — Планируемые изменения Федерального закона №152-ФЗ — https://sec.ussc.ru/152fz-changes

[10] VC.ru — Как не нарушать закон «О персональных данных» при работе с облачными CRM — https://vc.ru/ask/15994-problem-14877

[11] DashaMail — Персональные данные: требования закона и ответственность — https://dashamail.ru/blog/personal_data/

[12] Helpdesk Bitrix24 — Как создать и настроить CRM-форму — https://helpdesk.bitrix24.ru/open/24730032/

[13] Business.ru — 152-ФЗ о персональных данных в 2025–2026 годах — https://www.business.ru/article/5705-152-fz-o-personalnyh-dannyh-gg

[14] Helpdesk Bitrix24 — Соглашение о персональных данных в CRM-формах — https://helpdesk.bitrix24.ru/open/17359248/

[15] Integrator.Digital — Чек-лист проверки сайта на соответствие 152-ФЗ после 30 мая 2025 года — https://integrator.digital/blog/vse-o-razrabotke-saytov/chek-list-proverki-saita-fz-152-o-personalnyh-dannyh/

[16] Enkod.io — Закон о ПДн: что нужно знать CRM-маркетологу об использовании Telegram, WhatsApp и Google Analytics — https://enkod.io/blog/zakon-o-personalnyh-dannyh-chto-nuzhno-znat-crm-marketologu-ob-ispolzovanii-telegram-whatsapp-i-google-analytics/

[17] SecurityLab.ru — DSPM-подход: как превратить хаос в систему защиты данных — https://www.securitylab.ru/analytics/567140.php

[18] РБК Отрасли — Как новые законы изменят подход бизнеса к персональным данным — https://www.rbc.ru/industries/news/686fabc99a79472e5a66a3c5

[19] Pressfeed — Лид-форма: что это, как правильно составить — https://news.pressfeed.ru/kakie-lid-formy-byvayut-i-kak-ih-pravilno-sostavit-dlya-vysokoj-konversii/

[20] Cossa.ru — Персональные данные в маркетинге: границы допустимого — https://www.cossa.ru/trends/340569/