ФСТЭК-сертификация ПО: процедура, сроки, стоимость и лабораторные испытания

ФСТЭК-сертификация ПО — это не «один документ на согласование». Это процедура на 6-14 месяцев с лабораторными испытаниями, экспертизой, многократной доработкой продукта и бюджетом 3-8 млн ₽. Большинство команд-разработчиков впервые сталкиваются с сертификацией, когда контракт уже подписан, и оказываются в ситуации, когда продукт нужно сертифицировать «вчера», а реальный срок — год. Эта статья — для тех, кто хочет понять процедуру до начала проекта, а не во время.

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

Когда нужна сертификация ПО во ФСТЭК

Три основных сценария, когда сертификация обязательна.

Применение в значимых объектах КИИ. По приказам ФСТЭК № 17 (государственные ИС), № 21 (ПДн), № 31 (АСУ ТП в КИИ), № 235 (значимые объекты) и № 239 (для значимых объектов КИИ) операторы обязаны применять сертифицированные СЗИ. Если ваш заказчик — субъект КИИ с категорированными объектами (банк, оператор связи, ТЭК, транспорт, здравоохранение, химия и др. — 13 сфер по ФЗ-187), ПО должно быть сертифицировано. Подробнее про требования КИИ — в нашей статье про защиту КИИ и категорирование объектов КИИ.

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

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

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

Классы защищённости и оценочные уровни доверия

ФСТЭК различает классы защищённости (зависят от типа СЗИ) и оценочные уровни доверия (ОУД, аналог Common Criteria EAL).

Классы защищённости для СЗИ от НСД (приказ ФСТЭК):

• Класс 6 — самый низкий, общедоступная информация, минимальные требования
• Класс 5 — конфиденциальная информация
• Класс 4 — служебная тайна
• Класс 3 — стандарт для значимых объектов КИИ К3, государственных ИС класса 3, ИСПДн УЗ-3
• Класс 2 — значимые объекты КИИ К2, государственные ИС класса 2, ИСПДн УЗ-2
• Класс 1 — самый высокий, гостайна, КИИ К1, государственные ИС класса 1

Аналогичные классы существуют для:

• Межсетевых экранов (плюс типы А — пакетный фильтр, Б — приложений и так далее)
• Антивирусов (6 классов)
• Систем обнаружения вторжений (6 классов)
• Средств доверенной загрузки (СДЗ — 6 классов)
• Средств контроля целостности (6 классов)

Оценочные уровни доверия (ОУД):

• ОУД 1-2 — базовый анализ
• ОУД 3-4 — стандартный, для большинства коммерческих СЗИ
• ОУД 5-6 — высокий, для критически важных
• ОУД 7 — формальная верификация (применяется редко)

Класс защищённости определяется заранее, исходя из назначения продукта. Если планируется применение в КИИ К3 — нужен класс 3 (СЗИ от НСД), 3 (МЭ) и так далее. Заявить на сертификацию более высокий класс «впрок» можно, но это удлиняет процедуру и удорожает её в 1,5-2 раза.

Процедура сертификации: от подачи до сертификата

Полная последовательность шагов.

Шаг 1. Подготовка продукта (2-4 месяца)

До подачи в лабораторию ПО должно соответствовать требованиям выбранного класса. Что обычно делается:

• Архитектурный анализ соответствия требованиям приказов ФСТЭК
• Доработка функциональных модулей (разграничение доступа, аудит, контроль целостности)
• Внедрение Secure SDLC: SAST, DAST, SCA в pipeline разработки. Подробнее про этот процесс — в материале про Secure SDLC
• Анализ зависимостей и закрытие известных CVE в open-source компонентах
• Подготовка технической документации (архитектура, описание функций, инструкция оператора, программа испытаний)
• Внутренние тесты безопасности

Шаг 2. Выбор лаборатории и заключение договора (1-2 месяца)

Поиск аккредитованной испытательной лаборатории, проверка её специализации, согласование стоимости и сроков. Подписание договора. Передача программы и методики испытаний (ПМИ) на согласование.

