Место 149-ФЗ в иерархии актов разобрано в обзоре нормативно-правового обеспечения ИБ.

Понятийный аппарат и правовые режимы информации

149-ФЗ определяет, что считается информацией, кто ею распоряжается и в каком режиме она обращается. От режима зависит, обязана ли компания хранить сведения в тайне и какие меры защиты должна применить.

Ключевое различие для договорной работы — между предоставлением и распространением. Предоставление адресовано определенному кругу лиц, распространение — неопределенному (пункты 8 и 9 статьи 2). Выгрузка данных партнеру по API — предоставление, публикация в открытом каталоге — распространение, и требования к ним разные.

Информационная безопасность и ФЗ-149: классификация информации по режиму доступа

По режиму доступа закон делит информацию на две категории: общедоступную и ограниченного доступа (статья 5). Государственная тайна — не отдельная категория, а один из видов информации ограниченного доступа со своим законом.

Ограничить доступ можно только на основании федерального закона или акта Президента (часть 1 статьи 9 в редакции 2024 года). Компания не может объявить сведения тайной одним приказом: внутренний приказ — не нормативно-правовой акт, он лишь оформляет режим, который опирается на закон, например на 98-ФЗ о коммерческой тайне. Информационная безопасность по ФЗ 149 начинается с инвентаризации: какие данные к какому режиму относятся.

Внутри ограниченного доступа режимы различаются. Условия отнесения к коммерческой, служебной и иной тайне устанавливают федеральные законы, для коммерческой это 98-ФЗ. Профессиональная тайна охраняется, если закон возлагает обязанность ее хранить, а порядок доступа к персональным данным определяет 152-ФЗ.

Конфиденциальность и защита информации: как закон ограничивает и защищает данные

Конфиденциальность в 149-ФЗ — обязанность лица, получившего доступ к информации, не передавать ее третьим лицам без согласия обладателя (пункт 7 статьи 2). Защита информации — комплекс правовых, организационных и технических мер (статья 16).

Цели защиты закон называет прямо: предотвратить неправомерный доступ, уничтожение, изменение, блокирование и копирование, соблюсти конфиденциальность и обеспечить право на доступ. Последнее часто упускают: защита не должна блокировать законный доступ к информации.

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

Специфические субъекты и обязанности в цифровой среде

Закон выделяет субъектов с особыми обязанностями: организаторов распространения информации, операторов информационных систем и владельцев сайтов. Один бизнес может совмещать все три роли.

Организаторы распространения информации (ОРИ): обязанности по хранению и защите данных

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

ОРИ уведомляет Роскомнадзор о начале деятельности и хранит данные в России. Сведения о фактах приема, передачи и обработки сообщений и о пользователях с 1 января 2026 года хранятся три года вместо одного (изменение внесено законом № 41-ФЗ). Содержание сообщений — до шести месяцев.

Если сервис применяет дополнительное шифрование, ОРИ передает ФСБ сведения для декодирования. Мессенджеры обязаны идентифицировать пользователей по номеру телефона. Обязанности не распространяются на операторов государственных и муниципальных ИС, операторов связи в лицензируемой части и граждан, действующих для личных нужд.

Информационные системы и операторы: требования к обеспечению целостности и доступности

Оператор ИС — лицо, которое эксплуатирует информационную систему, включая обработку данных в ее базах. В случаях, установленных законодательством, он вместе с обладателем информации обязан обеспечить целостность и доступность данных.

Часть 4 статьи 16 перечисляет шесть обязанностей: не допускать несанкционированный доступ, своевременно его обнаруживать и предупреждать неблагоприятные последствия нарушений. Кроме того, нужно исключать воздействие на технические средства обработки, обеспечивать возможность незамедлительного восстановления информации и постоянно контролировать защищенность. Для архитектуры это резервирование, журналирование, мониторинг и регламент восстановления.

Для ГИС и иных систем госорганов требования конкретизируют ФСТЭК и ФСБ, а операторы ГИС взаимодействуют с ГосСОПКА. Для коммерческих систем конкретные обязанности по защите возникают из специальных законов: 152-ФЗ для персональных данных, 187-ФЗ для объектов КИИ.

Чек-лист: 4 шага для приведения внутренних регламентов работы с данными в соответствие с 149-ФЗ

Регламенты соответствуют 149-ФЗ, если в них определены режимы информации, роли компании по закону и меры защиты для каждой системы.

1. Классифицируйте информацию. Составьте перечень данных с указанием режима: общедоступная, коммерческая тайна, персональные данные, иная тайна — и закона, на котором режим основан
2. Определите роли компании. Оператор ИС, владелец сайта, ОРИ, обладатель информации — для каждой роли свой набор обязанностей
3. Разведите предоставление и распространение. Пропишите, какие данные и кому передаются по договору, а какие публикуются, и внесите условия конфиденциальности в договоры
4. Закрепите меры по части 4 статьи 16. Резервное копирование, журналирование, контроль доступа и регламент восстановления должны быть описаны и проверяться

FAQ: частые вопросы о 149-ФЗ

Как 149-ФЗ определяет понятие «конфиденциальность информации» и чем оно отличается от коммерческой тайны?

Конфиденциальность — обязанность получателя не передавать информацию третьим лицам без согласия обладателя, а коммерческая тайна — режим конфиденциальности, который вводит сама компания по 98-ФЗ.

Режим возникает, только если обладатель принял меры статьи 10 98-ФЗ: утвердил перечень сведений, ограничил доступ, ведет учет допущенных, урегулировал вопрос в трудовых и гражданско-правовых договорах и ставит гриф. Подробнее — в статье про корпоративную ИБ.

Обязана ли компания регистрироваться как ОРИ, если она использует корпоративный мессенджер?

Если компания пользуется чужим мессенджером, ОРИ — его провайдер, а не она.

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

Какие меры по обеспечению целостности и доступности информации требует 149-ФЗ от операторов ИС?

Закон требует не допускать воздействия на технические средства, обеспечивать незамедлительное восстановление информации и постоянный контроль защищенности.

Это обязанности части 4 статьи 16, которые применяются в случаях, установленных законодательством. Конкретные меры задают подзаконные акты, например приказы ФСТЭК.

Как 149-ФЗ регулирует вопросы блокировки информации и доступа к ней?

Основания и порядок ограничения доступа к информации в интернете установлены статьей 15.1 и следующими за ней: решения суда, уполномоченных органов и Генпрокуратуры.

Роскомнадзор ведет единый реестр запрещенной информации, а владелец сайта обязан удалить ее по уведомлению. Генпрокуратура вправе требовать блокировки по статье 15.3, ресурс ОРИ за неисполнение обязанностей блокируют по статье 15.4 на основании решения суда.

В чем связь между 149-ФЗ и 152-ФЗ (о персональных данных)?

149-ФЗ — общий закон об информации, 152-ФЗ — специальный закон о персональных данных, на который прямо отсылает часть 9 статьи 9.

Понятия обладателя, оператора ИС и конфиденциальности берутся из 149-ФЗ, а порядок обработки ПДн, согласия и уведомления — из 152-ФЗ. Подробнее — в статье про требования 152-ФЗ.

Сообщение 149-ФЗ «Об информации, информационных технологиях и о защите информации» в контексте ИБ появились сначала на Сompliance Сontrol.

Важная поправка к названию: Приказ № 17 с 1 марта 2026 года заменен Приказом № 117 от 11 апреля 2025 года. Ниже сравнение ведется по действующему документу, а номер 17 сохранен как привычный ориентир.

О месте ФСТЭК среди регуляторов и ее полномочиях — в обзоре роли ФСТЭК России.

Архитектура требований ФСТЭК: общий подход к защите объектов

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

Приказы ФСТЭК по информационной безопасности: эволюция от жестких таблиц к риск-ориентированному подходу

Приказы ФСТЭК по информационной безопасности прошли путь от фиксированных таблиц мер к управлению защитой через угрозы и измеримые показатели. Первым этапом были Приказы № 17 и № 21 2013 года, следующим — № 239, а Приказ № 117 закрепил новый подход.

