Обзор Приказа ФСТЭК России от 11.04.2025 № 117

Дата: 21.12.2025 г.
Автор статьи: Иван Вершинин — Руководитель направления аттестации информационных систем

Скачать презентацию и Дорожную карту↓

Требования Приказа ФСТЭК России от 11.04.2025 № 117

Требования Приказа ФСТЭК России от 11.04.2025 № 117 «Об утверждении Требований о защите информации, не составляющей государственную тайну, содержащейся в государственных информационных системах, иных информационных системах государственных органов, государственных унитарных предприятий, государственных учреждений» (далее — Приказ ФСТЭК России № 117) вступают в силу с 1 марта 2026 года и распространяются не только на ГИС, но и на иные ИС госорганов, государственных унитарных предприятий, госучреждений. Невыполнение требований грозит правовой ответственностью (например, КоАП РФ Статья 13.12: штрафы до 50 000 рублей и 100 000 рублей для должностных и юридических лиц соответственно).

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

Ниже рассказываем, что стоит знать о Требованиях.

Организация защиты информации

1. Должна быть разработана и утверждена политика защиты информации (требования к содержанию политики приведены в п. 14 Приказа ФСТЭК России № 117 ).
2. Установлены конкретные требования к содержанию внутренних стандартов по ИБ (п. 14 Приказа ФСТЭК России № 117). Фактически, в требованиях указано, стандарты для каких процессов ИБ необходимо разработать. В стандартах должны быть закреплены:
   • требования к первичной идентификации пользователей;
   • требования к применяемым моделям доступа пользователей;
   • перечень разрешенного/запрещенного ПО;
   • требования к типовым конфигурациям и настройкам программных, программно-аппаратных средств (в т.ч. предназначенных для обеспечения доступа к сети «Интернет», удаленного доступа);
   • требования к обеспечению безопасной дистанционной работы;
   • ограничения и запреты действий для пользователей при использовании информационных систем;
   • требования к защите физических и виртуальных устройств информационных систем, имеющих постоянный доступ к сети «Интернет»;
   • требования к защите мобильных устройств, планшетных, переносных компьютеров;
   • требования к непрерывности функционирования ИС;
   • требования к резервному копированию информации, программного обеспечения и его конфигураций;
   • требования к сбору, регистрации и анализу событий безопасности;
   • требования к защите информации при подключении к внешним информационным системам, включая требования к каналам передачи данных при взаимодействии с такими информационными системами.
3. Аналогично установлены требования к содержанию внутренних регламентов по ИБ (п. 14). Разница между стандартами и регламентами – в уровне документов: в стандартах закрепляются общие положения, требования и ответственность, в регламентах прописываются процедуры в рамках конкретных мероприятий. В регламентах закрепляется:
   • порядок создания, учета, изменения и блокирования, контроля, удаления учетных записей (в т.ч. привилегированных);
   • порядок создания, изменения, блокирования, контроля, удаления аутентификационной информации и средств аутентификации;
   • порядок предоставления пользователям удаленного доступа;
   • порядок и условия предоставления работникам подрядных организаций доступа к ИС, контроля за таким доступом;
   • порядок предоставления работникам иных государственных органов, организаций доступа к ИС и контроля за такими доступом;
   • порядок предоставления пользователям ИС доступа в сеть «Интернет» и контроля ее использования;
   • порядок повышения уровня знаний и информированности пользователей по вопросам защиты информации;
   • порядок выявления, оценки и устранения уязвимостей ИС;
   • порядок получения, оценки, тестирования и применения обновлений программных, программно-аппаратных средств;
   • порядок обработки, хранения и обращения с информацией ограниченного доступа;
   • порядок обеспечения физической защиты ИС;
   • порядок разработки безопасного программного обеспечения в случае его самостоятельной разработки;
   • порядок вывода в контур промышленной эксплуатации сервисов, доступ к которым осуществляется с использованием сети «Интернет»;
   • порядок мониторинга информационной безопасности ИС;
   • порядок восстановления штатного функционирования ИС и тестирования процессов восстановления;
   • порядок контроля уровня защищенности информации, содержащейся в ИС.
