```html

ISO 27001 для поставщика промышленного ПО: какие процессы и документы проверить

ISO 27001 для поставщика промышленного программного обеспечения — это не только политика информационной безопасности и несколько приказов. Для компании, которая разрабатывает, внедряет и сопровождает SCADA, MES, IIoT-платформы, системы диспетчеризации, промышленной аналитики или другое ПО, система менеджмента информационной безопасности должна охватывать реальные процессы разработки и поддержки продукта.

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

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

Компания «МинпромХелп» подготовила практическое руководство: какую редакцию стандарта проверить, какие процессы поставщика промышленного ПО включить в СУИБ, какие документы подготовить и какие доказательства должны существовать не только на бумаге, но и в реальной работе компании.

Актуальность информации: сентябрь 2026 года.

ISO/IEC 27001 и ГОСТ Р ИСО/МЭК 27001: какую редакцию проверять

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

На международном уровне актуальной является редакция ISO/IEC 27001:2022 «Information security, cybersecurity and privacy protection — Information security management systems — Requirements».

В 2024 году к ней была опубликована Amendment 1, связанная с учётом вопросов изменения климата в контексте системы менеджмента.

В Российской Федерации одновременно действует ГОСТ Р ИСО/МЭК 27001-2021.

Здесь есть принципиальное различие: российский ГОСТ 2021 года идентичен международному стандарту ISO/IEC 27001:2013 с техническими поправками 2014 и 2015 годов, а не ISO/IEC 27001:2022.

Документ	Основа	Статус на сентябрь 2026 года
ISO/IEC 27001:2022	Международная редакция 2022 года	Действующая международная версия
ISO/IEC 27001:2022/Amd 1:2024	Поправка к редакции 2022 года	Опубликована
ГОСТ Р ИСО/МЭК 27001-2021	ISO/IEC 27001:2013	Действующий национальный стандарт РФ

Поэтому формулировки «ISO 27001», «ISO/IEC 27001:2022» и «ГОСТ Р ИСО/МЭК 27001-2021» нельзя автоматически считать одинаковыми требованиями.

Если заказчик требует сертификат именно на ISO/IEC 27001:2022, необходимо проверить соответствие сертификата этой редакции.

Если в закупочной документации указан ГОСТ Р ИСО/МЭК 27001-2021, необходимо анализировать именно это требование.

Что на самом деле подтверждает ISO/IEC 27001

ISO/IEC 27001 устанавливает требования к системе менеджмента информационной безопасности — СУИБ.

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

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

Что сертификат ISO 27001 не подтверждает автоматически

Наличие сертификата само по себе не означает, что:

• конкретная программа не содержит уязвимостей;
• исходный код прошёл государственную сертификацию безопасности;
• ПО соответствует требованиям ФСТЭК России;
• продукт автоматически может использоваться на любом объекте критической информационной инфраструктуры;
• программа автоматически соответствует требованиям реестра российского ПО;
• каждое обновление продукта прошло отдельную сертификацию;
• поставщик выполнил специальные требования конкретного промышленного заказчика.

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

Поэтому при оценке поставщика необходимо смотреть не только на номер сертификата, но и на область действия СУИБ.

Что должно входить в область СУИБ поставщика промышленного ПО

Ошибочная область сертификации — одна из проблем при подготовке ИТ-компании.

Например, в область СУИБ включены:

«оказание консультационных услуг в сфере информационных технологий».

Однако фактически компания:

• разрабатывает промышленное ПО;
• хранит исходный код;
• формирует сборки;
• выпускает обновления;
• подключается к инфраструктуре промышленных заказчиков;
• оказывает техническую поддержку.

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

Практическая область проверки

Процесс	Что необходимо определить
Разработка ПО	Входит ли Secure SDLC в область СУИБ
Хранение исходного кода	Какие репозитории и инфраструктура охвачены системой
Сборка и релизы	Включены ли CI/CD и хранилища артефактов
Техническая поддержка	Как защищаются обращения и данные клиентов
Удалённый доступ	Как регулируется подключение к системам заказчика
Облачная инфраструктура	Какие сервисы и провайдеры входят в область
Обработка инцидентов	Как выявляются, регистрируются и расследуются события ИБ

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

Какие обязательные элементы СУИБ необходимо проверить

ISO/IEC 27001 строится не вокруг одного комплекта шаблонных регламентов, а вокруг системы управления.

Организация должна определить свой контекст, заинтересованные стороны, риски, цели информационной безопасности, меры обработки рисков и порядок оценки эффективности СУИБ.

Основная структура требований включает:

• контекст организации;
• лидерство;
• планирование;
• поддержку;
• операционную деятельность;
• оценку результативности;
• улучшение.

Если организация заявляет соответствие ISO/IEC 27001, требования соответствующих разделов системы менеджмента нельзя просто исключить как «неприменимые».

1. Контекст организации и область СУИБ

Первый блок — понимание того, что именно компания защищает и от каких рисков.

Для поставщика промышленного ПО необходимо определить:

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

Какие документы проверить

• описание контекста организации;
• перечень заинтересованных сторон;
• перечень применимых требований;
• утверждённую область СУИБ;
• описание основных процессов;
• перечень информационных активов.

2. Политика информационной безопасности

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

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

Например, если политика предусматривает разграничение доступа, это должно подтверждаться фактическими настройками Git, CI/CD, VPN, облачной инфраструктуры и других систем.

Проверяемые документы

• политика информационной безопасности;
• приказ об её утверждении;
• распределение ролей и ответственности;
• подтверждение ознакомления сотрудников;
• цели информационной безопасности.

3. Оценка рисков информационной безопасности

Управление рисками — центральный элемент ISO/IEC 27001.

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

Для разработчика риски могут включать:

• компрометацию репозитория исходного кода;
• утечку закрытых компонентов;
• внедрение вредоносного кода;
• компрометацию учётной записи разработчика;
• кражу ключей подписи;
• нарушение CI/CD;
• зависимость от уязвимого стороннего компонента;
• несанкционированный доступ к инфраструктуре заказчика;
• потерю исходного кода;
• отказ облачного провайдера;
• нарушение доступности сервиса;
• ошибку сотрудника технической поддержки.

Основные документы

Документ	Что проверить
Методика оценки рисков	Как определяется вероятность и воздействие
Реестр рисков	Какие реальные риски поставщика учтены
План обработки рисков	Какие меры и ответственные назначены
Критерии приемлемости риска	Какие остаточные риски компания принимает
Результаты пересмотра	Актуализируются ли риски при изменениях продукта

4. Statement of Applicability: один из ключевых документов

Для ISO/IEC 27001 важным документом является Statement of Applicability — заявление о применимости мер.

Компания определяет необходимые меры в процессе обработки рисков и сопоставляет их с эталонным набором мер приложения A.

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

Для редакции ISO/IEC 27001:2022 приложение A содержит 93 меры, распределённые по четырём группам:

• организационные;
• связанные с персоналом;
• физические;
• технологические.

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

Что проверить в SoA

• все ли необходимые меры рассмотрены;
• указана ли применимость;
• обоснованы ли исключения;
• отражено ли фактическое состояние внедрения;
• совпадает ли SoA с планом обработки рисков;
• соответствуют ли меры реальным процессам компании.

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

5. Управление информационными активами

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

Для поставщика ПО активами могут быть не только серверы и ноутбуки.

Что включить в инвентаризацию

• репозитории исходного кода;
• GitLab, GitHub Enterprise или другие системы;
• CI/CD;
• хранилища артефактов;
• образы контейнеров;
• системы управления задачами;
• базы знаний;
• серверы разработки;
• тестовые среды;
• продуктивные облачные среды;
• ключи подписи;
• секреты и токены;
• документацию;
• резервные копии;
• данные заказчиков;
• рабочие станции сотрудников.

Доказательства

Рекомендуется подготовить реестр активов с владельцами, классификацией информации и правилами обращения.

6. Управление доступом к исходному коду

Для поставщика промышленного программного обеспечения это один из наиболее важных процессов.

Необходимо установить, кто и на каких основаниях получает доступ к:

• исходному коду;
• веткам релизов;
• CI/CD;
• ключам;
• хранилищам пакетов;
• продуктивной инфраструктуре;
• системам заказчиков.

Что проверять

Контроль	Доказательство
Предоставление доступа	Заявка или согласование руководителя
Изменение прав	История изменения ролей
Удаление доступа	Процедура увольнения и блокировки
Привилегированные права	Отдельный учёт администраторов
MFA	Настройки критичных систем
Периодический пересмотр	Протокол или отчёт ревизии доступов

Типовая ошибка — сотрудник уволен, но его учётная запись продолжает иметь доступ к репозиторию или VPN.

7. Безопасная разработка ПО

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

На практике необходимо определить собственный Secure SDLC.

Что проверить в процессе разработки

• формирование требований безопасности;
• архитектурные решения;
• моделирование угроз при необходимости;
• правила безопасного программирования;
• code review;
• тестирование безопасности;
• управление зависимостями;
• разделение сред разработки, тестирования и эксплуатации;
• управление тестовыми данными;
• порядок выпуска релизов.

Конкретный набор технических инструментов определяется рисками и архитектурой продукта.

ISO/IEC 27001 не требует от любой компании использовать конкретный коммерческий SAST-, DAST- или SCA-продукт. Важно показать, каким образом организация управляет соответствующими рисками.

Какие документы подготовить

• регламент безопасной разработки;
• правила работы с репозиторием;
• стандарт кодирования;
• чек-лист code review;
• регламент тестирования;
• порядок выпуска релиза;
• требования к разделению сред;
• отчёты автоматизированных проверок, если они используются;
• записи устранения выявленных проблем.

8. CI/CD и выпуск программных обновлений

Современный поставщик ПО часто использует автоматизированный конвейер сборки.

Его компрометация способна привести к распространению вредоносного кода сразу среди большого числа заказчиков.

Необходимо проверить:

• кто может изменять pipeline;
• кто может инициировать продуктивную сборку;
• как защищены runner-ы;
• где хранятся секреты;
• как защищаются артефакты;
• кто утверждает релиз;
• как идентифицируется версия;
• можно ли восстановить происхождение конкретной сборки.

Практические доказательства

• история pipeline;
• настройки ролей;
• журналы сборок;
• релизные карточки;
• согласование выпуска;
• контрольные суммы;
• журнал изменений;
• процедура отката.

9. Управление уязвимостями

Промышленное ПО может эксплуатироваться заказчиком много лет.

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

Процесс должен отвечать на вопросы

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

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

Документы

• политика или регламент управления уязвимостями;
• реестр выявленных уязвимостей;
• классификация критичности;
• записи исправлений;
• уведомления заказчикам;
• результаты повторного тестирования.

10. Open Source и сторонние программные компоненты

Современный промышленный продукт редко полностью создаётся без сторонних компонентов.

Использование Open Source необходимо рассматривать одновременно как юридический и информационно-безопасностный риск.

Компании рекомендуется знать:

• какие библиотеки используются;
• их версии;
• источник получения;
• лицензии;
• известные уязвимости;
• кто отвечает за обновление.

Для сложного продукта полезно формировать перечень программных компонентов или SBOM. Однако наличие SBOM не является само по себе универсальным обязательным требованием ISO/IEC 27001 для каждой организации.

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

11. Управление подрядчиками и поставщиками

Разработчик может использовать:

• облачного провайдера;
• ЦОД;
• внешних разработчиков;
• аутсорсинговый SOC;
• поставщиков библиотек;
• сервисы CI/CD;
• сервисы электронной почты;
• подрядчиков технической поддержки.

Передача части процессов третьей стороне не переносит автоматически все риски на подрядчика.

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

Что проверить

• перечень критичных поставщиков;
• оценку рисков поставщика;
• требования ИБ в договоре;
• условия уведомления об инцидентах;
• порядок привлечения субподрядчиков;
• правила предоставления доступа;
• периодический пересмотр поставщика;
• процедуру прекращения отношений.

Для отношений с поставщиками семейство ISO/IEC 27036 содержит дополнительные специализированные требования и рекомендации по управлению рисками цепочки поставок.

12. Удалённый доступ к промышленному заказчику

Для поставщика промышленного ПО это особенно критичный процесс.

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

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

Рекомендуется проверить

• кто разрешает подключение;
• используется ли персональная учётная запись;
• применяется ли MFA;
• ограничивается ли время доступа;
• какие системы доступны инженеру;
• ведутся ли журналы действий;
• как передаются файлы;
• где хранятся учётные данные заказчика;
• как блокируется доступ после завершения договора.

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

13. Управление изменениями

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

Необходимо обеспечить контролируемый процесс.

Этап	Что фиксировать
Инициирование	Описание изменения
Оценка	Риски и влияние
Тестирование	Результаты проверки
Согласование	Ответственное лицо
Релиз	Версия и дата
Откат	Порядок восстановления

14. Резервное копирование и восстановление

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

Необходимо проверить возможность восстановления.

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

• исходный код;
• база задач;
• документация;
• реестр релизов;
• конфигурация CI/CD;
• образы;
• ключи и сертификаты;
• базы данных облачного сервиса.

Документы и доказательства

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

15. Управление инцидентами информационной безопасности

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

Необходимо определить:

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

Документы

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

16. Журналирование и мониторинг

Если компания не ведёт достаточные журналы, после инцидента бывает невозможно установить, кто изменил код, выпустил сборку или получил доступ к системе.

Рекомендуется определить:

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

Для поставщика ПО особое значение имеют журналы репозитория, CI/CD, VPN, административных систем и облачной инфраструктуры.

17. Управление персоналом

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

Следует проверить

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

18. Непрерывность деятельности поставщика ПО

Для промышленного заказчика недоступность поставщика во время серьёзного сбоя может иметь значительные последствия.

Поэтому необходимо определить критические процессы и сценарии их восстановления.

Например:

• недоступен основной офис;
• утрачен сервер разработки;
• недоступен облачный провайдер;
• скомпрометирована инфраструктура CI/CD;
• недоступна техническая поддержка;
• повреждён основной репозиторий.

Документы

• анализ воздействия на бизнес;
• план непрерывности;
• план восстановления;
• контактные схемы;
• результаты тренировок;
• отчёты о тестировании восстановления.

19. Внутренний аудит СУИБ

До сертификационного аудита организация должна проверять собственную систему.

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

Следует проверить:

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

20. Анализ СУИБ со стороны руководства

Высшее руководство должно участвовать в функционировании системы, а не просто подписать политику перед сертификацией.

В рамках анализа рассматриваются, в частности:

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

По результатам анализа принимаются решения и назначаются действия.

21. Несоответствия и корректирующие действия

Наличие выявленного нарушения не означает автоматически провал системы.

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

Для каждого существенного несоответствия рекомендуется фиксировать:

• описание проблемы;
• причину;
• корректирующее действие;
• ответственного;
• срок;
• проверку результативности.

Какие документы подготовить поставщику промышленного ПО: итоговый чек-лист

Блок	Основные документы и доказательства
СУИБ	Область, политика, роли, цели
Риски	Методика, реестр рисков, план обработки
Применимость мер	Statement of Applicability
Активы	Реестр информационных активов
Доступ	Политика доступа, заявки, ревизии прав
Разработка	Secure SDLC, code review, тестирование
CI/CD	Правила сборки, роли, журналы релизов
Уязвимости	Регламент, реестр, исправления
Open Source	Перечень компонентов, лицензии, контроль версий
Поставщики	Реестр, оценка рисков, требования ИБ в договорах
Удалённый доступ	Регламент, согласования, журналы подключения
Изменения	Change management и релизные документы
Резервирование	Политика, журналы и тесты восстановления
Инциденты	Регламент, реестр, расследования
Мониторинг	Логи, события, правила реагирования
Персонал	Обучение, NDA, процессы приёма и увольнения
Непрерывность	Планы и результаты тестирования
Аудит	Программа и отчёты внутренних аудитов
Руководство	Протокол анализа СУИБ
Улучшение	Несоответствия и корректирующие действия

Как проверить готовность СУИБ перед сертификацией

Рекомендуем проводить проверку не по принципу «есть документ или нет», а по трём уровням.

Уровень	Контрольный вопрос
Документ	Процесс формально установлен?
Практика	Сотрудники действительно его выполняют?
Доказательство	Можно ли показать записи о выполнении?

Например, компания имеет регламент пересмотра доступа каждые три месяца.

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

Именно наличие объективных свидетельств отличает работающую СУИБ от комплекта шаблонов.

ISO 27001 и реестр российского ПО: это разные процедуры

Для поставщиков программного обеспечения важно не смешивать ISO 27001 и включение продукта в реестр российского программного обеспечения.

Реестр Минцифры регулируется отдельными нормативными требованиями и оценивает, в частности:

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

Наличие ISO/IEC 27001 не является универсальной заменой требованиям реестра российского ПО.

А включение программного продукта в реестр, в свою очередь, не подтверждает наличие сертифицированной СУИБ у его правообладателя.

Это два разных инструмента, которые могут дополнять друг друга.

ISO 27001 и требования промышленного заказчика

Промышленный заказчик может потребовать от поставщика дополнительные доказательства безопасности.

Например:

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

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

FAQ: ISO 27001 для поставщика промышленного ПО

Обязательно ли получать ISO 27001 для включения программы в реестр Минцифры?

ISO 27001 и включение в реестр российского ПО являются разными процедурами. Необходимо отдельно проверять требования действующей редакции ПП №1236 к конкретному программному продукту.

Сертификат ISO 27001 подтверждает безопасность конкретной программы?

Нет. Он подтверждает соответствие системы менеджмента информационной безопасности организации установленным требованиям в пределах указанной области сертификации.

Нужно ли применять все 93 меры приложения A ISO/IEC 27001:2022?

Не обязательно автоматически применять каждую меру. Организация определяет необходимые меры на основании оценки и обработки рисков и сопоставляет их с эталонным набором приложения A. Выбранный подход отражается в Statement of Applicability.

Нужно ли обязательно внедрять SAST и DAST?

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

Можно ли сертифицировать только один продукт?

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

Достаточно ли написать все регламенты перед аудитом?

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

Какой стандарт использовать в России: ISO/IEC 27001:2022 или ГОСТ Р ИСО/МЭК 27001-2021?

Это зависит от требования заказчика, тендера или выбранной схемы сертификации. Российский ГОСТ Р ИСО/МЭК 27001-2021 основан на ISO/IEC 27001:2013, тогда как актуальная международная версия — ISO/IEC 27001:2022. Перед сертификацией необходимо точно определить требуемый документ.

Помощь МинпромХелп при подготовке системы ISO 27001

Для поставщика промышленного программного обеспечения подготовка к ISO 27001 должна начинаться не с покупки шаблонов политик, а с анализа реального жизненного цикла продукта.

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

Компания «МинпромХелп» помогает предприятиям подготовиться к сертификации систем менеджмента информационной безопасности.

Мы помогаем:

• определить применимый стандарт и область сертификации;
• провести предварительный GAP-анализ;
• сформировать структуру СУИБ;
• подготовить реестр информационных активов;
• организовать оценку рисков;
• подготовить Statement of Applicability;
• разработать необходимые политики и регламенты;
• структурировать процессы безопасной разработки;
• подготовить внутренний аудит;
• сформировать доказательную базу для сертификационного аудита.

Разрабатываете промышленное ПО и заказчик требует ISO 27001?

Направьте специалистам «МинпромХелп» сведения о компании, структуру разработки, описание продукта, используемую инфраструктуру и формулировку требования заказчика.

Мы поможем определить применимый стандарт, объём подготовки и процессы, которые необходимо привести в соответствие до сертификационного аудита.

Получить консультацию по ISO 27001 для разработчика промышленного ПО →

Нормативные документы и официальные источники

• ISO/IEC 27001:2022 — Information security, cybersecurity and privacy protection — Information security management systems — Requirements.
• ISO/IEC 27001:2022/Amd 1:2024 — Amendment 1: Climate action changes.
• ISO/IEC 27002:2022 — Information security controls.
• ГОСТ Р ИСО/МЭК 27001-2021 — Системы менеджмента информационной безопасности. Требования.
• ГОСТ Р ИСО/МЭК 27002-2021 — Свод норм и правил применения мер обеспечения информационной безопасности.
• ISO/IEC 27036-2:2022 — Cybersecurity — Supplier relationships — Requirements.
• Постановление Правительства РФ №1236 — правила формирования и ведения реестра российского программного обеспечения.

```