В 2013 году центром требований были таблицы базовых наборов в приложениях: класс или уровень системы определял стартовый перечень мер, а адаптация по угрозам шла вторым шагом. Приказ № 239 сделал анализ угроз с описанием архитектуры объекта обязательным этапом и добавил требования к безопасной разработке ПО для объектов первой категории.

Приказ № 117 разделил требования на мероприятия, то есть процессы защиты, и технические меры. Содержание мер вынесено в методический документ ФСТЭК апреля 2026 года, а результат оценивается показателями защищенности и зрелости. По тому же пути идет проект приказа на замену № 21: его опубликовали в июле 2026 года, но на октябрь он не подписан.

Базовые и адаптивные меры защиты: как читать приложения к приказам

Базовый набор мер — стартовая точка, а не готовый перечень: его обязательно адаптируют и дополняют. Читать приложение нужно вместе с моделью угроз и описанием архитектуры, иначе набор окажется либо избыточным, либо неполным.

Алгоритм одинаков. Сначала берут базовые меры для своего класса, уровня или категории. Затем исключают меры, неприменимые к архитектуре: нет виртуализации — нет мер по защите среды виртуализации. После этого сверяют набор с актуальными угрозами и добавляют меры, которых не хватает.

Здесь пригодится объектная модель — описание системы как набора объектов защиты: сегментов, компонентов, интерфейсов. Она позволяет назначать меры по сегментам, а не по системе целиком. Приказ № 117 допускает разные классы для разных сегментов одной ГИС.

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

Специфика защиты по ключевым приказам

Состав технических мер в трех приказах в основном совпадает, а различия сосредоточены в способе классификации, требованиях к средствам защиты и формах контроля. Именно их и стоит закладывать в бюджет отдельно.

Приказ №17 (ГИС) и Приказ №21 (ИСПДн): точки пересечения и фундаментальные отличия

Группы технических мер для ГИС и ИСПДн во многом совпадают, но по-разному определяются строгость защиты и формы подтверждения. Класс ГИС зависит от значимости информации и масштаба системы, уровень защищенности ИСПДн — от типа актуальных угроз, категорий и объема персональных данных.

Ключевые отличия касаются средств защиты и контроля. В ГИС применяются сертифицированные средства, а класс защиты и уровень доверия жестко привязаны к классу системы: для К1 — не ниже четвертого, для К2 — пятого, для К3 — шестого. Систему аттестуют до начала обработки информации. Приказ № 21 требует средства, прошедшие оценку соответствия, если они нужны для нейтрализации актуальных угроз, а аттестацию не делает обязательной.

Если ГИС обрабатывает персональные данные, требования о защите ГИС применяются вместе с требованиями к ИСПДн, и меры подбирают так, чтобы закрыть оба режима. Подробно защита ИСПДн разобрана в статье про требования 152-ФЗ.

Требования информационной безопасности ФСТЭК по Приказу №239: специфика защиты КИИ

Требования информационной безопасности ФСТЭК для значимых объектов КИИ строже двух других режимов в трех местах: моделировании угроз, требованиях к ПО и правилах совмещения. Категория значимости определяется по последствиям инцидента, а не по составу данных.

Модель угроз должна содержать описание архитектуры объекта, а исходными данными для анализа угроз служит БДУ ФСТЭК. Как строить такую модель, разобрано в статье про моделирование угроз.

Для прикладного ПО значимых объектов первой категории приказ требует безопасной разработки, поиска уязвимостей и поддержки безопасности. Если значимый объект одновременно является ГИС или ИСПДн, применяются меры по наиболее высокому из требований (пункт 24). Категорирование и защиту объектов по 187-ФЗ берет на себя услуга по безопасности объектов КИИ.

Чек-лист: 5 правил оптимизации затрат при выполнении требований нескольких приказов одновременно

Совмещение режимов дешевле, если строить одну систему защиты под самое строгое требование, а не три параллельные. Пять правил помогают этого добиться.

1. Сначала объектная модель, потом закупки. Разметьте сегменты и определите для каждого класс, уровень и категорию, чтобы не защищать всю систему по максимуму
2. Единая матрица мер. Сведите требования приказов в одну таблицу, где каждой мере сопоставлены все источники. Одна реализованная мера закрывает несколько строк
3. Покупайте СЗИ под самый строгий режим. Сертифицированное средство с нужным классом защиты и уровнем доверия для КИИ первой категории подойдет и для ИСПДн, и для ГИС
4. Одна модель угроз на объект. Общая модель с разделами по режимам дешевле в поддержке, чем три отдельных документа
5. Совместите циклы контроля. Оценку эффективности для ИСПДн проводите вместе с расчетом показателей для ГИС и КИИ. Доказательства тогда собираются один раз

FAQ: частые вопросы о приказах ФСТЭК

Можно ли использовать одну и ту же СЗИ для выполнения требований Приказов №21 и №239?

Да, если средство соответствует более строгому из двух наборов требований к классу защиты и уровню доверия.

Для значимых объектов дополнительно учитывают требования Приказа № 239 к программным средствам и их поддержке, которые зависят от категории.

Что такое «адаптация мер защиты» в контексте приказов ФСТЭК и как ее обосновать?

Это исключение из базового набора мер, неприменимых к архитектуре и технологиям конкретной системы.

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

Обязательно ли сертифицировать СЗИ по требованиям ФСТЭК, если система не обрабатывает гостайну?

Зависит от режима: для ГИС сертификация обязательна, для ИСПДн требуются средства, прошедшие оценку соответствия, а для значимых объектов КИИ допустимы испытания или приемка.

Если система не попадает ни под один из режимов, решение принимает ее владелец.

Как изменения в БДУ ФСТЭК влияют на уже утвержденные перечни мер защиты?

Автоматически перечень мер не меняется, но новые угрозы нужно проанализировать.

Для значимых объектов КИИ анализ изменения угроз в ходе эксплуатации прямо требует Приказ № 239, периодичность задает сам субъект, а для ГИС Приказ № 117 предписывает уточнять угрозы при эксплуатации. Если для новой угрозы мер нет, разрабатывают компенсирующие.

Какие санкции предусмотрены за невыполнение требований Приказа №239 для субъектов КИИ?

Основная статья — часть 1 статьи 13.12.1 КоАП: от 10 до 50 тысяч рублей для должностных лиц и от 50 до 100 тысяч для юрлиц.

Отдельно с 20 апреля 2026 года действует статья 13.12.2 КоАП о нарушении правил эксплуатации объектов КИИ и доступа к ним: для юрлиц от 100 до 500 тысяч рублей. При ущербе для КИИ возможна уголовная ответственность по статье 274.1 УК.

Сообщение Приказы ФСТЭК по информационной безопасности: разбор требований №17, №21 и №239 появились сначала на Сompliance Сontrol.

ФСТЭК России: статус, задачи и место в архитектуре госбезопасности

ФСТЭК — федеральный орган исполнительной власти в области безопасности КИИ, противодействия иностранным техническим разведкам, технической защиты информации и экспортного контроля. Руководство деятельностью службы осуществляет Президент, а сама она подведомственна Минобороны (Положение о ФСТЭК, Указ № 1085). Через эти полномочия ФСТЭК России определяет, как на практике выглядит информационная безопасность ГИС, ИСПДн и значимых объектов КИИ.

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

Чем ФСТЭК отличается от ФСБ и Роскомнадзора: разграничение зон ответственности

ФСТЭК отвечает за некриптографическую техническую защиту, ФСБ — за криптографию и реагирование на компьютерные атаки, Роскомнадзор — за законность обработки персональных данных. Банк России регулирует защиту в финансовом секторе.