4. Обязанности по исполнению положений политики защиты информации, стандартов и регламентов должна закрепляться в договорах с подрядчиками (п. 16, п. 26).
5. Защиту информации должен организовывать руководитель оператора (обладателя информации) или ответственное лицо. Обязанности и полномочия ответственного за защиту информации лица должны быть определены в его должностной инструкции (п. 18).
6. Должно быть создано структурное подразделение или назначены отдельные специалисты по защите информации. Функции и полномочия структурного подразделения должны быть закреплены в положении о подразделении, функции и полномочия отдельных специалистов – в должностных инструкциях (п. 19).
7. Специалисты по защите информации должны обладать соответствующими компетенциями, а не менее 30% специалистов подразделения по защите информации должны иметь соответствующее профессиональное образование или пройти обучение по программе профессиональной переподготовки (п. 20). Требований к высшему образованию нет. Количество часов программы профессиональной подготовки будет составлять не менее 250 часов, конкретные требования будут определены ФСТЭК России. Назначить формального ответственного теперь будет сложнее.
8. Во внутренних стандартах и регламентах должны быть закреплены средства защиты информации, необходимые специалистам по защите информации (п. 23). Скорее всего, будет достаточно указать типы/классы средств защиты, применение которых должно быть обеспечено, а также порядок их применения.
9. Теперь в законе закреплено требование к выделению руководством ресурсов (материальных, кадровых, финансовых) на мероприятия по защите информации (п. 27). Специалисты по защите информации направляют руководству предложения с обоснованием необходимости выделения ресурсов, включая указание негативных последствий, которые могут возникнуть в случае отсутствия ресурсов. Так, если ресурсы не были выделены, и по этой причине не была предотвращена атака на ИС, совесть специалистов по защите информации будет чиста.

Требования к мероприятиям по защите информации

1. К планированию мероприятий подход стал основательнее – нужно определить и события, которые могут привести к нарушению целей ИБ, и критичные системы, и даже ресурсы, необходимые для реализации мероприятий по защите информации (п. 29). Под ресурсами, вероятно, понимается количество привлекаемых к мероприятию работников, их временные трудозатраты и средства защиты, которые будут применяться в ходе реализации мероприятий. Интересно, что в Требованиях не указано на необходимость разработки какого-либо документа (плана), но рекомендуем всё-таки предусмотреть его.
2. В обязательном порядке должна проводиться оценка состояния защиты информации на основе показателя защищенности и показателя уровня зрелости (п. 31). Оценка показателя защищенности должна проводиться не реже одного раза в шесть месяцев. Оценка показателя уровня зрелости должна проводиться не реже одного раза в два года (п. 32). Результаты оценки состояния защиты должны направляться в ФСТЭК России не позднее 5 рабочих дней после их расчета (п. 32). В Требованиях не уточнено, но предполагаем, что результаты направляются в территориальное управление ФСТЭК России.
3. Если оценка состояния защиты показала, что нормированные значения показателя защищенности или уровня зрелости не достигнуты, разрабатывается план мероприятий по совершенствованию защиты информации (п. 33). Несмотря на то, что разработка плана мероприятий осуществляется «по решению руководителя», она является обязательной в соответствии с методическим документом ФСТЭК России от 11.11.2025 «Методика оценки показателя состояния технической защиты информации в информационных системах и обеспечения безопасности значимых объектов критической информационной инфраструктуры Российской Федерации» (действие методического документа распространяется на ИС государственных организаций).
4. Модели угроз для ГИС всё ещё обязательны, а вот для иных ИС они разрабатываются по решению организации (п. 36). При этом в ходе планирования мероприятий по защите информации должны быть выявлены и оценены угрозы безопасности информации (п. 29), поэтому для иных ИС разработка модели угроз настоятельно рекомендуется.
5. Контроль конфигураций ИС проводится на основе анализа результатов учета ИТ-активов. Учет ИТ-активов проводится в соответствии с требованиями постановления Правительства Российской Федерации от 1.07.2024 г. № 900 «О порядке учета ИТ-активов, используемых для осуществления деятельности по цифровой трансформации системы государственного (муниципального) управления» или при помощи систем инвентаризации ИТ-активов (п. 37). *Постановление Правительства Российской Федерации № 900 является обязательным для организаций, владеющих ГИС.
6. Установлены требования к срокам устранения уязвимостей (п. 38):
   • не более 24 часов для критических уязвимостей;
   • не более 7 календарных дней для уязвимостей высокого уровня критичности;
   • для иных уязвимостей организация определяет сроки самостоятельно, но фиксирует их во внутренних документах.
