По итогам голосования победил вариант «сложно все» 😅 И это очень похоже на реальность тендерной ИБ-части

По итогам голосования победил вариант «сложно все» 😅 И это очень похоже на реальность тендерной ИБ-части.

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

И чаще всего сложности начинаются на стыках.

⏩Сертификат есть, но не подтверждает нужный продукт

Сертификация кажется понятным блоком: либо сертификат есть, либо нет. Но для тендера этого недостаточно.

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

Формально документ есть. Но требование конкретного тендера он не закрывает, и заказчик это видит.

⏩SDLC внедрен, но его нельзя подтвердить

Команда может использовать SAST, проводить ревью кода, работать с уязвимостями и встраивать ИБ-проверки в пайплайн.

Но серьезный заказчик может запросить политику безопасной разработки, этапы проверки кода, результаты SAST/DAST, сведения об инструментах, роли и порядок работы с уязвимостями.

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

Зрелость SDLC в закупке оценивается не только по коду, но и по тому, можно ли показать процесс снаружи.

⏩Документы есть, но описывают прошлую компанию

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

Политика ИБ могла последний раз обновляться два года назад. План реагирования — описывать инфраструктуру, которой уже нет. Регламент — ссылаться на продукт, выведенный из эксплуатации. А зоны ответственности в разных документах могут расходиться.

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

⏩Инфраструктура работает, но не совпадает с требованиями

Инфраструктурные требования сложнее всего быстро исправить.

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

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

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

Почему побеждает вариант «сложно все»

Тендерная ИБ-часть работает как доказательная система.

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

Поэтому перед подачей важно проверять не только наличие сертификатов, документов и процессов, но и связи между ними:

➡️совпадает ли продукт в сертификате, документации и заявке

➡️покрывает ли сертификат нужный контур и актуальную версию

➡️описывает ли SDLC реальный процесс разработки

➡️есть ли артефакты проверок, которые можно показать

➡️соответствует ли документация текущей инфраструктуре

➡️не противоречат ли документы друг другу

➡️подтверждают ли технические меры то, что заявлено в политике ИБ

➡️понятно ли, кто отвечает за уязвимости, инциденты и эксплуатацию

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

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

😎