На практике зоны пересекаются. Субъект КИИ категорирует объекты и выполняет требования ФСТЭК, но об инцидентах сообщает в НКЦКИ, созданный ФСБ. Оператор ПДн поднадзорен Роскомнадзору, но технические меры защиты для него устанавливает ФСТЭК, а для криптографии — ФСБ. Контроль за выполнением этих мер ФСТЭК и ФСБ ведут только в государственных ИСПДн (часть 8 статьи 19 152-ФЗ). В коммерческой ИСПДн выполнение обязанностей оператора проверяет Роскомнадзор.

ФСТЭК в системе обеспечения информационной безопасности: от экспорта до защиты КИИ

ФСТЭК в системе обеспечения информационной безопасности объединяет четыре функции: устанавливает требования, сертифицирует средства защиты, лицензирует деятельность и контролирует исполнение. Экспортный контроль продукции двойного назначения стоит особняком: ИБ-компании сталкиваются с ним в основном при вывозе продукции за рубеж.

Как читать и выполнять требования информационной безопасности ФСТЭК из приказов, разобрано в статье о ведомственных приказах.

Инструменты влияния регулятора на рынок и организации

Главные рычаги ФСТЭК — допуск продуктов через сертификацию, допуск компаний через лицензирование и контроль защищенности на объектах.

Сертификация СЗИ и лицензирование деятельности по ТЗКИ: барьеры и возможности

Сертификат ФСТЭК подтверждает, что средство защиты соответствует требованиям безопасности и заявленному уровню доверия, а лицензия на ТЗКИ (техническую защиту конфиденциальной информации) разрешает компании оказывать такие услуги. Для производителя и интегратора это барьер на входе и одновременно конкурентное преимущество.

Сертификация проходит через испытательную лабораторию и орган по сертификации, аккредитованные ФСТЭК. Уровень доверия зависит от того, где средство будет применяться: для значимых объектов КИИ первой категории нужен уровень не ниже четвертого, второй — не ниже пятого, третьей — не ниже шестого. Сертификат требует сопровождения: производитель обязан устранять уязвимости и выпускать обновления, а условием действия сертификата стала техподдержка продукта.

Обязательна сертификация не везде. В значимых объектах КИИ Приказ № 239 допускает и другие формы оценки соответствия — испытания или приемку, если сертификация не требуется законодательством. Но несертифицированное средство тогда должно соответствовать шестому или более высокому уровню доверия. Подбор сертифицированных решений разобран в материале про средства защиты информации.

Лицензия на ТЗКИ выдается по Постановлению № 79 и нужна тем, кто оказывает услуги по защите конфиденциальной информации: аттестацию, проектирование систем защиты, установку и настройку СЗИ, контроль защищенности. Лицензиату нужны специалисты с профильным образованием, поверенное оборудование и помещения.

Банк данных угроз (БДУ) ФСТЭК: как регулятор формирует повестку моделирования угроз

БДУ ФСТЭК — ведомственный каталог угроз безопасности информации и уязвимостей программного обеспечения. Через него регулятор задает общий перечень угроз, с которым работают все, кто строит модель угроз для ГИС, ИСПДн и значимых объектов КИИ.

Перечень угроз в БДУ меняется редко, а раздел уязвимостей пополняется постоянно. По подсчетам «Лаборатории Касперского», за 2025 год в него внесли более 13 тысяч уязвимостей, за январь–май 2026 года — около 3,7 тысячи.

Методика оценки угроз 2021 года называет БДУ среди основных источников исходных данных, поэтому модель угроз без него на проверке выглядит неполной. Как применять БДУ в моделировании, разобрано в статье про моделирование угроз.

Повестку регулятор задает и методиками. Методика оценки показателя защищенности от 11 ноября 2025 года учитывает результаты поиска уязвимостей и тестирования на проникновение: если проверяющим удался первоначальный доступ к системе, вклад соответствующей группы показателей обнуляется. Методика анализа защищенности, утвержденная в конце 2025 года, встроила поиск уязвимостей в аттестацию информационных систем. Подготовиться к таким проверкам помогает тестирование на проникновение.

Чек-лист: 4 шага для выстраивания прозрачных отношений с территориальными органами ФСТЭК

Прозрачные отношения с ФСТЭК строятся на актуальных сведениях, одном ответственном за взаимодействие и готовности показать доказательства в любой момент.

1. Держите сведения актуальными. Результаты категорирования, изменения объектов КИИ и данные в реестре значимых объектов должны совпадать с реальностью
2. Назначьте ответственного за взаимодействие. Один сотрудник ведет переписку с управлением ФСТЭК, контролирует сроки ответов и хранит копии направленных документов
3. Соберите доказательную базу заранее. Акты категорирования, модель угроз, проект системы безопасности, сертификаты или протоколы испытаний СЗИ, акты приемки, журналы и план реагирования на инциденты
4. Исполняйте предписания в срок и проводите самооценку. Расчет показателей защищенности по методикам ФСТЭК лучше освоить до того, как Приказ № 220 сделает его регулярным с 1 марта 2027 года

FAQ: частые вопросы о ФСТЭК России

Нужна ли лицензия ФСТЭК компании, которая защищает только свои собственные ИСПДн?

Как правило, нет: Приказ № 21 позволяет оператору выполнять меры защиты и оценивать их эффективность самостоятельно, а лицензиатов привлекать по договору.

Лицензия понадобится, если компания оказывает услуги по ТЗКИ другим юрлицам, включая компании своей группы. Подробнее о защите ИСПДн — в статье про требования 152-ФЗ.

Как часто ФСТЭК обновляет Банк данных угроз (БДУ) и обязательно ли его использовать?

Уязвимости добавляются постоянно, тысячами в год, а перечень угроз обновляется редко.

Для ГИС, ИСПДн и значимых объектов КИИ использование БДУ фактически обязательно: на него опирается Методика оценки угроз 2021 года. Для остальных систем решение принимает их владелец.

В чем разница между сертификатом ФСТЭК и сертификатом ФСБ на криптографию?

ФСТЭК сертифицирует некриптографические средства защиты, ФСБ — средства криптографической защиты (СКЗИ) по классам от КС1 до КА1.

Многие продукты, например VPN-шлюзы, имеют оба сертификата: на межсетевой экран от ФСТЭК и на СКЗИ от ФСБ. Подробнее — в статье про криптографическую защиту.

Какие санкции грозят за использование несертифицированных СЗИ на объектах КИИ?

Основная статья — часть 1 статьи 13.12.1 КоАП, нарушение требований к безопасности значимых объектов: штраф от 10 до 50 тысяч рублей для должностных лиц и от 50 до 100 тысяч для юрлиц.

Если средство подлежало обязательной сертификации, возможна и часть 2 статьи 13.12 с теми же суммами и конфискацией. При ущербе для КИИ возможна уголовная ответственность по статье 274.1 УК.

Как проходит плановая проверка ФСТЭК и к каким документам нужно быть готовым?

Плановая проверка значимых объектов КИИ проводится по истечении трех лет с внесения объекта в реестр или с прошлой проверки, выездом и не дольше 20 рабочих дней (Постановление № 162).

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

Сообщение ФСТЭК России в системе обеспечения информационной безопасности: функции и контроль появились сначала на Сompliance Сontrol.

Место Доктрины среди других актов разобрано в обзоре нормативно-правового обеспечения ИБ.

Доктрина информационной безопасности: концептуальный базис и национальные интересы

Доктрина информационной безопасности фиксирует, что государство считает своими интересами в информационной сфере и от каких угроз их защищает.

Что такое Доктрина ИБ и её место в системе стратегического планирования РФ (Указ №646)

Доктрина — система официальных взглядов на обеспечение национальной безопасности в информационной сфере, утвержденная Указом Президента № 646 от 5 декабря 2016 года. Она заменила доктрину 2000 года и действует до сих пор.

Пункт 5 называет ее документом стратегического планирования. Это понятие закона № 172-ФЗ: такие документы задают цели и приоритеты, а обязанностей для бизнеса напрямую не создают. Доктрина развивала Стратегию национальной безопасности 2015 года, сейчас действует Стратегия 2021 года (Указ № 400), где информационная безопасность — отдельный национальный приоритет.

