Решения
Приводим ИСПДн в соответствие 152-ФЗ: модель угроз, уровень защищённости по ПП-1119, меры приказа ФСТЭК № 21 и рабочий контур вместо папки документов.
Наши клиенты
Десять лет назад приведение в соответствие 152-ФЗ выглядело как набор документов: политика обработки, приказы, перечень мест хранения, журнал инструктажей. Проверка сводилась к тому, есть ли эти бумаги и подписаны ли они. Такой формат держался, пока цена ошибки была сопоставима с расходами на комплаенс.
Сейчас цена другая. Повторная утечка переводит штраф в оборотный — процент от годовой выручки с нижней границей в 20 млн ₽. Оператор обязан уведомить Роскомнадзор об инциденте в течение 24 часов и отчитаться о результатах расследования за 72 часа. Уложиться в этот срок можно только если заранее известно, какие данные где лежали и кто к ним обращался. Папка с политикой на этот вопрос не отвечает.
Практический разрыв почти всегда один и тот же: компания не знает собственную карту персональных данных. ПДн живут не только в той системе, которую все называют ИСПДн. Они уезжают в интеграционные обмены, оседают в выгрузках для аналитики, копируются в тестовые контуры, попадают в логи приложений и в резервные копии. Меры защиты при этом выбирают под одну систему из списка, а утечка случается там, куда карта не дошла.
Карта ПДн → категория → модель угроз → уровень защищённости → меры → контур
Инвентаризация
Классификация
Угрозы
Уровень
Меры
Контур
Уровень защищённости не выбирают - его устанавливают по входным параметрам, заданным в ПП-1119. Ниже параметры, которые нужно зафиксировать до разговора о средствах защиты.
| Входной параметр | Что фиксируем | Почему это меняет уровень |
|---|---|---|
| Категория персональных данных | Специальные, биометрические, общедоступные или иные категории | Специальные и биометрические данные дают более строгий уровень при прочих равных |
| Объём субъектов | Больше или меньше 100 000 субъектов, не являющихся сотрудниками оператора | Массовая обработка чужих данных повышает требования к контуру |
| Чьи это данные | Сотрудники оператора или посторонние для оператора субъекты | База клиентов и база сотрудников попадают в разные условия |
| Тип актуальных угроз | 1-го, 2-го или 3-го типа по ПП-1119 — по наличию недокументированных возможностей в системном или прикладном ПО | Тип угроз определяется моделью угроз, поэтому её нельзя писать после выбора средств защиты |
Практический смысл таблицы: три из четырёх параметров - это про данные и процессы, а не про технику. Пока не описано, чьи данные и в каком объёме обрабатываются, разговор о конкретных средствах защиты преждевременен.
Состав работ собирается под вашу архитектуру. Мы приходим со стороны инженерии данных и интеграций - это та часть контура, которая обычно и остаётся неописанной.
Проходим по CRM, учётным системам, порталам, хранилищу и интеграционным обменам и фиксируем, где лежат ПДн, откуда приходят, куда уходят и кто их читает. Карта становится данными, а не знанием одного администратора.
Описываем угрозы и нарушителя по тому контуру, который действительно работает: подрядчики с доступом, интеграционная шина, выгрузки в аналитику, тестовые среды, мобильные клиенты.
Собираем входные параметры ПП-1119 - категорию ПДн, объём субъектов, тип актуальных угроз - и фиксируем уровень с письменным обоснованием, а не по аналогии с соседней компанией.
Ставим провайдер идентификации и SSO, роли и матрицу доступа. У каждого пользователя, включая внешних подрядчиков, один вход и явный набор прав, а отзыв доступа становится одним действием.
Настраиваем журнал: кто, когда и к каким данным обращался, какие выгрузки уходили наружу. Этот след - материал и для проверки регулятора, и для уведомления об инциденте в первые сутки.
Убираем персональные данные оттуда, где они не нужны: обезличивание в интеграциях, маскирование в тестовых контурах, чистка логов приложений. Данных, которых нет в системе, не утекают.
Если в процессах появились языковые модели, запросы к ним идут через LLM-шлюз с политикой данных и журналом, а не напрямую из приложения в чужое облако.
| Система / слой | Зона ответственности |
|---|---|
| Владелец бизнес-процесса | Решает, какие персональные данные нужны процессу и какие события считаются недопустимыми. Без этого решения объём защиты не с чем соотнести. |
| Юридический контур заказчика | Основания обработки, согласия, политика обработки ПДн, уведомление Роскомнадзора о начале обработки, договоры поручения обработки. |
| Служба ИБ и ИТ заказчика | Эксплуатирует контур каждый день: пользователи и права, обновления, реагирование на инциденты, контроль подрядчиков. |
| KT.Team | Карта ПДн и маршрутов данных, модель угроз под фактическую архитектуру, обоснование уровня защищённости, разграничение доступа и SSO, журналирование, минимизация данных в обменах. |
| Организация с лицензией ФСТЭК России | Аттестация ИСПДн и оценка соответствия там, где они требуются по характеру системы или по условиям контракта. |
| Роскомнадзор и ФСТЭК России | Регулятор и методология: требования, состав мер, надзор и реагирование на инциденты. |
С 30 мая 2025 года действуют поправки закона № 420-ФЗ от 30.11.2024 в статью 13.11 КоАП. Размер штрафа за утечку зависит от объёма затронутых субъектов, а повторное нарушение переводит штраф в оборотный: от 1 до 3% годовой выручки, но не менее 20 и не более 500 млн ₽ (ч. 15 ст. 13.11). Неправомерная передача биометрических персональных данных стоит юридическому лицу от 15 до 20 млн ₽ (ч. 17 ст. 13.11).
Для бизнеса это меняет не размер строки в бюджете, а адресата задачи. Пока штраф был фиксированным и умеренным, риск закрывался юридически — документами и регламентами. Оборотный штраф привязан к выручке, поэтому его нельзя заложить в резерв заранее, а значит вопрос переходит к тем, кто отвечает за архитектуру: где физически лежат данные, кто к ним имеет доступ и что останется в журнале, если доступ окажется чужим.
Сроки усиливают тот же сдвиг. Уведомить Роскомнадзор об инциденте нужно в течение 24 часов, отчитаться о результатах внутреннего расследования — за 72 часа. Собрать за сутки картину «что именно ушло» можно только по заранее настроенному журналу. Если журнала нет, компания получает второй состав нарушения поверх первого — уже за молчание.
Кейсы
Приведение ИСПДн в соответствие опирается на две инженерные вещи - управляемый доступ и явные границы данных. Ниже проекты, где мы делали именно это, вне рамок отдельного проекта по 152-ФЗ.
В проекте единого входа для ГК ТОЧНО у внутренних пользователей доступ к смежным сервисам согласовывался от трёх недель до двух месяцев, а у внешних подрядчиков учётных записей не было вообще — обмен шёл на бумаге с последующей оцифровкой. Мы поставили Keycloak как провайдер идентификации и личный кабинет как единую точку входа. С точки зрения 152-ФЗ это и есть базовая часть контура: явная учётная запись у каждого, кто читает данные, и один управляемый механизм выдачи и отзыва прав.
В проекте MDM для «Музторга» граница данных задавалась на этапе постановки задачи. Формулировка из кейса: «Еще одна граница — персональные данные: в историческую загрузку намеренно берем только юридические лица». Это дешёвый и недооценённый ход: данные, которые не втянули в новый контур, не нужно ни защищать, ни объяснять регулятору.
Смотрим системы, интеграции и подрядчиков с доступом. Результат - черновая карта персональных данных и список мест, где они оказались незапланированно.
Фиксируем категорию ПДн, объём субъектов и тип актуальных угроз, устанавливаем уровень защищённости с обоснованием и сверяем его с составом мер приказа № 21.
Раскладываем разницу между требуемым и фактическим на короткий список работ и сортируем его по риску, а не по алфавиту разделов приказа.
Внедряем доступы, журналирование и минимизацию данных, описываем регламенты и передаём контур команде заказчика вместе со схемами и журналом решений.
FAQ
По постановлению Правительства РФ № 1119 от 01.11.2012. На вход идут категория обрабатываемых ПДн, объём субъектов и признак «сотрудники или посторонние», а также тип актуальных угроз, который берётся из модели угроз. Уровней четыре - от УЗ-4 до УЗ-1. Порядок важен: сначала модель угроз, затем уровень, и только потом состав мер.
Приказ ФСТЭК России от 18.02.2013 № 21 утверждает состав и содержание мер по обеспечению безопасности персональных данных в ИСПДн. Приказ от 11.02.2013 № 17 задаёт требования к защите информации, не составляющей государственную тайну, в государственных информационных системах. Если ваша ИСПДн работает внутри ГИС, применяются оба документа.
Для государственных информационных систем аттестация предусмотрена требованиями к ГИС. Для коммерческой ИСПДн вопрос решается характером системы и условиями контрактов: заказчики из госсектора и крупные корпоративные клиенты нередко требуют её договором. Саму аттестацию выполняет организация с лицензией ФСТЭК России, мы к этой процедуре готовим контур.
Ответственность оператора не передаётся вместе с данными. Обработка на стороне подрядчика оформляется поручением обработки, а требования к защите распространяются на его часть контура. На практике это означает, что карта ПДн должна выходить за периметр компании и включать всех, кто получает данные по интеграции.
Карта персональных данных и обоснованный уровень защищённости обычно собираются за несколько недель - это аналитическая работа, а не закупка. Дальше срок зависит от разрыва между требуемым и фактическим состоянием: разграничение доступа и журналирование внедряются заметно быстрее, чем перестройка интеграций, где ПДн ходят открытым текстом.
Не по умолчанию. Передача данных внешнему сервису - самостоятельное действие с точки зрения закона, а промпт с фрагментом клиентской базы означает не одного субъекта, а тысячи. Рабочая схема - шлюз, который обезличивает данные до отправки и ведёт журнал; разбор архитектуры - в статье об ИИ-агентах и 152-ФЗ.
С карты персональных данных. Она отвечает на вопрос, какие системы вообще являются ИСПДн, и почти всегда обнаруживает два-три места, о которых не помнили: выгрузку в аналитику, тестовый контур с боевой базой или лог с номерами телефонов.
Услуга KT.Team
Собираем карту персональных данных, модель угроз под вашу архитектуру и обоснованный уровень защищённости, затем закрываем разрыв инженерно: доступы, журналирование, минимизация ПДн в обменах и логах.
