CRM и 152-ФЗ: что обязан сделать бизнес с клиентской базой

Да, законно. В 152-ФЗ нет запрета на ведение клиентской базы в CRM и нет перечня «одобренных» программ. Закон регулирует не инструмент, а роль: если вы собираете имена, телефоны, почту, адреса и историю обращений клиентов, вы становитесь оператором персональных данных, и обязанности возникают у вас.

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

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

Минимальный набор действий, без которого разговор о законности не имеет смысла, выглядит так.

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

Ниже — та же самая рамка, но переведённая с юридического языка на язык вашей CRM.

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

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

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

Что с этим делать. Начните с инвентаризации: выпишите все места, где данные клиента появляются вне CRM, включая личные ноутбуки, мессенджеры и файлы. Затем закройте очевидное — перенесите формы и хранение на российские мощности, уберите выгрузки в иностранные сервисы, задайте правило для AI-инструментов: в модель уходят обезличенные формулировки, а не карточка клиента целиком. Оставшиеся спорные случаи выносите на юриста — их не должно быть много, если очевидное уже убрано.

Согласие требуется по общему правилу, но у него есть альтернативные основания: закон допускает обработку без отдельного согласия, если она необходима для исполнения договора с самим субъектом данных. Проще говоря: чтобы отгрузить заказ и связаться с покупателем по этому заказу, отдельная галочка нужна не всегда, а вот чтобы потом присылать ему акции — уже да.

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

Технически корректная форма выглядит так: отметка о согласии не предустановлена, рядом стоит рабочая ссылка на политику обработки, а форма физически не отправляется без отметки. На нашем сайте это заложено в контракт формы: заявка не уходит в обработку, если согласие не отмечено, — это не декоративная галочка, а условие отправки.

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

Ровно в том месте, где заканчиваются документы и начинаются права доступа. Уведомление, политика и согласия — это бумажный слой; он необходим, но он ничего не делает с данными. Реальный контроль появляется тогда, когда система технически не позволяет сотруднику увидеть то, что ему не положено, и сохраняет след каждого действия с записями.

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

Разница между «настроили права в интерфейсе» и «изоляция заложена в архитектуру» существенная. В нашей собственной МИС — медицинской информационной системе, которую мы строим на своём стеке, — мультиарендность сделана через PostgreSQL RLS: row-level security, то есть разграничение доступа на уровне строк самой базы данных, а не условием WHERE в коде приложения. Смысл в том, что ошибка разработчика в одном запросе не приводит к утечке: данные одной клиники физически не попадают в выборку другой, потому что фильтрует их СУБД, а не программист.

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

Частично. Переезд на self-hosted CRM — систему, развёрнутую на вашем собственном сервере, — закрывает вопрос о том, где физически лежат данные, и даёт полный контроль над доступом, журналами и резервными копиями. Вы перестаёте зависеть от условий чужого облака и можете сами решать, кто и как получает доступ к базе.

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

Отдельный риск переезда — потерять данные в процессе. В нашем проекте миграции для мебельного производства мы переносили CRM-контур из Bitrix24 в self-hosted EspoCRM «один в один», со сверкой каждой записи: 45 компаний, 2217 контактов, 1541 лид и 668 сделок, а историю общения свели в 2584 записи таймлайна. Честно про статус: перенос файлов и настройка автоматизации там ещё в работе — они упираются в технические ограничения выгрузки из Bitrix24, поэтому проект в фазе внедрения, а не финального релиза.

Практический вывод: переезд на своё размещение имеет смысл, когда вам действительно нужен контроль над данными и вы готовы нести эксплуатационную нагрузку. Если задача — просто закрыть требования закона, часто дешевле остаться в российском облаке и привести в порядок документы, согласия и права доступа. На экспресс-аудите мы говорим об этом прямо, а не продаём переезд каждому.

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

Порядок, который мы проходим на экспресс-аудите, выглядит так.

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

Юридическую оценку вашей ситуации даёт ваш юрист, а не подрядчик по внедрению. Нужно ли вам уведомление и в какой редакции, какие основания обработки применимы к вашим процессам, как формулировать политику и согласия под ваши виды деятельности, какие риски несёт конкретная схема передачи данных — это вопросы к профильному специалисту. Мы не выдаём внедрение за юридическую консультацию и не обещаем «полное соответствие 152-ФЗ» как результат работ: подрядчик может привести в порядок техническую часть, но не может отвечать за правовую квалификацию вашего бизнеса.

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

Проверить контур CRM по техническим требованиям можно на бесплатном экспресс-аудите на 30 минут: смотрим, где лежат данные, как настроены права и согласия, что нужно исправить в первую очередь. Если окажется, что достаточно донастроить то, что уже куплено, мы так и скажем. Стоимость работ называем после аудита, когда понятен объём — до этого любая цифра была бы выдуманной.