О подготовке новой редакции Совбез сообщил в сентябре 2025 года. В январе 2026-го помощник секретаря Совбеза Дмитрий Грибков назвал ее ключевые идеи: информационный суверенитет и принцип неразрывности. По этому принципу защита закладывается при создании любой цифровой системы, включая ИИ. На октябрь 2026 года новый текст не утвержден.

Ключевые угрозы и национальные приоритеты: как они влияют на госсектор и бизнес

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

Среди угроз — рост компьютерной преступности, прежде всего в кредитно-финансовой сфере, и усложнение атак на объекты КИИ. Отдельно названа высокая зависимость промышленности от зарубежных технологий: электронной компонентной базы, ПО, вычислительной техники, средств связи.

Отсюда и задачи в экономической сфере (пункт 25): ликвидировать зависимость от зарубежных информационных технологий и средств защиты за счет отечественных разработок. Для госсектора и субъектов КИИ эта строка уже стала прямыми запретами. Для остального бизнеса она приходит через требования заказчиков и условия госзакупок.

Трансформация стратегии в регуляторную практику

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

Схема показывает путь идеи к технической мере, а не юридическую силу актов: указы стоят ниже федеральных законов.

От Доктрины к законам: как стратегические установки становятся императивными нормами (187-ФЗ, импортозамещение)

Установка превращается в императивную норму, когда указ или закон добавляет к ней адресатов, обязанности и сроки. Пример — КИИ: в декабре 2016 года Доктрина отнесла усложнение атак на эти объекты к основным угрозам, а в июле 2017-го принят 187-ФЗ.

Затем Правительство утвердило правила категорирования, а ФСТЭК — требования к защите значимых объектов. Выполнить их помогает услуга по безопасности объектов КИИ.

Импортозамещение прошло тот же путь, но позже и в основном через указы. Указ № 166 от 30 марта 2022 года запретил заказчикам по 223-ФЗ закупать иностранное ПО для значимых объектов КИИ без согласования. С 1 января 2025 года им и органам власти запрещено использовать такое ПО на своих значимых объектах. Указ № 250 с 2025 года запретил органам и организациям из своего круга, включая субъекты КИИ, использовать средства защиты из недружественных стран.

Постановление № 1912 до 1 января 2030 года переводит значимые объекты КИИ на преимущественное применение доверенных программно-аппаратных комплексов. Закон № 58-ФЗ с 1 сентября 2025 года дал Правительству право устанавливать требования к ПО на таких объектах и сроки перехода. В феврале 2026 года утвержден перечень типовых отраслевых объектов КИИ.

Как такие нормы читать и выполнять на уровне приказов, разобрано в статье о требованиях ИБ и ведомственных приказах.

Технологический суверенитет: практические последствия для корпоративных ИТ-стратегий

Технологический суверенитет для компании — возможность работать, обновляться и защищаться без согласия иностранного вендора. Это вопрос непрерывности бизнеса, а не только соответствия требованиям.

В 2022 году стала видна цена зависимости: уход вендоров оставил компании без обновлений и поддержки. Поэтому импортозамещение планируют как управление риском, даже там, где прямого запрета нет.

Меняются три вещи. Закупки: в техническом задании требуют запись в реестре российского ПО, сертификат ФСТЭК, статус доверенного комплекса. Архитектура: миграция идет по слоям, например от средств защиты к ОС и СУБД, с периодом параллельной работы. Бюджет: переход занимает годы и закладывается в ИТ-стратегию заранее. Выбор российских решений разобран в материале про средства защиты информации.

Чек-лист: 4 маркера соответствия корпоративной стратегии ИБ государственным приоритетам

Стратегия ИБ соответствует приоритетам государства, если компания знает свой статус, видит технологические зависимости и управляет ими на уровне руководства.

1. Статус определен. Субъект КИИ, оператор ПДн, поставщик госзаказчиков или субъектов КИИ: от статуса зависит, какие установки Доктрины для вас уже стали нормами
2. Есть карта зависимостей. Иностранное ПО, оборудование и средства защиты с оценкой риска отключения и сроками замены
3. Закупки учитывают регуляторику. Реестр российского ПО, сертификаты ФСТЭК и требования информационной безопасности к доверенным комплексам прописаны в регламенте закупок
4. Ответственность — на уровне руководства. ИБ курирует член правления, совет директоров получает регулярный отчет. GR-функция отслеживает новые стратегические документы, включая новую редакцию Доктрины

Отчетность службы ИБ перед советом директоров разобрана в статье про корпоративную ИБ.

FAQ: частые вопросы о Доктрине информационной безопасности

Обязана ли коммерческая компания (не КИИ) руководствоваться Доктриной ИБ?

Напрямую нет: Доктрина — документ стратегического планирования и обязанностей для бизнеса не устанавливает.

Обязательны для компании законы и акты, в которых закреплены те же приоритеты, например 152-ФЗ. Косвенно установки доходят через контрагентов: субъекты КИИ требуют российские решения от поставщиков.

Как Доктрина информационной безопасности влияет на требования к закупкам зарубежного ПО?

Доктрина задает цель — ликвидировать зависимость от зарубежных технологий, а конкретные ограничения вводят другие акты.

Для заказчиков по 223-ФЗ это Указ № 166, для значимых объектов КИИ — Постановление № 1912, в госзакупках действует национальный режим с опорой на реестр российского ПО. Частную компанию без КИИ, не работающую по 223-ФЗ и не входящую в круг Указа № 250, прямые запреты не касаются.

Какие указы Президента РФ детализируют положения Доктрины?

Ключевые — Указ № 166 о технологической независимости КИИ и Указ № 250 о дополнительных мерах по обеспечению ИБ.

Рамку задают также Стратегия национальной безопасности (Указ № 400), Стратегия развития информационного общества (Указ № 203) и Основы политики в области международной ИБ (Указ № 213).

Что понимается под «технологическим суверенитетом» в контексте ИБ?

Под ним понимают способность страны и компании разрабатывать, применять и обслуживать критические технологии без зависимости от иностранных поставщиков.

Обеспечение технологического суверенитета — одна из целей закона о технологической политике 2024 года. В ИБ это российские средства защиты, ОС, СУБД и оборудование под собственным контролем.

Как часто пересматривается Доктрина ИБ и кто инициирует изменения?

Фиксированного срока пересмотра нет: прежняя доктрина действовала 16 лет, нынешняя — с 2016 года.

Новую редакцию готовит аппарат Совета Безопасности с ведомствами и научными организациями, утверждает ее Президент указом.

Сообщение Доктрина информационной безопасности РФ: стратегические приоритеты и указы Президента появились сначала на Сompliance Сontrol.

Иерархия актов и их юридическая сила разобраны в обзорном материале кластера, здесь — практика.

Анатомия требований ИБ: от абстракции к техническим мерам

Любое требование проходит путь от общей нормы закона до конкретной настройки средства защиты. Задача compliance-менеджера — пройти этот путь целиком и для каждой настройки знать, из какой нормы она выросла.

Например, 152-ФЗ обязывает оператора принимать меры защиты персональных данных. Какие именно — определяет Приказ ФСТЭК № 21 в зависимости от уровня защищенности. Мера из группы идентификации и аутентификации может воплотиться в двухфакторный вход для администраторов.

Что такое требования информационной безопасности: виды, источники и юридическая сила

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

Договорные требования часто недооценивают. Нарушение PCI DSS не влечет штрафа от государства, но может стоить права принимать карты. Подтвердить соответствие можно в рамках услуги по PCI DSS.

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

Приказ по информационной безопасности обязателен с момента вступления в силу, а вступить в силу он может только после регистрации в Минюсте и официального опубликования. Но действует он не для всех, а только в своей сфере: для определенных видов систем и организаций.

Сферу действия проверяют реже всего, а ошибаются именно здесь. Приказ № 239 касается только значимых объектов КИИ, а не всех систем субъекта; Приказ № 21 — информационных систем персональных данных, причем набор мер зависит от уровня защищенности. Поэтому сначала определяют статус объекта. Потом читают требования.