Шаг 3. Испытания в лаборатории (3-6 месяцев)

Лаборатория проверяет ПО по ПМИ:

• Функциональные испытания (соответствие заявленным возможностям)
• Тесты разграничения доступа
• Тесты аудита и журналирования
• Проверка криптомеханизмов (если применимо)
• Тесты на уязвимости (по подходящим методикам)
• Анализ исходного кода (статический и динамический)
• Тесты в режиме сбоев, восстановление

По результатам — протокол испытаний. Если выявлены несоответствия — продукт возвращается на доработку. Это нормальный этап: типично 20-40% начальных испытаний выявляют несоответствия. Бывают «прохождение с первой попытки» (редко), а бывает 2-3 цикла доработки.

Шаг 4. Экспертиза в ФСТЭК (1-2 месяца)

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

Шаг 5. Получение сертификата

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

При существенных изменениях продукта (новая архитектура, новые модули с функциями защиты) — внеплановая ресертификация. Стоит 50-70% от первоначальной сертификации.

Аккредитованные лаборатории ФСТЭК

Реестр аккредитованных испытательных лабораторий ФСТЭК официально опубликован и регулярно обновляется. В 2026 году около 30 активных лабораторий. Самые крупные на российском рынке.

ИспЛаб (Москва). Один из старейших и самых активных игроков. Аккредитация на большинство типов СЗИ. Сильная сторона — большой штат экспертов, опыт работы с госзаказчиками. Сроки: 4-6 месяцев на типовой продукт. Стоимость средне-высокая.

ЦБИ (Центр безопасности информации, Москва). Активный игрок, особенно в части СЗИ от НСД и операционных систем. Сильная сторона — опыт работы с ОУД 4-6. Сроки сопоставимы с ИспЛаб.

ЦентрИнформ (Москва). Часть инфраструктуры ФСБ/ФСТЭК. Сильная сторона — работа с криптографическими СЗИ и сложными комплексами. Заказчики чаще из госсектора и финансов.

Информзащита. Крупный игрок с собственной инфраструктурой испытаний. Хорошо работает с СОВ, МЭ, антивирусами.

Эшелон. Активен в части операционных систем, прикладного ПО, СЗИ.

НПЦ Криптоника, Конфидент, СтэлС и другие — менее крупные, но активные в специализированных нишах (например, криптоСЗИ, защищённые СУБД).

Выбор лаборатории зависит от нескольких факторов:

1. Совпадение её аккредитации с вашим классом и типом продукта
2. Опыт работы с похожими продуктами в портфолио
3. Доступность (некоторые лаборатории загружены на 6-12 месяцев вперёд)
4. Стоимость работ
5. Сроки выполнения

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

Что должно быть в продукте до подачи

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

1. Разграничение доступа. Идентификация и аутентификация пользователей, разграничение прав по ролям, контроль попыток входа, блокировка после неудачных попыток. Не «логин-пароль с одной таблицей», а полноценная подсистема прав.

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

3. Контроль целостности. Контрольные суммы критически важных файлов, проверка при запуске, реакция на нарушение целостности. Для класса 3 и выше — обязательный механизм.

4. Криптомеханизмы. Если используется шифрование — только сертифицированные криптопровайдеры (КриптоПро, ViPNet CSP, Сигнал-КОМ). Никаких OpenSSL «как есть» — он не сертифицирован ФСТЭК и не пройдёт.

5. Защита от типовых атак. Минимум: защита от SQL-инъекций, XSS, CSRF, переполнения буфера, обход аутентификации. SAST/DAST в pipeline разработки. Подробнее — в статье про Secure SDLC.

6. Документация. Описание архитектуры, схемы потоков данных, описание функций безопасности, инструкция администратора, программа и методика испытаний (ПМИ). Объём — 300-800 страниц для среднего продукта.

7. Контроль зависимостей. Список open-source компонентов с версиями, лицензиями, известными CVE. Все критические CVE должны быть закрыты.

Сроки и бюджет

