Большинство владельцев сайтов уверены: форма заявки отправляет данные напрямую им. На почту, в CRM, в Telegram-бот. Там данные и живут.
На самом деле нет.
Если ваш сайт сделан на Tilda, uKit, Wix, LP Generator или любом другом конструкторе - данные из формы сначала попадают на серверы этого конструктора. И только потом - к вам.
Это не значит, что конструктор что-то делает не так. Это просто как устроена большинство SaaS-платформ. Но если вы не знали - самое время разобраться.
[Если хотите сразу понять, что именно открыто в вашем конкретном случае - узнайте на stopparsing.ru. Бесплатный аудит периметра показывает, через какие каналы ваши данные могут утекать к посторонним.]
Что происходит с данными, когда клиент нажимает «Отправить»?
Коротко: данные из формы сначала попадают на API-сервер конструктора. Браузер посетителя отправляет запрос туда - конструктор принимает, записывает и только потом доставляет вам по email или через интеграцию с CRM.
Вот как это выглядит технически:
- Посетитель заполняет поля (имя, телефон, email, любые другие) и нажимает «Отправить»
- Браузер отправляет запрос на сервер конструктора - например, forms.tildacdn.com или аналог
- Сервер конструктора принимает данные и записывает их в свою базу
- После этого - доставляет вам: письмо на почту, запись в Airtable, интеграция с AmoCRM
Шаги 2 и 3 - это то, чего большинство владельцев сайтов не видят. Но они происходят каждый раз.
Если вы откроете, например, Tilda и зайдёте в раздел «Лиды» - там будут все заявки, которые когда-либо пришли через формы на вашем сайте. Они хранятся в системе Tilda. Не только у вас в почте или CRM - ещё и там.
Почему конструктор не передаёт данные напрямую?
Коротко: конструктор несёт ответственность за надёжную доставку. Если отправлять данные напрямую на ваш email и тот упадёт - заявка потеряется. Поэтому конструктор сначала принимает данные к себе, а потом доставляет.
Это стандартная архитектура для SaaS-сервисов. Называется server-side form processing.
Альтернатива - когда у вас собственный сайт на своём хостинге. Тогда форма может отправлять данные напрямую в ваш CRM через REST API - без промежуточного звена. Данные не касаются серверов конструктора, потому что конструктора попросту нет.
Это не значит, что конструкторы плохие. Они решают конкретную задачу - дать бизнесу сайт без программистов и сложной инфраструктуры. За это приходится принять, что определённые данные проходят через их инфраструктуру.
Вопрос в другом: вы знаете, что именно через неё проходит?
Что именно хранит конструктор из вашей формы?
Коротко: всё, что посетитель ввёл в форму. Имя, телефон, email, кастомные поля - плюс технические метки: время заявки, IP-адрес и UTM-параметры, если форма их отслеживает.
Конкретно это означает:
- Имя и контактные данные потенциального клиента
- Телефон и email - то, за что вы платили рекламой
- Запросы и детали обращения - если в форме есть поля типа «опишите задачу»
- Рекламный источник (utm_source, utm_campaign) - откуда пришёл посетитель
- Время заявки - когда именно был пик интереса
Последнее может показаться мелочью. Но представьте: конкурент, у которого есть доступ к вашим данным в системе конструктора, видит не просто контакты - он видит, сколько заявок вы получили за месяц, в какие дни, с каких каналов. Это разведка о состоянии вашего бизнеса.
На практике - такой сценарий маловероятен. Но возможность существует, пока данные живут за пределами вашего периметра.
152-ФЗ: кто за что отвечает, когда форма на чужом сервисе?
Коротко: вы остаётесь оператором персональных данных, а конструктор становится обработчиком. По закону - это требует письменного договора и отдельных записей в вашей политике конфиденциальности.
Подробно о том, что закон говорит про сбор данных через цифровые инструменты, разобрано в статье «Парсинг сайтов и 152-ФЗ: что законно».
По 152-ФЗ «О персональных данных» есть два ключевых понятия:
Оператор - тот, кто определяет, зачем и как обрабатываются данные. В данном случае это вы - владелец сайта и бизнеса.
Обработчик - тот, кто фактически обрабатывает данные по поручению оператора. Это конструктор сайтов.
Что из этого следует практически:
Договор поручения обработки персональных данных. Между вами и конструктором должен быть заключён такой договор. У большинства крупных конструкторов он встроен в пользовательское соглашение - но вам нужно убедиться, что вы его приняли и он соответствует требованиям закона.
Политика конфиденциальности. В вашей политике должно быть указано, что данные передаются конструктору как обработчику. Большинство бизнесов об этом не знает.
Трансграничная передача. Если серверы конструктора находятся за пределами России - по 152-ФЗ это трансграничная передача данных. Для неё нужно уведомить Роскомнадзор. Российские конструкторы (uKit, российская инфраструктура Tilda) этой проблемы не создают. Wix с серверами в США - создаёт.
Если ваша форма сейчас работает без договора с конструктором и без упоминания его в политике - это нарушение. Небольшое, которое легко закрыть, но всё же.
Чем это отличается от сайта на своём хостинге?
Коротко: на своём хостинге данные из формы идут напрямую к вам, без промежуточного звена. Конструктор - это третья сторона в цепочке.
Сравнение:
| Вопрос | Конструктор сайтов | Свой хостинг |
|---|---|---|
| Где проходят данные формы | Сервер конструктора - потом к вам | Ваш сервер - потом в CRM |
| Кто хранит копию заявок | Конструктор + вы | Только вы |
| Договор по 152-ФЗ нужен | Да, с конструктором | Нет (если нет других сторонних сервисов) |
| Риск при инциденте у третьей стороны | Есть | Нет (если нет сторонних сервисов) |
| Стоимость и сложность запуска | Низкая | Выше - нужен разработчик |
Это не значит, что свой хостинг - единственное правильное решение. Конструкторы существуют, потому что для большинства бизнесов выгода скорости и цены перевешивает архитектурный риск. Вопрос в том, знаете ли вы о риске и сознательно его принимаете.
Есть и промежуточное решение: использовать конструктор, но настроить прямую интеграцию через webhook - тогда данные уходят сразу в ваш CRM, а у конструктора остаётся только технический лог запроса без содержимого. Это снижает объём хранимых данных на стороне конструктора, хотя полностью от промежуточного звена не избавляет.
Когда это реальный риск, а когда нет?
Коротко: риск существенный, если ваш конструктор подвергается инциденту или если за вашими данными целенаправленно охотятся. Для большинства B2B-бизнесов - это управляемый риск, который стоит понять, а не паниковать.
Честная оценка:
Когда риск выше:
- Вы работаете в нише с высокой конкурентной борьбой, где данные о клиентах - ценность
- Вы используете конструкторы с серверами за рубежом (Wix и аналоги)
- Объём заявок большой - вы собираете значительную базу через формы
- У вас нет договора с конструктором и форм обработки персональных данных
Когда риск ниже:
- Вы работаете в спокойной нише без активного перехвата клиентов
- Конструктор - российский, с серверами в России
- Вы уже подписали пользовательское соглашение (оно часто включает договор обработчика)
- Через формы проходят только базовые контактные данные, без чувствительной информации
Важное уточнение: даже «низкий риск» не значит «риска нет». Это значит, что угрозу можно принять как приемлемую при условии, что вы её понимаете. Незнание об угрозе - это не «низкий риск», это просто неоцененный риск.
Что можно сделать уже сейчас
Коротко: четыре конкретных шага, которые закрывают основные правовые и технические дыры без смены конструктора.
Шаг 1. Проверьте, что именно хранит конструктор. Зайдите в раздел «Лиды» или «Формы» вашего конструктора. Посмотрите, сколько данных там накоплено и как долго они хранятся. Обычно у конструктора есть настройки срока хранения.
Шаг 2. Сверьтесь с пользовательским соглашением конструктора. Найдите раздел про обработку персональных данных. Проверьте, включён ли там договор поручения обработки (или его эквивалент). Если не включён - обратитесь в поддержку конструктора.
Шаг 3. Обновите политику конфиденциальности. Добавьте конструктор в список лиц, которым передаются персональные данные. Если у вас вообще нет такой политики - это отдельная задача, но начните с этого.
Шаг 4. Настройте webhook или прямую интеграцию с CRM. Во многих конструкторах можно настроить прямую отправку данных в CRM через webhook. Данные всё равно пройдут через сервер конструктора, но объём хранимой копии там уменьшится.
Это минимум, который закрывает самые очевидные уязвимости. Но он не отвечает на вопрос: через какие каналы ваши данные вообще могут покинуть ваш периметр? Форма - один из них. Не единственный.
Аудит периметра: как понять, что реально открыто для посторонних
Коротко: чтобы знать реальное состояние своего периметра данных, нужен аудит - проверка того, через какие каналы ваши данные (заявки, номера сотрудников, трафик сайта) доступны системам сбора данных снаружи.
Форма на конструкторе - это один из векторов, которые проверяет аудит. Но не единственный. Подробнее о разнице между разными видами защиты - в материале «Чем защита от парсинга отличается от обычной».
Компании теряют данные через:
- Формы на сторонних платформах (именно то, о чём написана эта статья)
- Трафик сайта - посетители, которых «снимают» конкурирующие сервисы перехвата
- Телефоны сотрудников - по ним можно собрать оргструктуру и выйти на конкретных людей
- Незащищённые каналы передачи данных
Если коротко, кто за что отвечает в этой системе защиты данных - в материале «Меч и щит: зачем нужны и перехват, и защита от него».
StopParsing проводит бесплатный аудит периметра: показывает, какие именно данные доступны системам сбора снаружи и через какие каналы. Не «вот у вас проблема, платите» - сначала аудит, потом разговор о том, что закрывать и на каких условиях.
Цена защиты считается индивидуально - по объёму того, что нужно закрыть (сайты, номера сотрудников, каналы передачи данных). Без пакетов вслепую.
Узнать, что открыто в вашем конкретном случае, можно здесь: stopparsing.ru
Источники
- Федеральный закон № 152-ФЗ «О персональных данных» (актуальная редакция на consultant.ru)
- Разъяснения Роскомнадзора по вопросам поручения обработки персональных данных
- Tilda Help Center: раздел «Формы и заявки» (архитектура обработки данных форм)
- Документация Tilda: «Политика конфиденциальности и персональные данные»
- uKit: Пользовательское соглашение, раздел персональных данных
- Общие принципы server-side form processing (MDN Web Docs, архитектурные стандарты)