Дату вступления в силу тоже нужно проверять. Приказ ФСТЭК № 220 от 16 июля 2026 года с новыми показателями защищенности и зрелости значимых объектов КИИ зарегистрирован 7 сентября 2026 года, но вступает в силу 1 марта 2027 года. Оставшиеся месяцы — время подготовиться к расчету новых показателей.

При чтении формулировок помогает простое правило. «Обеспечивается», «должны», «не допускается» — признаки императивной нормы: ее выполняют, а отступить можно только в порядке, который предусмотрел сам акт. «Рекомендуется», «по решению оператора» — пространство для выбора, которое стоит зафиксировать документом.

Алгоритм достижения соответствия (Compliance Roadmap)

Compliance roadmap — дорожная карта, которая переводит перечень требований в последовательность работ с бюджетом и сроками. Работа идет по циклу: идентификация требований, GAP-анализ, план работ, внедрение, внутренний аудит.

Цикл замкнут. После аудита требования снова пересматриваются: меняются приказы, архитектура и статус объектов.

Чтобы не остановить бизнес, работы раскладывают на три волны. Первая — документы и организационные меры: назначение ответственных, регламенты, обучение. Вторая — изменение настроек существующих систем: в окна обслуживания, с пилотом на одном сегменте. Третья — закупка и внедрение новых средств защиты, самая долгая и дорогая.

GAP-анализ: как оценить разрыв между текущим состоянием и требованиями регуляторов

GAP-анализ сравнивает каждое применимое требование с тем, что реально внедрено. Результат — реестр несоответствий с оценкой риска и стоимости устранения.

Порядок работы:

1. Составить матрицу: требование, источник, текущее состояние, доказательство выполнения
2. Для каждой строки выставить статус: выполнено, частично, не выполнено
3. Проверить доказательства: документ, настройку, журнал событий, а не устное подтверждение
4. Оценить каждое несоответствие по риску и стоимости устранения
5. Сгруппировать устранение в проекты с ответственными и сроками

При приоритизации работает простой шаблон рассуждения. Сначала — несоответствия императивным нормам, влекущие санкции. Затем — те, что повышают риск реального инцидента. Последними — формальные расхождения в документах.

Типичная ошибка — считать требование выполненным, если есть документ. Политика паролей, которую не поддерживают настройки систем, остается несоответствием, сколько бы подписей ни стояло на титульном листе. Проверяющий смотрит на настройки. Методика оценки защищенности разобрана в статье про аудит информационной безопасности.

Компенсирующие меры: что делать, если технически невозможно выполнить требование приказа

Если меру невозможно реализовать, приказы ФСТЭК разрешают заменить ее компенсирующей. Условий два: компенсирующая мера должна нейтрализовать ту же угрозу, а ее применение — быть обосновано.

Приказ № 21 допускает компенсирующие меры при технической невозможности и с учетом экономической целесообразности. Приказ № 239 — в том числе когда мера мешает работе значимого объекта. Обоснование готовят при разработке мер, а для значимых объектов КИИ достаточность компенсации проверяют при приемочных испытаниях или аттестации.

Пример. Устаревшая АСУ ТП не поддерживает антивирус, а обновить ее нельзя без остановки производственной линии. Компенсация — изоляция сегмента, контроль съемных носителей и мониторинг трафика на границе.

Чек-лист: 5 этапов подготовки инфраструктуры к проверке выполнения требований ИБ

Подготовка к проверке — прежде всего сбор доказательств, а не срочное внедрение мер. Начинать ее стоит за 3–6 месяцев.

6. Актуализировать реестр требований с учетом статуса объектов и последних редакций приказов
7. Провести GAP-анализ и закрыть критичные несоответствия
8. Привести в порядок организационно-распорядительные документы (ОРД): приказы о назначении ответственных, политики, модели угроз
9. Собрать доказательную базу: сертификаты СЗИ, журналы, акты, результаты тестирования
10. Провести внутренний аудит соответствия по сценарию проверяющего и устранить замечания

Состав ОРД разобран в статье про организационное обеспечение ИБ, технические меры — в материале про средства защиты информации.

FAQ: частые вопросы о требованиях ИБ и ведомственных приказах

Что делать, если требования двух разных приказов (например, ФСТЭК и ЦБ РФ) противоречат друг другу?

Сначала убедиться, что противоречие реальное: требования разных регуляторов обычно накладываются друг на друга, и выполнять приходится и те, и другие.

Прямые противоречия редки, потому что требования Банка России к защите при переводах денежных средств согласуются с ФСБ и ФСТЭК. Если коллизия все же возникла, применяют более строгую меру и направляют запрос регулятору.

Являются ли методические документы ФСТЭК обязательными требованиями?

Сами по себе нет: они не являются нормативно-правовыми актами.

Обязательными их делает отсылка в приказе. Например, по Приказу № 220 методики расчета показателей должны соответствовать методическим документам ФСТЭК.

Как правильно оформить применение компенсирующих мер вместо выполнения прямого требования?

Документом с обоснованием: какая мера не реализуется и почему, какую угрозу она закрывала и чем ее заменяют.

Обоснование включают в проектную документацию системы защиты. Для значимых объектов КИИ достаточность компенсирующих мер оценивают при приемочных испытаниях или аттестации.

Кто в организации несет персональную ответственность за невыполнение требований ИБ?

Руководитель организации. Для органов и организаций, на которые распространяется Указ № 250, включая субъекты КИИ, это прямо закреплено в указе.

По КоАП отвечают и сама организация, и должностные лица, назначенные ответственными приказом. Поэтому назначение должно быть оформлено документально.

Как часто нужно проводить внутренний аудит на соответствие требованиям приказов?

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

Отдельные сроки задают сами акты. По Приказу № 21 эффективность мер оценивают не реже раза в три года, а кредитные организации проходят оценку по ГОСТ Р 57580 не реже раза в два года. С 1 марта 2027 года для значимых объектов КИИ показатель защищенности нужно рассчитывать не реже раза в полгода.

Сообщение Требования информационной безопасности и ведомственные приказы: алгоритм соответствия появились сначала на Сompliance Сontrol.

Участники пленарной дискуссии конференции «Финтех в безопасности 2026».

Тренды в центре программы

В центре обсуждений оказались актуальные угрозы финансовому сектору, развитие цифровых платежей, применение искусственного интеллекта, международные стандарты, защита персональных данных в Казахстане, аудит и практические подходы к повышению киберустойчивости.

Программа объединила вопросы комплаенса и кибербезопасности, практические кейсы тестирования на проникновение, автоматизацию аудита и управления рисками, а также международный опыт защиты бизнеса от киберугроз.

На открытии представители компаний Compliance Control и Rakasta подчеркнули, что безопасность финансовых сервисов невозможно рассматривать отдельно от технологий, регулирования и бизнес-процессов.

«Быстрота развития финансовых сервисов требует такого же внимания к их безопасности. Для нас важно объединять банки, финтех-компании, ритейл и специалистов по ИБ, чтобы обсуждать не только возникающие риски, но и работающие способы защиты платежной инфраструктуры», — Аркадий Прокудин, международный эксперт в кибербезопасности, коммерческий директор Rakasta.

Конференция объединила представителей финансового и технологического секторов.

Пленарная дискуссия «Вселенная безопасных платежей»

Центральным событием конференции стала пленарная дискуссия «Вселенная безопасных платежей», объединившая представителей банковского сектора, финтеха, ритейла и технологических компаний. В обсуждении приняли участие: Дмитрий Шапошников, CISO Банка ЦентрКредит; Умид Тухтаев, руководитель Центра управления ИБ (SOC) компании «Транстелеком»; Артём Шалтаев, начальник отдела кибербезопасности Technodom/Airbapay; Александр Косенков, CISO/Head of SOC PS Cloud Services. 