Этап	Срок	Бюджет
Подготовка продукта (доработка, документация, тесты)	2-4 месяца	1-3 млн ₽
Выбор лаборатории, договор, согласование ПМИ	1-2 месяца	0,1-0,3 млн ₽
Испытания в лаборатории	3-6 месяцев	1-3 млн ₽
Доработка по результатам испытаний	1-3 месяца	0,5-1,5 млн ₽
Экспертиза ФСТЭК и оформление	1-2 месяца	0,3-0,8 млн ₽
Итого, первая сертификация	6-14 месяцев	3-8 млн ₽
Повторная сертификация (через 5 лет)	4-8 месяцев	2-5 млн ₽
Внеплановая ресертификация при значимых изменениях	3-6 месяцев	1,5-4 млн ₽
Поддержка сертификата (год)	—	0,3-0,8 млн ₽

Типичные ошибки разработчиков

Начало без анализа требований. Команда читает «сертификация — это формальность» и начинает разработку без учёта классов защищённости и приказов ФСТЭК. Через 6 месяцев приходит к лаборатории, которая объясняет: «архитектурно вы не соответствуете классу 3, нужно переписывать модули доступа и аудита». +6-8 месяцев и в 2 раза больше бюджета.

Open-source без контроля. Продукт построен на 200+ зависимостях из npm, PyPI, Maven. Никто не отслеживает CVE. На испытаниях лаборатория находит 30 критических уязвимостей. Закрытие — 3-6 месяцев.

Документация «потом». Программа разработки 12 месяцев, документация — 2 недели в конце. Получается 50-100 страниц вместо нужных 500-800. Лаборатория отказывается принимать продукт без полной документации. +1-2 месяца.

Использование зарубежного криптопровайдера. Команда использует OpenSSL, не подозревая, что для сертификации нужен КриптоПро. Переделка — 2-4 месяца.

Выбор лаборатории по цене. Команда выбирает самую дешёвую лабораторию, не проверив её специализацию. Лаборатория не аккредитована на нужный тип СЗИ — пакет документов возвращается, поиск заново. +3-4 месяца.

Игнорирование изменений требований. ФСТЭК периодически выпускает разъяснения, обновляет приказы. Команда работает по версии 2022 года, на испытаниях оказывается, что 2025 год ужесточил требования. +1-3 месяца на доработку.

С чего начать проект сертификации

Сценарий для команды, которая впервые планирует сертификацию.

1. Определить требуемый класс защищённости. Исходя из назначения продукта: КИИ К1/К2/К3, государственные ИС, ИСПДн. Это влияет на всю последующую работу.
2. Аудит соответствия. Внешний аудит продукта на предмет соответствия требованиям ФСТЭК для выбранного класса. Стоимость 300-500 тыс ₽, срок 2-4 недели. На выходе — список несоответствий и план работ.
3. План подготовки. На основе аудита — детальный план: что доработать в коде, какие документы создать, какие тесты провести. Срок и бюджет реалистичной подготовки — 2-4 месяца и 1-3 млн ₽.
4. Внедрение Secure SDLC. SAST/DAST/SCA в pipeline разработки, регулярная проверка зависимостей, документирование изменений. Подробнее — в нашей статье про Secure SDLC.
5. Поиск лаборатории заранее. Многие лаборатории загружены на 6-12 месяцев вперёд. Договорённость о слоте лучше получать на этапе подготовки продукта, а не «когда готовы».
6. Юридический пакет. Договоры, NDA, передача документации — должно быть отработано юристом с опытом в ФСТЭК-проектах.
7. Резерв бюджета и сроков. Заложите 30-50% буфера на доработки по результатам испытаний — это норма для первой сертификации.

ФСТЭК-сертификация ПО — это серьёзный проект на год и 3-8 млн ₽ для одного продукта. Главная экономия — заложить требования сертификации в архитектуру с самого начала разработки, а не пытаться «пройти как есть». Подробнее про общий контекст защиты КИИ — в наших статьях про защиту КИИ, категорирование, требования ФСТЭК.