Требования к защите персональных данных: 5 ключевых метрик
У системы защиты персональных данных есть два разных измерения: соответствие установленным требованиям и способность обнаружить сбой до того, как он станет утечкой. Первое описывают правовые нормы и уровень защищенности ИСПДн.
Второе приходится измерять по рабочим показателям: охвату инфраструктуры контролем, срокам устранения уязвимостей, готовности к инцидентам.
Единого нормативного списка из пяти метрик, обязательного для любой организации, нет. Законодательство задает категории данных, уровни защищенности и отдельные процедуры. Метрики ниже помогают оценить, работает ли система защиты на практике, но не заменяют определение применимых требований.
Федеральный закон № 152-ФЗ действует с 26 января 2007 года и определяет базовые организационные и технические требования к обработке и защите персональных данных граждан РФ. Постановление Правительства № 1119 от 1 ноября 2012 года устанавливает четыре уровня защищенности. Конкретные меры зависят от категории обрабатываемых данных, актуальных угроз, типа информационной системы и числа субъектов.
1. Уровень защищенности ИСПДн
Уровень защищенности это не рейтинг надежности продукта и не результат одного сканирования. Это нормативная характеристика информационной системы персональных данных, которую определяют с учетом условий обработки и модели угроз. Постановление № 1119 предусматривает УЗ-1, УЗ-2, УЗ-3 и УЗ-4. В общем случае более высокий уровень связан с более жесткими требованиями.
Порог в 100 000 субъектов встречается среди критериев определения уровня, но сам по себе не дает ответа, какой именно уровень нужен. В расчет также входят категории данных и вид угроз. Поэтому присвоение уровня по одному числу пользователей это неполная оценка.
| Показатель | Что он показывает | Чего не показывает |
|---|---|---|
| Уровень защищенности ИСПДн | Какой набор требований применим к системе при заданных условиях обработки | Фактическое качество исполнения каждой меры |
| Число субъектов | Масштаб обработки и один из критериев классификации | Категорию данных и актуальные угрозы |
| Категория данных | Чувствительность обрабатываемой информации и нормативный контекст | Уязвимости конкретной реализации |
| Модель угроз | Какие сценарии воздействия должны учитываться | Что система уже защищена от каждого сценария |
На практике уровень следует связывать с конкретной системой, а не с компанией целиком. У мобильного приложения, облачного хранилища и кадровой ИСПДн могут быть разные составы данных, потоки и границы доверия. Одна общая формулировка «данные защищены» не описывает ни архитектуру, ни примененные меры.
Для цифрового продукта полезно фиксировать, где именно данные появляются, куда передаются и какие компоненты получают доступ. Например, приложение может собирать сведения на устройстве, отправлять их в API, передавать в аналитическую платформу и сохранять в облаке. Каждое звено расширяет периметр обработки. Если реестр систем и потоков не совпадает с реальной архитектурой, выбранный уровень защищенности опирается на неполную модель.
2. Уведомление об инциденте и срок 24 часа
Для подлежащих соответствующему порядку операторов информирование ГосСОПКА об инциденте должно выполняться в течение 24 часов. Это срок организационного реагирования. Его нельзя считать допустимым временем бездействия или целевым сроком восстановления системы.
Внутри организации отсчет начинается раньше формальной отправки уведомления: событие нужно обнаружить, классифицировать, подтвердить связь с информационной инфраструктурой и передать ответственным. Если журналы хранятся в разных системах, синхронизация времени отсутствует, а дежурный не знает, кто принимает решение, календарные 24 часа быстро превращаются в операционное ограничение.
Для контроля этой части процесса нужны как минимум три временные отметки:
- время первого события в журнале или системе мониторинга;
- время, когда событие признано инцидентом и передано ответственному;
- время выполнения применимого уведомления и начала локализации.
Разница между первой и второй отметками показывает, сколько времени уходит на обнаружение и первичную классификацию. Разница между подтверждением и уведомлением характеризует работу процедуры эскалации. Если организация измеряет только время закрытия тикета, задержка до регистрации инцидента остается невидимой.
Для расследования нужны журналы аутентификации, сетевых соединений, изменений конфигурации и действий с данными. Логи должны позволять установить источник события, затронутые системы и временную последовательность. Само наличие SIEM или агента мониторинга ничего не доказывает, если нужные события не собираются либо хранятся слишком короткий срок.
Срок уведомления имеет смысл только при работающем механизме обнаружения, классификации и эскалации инцидента.
Регламент стоит проверять не по наличию документа, а по результатам учений и реальных инцидентов. Кто имеет право объявить событие инцидентом? Кто передает сведения? Кто сохраняет доказательства? Как изолируют узел, не уничтожив данные для анализа? Ответы должны быть закреплены до аварии. В момент компрометации проприетарного компонента времени на проектирование процесса уже нет.
3. Зрелость системы защиты
Соответствие формальным требованиям описывает обязательный минимум для заданных условий. Зрелость показывает, насколько системно организация управляет риском: выявляет активы, пересматривает угрозы, назначает владельцев мер, проверяет результат и обновляет процедуры после изменений.
По обновленным требованиям ФСТЭК регулярная оценка зрелости защиты предусмотрена с 1 сентября 2026 года. На 3 октября 2026 года эта дата уже пройдена, и требование вступило в силу: организации должны проводить такую оценку в установленном порядке. Перед практическим применением все же стоит сверить актуальную редакцию нормативных актов и уточнить применимый состав положений, поскольку отдельные пункты могут сопровождаться переходными положениями и методическими разъяснениями регулятора. Периодическая оценка зрелости остается полезной как управленческий инструмент независимо от того, когда именно она становится обязательной.
Уровень зрелости не стоит сводить к одному баллу без расшифровки. Итоговая оценка должна опираться на проверяемые свидетельства: инвентаризацию систем, результаты сканирования, сроки устранения дефектов, протоколы тестирования резервного восстановления, историю пересмотра доступов и материалы разбора инцидентов.
Метрика становится полезной, когда у нее есть владелец, период измерения и правило расчета. Например, доля систем с актуальной моделью угроз имеет смысл только при ясном знаменателе: в него включены все системы обработки ПДн или только те, которые попали в выборку? Если часть облачных сервисов не учтена, высокий процент покрытия будет отражать качество таблицы, а не состояние инфраструктуры.
При оценке зрелости также важна повторяемость. Разовая проверка показывает состояние на дату аудита. Серия сопоставимых оценок позволяет увидеть, устранены ли прежние несоответствия, сократилось ли время реакции, появились ли новые системы вне контроля. Сравнивать результаты можно лишь при неизменной методике и понятном составе проверяемых активов.
4. Охват контроля и MTTR
Технические меры защиты данных включают управление доступом, регистрацию событий, обновление программного обеспечения, резервное копирование и контроль уязвимостей. Их наличие в политике не равно фактическому охвату. Показатель покрытия инфраструктуры системами контроля должен отвечать на прямой вопрос: какая доля обнаруженных активов действительно сканируется и получает результаты, пригодные для обработки.
Знаменатель здесь критичен. Если сканер проверяет 90% узлов из CMDB, но сама инвентаризация не содержит тестовых серверов, облачных рабочих нагрузок и забытых API, процент вводит в заблуждение. Инвентаризацию следует сверять с облачными учетными записями, DNS, сетевыми журналами, репозиториями и фактическими данными о подключенных устройствах. Сканирование должно охватывать не только операционные системы, но и внешние сервисы, контейнерные образы, зависимости приложений и конфигурации, если эти компоненты входят в периметр.
Среднее время устранения уязвимости, MTTR, часто используют как показатель скорости реакции. Но среднее скрывает хвост распределения: множество простых дефектов могут быть закрыты быстро, пока одна критическая уязвимость остается открытой месяцами. Поэтому полезно считать MTTR отдельно по критичности, типу актива и наличию эксплуатации. Еще одна важная отметка — время от обнаружения до компенсирующей меры, если немедленное обновление невозможно.
Для интерпретации показателя нужны как минимум такие параметры:
- дата обнаружения и дата закрытия каждой уязвимости;
- уровень критичности и наличие публичного эксплойта либо признаков эксплуатации;
- тип системы и ее доступность из внешней сети;
- наличие временной меры: отключения сервиса, ограничения доступа или сетевой фильтрации;
- число повторно открытых дефектов после неудачного исправления.
MTTR не следует превращать в соревнование подразделений. Если команда закрывает уязвимости без проверки исправления, показатель улучшается, а риск остается. Нужны подтверждение версии, повторное сканирование и контроль конфигурации. Для критичных систем важна также процедура исключения: кто и на какой срок принимает остаточный риск, если обновление конфликтует с работой сервиса.
5. Телеметрия и скрытый периметр обработки
IP-адреса, cookies и параметры устройства, собираемые веб-метриками, в указанной фактуре квалифицируются как обработка персональных данных, требующая уведомления и согласия пользователя. Значит, аналитический счетчик нельзя рассматривать как нейтральный фрагмент интерфейса. Он создает поток данных к стороннему сервису и меняет карту обработки.
С точки зрения аудита нужно установить, какие события отправляются, какие идентификаторы формируются, как долго хранятся сведения и кто получает к ним доступ. У мобильного приложения к этому добавляются идентификаторы установки, диагностические события и сведения о версии ОС. Конкретный состав зависит от реализации и настроек. Его нельзя выводить только из названия SDK: поведение следует сверять с конфигурацией и сетевым трафиком.
Отдельно оценивается передача данных подрядчикам и SaaS-платформам. Критерии безопасности облачных хранилищ начинаются с границ ответственности: кто управляет ключами, кто может администрировать среду, как фиксируются действия привилегированных учетных записей и каким образом заказчик получает журналы. Шифрование канала не отвечает на вопрос, кто имеет доступ к данным после их расшифровки на стороне сервиса. При разборе этой модели полезен материал о защите персональных данных в SaaS.
Сквозное шифрование также не закрывает весь риск. Оно может защищать содержимое между конечными точками, но не обязательно скрывает метаданные, факт соединения, размер и время передачи. Если ключи контролирует поставщик или они доступны административному контуру, модель доверия отличается от сценария, где ключ остается у владельца данных. Это должно быть отражено в документации, а не подразумеваться по маркетинговому описанию сервиса.
Минимальные требования к обработке данных должны быть видны в технической конфигурации: сбор ограничен заявленной целью, лишние события отключены, сроки хранения определены, доступ разделен по ролям, а передача третьим сторонам учтена. Для веб-сайта и приложения полезна сверка фактических сетевых запросов с перечнем интеграций. Расхождение между декларацией и телеметрией это отдельный риск, даже если каждый компонент по отдельности считается стандартным.
Как читать пять метрик вместе
Пять показателей дают разные срезы: уровень защищенности задает применимые требования, процедура уведомления измеряет готовность к инциденту, оценка зрелости показывает устойчивость процессов, покрытие контроля и MTTR описывают техническую реакцию, а анализ телеметрии выявляет неочевидные потоки данных.
Ни один показатель не заменяет остальные. Высокий охват сканированием не компенсирует неизвестный перечень обрабатываемых данных. Низкий MTTR не доказывает, что устранены уязвимости в компонентах, которые не попали в инвентаризацию. Наличие согласия на обработку не подтверждает защищенность хранилища.
Рабочая оценка начинается с инвентаризации систем и потоков данных. Затем определяется применимый уровень защищенности, фиксируются владельцы мер и строится измерение по сопоставимым правилам. Отдельно проверяются сроки реакции, полнота журналирования и фактическая телеметрия приложений. Число в отчете имеет ценность только тогда, когда можно восстановить его происхождение.
Защита персональных данных это контур контроля, а не комплект документов. Если активы не учтены, события не регистрируются, а передача данных подрядчикам остается за пределами аудита, формальное соответствие не показывает реальное состояние системы. Метрики должны выявлять эти разрывы, а не маскировать их средним баллом.