"Даже в 2026 году заявки на госзаказ в ИТ идут по устаревшим шаблонам: куча формальностей, но мало вопросов о реальной компетенции. Часто выигрывает не тот, кто безопаснее делает, а тот, кто лучше заполняет клеточки. Это проблема обеих сторон — заказчик не получает того, чего хочет, а исполнитель тратит время на бюрократию вместо технологий."
Стандартный пакет вопросов и документов для тендера
Тендерная документация часто вызывает раздражение у технических специалистов — кажется, что она создана специально, чтобы отнимать время и заставлять писать очевидные формальности вместо решения реальных задач. Однако именно в этом папке кроются возможности и ловушки для обеих сторон. Грамотный пакет документов с правильными вопросами, это фильтр, который отсеивает несерьёзных исполнителей и фокусирует диалог на содержании, а не на бюрократии.
Привычный подход в госзакупках и крупных коммерческих тендерах — использовать устоявшийся, из года в год повторяющийся набор документов. Этот пакет часто перегружен общими требованиями и шаблонными вопросами, которые не отражают специфику современного ИТ-проекта, особенно связанного с защитой информации, интеграциями и разработкой под регуляторные требования.
Задача этой статьи — не переписать учебник по 44-ФЗ или 223-ФЗ, а разобрать структуру и содержание типового пакета. Мы выявим слабые места стандартного подхода, определим, какие вопросы в нём не задаются, но должны быть, и как можно адаптировать документацию под реалии российского ИТ-рынка, где вопросы безопасности данных (152-ФЗ, ФСТЭК) и импортозамещения стали неотъемлемой частью любого проекта.
Структура типового тендерного пакета: форма над содержанием
Стандартный набор документов для участия в тендере на ИТ-услуги или разработку ПО обычно формируется юристами и закупщиками, а не техническими специалистами. Это приводит к ситуации, когда объём формальной информации огромен, но критически важные для проекта вопросы остаются без ответа.
Основные разделы пакета
- Извещение и документация о закупке. Основной документ, описывающий предмет закупки, сроки, порядок рассмотрения заявок. Часто содержит лишь общие слова о «создании информационной системы» или «оказании услуг по технической поддержке».
- Техническое задание (ТЗ) или Технические требования. Ключевой для исполнителя раздел. В идеале он должен максимально подробно описывать, что нужно сделать. На практике же нередко встречаются расплывчатые формулировки: «обеспечить высокую скорость работы», «создать современный интерфейс», «настроить безопасный обмен данными». Отсутствие конкретных требований к информационной безопасности — больная тема. Часто в ТЗ просто ссылаются на необходимость соблюдения 152-ФЗ без детализации мер защиты.
- Требования к участникам (квалификационные критерии). Здесь заказчик пытается отсечь неподходящих кандидатов. Стандартный набор включает:
- Наличие в штате специалистов с высшим образованием или определёнными сертификатами.
- Опыт работы по аналогичной тематике (часто измеряется в годах, а не в конкретных проектах).
- Финансовые показатели компании (отсутствие убытков и определённый размер выручки).
- Отсутствие исполнителя в реестре недобросовестных поставщиков. Эти критерии — формальный фильтр. Они не говорят о реальной способности компании выполнить технически сложный проект.
Проблема отсутствующих вопросов
Основной недостаток — пакет сосредоточен на формальных допусках, а не на содержательной экспертизе. Исполнитель должен доказать «устойчивость» и «опыт работы 5 лет», но не обязан раскрывать свои процессы разработки, подход к тестированию безопасности, методы управления инцидентами или архитектурные решения. Заказчик же, формально выполнив требования законодательства о закупках, часто остаётся в неведении о техническом уровне потенциального подрядчика.
Ключевые блоки документов, которых обычно не хватает
Чтобы тендер стал не просто формальной процедурой, а инструментом выбора оптимального партнёра, пакет должен быть дополнен.
Функциональные и нефункциональные требования
Вместо расплывчатого ТЗ нужна детализация, особенно в части, касающейся безопасности. Это не просто отсылка к 152-ФЗ. Конкретика может выглядеть так:
- Требования к аутентификации: Используется ли многофакторная аутентификация (МФА)? Как реализован контроль сессий? Как происходит сброс паролей?
- Требования к логированию и аудиту: Какие именно события подлежат обязательному логированию (попытки входа, изменение прав доступа, доступ к персональным данным)? Где хранятся логи и как обеспечивается их целостность?
- Обработка персональных данных: Если проект связан с ПДн, необходимо уточнить, какие именно меры защиты из приказа ФСТЭК №17 или №21 должны применяться в рамках системы. Табличная структура помогает сделать требования понятными:
| Категория требования | Конкретное требование | Обязательность |
|---|---|---|
| Безопасность | Реализовать МФА для администраторов системы. | Обязательно |
| Безопасность | Все HTTP-соединения должны использовать TLS 1.2+. | Обязательно |
| Надёжность | Время наработки на отказ (MTBF) ключевых компонентов — не менее 10 000 часов. | Желательно |
| Масштабируемость | Система должна устойчиво работать при увеличении нагрузки в 2 раза за 6 месяцев. | Обязательно |
Детализация архитектурных и процессных требований
Это вопросы к исполнителю, позволяющие оценить зрелость его процессов. Стандартный пакет их почти никогда не включает.
- Архитектура безопасности: Какие модели угроз (STRIDE, PASTA) используются при проектировании? Как организована сегментация сети в предлагаемом решении? Планируется ли проведение внешнего аудита безопасности кода или пентеста силами аккредитованной ФСТЭК организации?
- Процессы DevOps/DevSecOps: Используется ли статический/динамический анализ безопасности кода (SAST/DAST)? Как встроен контроль зависимостей на наличие известных уязвимостей? Как организован процесс обновления ПО и компонентов, включая импортозамещённое ПО?
- Управление инцидентами безопасности: Есть ли у исполнителя документированный регламент реагирования на инциденты ИБ (согласно ГОСТ Р 57580.1)? Каковы примерные сроки реакции на критический инцидент, связанный с утечкой ПДн?
Декларация о цифровом суверенитете и импортозамещении
Этот блок становится всё более актуальным. Речь не только о софте, но и о компетенциях.
- Стек технологий: Указать, какие отечественные СУБД, операционные системы, средства виртуализации, фреймворки будут использоваться, а также обосновать их выбор.
- Модель миграции: Если проект предполагает переход с иностранных решений на российские, исполнитель должен кратко описать план такой миграции, включая оценку рисков.
- Ответственные специалисты: Есть ли в команде специалисты, сертифицированные по работе с ключевыми российскими платформами (например, Astra Linux, «Ред ОС», Postgres Pro)?
Практика: как адаптировать и дополнить пакет
Для заказчика: от шаблона к содержанию
Не стоит слепо копировать прошлые пакеты документов. Лучше начать с технического совета внутри компании или с привлечённых архитекторов. Их задача — составить не просто ТЗ, а технико-коммерческое предложение, в котором бизнес-требования дополняются чёткими техническими и процессными критериями.
- В раздел «Требования к участникам» добавьте не только формальные сертификаты, но и требование предоставить кейсы (Case Study) по 2-3 аналогичным проектам с описанием решённых сложностей, особенно касающихся безопасности.
- Вместо абстрактного «опыт работы 5 лет» сформулируйте «команда проекта должна включать не менее одного специалиста с подтверждённым опытом проведения пентестов или аудита безопасности веб-приложений».
- Создайте отдельный опросный лист (RFQ-Questionnaire) для технической команды. Это 20-30 конкретных вопросов по архитектуре, безопасности, релизному циклу. Ответы на них станут основой для оценки предложения помимо коммерческой части.
Для исполнителя (поставщика): как отвечать правильно
Получив нестандартный, детализированный пакет, не стоит паниковать. Для грамотной компании это сигнал о серьёзном и технически подкованном заказчике.
- Не оставляйте вопросы без ответа. Если какой-то пункт неясен — запрашивайте разъяснения в установленный порядком тендера срок.
- Давайте развёрнутые, но структурированные ответы. Используйте списки и таблицы для ясности. Например: «Для обеспечения требований к логированию мы предлагаем: 1) внедрение централизованной системы сбора логов на базе Rsyslog; 2) классификацию событий безопасности; 3) ежедневную проверку целостности логов».
- Создайте «приложение по безопасности». Если в тендерной документации вопросы безопасности разбросаны, объедините все свои меры в отдельный краткий документ (Security Appendix), где наглядно покажете, как требования ФСТЭК и 152-ФЗ будут заложены в архитектуру и процессы на каждом этапе.
- Готовьтесь к презентации. Самые сложные технические тендеры почти всегда включают очную презентацию решения. Лучше, если её будет вести не только менеджер, но и ведущий архитектор или специалист по безопасности.
Эволюция тендерной документации, это путь от бюрократической отчётности к содержательному диалогу между заказчиком и исполнителем. Стандартный пакет вопросов сегодня, это не более чем минимальная планка, стартовая точка. Его настоящая ценность раскрывается, когда обе стороны выходят за рамки формальностей и начинают обсуждать технологии, процессы и реальные механизмы решения задач.
Заказчик, который умеет задавать правильные, «неудобные» технические вопросы, с гораздо большей вероятностью получит качественный результат и избежит долгих и дорогостоящих переделок в середине проекта. Исполнитель же, способный на эти вопросы чётко и аргументировано ответить, не только побеждает в конкретном тендере, но и позиционирует себя как зрелого и надёжного технологического партнёра. В конечном счёте, такой подход экономит ресурсы всех участников и способствует повышению общего уровня зрелости российского ИТ-рынка, особенно в чувствительных областях, связанных с безопасностью и данными.