Слово «сертификат» в требованиях тендера звучит одинаково, а за ним могут стоять три совершенно разные вещи: ISO/IEC 27001, NIST CSF и приказы ФСТЭК. Я видел компании, которые заказывали аудит ISO 27001 с формулировкой «теперь мы защищены по всем требованиям», а через полгода получали предписание за невыполнение приказа ФСТЭК № 17. Видел и обратное: отдел ИБ годами закрывает бумаги по ГОСТ, но не может показать ни реестр рисков, ни процесс управления изменениями.
Это не конкурирующие стандарты. Они отвечают на разные вопросы, и выбор «или-или» здесь почти всегда проигрышный. Разберём по существу — без придыхания перед трёхбуквенными аббревиатурами.
Три документа — три разных вопроса
- ISO/IEC 27001 — про управление: процессы, ответственность, риски, постоянное улучшение. Отвечает на вопрос «как организовать ИБ, чтобы она не держалась на одном энтузиасте».
- NIST CSF и SP 800-53 — про содержание: каталог мер и общий язык с инженерами. Отвечает на вопрос «что конкретно настроить и как это проверить».
- ГОСТ и приказы ФСТЭК/ФСБ — про обязательства перед государством. Отвечает на вопрос «что с вас спросят при проверке», и здесь выбора обычно нет.
ISO/IEC 27001: система менеджмента, а не набор настроек
Главное заблуждение: ISO 27001 воспринимают как чек-лист технических настроек. Нет, стандарт сертифицирует систему управления информационной безопасностью (СУИБ, ISMS) — то есть то, как вы принимаете решения, а не то, какой у вас фаервол.
Что реально требуется
- описать контекст: какие активы, какие заинтересованные стороны, какие обязательства;
- оценить риски и зафиксировать решение руководства о допустимом уровне (аппетит к риску);
- выбрать меры из приложения A и обосновать, почему какие-то не применяются;
- держать доказательства: политики, журналы, записи об обучении, результаты внутренних аудитов;
- реагировать на несоответствия и улучшать процесс — цикл замыкается не на бумаге.
В редакции 2022 года мер стало 93 вместо 114, и они сгруппированы в четыре темы: организационные (37), связанные с людьми (8), физические (14) и технологические (34). Появились пункты про threat intelligence, безопасность облаков, непрерывность ИКТ и мониторинг. Переходный период на версию 2022 года, по данным IAF, завершился 31 октября 2025 года — если у вас на руках сертификат на 2013-ю версию, его пора переоформлять.
Где ломается на практике
Самая частая история: компания покупает сертификат под тендер, консультант пишет 40 политик, аудитор их принимает, а через год выясняется, что политики никто не читал, реестр рисков не обновлялся, а инциденты фиксируются в переписке.
- Реестр рисков ради галочки. Если в нём 300 строк, сгенерированных по шаблону, он бесполезен: по нему нельзя принять решение.
- Нет владельцев рисков. Пока риск не закреплён за конкретным человеком с бюджетом, он не лечится.
- СУИБ живёт в вакууме. Если у разработки свой процесс релизов, а у ИБ — свой, вы получите два параллельных мира и ноль влияния на продукт.
Сертификация — это двухэтапный аудит (сначала документы, потом практика), затем ежегодные надзорные аудиты и ресертификация раз в три года. По опыту рынка, для компании на 50–200 человек подготовка занимает от полугода до года, а бюджет — от нескольких сотен тысяч рублей только на аудит, без учёта внедрения мер.
NIST CSF 2.0 и SP 800-53: инженерный каталог без обязательств
NIST — это не закон и не стандарт в юридическом смысле. Это институт стандартов США, который публикует открытые документы. Сертификата по NIST не существует, и это его главное преимущество: вы берёте ровно то, что применимо.
Фреймворк по кибербезопасности NIST CSF в версии 2.0 (опубликован 26 февраля 2024 года) описывает шесть функций: Govern, Identify, Protect, Detect, Respond, Recover. Добавленный по сравнению с первой версией Govern — как раз про то, чего обычно не хватает: распределение ролей, политику, управление рисками на уровне руководства. Документ намеренно короткий, его можно прочитать за вечер, и он хорошо ложится на разговор с бизнесом.
SP 800-53 Revision 5 — уже совсем другой жанр: порядка 1200 мер и их усилений, разбитых по семействам, плюс базовые наборы Low/Moderate/High в 800-53B и процесс управления рисками RMF (SP 800-37). Это удобный справочник, когда нужно понять, что конкретно должно быть в журналировании, управлении доступом или реагировании на инциденты.
Кому подходит
- продуктовым командам, которым нужен общий язык между ИБ и разработкой;
- компаниям без внешних мандатов, которые хотят взрослую программу безопасности, а не сертификат;
- тем, кто строит отчётность для совета директоров и инвесторов;
- всем, кто ищет mapping: NIST официально сопоставляет CSF и 800-53 с ISO 27001, так что «перевести» меры из одного мира в другой можно без боли.
Минус один: NIST ничего не требует. Если в компании нет воли что-то менять, фреймворк останется красивой презентацией. Он хорошо работает как содержание, но не как двигатель.
ГОСТ и приказы ФСТЭК: когда выбора нет
Российская специфика в том, что здесь есть безусловно обязательные документы, и их выполнение проверяют. Краткая карта, чтобы не путаться:
- 152-ФЗ и постановление правительства № 1119 — уровни защищённости персональных данных УЗ-1…УЗ-4 и требования к ним; конкретный состав мер — приказ ФСТЭК № 21 и, если используется криптография, приказ ФСБ № 378.
- Приказ ФСТЭК № 17 — защита государственных информационных систем, классы К1–К3.
- Приказ ФСТЭК № 31 — автоматизированные системы управления технологическими процессами.
- 187-ФЗ и приказ ФСТЭК № 239 — значимые объекты критической информационной инфраструктуры.
- ГОСТ Р 57580.1-2017 — методика Банка России с несколькими уровнями защиты; для кредитных организаций и платёжной отрасли де-факто обязательна.
- ГОСТ Р ИСО/МЭК 27001-2021 — национальная гармонизация ISO 27001; удобно, когда заказчик требует «по ГОСТ», а вы привыкли работать по ISO.
Отдельно проговорю то, что регулярно путают: сертификат ISO 27001 не означает соответствия 152-ФЗ и не заменяет оценку эффективности мер по приказу № 21. Модель угроз и уровень защищённости ПДн определяются по российской логике, а не по ISO. Точно так же аттестация ГИС — это не «ISO на минималках», а отдельная процедура с аккредитованным органом.
Плюс российских документов — конкретика: перечень мер с классами и уровнями. Минус — они почти не описывают жизненный цикл: как поддерживать соответствие между проверками, оттуда не узнать. Именно здесь пригодится ISO.
Как выбрать: четыре вопроса к себе
- Есть ли обязательный регулятор? ГИС, персональные данные, КИИ, финансы — начинайте с ФСТЭК, ЦБ и ГОСТ, потому что штрафы и предписания приходят оттуда. ISO — вторым слоем.
- Нужен ли сертификат заказчику? Если в тендерах и на Enterprise-переговорах его спрашивают — ISO 27001 окупается как коммерческий инструмент. Если нет — честно посчитайте, что даст сертификат, кроме рамки на стене.
- Какая у вас зрелость? Если процессов ИБ нет вообще, ISO даст каркас: кто за что отвечает и как принимаются решения. Если каркас есть, а не хватает технической глубины — берите NIST 800-53 как справочник.
- Сколько ресурсов готовы выделить? ISO — это отдельная роль (пусть даже на part-time) и постоянные усилия: внутренние аудиты, анализ со стороны руководства, обновление рисков. NIST можно внедрять постепенно, начиная с одного домена.
Схема, которая работает у большинства
Универсального ответа нет, но рабочая связка выглядит так. Обязательные требования регулятора закрываем первыми — это гигиена, без неё остальное не имеет значения. Поверх строим СУИБ по ISO 27001 (можно без сертификации, если она не нужна рынку): риски, владельцы, политики, внутренний аудит. Технические меры и уровень детализации берём из NIST, потому что там проще найти язык с инженерами и удобные сопоставления.
Ключевая мысль: не надо выбирать между стандартами. Надо один раз зафиксировать, что у вас есть три слоя — закон, управление и инженерия, — и не пытаться закрыть все три одним документом.
Чек-лист перед стартом
- выписать все регуляторные требования, которые к вам применимы: данные, отрасль, тип систем;
- понять, требует ли рынок сертификат, и получить это требование письменно от отдела продаж;
- провести инвентаризацию активов и систем — без неё любой стандарт превращается в теорию;
- собрать первичный реестр рисков на 10–20 реальных сценариев, а не 300 шаблонных строк;
- назначить владельца СУИБ и человека, отвечающего за техническую часть;
- заложить бюджет на внешний аудит и на внедрение мер, а не только на первый;
- определить метрики: время устранения критичных уязвимостей, доля активов под мониторингом, число повторных инцидентов.
И последнее. Любой из трёх документов бесполезен, если после аудита ничего не меняется. Разница между «сертифицированы» и «защищены» — ровно в том, что происходит в остальные 364 дня года.
