Проверка подрядчиков по ИБ: как оформить due diligence контрагента

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

Due diligence контрагента по ИБ — это постоянная оценка надежности. Она начинается до договора, продолжается во время сотрудничества и меняется после инцидентов или важных изменений.

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

🔍 Что такое due diligence подрядчика по ИБ

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

Техническая проверка отвечает на узкий вопрос: есть ли сейчас у системы заметные слабые места. Due diligence отвечает шире: можно ли доверить партнеру доступ, данные и выполнение важного процесса.

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

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

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

Что сделать сейчас: разделите в своих процедурах технический аудит и полную проверку контрагента. Для каждого подрядчика назначьте владельца оценки.

📊 Как определить уровень критичности подрядчика

Одинаковая анкета не подходит всем партнерам. Риск зависит от доступа к системам, объема данных и влияния подрядчика на бизнес.

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

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

Высокий уровень получают подрядчики с привилегированным доступом, подключением к сетям или обработкой значительного объема данных. К этой группе относят поставщиков инфраструктуры и исполнителей важных ИТ-работ.

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

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

Что сделать сейчас: составьте таблицу подрядчиков и присвойте каждому уровень: низкий, средний, высокий или критический. Не повышайте уровень только из-за известности бренда.

🧾 Что проверить в компании и ее окружении

Сначала проверьте юридическую и деловую сторону. Поиск по ИНН помогает увидеть статус компании, задолженности и судебные дела. Эти сведения показывают только часть картины.

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

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

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

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

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

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

🛠️ Как проверить техническую защищенность

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

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

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

Проверьте межсетевые экраны на периметре. В практическом чек-листе отдельно указаны средства уровня L3/L4. Запросите описание правил и порядок их пересмотра.

Уточните, как подрядчик ищет и устраняет уязвимости. В опубликованном чек-листе указано: критические уязвимости на периметре исправляют в течение 30 дней, а на серверах — в течение 90 дней.

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

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

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

Что сделать сейчас: отправьте подрядчику чек-лист из 15 пунктов. Отметьте не только наличие меры, но и доказательство ее работы.

☁️ Особенности проверки облачных и ИТ-поставщиков

Облачный или ИТ-поставщик часто использует много компонентов. В его контуре могут работать операционные системы, плагины, библиотеки и внешние сервисы.

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

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

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

Отдельный пример связан с критичной уязвимостью компонента Linux. Ее высокий балл CVSS 9.8 показывает, почему поставщик инфраструктуры должен контролировать системные компоненты.

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

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

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

📋 Какие доказательства считать достаточными

Ответ «у нас все защищено» не подтверждает контроль. Каждое важное утверждение нужно связать с документом, отчетом или результатом проверки.

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

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

Проверяйте актуальность документов. Укажите дату выпуска, область действия и систему, к которой относится доказательство. Не принимайте общий документ вместо подтверждения по нужному сервису.

Разделяйте самодекларацию и независимое подтверждение. Анкета показывает позицию подрядчика. Отчет аудита или теста дает дополнительную опору для решения.

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

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

Что сделать сейчас: добавьте к каждому пункту анкеты поле «доказательство» и поле «дата повторной проверки». Пустое поле считайте незакрытым.

⚖️ Как оформить риск-ориентированную оценку

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

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

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

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

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

В практическом чек-листе первые восемь пунктов названы минимальным набором для подрядчиков с доступом к ИС. Без них сотрудничество несет высокий риск.

К числу важных критериев относят требования к подрядчикам в договоре, ответственного за ИБ, парольную политику и MFA. Также проверяют межсетевой экран, уязвимости и реагирование.

Для оценки состояния защищенности используется 13 критериев, объединенных в четыре блока. Требования к подрядчикам обозначены критерием k13. В расчете показатель относится к группе «Организация» и имеет вес 10 процентов.

Приказ ФСТЭК №117 вступает в силу 1 марта 2026 года. Этот факт нужно учитывать при обновлении внутренних процедур и договорных шаблонов.

Что сделать сейчас: создайте матрицу «уровень риска — решение — срок исправления». Не допускайте исключения без письменного обоснования.

🔐 Какие условия включить в договор

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

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

Зафиксируйте сроки устранения уязвимостей. Можно использовать контрольные сроки из рабочего чек-листа: 30 дней для критичных проблем на периметре и 90 дней для критичных проблем на серверах.

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

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

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

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

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

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

🔄 Как контролировать подрядчика после допуска

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

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

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

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

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

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

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

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

✅ Чек-лист перед допуском контрагента

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

• Определен уровень доступа к системам и данным.
• Проверены юридический статус, долги и судебные дела.
• Установлены владельцы компании и фактические исполнители.
• Раскрыты субподрядчики и их роли.
• Проверена история инцидентов и исправления нарушений.
• Назначен ответственный за ИБ.
• Действует парольная политика.
• Включена MFA для привилегированных пользователей.
• Удалены учетные записи уволенных сотрудников.
• На периметре работают межсетевые экраны L3/L4.
• Есть порядок поиска и устранения уязвимостей.
• Работают резервное копирование и журналирование.
• Есть антивирусная защита и проверка почтовых вложений.
• Утвержден регламент реагирования на инциденты.
• В договоре закреплены доступ, уведомления, аудит и субподрядчики.

Для каждого пункта укажите статус: выполнено, частично выполнено или не выполнено. Частичный статус требует срока исправления и ответственного лица.

Итоговое решение может разрешить доступ, разрешить его с ограничениями или отказать. Важно записать причину решения и условия повторного допуска.

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

Что сделать сейчас: сохраните чек-лист в системе учета рисков. Не выдавайте доступ, пока владелец риска не подтвердит итоговое решение.

📚 Читайте также

• Корпоративный мессенджер без вендорского капкана: чек-лист компании
• Песочница для ИИ-агента: как вовремя заметить опасные действия
• Квантовая криптография и постквантовая безопасность: подготовка к эре квантовых компьютеров
• Антифрод против ИИ: почему согласованность сигналов важнее отпечатка
• Фальшивый криптостартап: как КНДР вербует разработчиков и хакеров

📖 Термины

IAM (Identity and Access Management) · MFA · SBOM · Supply Chain Attack

🔗 Источники

• Обзор CICADA8 Cyber Rating 26.3.1: платформа оценки рисков контрагентов(2026-09-17 ✓)
• Проверка контрагентов службой безопасности(2026-09-17 ✓)
• Чек-лист проверки контрагента по ИБ — ФСТЭК №117 | КРЕДО-С(2026-09-17 ✓)