7. Если в ходе анализа уязвимостей были обнаружены уязвимости, отсутствующие в БДУ ФСТЭК, сведения о таких уязвимостях должны направляться в ФСТЭК России в течение 5 рабочих дней с даты выявления (п. 38). При этом не указано, какие конкретно сведения должны направляться, в какое управление ФСТЭК России. Рекомендуется направлять в территориальное управление ФСТЭК России сведения о наименовании уязвимого программного обеспечения, его версии, идентификатор уязвимости в других источниках, а также наименование и описание уязвимости при их наличии. Копию всех писем о направлении сведений по уязвимостям рекомендуется хранить бессрочно или до появления уязвимости в БДУ ФСТЭК, чтобы регулятор не придрался к наличию в организации уязвимостей, о которых не доложено во ФСТЭК России.
8. В отношении обновлений требуется проводить проверку подлинности, целостности и их тестирование (п. 39). Проверка обновлений должна осуществляться на тестовых компьютерах/в тестовых сегментах, отделенных от сегментов промышленной эксплуатации ИС. Каждое обновление должно быть санкционировано – то есть, на его установку должно быть выдано разрешение. Требований к оформлению разрешений не предъявлено, но рекомендуется их оформлять в виде хотя бы электронных писем или служебных записок. Бесконтрольная установка обновлений полностью запрещена, поэтому рекомендуется предусмотреть средства централизованного управления обновлениями и запрет на установку обновлений непривилегированными пользователями вручную.
9. Обязательным становится требование по определению перечня сведений ограниченного доступа и предназначенных для их хранения программно-аппаратных средств (п. 40). Лучше, если это будет закреплено документально, например, в виде реестра информации ограниченного доступа с указанием компьютеров (их логических, сетевых имен или адресов), на которых ведётся обработка такой информации.
10. Все факты доступа пользователей к аппаратно-программным средствам, где ведется обработка информации ограниченного доступа, должны контролироваться и регистрироваться (п. 40). На каждом программно-аппаратном средстве должны быть настроены политики регистрации доступа в систему (например, настройка записи в журнале аудита ОС события входа в ОС), а если такой возможности нет, необходимо регистрировать факты физического доступа к оборудованию, например, в специальном журнале.
11. Защита конечных устройств должна исключать возможность несанкционированного доступа к конечным устройствам или воздействия на них через интерфейсы и порты, непосредственно взаимодействующие с сетью «Интернет» (п. 41). Таким образом подчеркивается необходимость установки МЭ, СОВ уровня сети или хоста.
12. Защита конечных устройств должна предусматривать проведение на них мониторинга и анализа событий и процессов, а также предупреждение о событиях безопасности (п. 41). Вероятно, теперь обязательным требованием к защите конечных точек будет наличие в инфраструктуре решений классов SIEM, EDR.
13. Доступ к ИС с использованием мобильных устройств должен осуществляться с применением защищенных каналов передачи данных и с применением строгой аутентификации (многофакторной взаимной аутентификации и использованием криптографических протоколов аутентификации) (п. 42).
14. Использование для доступа к ИС личных мобильных устройств допускается, если они соответствуют Требованиям и, если оператор может контролировать их использование (п. 43).
    Примечание: представители ФСТЭК России, выступавшие на ТБ Форуме в феврале 2025 года, заявили, что требования к защите мобильных устройств разработаны с большим расчётом на ноутбуки, чем на мобильные телефоны, планшеты, так как обеспечить безопасность последних пока что невозможно.
