С 1 сентября 2026 года российская система регулирования безопасности персональных данных фундаментально трансформируется. Приказ ФСТЭК России, утвержденный в июле 2026 года, прекращает действие приказа № 21 от 18 февраля 2013 года и всех последующих изменений, включая поправки 2017 и 2020 годов. Это не просто обновление технического регламента, а смена парадигмы: от статического выполнения перечня мер к динамическому управлению уровнем зрелости системы защиты. Регулятор фиксирует, что наличие бумажных политик и установленных средств защиты само по себе не гарантирует безопасность. Требуется доказательство эффективности через измеряемый показатель. Новая архитектура регулирования строится на принципе непрерывного цикла: оценка угроз, выбор мер, их адаптация, внедрение, проверка эффективности и корректировка. Этот цикл должен быть встроен в бизнес-процессы оператора, а не существовать как отдельная бюрократическая функция.
Юридическая база нового приказа опирается на часть 4 статьи 19 Федерального закона № 152-ФЗ «О персональных данных» и Положение о ФСТЭК России. Документ является подзаконным актом прямого действия, обязательным для всех операторов информационных систем персональных данных, независимо от формы собственности и объема обрабатываемых данных. Важно понимать иерархию норм: требования к уровням защищенности остаются в ведении постановления Правительства № 1119, а состав и содержание мер теперь регулируются исключительно новым приказом. Для государственных информационных систем действуют специальные требования приказа ФСТЭК № 117 от 11 апреля 2025 года, что создает дифференцированный подход к регулированию. Системы, содержащие государственную тайну, выводятся из-под действия данного приказа и регулируются отдельными нормами по технической защите гостайны. Значимые объекты критической информационной инфраструктуры должны выполнять требования одновременно по двум контурам: по закону № 187-ФЗ и по новому приказу ФСТЭК, что требует гармонизации мер и устранения противоречий.
Показатель уровня зрелости Узи становится центральным элементом новой архитектуры. Он заменяет собой субъективные оценки «соответствует/не соответствует». Теперь оператор должен оперировать количественными или качественными метриками, характеризующими достаточность и эффективность реализованных мер. Методика расчета этого показателя утверждается ФСТЭК России в отдельных методических документах. Отсутствие опубликованной методики на момент выхода приказа создает временный лаг, но не освобождает от обязанности готовиться к оценке. Операторам следует мониторить публикации ведомства и участвовать в профессиональных обсуждениях для формирования понимания ожидаемых метрик. Введение показателя Узи синхронизирует российские требования с международными стандартами зрелости, такими как CMMI for Services или NIST Cybersecurity Framework, адаптируя их под национальную специфику и угрозы.
Взаимосвязь нового приказа с существующей нормативной базой требует внимательного анализа. Статья 18.1 закона № 152-ФЗ обязывает оператора принимать меры, необходимые для выполнения обязанностей, предусмотренных законом. Новый приказ детализирует эти меры. Политика в отношении обработки персональных данных должна быть актуализирована с учетом нового состава мер. Это не формальная правка документа, а пересмотр стратегии защиты. Если ранее политика могла содержать общие фразы, то теперь она должна фиксировать конкретный состав мер, выбранный оператором с учетом актуальных угроз и применяемых технологий. Изменение политики должно сопровождаться уведомлением субъектов ПДн, если изменения затрагивают их права и свободы, хотя технические меры защиты обычно не требуют такого уведомления. Однако прозрачность подхода к безопасности становится конкурентным преимуществом и фактором доверия.
Для финансовых организаций и бухгалтерских служб, работающих с большими массивами чувствительных данных, новый приказ означает необходимость интеграции требований ФСТЭК в системы внутреннего контроля. Бухгалтерский учет и финансовая отчетность напрямую зависят от целостности и конфиденциальности данных. Утрата контроля над ПДн может привести не только к штрафам Роскомнадзора, но и к репутационным потерям, отзыву лицензии или искам клиентов. Поэтому внедрение новых требований должно рассматриваться не как накладной расход, а как инвестиция в устойчивость бизнеса. Опыт показывает, что организации, проактивно внедряющие зрелостные модели, быстрее проходят проверки и эффективнее реагируют на инциденты. Переходный период до 1 сентября 2026 года дает время на планомерную подготовку, но откладывать аудит на последний квартал опасно из-за возможного дефицита ресурсов лицензиатов и экспертов.
Показатель уровня зрелости Узи как центральный метрический стандарт
Введение показателя уровня зрелости Узи является наиболее значимым нововведением приказа. Этот показатель характеризует достаточность и эффективность реализованных мер по обеспечению безопасности персональных данных. Термин «зрелость» подразумевает, что безопасность — это не состояние, а процесс развития. Система может иметь все необходимые средства защиты, но если процессы их эксплуатации не отлажены, персонал не обучен, а мониторинг ведется формально, уровень зрелости будет низким. И наоборот, система с меньшим набором технических средств, но выстроенными процессами управления рисками, может демонстрировать высокую зрелость. Методические документы ФСТЭК России, на которые ссылается пункт 9 приложения, станут ключевым руководством по расчету Узи. До их официального выхода операторам рекомендуется использовать лучшие практики и отраслевые стандарты для предварительной самооценки.
Регламент проведения оценки строго определен. Первая оценка проводится перед началом обработки персональных данных в информационной системе. Это означает, что ни одна новая ИСПДн не может быть введена в эксплуатацию без подтверждения достигнутого уровня зрелости. Для действующих систем первая оценка по новым правилам должна быть проведена в разумные сроки после вступления приказа в силу, чтобы подтвердить соответствие. Далее оценка проводится не реже одного раза в три года. Этот цикл совпадает с типичным горизонтом планирования ИБ и позволяет отслеживать динамику. Третий триггер оценки — компьютерный инцидент. После любого подтвержденного инцидента оператор обязан провести внеплановую оценку. Это требование направлено на проверку того, был ли инцидент следствием недостаточности мер или случайным событием, и насколько система способна противостоять повторным атакам. Внеплановая оценка не заменяет плановую, а дополняет ее.
Роль лицензиатов ФСТЭК в процедуре оценки существенно возрастает. Пункт 9 прямо предусматривает возможность привлечения юридических лиц или индивидуальных предпринимателей, имеющих лицензию на техническую защиту конфиденциальной информации. Хотя оператор может проводить оценку самостоятельно, сложность методики и ответственность за результат делают привлечение внешних экспертов предпочтительным для большинства организаций. Лицензиат выступает независимым арбитром, подтверждающим объективность оценки. Для операторов, не обладающих внутренними компетенциями, сотрудничество с лицензиатом становится обязательным условием соблюдения требований. Важно выбирать партнера не по минимальной цене, а по опыту работы с аналогичными информационными системами и знанию специфики отрасли. Договор с лицензиатом должен четко определять объем работ, методику оценки и формат отчетности.
Критерии достаточности и эффективности мер защиты теперь неразрывно связаны с показателем Узи. Достаточность означает, что выбранный набор мер способен нейтрализовать актуальные угрозы. Эффективность означает, что эти меры работают так, как задумано, и дают измеримый результат. Например, установленный антивирус — это мера. Но если базы сигнатур не обновляются месяц, а алерты игнорируются администратором, эффективность меры равна нулю. Показатель Узи должен агрегировать такие нюансы. Ожидается, что методика будет включать как количественные метрики (процент закрытых уязвимостей, время реакции на инцидент, покрытие мониторингом), так и качественные оценки (уровень осведомленности персонала, качество документации). Комбинация этих параметров даст интегральную картину зрелости.
Документирование результатов оценки является критически важным элементом. Отчет об оценке Узи становится основным доказательством выполнения требований закона при проверках регулятора. В нем должны быть зафиксированы исходные данные, примененная методика, выявленные недостатки, достигнутые значения показателей и рекомендации по улучшению. Отчет должен храниться в течение установленного срока и предоставляться по запросу ФСТЭК или Роскомнадзора. Прозрачность процесса оценки внутри организации также важна. Результаты должны доводиться до руководства для принятия решений по финансированию и развитию системы защиты. Без поддержки топ-менеджмента повышение уровня зрелости невозможно. Показатель Узи переводит разговор о безопасности с языка технических терминов на язык бизнес-метрик, понятных директорам и собственникам.
Расширенная таксономия организационных и технических мер
Новый приказ существенно расширяет и детализирует перечень мер по обеспечению безопасности персональных данных. Пункт 11 приложения перечисляет организационные меры, а пункт 12 — технические. Этот список является исчерпывающим базовым набором, из которого оператор формирует свой профиль защиты. Появление новых категорий мер отражает эволюцию технологического ландшафта и угроз. Контроль конфигураций информационных систем выделяется в отдельную меру. Это признание того, что дрейф конфигураций является одной из главных причин уязвимостей. Оператор должен иметь эталонные образы конфигураций, регулярно проверять соответствие систем этим образам и оперативно устранять отклонения. Автоматизация контроля конфигураций становится стандартом де-факто. Ручная проверка сотен серверов и рабочих станций невозможна в современных условиях.
Управление уязвимостями и управление обновлениями разделены на две самостоятельные меры. Это подчеркивает разницу между процессами. Управление уязвимостями включает инвентаризацию активов, сканирование, приоритизацию и верификацию устранения. Управление обновлениями фокусируется на безопасном развертывании патчей, тестировании совместимости и откате при сбоях. Обе меры требуют налаженных процессов и инструментов. В финансовой сфере, где доступность систем критична, обновление часто откладывается из-за страха нарушить работу. Новый приказ требует найти баланс между безопасностью и доступностью, используя компенсирующие меры, если немедленное обновление невозможно. Игнорирование уязвимостей больше не может оправдываться операционными рисками без официальной компенсации.
Защита виртуализации, облачных вычислений и контейнерных сред вынесена в отдельные пункты. Традиционные меры защиты периметра недостаточно эффективны в средах, где границы размыты. Требуется защита гипервизора, изоляция виртуальных машин, контроль трафика east-west, безопасность образов контейнеров и оркестраторов. Для организаций, мигрирующих в облака или использующих гибридную инфраструктуру, это означает необходимость пересмотра архитектуры защиты. Облачные провайдеры предоставляют базовую безопасность платформы, но безопасность данных и приложений остается ответственностью клиента. Модель shared responsibility должна быть четко задокументирована и реализована технически. Защита сервисов электронной почты и веб-технологий также получила отдельный статус. Почта остается основным вектором фишинга и целевых атак. Веб-приложения — главной мишенью для эксплойтов. Требуются специализированные средства защиты: WAF, шлюзы безопасности почты, песочницы для анализа вложений.
Защита программных интерфейсов взаимодействия приложений (API) признана самостоятельной мерой. В эпоху микросервисов и интеграций API становятся новой поверхностью атаки. Небезопасные API позволяют обойти защиту фронтенда и получить прямой доступ к данным. Необходима инвентаризация всех API, аутентификация и авторизация вызовов, ограничение частоты запросов, валидация входных данных и мониторинг аномальной активности. Стандарты OWASP API Security Top 10 должны стать ориентиром для реализации этой меры. Защита технологий интернета вещей (IoT) включена в перечень с учетом роста числа подключенных устройств в офисах и на производстве. Камеры наблюдения, принтеры, датчики, умные устройства часто имеют слабую защиту и используются как точка входа в сеть. Требуется сегментация IoT-сетей, контроль доступа, регулярное обновление прошивок и отказ от дефолтных паролей.
Мониторинг информационной безопасности трансформируется из опциональной функции в обязательную меру. Недостаточно просто собирать логи. Требуется их анализ, корреляция событий, выявление аномалий и оперативное реагирование. SIEM-системы становятся обязательным элементом инфраструктуры для большинства операторов. Требования к мониторингу должны учитывать объем данных и критичность систем. Для малых систем может быть достаточно базового анализа логов, для крупных — полноценного SOC. Непрерывное функционирование информационных систем при возникновении нештатных ситуаций требует планов аварийного восстановления, регулярного резервного копирования и тестирования восстановления. Резервные копии должны быть защищены от модификации и удаления, в том числе при ransomware-атаках. Физическая защита остается фундаментом, но ее содержание адаптируется к современным реалиям: контроль доступа в ЦОД, защита стоек, контроль съемных носителей.
Искусственный интеллект как новый объект регулирования ФСТЭК
Включение защиты информации при использовании искусственного интеллекта в перечень мер является знаковым событием. Россия стала одним из первых регуляторов, явно потребовавших защиты ПДн в контексте ИИ. Это реакция на массовое внедрение генеративных моделей и систем машинного обучения в бизнес-процессы. Риски ИИ многогранны: утечка данных через обучение моделей, манипуляция результатами работы ИИ, использование ИИ для создания фишинговых материалов, непредсказуемость поведения моделей. Новый приказ требует от оператора осознавать эти риски и принимать меры по их нейтрализации. Конкретное содержание мер будет зависеть от типа используемого ИИ и характера обрабатываемых данных. Для чат-ботов поддержки клиентов, обрабатывающих обращения граждан, требования будут отличаться от требований к системам скоринга в банке.
Верификация моделей и контроль обучающих выборок становятся критическими задачами. Оператор должен убедиться, что модель обучена на легитимных данных, не содержит смещений и не воспроизводит конфиденциальную информацию. Требуется контроль целостности обучающих данных и защита от data poisoning. При использовании сторонних моделей необходимо оценивать риски supply chain. Открытые модели могут содержать бэкдоры или уязвимости. Локальное развертывание моделей снижает риски утечки, но требует собственных вычислительных ресурсов и экспертизы. Использование облачных API ИИ передает данные третьей стороне, что требует отдельной оценки рисков и договорного регулирования. Новый приказ стимулирует развитие локальных решений и суверенных моделей ИИ, что соответствует общему тренду на технологическую независимость.
Компенсирующие меры для систем ИИ приобретают особое значение. Технологии развиваются быстрее, чем стандарты защиты. Для многих сценариев использования ИИ еще не существует сертифицированных средств защиты. Оператор вправе применять компенсирующие меры, но должен обосновать их достаточность. Например, если невозможно технически обеспечить анонимизацию данных для обучения модели, можно применить усиленный контроль доступа, мониторинг использования модели и юридические ограничения на вывод результатов. Обоснование должно быть документировано и утверждено руководством. Регулятор ожидает ответственного подхода, а не формальных отписок. Практика покажет, какие компенсирующие меры будут признаны приемлемыми. Диалог с ФСТЭК и отраслевыми ассоциациями поможет сформировать пул одобренных практик.
Практические аспекты внедрения безопасного ИИ в финансовом секторе требуют особого внимания. Банки и страховые компании активно используют ИИ для скоринга, фрод-мониторинга, персонализации услуг. Ошибки в этих системах могут привести к дискриминации клиентов, финансовым потерям и регуляторным санкциям. Требуется explainability (объяснимость) решений ИИ, особенно тех, которые влияют на права граждан. Черный ящик недопустим в регулируемых отраслях. Система должна предоставлять понятное объяснение принятого решения. Также требуется регулярный аудит моделей на предмет дрейфа данных и деградации качества. Человеческий контроль над критическими решениями ИИ остается обязательным. Автоматизация не должна означать снятие ответственности. Человек в контуре (human-in-the-loop) является важнейшей компенсирующей мерой.
Разработка безопасного программного обеспечения с учетом ИИ также попадает в фокус. Если оператор разрабатывает собственные модели или интегрирует ИИ в свои продукты, он должен следовать требованиям ГОСТ Р 56939-2024. Безопасность должна быть заложена на этапе проектирования. Тестирование на уязвимости должно включать проверку специфических для ИИ атак. Документация должна описывать ограничения модели и известные риски. Обучение разработчиков и data scientists основам ИБ становится обязательным. Разрыв между командами ML и ИБ должен быть преодолен. Совместные рабочие группы и cross-functional review помогают выявить риски на ранних стадиях. Культура безопасности в AI-командах формируется годами, но начинать нужно сейчас.
Адаптация базовых мер и институт компенсирующих механизмов
Процесс выбора мер по обеспечению безопасности персональных данных в новом приказе структурирован как трехэтапный алгоритм: определение базовых мер, адаптация, верификация. Базовые меры определяются для установленного уровня защищенности персональных данных (УЗ ПДн). Это отправная точка, гарантирующая минимально необходимый уровень защиты. Однако слепое копирование базового набора без учета специфики системы неэффективно и экономически нецелесообразно. Адаптация предполагает изменение состава и содержания мер применительно к архитектуре ИСПДн, применяемым технологиям и особенностям функционирования. Например, для системы, работающей только в локальной сети без доступа в интернет, меры по защите удаленного доступа могут быть исключены или существенно упрощены. Для облачной системы, напротив, они будут усилены.
Верификация адаптированного набора мер — это проверка на соответствие актуальным угрозам и возможностям нарушителей. Модель угроз, разработанная оператором, служит фильтром для верификации. Если модель выявляет угрозу, для которой в адаптированном наборе нет меры, набор должен быть дополнен. Если мера избыточна относительно актуальных угроз, она может быть ослаблена или исключена. Верификация требует глубокого понимания тактик, техник и процедур (TTPs) нарушителей. Методические документы ФСТЭК и базы знаний об угрозах (например, MITRE ATT&CK) являются источниками информации для верификации. Этот этап превращает защиту из шаблонной в риск-ориентированную. Результатом верификации является финальный перечень мер, который фиксируется в политике обработки ПДн.
Институт компенсирующих мер является предохранительным клапаном системы. Пункт 14 приложения разрешает разработку иных мер, если реализация выбранных базовых или адаптированных мер невозможна технически или экономически нецелесообразна. Это признание реальности: идеальная защита недостижима. Компенсирующая мера должна быть направлена на нейтрализацию той же угрозы, что и нереализуемая базовая мера. Она не обязательно должна быть идентичной по механизму, но должна быть эквивалентной по эффекту. Например, если невозможно установить агентский антивирус на legacy-оборудование, компенсирующей мерой может быть сетевой мониторинг трафика этого оборудования на наличие вредоносной активности и строгая сегментация сети. Обоснование применения компенсирующих мер является обязательным документом. В нем должны быть указаны причина невозможности реализации базовой меры, описание компенсирующей меры и доказательство ее эффективности.
Обоснование экономической целесообразности требует осторожности. Нельзя просто написать «дорого». Нужно показать расчет стоимости внедрения базовой меры, оценку ущерба от реализации угрозы и стоимость компенсирующей меры. Если стоимость базовой меры превышает потенциальный ущерб в разы, а компенсирующая мера снижает риск до приемлемого уровня за разумные деньги, обоснование будет принято. Регулятор ожидает рационального подхода, а не желания сэкономить на безопасности. Документирование компенсирующих мер в политике обработки ПДн обеспечивает прозрачность. При проверке инспектор увидит не отсутствие меры, а осознанное решение оператора с обоснованием. Это переводит разговор из плоскости нарушений в плоскость управления рисками. Отсутствие обоснования равносильно отсутствию меры и является нарушением.
Риски необоснованного применения компенсаций высоки. Соблазн заменить сложные и дорогие меры простыми и дешевыми велик. Но если компенсирующая мера не обеспечивает реальной защиты, оператор несет полную ответственность при инциденте. Суд и регулятор будут оценивать не наличие бумаги с обоснованием, а реальную способность системы противостоять угрозам. Формальный подход к компенсациям — путь к санкциям. Рекомендуется проводить экспертизу обоснований компенсирующих мер, возможно, с привлечением внешних специалистов. Коллективное обсуждение помогает выявить слабые места. Компенсирующие меры должны регулярно пересматриваться. То, что было невозможно вчера, может стать возможным завтра благодаря новым технологиям. Гибкость системы защиты не должна превращаться в ее слабость.
Ужесточение требований к средствам защиты информации
Пункт 16 приложения устанавливает четкую матрицу требований к средствам защиты информации (СЗИ) в зависимости от уровня защищенности персональных данных. Для ИСПДн 1 уровня требуются СЗИ не ниже 4 класса и 4 уровня доверия. Для 2 уровня — не ниже 5 класса и 5 уровня доверия. Для 3 и 4 уровней — 6 класс и 6 уровень доверия. Эта привязка устраняет двусмысленности предыдущего регулирования. Классы защиты определяются нормативными актами ФСТЭК, а уровни доверия — приказом № 76 от 2 июня 2020 года с изменениями. Уровень доверия характеризует степень уверенности в отсутствии недекларированных возможностей и уязвимостей в СЗИ. Высокий уровень доверия достигается через сертификацию, контроль разработки и анализ исходного кода.
Применение сертифицированных СЗИ является обязательным для нейтрализации актуальных угроз, если это необходимо. Формулировка «в случаях, когда применение таких средств необходимо» оставляет пространство для маневра, но на практике регулятор трактует ее широко. Если угроза актуальна и для ее нейтрализации существует сертифицированное средство, оно должно быть применено. Использование несертифицированных средств допускается только при отсутствии сертифицированных аналогов или при применении компенсирующих мер с надлежащим обоснованием. В реестре отечественного ПО и реестре сертифицированных СЗИ регулярно появляются новые продукты. Операторам следует мониторить эти реестры для планирования закупок. Импортозамещение в сфере ИБ стало неотъемлемой частью требований. Зарубежные СЗИ без российской сертификации не могут использоваться для защиты ПДн в государственных системах и на значимых объектах КИИ, а для коммерческих операторов их использование сопряжено с высокими рисками несоответствия.
Оценка соответствия СЗИ проводится в установленном порядке. Сертификация — длительный и дорогой процесс для вендоров, но гарантия качества для операторов. При выборе СЗИ следует проверять наличие действующего сертификата ФСТЭК, его срок действия и область применения. Сертификат может ограничивать условия применения средства (например, только в составе определенного ПО или в определенных конфигурациях). Нарушение условий применения аннулирует соответствие. Обновление сертифицированных СЗИ также требует внимания. Новые версии могут требовать ресертификации или подтверждения соответствия. Оператор должен отслеживать уведомления вендоров и ФСТЭК об изменениях в статусе сертификатов. Использование просроченных или отозванных сертификатов равносильно использованию несертифицированного ПО.
Криптографическая защита информации находится в ведении ФСБ России. Новый приказ ФСТЭК не регулирует вопросы криптографии напрямую, но ссылается на требования ФСБ. При использовании шифрования для защиты ПДн оператор должен выполнять оба набора требований. Это создает двойную нагрузку, но обеспечивает комплексную защиту. Согласование требований ФСТЭК и ФСБ иногда вызывает сложности на практике. Например, сертифицированное СЗИ может иметь встроенную криптографию, сертифицированную ФСБ, но сам продукт сертифицирован ФСТЭК по другому профилю. Важно убедиться, что все компоненты системы соответствуют требованиям обоих регуляторов. Консультации с лицензиатами, имеющими опыт работы с обоими ведомствами, помогают избежать ошибок.
Требования к уровням доверия стимулируют развитие отечественной индустрии ИБ. Создание СЗИ высокого уровня доверия требует доступа к исходному коду, контроля производственной цепочки и глубокого анализа. Это барьер для непроверенных продуктов, но и стимул для серьезных вендоров. Операторы, выбирающие продукты высокого уровня доверия, снижают риски supply chain атак. В условиях геополитической напряженности этот аспект становится критическим. Доверие к ПО больше не может основываться только на репутации бренда. Оно должно быть подтверждено независимой оценкой. Переход на отечественные СЗИ высокого уровня доверия — стратегическая задача для каждого оператора, обрабатывающего ПДн. Рынок адаптируется к новым требованиям, предлагая решения для различных сегментов и бюджетов.
Сквозной контроль подрядчиков и третьих лиц
Новый приказ возлагает на оператора прямую обязанность устанавливать требования к показателю уровня зрелости Узи для лиц, осуществляющих обработку персональных данных по его поручению. Это прорыв в регулировании цепочки поставок данных. Ранее ответственность оператора за действия подрядчика была декларативной. Теперь она подкреплена конкретным метрическим требованием. Оператор не может просто включить в договор пункт о соблюдении закона № 152-ФЗ. Он должен указать конкретное целевое значение Узи, которое подрядчик обязан достичь и поддерживать. Это значение должно быть не ниже, чем у самого оператора, если подрядчик обрабатывает те же категории данных в аналогичных условиях. Делегирование обработки не делегирует ответственность за уровень зрелости защиты.
Периодичность проверки подрядчиков установлена жестко: перед началом обработки, далее не реже одного раза в три года и после компьютерного инцидента у подрядчика. Это зеркально отражает требования к самому оператору. Оператор должен иметь механизм получения достоверной информации об уровне зрелости подрядчика. Запрос справки или отчета об оценке Узи становится стандартной процедурой due diligence. Право на аудит подрядчика должно быть закреплено в договоре. Аудит может проводиться силами оператора или привлеченным лицензиатом. Отказ подрядчика от предоставления информации или проведения аудита должен рассматриваться как критический риск и основание для пересмотра отношений. Работа с непрозрачными подрядчиками недопустима.
Договорные механизмы фиксации требований к зрелости требуют юридической точности. В договоре поручения обработки ПДн должны быть указаны: целевой показатель Узи, методика его оценки, порядок предоставления отчетности, право на аудит, санкции за несоответствие, обязанность уведомления об инцидентах. Эти условия должны быть согласованы до начала передачи данных. Существующие договоры подлежат приведению в соответствие с новыми требованиями. Это масштабная юридическая и организационная задача. Шаблонные договоры из интернета не подходят. Требуется индивидуальная проработка с учетом специфики услуг и рисков. Юристы и специалисты по ИБ должны работать совместно. Технические требования должны быть переведены на язык юридических обязательств.
Ответственность за инциденты у подрядчика остается на операторе перед субъектами ПДн и регулятором. Но оператор имеет право регрессного требования к подрядчику, если инцидент произошел по его вине. Четкая фиксация требований к Узи в договоре укрепляет позицию оператора в спорах. Если подрядчик не достиг установленного уровня зрелости и это привело к утечке, его вина очевидна. Если же подрядчик выполнял все требования, а инцидент произошел из-за непреодолимой силы или действий самого оператора, ответственность распределяется иначе. Прозрачность и документирование — ключ к управлению ответственностью. Страхование киберрисков также может быть инструментом компенсации убытков, но страховщики все чаще требуют подтверждения уровня зрелости защиты как условия выплаты.
Интеграция требований к Узи в SLA и договоры оказания услуг трансформирует рынок аутсорсинга. Провайдеры облачных услуг, хостинга, технической поддержки, разработки ПО должны адаптироваться к новым требованиям. Те, кто не сможет подтвердить уровень зрелости, потеряют клиентов. Рынок очищается от недобросовестных игроков. Для добросовестных провайдеров это возможность дифференцироваться и обосновать цену. Сертификаты соответствия, отчеты об аудите, публичные политики безопасности становятся маркетинговыми активами. Операторы, выбирая подрядчиков, должны смотреть не только на цену, но и на зрелость защиты. Дешевый сервис с низкой зрелостью обойдется дороже в случае инцидента. Экономика безопасности диктует новые правила конкуренции.
Взаимодействие с ГосСОПКА и реагирование на инциденты
Непрерывное взаимодействие с государственной системой обнаружения, предупреждения и ликвидации последствий компьютерных атак (ГосСОПКА) закреплено как обязательная мера. Это не просто техническое подключение, а процесс обмена информацией об угрозах и инцидентах. Субъекты КИИ уже обязаны взаимодействовать с ГосСОПКА по закону № 187-ФЗ. Новый приказ распространяет эту практику на всех операторов ПДн, даже если они не являются субъектами КИИ. Цель — формирование единой картины киберугроз в стране и оперативное оповещение о новых атаках. Техническая реализация взаимодействия может осуществляться через ведомственные центры ГосСОПКА или напрямую через НКЦКИ. Форматы и протоколы обмена данными регламентируются ФСТЭК.
Порядок уведомления о компьютерных инцидентах имеет строгие сроки. Для субъектов КИИ они установлены законодательно. Для иных операторов ПДн сроки и порядок определяются методическими документами ФСТЭК и условиями взаимодействия с ГосСОПКА. Даже если оператор не обязан сообщать об инциденте в обязательном порядке, добровольное взаимодействие поощряется и способствует получению обратной связи от регулятора. Сокрытие инцидентов —стратегия с высоким уровнем риска. При последующей проверке сокрытие будет квалифицировано как нарушение требований по мониторингу и реагированию. Прозрачность и сотрудничество с регулятором снижают репутационные и юридические риски. ГосСОПКА предоставляет индикаторы компрометации, данные о тактиках атакующих и рекомендации по защите. Это ценный ресурс для повышения уровня зрелости.
Корреляция между инцидентом и внеплановой оценкой Узи создает петлю обратной связи. Каждый инцидент — это тест системы защиты в реальных условиях. Если инцидент произошел, значит, система имела пробелы. Внеплановая оценка должна выявить эти пробелы и инициировать корректирующие действия. Результаты оценки должны лечь в основу плана remediation. Просто восстановить систему после атаки недостаточно. Нужно изменить систему так, чтобы подобная атака не повторилась. Регулятор будет проверять не только факт проведения внеплановой оценки, но и выполнение рекомендаций по ее итогам. Отсутствие действий после оценки равносильно отсутствию самой оценки. Цикл «инцидент — оценка — улучшение» должен быть замкнут.
Техническая реализация обмена данными с НКЦКИ требует интеграции систем мониторинга оператора с платформой ГосСОПКА. Автоматизация обмена снижает нагрузку на персонал и ускоряет реакцию. Ручная отправка отчетов по почте устарела. Современные платформы ИБ поддерживают интеграцию с ГосСОПКА из коробки. При выборе SIEM или SOAR-системы следует проверять наличие такой интеграции. Настройка правил корреляции для выявления инцидентов, подлежащих уведомлению, требует экспертизы. Ложные срабатывания перегружают канал, пропуск реальных инцидентов ведет к санкциям. Баланс чувствительности и специфичности настраивается итеративно. Тестирование взаимодействия с ГосСОПКА должно проводиться регулярно, как учения по пожарной безопасности.
Практика построения процессов IRP (Incident Response Plan) в соответствии с новыми требованиями должна учитывать роль ГосСОПКА. План реагирования должен включать этапы уведомления регулятора, получения консультаций и предоставления отчетности. Роли и ответственности в команде IRP должны быть распределены. Коммуникация с регулятором — отдельная функция, требующая навыков деловой переписки и знания регламентов. Юридический отдел должен быть вовлечен в процесс реагирования с самого начала. Фиксация всех действий во время инцидента критически важна для последующего разбора и отчетности. Пост-инцидентный анализ (post-mortem) должен быть обязательной процедурой. Уроки, извлеченные из инцидентов, — самый ценный актив для повышения зрелости. Культура blameless post-mortem, где ищут системные причины, а не виноватых, способствует открытости и обучению.
Жизненный цикл системы защиты и безопасная разработка
Стадии жизненного цикла информационных систем регулируются ГОСТ Р 51583-2014. Новый приказ делает ссылку на этот стандарт обязательной. Безопасность должна быть встроена в систему с этапа проектирования, а не добавлена постфактум. На этапе формирования требований к ИСПДн должны быть определены требования к защите ПДн. На этапе проектирования должна быть разработана модель угроз и выбраны меры защиты. На этапе разработки и внедрения должны быть реализованы выбранные меры и проведены испытания. На этапе эксплуатации должна проводиться оценка эффективности и мониторинг. На этапе вывода из эксплуатации должно быть обеспечено безопасное уничтожение данных. Игнорирование стадий жизненного цикла ведет к накоплению технического долга в безопасности, который дорого исправлять.
Разработка безопасного программного обеспечения регулируется ГОСТ Р 56939-2024. Этот стандарт стал обязательным ориентиром для операторов, разрабатывающих собственное ПО или заказывающих разработку. Требования стандарта охватывают весь цикл SDLC: управление требованиями, безопасное проектирование, безопасное кодирование, тестирование безопасности, управление уязвимостями в выпущенном ПО. Применение стандарта снижает количество уязвимостей в продукте. Для заказчиков ПО требование соответствия ГОСТ Р 56939-2024 должно быть включено в техническое задание и договор. Приемка ПО должна включать тестирование безопасности и анализ кода. Слепое доверие разработчику недопустимо. Независимый аудит кода — лучшая страховка.
Проверка системного и прикладного программного обеспечения на отсутствие уязвимостей и недекларированных возможностей предусмотрена пунктом 15 приложения для систем с актуальными угрозами 1-го и 2-го типов. Это высший уровень контроля, требуемый для наиболее критичных систем. Проверка может проводиться автоматизированными средствами (SAST, DAST, SCA) и вручную (code review, fuzzing). Объем проверки зависит от критичности системы и доступных ресурсов. Полная проверка всего кода крупной системы может быть экономически нецелесообразна. Риск-ориентированный подход позволяет сосредоточить усилия на наиболее критичных модулях. Результаты проверки должны документироваться. Выявленные уязвимости должны быть устранены до ввода системы в эксплуатацию.
Security by Design в контексте требований ФСТЭК означает, что архитектура системы изначально проектируется с учетом ограничений и угроз. Принцип наименьших привилегий, защита в глубину, сегментация, отказоустойчивость — эти принципы должны быть заложены в фундамент. Архитектурные решения по безопасности должны быть задокументированы и утверждены. Изменения архитектуры должны проходить review на предмет влияния на безопасность. Деградация архитектуры со временем — распространенная проблема. Регулярный архитектурный аудит помогает поддерживать целостность системы защиты. Документация по архитектуре должна быть актуальной. Устаревшие схемы вводят в заблуждение и создают риски.
Управление обновлениями и патч-менеджмент являются частью жизненного цикла. Устаревшее ПО — главная цель атакующих. Процесс обновления должен быть автоматизирован там, где это возможно. Тестирование обновлений в изолированной среде перед развертыванием в продакшене обязательно. Планы отката должны быть готовы заранее. Для систем, которые нельзя остановить для обновления, должны быть предусмотрены компенсирующие меры. Вендоры ПО должны предоставлять информацию об уязвимостях и патчах своевременно. Подписка на бюллетени безопасности — базовая гигиена. End-of-life ПО должно быть заменено или изолировано. Поддержка устаревшего ПО без обновлений — неприемлемый риск. Инвентаризация ПО и отслеживание сроков поддержки — основа управления жизненным циклом.
Практическая дорожная карта перехода на новые требования
Переход на новые требования ФСТЭК требует системного подхода и планирования. Первый этап — аудит текущей системы защиты на соответствие новому приказу. Необходимо сопоставить существующие меры с новым перечнем, оценить уровень зрелости по предварительным критериям, выявить разрывы. Аудит должен охватывать не только технические средства, но и процессы, документацию, компетенции персонала. Результаты аудита формируют план работ. Приоритезация задач должна основываться на рисках. Критические разрывы, создающие непосредственную угрозу утечки, устраняются в первую очередь. Задачи, требующие значительных инвестиций, планируются в бюджете следующего периода. Дорожная карта должна быть согласована с руководством и обеспечена ресурсами.
Второй этап — разработка или актуализация модели угроз. Новая модель должна учитывать изменившийся ландшафт угроз, включая ИИ, облака, IoT. Модель должна быть привязана к конкретной архитектуре ИСПДн и используемым технологиям. Использование актуальных баз знаний об угрозах и методических документов ФСТЭК обязательно. Модель угроз — живой документ, который должен обновляться при изменении системы или появлении новых угроз. На основе модели проводится верификация мер. Без качественной модели угроз выбор мер будет случайным и неэффективным. Привлечение экспертов для разработки модели угроз оправдано для сложных систем. Качество модели определяет качество всей системы защиты.
Третий этап — внедрение недостающих технических мер и процессов. Это может включать закупку и внедрение новых СЗИ, настройку мониторинга, автоматизацию контроля конфигураций, внедрение процессов управления уязвимостями. Параллельно должна обновляться документация: политика обработки ПДн, регламенты, инструкции. Обучение персонала новым требованиям и процедурам критически важно. Самые совершенные средства защиты бесполезны, если персонал не умеет ими пользоваться или саботирует процессы. Программы повышения осведомленности должны быть регулярными и практическими. Тестирование знаний и симуляции фишинга помогают закрепить навыки. Культура безопасности формируется действиями, а не лозунгами.
Четвертый этап — подготовка к первой оценке показателя Узи. Оператор должен выбрать методику оценки (дождаться официальной или использовать предварительную), определить исполнителя (собственные силы или лицензиат), подготовить необходимую документацию и доказательства. Пробная оценка помогает выявить слабые места до официального мероприятия. Корректировка по результатам пробной оценки повышает шансы на успешное прохождение официальной оценки. Отчет об оценке должен быть подготовлен качественно и полно. Он станет основой для дальнейшего развития системы защиты. Первая оценка — не финиш, а старт нового цикла улучшения. Регулярные оценки позволяют отслеживать прогресс и адаптироваться к изменениям.
Пятый этап — обучение персонала и повышение осведомленности. Новые требования меняют роли и ответственность сотрудников. Администраторы должны освоить новые инструменты. Разработчики — принципы безопасной разработки. Руководители — основы управления рисками ИБ. Все сотрудники — правила гигиены и реагирования на инциденты. Обучение должно быть дифференцированным по ролям. Форматы обучения разнообразны: очные тренинги, вебинары, e-learning, симуляции. Оценка эффективности обучения обязательна. Сертификаты о прохождении обучения — доказательство выполнения меры по повышению осведомленности. Инвестиции в людей дают наибольшую отдачу в безопасности. Зрелая организация — это организация, где каждый понимает свою роль в защите данных.
Чек-лист готовности оператора к 1 сентября 2026 года
Провести полный аудит текущей системы защиты персональных данных на соответствие требованиям нового приказа ФСТЭК России и зафиксировать выявленные разрывы в реестре несоответствий. Актуализировать модель угроз безопасности персональных данных с учетом новых категорий угроз, включая риски искусственного интеллекта, облачных сред и интернета вещей, и утвердить ее руководителем организации. Определить базовый набор мер для установленного уровня защищенности, выполнить адаптацию и верификацию мер с учетом актуальной модели угроз и архитектуры информационной системы. Разработать и документально обосновать компенсирующие меры для случаев технической или экономической невозможности реализации базовых мер. Актуализировать политику в отношении обработки персональных данных, включив в нее обновленный состав и содержание мер по обеспечению безопасности. Провести инвентаризацию средств защиты информации и проверить соответствие их классов и уровней доверия требованиям пункта 16 приложения к приказу. Запланировать и провести первую оценку показателя уровня зрелости Узи до начала обработки или в кратчайшие сроки после вступления приказа в силу. Установить целевые значения показателя Узи для всех лиц, осуществляющих обработку персональных данных по поручению оператора, и внести соответствующие изменения в договоры. Настроить техническое и организационное взаимодействие с ГосСОПКА и обеспечить непрерывный обмен информацией об угрозах и инцидентах. Разработать и утвердить регламент проведения внеплановых оценок Узи после компьютерных инцидентов и интегрировать его в процесс реагирования на инциденты. Организовать обучение ключевого персонала новым требованиям и процедурам, провести оценку знаний и задокументировать результаты. Подготовить комплект документации для подтверждения соответствия при проверках регулятора, включая отчеты об оценках, обоснования компенсирующих мер и договоры с подрядчиками.
Заключение и перспективы развития регулирования
Новый приказ ФСТЭК России знаменует переход к зрелой модели регулирования безопасности персональных данных. Требования стали сложнее, но и более осмысленными. Фокус сместился с наличия бумаг на реальную эффективность защиты. Показатель Узи дает операторам инструмент для управления безопасностью как бизнес-процессом. Расширение перечня мер отражает реалии цифровой экономики. ИИ, облака, API — это не будущее, а настоящее. Регулятор требует защищать данные там, где они реально находятся и обрабатываются. Жесткие требования к СЗИ и подрядчикам повышают общий уровень безопасности в стране. Взаимодействие с ГосСОПКА создает единую экосистему противодействия угрозам. Переходный период до 1 сентября 2026 года дает время на адаптацию, но требует активных действий уже сейчас.
Перспективы развития регулирования включают дальнейшую детализацию методик оценки зрелости, появление отраслевых стандартов и лучших практик, развитие рынка услуг по оценке и аудиту. Ожидается интеграция требований ФСТЭК с другими регуляторными рамками, снижение дублирования и упрощение compliance. Технологии ИИ будут продолжать развиваться, и регулирование будет адаптироваться. Возможно появление специализированных требований для различных типов ИИ. Международная гармонизация стандартов также будет продолжаться, несмотря на геополитические сложности. Безопасность данных — глобальная задача. Российский опыт регулирования зрелости защиты может быть интересен другим странам.
Для операторов новый приказ — вызов и возможность. Вызов — в сложности и объеме требований. Возможность — в построении действительно эффективной системы защиты, которая поддерживает бизнес, а не тормозит его. Зрелая система защиты снижает риски, повышает доверие клиентов и партнеров, создает конкурентное преимущество. Инвестиции в безопасность возвращаются через избежание убытков и укрепление репутации. Главное — начать движение сейчас. Откладывать на потом опасно. Время работает против тех, кто бездействует. Активная позиция, диалог с регулятором, обмен опытом с коллегами — залог успеха. Безопасность — это путь, а не точка назначения. И новый приказ указывает верное направление на этом пути.
Приглашаю вас поделиться своим опытом подготовки к новым требованиям ФСТЭК в комментариях. Ваш практический опыт и вопросы помогут сообществу быстрее адаптироваться к изменениям и построить надежную защиту персональных данных в новых регуляторных условиях.
Добавить комментарий