Слой 1. Требования: от нормы к проверяемому утверждению

Первая методологическая ошибка — работать с требованием как с абзацем закона, а не как с декомпозированным, проверяемым утверждением. Формулировка «обеспечить защиту персональных данных» (ст. 19 Федерального закона от 27.07.2006 № 152-ФЗ «О персональных данных (далее — ПДн)» (далее — 152-ФЗ) сама по себе не аудируема. Она раскладывается до уровня конкретных мер, которые уже определены подзаконными актами: приказ Федеральной службы по техническому и экспортному контролю РФ (далее − ФСТЭК России) от 18.02.2013 № 21 «Об утверждении Состава и содержания организационных и технических мер по обеспечению безопасности ПДн при их обработке в информационных системах ПДн (далее — ИСПДн)» (далее — приказ ФСТЭК России № 21) задает конкретные технические меры для каждого уровня защищенности ИСПДн (УЗ1-УЗ4), определенного постановлением Правительства РФ от 01.11.2012 № 1119 «Об утверждении требований к защите ПДн при их обработке в ИСПДн» (далее — ПП РФ № 1119). Только на этом уровне требование превращается в проверяемый пункт: «в ИСПДн уровня УЗ2 применяется межсетевое экранирование (далее — МЭ), идентификация/аутентификация, регистрация событий безопасности — есть внедренное средство, есть конфигурация, есть журнал».

Источники требований для российской организации, как правило, образуют несколько независимых, но пересекающихся контуров:

Эти контуры не изолированы. Компания, обрабатывающая биометрию сотрудников через систему контроля и управления доступом на объекте энергетики, одновременно является оператором ИСПДн по 152-ФЗ и субъектом КИИ по 187-ФЗ — и обязана вести единую модель угроз, покрывающую оба режима, иначе получает разрыв: центр мониторинга и реагирования на инциденты ИБ (SOC) реагирует на инцидент по сценарию действий при реагировании на инцидент КИИ и укладывается в срок уведомления ГосСОПКА, но пропускает отдельное уведомление Роскомнадзора об утечке ПДн, обязательное по ст. 21 152-ФЗ в течение 24 часов с момента обнаружения. Именно на стыке контуров чаще всего рвется связь «требование-контроль», потому что каждый контур закрывается своим ответственным, и никто не видит пересечения.

Слой 2. Риски: комплаенс-риск ≠ операционный риск ИБ

Здесь необходимо разделить два по-разному устроенных риска, которые в практике часто смешивают в одну строку реестра.

Комплаенс-риск — вероятность и размер санкции за несоответствие требованию, независимо от того, произошел ли реальный инцидент. Его уже можно оценивать количественно, потому что уполномоченный орган в последние два года формализовал шкалу санкций. После вступления в силу Федерального закона от 30.11.2024 № 420-ФЗ «О внесении изменений в Кодекс РФ об административных правонарушениях (далее — КоАП РФ)» (поправки в ст. 13.11 КоАП РФ действуют с 30.05.2025) штрафы за нарушения в области ПДн перестали быть символическими:

С 11.12.2024 действует ст. 272.1 «Уголовного кодекса РФ от 13.06.1996 № 63-ФЗ» (далее −УК РФ), устанавливающая уголовную ответственность за незаконный оборот ПДн, а нарушение требований по значимым объектам КИИ, приведшее к неправомерному воздействию, квалифицируется по ст. 274.1 УК РФ (до 10 лет лишения свободы для должностных лиц). Это не абстрактная «репутационная угроза» из презентации, а конкретная, юридически формализованная величина, которую нужно закладывать в расчет риска как компонент ущерба.

Операционный риск ИБ — вероятность и ущерб от самого инцидента (простой, потеря данных, мошеннические операции, восстановление систем), рассчитываемый независимо от того, есть ли по данному сценарию регуляторное требование. В финансовом секторе это закреплено напрямую: положение № 716-П обязывает кредитную организацию вести систему управления операционным риском, где риск ИБ — один из источников операционного риска, а положение № 851-П требует оценивать соответствие ГОСТ Р 57 580.1−2017 именно как механизм снижения этого риска, напрямую влияющий на резервирование капитала под покрытие потерь.

Операционный риск ИБ — вероятность и ущерб от самого инцидента (простой, потеря данных, мошеннические операции, восстановление систем), рассчитываемый независимо от того, есть ли по данному сценарию регуляторное требование. В финансовом секторе это закреплено напрямую: положение № 716-П обязывает кредитную организацию вести систему управления операционным риском, где риск ИБ — один из источников операционного риска, а положение № 851-П требует оценивать соответствие ГОСТ Р 57 580.1−2017 именно как механизм снижения этого риска, напрямую влияющий на резервирование капитала под покрытие потерь.

Смешение этих двух рисков в одной строке реестра — типичная методологическая ошибка. Формула количественной оценки совокупного ожидаемого ущерба (ALE) должна учитывать оба компонента отдельно:

Пример расчета для банка, обрабатывающего 50 000 клиентских записей, при риске утечки клиентской базы через уязвимость в программный интерфейс взаимодействия (API):

Эта цифра — не украшение отчета, а прямой аргумент для обоснования бюджета на контроль: МЭ уровня приложений (WAF) и сегментация программного интерфейса взаимодействия (API) стоимостью 3−4 млн руб в год окупаются уже в первый год, если снижают ожидаемую частоту реализации угрозы в год (ARO) хотя бы вдвое. Именно так риск-ориентированный подход конвертируется в решение о финансировании, а не остается качественной шкалой «высокий/средний/низкий», ничего не говорящей финансовому директору.

Слой 3. Контроли: почему один контроль должен закрывать несколько строк сразу

Матрица соответствия рисков и контролей (RCM, Risk-Control Matrix) — рабочий инструмент, физически связывающий три слоя. Принцип «один контроль — множество привязок» («one control — many mappings») означает, что при проектировании контроля сразу нужно фиксировать все требования и риски, которые он покрывает, — иначе тот же контроль будет спроектирован повторно другим подразделением под другой стандарт.

Пример матрицы для финансовой организации, где один технический контроль закрывает несколько независимых нормативных требований одновременно:

Последний пример показывает суть межконтурного анализа: процедура реагирования на инцидент должна с самого начала маршрутизировать событие в оба уведомительных потока — ГосСОПКА/ФСБ России (в сфере КИИ) и Роскомнадзор (если затронуты ПДн), — потому что 24-часовой срок по 152-ФЗ и срок уведомления ФСБ России по приказу ФСБ России № 547 (3 часа для значимых объектов КИИ, 24 часа для остальных субъектов КИИ и информационных ресурсов государственных органов) текут параллельно и не заменяют друг друга. Организации, выстраивающие сценарии действий при реагировании на инцидент только под один контур, систематически получают штраф по второму — это не гипотетический, а массово наблюдаемый на практике сценарий.

Аудит: не «есть документ», а проверка проектной эффективности контроля vs фактической эффективности его применения

Аудит ИБ в парадигме SGRC проверяет не факт существования политики, а три отдельные, аналитически различимые вещи:

1. Проектная эффективность контроля — контроль спроектирован так, что при штатной работе действительно закрывает риск и требование (а не подобран под требование постфактум, без анализа угрозы).

2. Фактическая эффективность применения — контроль реально исполняется в проверяемый период, а не описан в регламенте и забыт. Типичный источник расхождения: политика согласования доступа существует, но выборка заявок за квартал показывает, что 30% доступов выданы без утверждения.

3. Актуальность связи — при изменении инфраструктуры (миграция в облако, новый программный интерфейс, слияние систем после сделки по слиянию и поглощению) или изменении нормативных требований (например, ужесточение 152-ФЗ в мае 2025 года) матрица соответствия обновлена, а не осталась артефактом прошлогоднего цикла.

Практика ФСТЭК России по итогам контрольно-надзорной деятельности на объектах КИИ фиксирует типовой набор нарушений, прямо иллюстрирующий разрыв слоев:

Все три нарушения — это не отсутствие документов, а разрыв конкретно тех связей, которые призвана поддерживать модель SGRC.

Полезный организационный принцип для аудита — модель трех линий защиты:

Смешение линий — например, когда служба ИБ сама себе присваивает статус соответствия без независимой проверки — обесценивает весь аудиторский цикл, даже если по внутренней отчетности контроль числится закрытым.

Где на практике рвется связка: пять типовых разрывов

Разрывы между слоями не возникают случайно. Они образуются в предсказуемых точках организационной структуры, и практика аудита из года в год фиксирует одни и те же паттерны.

Самый частый — требования без владельца связки: пункт закрыт контролем, но ответственность закреплена за отдельным элементом, например, за системой, а не за целостностью цепочки «требование-риск-контроль-свидетельство». При смене архитектуры контроль перестает закрывать требование, но формально никто не обязан это заметить.

Рядом с этим почти всегда соседствует дублирование контролей между контурами: ИБ-департамент внедряет меры под ГОСТ Р 57 580.1, юристы параллельно закрывают 152-ФЗ, а отдельное подразделение, отвечающее за категорирование и защиту объектов КИИ, — свой контур по 187-ФЗ, не зная, что 60−80% технических мер пересекаются между всеми тремя. Итог — рост стоимости владения без роста защищенности и три параллельных, несинхронизированных версии одной и той же процедуры.

Третий паттерн лежит уже не в структуре контролей, а в процессе управления — это риск-реестр, оторванный от графика аудита: риски переоцениваются раз в год на бумаге, а аудит фактического состояния контролей идет по собственному календарю. В результате приоритеты аудиторской выборки не соответствуют актуальной карте рисков.

Четвертый разрыв проявляется в момент реального инцидента, а не на этапе планирования: реагирование, не покрывающее все применимые контуры одновременно. Пример с параллельными уведомлениями ГосСОПКА и Роскомнадзора — системная причина штрафов при технически корректном, но процедурно неполном реагировании.

И наконец, пятый разрыв возникает уже после того, как контроль внедрен, — это отсутствие пересчета остаточного риска. Статус в реестре — «выполнено», но никто не оценил, насколько снизилась вероятность или ущерб.

Практические рекомендации

Пять разрывов, разобранных выше, возникают не случайно – это прямое следствие того, что требования, риски и контроли ведутся тремя независимыми функциями. Рекомендации ниже адресуют не абстрактную «зрелость ИБ», а конкретно эти разрывы и сгруппированы по трем уровням.

Итог

Модель SGRC работает не как дополнительный слой бюрократии, а как механизм, который делает три параллельных вида работы — юридическую, риск-аналитическую и техническую — единым процессом с прослеживаемыми связями в обе стороны. В российской практике это особенно критично из-за многоконтурности регулирования: одна и та же информационная система нередко одновременно подпадает под 152-ФЗ, 187-ФЗ и отраслевые требования Банка России, а санкции за разрыв связки в 2025—2026 годах перестали быть символическими — оборотные штрафы до 500 млн ₽ и уголовная ответственность по ст. 274.1 и 272.1 УК РФ делают формальный, несвязанный комплаенс не просто неэффективным, а прямо опасным для бизнеса. Аудит в этой модели — не проверка наличия документов, а верификация того, что граф «требование-риск-контроль» остается целостным, актуальным и работоспособным на момент проверки, а не только на момент его первоначального построения.