Пленарная сессия состояла из трёх тематических блоков: «Индустрии. Навигация в новой галактике», «Регулирование. Комплаенс-Орбита» и «Решения. Инновации на космических скоростях».

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

«Одна из главных проблем платежной индустрии сегодня в том, что рынок научился проводить финансовые операции практически мгновенно, но не всегда способен с той же скоростью установить, кто действительно стоит за транзакцией и насколько легитимны его намерения. Развитие ИИ усиливает этот разрыв: мошенничество становится всё менее отличимым от обычного поведения клиента. Поэтому следующий этап развития информационной безопасности в финтехе будет связан не столько с защитой транзакций, сколько с оценкой доверия к ним в реальном времени», — Дмитрий Шапошников, CISO Банка ЦентрКредит.

Отдельное внимание было уделено взаимодействию финансовых организаций, технологических компаний и поставщиков ИБ-решений. Участники рассмотрели, как требования регулирования и развитие цифровых технологий влияют на практические подходы к обеспечению безопасности платежной инфраструктуры.

Пленарная дискуссия о роли CISO и управлении киберрисками.

SOC, искусственный интеллект и совместная защита инфраструктуры

Отдельным направлением дискуссии стало развитие центров мониторинга информационной безопасности (SOC). Эксперты обсудили применение моделей искусственного интеллекта для анализа событий, обнаружения угроз и ускорения реагирования, а также обмен данными между организациями и телекоммуникационными операторами.

«Форум показал, что ландшафт угроз в финансовом секторе требует принципиально новых подходов. Коммерческие и аутсорсинговые SOC со встроенными моделями ИИ становятся основой киберустойчивости платежной и смежных отраслей: они объединяют экспертизу и защищают разные инфраструктуры. Соединяя возможности мониторинга с данными телеком-операторов, мы формируем гибкую распределённую систему защиты, способную оперативно реагировать на целевые атаки», — Умид Тухтаев, руководитель Центра управления ИБ (SOC) компании «Транстелеком».

Участники отметили значение комплексного мониторинга, интеграции различных источников данных и развития инструментов автоматизированного реагирования. Такие подходы позволяют повысить скорость обнаружения угроз и эффективность защиты финансовых сервисов.

Обсуждение современных атак на финансовый сектор.

Регулирование, защита персональных данных и международные стандарты

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

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

Эксперты отметили, что практическая ценность аудита не ограничивается формальным подтверждением соответствия. Результаты проверок должны помогать организациям выявлять риски, правильно определять приоритеты и совершенствовать процессы безопасности.

Пентесты и практика оценки защищённости

Отдельный блок программы был посвящён теме «О пентесте как инструменте улучшения защиты. Лучшие кейсы».

Практическая часть охватила тестирование на проникновение, анализ уязвимостей внешнего и внутреннего периметра, а также защиту веб-, мобильных и других приложений финансовых организаций. Участники рассмотрели, как результаты технических проверок могут использоваться при принятии решений о снижении рисков.

«Пентест помогает оценить не только наличие уязвимостей, но и возможные последствия их эксплуатации для бизнеса. Мы рассматриваем реальные сценарии атак, проверяем защищённость инфраструктуры и приложений, а полученные результаты переводим в конкретные рекомендации. Отдельное внимание уделяем собственной исследовательской работе», — Евгений Кудашов, руководитель направления анализа защищённости Compliance Control.

В рамках конференции также рассматривалась тема «Защита бизнеса от киберугроз и регуляторов: международный опыт», посвящённая комплексным подходам к безопасности и взаимодействию бизнеса с требованиями различных регуляторных систем.

Compliance APP и автоматизация аудита

Отдельное выступление программы было посвящено Compliance APP — платформе управления аудитом, рисками и соответствием, разработанной Compliance Control. Платформа объединяет связанные с этими задачами процессы в единой цифровой среде, позволяя систематизировать работу с требованиями, контролировать выполнение мероприятий и повышать прозрачность аудиторских процедур. 

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

Искусственный интеллект в финтехе и стандарт ISO 42001

Завершающая часть деловой программы включала выступление «ИИ в финтехе: почему стандарт ISO 42001 неизбежен». Тема объединила вопросы применения искусственного интеллекта в финансовых организациях.

Итоги

Конференция в Алматы продолжила международную серию мероприятий Compliance Control и Rakasta и стала площадкой для диалога между представителями финансового рынка, технологических компаний и ИБ-индустрии.

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

«Вопросы безопасности всё теснее связаны с устойчивостью финансового бизнеса и доверием клиентов. Особенно ценно услышать разные точки зрения: бизнеса, IT, ИБ. В этом году основной фокус обсуждений был на доверии и единых критериях оценки качества обеспечения информационной безопасности. Мы продолжим делиться международным опытом и укреплять профессиональное сотрудничество в Казахстане», — Евгений Бабицкий, сооснователь Compliance Control и директор Rakasta.

Профессиональная дискуссия с участниками конференции.

«Финтех в безопасности 2026» подтвердила значимость международного профессионального диалога и комплексного подхода к защите финансовой инфраструктуры. Обмен практическим опытом, развитие технологических решений и совместная работа с киберрисками остаются важными направлениями повышения устойчивости цифровой экономики.

Сообщение Compliance Control и Rakasta провели международную конференцию «Финтех в безопасности 2026» в Алматы появились сначала на Сompliance Сontrol.

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

Правовое обеспечение информационной безопасности — система нормативных актов, которая определяет, что защищать, кто отвечает и какие меры обязательны. Она выстроена иерархически: акт нижнего уровня не может противоречить вышестоящему.

Основа заложена в Конституции. После поправок 2020 года пункт «м» статьи 71 относит к ведению Российской Федерации обеспечение безопасности личности, общества и государства при применении информационных технологий и обороте цифровых данных.

Иерархия нормативно-правовых актов: какой документ имеет приоритет при противоречиях

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

Ведомственный уровень в ИБ самый плотный: приказы издают ФСТЭК, ФСБ, Роскомнадзор, Минцифры, нормативные акты — Банк России. Ниже всех — локальные акты организации.

Кроме вертикали работают два правила. Первое — приоритет специальной нормы над общей: для объектов КИИ требования 187-ФЗ применяются вместо расходящихся с ними норм 149-ФЗ. Второе: из двух актов одного уровня действует более поздний.

Законы информационной безопасности Российской Федерации: базовый фундамент (обзор ключевых ФЗ)

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

• 149-ФЗ «Об информации, информационных технологиях и о защите информации» — базовые понятия, права обладателя информации, общие обязанности по защите
• 152-ФЗ «О персональных данных» — требования к операторам, уведомление Роскомнадзора об обработке и об утечках
• 187-ФЗ «О безопасности критической информационной инфраструктуры» — категорирование объектов, обязанности субъектов КИИ, взаимодействие с ГосСОПКА

Помощь в категорировании объектов по 187-ФЗ входит в услугу по безопасности объектов КИИ.

Отдельные виды тайны и отраслевые процессы регулируют специальные законы: 98-ФЗ о коммерческой тайне, 63-ФЗ об электронной подписи, 161-ФЗ о национальной платежной системе, закон о государственной тайне.

Еще один слой образуют указы Президента: по юридической силе они ниже законов. Стратегические приоритеты задает Доктрина информационной безопасности (Указ № 646 от 5 декабря 2016 года), конкретные обязанности — Указ № 250 о дополнительных мерах по обеспечению ИБ и Указ № 166 о технологической независимости КИИ.

Роль стандартов и ведомственных актов в регулировании

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

Главная ошибка — считать все эти документы одинаково обязательными.

ГОСТ Р в информационной безопасности: обязательность применения и связь с техрегулированием

ГОСТ Р не является нормативно-правовым актом и по общему правилу применяется добровольно. Это правило статьи 26 Федерального закона № 162-ФЗ «О стандартизации в Российской Федерации», исключения из него устанавливает законодательство.

