Приказ ФСТЭК России № 117 действует с 1 марта 2026 года, и вместе с мерами защиты он принёс жёсткий календарь. Сутки на критическую уязвимость, неделя на высокую, полгода до следующего расчёта Кзи, три рабочих дня на отчёт руководителю. Часть сроков прописана в самом приказе, часть оператор обязан установить сам — во внутреннем регламенте.
Разберём все сроки приказа № 117 по пунктам, соберём их в одну таблицу и покажем, какие заявки службы информационной безопасности из них вытекают. Отдельно — чем хелпдеск ИБ отличается от обычного ИТ-хелпдеска и как вести сроки, чтобы показать их проверяющему.
Приказ ФСТЭК № 117 устанавливает для операторов государственных информационных систем конкретные сроки: устранить критическую уязвимость — не более 24 часов, высокую — не более 7 календарных дней, рассчитывать показатель Кзи — не реже раза в шесть месяцев, проводить контроль уровня защищённости — не реже раза в три года. Сроки для средних уязвимостей, обновлений и отчётов мониторинга оператор устанавливает во внутреннем регламенте.
Для кого действуют сроки приказа № 117
Требования приказа распространяются на государственные информационные системы, иные информационные системы государственных органов, государственных унитарных предприятий и государственных учреждений (п. 1). Для коммерческой компании без ГИС приказ № 117 не обязателен: её базой остаются 152-ФЗ и приказ ФСТЭК № 21, а для субъектов КИИ — приказ № 239.
При этом календарь из приказа полезен и тем, на кого он не распространяется. Сроки «сутки на критическую уязвимость» и «раз в полгода — оценка защищённости» стали ориентиром для отрасли: по ним удобно строить собственный регламент, даже если проверяющий придёт с другим приказом. Что изменилось с 1 марта и что делать в первую очередь — в статье «Приказ ФСТЭК № 117 вступил в силу», а полный разбор требований — в материале «Приказ ФСТЭК № 117: требования к защите ГИС».
Сроки по приказу ФСТЭК № 117: сводная таблица
Таблица собрана по тексту приказа в редакции приказа ФСТЭК № 137 от 08.05.2026. Колонка «Кому» показывает, кого нужно известить или кому сдать результат.
| Что | Срок | Кому | Пункт |
|---|---|---|---|
| Устранить уязвимость критического уровня или закрыть её компенсирующими мерами | не более 24 часов | — | 38 |
| Устранить уязвимость высокого уровня | не более 7 календарных дней | — | 38 |
| Устранить уязвимость среднего и низкого уровня | по внутреннему регламенту | — | 38 |
| Сообщить об уязвимости, которой нет в БДУ ФСТЭК | не более 5 рабочих дней с даты выявления | ФСТЭК России | 38 |
| Применить обновления, закрывающие уязвимости | по внутреннему регламенту, с учётом сроков устранения уязвимостей | — | 39 |
| Рассчитать показатель защищённости Кзи | не реже одного раза в 6 месяцев | — | 32 |
| Сообщить о несоответствии Кзи нормированному значению | в течение 3 календарных дней со дня завершения оценки | руководитель оператора | 32 |
| Направить результаты оценки Кзи | не позднее 5 рабочих дней после дня расчёта | ФСТЭК России | 32 |
| Отчёт о результатах мониторинга ИБ | с периодичностью и в сроки по внутреннему регламенту | руководитель, ответственное лицо | 49 |
| Последний за год отчёт мониторинга (или итоговый) | после представления руководителю | ФСТЭК России | 49 |
| Сообщить о неправомерном распространении информации ограниченного доступа | незамедлительно | руководитель, ответственное лицо | 40 |
| Восстановить значимые функции ИС 1 / 2 / 3 класса | не более 24 часов / 7 календарных дней / 4 недель с момента обнаружения нарушения | — | 53 |
| Проверить восстановление из резервных копий | не реже одного раза в 2 года | — | 55 |
| Оценить уровень знаний пользователей | не реже одного раза в 3 года или после компьютерного инцидента | — | 57 |
| Провести контроль уровня защищённости | не реже одного раза в 3 года или после компьютерного инцидента | — | 67 |
| Отчёт о контроле уровня защищённости | в течение 3 рабочих дней с даты завершения | руководитель, ответственное лицо | 67 |
| Направить отчёт о контроле уровня защищённости | в течение 5 рабочих дней с даты завершения | ФСТЭК России | 67 |
Если уязвимости и их сроки у вас пока живут в таблице, запросите демо КиберОснова SGRC: покажем учёт уязвимостей из БДУ ФСТЭК, контроль их устранения и расчёт Кзи в платформе.
Уязвимости и обновления: 24 часа и 7 дней
По пункту 38 приказа ФСТЭК № 117 уязвимость критического уровня опасности оператор устраняет или исключает возможность её использования компенсирующими мерами в срок не более 24 часов, уязвимость высокого уровня — не более 7 календарных дней. Сроки для средних и низких уязвимостей оператор сам определяет во внутреннем регламенте по защите информации.
Уровень опасности определяют по ГОСТ Р 56545-2015 — на него ссылается сам пункт 38. На практике его считают по CVSS и методике ФСТЭК: как это делается и где ошибаются чаще всего, разобрано в статье «Методика оценки критичности уязвимостей ФСТЭК». Быстро посчитать балл по вектору можно в CVSS-калькуляторе.
Отдельная обязанность — уязвимости, которых нет в банке данных угроз ФСТЭК. Если вы нашли такую, у оператора не более 5 рабочих дней с даты выявления, чтобы направить сведения в ФСТЭК России для оценки включения в БДУ. Проверить, есть ли уязвимость в банке, можно в реестре БДУ.
Пункт 39 не задаёт обновлениям жёсткого срока, но задаёт порядок: проверить подлинность и целостность обновления, протестировать его до применения в промышленном контуре, выдать разрешение на установку. Бесконтрольная установка обновлений не допускается. Сроки применения обновлений, закрывающих уязвимости, оператор устанавливает во внутреннем регламенте — в зависимости от сроков устранения уязвимостей соответствующего уровня.
Отсюда практический вывод: обновление для критической уязвимости должно пройти проверку, тест и разрешение так, чтобы уложиться в те же 24 часа. Если не укладывается — нужна компенсирующая мера, и её тоже стоит зафиксировать. Как оформить весь цикл, показано в статье «Регламент управления уязвимостями».
Кзи раз в полгода и отчёты в ФСТЭК
По пункту 32 приказа ФСТЭК № 117 оператор рассчитывает показатель защищённости Кзи не реже одного раза в шесть месяцев. Результаты оценки он направляет в ФСТЭК России не позднее 5 рабочих дней после дня расчёта. Если значение не соответствует нормированному, руководителя оператора информируют в течение 3 календарных дней со дня завершения оценки.
Получается два обязательных события в год и три срока вокруг каждого. Расчёт удобно привязать к фиксированным датам — например, к концу второго и четвёртого кварталов, — чтобы не пропустить полугодие. Что такое Кзи и как он складывается из критериев, разобрано в глоссарии, а прикинуть значение можно в калькуляторе Кзи.
Пункт 32 говорит и о показателе уровня зрелости. Порядок его оценки меняет приказ ФСТЭК № 137, и часть изменений вступает в силу позже, поэтому график по зрелости сверяйте с действующей редакцией на дату оценки.
Мониторинг, восстановление и резервные копии
Пункт 49 требует мониторинга информационной безопасности по разделам 4 и 5 ГОСТ Р 59547-2021 для всех систем, кроме локальных и изолированных — в них контролируют журналы регистрации событий. Подразделение по защите информации с периодичностью и в сроки, установленные внутренним регламентом, готовит отчёт о результатах мониторинга для руководителя. Последний в году отчёт или итоговый отчёт за год после представления руководителю направляют в ФСТЭК России.
Пункт 53 приказа ФСТЭК № 117 задаёт интервалы восстановления информационных систем, выполняющих значимые функции: для систем 1 класса защищённости — не более 24 часов с момента обнаружения нарушения функционирования, 2 класса — не более 7 календарных дней, 3 класса — не более 4 недель. Конкретный интервал оператор закрепляет во внутренних стандартах и регламентах.
Чтобы эти интервалы были реальными, пункт 55 требует проверять восстановление из резервных копий не реже одного раза в два года, в том числе в форме тренировок, с привлечением работников, которые будут восстанавливать системы. Периодичность самого резервного копирования, количество и типы носителей определяет внутренний регламент.
Контроль защищённости и обучение пользователей
Контроль уровня защищённости проводят не реже одного раза в три года или после компьютерного инцидента (п. 67). Методы перечислены в пункте 66: выявление уязвимостей с экспертной оценкой, выявление несанкционированных подключений устройств, тестирование через моделирование актуальных угроз, тренировки работников. По итогам составляют отчёт, подписанный проводившими контроль. Руководителю его представляют в течение 3 рабочих дней с даты завершения контроля, в ФСТЭК России направляют в течение 5 рабочих дней. Что ещё смотрит регулятор при проверке, разобрано в статье «Что проверяет ФСТЭК при проверках».
С пользователями работают по пунктам 56 и 57. Мероприятия по повышению знаний включают памятки и баннеры, лекции и семинары, имитационные фишинговые рассылки и тренировки. Оценку уровня знаний проводят не реже одного раза в три года или после компьютерного инцидента. Пользователей без нужных знаний направляют на повторное обучение. Как провести инструктаж и что в нём должно быть, рассказываем в статье «Инструктаж по информационной безопасности».
Какие сроки вы устанавливаете сами
Почти половина сроков приказа № 117 отсылает к внутреннему регламенту. Пункт 14 «д» перечисляет порядки, которые в нём должны быть: учётные записи и привилегированные учётные записи, аутентификационная информация, удалённый доступ, доступ подрядчиков и иных органов, доступ в интернет, повышение знаний пользователей, управление уязвимостями, управление обновлениями и другие.
Регламент — не формальность. Если срок не записан, проверяющий не сможет сравнить с ним факт, а служба ИБ не сможет доказать, что уложилась. Минимальный набор сроков, которые стоит закрепить явно:
- устранение уязвимостей среднего и низкого уровня;
- применение обновлений по уровням уязвимостей;
- периодичность и сроки отчётов мониторинга;
- периодичность резервного копирования и интервалы восстановления;
- периодичность и формы оценки знаний пользователей;
- методы и периодичность контроля уровня защищённости.
Политики и регламенты под требования приказа готовят в модуле документов ИБ КиберОснова SGRC. Как выглядит такой регламент и как он связан с учётом активов и уязвимостей, покажем на демостенде — запросите демо.
Что такое хелпдеск ИБ и чем он отличается от ИТ-хелпдеска
Хелпдеск информационной безопасности — это контур, в котором служба ИБ принимает и ведёт заявки по своим обязанностям: доступы, уязвимости, обновления, события безопасности, отчёты. В отличие от ИТ-хелпдеска, сроки заявок в нём задаёт не договорённость с пользователями, а норма — например, 24 часа на критическую уязвимость по приказу ФСТЭК № 117.
Обычный ИТ-хелпдеск отвечает на вопрос «восстановили ли сервис для пользователя». Хелпдеск ИБ отвечает на другой вопрос: «выполнила ли организация обязанность в срок и может ли это показать». Отсюда три отличия:
- Срок привязан к пункту нормы. Тип заявки «критическая уязвимость» несёт срок из пункта 38, а не из внутреннего SLA.
- Журнал — доказательство. История заявки показывает, когда уязвимость выявили, кто её оценил, когда закрыли и чем. Это то, что спросят на проверке.
- Заявки связаны с активами и документами. Уязвимость относится к конкретному активу, а порядок её устранения — к конкретному регламенту.
Подробнее о том, что такое Service Desk и чем он отличается от хелпдеска, — в статье «Service Desk: что это такое».
Какие заявки служба ИБ получает из приказа № 117
| Тип заявки | Пункт | Срок по норме |
|---|---|---|
| Создание, изменение, блокирование учётной записи | 14 «д» | по внутреннему регламенту |
| Привилегированный доступ | 14 «д» | по внутреннему регламенту |
| Удалённый доступ | 14 «д» | по внутреннему регламенту |
| Доступ подрядчика или работника иного органа | 14 «д» | по внутреннему регламенту |
| Уязвимость критического уровня | 38 | не более 24 часов |
| Уязвимость высокого уровня | 38 | не более 7 календарных дней |
| Уязвимость, которой нет в БДУ | 38 | сведения в ФСТЭК — не более 5 рабочих дней |
| Обновление: проверка, тест, разрешение | 39 | по внутреннему регламенту |
| Утечка информации ограниченного доступа | 40 | руководителю — незамедлительно |
| Расчёт Кзи и отчёт | 32 | раз в 6 месяцев; в ФСТЭК — 5 рабочих дней |
| Отчёт о мониторинге | 49 | по внутреннему регламенту |
| Контроль уровня защищённости и отчёт | 66, 67 | раз в 3 года; руководителю — 3 рабочих дня, в ФСТЭК — 5 |
| Оценка знаний пользователей | 57 | раз в 3 года или после инцидента |
Часть заявок плановая: расчёт Кзи, контроль защищённости, оценка знаний, проверка восстановления. Их удобно завести заранее на год вперёд. Остальные возникают по событию — новая уязвимость, запрос доступа, утечка, — и для них важно, чтобы срок начал считаться с момента выявления, а не с момента, когда кто-то вспомнил о проблеме.
Как вести сроки: таблица, ITSM или отдельный контур
Таблица. Работает, пока заявок мало и за сроками следит один человек. Слабое место — нет истории: по таблице сложно доказать, когда уязвимость выявили и кто разрешил обновление.
Общий ITSM. Если ИТ-хелпдеск уже есть, в нём можно завести категории ИБ. Ограничение в том, что ITSM-система не знает про БДУ ФСТЭК, Кзи и регламенты по пункту 14 «д»: сроки и связи придётся настраивать вручную. Подробнее о том, как устроены ITSM-системы, — в статье «ITSM: что это такое».
Отдельный контур ИБ. Заявки ведутся рядом с учётом активов, уязвимостей и документов. Так в КиберОснова SGRC уже работают учёт уязвимостей из БДУ ФСТЭК, учёт активов с импортом из Kaspersky Security Center и Zabbix, автоматизация требований приказа № 117 с расчётом Кзи и модуль документов ИБ. Service Desk для ИБ, который свяжет заявки с этими данными и сроками из нормы, мы сейчас строим вместе с участниками пилота.
Учёт инцидентов как отдельный модуль в платформе пока не реализован. Если инциденты у вас уже ведутся по ГОСТ Р 59547-2021, разберитесь, как устроен процесс, в статье «Управление инцидентами ИБ».
Календарь службы ИБ на год
Плановые сроки приказа № 117 складываются в простой календарь. Даты ниже — пример, а не требование: привяжите их к своему регламенту.
- Каждые 6 месяцев: расчёт Кзи → при несоответствии руководителю за 3 календарных дня → результаты в ФСТЭК за 5 рабочих дней.
- По регламенту, например ежеквартально: отчёт о мониторинге руководителю.
- Конец года: последний или итоговый отчёт мониторинга — руководителю, затем в ФСТЭК.
- Раз в 2 года: тренировка восстановления из резервных копий.
- Раз в 3 года и после инцидента: контроль уровня защищённости с отчётом за 3 и 5 рабочих дней; оценка знаний пользователей.
- Постоянно: уязвимости — 24 часа и 7 дней; уязвимости вне БДУ — 5 рабочих дней; обновления — по регламенту.
Итог
Приказ ФСТЭК № 117 задаёт службе ИБ два типа сроков: жёсткие, прописанные в самом приказе, и те, что оператор обязан закрепить во внутреннем регламенте. Первые — 24 часа и 7 дней на уязвимости, полгода на Кзи, три года на контроль защищённости, 3 и 5 рабочих дней на отчёты. Вторые — средние уязвимости, обновления, мониторинг, резервные копии и обучение.
Чтобы уложиться в оба типа, сроки нужно записать, заявки — вести с историей, а плановые события — завести на год вперёд. Начните с регламента и таблицы сроков из этой статьи, а когда заявок станет больше, чем помещается в таблицу, переходите к отдельному контуру ИБ.