15. Удаленный доступ внутренних пользователей к ИС должен осуществляться с использованием технических средств, выделенных организацией. Могут использоваться и личные устройства, но при условии применения сертифицированных средств обеспечения безопасной дистанционной работы, средств антивирусной защиты и иных средств защиты (п. 46).
16. Удаленный доступ должен осуществляться только с использованием сетей связи, расположенных на территории РФ, при условии защиты канала связи и применении строгой аутентификации (п. 46).
17. Беспроводные точки доступа пользователей к ИС должны быть однозначно идентифицированы, должны быть определены места их размещения. Точки беспроводного доступа должны быть настроены таким образом, чтобы исключать возможность несанкционированного подключения к ним устройств из-за пределов контролируемой зоны (п. 47).
18. Беспроводные точки доступа пользователей к ИС и построенные на их основе беспроводные сети должны быть изолированы от беспроводных сетей, имеющих доступ к сети «Интернет» и/или общедоступной информации (п. 47).
19. Привилегированные учетные записи, имеющие права по созданию других привилегированных учетных записей, должны быть персонифицированными, не допускается объединение в рамках одной привилегированной учетной записи или одной группы привилегированных учетных записей ролей по системному администрированию, ролей по разработке и тестированию программных, программно-аппаратных средств, ролей администраторов безопасности. Теперь каждый указанный процесс должен реализовываться от имени своей учетной записи, созданной специально для этих целей. Встроенные привилегированные учетные записи должны быть отключены, в случае невозможности – переименованы, а их аутентификационная информация – изменена (п. 48).
20. Привилегированный доступ должен осуществляться с применением строгой аутентификации, а в случае технической невозможности применения строгой аутентификации – с использованием усиленной многофакторной аутентификации (п. 48).
21. Все действия по доступу пользователей с использованием привилегированных учетных записей подлежат регистрации (п. 48).
22. Мониторинг информационной безопасности (сбор данных о событиях безопасности, их обработка и анализ, выявление признаков реализации угроз) должен проводиться в отношении всех ИС, кроме локальных и изолированных (для них реализуется контроль журналов событий безопасности) (п. 49). Снова о SIEM/EDR. В ИС, которые невозможно подключить к централизованной SIEM или EDR-системе, будет достаточно контролировать регистрируемые в журналах СЗИ события безопасности.
23. Специалисты по защите информации регулярно (в соответствии с внутренним регламентом) разрабатывают и предоставляют руководству (ответственному за информационную безопасность) отчет о результатах мониторинга. Последний в текущем году отчет или итоговый отчет за год о результатах мониторинга за прошедший год направляется организацией в ФСТЭК России (п. 49). Форма отчёта не установлена, но отчет должен содержать обнаруженные типы событий безопасности, связанные с ним компьютерные инциденты (при наличии) и рекомендации по их анализу и/или устранению.
24. В случае самостоятельной разработки оператором программного обеспечения для ИС, должны быть реализованы меры, предусмотренные разделами 4 и 5 ГОСТ Р 56939-2024 (п. 50).
25. В случае разработки программного обеспечения подрядчиком допускается включение в техническое задание требований, предусмотренных ГОСТ Р 56939-2024 (п. 50).
26. Разрешенные к использованию съемные МНИ подлежат учету и контролю использования. Подключение неизвестных МНИ к ИС запрещается (п. 51).
27. Установлены требования к срокам восстановления функционирования ИС (п. 53):
    • для ИС 1 класса защищенности – не более 24 часов с момента обнаружения нарушения функционирования;
    • для ИС 2 класса защищенности – не более 7 календарных дней с момента обнаружения нарушения функционирования;
    • для ИС 3 класса защищенности – не более 4 недель с момента обнаружения нарушения функционирования.
28. Программные, программно-аппаратные средства, обеспечивающие выполнение значимых функций, должны быть развернуты в отказоустойчивой конфигурации (п. 54). Таким образом, предъявляются требования, в том числе, к кластеризации ИС.
29. Резервные копии информации, необходимой для выполнения значимых функций, должны храниться в достаточном количестве на разных типах машинных носителей информации в местах, исключающих несанкционированный доступ к резервным копиям информации (п. 55).
30. Не реже чем раз в 2 года должны проводиться проверки возможности восстановления ИС из резервных копий (п. 55). Форма отчетности не установлена, но рекомендуется предусмотреть план восстановления, который будет отрабатываться с установленной периодичностью. По итогам проверки рекомендуется составлять акт, в котором будут отмечены результаты проверки и предложения по совершенствованию процессов восстановления ИС.
31. В случае превышения интервалов времени восстановления ИС, должна быть обеспечена возможность выполнения пользователями значимых функций, в том числе в неавтоматизированном режиме (п. 55). То есть, необходимо заранее определить, как пользователи продолжат свою работу, если ИС не удастся восстановить вовремя. Разумно решать этот вопрос совместно с подразделениями, эксплуатирующими ИС, так как они имеют лучшее представление о том, что им необходимо для выполнения своих задач, как их возможно перестроить в случае выхода ИС из строя. Сценарии выполнения задач альтернативным способом требуется закрепить во внутренних документах. Рекомендуется составить план конкретных действий изменения процессов выполнения задач в случае выхода ИС из строя с указанием сроков и ответственных.
32. Оценка уровня знаний пользователей по вопросам защиты информации должна проводиться не реже 1 раза в 3 года или после компьютерного инцидента (п. 57). Формы повышения уровня знаний устанавливаются внутренними стандартами и регламентами. В случае неудовлетворительной оценки для работника проводится повторное обучение.
33. Подрядчики, осуществляющие обработку и хранение полученной в результате предоставленного доступа к ИС информации, должны принимать меры по защите информации (п. 58). Класс защищенности, которому должны соответствовать подрядчики, владелец ИС устанавливает на основе Требований и отражает во внутренних регламентах.
34. Разработка и тестирование программного обеспечения подрядчиками в ИС не допускается (п. 58). Для проведения работ по разработке и тестированию работникам подрядных организаций должен быть предоставлен доступ к специально выделенным стендам разработки и тестирования, которые должны быть изолированы от эксплуатируемых ИС.
35. Должно быть обеспечено взаимодействие с ГосСОПКА и взаимодействие в автоматизированном режиме с Центром мониторинга и управления сетью связи общего пользования (п. 59). Это делается в рамках защиты ИС, которым необходим постоянный доступ к Интернету, от атак типа «отказ в обслуживании». При этом такое взаимодействие и защита от DoS/DDoS в целом должны осуществляться с привлечением провайдеров хостинга, услуг связи или организаций, оказывающих услуги по контролю, фильтрации и блокированию трафика.
36. Для ИС должны разрабатываться перечни ресурсов сети «Интернет», с которыми может взаимодействовать ИС, включающим исходящий и входящий сетевые потоки, их характеристики и используемые протоколы (п. 59).
37. Предъявлены требования к мероприятиям по обеспечению защиты информации при использовании для функционирования ИС искусственного интеллекта (п. 61).

