152-ФЗ и клиентские данные — тема, которая регулярно возникает на архитектурных комитетах enterprise-компаний. Закон о персональных данных предъявляет конкретные требования к хранению, обработке и защите клиентской информации. Однако большинство SaaS CDP и CRM-платформ не дают оператору полного контроля над тем, где и как обрабатываются данные. В результате enterprise-компании в Москве и по всей России сталкиваются с разрывом: бизнес требует единый клиентский профиль и триггерные коммуникации, а служба ИБ блокирует внедрение, потому что облачный сервис не проходит compliance-проверку. On-prem CDP закрывает этот разрыв архитектурно — данные остаются внутри контура компании, а оператор получает полный контроль над доступом, аудитом и жизненным циклом персональных данных.
В этом руководстве — конкретика по требованиям 152-ФЗ к клиентским данным в CDP/CRM-контуре, типичные проблемы SaaS-модели с точки зрения закона, архитектурные решения on-prem платформы и чек-лист для команды ИБ. Подробнее об архитектуре on-prem CDP — в отдельном разделе.
Что 152-ФЗ требует от оператора клиентских данных
Федеральный закон №152-ФЗ «О персональных данных» определяет обязанности оператора — любой организации, которая собирает, хранит, обрабатывает или передаёт персональные данные клиентов. Для enterprise-компаний с клиентской базой от 50 000 записей и выше эти обязанности имеют прямые архитектурные последствия.
Ключевые обязанности оператора персональных данных
| Требование 152-ФЗ | Статья закона | Архитектурное следствие |
|---|---|---|
| Локализация данных граждан РФ на территории России | ст. 18, ч. 5 | Серверы — в российском дата-центре |
| Обеспечение конфиденциальности | ст. 7 | Шифрование, контроль доступа, изоляция |
| Получение согласия субъекта | ст. 9 | Consent management в CDP |
| Уведомление Роскомнадзора об обработке | ст. 22 | Фиксация целей и оснований обработки |
| Обеспечение прав субъекта (доступ, удаление, уточнение) | ст. 14-17 | API для отзыва согласия и удаления данных |
| Оценка вреда и определение уровня защищённости | ст. 18.1, ПП-1119 | Классификация ИСПДн, подбор средств защиты |
| Назначение ответственного за обработку | ст. 22.1 | Ролевая модель с выделенным DPO |
| Уничтожение данных по достижении цели или отзыву согласия | ст. 21 | Автоматическое удаление с подтверждением |
Поскольку CDP по определению агрегирует клиентские данные из нескольких источников — CRM, сайта, мобильного приложения, контакт-центра, биллинга — платформа становится ключевой информационной системой персональных данных (ИСПДн). Следовательно, именно CDP определяет уровень защищённости всего клиентского контура.
Что изменилось в 2024-2026 годах
Регулирование ужесточается. В 2024 году приняты поправки, увеличивающие штрафы за утечку персональных данных до 15 млн рублей для юридических лиц (ст. 13.11 КоАП). Кроме того, введена обязанность уведомлять Роскомнадзор и субъекта данных об инциденте в течение 24 часов. Для enterprise-компаний с клиентской базой в сотни тысяч записей цена ошибки возросла кратно. Поэтому архитектурный выбор CDP — не технический, а бизнес-критичный вопрос.
Почему SaaS CDP создаёт compliance-риски
Облачная CDP-платформа решает функциональную задачу — единый профиль клиента, сегментация, триггерные коммуникации. Однако при прохождении compliance-проверки SaaS-модель регулярно вызывает вопросы у службы ИБ. Рассмотрим типичные проблемы.
1. Неопределённость места хранения данных
SaaS-провайдер управляет инфраструктурой самостоятельно. Даже если серверы формально находятся в России, оператор не контролирует, на каких именно узлах обрабатываются данные, кто имеет к ним доступ на уровне инфраструктуры и как организовано резервное копирование. С точки зрения 152-ФЗ оператором персональных данных остаётся ваша компания — не SaaS-провайдер. Вы отвечаете за соблюдение закона, даже если данные хранятся в чужом облаке.
2. Ограниченный контроль над доступом
В облачной модели администраторы провайдера имеют техническую возможность доступа к данным клиентов. Формально это регулируется SLA и NDA, но при проверке Роскомнадзора или аудите ИБ возникает вопрос: как оператор может гарантировать конфиденциальность, если физический контроль над данными — у третьей стороны? Более того, RBAC в SaaS-платформах обычно ограничен ролями бизнес-пользователей и не покрывает инфраструктурный уровень.
3. Audit trail без полноты
152-ФЗ требует от оператора фиксировать факты обработки персональных данных. SaaS-платформы предоставляют журнал действий пользователей, но не дают полного аудита на уровне базы данных — кто читал запись, кто экспортировал выборку, кто изменил consent-статус через API. Без контроля над инфраструктурой построить полноценный audit trail невозможно.
4. Сложность удаления данных
По закону оператор обязан уничтожить персональные данные при отзыве согласия субъекта (ст. 21 152-ФЗ). В SaaS-модели вы отправляете запрос провайдеру и получаете подтверждение. Однако вы не можете проверить, действительно ли данные удалены из всех резервных копий, реплик, CDN-кэшей и аналитических хранилищ провайдера. Для enterprise-компании с жёсткими compliance-политиками это неприемлемый уровень неопределённости.
5. Vendor lock-in как compliance-риск
Зависимость от SaaS-провайдера создаёт не только коммерческий, но и регуляторный риск. Если провайдер изменит условия обработки данных, перенесёт серверы или закроет бизнес на российском рынке — оператор окажется в ситуации, когда персональные данные клиентов находятся в контуре, над которым он потерял контроль. Подробнее о рисках зависимости — в разделе «Независимость от вендора».
Как on-prem CDP закрывает требования 152-ФЗ
On-prem развёртывание CDP устраняет архитектурный конфликт между функциональностью платформы и требованиями закона. Данные физически остаются внутри контура компании — на серверах, которыми оператор управляет напрямую. Рассмотрим, как это работает на практике.
Локализация данных — по определению
При on-prem развёртывании серверы CDP находятся в дата-центре компании или в российском colocation. Оператор знает точный адрес каждого узла, контролирует физический доступ и самостоятельно определяет политику резервного копирования. Требование ст. 18 ч. 5 о локализации закрывается архитектурно, а не через SLA с третьей стороной.
Изоляция клиентского контура
On-prem CDP работает в изолированной сети. В отличие от мультитенантного SaaS, где данные разных клиентов провайдера хранятся в общей инфраструктуре, on-prem контур — это отдельная инсталляция с выделенной базой данных. Ни один другой заказчик не разделяет с вами ни серверы, ни сетевой сегмент, ни хранилище.
Для enterprise-компаний в retail, банковском секторе и телекоме эта изоляция — базовое требование службы ИБ. Без неё проект не проходит архитектурный комитет.
Полный контроль над шифрованием
On-prem позволяет применять собственные политики шифрования — как на уровне хранения (encryption at rest), так и на уровне передачи (encryption in transit). Оператор самостоятельно выбирает криптографические алгоритмы, управляет ключами шифрования и интегрирует CDP с корпоративным HSM (Hardware Security Module), если это требуется регуляторикой. В SaaS-модели выбор криптографии — за провайдером.
Архитектура Stackfort для compliance
Stackfort — on-prem CDP платформа на стеке Go + PostgreSQL + React — изначально спроектирована для работы внутри защищённого контура. Платформа запускается на 1-3 узлах (профиль Minimum: 8 vCPU, 32 ГБ RAM, 500 ГБ NVMe) и не требует тяжёлого distributed-стека с Kafka, Elasticsearch или Keycloak. Это упрощает прохождение ИБ-аудита — меньше компонентов, меньше attack surface, меньше точек контроля.
Lean-архитектура — осознанное решение. Каждый дополнительный компонент в стеке — это дополнительная поверхность атаки, дополнительные порты для firewall-правил и дополнительная зависимость для обновления. PostgreSQL покрывает задачи полнотекстового поиска через встроенные механизмы (tsvector + trigram), поэтому Elasticsearch не нужен. Один Go-бинарь выполняет роли API-сервера, rules engine и worker-процессов — нет необходимости в отдельных message broker-ах на старте. Такой подход сокращает число компонентов ИСПДн, которые необходимо документировать в модели угроз.
| Аспект compliance | SaaS CDP | On-prem CDP (Stackfort) |
|---|---|---|
| Место хранения данных | Контролирует провайдер | Контролирует оператор |
| Физический доступ к серверам | Только у провайдера | У оператора |
| Управление ключами шифрования | Провайдер | Оператор |
| RBAC на уровне инфраструктуры | Нет | Да |
| Полный audit trail (включая БД) | Ограниченный | Полный |
| Гарантированное удаление данных | Через SLA | Верифицируемое |
| Изоляция данных | Мультитенант | Выделенный контур |
RBAC и audit trail: контроль доступа по закону
152-ФЗ требует от оператора обеспечить конфиденциальность персональных данных (ст. 7) и принять меры по защите от несанкционированного доступа (ст. 19). На практике это означает две вещи: ролевую модель доступа (RBAC) и полный журнал аудита (audit trail). Рассмотрим, как это реализуется в on-prem CDP.
Ролевая модель доступа (RBAC)
RBAC (Role-Based Access Control) в контексте 152-ФЗ — это не просто «администратор / менеджер / оператор». Enterprise-компании с клиентской базой от 150 000 записей и 10-50 пользователями CDP нуждаются в гранулярной модели:
- Доступ к данным по категориям. Оператор колл-центра видит имя и телефон, но не видит историю покупок. Маркетолог видит сегменты и агрегированные показатели, но не видит конкретные контакты. Аналитик видит обезличенные данные.
- Доступ по подразделениям. Менеджер московского филиала не видит клиентов петербургского отделения.
- Разделение ролей «просмотр / редактирование / экспорт / удаление». Экспорт клиентской базы — отдельное право, которое выдаётся только руководителям с согласованием DPO.
- Workspace-изоляция. В мультибрендовых холдингах каждый бренд работает в своём workspace с полной изоляцией данных.
В on-prem CDP оператор сам определяет ролевую матрицу — без ограничений тарифного плана SaaS-провайдера, где гранулярный RBAC часто доступен только на дорогих enterprise-тарифах.
Audit trail: что фиксировать и зачем
Полный audit trail в CDP должен фиксировать каждое действие с персональными данными. Это необходимо для трёх целей: соответствие 152-ФЗ и подзаконным актам, расследование инцидентов и подготовка к проверке Роскомнадзора.
| Событие | Что фиксируется | Зачем |
|---|---|---|
| Просмотр карточки клиента | Кто, когда, какие поля, IP-адрес | Контроль доступа к ПДн |
| Редактирование профиля | Старое/новое значение, автор, метка времени | Расследование инцидентов |
| Экспорт данных | Объём выгрузки, формат, получатель | Предотвращение утечек |
| Удаление данных | Что удалено, основание, подтверждение | Соблюдение ст. 21 (уничтожение по запросу) |
| Изменение consent-статуса | Основание, субъект, дата, канал | Юридическая фиксация согласия/отзыва |
| Изменение ролей и прав | Кто назначил, какую роль, кому | Контроль привилегированного доступа |
| API-запросы к данным | Endpoint, параметры, токен, результат | Контроль внешних интеграций |
В Stackfort audit log хранится в PostgreSQL — том же стеке, что и основные данные. Это упрощает резервное копирование и гарантирует, что журнал аудита не «отделяется» от данных при миграции или восстановлении из бэкапа.
Связь RBAC и audit trail
Грамотная архитектура подразумевает, что RBAC и audit trail работают как единая система. Каждое действие проверяется на уровне прав (RBAC → разрешить/запретить) и одновременно логируется (audit trail → зафиксировать). Если пользователь пытается выполнить действие без прав — это тоже фиксируется как событие безопасности. Такой подход позволяет ИБ-службе не только контролировать текущий доступ, но и ретроспективно анализировать все попытки доступа к персональным данным.
Типичные ошибки при внедрении RBAC в CDP
На практике мы видим несколько повторяющихся ошибок, которые ослабляют compliance-позицию компании:
- Плоская ролевая модель. Два уровня — «администратор» и «пользователь» — не покрывают реальные сценарии enterprise-компании. Маркетолог, аналитик и оператор колл-центра нуждаются в разном объёме доступа. Без гранулярного RBAC любой пользователь CDP потенциально имеет доступ ко всем персональным данным — а это прямое нарушение принципа минимизации.
- Отсутствие контроля экспорта. Право на экспорт клиентской базы в CSV или Excel — наиболее рискованная операция с точки зрения утечки. Если экспорт доступен всем ролям по умолчанию, audit trail фиксирует факт, но не предотвращает инцидент. Рекомендация — выделить экспорт как отдельное привилегированное право с двойным подтверждением.
- Неактуальные роли. Сотрудник уволился или перешёл в другой отдел, но его учётная запись в CDP осталась активной. Интеграция с корпоративным Active Directory или SSO решает эту проблему автоматически — деактивация в AD немедленно блокирует доступ к CDP.
Жизненный цикл персональных данных в CDP
152-ФЗ регулирует не только хранение, но и весь жизненный цикл персональных данных — от сбора до уничтожения. On-prem CDP должна поддерживать каждый этап этого цикла. Рассмотрим, как это выглядит архитектурно.
Сбор: consent management
Персональные данные попадают в CDP из нескольких источников: формы на сайте, мобильное приложение, CRM, контакт-центр, биллинг. На этапе сбора критично зафиксировать правовое основание обработки — согласие субъекта (ст. 9 152-ФЗ) или иное основание (ст. 6). В on-prem CDP consent-статус хранится как атрибут профиля клиента и обновляется в реальном времени при каждом взаимодействии.
Важный нюанс: consent должен быть конкретным. Субъект даёт согласие на определённые цели обработки — маркетинговые коммуникации, аналитику, передачу партнёрам. CDP должна хранить не флаг «согласен/не согласен», а матрицу согласий по целям.
Хранение: сроки и основания
Закон требует хранить персональные данные не дольше, чем это необходимо для достижения целей обработки (ст. 5 ч. 7). Следовательно, CDP должна поддерживать настраиваемые политики retention — автоматическое удаление или обезличивание данных по истечении заданного срока. Например, данные клиента, не совершавшего покупок 36 месяцев, могут быть автоматически обезличены для аналитики и удалены из активного профиля.
Обработка: минимизация
Принцип минимизации (ст. 5 ч. 5) означает, что оператор обрабатывает только те данные, которые необходимы для заявленных целей. В архитектуре CDP это реализуется через разграничение полей по категориям доступа и автоматическое маскирование данных, не относящихся к текущей задаче. Например, при построении маркетингового сегмента система использует поведенческие атрибуты, не раскрывая ФИО и контактные данные.
Удаление: верифицируемое уничтожение
При отзыве согласия оператор обязан прекратить обработку и уничтожить персональные данные в течение 30 дней (ст. 21). В on-prem CDP этот процесс полностью контролируем:
- Субъект отзывает согласие (через форму, API или обращение в компанию).
- CDP помечает профиль на удаление и блокирует обработку.
- Запускается процедура уничтожения — удаление из основной БД, бэкапов и всех связанных систем.
- Формируется акт уничтожения с фиксацией в audit log.
- Акт доступен для предъявления при проверке Роскомнадзора.
В SaaS-модели оператор не может верифицировать шаги 3-5 самостоятельно — приходится полагаться на слово провайдера.
Когда удаление — не вариант: обезличивание
Не все данные можно просто удалить. Аналитические агрегаты, отчёты по когортам, статистика конверсий — всё это содержит производные от персональных данных. 152-ФЗ допускает обезличивание как альтернативу удалению (ст. 3 п. 9): данные утрачивают привязку к конкретному субъекту, но сохраняют аналитическую ценность. On-prem CDP позволяет реализовать обезличивание на уровне базы данных — замена ФИО на хеши, маскирование контактов, удаление прямых идентификаторов с сохранением поведенческих атрибутов. В результате маркетинговая аналитика продолжает работать, а персональные данные считаются уничтоженными с точки зрения закона.
Чек-лист для команды ИБ: оценка compliance-готовности CDP
Этот чек-лист предназначен для руководителей ИБ и DPO, которые оценивают CDP-платформу на соответствие требованиям 152-ФЗ. Используйте его при выборе решения или при аудите уже внедрённой системы.
Блок 1. Локализация и инфраструктура
| № | Проверка | Критерий «пройдено» |
|---|---|---|
| 1.1 | Серверы расположены на территории РФ | Физический адрес дата-центра подтверждён |
| 1.2 | Данные не покидают контур (нет трансграничной передачи) | Сетевая изоляция, whitelist исходящих соединений |
| 1.3 | Бэкапы хранятся в РФ | Политика резервного копирования документирована |
| 1.4 | Шифрование at rest | AES-256 или ГОСТ, ключи — у оператора |
| 1.5 | Шифрование in transit | TLS 1.2+ между всеми компонентами |
Блок 2. Контроль доступа
| № | Проверка | Критерий «пройдено» |
|---|---|---|
| 2.1 | RBAC с гранулярностью до полей/действий | Матрица ролей задокументирована |
| 2.2 | Разделение «просмотр / редактирование / экспорт» | Экспорт — отдельное право |
| 2.3 | Интеграция с корпоративным SSO/AD | SAML 2.0 или LDAP |
| 2.4 | Двухфакторная аутентификация | TOTP или push для привилегированных ролей |
| 2.5 | Автоматическая блокировка при бездействии | Сессия истекает через 30 минут |
Блок 3. Аудит и мониторинг
| № | Проверка | Критерий «пройдено» |
|---|---|---|
| 3.1 | Audit trail на все действия с ПДн | Просмотр, редактирование, экспорт, удаление |
| 3.2 | Неизменяемость журнала аудита | Append-only, защита от модификации |
| 3.3 | Срок хранения журнала ≥ 3 года | Настраиваемый retention для аудит-логов |
| 3.4 | Алертинг при аномальных действиях | Массовый экспорт, вход из нового IP, изменение ролей |
| 3.5 | Интеграция с SIEM | Syslog / API для экспорта событий |
Блок 4. Управление данными
| № | Проверка | Критерий «пройдено» |
|---|---|---|
| 4.1 | Consent management по целям обработки | Матрица согласий, история изменений |
| 4.2 | Автоматическое удаление при отзыве согласия | 30 дней, акт уничтожения |
| 4.3 | Retention-политики (автоудаление по сроку) | Настраиваемые сроки по категориям данных |
| 4.4 | Обезличивание для аналитики | Маскирование ФИО, контактов при агрегации |
| 4.5 | Реализация права на доступ субъекта | API или интерфейс для выгрузки данных субъекта |
Блок 5. Документация и процессы
| № | Проверка | Критерий «пройдено» |
|---|---|---|
| 5.1 | Политика обработки ПДн | Документ утверждён, опубликован |
| 5.2 | Модель угроз для ИСПДн | Классификация по ПП-1119 проведена |
| 5.3 | Уведомление Роскомнадзора | Реестр операторов, запись актуальна |
| 5.4 | Регламент реагирования на инциденты | Уведомление РКН в 24 часа, план действий |
| 5.5 | Регулярный внутренний аудит | Не реже 1 раза в год |
Stackfort закрывает блоки 1-4 на уровне платформы. Блок 5 — зона ответственности оператора, но платформа предоставляет данные для документации: журналы аудита, матрицу ролей, отчёты по consent-статусам и историю удалений.
Отраслевые требования поверх 152-ФЗ
152-ФЗ — базовый закон. Однако для ряда отраслей существуют дополнительные требования, которые ужесточают правила обработки клиентских данных. При выборе CDP необходимо учитывать отраслевую специфику.
Банки и финансовые организации
Помимо 152-ФЗ, банки подчиняются требованиям ЦБ РФ: ГОСТ Р 57580.1 (защита информации), положения 683-П и 684-П (уровни защиты для кредитных и некредитных финансовых организаций). Тем не менее CDP в банковском контуре обязана интегрироваться с существующей системой ИБ — SIEM, DLP, HSM — и проходить аттестацию как часть ИСПДн. On-prem развёртывание упрощает аттестацию, поскольку все компоненты находятся в контролируемой среде.
Retail и e-commerce
Розничные сети работают с программами лояльности, где персональные данные клиентов (ФИО, телефон, история покупок, геолокация) обрабатываются в больших объёмах. Следовательно, для retail критичны масштабируемость RBAC (десятки магазинов = десятки ролей) и скорость обработки запросов на удаление — клиент может отозвать согласие в любом из каналов. Подробнее о построении лояльности на базе CDP — в разделе «Программы лояльности».
Телеком
Операторы связи подчиняются 126-ФЗ «О связи» и обязаны хранить данные о соединениях абонентов. CDP в телекоме обычно интегрируется с биллингом и BSS/OSS-стеком. При этом on-prem подход для телекома — естественный выбор, поскольку операторы уже имеют собственную ЦОД-инфраструктуру и привыкли к эксплуатации on-prem систем.
Медицина и здравоохранение
Медицинские данные относятся к специальным категориям персональных данных (ст. 10 152-ФЗ) и требуют повышенного уровня защищённости. Обработка допускается только с письменного согласия субъекта. CDP для медицинских организаций должна обеспечивать физическую изоляцию медицинских данных от маркетинговых — вплоть до хранения в разных таблицах с разными ключами шифрования.
Сводная таблица отраслевых требований
| Отрасль | Дополнительная регуляторика | Ключевое требование к CDP |
|---|---|---|
| Банки | ГОСТ Р 57580.1, 683-П | Аттестация ИСПДн, интеграция с SIEM/HSM |
| Retail | 152-ФЗ (большие объёмы) | Масштабируемый RBAC, быстрое удаление |
| Телеком | 126-ФЗ | Интеграция с биллингом, хранение метаданных |
| Медицина | ст. 10 152-ФЗ (спец. категории) | Физическая изоляция медданных |
| Travel / hospitality | 152-ФЗ + ПП-687 (биометрия) | Обработка документов, consent per trip |
FAQ о 152-ФЗ и клиентских данных
Какой уровень защищённости ИСПДн нужен для CDP?
Уровень защищённости определяется по ПП-1119 на основе категории данных, объёма базы и типа угроз. Для CDP с клиентской базой от 100 000 записей, содержащей ФИО, контакты и историю покупок, обычно требуется 3-й или 2-й уровень защищённости. On-prem развёртывание упрощает достижение нужного уровня, поскольку все компоненты — в контролируемом контуре. Конкретный уровень фиксируется в акте классификации ИСПДн.
Обязательно ли хранить клиентские данные CDP в России?
Да. Статья 18 ч. 5 152-ФЗ требует, чтобы при сборе персональных данных граждан РФ запись, систематизация, накопление и хранение осуществлялись в базах данных на территории России. Это касается любой CDP, обрабатывающей данные российских клиентов. On-prem CDP в российском дата-центре закрывает это требование по определению — без дополнительных соглашений с облачным провайдером.
Сколько стоит привести CDP в соответствие с 152-ФЗ?
Стоимость compliance зависит от архитектуры. Для on-prem CDP основные затраты — внедрение платформы (от 2,1 млн рублей за пакет Minimum) плюс организационные меры: модель угроз, политика обработки, аттестация ИСПДн. Для SaaS CDP к подписке добавляются затраты на аудит провайдера, юридическую экспертизу SLA и дополнительные контракты на data processing agreement. В долгосрочной перспективе on-prem обычно выходит дешевле за счёт предсказуемого TCO.
Как on-prem CDP помогает при проверке Роскомнадзора?
При проверке Роскомнадзора оператор обязан предъявить: политику обработки ПДн, уведомление в реестр операторов, журнал аудита доступа к данным, подтверждение согласий и акты уничтожения. On-prem CDP генерирует все технические артефакты автоматически — audit trail, consent history, акты удаления. Оператору остаётся подготовить организационные документы. В SaaS-модели часть артефактов приходится запрашивать у провайдера, что усложняет и замедляет процесс.
Можно ли использовать SaaS CDP и соответствовать 152-ФЗ?
Формально — да, если провайдер хранит данные в России и готов подписать data processing agreement. На практике compliance в SaaS-модели держится на доверии к провайдеру, а не на техническом контроле оператора. Вы не можете самостоятельно проверить, кто имеет доступ к данным на стороне провайдера, как работает удаление из бэкапов и какие данные передаются субподрядчикам. Для enterprise-компаний с жёсткими ИБ-политиками этот уровень неопределённости часто неприемлем.
Какие штрафы за нарушение 152-ФЗ в 2026 году?
С учётом поправок 2024 года штрафы за утечку персональных данных выросли до 15 млн рублей для юридических лиц. За повторные нарушения — оборотные штрафы. За несоблюдение требований локализации — от 6 до 18 млн рублей. Помимо штрафов, Роскомнадзор вправе ограничить обработку данных, что для бизнеса с клиентской базой означает остановку маркетинговых коммуникаций, программы лояльности и сегментации.
Нужна ли аттестация ИСПДн для on-prem CDP?
Аттестация обязательна для государственных информационных систем (приказ ФСТЭК №17). Для коммерческих организаций формально достаточно оценки эффективности мер защиты (приказ ФСТЭК №21). Тем не менее на практике крупные enterprise-компании — банки, телеком, госкорпорации — проводят добровольную аттестацию, поскольку это демонстрирует compliance контрагентам и регулятору. On-prem CDP упрощает процедуру: все компоненты в одном контуре, не нужно аттестовать инфраструктуру третьей стороны.
Следующий шаг: архитектурная консультация
Соответствие 152-ФЗ — не разовый проект, а постоянный процесс. Архитектура CDP определяет, насколько этот процесс будет управляемым. Если ваша команда оценивает compliance-готовность текущего клиентского контура или выбирает между SaaS и on-prem CDP — запишитесь на архитектурную консультацию. Разберём вашу ситуацию: текущую инфраструктуру, объём данных, отраслевые требования и оптимальный deployment profile.
Подробнее о внедрении on-prem CDP и профилях мощностей — в разделе «Внедрение и развёртывание CDP».