На практике обязательным стандарт становится в трех случаях. Первый — на него ссылается нормативный акт: Положения Банка России делают обязательным ГОСТ Р 57580 для кредитных и ряда некредитных финансовых организаций. Второй — его требует договор или техническое задание, в том числе в госзакупках. Третий — компания сама публично заявляет о соответствии стандарту.

Связь с техрегулированием проходит через 184-ФЗ «О техническом регулировании»: обязательны технические регламенты, а не стандарты. Для средств защиты информации статья 5 закона устанавливает особый порядок: требования к ним задают ФСТЭК и ФСБ. В ГИС, на значимых объектах КИИ и в ряде других систем средства защиты должны быть сертифицированы. На проверке решает сертификат, а не ссылка на ГОСТ в паспорте продукта.

Ключевой ГОСТ Р по информационной безопасности для финансового сектора — 57580, порядок оценки описан на странице услуги по ГОСТ Р 57580.

Нормативно-правовой акт в ИБ: как отличить рекомендательный документ от императивного

Отличить нормативно-правовой акт в ИБ от рекомендации можно по трем признакам: он издан уполномоченным органом, содержит общеобязательные правила и официально опубликован. Ведомственный приказ, как правило, дополнительно проходит регистрацию в Минюсте: без нее и без публикации он правовых последствий не влечет.

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

Методические документы ФСТЭК занимают промежуточное положение. Сами по себе они не НПА, но приказы отсылают к ним. Пример — Приказ ФСТЭК № 220 от 16 июля 2026 года: методики расчета показателей защищенности и зрелости значимых объектов КИИ должны соответствовать методическим документам ведомства. А методику оценки зрелости от 7 августа 2026 года регулятор применяет, чтобы судить об эффективности защиты у операторов по результатам их самооценки.

Учитывайте срок между принятием и вступлением в силу: тот же Приказ № 220 зарегистрирован в Минюсте 7 сентября 2026 года, а вступит в силу только 1 марта 2027 года.

Чек-лист: 5 шагов для аудита нормативной базы вашей организации

Аудит показывает, какие требования применимы и закрыты ли они документами. Начинать стоит со статуса компании, а не с изучения законов.

1. Определите правовой статус. Оператор персональных данных, субъект КИИ, оператор ГИС, финансовая организация. Каждый статус влечет свой набор обязательных актов
2. Составьте реестр применимых НПА с номерами, редакциями и датами вступления в силу
3. Отделите обязательное от добровольного. Для ГОСТов и методик указывайте акт или договор, который делает их обязательными, остальные помечайте как рекомендательные
4. Сверьте локальные акты с реестром. Политики и приказы не должны противоречить федеральным требованиям и ссылаться на отмененные документы
5. Назначьте ответственного за мониторинг изменений и закрепите порядок актуализации внутренних документов

Как оформить внутренние приказы и распределить полномочия, разобрано в статье про систему внутренних документов по ИБ.

FAQ: частые вопросы о нормативно-правовом обеспечении ИБ

Является ли ГОСТ Р обязательным к исполнению для коммерческих компаний?

По общему правилу нет: национальные стандарты применяются добровольно.

Обязательным ГОСТ становится, если на него ссылается нормативный акт, договор или техническое задание, либо компания сама заявила о соответствии. Пример — ГОСТ Р 57580 для банков.

Что делать, если требования внутреннего приказа компании противоречат федеральному закону?

Руководствоваться законом: противоречащая ему часть локального акта не применяется.

Приказ нужно привести в соответствие. Чаще всего противоречия возникают, когда документы ссылаются на отмененные акты.

Какие 3 основных закона формируют фундамент правового обеспечения ИБ в РФ?

Это 149-ФЗ «Об информации, информационных технологиях и о защите информации», 152-ФЗ «О персональных данных» и 187-ФЗ «О безопасности критической информационной инфраструктуры». Стратегические приоритеты задает Доктрина информационной безопасности, утвержденная Указом Президента.

Как отслеживать изменения в нормативно-правовых актах по информационной безопасности?

Законопроекты публикуются на sozd.duma.gov.ru, проекты ведомственных актов — на regulation.gov.ru, принятые акты — на publication.pravo.gov.ru, документы ФСТЭК — на сайте ведомства.

Имеют ли силу методические рекомендации ФСТЭК при прохождении проверки?

Прямой юридической силы у них нет: методические документы не являются нормативными актами.

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

Сообщение Нормативно-правовое обеспечение информационной безопасности в РФ: иерархия законов и ГОСТов появились сначала на Сompliance Сontrol.

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

Что такое «Проверка на прочность»?

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

Основные темы форума

В центре внимания участников оказались тестирование на проникновение, Red Team и Purple Team, управление уязвимостями, анализ поверхности атаки, автоматизация процессов информационной безопасности и применение искусственного интеллекта в оценке защищенности.

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

Комплексный подход к оценке защищенности

Аркадий Прокудин, коммерческий директор Compliance Control, принял участие в круглом столе «Объект оценки».

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

Исследовательская инфраструктура для анализа киберугроз

Евгений Кудашов, руководитель направления анализа защищенности Compliance Control, представил доклад «Исследовательский центр: как мы строим инфраструктуру для исследований безопасности».

Выступление прошло в рамках практической сессии «Пентест, Red Team, Purple Team. Где между ними проходит реальная граница?».

Эксперт посвятил выступление вопросам создания исследовательской инфраструктуры для изучения уязвимостей и сценариев кибератак. Подобные исследования позволяют развивать инструменты тестирования на проникновение, совершенствовать методики анализа защищенности и применять полученные результаты в практических проектах по информационной безопасности.

«В ходе участия в форуме „Проверка на прочность: практика анализа защищенности“ мы рассказали о работе нашего исследовательского центра. Тема вызвала отклик у коллег по отрасли. Программа форума подтвердила актуальность вопросов практического анализа защищенности в современных условиях», — отметил Евгений Кудашов, руководитель направления анализа защищенности Compliance Control.

Сообщение Эксперты Compliance Control выступили на форуме «Проверка на прочность 2026» появились сначала на Сompliance Сontrol.

«Финтех в безопасности» — международная площадка для обсуждения актуальных вопросов защиты финансовых технологий, регулирования и развития практик информационной безопасности.

Тренды в центре программы

В центре ташкентской программы оказались глобальные тренды информационной безопасности и их влияние на рынок Узбекистана, развитие цифровых финансовых сервисов, применение AI/ML, изменение роли CISO, кадровые вызовы IT- и ИБ-отрасли, международное регулирование и практические подходы к обеспечению киберустойчивости.

На открытии представители Compliance Control и Rakasta обозначили одну из главных идей конференции: безопасность современного финансового бизнеса невозможно рассматривать отдельно от технологий, регулирования, комплаенса и бизнес-процессов.

«Как сделать платежи, переводы и существование финансовых активов безопасными? Для решения этих задач важно объединять банки, финтех, ритейл, регуляторов и ИБ-экспертов на одной площадке», — Аркадий Прокудин, международный эксперт в кибербезопасности, коммерческий директор Rakasta.

Дискуссия «Вселенная безопасных платежей»

Центральным событием конференции стала пленарная дискуссия «Вселенная безопасных платежей». В ней приняли участие представители разных сегментов финансового рынка и ритейла: Бехзод Дехканов, CISO Турон Банка; Тимур Эмирсалиев, заместитель председателя Apex Bank; Александр Зорин, CISO Korzinka.uz; Зохир Мирзаев, CISO Asakabank; Фаёз Бахадыров, старший эксперт Центра кибербезопасности CERT-CBU, а также Аркадий Прокудин.

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

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

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

Одной из важных тем стала и трансформация роли CISO. По мере того как информационная безопасность всё глубже интегрируется в бизнес-процессы, от руководителя ИБ требуется не только техническая экспертиза, но и понимание бизнес-задач, регуляторной среды и принципов управления рисками.

Информационная безопасность в ритейле

В рамках пленарной части участники также обсудили специфику информационной безопасности в ритейле и роль качественного аудита в принятии управленческих решений.

