Аудит подрядчиков по информационной безопасности: как проверять вендоров ПО

Более 60% инцидентов ИБ связаны с компрометацией поставщиков. ISO 27001 требует системного управления рисками цепочки поставок. В этой статье — матрица оценки вендоров, алгоритм аудита второй стороны и практические рекомендации по контрактным требованиям.

Пошаговая методика аудита вендора ПО

На основе требований ISO 27001, ISO 27036 и практики проведения аудитов ИБ поставщиков мы выделяем шесть ключевых этапов проверки вендора программного обеспечения:

Этап 1. Классификация поставщика по уровню критичности. Прежде чем проводить аудит, определите, к какой категории относится вендор. Критерии: объём обрабатываемых данных, доступ к критичным системам, возможность влияния на непрерывность бизнеса. Вендор CRM-системы с доступом к клиентской базе — это уровень «высокий», поставщик офисных канцтоваров — «низкий».

Этап 2. Запрос документации и самооценка. Направьте вендору опросник (Security Assessment Questionnaire, SAQ). Запросите: политику ИБ, наличие сертификатов (ISO 27001, SOC 2), результаты последнего пентеста, описание процессов управления уязвимостями, план реагирования на инциденты. Вендор заполняет опросник и прикладывает подтверждающие документы.

Этап 3. Анализ полученных данных. Оцените полноту и достоверность предоставленной информации. Типичный «красный флаг» — вендор утверждает, что «у нас всё защищено», но не может предоставить ни одного документа. Сравните ответы с вашими требованиями из политики управления поставщиками (контроль A.5.19).

Этап 4. Выездной или удалённый аудит. Для поставщиков высокого уровня критичности проведите полноценный аудит — на площадке вендора или дистанционно. Проверьте: физическую безопасность серверных, процедуры управления доступом, практики безопасной разработки (SDLC), наличие SBOM (Software Bill of Materials), процесс управления изменениями.

Этап 5. Формирование отчёта и плана корректирующих действий. Зафиксируйте выявленные несоответствия, оцените их критичность и согласуйте с вендором сроки устранения. Укажите, какие риски организация принимает, а какие — требуют обязательного закрытия.

Этап 6. Регулярный мониторинг (контроль A.5.22). Аудит — это не разовое мероприятие. Установите KPI: время реагирования на инциденты, количество выявленных уязвимостей за период, сроки применения патчей. Проводите повторную оценку не реже одного раза в год.

Матрица оценки рисков поставщика

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

Интерпретация баллов: 6–9 — низкий совокупный риск (достаточно самооценки вендора), 10–14 — средний (требуется документальный аудит), 15–18 — высокий (полный аудит с выездом, включение в план непрерывного мониторинга). Эта матрица прямо вытекает из требований контроля A.5.19 и может быть использована как приложение к Заявлению о применимости (SoA).

При работе с вендорами, обрабатывающими персональные данные, матрицу рисков следует дополнить критериями, связанными с интеграцией ISO 27001 и 152-ФЗ. Это позволит одновременно закрыть требования и стандарта, и российского законодательства.

Чек-лист проверки подрядчика по информационной безопасности

Ниже приводим чек-лист, который наши аудиторы используют при оценке вендоров ПО. Он основан на контролях ISO 27001 Annex A и рекомендациях ISO 27036 и может быть адаптирован под специфику вашей организации.

Организационная безопасность:

• ☐ Наличие утверждённой политики информационной безопасности
• ☐ Назначен ответственный за ИБ (CISO или аналог)
• ☐ Проводится регулярное обучение персонала по вопросам ИБ
• ☐ Наличие сертификатов (ISO 27001, SOC 2 Type II, PCI DSS)
• ☐ Наличие страхования от киберрисков

Безопасность разработки (SDLC):

• ☐ Применяются практики безопасной разработки (OWASP, SAST/DAST)
• ☐ Ведётся Software Bill of Materials (SBOM)
• ☐ Проводится анализ зависимостей на известные уязвимости (SCA)
• ☐ Реализовано разделение сред: разработка, тестирование, продакшен
• ☐ Проводятся регулярные пентесты (не реже 1 раза в год)

Управление доступом и данными:

