Для соответствия требованиям к хранению данных в CRM нужно: классифицировать персональные данные, зафиксировать сроки и цели хранения, оформить правовые основания и согласия, настроить шифрование и доступы, обеспечить локализацию и резервное копирование, а также контролировать подрядчиков через договоры, SLA и регулярный аудит конфигурации CRM.
Основные регуляторные требования к хранению данных в CRM
- Фиксация целей обработки и сроков хранения персональных данных в политике и в настройках CRM.
- Наличие правового основания, согласий и процедур исполнения прав субъекта данных.
- Шифрование данных, разграничение прав доступа и ведение аудита действий пользователей.
- Локализация персональных данных граждан РФ и контролируемая трансграничная передача.
- Регулярное резервное копирование, тестовое восстановление и контроль целостности бэкапов.
- Договорные обязательства и SLA со всеми поставщиками CRM и облачной инфраструктуры.
- Периодический аудит: проверка настроек CRM, журналов, прав и фактических практик хранения.
Классификация данных и политика хранения: как разбить и задокументировать
Подход применим организациям, которые запускают внедрение CRM с учетом требований по хранению и обработке персональных данных или пересматривают существующую систему. Не стоит усложнять классификацию микробизнесу без чувствительных данных и без отраслевого регулирования (банки, медицина, госзаказ), чтобы не перегрузить процессы.
Цель раздела: превратить абстрактные требования в конкретные классы данных и понятную политику хранения, которую можно отразить в настройках корпоративной CRM с защитой и хранением персональных данных.
Мини-чек-лист: подготовка к описанию политики хранения
- Что сделать: собрать перечень всех сущностей и полей в CRM (лиды, сделки, пациенты, заемщики, документы).
Кто отвечает: владелец CRM-процесса + администратор CRM.
Как проверить: выгрузка структуры данных из CRM, сверка с бизнес-процессами. - Что сделать: определить, какие поля относятся к персональным данным и специальным категориям.
Кто отвечает: DPO/ответственный за ПДн + юрист.
Как проверить: перечень ПДн утвержден приказом/политикой, есть ссылка на статьи закона. - Что сделать: описать бизнес-цели использования каждого класса данных.
Кто отвечает: бизнес-владелец процессов продаж/сервиса/медицинских услуг.
Как проверить: для каждого класса есть связка «цель — основание — срок». - Что сделать: согласовать сроки хранения и правила обезличивания/удаления.
Кто отвечает: юрист + ИБ/IT.
Как проверить: сроки отражены в политике, есть описание механизма автоудаления или архивирования.
Практическая классификация данных в CRM
- Классы данных:
- Идентификационные данные (ФИО, контакты, ID клиента).
- Договорные и финансовые данные (счета, договоры, история оплат) — критично для crm для банков с соблюдением требований к хранению данных.
- Медицинские или иные чувствительные данные (диагнозы, результаты исследований) для crm для медицинских организаций с соблюдением регуляторных требований.
- Маркетинговые данные (история коммуникаций, предпочтения, теги).
- Технические журналы и метаданные (IP, логины, Device ID).
- Что сделать: для каждого класса указать:
- цель обработки;
- правовое основание;
- срок хранения и событие, после которого запускается отсчет (окончание договора, отписка от рассылки и т.п.);
- степень критичности (высокая/средняя/низкая).
- Кто отвечает: владелец процесса + юрист/комплаенс + ИБ.
- Как проверить: наличие отдельного документа «Реестр категорий данных CRM», связанного с политикой обработки ПДн.
Документирование политики хранения и реализация в CRM
- Что сделать: оформить политику хранения с привязкой к настройкам CRM:
- описать, какие данные и когда подлежат удалению/архивированию;
- зафиксировать ответственных за запуск процедур удаления;
- определить, что именно попадает в отчеты и журналы.
- Кто отвечает: юрист/комплаенс + администратор CRM.
- Как проверить: в CRM настроены:
- автоматические правила архивирования/удаления по триггерам;
- ограничения на экспорт данных (только по заявкам и ролям);
- регламент по ручному удалению в нестандартных случаях.
Правовые основания, согласия и управление правами субъектов данных
На этом этапе важны не только юридические тексты, но и конкретные поля, статусы и процессы в CRM системе соответствие 152 фз хранение персональных данных.
Что понадобится из требований
- Правовые основания:
- исполнение договора или подготовка к нему;
- согласие субъекта данных (для маркетинга, чувствительных данных);
- законные интересы оператора (с обоснованием и возможностью возражения);
- отраслевые требования (банковская, медицинская тайна, архивные требования).
- Что сделать: для каждого процесса в CRM (продажи, сервис, телемаркетинг, медуслуги, кредитование) указать конкретное основание обработки.
- Кто отвечает: юрист/комплаенс, согласование с бизнес-владельцами процессов.
- Как проверить: наличие матрицы «процесс — тип данных — основание».
Инструменты и настройки CRM
- Поля согласий:
- отдельные флаги/поля для каждого канала коммуникации (email, SMS, звонки, мессенджеры);
- дата и источник согласия (форма на сайте, бумажное заявление, колл-центр);
- история изменений статуса согласия.
- Управление правами субъектов:
- процедура доступа: поиск записи клиента, выгрузка полного досье из CRM по запросу;
- процедура исправления: фиксация, кто и когда менял данные;
- процедура удаления/ограничения: перевод записи в специальный статус с частичным обезличиванием.
- Кто отвечает: администратор CRM + служба поддержки/операционный отдел.
- Как проверить: тестовые сценарии: подать «запрос субъекта» от тестового клиента и пройти всю цепочку.
Доступы и журналы для работы с запросами субъектов
- Что сделать:
- ограничить права на удаление и массовые изменения только уполномоченным ролям;
- включить детальный аудит по операциям чтения, экспорта и удаления ПДн;
- создать преднастроенные отчеты для контроля запросов субъектов.
- Кто отвечает: ИБ/IT + владелец процесса.
- Как проверить: выборочно проверить по журналу несколько операций с ПДн, убедиться в наличии атрибутов «кто/что/когда».
Шифрование, управление доступом и аудит действий пользователей
Мини-чек-лист подготовки к настройке защиты
- Что сделать: определить, какие среды используются: облако поставщика CRM, локальные сервера, мобильные клиенты.
Кто отвечает: IT/администратор CRM.
Как проверить: инвентаризация: список всех компонентов инфраструктуры CRM. - Что сделать: собрать перечень ролей и типовых пользователей (продажи, сервис, врачи, операционисты банка).
Кто отвечает: HR/бизнес + администратор CRM.
Как проверить: есть утвержденная матрица ролей и прав. - Что сделать: согласовать минимальный набор логируемых событий.
Кто отвечает: ИБ/комплаенс.
Как проверить: перечень событий описан в регламенте, доступны тестовые логи.
- Определить зоны, где требуется шифрование данных
Шифрование нужно на уровне каналов связи, хранения на серверах и рабочих станциях, а также для резервных копий.- Что сделать: проверить поддержку TLS, шифрования на уровне БД и приложений в используемой CRM.
- Кто отвечает: IT/архитектор + поставщик CRM.
- Как проверить: сканирование портов/сертификатов, тестовая расшифровка бэкапа, проверка настроек БД.
- Настроить защищенные каналы и политики паролей
Все подключения пользователей к CRM должны происходить по защищенным протоколам, с жесткими требованиями к аутентификации.- Что сделать: включить принудительный HTTPS, настроить VPN для удаленного доступа, включить сложные пароли и MFA.
- Кто отвечает: администратор сети и CRM.
- Как проверить: попытаться подключиться по незащищенному протоколу; убедиться, что система блокирует.
- Развернуть ролевую модель доступа в CRM
Разграничение должно отражать бизнес-роль, а не «имя человека».- Что сделать: создать ролей столько, сколько типов пользователей; для каждой задать права чтения/записи/удаления по объектам CRM.
- Кто отвечает: владелец процесса + администратор CRM.
- Как проверить: зайти под тестовым пользователем каждой роли и проверить, что недоступны лишние данные.
- Включить и настроить аудит действий пользователей
Журналы должны фиксировать критические операции, особенно в корпоративной CRM с защитой и хранением персональных данных.- Что сделать: включить логирование операций входа, экспорта, изменения и удаления записей; задать срок хранения логов.
- Кто отвечает: ИБ/IT.
- Как проверить: выполнить тестовые операции и убедиться, что они появились в журналах с нужными деталями.
- Организовать регулярный обзор логов и реагирование на инциденты
Одного ведения журналов мало, нужен понятный процесс анализа.- Что сделать: назначить ответственных, создать расписание и форматы отчетов по аномальным действиям.
- Кто отвечает: ИБ/комплаенс.
- Как проверить: наличие ежемесячных отчетов, примеры обработанных инцидентов.
Локализация данных и правила трансграничной передачи
Важный аспект для компаний, работающих сразу на нескольких рынках (РФ, ЕС, США) и использующих облачные решения.
Сравнение ключевых требований по юрисдикциям
| Юрисдикция | Базовое требование к хранению | Трансграничная передача | Практическое влияние на CRM |
|---|---|---|---|
| РФ | Первичный сбор и запись ПДн граждан РФ — на территории РФ. | Допустима при соблюдении требований, в т.ч. к странам-получателям и договорам. | Нужны дата-центры в РФ или локальные ноды; контроль, чтобы основные таблицы ПДн хранились в РФ. |
| ЕС (GDPR) | Нет строгой локализации, акцент на защите и правах субъектов. | Строгие условия передачи вне ЕС (адекватность стран, стандартные договорные оговорки). | Нужно описать потоки данных, использовать утвержденные механизмы передачи, вести реестр операций. |
| США | Федеральные и отраслевые требования, фокус на уведомлении и безопасности. | Ограничения зависят от отрасли (медицина, финансы) и договоров. | Важно, где физически расположен облачный провайдер, и какие контракты подписаны. |
Чек-лист проверки локализации и передачи
- Что сделать: получить от поставщика CRM перечень дата-центров и стран обработки.
Кто отвечает: закупки/IT.
Как проверить: официальное письмо или спецификация в договоре. - Что сделать: убедиться, что ПДн граждан РФ хранятся в дата-центрах РФ, а репликации за рубежом не нарушают закон.
Кто отвечает: комплаенс + IT.
Как проверить: схемы архитектуры, настройки регионов хранения. - Что сделать: описать все сценарии, когда данные уходят за границу (поддержка, аналитика, резервные копии, интеграции).
Кто отвечает: архитектор интеграций.
Как проверить: карта потоков данных, перечень интеграций. - Что сделать: включить в договоры с поставщиками стандартные положения о трансграничной передаче и защите ПДн.
Кто отвечает: юрист/закупки.
Как проверить: текст договора, наличие приложений по защите данных. - Что сделать: разнести аккаунты по регионам, если CRM поддерживает региональные инстансы.
Кто отвечает: администратор CRM.
Как проверить: настройки региона на уровне аккаунта/организации. - Что сделать: регламентировать, где и как сотрудники могут выгружать данные (экспорт в файлы, BI-системы за рубежом).
Кто отвечает: ИБ/владелец данных.
Как проверить: политика экспорта, ограничения в ролях CRM.
Резервное копирование, восстановление и проверка целостности данных
Типичные ошибки при работе с резервными копиями
- Отсутствие документированной схемы бэкапа.
Нет понятного описания, какие данные, как часто и куда копируются, особенно опасно для crm для банков с соблюдением требований к хранению данных. - Бэкапы без шифрования.
Резервные копии хранятся незашифрованными, иногда в «общих» файловых хранилищах, доступных многим. - Отсутствие регулярного тестового восстановления.
Система вроде бы делает бэкапы, но никто не проверяет, что из них можно восстановиться. - Хранение резервных копий только в одной локации.
Риски потери данных из-за аварии, пожара, отказа оборудования. - Недостаточный контроль доступа к бэкапам.
Доступ имеют администраторы без разделения ролей, нет журналов обращений. - Отсутствие связки бэкапов с политикой хранения.
Данные, которые должны быть удалены, продолжают существовать в старых копиях без регламента их уничтожения. - Игнорирование специфики чувствительных данных.
Медицинские или финансовые данные копируются в тестовые среды без обезличивания, что критично для crm для медицинских организаций с соблюдением регуляторных требований. - Слабая документация по процедурам аварийного восстановления.
При инциденте команда тратит время на выяснение шагов, а не на восстановление.
Операционные процедуры, SLA и контроль сторонних поставщиков
Варианты организационной модели
- Полностью внутренняя CRM-инфраструктура
- Когда уместно: крупные организации с сильной IT/ИБ-функцией, высокой чувствительностью данных (банки, госкомпании).
- Плюсы: максимальный контроль, возможность тонкой настройки под регулятора, проще обосновывать crm система соответствие 152 фз хранение персональных данных.
- Минусы: высокая стоимость владения и необходимость собственной экспертизы.
- Облачная CRM с жесткими SLA и DPA
- Когда уместно: компании среднего размера, которым нужна гибкость и скорость внедрения CRM с учетом требований по хранению и обработке персональных данных.
- Плюсы: быстрый старт, обновления на стороне провайдера, масштабирование.
- Минусы: зависимость от провайдера, нужно тщательно прорабатывать договоры и механизмы аудита.
- Гибридная модель (облако + on-premise)
- Когда уместно: сложные ландшафты с разными юрисдикциями и требованиями, в том числе crm для банков с соблюдением требований к хранению данных.
- Плюсы: возможность хранить критичные данные локально, а вспомогательные сервисы выносить в облако.
- Минусы: усложнение архитектуры и процессов администрирования.
- Отраслевые специализированные CRM-платформы
- Когда уместно: медицинские, финансовые, страховые организации, где регуляторика особенно жесткая.
- Плюсы: встроенные механизмы соответствия отраслевым требованиям, преднастроенные журналы и отчеты.
- Минусы: меньше свободы кастомизации, возможная привязанность к вендору.
Операционные процедуры и контроль поставщиков
- Что сделать: описать операционные регламенты: создание пользователей, отзыв доступа, реагирование на инциденты, обновления CRM.
Кто отвечает: владелец CRM-процесса + ИТ-эксплуатация.
Как проверить: регламенты утверждены, сотрудники знают свои роли. - Что сделать: формализовать SLA по доступности, времени реакции на инциденты, срокам устранения уязвимостей.
Кто отвечает: закупки/юрист + ИТ.
Как проверить: SLA закреплены в договорах, есть отчеты от поставщика по фактическому выполнению. - Что сделать: провести оценку поставщиков: безопасность, локация дата-центров, практика резервного копирования.
Кто отвечает: комплаенс/ИБ.
Как проверить: отчеты аудита, опросники, сертификаты, результаты тестов. - Что сделать: внедрить периодический аудит конфигурации CRM на предмет соответствия политике хранения и защиты.
Кто отвечает: внутренний аудит/ИБ.
Как проверить: план аудитов, отчеты, планы корректирующих действий.
Практические ответы на часто встречающиеся вопросы по хранению данных
Нужно ли всегда получать согласие на обработку данных в CRM?
Нет, если обработка необходима для исполнения договора или по закону, можно обойтись без отдельного согласия. Но для маркетинговых рассылок и чувствительных данных согласие практически всегда требуется и должно фиксироваться в полях CRM.
Какой минимальный набор журналов действий должен быть в CRM?
Следует фиксировать входы и выходы пользователей, изменения и удаления записей с персональными данными, операции экспорта и администрирования прав доступа. Журналы должны позволять однозначно определить, кто и когда выполнил действие.
Можно ли хранить резервные копии CRM в публичном облаке за рубежом?
Технически можно, но только при соблюдении требований по локализации, трансграничной передаче и шифрованию. Важно, чтобы в договорах с провайдером были прописаны меры защиты и ответственность за инциденты.
Как совместить требования локализации данных РФ и использование зарубежной облачной CRM?
Чаще применяют гибридную схему: основные базы с ПДн граждан РФ размещают в дата-центрах в России, а зарубежная CRM работает с обезличенными или минимально необходимыми данными. Вариант зависит от архитектуры конкретного продукта.
Кто должен быть формальным владельцем данных в CRM?
Обычно это бизнес-подразделение, которое использует данные для своей деятельности (продажи, сервис, медицина, банк), а ИТ и ИБ выступают сервисными функциями. Важно письменно зафиксировать, кто принимает решения о правилах хранения и доступа.
Как проверять, что поставщик CRM соблюдает свои обещания по безопасности?
Полагайтесь не только на маркетинговые заявления: просите отчеты аудитов, сертификаты, результаты тестов, проводите периодические опросники и сверяйте их с фактическими архитектурными решениями и инцидентами.
Стоит ли переносить старые данные при миграции в новую CRM?
Рекомендуется переносить только данные, у которых сохраняются цели обработки и правовые основания. Остальное лучше архивировать или обезличить, совместив миграцию с «генеральной уборкой» в соответствии с политикой хранения.