Требования к мерам защиты информации

1. После адаптации базового набора мер защиты теперь идёт верификация этого набора – уточнение набора мер, в соответствии с актуальными угрозами безопасности, усиление мер (п. 62). Про дополнение набора мер требованиями из других НПА не сказано, но в первых пунктах Требований обозначена необходимость исполнения требований НПА по защите КИИ и ПДн, если ИС является значимым объектом КИИ или ИСПДн.
2. Среди мер защиты информации появились новые (п. 63), изменения выделены красным цветом:
   • защита виртуализации и облачных вычислений;
   • защита технологий контейнерных сред и их оркестрации;
   • защита сервисов электронной почты – вероятно, в первую очередь защита от спама и антивирусный контроль почтового трафика;
   • защита веб-технологий – скорее всего, в первую очередь обеспечение доступности веб-сервисов и применение WAF;
   • защита программных интерфейсов взаимодействия приложений – потребуется внедрить специальные средств защиты таких интерфейсов;
   • защита конечных устройств – применение решений EDR, хостовых МЭ, СОВ;
   • защита мобильных устройств – изоляция вычислительной среды, применение СКЗИ для сетевых соединений и шифрования дисков;
   • защита технологий интернета вещей;
   • защиты точек беспроводного доступа;
   • обнаружение и предотвращение вторжений на сетевом уровне – такое уточнение подтверждает предположение о том, что хостовые СОВ относятся к защите конечных точек, то есть, теперь сетевого СОВ может оказаться недостаточно;
   • защита от атак, направленных на отказ в обслуживании – требования были добавлены в конце 2024 в старый приказ № 17, но не нашли отражения в его таблице-приложении с мерами. Но есть и уже знакомые группы мер, реализация которых вряд ли поменяется:
   • идентификация и аутентификация;
   • управление доступом;
   • регистрация событий безопасности;
   • антивирусная защита;
   • сегментация и межсетевое экранирование;
   • защита каналов передачи данных и сетевого взаимодействия.
3. Для защиты ИС допускается использовать только сертифицированные СЗИ (п. 71).
4. Мероприятия и меры по защите информации, предусмотренные Требованиями, должны реализовываться оператором (обладателем информации) с использованием методических документов ФСТЭК России (п. 68). Просто лишний раз напоминаем, что для всего описанного выше будут методички.
5. Традиционно предусмотрена возможность реализации компенсирующих мер защиты (п. 69).
6. Технические меры должны применяться на аппаратном, системном, прикладном уровнях, а также в информационно-телекоммуникационной инфраструктуре (п. 70). На аппаратном и системном уровнях защита должна обеспечиваться встроенными в аппаратное обеспечение и системное программное обеспечение средствами защиты. На прикладном и сетевом (инфраструктурном) уровнях защита обеспечивается встроенными в прикладное программное обеспечение средствами защиты или наложенными и сетевыми средствами защиты. Регулятор подчеркивает, что защита должна строиться на всех уровнях: от мер на уровне BIOS до мер на уровне сети. При этом реализовать меры защиты на одном уровне средствами другого не получится (если речь не идет о компенсирующих мерах, применение которых подлежит обоснованию), поэтому стоит подумать над внедрением средств защиты, реализующих требуемые меры на нужном уровне.
7. Создание системы (подсистемы) защиты информации ГИС должно предусматривать реализацию мероприятий, определенных в постановлении Правительства Российской Федерации от 06.07.2015 № 676. Создание системы (подсистемы) защиты информации иных ИС должно предусматривать реализацию мероприятий, определенных в разделе 5 ГОСТ Р 51583-2014 «Защита информации. Порядок создания автоматизированных систем в защищенном исполнении. Общие требования» (п. 73).