• ☐ Реализован принцип наименьших привилегий (Least Privilege)
• ☐ Применяется многофакторная аутентификация (MFA)
• ☐ Данные шифруются при передаче (TLS 1.2+) и хранении (AES-256)
• ☐ Ведётся журналирование доступа к критичным системам
• ☐ Определены процедуры удаления данных при завершении договора

Управление инцидентами и непрерывность:

• ☐ Существует и протестирован план реагирования на инциденты ИБ
• ☐ Определены сроки уведомления заказчика об инцидентах (≤ 24 часа)
• ☐ Наличие плана обеспечения непрерывности бизнеса (BCP/DRP)
• ☐ Регулярное резервное копирование с проверкой восстановления
• ☐ Определены RTO и RPO для критичных сервисов

Управление субподрядчиками (контроль A.5.21):

• ☐ Вендор раскрывает список ключевых субподрядчиков
• ☐ Требования ИБ транслируются на субподрядчиков
• ☐ Уведомление заказчика при смене субподрядчика

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

Типичные ошибки при аудите вендоров и как их избежать

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

Ошибка 1. «У них есть ISO 27001 — значит, всё в порядке». Наличие сертификата — хороший знак, но не гарантия. Область сертификации может не покрывать те услуги, которые вендор оказывает именно вам. Всегда запрашивайте скоуп сертификата и проверяйте, входят ли в него релевантные процессы.

Ошибка 2. Формальный подход к опросникам. Вендор ставит галочки в SAQ, организация принимает ответы без верификации. Это создаёт ложное чувство защищённости. Наш совет: для критичных поставщиков всегда запрашивайте подтверждающие документы — скриншоты настроек, результаты сканирований, копии политик.

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

Ошибка 4. «Проверили один раз — и забыли». Контроль A.5.22 требует регулярного мониторинга. Ситуация вендора может измениться: сменился владелец, прошло сокращение ИБ-отдела, изменились субподрядчики. Без регулярных проверок вы узнаете о проблемах только после инцидента.

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

Ошибка 6. Отсутствие «права на аудит» в договоре. Если в контракте не зафиксировано право заказчика проводить проверки, вендор может на законных основаниях отказать. Включайте условие «right to audit» ещё на этапе подписания соглашения (контроль A.5.20).

Практические рекомендации: выстраиваем Supply Chain Security

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

Создайте реестр поставщиков. Ведите единый документ со всеми вендорами, их классификацией по уровню риска, сроками последней проверки и статусом выполнения корректирующих мер. Это базовый артефакт для демонстрации соответствия ISO 27001 на сертификационном аудите.

Внедрите Zero Trust подход. Исходите из предположения, что любой внешний сервис может быть скомпрометирован. Сегментируйте сеть, ограничивайте доступ вендоров принципом Least Privilege, мониторьте активность привилегированных учётных записей. Кейс SolarWinds показал: организации с принципом «нулевого доверия» пострадали значительно меньше.

Требуйте SBOM от вендоров ПО. Software Bill of Materials — перечень всех компонентов, библиотек и зависимостей в поставляемом продукте. Наличие SBOM позволяет оперативно оценить, затронут ли ваш софт при обнаружении новой уязвимости (вспомните Log4Shell). В 2025–2026 годах требование SBOM становится де-факто стандартом для зрелых компаний.

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

Используйте стандарты как основу, а не как ограничение. ISO 27001 и ISO 27036 дают фреймворк, но его нужно адаптировать. Компания, работающая с ИИ-системами, должна дополнительно оценивать риски, связанные с моделями машинного обучения в продуктах вендоров: предвзятость обучающих данных, утечку данных через инференс, отсутствие контроля дрейфа модели.

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

Управление безопасностью цепочки поставок — это область, где стандарты и практика сходятся наиболее наглядно. Организация может иметь безупречную внутреннюю СУИБ, но единственный непроверенный подрядчик способен обнулить все усилия. В мире, где атаки на supply chain удваиваются каждый год, системный подход к аудиту вендоров — это инвестиция в устойчивость бизнеса.

Сертификационный центр «Астелс» помогает компаниям выстроить процесс управления поставщиками в соответствии с ISO 27001, провести gap-анализ и подготовиться к сертификации. Мы разрабатываем политики, реестры поставщиков, опросники SAQ и сопровождаем организации на каждом этапе — от первичной оценки до успешного прохождения сертификационного аудита. Свяжитесь с нами, чтобы обсудить ваш проект.