Клиентские данные — это одновременно рабочий инструмент и источник рисков. С одной стороны, без них невозможно нормально продавать и обслуживать: непонятно, кто что покупал, о чём договорились, кому и когда перезвонить. С другой — утечка или неаккуратное обращение с персональными сведениями обходится дорого и репутационно, и юридически. Ниже — как мы наводим в этом порядок на проектах: последовательность шагов, технические меры и организационные решения.
Шаг первый: инвентаризация
Начинать нужно не с выбора системы, а с ответа на вопрос, где данные лежат сейчас. В большинстве компаний картина одинаковая: часть в учётной системе, часть в таблицах у менеджеров, часть в почте и мессенджерах, часть в выгрузках на личных компьютерах и во внешних сервисах рассылок.
- Перечисляем все места, где хранятся сведения о клиентах, включая временные выгрузки.
- Описываем состав: какие именно поля собираются и зачем каждое из них.
- Отмечаем, кто имеет доступ к каждому хранилищу.
- Отмечаем, кому данные передаются наружу: бухгалтерия, доставка, сервис рассылок, аналитика.
- Фиксируем, как долго данные хранятся и удаляются ли вообще.
Уже на этом шаге обычно выясняется, что половина собираемых полей никому не нужна, а часть выгрузок никто не помнит, кто и зачем делал. Самый простой способ снизить риск — перестать собирать лишнее.
Единая карточка клиента
Дальше данные сводятся в одно место. Смысл единой карточки не в красоте интерфейса, а в том, что у сведений появляется хозяин и понятный источник истины. Пока в трёх таблицах живут три разных номера телефона одного клиента, любая автоматизация будет работать по случайному из них.
- Договариваемся, какая система считается основной для каждого типа сведений.
- Определяем правило склейки дубликатов: по телефону, почте, номеру договора.
- Настраиваем обмен, чтобы данные не переносились руками.
- Убираем ручные выгрузки в таблицы, заменяя их отчётами внутри системы.
- Прописываем, что делать с историей: переносим полностью, частично или оставляем архив только для чтения.
Меры защиты
Права доступа: минимум необходимого
Основной принцип простой: сотрудник видит те данные, которые нужны ему для работы, и не видит остальные. Менеджеру не нужен доступ ко всей базе, оператору поддержки не нужны платёжные реквизиты, стажёру не нужна выгрузка контактов целиком.
На практике это означает роли вместо индивидуальных настроек, отдельное решение по массовым выгрузкам (право на экспорт всей базы должно быть у единиц) и обязательную процедуру при увольнении: доступы закрываются в тот же день, а не когда вспомнят.
Технические меры
| Мера | От чего защищает | Что нужно сделать |
|---|---|---|
| Шифрование канала | Перехват данных при передаче | Обязательный HTTPS на всех формах и в админке |
| Шифрование хранилища | Доступ к дискам и резервным копиям | Шифрование на уровне диска или отдельных полей |
| Двухфакторный вход | Кража паролей сотрудников | Второй фактор для всех, у кого есть доступ к базе |
| Журналы действий | Незаметный доступ и выгрузки | Запись просмотров, изменений и экспорта |
| Резервные копии | Потеря данных и шифровальщики | Копии по расписанию и регулярная проверка восстановления |
| Разделение сред | Утечки через тестовые контуры | Обезличенные данные на тестовых стендах |
| Сроки хранения | Накопление лишнего | Автоматическое удаление по истечении срока |
Отдельно отметим резервные копии: они защищают от потери, но сами являются полноценной базой клиентов. Копия, лежащая на общем диске без шифрования, сводит на нет остальные меры.
Согласия и прозрачность
Юридическая часть требует отдельного внимания и участия юриста, но общие принципы одинаковы для всех. Человек должен понимать, какие данные и зачем у него собирают, и дать на это согласие осознанно.
- Галочка согласия не должна быть проставлена заранее — человек ставит её сам.
- Рядом с формой нужна работающая ссылка на политику обработки данных.
- Политика должна быть открыта на сайте, а не лежать файлом, который никто не откроет.
- Согласие на рассылку отделяется от согласия на обработку заявки.
- Должен быть понятный способ отозвать согласие и удалить данные.
- Передача данных третьим сторонам, включая сервисы аналитики и рекламы, требует отдельного внимания.
Организационная часть
Технические меры не работают без правил и привычек. Мы всегда обсуждаем с заказчиком три вещи. Первая — кто отвечает за данные: должен быть конкретный человек, а не отдел. Вторая — что считается инцидентом и что делать при подозрении на утечку: кого оповещать и в каком порядке. Третья — обучение: большинство утечек происходит не через взлом, а через обычные действия сотрудников, отправивших файл не туда или переславших выгрузку на личную почту.
Полезная практика — короткий регламент на одну страницу: что можно, чего нельзя, куда обращаться. Длинные документы, которые никто не читает, не работают.
Что даёт порядок в данных
Помимо снижения рисков есть прямая рабочая польза, ради которой всё и делается.
- Менеджер видит историю общения и не переспрашивает клиента о том, что уже обсуждали.
- Руководитель видит реальную картину по сделкам, а не сводку из трёх таблиц.
- Обращения не теряются при отпуске или увольнении сотрудника.
- Маркетинг работает с сегментами, а не с общей рассылкой по всей базе.
- Данные можно передать в другие системы без ручного переноса.
Данные на сайте: где чаще всего протекает
Сайт — это первая точка, где персональные данные попадают в компанию, и одновременно самое уязвимое место. Типичные проблемы мы видим почти в каждом проекте, который принимаем на поддержку.
- Заявки уходят на личную почту сотрудника вместо корпоративного ящика или системы учёта.
- Админка сайта открыта из интернета без ограничения по адресам и без второго фактора.
- Формы отправляются без шифрования канала, потому что сертификат когда-то истёк.
- В аналитику и рекламные скрипты попадают введённые в форму значения.
- Резервные копии базы лежат в открытой папке на том же сервере.
- Учётные записи прошлых подрядчиков остались активными.
Большинство из этого закрывается за несколько часов работы и не требует никаких закупок. Поэтому в проектах по наведению порядка мы начинаем именно отсюда: сначала перекрываем очевидные пути утечки, затем занимаемся системной частью.
С чего начать, если всё запущено
Не пытайтесь решить всё одним проектом. Работающий порядок такой: сначала инвентаризация и закрытие очевидных дыр (общие пароли, открытые выгрузки, доступы уволенных). Затем сведение данных в одну систему по одному направлению — например, только продажи. Потом права доступа и журналы. Потом сроки хранения и удаление лишнего. И только после этого автоматизация и аналитика: строить их на неупорядоченных данных бессмысленно.
В медицине требования к доступу к данным жёстче обычного: роли, журнал действий и хранение базы на стороне заказчика — обязательная часть разработки CRM для клиники.
Если нужна система под ваши процессы
Мы проектируем и разрабатываем системы учёта клиентов и заказов с разграничением прав, журналами и обменом с учётными программами. Если данные разбросаны по таблицам и почте, разработаем информационную систему под ваши процессы. Напишите нам, начнём с разбора того, что и где у вас хранится.