Классификация, аттестация и контроль

1. Классы защищенности ИС остались без изменений (Приложение № 1), за исключением уточнения критериев отнесения информации к определённому уровню значимости. Теперь любой информации «Для служебного пользования» автоматически присваивается первый уровень значимости (УЗ 1). Рекомендуется пересмотреть присвоенные классы защищенности, если в ИС обрабатывается информация «ДСП».
2. Аттестации подлежат только ГИС. Аттестация иных ИС проводится по решению организации (п. 65). При этом ГИС, аттестованные по старому приказу № 17, до вступления в силу Требований не подлежат переаттестации. Но! Наличие аттестата соответствия по приказу № 17 не означает, что в отношении уже аттестованной ИС не нужно реализовывать требования нового приказа № 117. Таким образом, после вступления в силу требований приказа № 117 потребуется оценить степень их выполнения для ИС. Если будет установлена потребность во внедрении новых средств защиты, изменения архитектуры существующей системы защиты, необходимо провести или дополнительные аттестационные испытания, или повторную аттестацию (в зависимости от тех изменений, которые будут внесены в порядок защиты ИС, систему защиты ИС).
3. Необходимо проводить контроль уровня защищенности (п. 66). Периодичность и порядок устанавливаются во внутренних документах организации, но не реже, чем 1 раз в 3 года или после компьютерного инцидента (п. 67). Контроль проводится один из следующих способов (или совокупностью способов):
   • выявление уязвимостей ИС и оценка возможности их использования нарушителем;
   • выявление несанкционированных подключений устройств к ИС;
   • тестирование на проникновение;
   • проведение тренировок по отработке действий по обеспечению требуемого уровня защищенности информации в условиях реализации актуальных угроз.
4. Отчет о контроле уровня защищенности должен направляться в ФСТЭК России в течение 5 рабочих дней с даты завершения контроля (п. 67). Отметим, что отчет о контроле уровня защищенности в течение 3 рабочих дней предоставляется руководителю организации для принятия решения о выделении ресурсов с целью повышения уровня защищенности информации – если контроль покажет неудовлетворительный результат, он будет основанием для получения дополнительных ресурсов специалистами по защите информации.

Термины, сокращения и определения

БДУ ФСТЭК — база данных угроз ФСТЭК России — это ресурс, содержащий сведения об уязвимостях программного и программно-аппаратного обеспечения, а также перечень и описание угроз безопасности информации для информационных систем различного назначения

ГИС — государственная информационная система

ГосСОПКА — государственная система обнаружения, предупреждения и ликвидации последствий компьютерных атак

ДСП — для служебного пользования

ИБ — информационная безопасность

ИС — информационная система

КИИ — критическая информационная инфраструктура

КоАП РФ — Кодекс Российской Федерации об административных правонарушениях

МЭ — межсетевой экран

НПА — нормативно-правовой акт

ОС — операционная система

ПДн — персональные данные

ПО — программное обеспечение

СЗИ — средства защиты информации

СКЗИ — средства криптографической защиты информации

СОВ — система обнаружения вторжений

Съемные МНИ — съёмные машинные носители информации

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

В начало статьи ↑

Соглашение об использовании шаблонов документов

Документы (их формы), размещенные в настоящем разделе сайта, являются интеллектуальной собственностью ООО «Альтирикс системс» (ИНН 7811463860) и подлежат правовой защите в соответствии с законодательством Российской Федерации. Использование данных материалов без разрешения правообладателя допускается исключительно в целях, не связанных с предпринимательской и иной приносящей доход деятельностью. Загружая документы, вы соглашаетесь с условиями использования документов.