«Эффективный внутренний аудит, который проводится не только для формальных результатов, приносит реальную пользу для CISO при оценке результатов его работы. Но если аудитор не понимает предметную область или не обладает достаточной компетентностью, наблюдения аудита могут нанести вред: сместить приоритеты или заставить компанию направить ресурсы на решение несуществующих проблем», — Александр Зорин, CISO Korzinka.uz.

Отдельный блок дискуссии был посвящён искусственному интеллекту и машинному обучению. Эксперты рассмотрели AI/ML одновременно как инструмент повышения эффективности и как новую область, требующую дополнительного контроля со стороны бизнеса и информационной безопасности.

«Искусственный интеллект сегодня — важнейший инструмент не только для IT и ИБ, но и для бизнеса. Однако наибольшую сложность представляют контроль его рационального и безопасного использования и оценка эффективности такого применения», — Александр Зорин, CISO Korzinka.uz.

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

Практическая реализация требований постановления ЦБ Узбекистана

Отдельно обсуждалась практическая реализация требований постановления Центрального банка Республики Узбекистан № 3669 и подходы, позволяющие встроить требования регулятора в реальные процессы управления безопасностью.

В рамках программы участники также рассмотрели PCI DSS и ISO, особенности применения стандартов в современной IT-инфраструктуре и практический эффект их корректного внедрения для бизнеса.

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

Пентесты и практика

Отдельная часть программы была посвящена пентестам и практическим кейсам. Эксперты Compliance Control показали, как тестирование на проникновение применяется для проверки внешнего и внутреннего периметра организаций, различных типов приложений и других элементов инфраструктуры.

«Мы представили свои компетенции в тестировании на проникновение внешнего и внутреннего периметра финтех-организаций и ритейла, а также веб-, мобильных и десктоп-приложений. На примерах из практики разобрали актуальные уязвимости. Отдельно рассказали о работе нашего исследовательского центра», — Евгений Кудашов, руководитель направления анализа защищённости Compliance Control.

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

Ещё одним направлением конференции стала автоматизация процессов аудита и комплаенса. Compliance Control представила Compliance APP — платформу для управления аудитом, рисками и соответствием, призванную объединить связанные с этими задачами процессы в единой среде.

Итоги

Подводя итоги конференции, представители Compliance Control и Rakasta отметили, что по мере развития цифровых финансовых сервисов вопросы безопасности всё теснее связаны с доверием между компаниями, клиентами и участниками платежной инфраструктуры. Одновременно возрастает значение международного обмена опытом: многие технологические и регуляторные задачи уже невозможно рассматривать исключительно в рамках одного рынка.»

«На подобных крупных мероприятиях мероприятиях удается собрать и обсудить мнения разных сторон — и безопасности и бизнеса и ИТ. В этом году основной фокус обсуждений был на доверии и единых критериях оценки качества обеспечения информационной безопасности. Мы были рады в очередной раз поделиться своим опытом с экспертным сообществом и будем продолжать укреплять безопасность финансового и финтех рынков Республики Узбекистан». — Евгений Бабицкий, сооснователь Compliance Control и Директор Rakasta.

Ташкентский «Финтех в безопасности 2026» продолжил международную серию мероприятий Compliance Control и Rakasta и стал площадкой для профессионального диалога между представителями финансового сектора, ритейла, технологических компаний и индустрии информационной безопасности.

Конференция объединила в одной повестке национальное регулирование, международные стандарты, аудит и комплаенс, пентесты, защиту инфраструктуры и технологические решения, показав, как эти направления могут работать как элементы единой системы безопасности бизнеса.

Сообщение Compliance Control и Rakasta провели международную конференцию «Финтех в безопасности 2026» в Ташкенте появились сначала на Сompliance Сontrol.

Среди гостей бизнес-завтрака представители бизнеса, руководители и специалисты по информационным технологиям и информационной безопасности. Формат объединил экспертные выступления и открытую дискуссию, в рамках которой участники смогли обсудить актуальные задачи ИБ и обменяться практическим опытом.

Деловая программа

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

Мероприятие открыл Рустам Сарыбаев, директор Академии устойчивого развития Союза банков Кыргызстана.

«Информационная безопасность сегодня —  это уже не только вопрос IT-подразделений. Это вопрос устойчивости бизнеса, защиты клиентов, данных и доверия к финансовой системе в целом. Поэтому особенно важно, что мы говорим не только о стандартах и требованиях, но прежде всего о практических инструментах и реальном опыте: от защиты инфраструктуры и безопасной разработки до построения эффективного SOC. Уверен, что открытый формат общения позволит участникам не только получить новые знания, но и обменяться решениями, которые можно применять на практике», — отметил Рустам Сарыбаев, директор Академии устойчивого развития Союза банков Кыргызстана.

Деловую программу продолжил Андрей Лупешко, директор по развитию бизнеса Compliance Control, который представил компетенции компании, международный опыт и основные направления работы в области информационной безопасности и ИБ-комплаенса.

Андрей Лупешко, директор по развитию бизнеса Compliance Control, представляет компетенции, опыт и ключевые направления деятельности компании.

Международный стандарт ISO/IEC 27001:2022 — Анастасия Платонова

О применении международного стандарта ISO/IEC 27001:2022 рассказала Анастасия Платонова, эксперт ИБ международного консалтинга Compliance Control. В своем выступлении она рассмотрела практические аспекты выполнения требований стандарта и построения системы управления информационной безопасностью.

Анастасия Платонова, эксперт ИБ международного консалтинга Compliance Control, рассказывает о практическом применении ISO/IEC 27001:2022.

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

Безопасность цифровых продуктов — Виктор Кривецкий

Тему безопасности цифровых продуктов продолжил Виктор Кривецкий, эксперт по безопасной разработке Compliance Control. В докладе «Как встроить безопасность в создание цифровых продуктов: от ИБ-контролей к Secure SDLC» он рассказал о том, как интегрировать требования безопасности непосредственно в процессы разработки и учитывать их на разных этапах жизненного цикла продукта.

Виктор Кривецкий, эксперт по безопасной разработке Compliance Control, рассказывает о переходе от отдельных ИБ-контролей к Secure SDLC.

Сервисы информационной безопасности и роли SOC — Семен Кошелев

Завершающий экспертный блок был посвящен сервисам информационной безопасности и роли SOC. Семен Кошелев, технический директор MSSP-направления Rakasta, рассказал о подходах к непрерывному мониторингу событий ИБ, управлению уязвимостями и контролю защищенности инфраструктуры.

«Современная информационная безопасность уже не может состоять из отдельных, не связанных между собой мер. Компаниям важно выстраивать непрерывный процесс: видеть происходящее в инфраструктуре, своевременно выявлять уязвимости, анализировать события и реагировать на потенциальные угрозы. SOC в этой модели становится центром, который объединяет технологии, процессы и экспертизу специалистов в единую систему защиты», — отметил Семен Кошелев, технический директор MSSP-направления Rakasta.

Семен Кошелев, технический директор MSSP-направления Rakasta, выступает с докладом о сервисах информационной безопасности и роли SOC.

Открытая дискуссия

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

Проведение «Киберзавтрака» в Бишкеке стало частью работы Compliance Control и Rakasta по развитию профессионального диалога в области информационной безопасности и обмену практической экспертизой с бизнесом и ИБ-сообществом Центральной Азии.

Участники «Киберзавтрака» Compliance Control и Rakasta в Бишкеке, 16 сентября 2026 года.

О компаниях Compliance Control и Rakasta

Compliance Control и Rakasta работают в области информационной безопасности, международного ИБ-комплаенса и консалтинга. В числе направлений деятельности компаний: международная сертификация и аудит, PCI DSS, ISO 27001, анализ защищенности и пентест, безопасная разработка, SOC/MSSP и другие направления информационной безопасности.

Сообщение Компании Compliance Control и Rakasta провели в Бишкеке бизнес-завтрак по информационной безопасности появились сначала на Сompliance Сontrol.